Re: connect userid/password script

Am I missing something? Why not create the Oracle user account for running
these sqlplus scripts as "identified externally". The scripts would have
to be run under the corresponding OS account but could be invoked simply as "sqlplus /". The only disadvantage I see is if you need to run them over SQL*net, which is possible by enabling REMOTE_OS_AUTHENT, but not recommended.

>
> The last solution I have is to do a
>
> $ mkdir a_realy_long_directory_to_hide_the_oracle_password_from_the_ps_command
> $ cd a_realy_long_directory_to_hide_the_oracle_password_from_the_ps_command
> $ ln -s $ORACLE_HOME/bin/sqlplus sqlplus
>
> alias sql='$HOME/a_realy_long_directory_to_hide_the_oracle_pa\
> ssword_from_the_ps_command/sqlplus myid/pw'
>
> the realy long directory will have to be adjusted for the the operating system.
>
> I have tried hiding the password in an environment variable, but ps on some
> systems will expand it for you (cannot remember if it was HPUX or SUN OS).
>
> Marek Wiechula and Sheila Plant (sparemgw_at_batelco.com.bh) wrote:
> : Daryl Peh Boon Chai wrote:
> : >
> : > You can store the password in a password file.
> : > Then in your sqlplus command, redirect in the password file, eg :
> : > sqlplus userid _at_sqlfilename < passwordfile
> : > This way, the password file can be kept in a safe place where only
> : > the CRON id can access. It is safer than keeping in the sqlscript.
> : >
> : > Daryl
 

> : You're right. It is safer to keep the password separately as you suggest. And
> : actually I do store the password in a separate file, readable only by the oracle
> : unix user. I don't generally use the file directly as you've shown, I prefer to
> : extract the password into a unix variable which I later embed in the temporary sql
> : script.
 

> : While we're on the subject, I also make sure that the temporary sql file is also
> : unreadable for non-oracle users and I use a trap command to get rid of the file
> : when I'm done with it.
 

> : I also capture the output of the sqlplus run and analyze it for ORA- type error
> : messages. This allows me to distinguish between the case in which the data simply
> : was not found and the case in which (for example) the database was simply not up
> : and running.
 

> : Marek
>
> --
> This posting represents the personal opinions of the author. It is not the
> official opinion or policy of the author's employer. Warranty expired when you
> opened this article and I will not be responsible for its contents or use.
 

-- 
-----------------------------------------------------
Andre Yoshida
Contract employee for HP Clinical Information Systems
Email: yoshida_at_an.hp.com	Vmail: (508) 659-4693