I am developing a complicated automation script that will automate a large portion of my build, install, deploy and post installation processes. The problem is that within all of the commands that need to be issued, there is one that requires the user to be root. (This is a requirement constraint as is the need for the other user (we'll call user1) to not be on the sudoers list)
Basically the way I am structuring my scripts is, I have a starting script that must be run as root. This script will call two other scripts as user1.
All three scripts share a sharedFunctions.sh
script that defines common functions. Within this script I have a run_command
function that needs to take a command and a failure string among other arguments that are unimportant to this problem.
Now if the failure string appears in the output of the given command, I want to kill the parent process stopping the entire train. I have an exported variable of the parent PID that I grab from the root script, but if the script fails while it is running either of the two user1 scripts, I cannot kill that process because it is owned by root.
Is there a way to "exit" back to root without it requiring credentials (similar to how you can in the terminal) so I can kill the PID owned by root?
*****EDIT*****
This is the very simplified process that my script needs to follow formatted as such (required user:function):
user1:maven install
user1:scp jars to chef server
root:chef command
user1:chef command
user1:post-installation scripts
I have three scripts and one sourced script
user1cmd1.sh
parentscript.sh
user1cmd2.sh
sharedFunctions.sh
the parentscript.sh
first extracts the PID by using export TOP_PID=$$
it then calls user1cmd1.sh as user1
when that script finishes, it returns to the parentscript and as root the chef command is run
it then calls user1cmd2.sh as user1
my run_command
which is defined in sharedFunctions.sh
is scripted similar to this:
run_command(){
cmd=$1
fail=$2
if $cmd | grep -q $fail;then
kill $TOP_PID #there is more to this particular command, but I don't have it in front of me
fi
}
sudo
allows you control which commands any user can execute as anyone else, so you could have two different users a and b that can executecommand_a
andcommand_b
as users c and d, it makes very little sense to put those on one list. But that also hints at a possible solution, read the documentation forsudo
and think about whether it can solve your problem and whether your requirements actually prevent that (or can be loosened not to).