(imported topic written by gregv91)
I’m scratching my head on this and hoping someone can shed some light.
Why is it that I can issue a command such as
wait touch /tmp/testfile
without any issue, yet something like
wait echo “test” > /tmp/testfile
doesn’t work?
What are the limitations and why are there any limitations at all? I don’t see why it wouldn’t just pass the command through to the shell? Seems to be any command that has redirection.
Much appreciated!
Greg
(imported comment written by nicoya91)
I don’t have any insight into this, but would like to echo that I’m having the same problem, only it’s not isolated to commands with redirection.
I’ve authored several custom fixlets that use varations of “wait rpm -i .rpm” or “run rpm .rpm”, no problems. Basic useradd or groupadd commands won’t work.
I’ve tried the following, thinking perhaps there were issues with paths or quotings,and I’ve tried them all with both “run” and “wait”:
wait /usr/sbin/useradd -c ‘bogus user’ -m -s /bin/false -G bogusgroup bogus
wait useradd -c ‘bogus user’ -m -s /bin/false -G bogusgroup bogus
wait useradd -c “bogus user” -m -s /bin/false -G bogusgroup bogus
wait groupadd bogusgroup
wait /usr/sbin/groupadd bogusgroup
Ironically, the client logs always report success:
At 13:04:24 -0600 - actionsite (http://:52311/cg
i-bin/bfgather.exe/actionsite)
Command succeeded wait /usr/sbin/groupadd bogusgroup (fixlet 14002)
Command succeeded wait /usr/sbin/useradd -c ‘bogus user’ -m -s /bin/false -G
bogusgroup bogus (fixlet 14002)
At 13:04:24 -0600 -
ActionLogMessage: (action 14002 ) ending action
I tried contacting BigFix support on this. Unfortunately the response was “We don’t support custom fixlets - try the forums”.
If I deploy the fixlet as a shell script instead of using the BigFix action language, works like a charm. It seems clear that there are limitations using run/wait with Unix/Linux systems. Just wish there was a way to find out what they are!
(imported comment written by BenKus)
Hey guys,
Sorry for the delayed response as we had an extended internal discussion about this and I forgot to post the answer…
Here is what I found (please remember that Unix is not my area of expertise so forgive me if I mis-speak):
You guys are correct in that this question involves commands with redirection… When you run a process as a daemon on Unix OSes, it is expected that you run your process without access to STDOUT and STDERR. This is how the BigFix Agent operates normally, which is fine and shouldn’t cause you any issues because the agent doesn’t write anything useful to STDERR or STDOUT anyway… But… When our agent launches a process (such as the commands you posted), the process inherits the run-environment, which means your processes won’t have acccess to STDERR/STDOUT either… Note that your processes are indeed executing…
We are looking into this to see if we have a way to get around this or change our behavior to avoid this… but it seems like everything is behaving as expected according to these rules…
Nicoya, note that I
think
your issue is a bit different… When you use “run” or “wait”, you are using “CreateProcess” and we are not using “ShellExecute”. This means that you will not have access to the built-in shell commands unless you launch the shell…
Try this instead:
wait sh –c command arg1 arg2 …
So for your command, try:
wait sh useradd -c ‘bogus user’ -m -s /bin/false -G bogusgroup bogus
See if that works…
Ben
(imported comment written by nicoya91)
Initiating the shell did not have any impact. Useradd and groupadd are not shell built-ins, so the logic behind why using the shell would make a difference is not valid. They are system binaries just like the “rpm” command. That is why it doesn’t make sense that “rpm” including options runs fine, but not something equally simple like “groupadd testgroup”. If only certain Unix/Linux binaries are compatible with the wait or run commands in BigFix action language, this is truly something that needs to be determined and documented by BigFix. Otherwise, the promise of the custom fixlet functionality falls a bit flat for us *ix customers.
Here is the exact syntax I used:
// enter your action script here
wait /bin/sh /usr/sbin/groupadd bogusgroup
wait /bin/sh /usr/sbin/useradd -c ‘bogus’ -s /bin/false -G bogusgroup bogus
I also tried both with fully qualified paths and not, just to rule that out. No difference. And I have tried on multiple systems to rule out issue with a particular client.
Side note - while the fixlet shows failed status, the local client logs continue to report success of both commands. However, neither the group or user is created.
While I can run this as a shell script via BES just fine, using the BigFix action language does offer some advantages, so I’d really like to use it. But not being able to run simple binaries is a show stopper.
(imported comment written by gregv91)
Thanks Ben… Keep us posted because this really limits what we can do on UNIX…
(imported comment written by sthull)
nicoya,
You need one more -c which is an argument to sh as well as useradd. Try:
wait /bin/sh -c /usr/sbin/groupadd bogusgroup
wait /bin/sh -c /usr/sbin/useradd -c ‘bogus’ -s /bin/false -G bogusgroup bogus
Regards,
Steve
(imported comment written by nicoya91)
I added the “-c” after the sh, same results:
from BES client logs:
At 21:28:14 -0600 - actionsite (http://:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded wait /bin/sh -c /usr/sbin/groupadd bogusgroup (fixlet 14021)
At 21:28:15 -0600 - actionsite (http://:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded wait /bin/sh -c /usr/sbin/useradd -c ‘bogus’ -s /bin/false -G bogusgroup bogus (fixlet 14021)
At 21:28:15 -0600 -
ActionLogMessage: (action 14021 ) ending action
But when I check the system for the ID and group, neither exist, and the fixlet reports Failed via BES console. I ran the fixlet on 2 test machines. Same results on both.
(imported comment written by Doug_Coburn)
Ben almost had it. This works on my test system that I just tested on:
Relevance:
(name of operating system as string as lowercase does not contain “win”) and (not exists line whose (it as string contains “bogusgroup”) of file “/etc/group”)
ActionScript:
delete __createfile
delete /tmp/bogus.sh
createfile until myend
#!/bin/sh
/usr/sbin/groupadd bogusgroup
/usr/sbin/useradd -c ‘bogus’ -s /bin/false -G bogusgroup bogus
myend
move __createfile /tmp/bogus.sh
wait /bin/sh -C /tmp/bogus.sh
The main difference is I created a shell script which I then executed with the -C option, on Linux it does need to be an uppercase C as opposed to lowercase c. I’ve also attached a Fixlet with the same information
(imported comment written by Doug_Coburn)
For the echo doing the same steps as above worked.
Relevance:
not exists file “/var/opt/BESClient/echo”
ActionScript
delete __createfile
delete /tmp/echo.sh
createfile until myend
#!/bin/sh
echo “This is an echo test” > /var/opt/BESClient/echo
myend
move __createfile /tmp/echo.sh
wait /bin/sh -C /tmp/echo.sh
example fixlet attached
(imported comment written by nicoya91)
Doug’s work around worked perfectly for me. Thanks!
It still does not answer the underlying question of why "wait rpm -i " or “run rpm -i” works, but an equally simple “run groupadd bogusgroup” does not.
The WinActions document for Windows and Unix for BES 7 documents the ‘run’ command simply as “Executes the indicated program”, and the ‘wait’ command as doing the same except also waiting for program to finish. It provides no caveats on behavior on *ix. The logical conclusion: “run groupadd” should work just as well as “run rpm”. However, that is not the case. It might save a lot of head-scratching (and probably future forum posts and support calls) if BES could document which *ix commands will work with ‘run’ and ‘wait’ and which won’t. Or, get ‘run’ and ‘wait’ to work as documented.
Thanks again for the work around.
(imported comment written by clementine91)
gregv
I’m scratching my head on this and hoping someone can shed some light.
Why is it that I can issue a command such as
wait touch /tmp/testfile
without any issue, yet something like
wait echo “test” > /tmp/testfile
doesn’t work?
I may be wrong but I suspect the child process is created thanks to a fork()/exec() sequence. So the shell redirection symbol is in argv[] but of no use in that context.
You may consider to run some shell with needed args or to create in the fixlet action section a shell script lauching your command.
If the child process was created with the stdlib system() routine it would work as you did expect but it has some other side effetcs…
With the hope that my explanation is the right one, I haven’t got yet any idea about BES client internals 
(imported comment written by gregv91)
Ben,
If I can’t redirect output, what’s the best way for me to go about getting output from a command?
For example I want to capture information output by “uname -a”
Thanks in advance for any help.
Greg
(imported comment written by BenKus)
Hey Greg,
Doesn’t Doug’s approach mentioned above work for you?
Ben
(imported comment written by gregv91)
Ben,
Missed it. Thought the post was in response to Nicoya’s post.
Thanks!
(imported comment written by gregv91)
Does this environment limitation with output redirection also affect Windows? I’m less familiar with Windows OSes but seem to come across the same problem when trying to run utilities with their output sent to a file…
Thanks!
(imported comment written by BenKus)
Nope… Windows doesn’t have the same issue…
You can easily check this by running a simple custom action:
waithidden cmd.exe /C echo testing… >> C:\test.txt
Which I believe should make the C:\test.txt file appear showing the echoing to work just fine…
What problem are you experiencing?
Ben
(imported comment written by NoahSalzman)
In case anyone is googling for “output redirection” and hits this old thread, I just wanted to make sure that we clarify:
Output redirection using > or >> works on non-windows, but you have to wrap it in quotes. E.g.:
waithidden /bin/sh -c “foo.sh > /home/bar”
Wish they could put your answer at the top. was having the same issue as this thread but with chown.
Sometimes old threads are the best 
. Helped to better understand handling of unix commands within fixlets.