Changing the os dba group

We extensively use the clone.pl script provided by oracle to install software on our servers as it saves us so much time. This has all worked perfectly up until last week where we did an 11.2.0.2 clone on to a server which had not been touched for a few years. This revealed a slight anomaly in how this server was set up which meant the clone (while it all worked fine) could not be used to open the database to do the upgrade.

After the clone we got the following error when trying to connect

[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Mon Feb 24 05:02:04 2014

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

ERROR:
ORA-01031: insufficient privileges


Enter user-name:




This is the kind of thing we would expect if we tried to connect when we were not a member of the dba group. And indeed in this case oracle was not in the dba group as it turned out - it was a member of a group called 'oracle' of all things....


Hmm so how was the existing install working on the server - that had no problems.

Simple enough - the dba 'unix group' is not the group that oracle has defined as being the 'dba group'. So what does oracle think the group should be?

The answer to that is held in the file $ORACLE_HOME/rdbms/lib/config.c

Here is the file from the working install

/*  SS_DBA_GRP defines the UNIX group ID for sqldba adminstrative access.  */
/*  Refer to the Installation and User's Guide for further information.  */

/* IMPORTANT: this file needs to be in sync with
              rdbms/src/server/osds/config.c, specifically regarding the
              number of elements in the ss_dba_grp array.
 */

#define SS_DBA_GRP "oracle"
#define SS_OPER_GRP ""
#define SS_ASM_GRP ""

char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP, SS_ASM_GRP};  

Here we can see that the SS_DBA_GRP is defined as "oracle" - so anyone in the "oracle" group is a DBA.

(I like the way this file header has not been changed for about 20 years and still refers to sqldba, which was even pre svrmgrl - of course now everything is sqlplus)

So how do we fix things?

We can either:
a) update the cloned file so that it also contains oracle rather than dba
b) sort out the groups on this box for all the installs

So which did we choose? For us we chose a) as this means we dont have to involve our service provider as this is too painful. b) is the right solution in any sane persons mind though......

So to complete a) we do the following:

1) update the config.c file to replace "dba" with "oracle"
2) recompile the executable oracle so that it picks up this change in the .c file

To recompile for step 2) we can just use the relink script from $ORACLE_HOME/bin (this is easier than trying to work out what the make command should be). So in this case we just run

relink all

This will recompile all of the executables for oracle on the box (i'm sure there was just an option to say 'relink oracle' but it didn't seem to like this - at least not in 11.2.0.2)

Once this is complete then the software will work fine and we get no insufficient privileges errors.

One thing to make sure of though is that you re-run root.sh after the relink step as any executables with a setuid bit of root will lose them and this will need to be reset by this script.