Re: Extracting a password from a table.

Henrik,

We had a similar problem on a Unix box... We needed the password, but did not want to hardcode the user/password in all the scripts...

This is what we did to solve the problem.

1. The /oracle account was tightly controlled, so the DBA created password files with shell SET commands. The files were hidden, and given group read/execute rights to our project, Group X we'll say. The contents of the files were like so: file: .OraPass_MyProject1, .OraPass_MyProject2, etc. SET PROJUSER=xxxxx SET PROJPASS=xxxxx SET PROJUSERPASS=xxxx/xxxx (My Unix might be wrong: whatever commands set the variable in the environment...)
2. Now, each script which needs this password is contained in another tightly controlled account, such as loaduser, or projload, etc... This user belongs to the group X The first step of the script is to execute the password file: on Sequent: . .OraPass_MyProject1 Now the passwords are "alive" for the life of the script, no one can see them, and they have not been typed on the command line, and so won't be in any history file.
3. The main script passes these as parameters to any sub-script which it might call.
4. SQL calls use parameters like so... sqlldr {$PROJUSERPASS}@$MYSID etc....... Or, if passed as parms, then either: sqlplus {$1}..... sqlplus {$1}/{$2}.....etc. or: TEMPUSERPASS={$1} sqlplus {$TEMPUSERPASS}....etc.

Worked fine for our application....
While there is a risk that the password is stored "somewhere", we felt the risk was small, since we tightly controlled those accounts and groups. Benefit was that script management was easy because a password change is handled in ONE spot (we had upwards of 20 scripts). Second bonus, by standardizing naming of password files, the same script text could be used to load _TEST, _PROD, _TRAIN, _DEV simply by controlling a passed parameter to the name of the password file. Downside, troubleshooting was a little harder, because one would have to create a password file or copy a script and hardcode it to test it...all in all, very livable, we thought.

(Thanks goes to our DBA Aramazd Davidian for this idea...)
Robert Proffitt
Beckman Coulter
(formerly Boeing)

RTProffitt "AT" beckman "DOT" com (change to symbols)

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Nov 15 1999 - 10:35:32 CST