Re: starting Oracle on Linux

Some of this information is sorely out of date and should be revised.

For example, CONNECT INTERNAL has been de-supported in 9i.

Please avoid setting REMOTE_OS_AUTHENT to FALSE unless you are sure that your environment is secure. Setting it to TRUE is a very dangerous thing to do.

                                    Rick

jaf12466_at_yahoo.com (D_Kroma) writes:

> A Checklist for CONNECT INTERNAL PASSWORD Issues
> ================================================
>
>
> Introduction:
> =============
>
> This bulletin lists the documented causes of getting prompted for a
> password
> when trying to CONNECT INTERNAL through "sqldba" or "svrmgrl". In
> other words,
> if you get prompted for a password when trying to CONNECT INTERNAL,
> use the
> following to troubleshoot the problem. This article also contains
> information
> on some additional errors that you may receive while connecting
> internal.
>
>
> A. SQLNET.ORA Checks:
> =====================
>
> 1. The "sqlnet.ora" can be found in the following locations (listed by
> search
> order):
>
> $TNS_ADMIN/sqlnet.ora
> $HOME/sqlnet.ora
> $ORACLE_HOME/network/admin/sqlnet.ora
>
> Depending upon your operating system, it may also be located in:
>
> /var/opt/oracle/sqlnet.ora
> /etc/sqlnet.ora
>
>
>
> A corrupted "sqlnet.ora" file, or one with security options set,
> will cause
> a 'connect internal' request to prompt for a password. To determine
> if this
> is the problem, locate the "sqlnet.ora" that is being used. The one
> being
> used will be the first one found according to the search order
> listed above.
> Next, move the file so that it will not be found by this search:
>
> % mv sqlnet.ora sqlnet.ora_save
>
> Try to connect internal again. If it still fails, search for other
> "sqlnet.ora" files according to the search order listed above and
> repeat
> using the move command until you are sure there are no other
> "sqlnet.ora"
> files being used. If this does not resolve the issue, use the move
> command
> to put all the "sqlnet.ora" files back where they were before you
> made the
> change:
>
> % mv sqlnet.ora_save sqlnet.ora
>
> If moving the "sqlnet.ora" resolves the issue, then verify the
> contents
> of the file:
>
> a) SQLNET.AUTHENTICATION_SERVICES
>
> If you arenot using database links, comment this line out or
> try
> setting it to:
>
> SQLNET.AUTHENTICATION_SERVICES = (BEQ,NONE)
>
> b) SQLNET.CRYPTO_SEED
>
> This should not be set in a "sqlnet.ora" file on UNIX. If it
> is,
> comment the line out. (This setting is added to the
> "sqlnet.ora" if
> it is built by one of Oracle's network cofiguration products
> shipped
> with client products.)
>
> c) AUTOMATIC_IPC
>
> If this is set to "ON" it can force a "TWO_TASK" connection.
> Try setting this to "OFF":
>
> AUTOMATIC_IPC = OFF
>
> 2. Set the permissions correctly in the "TNS_ADMIN" files. The
> environment
> variable TNS_ADMIN defines the directory where the "sqlnet.ora",
> "tnsnames.ora", and "listener.ora" files reside. These files must
> contain
> the correct permissions, which are set when "root.sh" runs during
> installation.
>
> As root, run "root.sh" or edit the permissions on the "sqlnet.ora",
> "tnsnames.ora", and "listener.ora" files by hand as follows:
>
> $ cd $TNS_ADMIN
> $ chmod 644 sqlnet.ora tnsnames.ora listener.ora
> $ ls -l sqlnet.ora tnsnames.ora listener.ora
>
> -Rw-R--R-- 1 oracle dba 1628 Jul 12 15:25 listener.ora
> -Rw-R--R-- 1 oracle dba 586 Jun 1 12:07 sqlnet.ora
> -Rw-R--R-- 1 oracle dba 82274 Jul 12 15:23 tnsnames.ora
>
>
> B. Software and Operating System Issues:
> ========================================
>
> 1. Be sure $ORACLE_HOME is set to the correct directory and does not
> have any
> typing mistakes:
>
> % cd $ORACLE_HOME
> % pwd
>
> If this returns a location other than your "ORACLE_HOME" or is
> invalid,
> you will need to reset the value of this environment variable:
>
> sh or ksh:
> ----------
>
> % ORACLE_HOME=<path_to_ORACLE_HOME>
> % export ORACLE_HOME
>
> Example:
>
> % ORACLE_HOME=/u01/app/oracle/product/7.3.3
> % export ORACLE_HOME
>
>
> csh:
> ----
>
> % setenv ORACLE_HOME <path_to_ORACLE_HOME>
>
> Example:
>
> % setenv ORACLE_HOME /u01/app/oracle/product/7.3.3
>
>
> If your "ORACLE_HOME" contains a link or the instance was started
> with
> the "ORACLE_HOME" set to another value, the instance may try to
> start
> using the memory location that another instance is using. An
> example of
> this might be:
>
> You have "ORACLE_HOME" set to "/u01/app/oracle/product/7.3.3" and
> start
> the instance. Then you do something like:
>
> % ln -s /u01/app/oracle/product/7.3.3 /u01/app/oracle/7.3.3
> % setenv ORACLE_HOME /u01/app/oracle/7.3.3
> % svrmgrl
>
> SVRMGR> connect internal
>
> If this prompts for a password then most likely the combination of
> your
> "ORACLE_HOME" and "ORACLE_SID" hash to the same shared memory
> address of
> another running instance. Otherwise you may be able to connect
> internal
> but you will receive an ORA-01034 "Oracle not available" error.
>
> In most cases using a link as part of your "ORACLE_HOME" is fine
> as long
> as you are consistent. Oracle recommends that links not be used as
> part
> of the "ORACLE_HOME", but their use is supported.
>
> 2. Check that $ORACLE_SID is set to the correct SID, (including
> capitalization),
> and does not have any typos:
>
> % echo $ORACLE_SID
>
> Refer to article [NOTE:1048876.6]
> <ml2_documents.showDocument?p_id=1048876.6&p_database_id=NOT> for more
> information.
>
> 3. Ensure $TWO_TASK is not set. To check if "TWO_TASK" is set, do the
> following:
>
> sh, ksh or on HP/UX only csh:
> -----------------------------
>
> env |grep -i two
>
>
> csh:
> ----
>
> setenv |grep -i two
>
>
> If any lines are returned such as:
>
> TWO_TASK=
>
> or
>
> TWO_TASK=PROD
>
> You will need to unset the environment variable "TWO_TASK":
>
> sh or ksh:
> ----------
>
> unset TWO_TASK
>
>
> csh:
> ----
>
> unsetenv TWO_TASK
>
>
> If you are running Oracle release 8.0.4, and upon starting
> "svrmgrl" you
> receive an ORA-06401 "NETCMN: invalid driver designator" error, you
> should
> also unset two_task. The login connect string may be getting its
> value
> from the TWO_TASK environment variable if this is set for the user.
>
> 4. Check the permissions on the Oracle executable:
>
> % cd $ORACLE_HOME/bin
> % ls -l oracle ('ls -n oracle' should work as
> well)
>
> The permissions should be rwsr-s--x, or 6751.
> If the permissions are incorrect, do the following as the "oracle"
> software owner:
>
> % chmod 6751 oracle
>
> If you receive an ORA-03113 "end-of-file on communication" error
> followed
> by a prompt for a password, then you may also need to check the
> ownership and
> permissions on the dump directories. These directories must belong
> to Oracle,
> group dba, (or the appropriates names for your installation). This
> error may occur
> while creating a database.
>
> Permissions should be: 755 (drwxr-xr-x)
>
> Also, the alert.log must not be greater than 2 Gigabytes in size.
>
> When you start up "nomount" an Oracle pseudo process will try to
> write the
> "alert.log" file in "udump". When Oracle cannot do this (either
> because of
> permissions or because of the "alert.log" being greater than 2
> Gigabytes in
> size), it will issue the ORA-03113 error.
>
> 5. Make sure the operating system user issuing the CONNECT INTERNAL
> belongs
> to the "osdba" group as defined in the
> "$ORACLE_HOME/rdbms/lib/config.s"
> or "$ORACLE_HOME/rdbms/lib/config.c". Typically this is set to
> "dba". To
> verify the operating system groups the user belongs to, do the
> following:
>
> % id
> uid=1030(oracle) gid=1030(dba)
>
> The "gid" here is "dba" so the "config.s" or "config.c" may contain
> an
> entry such as:
>
> /* 0x0008 15 */ .ascii "dba\0"
>
> If these do not match you will either need to add the operating
> system user
> to the group as it is seen in the "config" file, or modify the
> "config" file
> and relink the "oracle" binary. Refer to entry [NOTE:50507.1]
> <ml2_documents.showDocument?p_id=50507.1&p_database_id=NOT> section
> 3 for more details.
>
> 6. Verify that the file system is not mounted no set uid:
>
> % mount
> /u07 on /dev/md/dsk/d7 nosuid/read/write
>
> If the filesytem is mounted "nosuid", as seen in this example, you
> will
> need to unmount the filesystem and mount it without the "nosuid"
> option.
> Consult your operating system documentation or your operating
> system vendor
> for instruction on modifying mount options.
>
> 7. Be sure you are not logged in as the "root" user and that the
> environment
> variables "USER", "USERNAME", and "LOGNAME" are not set to "root".
> The
> "root" user is a special case and cannot connect to Oracle as the
> "internal"
> user unless the effective group is changed to the "osdba" group,
> which is
> typically "dba". To do this you would either have to modify the
> "/etc/password" file (not recommended) or use the "newgrp" command:
>
> # newgrp dba
>
> "newgrp" will always open a new shell, so you can not issue
> "newgrp" from
> within a shell script. Keep this in mind if you plan on executing
> scripts
> as the "root" user.
>
> 8. Verify that the "osdba" group is only listed once in the
> "/etc/group" file:
>
> % grep dba /etc/group
> dba::1010:
> dba::1100:
>
> If more than one line starting with the "osdba" group is returned
> you will
> need to remove the ones that are not correct. It is not possible to
> have
> more than one group use a group name.
>
> 9. Please read the following warning before you attempt to use the
> information
> in this step:
>
> ******************************************************************
> *
> *
> * WARNING: If you remove segments that belong to a running
> *
> * instance you will crash the instance, and this may
> *
> * cause database corruption.
> *
> *
> *
> * Please call Oracle Support Services for assistance
> *
> * if you have any doubts about removing shared memory
> *
> * segments.
> *
> *
> *
> ******************************************************************
>
> If an instance crashed or was killed off using "kill" there may be
> shared
> memory segments hanging around that belong to the down instance. If
> there
> are no other instances running on the machine you can issue:
>
> % ipcs -b
>
> T ID KEY MODE OWNER GROUP
> SEGSZ
> Shared Memory:
> m 0 0x50000ffe --rw-r--r-- root root
> 68
> m 1601 0x0eedcdb8 --rw-r----- oracle dba
> 4530176
>
>
> In this case the "ID" of "1601" is owned by "oracle" and if there
> are no
> other instances running in most cases this can safely be removed:
>
> % ipcrm -m 1601
>
> If your SGA is split into multiple segments you will have to remove
> all
> segments associated with the instance. If there are other instances
> running, and you are not sure which memory segments belong to the
> failed
> instance, you can do the following:
>
> a) Shut down all the instances on the machine and remove
> whatever
> shared memory still exists that is owned by the software
> owner.
>
> b) Reboot the machine.
>
> c) If your Oracle software is release 7.3.3 or newer, you can
> connect
> into each instance that is up and identify the shared memory
> owned
> by that instance:
>
> % svrmgrl
> SVRMGR> connect internal
> SVRMGR> oradebug ipc
>
>
> In Oracle8:
> -----------
>
> Area #0 `Fixed Size', containing Subareas 0-0
> Total size 000000000000b8c0, Minimum Subarea size
> 00000000
> Subarea Shmid Size Stable Addr
> 0 7205 000000000000c000 80000000
>
>
> In Oracle7:
> -----------
>
> -------------- Shared memory --------------
> Seg Id Address Size
> 2016 80000000 4308992
> Total: # of segments = 1, size = 4308992
>
>
> Note the "Shmid" for Oracle8 and "Seg Id" for Oracle7 for
> each
> running instance. By process of elimination find the
> segments that
> do not belong to an instance and remove them.
>
> 10. If you are prompted for a password and then receive error
> ORA-09925 "unable
> to create audit trail file" or error ORA-09817 "write to audit
> file failed",
> along with "SVR4 Error: 28: No space left on device", do the
> following:
>
> Check your "pfile". It is typically in the "$ORACLE_HOME/dbs"
> directory
> and will be named "init<your_sid>.ora, where "<your_sid>" is the
> value
> of "ORACLE_SID" in your environment. If the "init<your_sid>.ora"
> file has
> the "ifile" parameter set, you will also have to check the
> included file
> as well. You are looking for the parameter "audit_file_dest".
>
> If "audit_file_dest" is set, change to that directory; otherwise
> change to
> the "$ORACLE_HOME/rdbms/audit" directory, as this is the default
> location
> for audit files. If the directory does not exist, create it.
> Ensure that
> you have enough space to create the audit file. The audit file is
> generally
> 600 bytes in size. If it does exist, verify you can write to the
> directory:
>
> % touch afile
>
> If it could not create the called "afile", you need to change the
> permissions on your audit directory:
>
> % chmod 751
>
> 11. If connect internal prompts you for a password and then you
> receive an
> ORA-12705 "invalid or unknown NLS parameter value specified"
> error, you
> need to verify the settings for "ORA_NLS", "ORA_NLS32",
> "ORA_NLS33" or
> "NLS_LANG". You will need to consult your Installation and
> Configuration
> Guide for the proper settings for these environment variables.
>
> 12. If you have installed Oracle software and are trying to connect
> with
> Server Manager to create or start the database, and receive a
> TNS-12571
> "packet writer failure" error, please refer to [NOTE:1064635.6]
> <ml2_documents.showDocument?p_id=1064635.6&p_database_id=NOT>.
>
>
> 13. If in SVRMGRL (Server Manager line mode), you are running the
> "startup.sql"
> script and receive the following error:
>
> ld:so.1: oracle_home/bin/svrmgrl fatal relocation error
> symbol not found kgffiop
>
> RDBMS v7.3.2 is installed. RDBMS v8.0.4 is a separate
> "oracle_home", and you
> are attempting to have it coexist. This is due to the wrong
> version of the client shared
> library "libclntsh.so.1" being used at runtime. Verify
> environment variable settings.
>
> You need to ensure that "ORACLE_HOME" and "LD_LIBRARY_PATH" are
> set correctly.
>
> For C-shell, type:
>
> % setenv LD_LIBRARY_PATH $ORACLE_HOME/lib
> % setenv ORACLE_HOME /u01/app/oracle/product/8.0.4
>
> For Bourne or Korn shell, type:
>
> $ LD_LIBRARY_PATH=$ORACLE_HOME/lib
> $ export LD_LIBRARY_PATH
>
>
> $ ORACLE_HOME=/u01/app/oracle/product/8.0.4
> $ export ORACLE_HOME
>
> 14. Ensure that the disk the instance resides on has not reached 100%
> capacity.
>
> % df -k
>
> If it has reached 100% capacity, this may be the cause of 'connect
> internal'
> prompting for a password. Additional disk space will need to be
> made
> available before 'connect internal' will work.
>
> For additional information refer to [NOTE:97849.1]
> <ml2_documents.showDocument?p_id=97849.1&p_database_id=NOT>.
>
> 15. Delete process.dat and regid.dat files in
> $ORACLE_HOME/otrace/admin directory.
> Oracle Trace is enabled by default on 7.3.2 and 7.3.3 (depends on
> platform)
> This can caused high disk space usage by these files and cause a
> number of
> apparently mysterious side effects. See note:45482.1 for more
> details.
>
> C. Operating System Specific checks:
> ====================================
>
> 1. On OpenVMS, check that the privileges have been granted at the
> Operating
> System level:
>
> $ SET DEFAULT SYS$SYSTEM:
> $ RUN AUTHORIZE
>
> If the list returned by AUTHORIZE does not contain ORA_<SID>_DBA,
> or
> ORA_DBA, then you do not have the correct OS privileges to issue a
> connect
> internal. If ORA_<SID>_DBA was added AFTER ORA_DBA, then ORA_DBA
> needs to
> be removed and granted again to be updated. Please refer to
> [NOTE:1010852.6] <ml2_documents.showDocument?p_id=1010852.6&p_database_id=NOT>
> for more details.
>
> 2. On Windows NT, check if DBA_AUTHORIZATION is set to BYPASS in the
> registry.
> Refer to [NOTE:1027664.6]
> <ml2_documents.showDocument?p_id=1027664.6&p_database_id=NOT> for more
> details.
>
> 3. On Windows NT, if you are able to connect internally but then
> startup fails
> for some reason, successive connect internal attempts might prompt
> for a
> password. You may also receive errors such as:
>
> ORA-12705: invalid or unknown NLS parameter value specified
> ORA-01012: not logged on
> LCC-00161: Oracle error (possible syntax error)
> ORA-01031: insufficient privileges
>
> Refer to entry [NOTE:1027964.6]
> <ml2_documents.showDocument?p_id=1027964.6&p_database_id=NOT> for
> suggestions on how to resolve this
> problem.
>
> 4. If you are using Multi-Threaded Server (MTS), make sure you are
> using a
> dedicated server connection. A dedicated server connection is
> required to
> start up or shutdown the database. Unless the database alias in the
> "TNSNAMES.ORA" file includes a parameter to make a dedicated server
> connection, it will make a shared connection to a dispatcher. See
> [NOTE:1058680.6] <ml2_documents.showDocument?p_id=1058680.6&p_database_id=NOT>
> for more details.
>
> 5. On Solaris, if the file "/etc/.name_service_door" has incorrect
> permissions,
> Oracle cannot read the file. You will receive a message that "The
> Oracle
> user cannot access "/etc/.name_service_door" (permission denied).
> This file
> is a flavor of IPC specific to Solaris which Oracle software is
> using. This
> can also cause connect internal problems. See entry
> [NOTE:1066589.6] <ml2_documents.showDocument?p_id=1066589.6&p_database_id=NOT>.
>
> 6. You are on Digital Unix, running SVRMGRL (Server Manager line
> mode),
> and you recieve an ORA-12547 "TNS:lost contact" error and a
> password
> prompt.
>
> This problem occurs when using Parallel Server and the True Cluster
> software together. If Parallel Server is not linked in, svrmgrl
> works as
> expected.
>
> Oracle V8.0.5 requires an Operating System patch which previous
> versions of
> Oracle did not require. The above patch allows svrmgrl to
> communicate with the
> TCR software.
>
> You can determine if the patch is applied by running:
> % nm /usr/ccs/lib/libssn.a | grep adjust
>
> If this returns nothing, then you need to:
>
> 1. Obtain the patch for TCR 1.5 from Digital. This patch is for
> the
> MC SCN and adds the symbol "adjustSequenceNumber" to the
> library
> /usr/ccs/lib/libssn.a.
>
> 2. Apply the patch.
>
> 3. Relink Oracle
>
> 7. You are on version 6.2 of the Silicon Graphics UNIX (IRIX)
> operating system
> and you have recently installed RDBMS release 8.0.3. If you are
> logged on
> as "oracle/dba" and an attempt to log in to Server Manager using
> "connect/internal" prompts you for a password, you should refer to
> entry
> [NOTE:1040607.6] <ml2_documents.showDocument?p_id=1040607.6&p_database_id=NOT>.
>
>
> D. Additional Information:
> ==========================
>
> 1. In the "Oracle7 Administrator's Reference for UNIX", there is a
> note that
> states:
>
> If REMOTE_OS_AUTHENT is set to true, users who are members of
> the
> dba group on the remote machine are able to connect as INTERNAL
> without a password.
>
> However, if you are connecting remotely, that is connecting via
> anything
> except the bequeath adapter, you will be prompted for a password
> regardless
> of the value of "REMOTE_OS_AUTHENT".

-- 
                                Rick Wessman
                                Security Assurance Group
                                Oracle Corporation
                                Rick.Wessman_at_oracle.com

     The opinions expressed above are mine and do not necessarily reflect
                         those of Oracle Corporation.