We've setup some scripts in SCOM to monitor some stuff in Red Hat machines.
Actually the scripts are located on the Red Hat servers and scom just calls the scripts. In the sudoers file we've allowed the scom user to run the script (bin/bash -c script.sh).
On some machines this works fine, but on others it fails with errors that is't not allowed to run. In the securelog we can see that this script is being called with bin/sh instead of bin/bash. if we change the sudoers to bin/sh -c script.sh it works, but as we use a centralised sudoers file we'd really like to know how we can influence the shell process that the scom agent/user calls so we only have to include /bin/bash or /bin/sh
The env. variable for the scom user is the same on all servers (shell=/bin/bash).
May 19 15:19:26 SERVERNAME sudo: SCOMUSER : command not allowed ; TTY=unknown ; PWD=/var/opt/microsoft/scx/tmp ; USER=root ; COMMAND=/bin/sh -c /usr/local/bin/scomscripts/service_check.sh
in the sudo file:
SCOMUSER ALL=(root) NOPASSWD: /bin/bash -c /usr/local/bin/scomscripts/service_check.sh
- Edited by rob1974 Thursday, May 19, 2016 2:03 PM
We will honor the SHELL environment variable. The problem is that the job running this is not an interactive job (it's a network job), and how network jobs get initialized will vary based on shell version and similar issues. It's unstable enough where I like to say it depends on the phase of the moon, but that's not strictly true. It also depends on the mood of my 14 year old kid. :-)
You can do a "man sh" on RedHat, and it does talk extensively about startup behavior. But again, I've found that certain versions of bash run startup scripts where newer versions of bash did not, only to find that according to the specs, when starting a network job, the documented behavior is not to call anything (unless a specific environment variable is set, which you have minimal control over as a user, although you can perhaps influence it via system setup files like /etc/profile and the such - I'm not certain). I think it's defined this way for performance purposes; network jobs can be started commonly, and you don't want to run several seconds worth of startup scripts where, most of the time, you don't need them for network jobs.
Bottom line: If you want startup scripts to run, you should run that yourself as part of your scripting. BUT: You have the added complexity where this is called from OM on Windows, and the EXACT command line is done in a way where you have no control over it (since you can't strictly control the value of the SHELL environment variable).
What I would suggest, given your common /etc/sudoers file, is to do this:
1. Know that the SCOM agent will default to /bin/sh if SHELL is not defined. Otherwise, it will honor SHELL,
2. You could always run /bin/sh and then, if your script actually requires bash, you can ask /bin/sh to run your script via bash by adding "#! /bin/bash" as the first line of your script (without quotes). The /bin/sh program will honor that.
3. Because of these choices, either don't define the SHELL environment variable, or if you really want to, define SHELL=/bin/sh
4. If your script needs other initialization to be done (like running .bash_profile and such), it should do that itself.
In this way, your actual sudo invocation will ALWAYS be /bin/sh all the times, but for scripts that actually require bash, you can make that happen without affecting the sudo invocation command line.
Hopefully this helps. Please let me know if you have further questions.
- Edited by Jeff CofflerMicrosoft employee, Moderator Thursday, May 19, 2016 4:21 PM
Thanks for the reply, but unfortunately a lot of things we've tried already (and my linux knowlegde is that great, so i have to rely on the linux admins here).
The SHELL of the user = /bin/bash
The first line of the script = "#! /bin/bash"
But still it's being called as /bin/sh. Is there a system variable/network variable for SHELL? As in scom reads the system var instead of using the shell variable for the scom user.
- Edited by rob1974 Monday, May 23, 2016 11:07 AM
There is no concept of "system variable/network variables". Each process has it's own set of environment variables, controlled by system settings, or perhaps by nothing at all. It depends on the version of the shell, and what it chooses to execute for startup scripts. Here's a great example on my CentOS 7.x system:
jeffcof:~> env | wc -l
jeffcof:~> ssh jeffcof64-cent7x-01 "env | wc -l"
This means that my primary (interactive) job has 34 environment variables, but if I perform a network job, it only has 17 variables (and a good chunk of those are SSH/SELinux variables, that I have no direct control over).
For network jobs, your login scripts may not run, and your interactive shell may not be honored (given that it's not an interactive job).
Please read over my prior message carefully (or give it to your Linux admin). You really do NOT want to set your SHELL environment variable at all (or set it to /bin/sh in .profile, which may be read). Then count on the #! line to control the actual interpreter that's run for your shell script. In this way, you should have a nice, consistent shell. Note that, if defined, SCOM will honor the SHELL script, but it's tough to be certain of that on all versions of all Linux platforms. Better to let SCOM default to /bin/sh (nice and consistent for sudoers), and then depend on #! if you truly need bash.
Another option, of course, is to duplicate the sudoers definitions for both /bin/sh and /bin/bash. Not preferable, but perhaps an option if you feel like you've spent enough time on this and just want to move on. But, with careful interpretation of my prior message, you should be in pretty good shape, I believe.
Hope this helps,
- Edited by Jeff CofflerMicrosoft employee, Moderator Monday, May 23, 2016 3:22 PM
I have given this blog to the linux admins, but they don't really know what to check (they did check a few files where SHELL was configured, but they are the same between the devices).
Here they just use 2 versions of redhat (5 and 6) and they are all on the same patchlevel. They also supposed to be configured the same, but still scom calls the scripts with a different SHELL. I assume that the servers that use /bin/bash have something configured, but we don't know where to look.
We know about the 2 lines in sudo; maybe we will do that. But this is also about giving the idea that MS knows what it's doing on Linux as there's a lot of mistrust by the linux admins.
- Edited by rob1974 Tuesday, May 24, 2016 9:11 AM
Good Afternoon Rob. This is my very first foray into the forums, but I need to start somewhere. I'm converting all of our Unix monitors to SCOM, so your question about what shell SCOM chooses when submitting a script is a critical issue to me as well. Right now, for every privileged script I release, I must submit a SUDO line prefixed with every possible flavor and path of shell in our environment. As such, my SUDO files are growing exponentially. And the quality of our SCOM monitoring is rightfully questioned since the best coded script will ABEND (and fail to issue alerts) if SCOM tries to run it under an unauthorized shell or a shell run from a previously unknown location. This is totally unacceptable. Did you ever find an answer? Is there any way to control what shell the SCOM agent will use when submitting a script? In our company the only universally available, consistently located, shell on every HP, AIX, RedHat, Solaris etc system is bash. What I wouldn't give to be able to force SCOM to use it for all scripts. Thanks for any leads. Britt
i think we ended up to add both commands in the sudoers as we never found out how to make configure this. But that's only because that environment had a central sudoers file.
In the end, the script runs fine and there's not really an issue, just administrative overhead.
Also note, that for another environment in which all servers were automatically deployed (devops > os as code) i didn't experience this issue. But who knows, someday it will automagically change from bin/bash to bin/sh when the OS gets an upgrade.
- Edited by rob1974 Monday, March 20, 2017 3:03 PM