I have a CIS-CAT .sh script for Linux that is running fine when initiated via the ssh command line on my remote CentOS 7 box. However, I’m having issues executing it successfully via BigFix.
The following BigFix Action Script is working fine until the last line:
// Download CIS-CAT
prefetch <sha1> sha1:<sha1> size:<1234567> http://myserver.com:52311/Uploads/<sha1>/CIS-CAT-Auto-Linux.tmp sha256:<sha256>
extract <sha1> /tmp/cis/
// Download JRE Linux x64 to endpoint
download http://myserver.com:52311/Tools/Linux_Java/jre-8u91-linux-x64.tar.gz
// Unpack the JRE tar.gz file
wait /bin/sh -c "tar -zxvf __Download/jre-8u91-linux-x64.tar.gz -C /tmp/cis/cis-cat-full/jres/"
// Rename Java version directory to jre
wait /bin/sh -c "mv /tmp/cis/cis-cat-full/jres/{name of folder of folder "/tmp/cis/cis-cat-full/jres/"} /tmp/cis/cis-cat-full/jres/jre"
// Run shell script
wait bin/sh -c "/tmp/cis/cis-cat-full/cis-cat-centralized.sh"
What command should I be using to simply run the “cis-cat-centralized.sh” script?
I’ve tried a bunch of different iterations of the “sh ./file.sh” command and am about ready to throw my laptop out the window. Here are a few:
So not sure if the line start format is correct for running Linux commands; if the quotes are needed; if the “sh” command is also required after typing “/bin/sh -c”, etc… I either see exit code 127, or no error (exit code 0), but it’s not running the script/tool.
Hey Alan, thanks for the assistance… still having issues though. So, the end of my script is now as follows (including modifying the script permissions and switching to the directory to the one where the script resides):
So it just doesn’t seem to like that… I’ve tried running all three commands without the -c (and quotes), but I get more errors (Exit Code 126).
Any ideas?
Regarding the “rename” relevance; the (Java) directory that we are renaming will be the only folder to be in there ever, as we copy the folder on the fly for the action, and then delete it when the action is done. It’s setup that way so that if the name of the Java folder changes, we won’t have to update the action script, as we are not hard-coding the specific folder name (but rather referencing the parent folder). Does that make sense?
It may be a shell environment issue as the BESClient on Linux does not run with the full root shell environment. I would recommend trying the following:
The above does assume that your script has the necessary shell designations.
Also, as a best practice don’t use download to pull artifacts through your BES infrastructure. When pulling artifacts through the BES infrastructure use the prefetch command. If you need to circumvent the BES infrastructure for some reason, use the Download Now As command.
Thanks all. Unfortunately, none of the commands above worked for me as a BigFix Action Script (and I don’t believe it was the script returning the errors; it was BigFix).
For anyone who is interested in achieving the same thing, what worked for me in the end was cd-ing to the required directory at the start of each command, and then combining that (&&) with running the required command, like so:
Be aware that the +x on some systems in /tmp may not work as some standards are to not allow executables in /tmp. You could just use /bin/sh directly to run the shell script without marking it executable.
That’s good to know @AlanM; I wasn’t aware. I’ve had a few failures, so tried removing the “mark as executable” command (in case that was the issue), but it’s still failing on those same machines. (I was running into issue with Java running out of memory, so increased the default allocation from 768MB to 1024MB to 1536MB. Has helped for some machines, but not all.)
Seems to be getting caught on the CIS-CAT shell script - running for hours - and is perhaps not related to anything I’m doing in the BigFix task. Need to figure out if I can quit the script if it doesn’t complete within say 30 minutes.
OK ! I have faced most likely same issue but have solved it by splitting fixlet in 2 actions, one for downloading files on endpoints with BIGFIX action script & 2nd action to run shell script with SH action script, and removed the default action for both of them so user can see both action while taking take action & use accordingly.
Interesting, @vk.khurava! I messed around a little with the SH action script but didn’t have any success… are you just using the "./CIS-CAT.sh" command in it?
Mine script is different but case is very much similer to it, we were trying to copy some file on endpoints & then executing a specific script which suppose to drop the output in a file somehow script was running perfectly fine but not creating output file, tried many ways to run it but could not helped hence I split the task into 2 action as described above & amazingly script part running fine under sh action script & generating output with same command which we were trying to run in BIGFIX action script.
This is not needed. You can do it all in 1 action.
Another work around for issues like this is running a shell script that uses CD to get to the correct directory, and then the rest of the commands run from within that directory as the base. I don’t generally do this for simple commands if I can just use absolute paths instead, but it does work.
You can have a single action that uses a prefetch to download files, then uses a create file command to create a script, then mark the script executable and run it.
I was trying to execute a shell script that had another embedded shell script. if I combined it with the command to change to the directory it worked. When it wasn’t combined “&&” with the change directory command the shell script immediately exited.
I tend to specify bash specifically as well. I’ve run into issues where most systems actually use bash for sh, but others don’t, and most scripts I find are using bash specific stuff, so if it fails with sh, so strongly recommend trying bash instead. (on MacOS sh is actually just a symlink to bash or something like that, while on some linux platforms, that is not the case, and sh is actually sh, which causes problems)
I’ve also seen Linux platforms where /bin/sh was symlinked to /bin/bash, but the shell would behave differently based on whether ‘sh’ or ‘bash’ was used by the caller.