Re: Internal database password file

From: Mikko Lahti <Mikko.Lahti_at_fmi.fi>
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

Original text of this message