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.
theoradicallyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.