Skip to Main Content

Infrastructure Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Automount and LDAP : attribute mapping ignored

807557Jul 1 2009
Hello,

We are running several Solaris servers configured on a very old Sun Directory Server. This server is about to die, that's why we're preparing a migration to a new OpenLDAP server.

The new server also deserve Linux systems. This mean we already have an automount objectClass, and thus used the old nis Schema for the Solaris systems.

As explained in the Solaris 10 documentation, we initialized ldapclient with the AttributeMap and ObjectClassMap parameters.

It works fine with ldaplist, but automount seems to ignore the mapping.

Here are a few config files and command outputs :
*LDAP Client configuration*

root@testldapc01 # ldapclient list
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=nisRead,ou=Special Users,ou=nis,o=hefr
NS_LDAP_BINDPASSWD= xxxxxxxxxxx
NS_LDAP_SERVERS= xxxxxxxxx.hefr.ch
NS_LDAP_SEARCH_BASEDN= ou=nis,o=hefr
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= FALSE
NS_LDAP_SEARCH_SCOPE= sub
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_CACHETTL= 43200
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=People,ou=nis,o=hefr?sub
NS_LDAP_SERVICE_SEARCH_DESC= group: ou=Groups,ou=nis,o=hefr?sub
NS_LDAP_SERVICE_SEARCH_DESC= auto.master: nisMapName=auto_master,ou=solaris,ou=automount,ou=nis,o=hefr?sub
NS_LDAP_SERVICE_SEARCH_DESC= auto.home: nisMapName=auto_home,ou=solaris,ou=automount,ou=nis,o=hefr?sub
NS_LDAP_SERVICE_SEARCH_DESC= auto_home: nisMapName=auto_home,ou=solaris,ou=automount,ou=nis,o=hefr?sub
NS_LDAP_SERVICE_SEARCH_DESC= auto_master: nisMapName=auto_master,ou=solaris,ou=automount,ou=nis,o=hefr?sub
NS_LDAP_SERVICE_SEARCH_DESC= shadow:ou=People,ou=nis,o=hefr?sub
NS_LDAP_BIND_TIME= 10
NS_LDAP_ATTRIBUTEMAP= automount: automountInformation=nisMapEntry
NS_LDAP_ATTRIBUTEMAP= automount: automountKey=cn
NS_LDAP_ATTRIBUTEMAP= automount: automountMapName=nisMapName
NS_LDAP_OBJECTCLASSMAP= automount: automount=nisObject
NS_LDAP_OBJECTCLASSMAP= automount: automountMap=nisMap

*LDAP tests for automount informations*

root@testldapc01 # ldaplist -l auto.master
dn: nisMapName=auto_master,ou=solaris,ou=automount,ou=nis,o=hefr
        nisMapName: auto_master
        objectClass: nisMap

dn: cn=/home,nisMapName=auto_master,ou=solaris,ou=automount,ou=nis,o=hefr
        objectClass: nisObject
        objectClass: top
        cn: /home
        nisMapEntry: auto_home -nosuid,nobrowse
        nisMapName: auto_master
root@testldapc01 # ldaplist -l auto.home beytriso
dn: cn=beytriso,nisMapName=auto_home,ou=solaris,ou=automount,ou=nis,o=hefr
        nisMapName: auto_home
        cn: beytriso
        objectClass: top
        objectClass: nisObject
        nisMapEntry: 160.98.2.27:/vol/vol_pers_sofr/qt_home_sofr/&

*/etc/nsswitch.conf for automount*

root@testldapc01 # grep automount /etc/nsswitch.conf
automount:  ldap

*Packet capture when automountd starts :*

Frame 20 (183 bytes on wire, 183 bytes captured)
Lightweight-Directory-Access-Protocol
    LDAPMessage searchRequest(2) " nisMapName=auto_master,ou=solaris,ou=automount,ou=nis,o=hefr" wholeSubtree
        messageID: 2
        protocolOp: searchRequest (3)
            searchRequest
                baseObject:  nisMapName=auto_master,ou=solaris,ou=automount,ou=nis,o=hefr
                scope: wholeSubtree (2)
                derefAliases: derefAlways (3)
                sizeLimit: 0
                timeLimit: 30
                typesOnly: False
                Filter: (&(objectClass=automount)(automountKey=*))
                attributes: 0 items
        [Response In: 21]

Frame 21 (68 bytes on wire, 68 bytes captured)
Lightweight-Directory-Access-Protocol
    LDAPMessage searchResDone(2) success [0 results]
        messageID: 2
        protocolOp: searchResDone (5)
            searchResDone
                resultCode: success (0)
                matchedDN: 
                errorMessage: 
        [Response To: 20]
        [Time: 0.002397000 seconds]
As you can see in the capture, it sends a filter containing the objectClass=automount and the attribute automountKey (&(objectClass=automount)(automountKey=*)).
*The current version of the autofs package *
root@testldapc01 # pkginfo -l SUNWatfsr
   PKGINST:  SUNWatfsr
      NAME:  AutoFS, (Root)
  CATEGORY:  system
      ARCH:  sparc
   VERSION:  11.10.0,REV=2005.01.21.15.53
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  configuration and start-up files for the AutoFS filesystem
    PSTAMP:  on10ptchfeat20090317035816
  INSTDATE:  Jun 26 2009 08:04
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:       15 installed pathnames
                  10 shared pathnames
                  10 directories
                   1 executables
                  13 blocks used (approx)

*System version*
root@testldapc01 # showrev -w

OpenWindows version: 
Solaris X11 Version 6.6.2 20 May 2009
Anyone already encountered this kind of problems ? How did you solve it ?

Comments

Jonathan Lewis

Which version of Oracle ?

What does v$session_wait_history show for that session.

What do you see as the state and event over a short set of queries to v$session for that sid ?

Regards

Jonathan Lewis


JustinCave

Sorry.

The database is 11.2.0.3 on AIX.

I'll take a look at gv$session_wait_history momentarily, we've killed the process and are restarting after giving the Access database a couple good kicks in the pants.

Justin

JustinCave

gv$session_wait_history is reporting events of

SQL*Net message to client

SQL*Net message from client

It does appear that the Access changes resolved the overall issue.  But while Access was chugging away, I was still seeing LAST_CALL_ET getting reset with no other obvious signs of activity.

Justin

Jonathan Lewis
Answer

JustinCave wrote:

gv$session_wait_history is reporting events of

SQL*Net message to client

SQL*Net message from client

It does appear that the Access changes resolved the overall issue.  But while Access was chugging away, I was still seeing LAST_CALL_ET getting reset with no other obvious signs of activity.

Justin

If it was changing between FROM and TO there must have been some message coming from Access and bouncing back without an error. Possibly some sort of OCI "ping" type call that didn't involve an SQL statement.

Update:  something like a "set context" or "set client identifier" perhaps; possibly a (non-SQL) rollback or commit


Regards

Jonathan Lewis

Marked as Answer by JustinCave · Sep 27 2020
1 - 4
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jul 29 2009
Added on Jul 1 2009
0 comments
919 views