Re: Internal database password file
Date: 17 Feb 1995 14:21:24 GMT
Message-ID: <3i2bd4$fh6_at_kronos.fmi.fi>
In article <3h8a8o$r66_at_ra.nrl.navy.mil>, Steve Randolph <steve_randolph_at_alx.sticomet.com> says:
>
>
>Assembled wisdom,
>
>I have a question about the internal passwords for dba and operator.  We're 
>running V7.1.4 on OSF/1 V3.  I didn't elect to define passwords for the 
>internal user accounts during install.  I want to use remote database 
>administration utilities that require a connect internal and therefore need 
>to enable these passwords now.  According to the UNIX Administrator's 
>Reference Guide, a utility exists (orapwd) to do just that.  
>
>The problem I have is that the orapwd utility doesn't work on OSF/1 _exactly_ 
>as it's documented in the book (surprise, surprise).  It requires a password 
>file name as an argument.  The database then looks to that file during 
>startup.  You can't specify just _any_ filename, the database gives me a 
>"Can't open file..." error message as if it's expecting a particular one.  
>Only, Oracle tech support doesn't know what the filename should be. They had 
>to log a bug with the developers to get an answer.  I'm still waiting... 
>
>Now, I figure I ought to be able to find someone out there who has 
>implemented internal passwords on an OSF/1 (maybe it can be any UNIX) 
>installation and can look in their $ORACLE_HOME/dbs for a file like orapsswd. 
>If that's you, please do that for me and post or email me the name of the 
>file that you find.  Much obliged.
Steve,
I did the same thing with V7.1.3 on OSF/1 V3 some time ago. I checked all the manuals about it and found that the UNIX Administrator's Reference Guide and the DEC Alpha AXP OSF/1 Installation and Configuration Guide was telling a different tale than the Oracle7 Server Documentation Addendum Rel. 7.1. I asked about this from local Oracle branch and they told that the Addendum was correct and UNIX guides talk about an older and obscure version of orapwd.
I used the Addendum method and I can now CONNECT AS SYSDBA with a username other than system and do same things as CONNECT INTERNAL (I think, I have not tested everything but things like shutdown work ok). I have not tried it remote tought but the Addendum said it should work too (and pigs should fly, too :-).
Try it and please tell if remote access works too.
Mikko Lahti
Finnish Meteorological Institute
Helsinki
Finland
Europe
e-mail Mikko.Lahti_at_fmi.fi
Received on Fri Feb 17 1995 - 15:21:24 CET
