I can confirm that this problem still exists in Ubuntu 9.10
Dec 9 01:26:07 human automount[11065]: using kernel protocol version 5.01
Dec 9 01:26:07 human automount[11065]: lookup_nss_read_master: reading master file /etc/auto.master
Dec 9 01:26:07 human automount[11065]: parse_init: parse(sun): init gathered global options: (null)
Dec 9 01:26:07 human automount[11065]: lookup_read_master: lookup(file): read entry +auto.master
Dec 9 01:26:07 human automount[11065]: lookup_nss_read_master: reading master files auto.master
Dec 9 01:26:07 human automount[11065]: parse_init: parse(sun): init gathered global options: (null)
Dec 9 01:26:07 human automount[11065]: lookup_nss_read_master: reading master ldap auto.master
Dec 9 01:26:07 human automount[11065]: open_lookup:90: cannot open lookup module ldap (/usr/lib/autofs/lookup_ldap.so: undefined symbol: do_verbose)
Dec 9 01:26:07 human automount[11065]: lookup(file): failed to read included master map auto.master
Dec 9 01:26:07 human automount[11065]: no mounts in table
My /etc/auto.master has nothing in it except the default uncommented line (+auto.master at the end of the file).
I have made the following changes to /etc/default/autofs
I have several machines running CentOS 5.3, and everything worked perfectly as soon as I renamed auto.master to auto_bak.master (literally -- install, set up ldap authentication and rename the file. Nothing more.). I assume this means we can rule out LDAP-related problems.
If it makes a difference, this bug is occurring on both of my Ubuntu servers, and they are the OpenLDAP servers. All configuration is done with a non-LDAP user. Slapd confirmed to be up and running from the point of view of a CentOS machine.
I have to manually keep my auto.* files in sync on the ubuntu machines until this bug gets fixed, so please let me know if there's any other information you need in order to investigate.
I can confirm that this problem still exists in Ubuntu 9.10
Dec 9 01:26:07 human automount[11065]: using kernel protocol version 5.01 nss_read_ master: reading master file /etc/auto.master nss_read_ master: reading master files auto.master nss_read_ master: reading master ldap auto.master autofs/ lookup_ ldap.so: undefined symbol: do_verbose)
Dec 9 01:26:07 human automount[11065]: lookup_
Dec 9 01:26:07 human automount[11065]: parse_init: parse(sun): init gathered global options: (null)
Dec 9 01:26:07 human automount[11065]: lookup_read_master: lookup(file): read entry +auto.master
Dec 9 01:26:07 human automount[11065]: lookup_
Dec 9 01:26:07 human automount[11065]: parse_init: parse(sun): init gathered global options: (null)
Dec 9 01:26:07 human automount[11065]: lookup_
Dec 9 01:26:07 human automount[11065]: open_lookup:90: cannot open lookup module ldap (/usr/lib/
Dec 9 01:26:07 human automount[11065]: lookup(file): failed to read included master map auto.master
Dec 9 01:26:07 human automount[11065]: no mounts in table
My /etc/auto.master has nothing in it except the default uncommented line (+auto.master at the end of the file).
I have made the following changes to /etc/default/autofs
LOGGING="debug"
LDAP_URI= "ldap:/ /localhost"
SEARCH_ BASE="ou= automount, dc=mydomain, dc=com"
MAP_OBJECT_ CLASS=" automountMap" CLASS=" automount" ="cn" ="automountInfo rmation"
ENTRY_OBJECT_
MAP_ATTRIBUTE="ou"
ENTRY_ATTRIBUTE
VALUE_ATTRIBUTE
I have several machines running CentOS 5.3, and everything worked perfectly as soon as I renamed auto.master to auto_bak.master (literally -- install, set up ldap authentication and rename the file. Nothing more.). I assume this means we can rule out LDAP-related problems.
If it makes a difference, this bug is occurring on both of my Ubuntu servers, and they are the OpenLDAP servers. All configuration is done with a non-LDAP user. Slapd confirmed to be up and running from the point of view of a CentOS machine.
LDAP automounts are in the form:
dn: cn=myNfsShare, ou=auto. u,ou=automount, dc=mydomain, dc=com ation: -fstype= nfs,rw, soft,intr, rsize=8192, wsize=8192 shareHostName: /myNfsShare tClass: automount
objectClass: automount
objectClass: top
automountInform
cn: myNfsShare
creatorsName: cn=root,dc=com
hasSubordinates: FALSE
structuralObjec
subschemaSubentry: cn=Subschema
and maps are in the form:
dn: ou=auto. machines, ou=automount, dc=mydomain, dc=com tClass: automountMap
objectClass: automountMap
objectClass: top
ou: auto.machines
creatorsName: cn=root,dc=com
hasSubordinates: TRUE
structuralObjec
subschemaSubentry: cn=Subschema
I have to manually keep my auto.* files in sync on the ubuntu machines until this bug gets fixed, so please let me know if there's any other information you need in order to investigate.