• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2487
  • Last Modified:

su-ing to another user in a ksh script

I would like help writing a ksh script to automate recycling my application on solaris.  

Shutdown/Startup of the main application requires stopping/starting 6 sub-applications.
Each of the 6 sub applications has it's own start/stop executable, but has to be run by different users.

None of the scripts require root access and all of the user accounts have the same password.  
I would think that limiting read access to the script to only the user and/or group would be enough
security for my needs that I could use a plain text password within the script.  But would like your advice.

I have searched the archives, but did not find what I was looking for, and appreciate your expertise

I want the script to:

su - user1  (password)
stop_script1.ksh
(wait long enough for this application to stop)
(check if a certain process is running)

su - user2  (password)
stop_script2.ksh
(wait long enough for this application to stop)
(check if a certain process is running)

then after all 6 applications have been stopped,
I want to su to all 6 account again and run their start scripts.
0
theoradically
Asked:
theoradically
2 Solutions
 
yuzhCommented:
Write your script first.

then config "sudo" to allow the user to run the script without password.

For Solaris you can download sudo from:
http://sunfreeware.com/

also have a look at the following page to see how it work:
http:Q_20985727.html

or you can use expect script to handle the password:
http:Q_20419559.html

I prefer the "sudo" solution, more secure.

0
 
yuzhCommented:
Just in case you need a sample script:

#!/bin/ksh
/path-to/stop_script1.ksh

#check if a process is running

if [ ps -ef|grep -w process-name | grep -v ] ; then
   echo "ProcessName  is running "
   # you might need to add statememet to kill the process
   # eg:
   # kill -9 `ps -ef|grep -w process-name | awk '{print $2}'`
else
   echo "ProcessName is not exist"
fi

#restart process
/path-to/startupscript start

exit
#end of script

To run the about script as user1:

su - user1 -c "/path-to/abovescript

man su
to learn more details

0
 
jkrCommented:
Just as a side note, if the script is run by 'root', you won't need a password for 'su' anyway...
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
ahoffmannCommented:
#!/bin/sh
su - user1 -c "/path/stop_script1.ksh"
su - user2 -c "/path/stop_script2.ksh"
# and so on ..
exit

run above script as root
0
 
chris_calabreseCommented:
The whole point of having different users is so that you can't do this type of thing.

The mechanism in Unix for going "above" the usual user restrictions is through root, whether it's running the main script as root so that no su password is necessary or using root to manage the sudo access file (sudoers).

The one way I can think of around this is to use SSH trusts between the accounts. But that obviates the point of having different accounts.

Also, it's a bad idea to have a password that anyone knows on a non-person account - keeps you from  knowing who made the change that broke the system. Use SSH trusts or sudo to access such accounts instead.
0
 
theoradicallyAuthor Commented:
Yuzh,

Thanks for your quick response and thorough answer.  I tested Expect at home and it worked great.
Our systems at work require suing to the functional accounts used in the scripts.  Any time we use those
accounts, we must su from our primary ids to those account.  So Expect sounded like it should have worked fine.

When running the Expect scripts, I get "Interactive logons with this account are prohibited!"  So this looks like
an seos issue that I probably won't get around.  Your explanantion of Expect was great, though. Thanks


Ahoffman,

I was aware of that syntax, but if not run as root, I need to supply a password.  And, I "Ain't got R00T"
and did not supply that in my request.  But I do appreciate your time in responding.

0

Featured Post

Important Lessons on Recovering from Petya

In their most recent webinar, Skyport Systems explores ways to isolate and protect critical databases to keep the core of your company safe from harm.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now