EUS and asmcmd

I have been working a lot with EUS lately at a big customer. My personal account is able to login to databases (EUS) and also on to OEL (OAS4OS). This combined with some chown/chmod commands on OEL enables me to do my job with my personal account.

Since this customers also uses ASM, I figured I would like to use my personal account for asmcmd too. First I tested the process with a local account, baby steps usually works best for me. I created an account jhl

# useradd -g asmadmin -G dba jhl

Next i su’d to jhl and tested the procedure:

$ id
uid=10238(jhl) gid=4007(asmadmin) groups=4006(dba),4007(asmadmin)

$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm_200 is /u01/app/oracle

$ asmcmd
ASMCMD> ls

This looks promising, all needed to be done next was repeating the steps only now with an account from the OID. First I had to add the group to the OID, here’s the ldif I used:

cn=asmadmin,cn=groups,dc=some_company,dc=nl
uniquemember=cn=landlustjh,cn=users,dc=some_company,dc=nl
owner=cn=orcladmin,cn=users, dc=some_company,dc=nl
objectclass=top
objectclass=groupOfUniqueNames
objectclass=orclGroup
objectclass=posixgroup
cn=asmdba
orclisvisible=true
displayname=asmadmin
description=asmadmin
gidnumber=1007

As you can see in the ldif, I added my personal account to the asmadmin group. After adding the group to the OID I performed a quick check to see if all went according to plan:

$ id
uid=10217(LandlustJH) gid=1006(dba) groups=1006(dba),1007(asmadmin),1010(remotelogin),1011(oraclemembers),1012(rootmembers)

Now te login:

$ asmcmd
ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode
ASMCMD>

Aiks? Since I’m not that stupid, I started tracing asmcmd:

$ export DBI_TRACE=1

$ asmcmd
    -> DBI->connect(dbi:Oracle:, , ****, HASH(0xd547e0))
    -> DBI->install_driver(Oracle) for linux perl=5.008003 pid=6683 ruid=10217 euid=10217
       install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_202//perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
    <- install_driver= DBI::dr=HASH(0x7c28c0)
       ERROR: 1034 ‘ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin)’
    <- DESTROY= undef at DBI.pm line 591
       DBI connect(”,”,…) failed: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin)
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode

The tracing and some MOS-ing (MOS actually works for me!) learned me that I forgot to set my environment. No rocket science to far. Let’s retry:

$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.1.0/asm_200 is /u01/app/oracle

$ asmcmd
    -> DBI->connect(dbi:Oracle:, , ****, HASH(0xd53960))
    -> DBI->install_driver(Oracle) for linux perl=5.008003 pid=3186 ruid=10217 euid=10217
       install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
    <- install_driver= DBI::dr=HASH(0x7c1e70)
       ERROR: 12547 ‘ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)’
    <- DESTROY= undef at DBI.pm line 591
       DBI connect(”,”,…) failed: ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)
ORA-12547: TNS:lost contact (DBD ERROR: OCIServerAttach)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode

ORA-12547 was NOT wat I was expecting at all. Even more MOS-ing later I discovered the privileges on the oracle binary were not set correctly. This could be fixed easily

oracle$ chmod 6751 $ORACLE_HOME/bin/oracle

and then yet another try (now with the proper environment):

$ asmcmd
    -> DBI->connect(dbi:Oracle:, , ****, HASH(0xd53990))
    -> DBI->install_driver(Oracle) for linux perl=5.008003 pid=31109 ruid=10217 euid=10217
       install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
    <- install_driver= DBI::dr=HASH(0x7c1ec0)
       ERROR: 1031 ‘ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)’
    <- DESTROY= undef at DBI.pm line 591
       DBI connect(”,”,…) failed: ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode

ORA-01031? Now how about that? Usually that’s caused by password file trouble:

SQL> select * from v$pwfile_users;

USERNAME         SYSDBA          SYSOPER         SYSASM
—————- ————— ————— —————
SYS              TRUE            TRUE            FALSE
SQL> grant sysasm to sys;

Grant succeeded.
SQL> select * from v$pwfile_users;

USERNAME        SYSDBA          SYSOPER         SYSASM
————— ————— ————— —————
SYS             TRUE            TRUE            TRUE

Now lets’ try again:

$ asmcmd
    -> DBI->connect(dbi:Oracle:, , ****, HASH(0xd539b0))
    -> DBI->install_driver(Oracle) for linux perl=5.008003 pid=4315 ruid=10217 euid=10217
       install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
    <- install_driver= DBI::dr=HASH(0x7c23c0)
       ERROR: 1031 ‘ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)’
    <- DESTROY= undef at DBI.pm line 591
       DBI connect(”,”,…) failed: ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ORA-01031: insufficient privileges (DBD ERROR: OCISessionBegin)
ASMCMD-08103: failed to connect to ASM; ASMCMD running in non-connected mode

 Still no jackpot, but guess what:

$ asmcmd -a sysdba
    -> DBI->connect(dbi:Oracle:, , ****, HASH(0xd539b0))
    -> DBI->install_driver(Oracle) for linux perl=5.008003 pid=4351 ruid=10217 euid=10217
       install_driver: DBD::Oracle version 1.15 loaded from /u01/app/oracle/product/11.1.0/asm_200/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Oracle.pm
    <- install_driver= DBI::dr=HASH(0x7c23c0)
1   <- prepare(‘
                SELECT SYS_CONTEXT(‘userenv’,’session_user’) FROM DUAL
            ‘ undef)= DBI::st=HASH(0x100a6e0) at Oracle.pm line 295
    <- selectrow_array(‘
                SELECT SYS_CONTEXT(‘userenv’,’session_user’) FROM DUAL
            ‘)= ‘SYS’ at Oracle.pm line 295
$h->{‘ora_session_mode’}=2 ignored for invalid driver-specific attribute
    <- connect= DBI::db=HASH(0xfa15d0)
1   <- FETCH(‘NAME’)= [ ‘VALUE’ ] at asmcmdshare.pm line 2324
1   <- fetch= [ ‘asm’ ] row1 at asmcmdshare.pm line 2324
1   <- FETCH(‘NAME’)= [ ‘VERSION’ ] at asmcmdshare.pm line 2324
1   <- fetch= [ ‘11.1.0.7.0’ ] row1 at asmcmdshare.pm line 2324
ASMCMD>

hey joe, what do you know? I only found this behaviour once, when the osdba group was not called dba. I remember that I had to check some spec file and recompile ioracle:

cat $ORACLE_HOME/rdbms/lib/config.c
#define SS_DBA_GRP “dba”
#define SS_OPER_GRP “dba”
#define SS_ASM_GRP “asmadmin”

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

Sadly enough in this case the default group name is asmadmin, so a recompile will not help me out. The only thing left is to trace the sqlnet session from asmcmd to the database back to OID, but somehow I have a feeling this will not help me out. Anyway, I’m done for the day. Maybe I can find a solution tomorrow. Any help is appreciated.