backup script and oracle problem

[Lisa Mauer]

Hi all, yes I have another script problem :)
We have a backup user that logs in, ID of 0, the .profile is scripted to automatically run from that point on. All they do is log in, walk away and look for any error messages. The backup user with an ID of 0 can then "su -" to all users such as oracle and shutdown databases before backups and then "su -" back in to start them up once backups complete. My problem is, our dba's added a prompt in oracle's .profile to ask which database they are going to want to work with. Well, when the backup user tries to su to oracle, it hangs waiting for a response that it will never get because it is all running automatically behind the scenes. Is there a way that either I can answer the prompt through the "su -" which I have tried several times and to no avail, or is the original ID retained so far that I could check the ID - if 0 bypass the prompt code? Anyone have any ideas? They would be greatly appreciated. I know this is limited information our backup scripts are quite complex but I tried to "put it in a nutshell". Thanks!!

[Eugeny Brychkov]

Lisa,
ID 0 has user with name 'root' usually. Why do you want to run script under root? Not under dba account?
Eugeny

[Eugeny Brychkov]

Maybe you can develop C program to 'ungetc' desired characters into buffer so they retrieved by dba's script prompt
Eugeny

[Lisa Mauer]

Hi: Thanks for the response, we use the user id of 0 because we have many applications that need to be shut down a long with the databases. With a user id of 0 the script can run and become each user to shut down the necessary applications. We also check for looping processes, etc and kill those before the backups. It is a development environment and some code or processes from the programmers may be looping or hung etc....

[john korterman · Accepted solution]

Hi,
you can use the ksh logname command for asking who originally logged in. However, if two users share the same ID, logname will show the one that appears first in /etc/passwd ("root", I assume in this case).
Assuming again that your backup user logs in directly, you could make a check based on this skeleton in oracle's .profile:

ORIG_USER=`logname`
if [ $ORIG_USER != "root" ]
then
# enter code for dba's prompt
else
# enter code for
# database selection
fi

But you should keep in mind that the above logname test cannot distinguish between your backup user and the normal root user.

regards,
John K.

[Lisa Mauer]

John - I think that is exactly what I needed. I have coded that into the .profile and will run in tonight to see how it works.
Thanks!!

[Eugeny Brychkov]

As I know system's behavior depends not on user name ('root', 'admin', 'superuser', 'lamer', 'gamer' etc) but depends on user ID. So however you will name user with user ID = 0 it will be superuser and system will behave the same way
Eugeny

[James R. Ferguson]

Without seeing your script I have constructed a demonstration, which I think, offers you a solution to your problem.

First, amend Oracle's $HOME/.profile to read conditionally the database name variable only if the profile is associated with a terminal. The amended code would look something like:

if [ -t 0 ]
then
echo ">>> What Database? \c"
read MYDB
export MYDB
fi

To simulate your backup script, use this script and call it "whatdb.sh"

#!/usr/bin/sh
echo "I use the '${MYDB}' database'"
exit 0
#.end.

To utilize 'whatdb.sh' and collect the $MYDB variable's value from the Oracle profile's interactive query do:

# su - oracle -c 2> /dev/null './whatdb.sh'

To utilize 'whatdb.sh' in a non-interactive environment (i.e. one in which stdin isn't associated with a terminal, do:

# su - oracle -c < /dev/null 2> /dev/null 'export MYDB=USEME;./whatdb.sh'

In the case above, stdin was associated with '/dev/null' and so Oracle's profile did not query for the MYDB variable via a read. Instead, the value of the MYDB variable was exported to the environment for use with the 'whatdb.sh' script.

In both cases, the annoying "not a typewriter" messages produced by sourcing the Oracle profile when 'su -' is executed, were suppressed by redirecting stderr to /dev/null. In point of fact, the Oracle .profile could also use:

If [ -t 0 ]
Then
??????
fi

...to execute conditionally its 'stty' terminal sequences too.

Regards!

...JRF...

[Steven E. Protter]

Our backup approach is a little different.

root cron starts the backup process.

does a su -c oracle for database shutdown and backup.

Any other apps that need to be shut down are shut down the same way.

From a security standpoint this is much better.

Also, there are no problems with password prompts and other issues with t his setup.

I'd revise the approach though there are probably better ones. The best part about my approach is I know cron's environment and I'm not dealing with a user environment per say.