0

We have a command to handle the joining of our RHEL7 servers to Privilege Manager for Sudo that is not working when ran from the rc.local script. The command is below with more generic names instead of our specific assets.

echo "password" | /opt/quest/sbin/pmjoin_plugin -b -a -v -q -d masterport=12345 -d FailOverTimeOut=10 -d selecthostrandom=YES somehostname.com someotherhostname.com >> /var/log/Build.log

The command when ran manually or from other bash scripts work to perfection, but when it is executed from within rc.local, it is as if the password is not being piped into the command for when it is prompted for a password.

I've read some suggestions such as "plymouth quit" which has not helped.

Anyone out there have any experience with "echoing" a password to a command this way within the rc.local script so that you can proceed through an interactive script that prompts for a password?

Ultimately, this is just something we want to have run when an instance is first booted. So if there is another way to have a shell script to run once on boot and then delete itself without rc.local then we could explore that route too (crontab, etc?).

Sadadar
  • 13
  • 3
  • Are you saying that the command with `echo "password"` and no manual password entry works manually and from scripts? – that other guy Jun 06 '16 at 19:55
  • @thatotherguy that's correct. Something about rc.local seems to change the behavior or it works differently. If I take the command I have in the rc.local for this and run it from the command line, everything goes through fine. Same if I add it to a .sh script and call that script. If the command is run from the rc.local or rc.local tries to call the command in a .sh script then it doesn't work. The log I'm outputting to >> /var/log/Build.log acts like it has a bad password which leads me to believe it's not echoing the password the same way (or at all) within rc.local. – Sadadar Jun 06 '16 at 20:00
  • what happens if you put `echo "testtest" | cat > /var/log/testtest.log`into your rc.local, does the testtest.log show up? – Stefan Hegny Jun 06 '16 at 21:15
  • 1
    That adds testest into /var/log/testtest.log. – Sadadar Jun 06 '16 at 21:55
  • Ok so we know that the piping works inside the rc.local in principle, so it must be something around your pmjoin_plugin executable -might it go into interactive mode somehow and not continue? – Stefan Hegny Jun 07 '16 at 06:18
  • That's what I'm thinking as well. I'm thinking rc.local was behaving differently with answering an interactive mode response than if it was running in it's own script. I went ahead and implemented a different solution to get around that problem - added as an answer to this thread. – Sadadar Jun 07 '16 at 16:13

1 Answers1

0

I ended up implementing a solution that worked for my situation. While it's not as clean as just letting things run in rc.local, it will get the job done.

I took the command out of our rc.local script and put it into it's own .sh script. Our AMI build process stores it at /tmp/nameofscript.sh and I also created a systemd service file that the AMI process is storing in /etc/systemd/system/nameofservicefile.service. That service file executes with an ExecStart=/tmp/nameofscript.sh in it so that it will run on reboot. Our rc.local runs in a phase1 and phase2 sort of manner, with phase1 rebooting at the end, so I added a line to the phase1 portion to enable the service with "systemctl enable nameofservicefile.service" just before the reboot that happens as the last step of phase1.

Going this route enabled it so that the PM Sudo join command runs during our "phase2" steps since the reboot at the end of "phase1" triggered the script from the systemd service.

To ensure it doesn't run on every reboot, my /tmp/nameofscript.sh script has steps to rm -f /etc/systemd/system/nameofservicefile.server and to delete itself with rm -- "$0".

Probably a messy way to do this, but gets the job done.

Sadadar
  • 13
  • 3