From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux; es, es_CL) (KHTML, like Gecko) Description of problem: The autofs shipped with FC2 refuses to start when configured to retrieve data from a LDAP directory which format is exactly the suggested in the docs. Version-Release number of selected component (if applicable): 4.1.2-2 How reproducible: Always Steps to Reproduce: 1. Login as root on the client 2. Do /etc/init.d/autofs start Actual Results: autofs init.d script says [OK], but the following appears on /var/log/messages: Jul 17 15:10:48 manutara autofs: automount startup succeeded Jul 17 15:10:49 manutara automount[8646]: lookup(ldap): query failed for (&(objectclass=automount)) Jul 17 15:10:49 manutara automount[8646]: failed to load map, exiting And automount is not found running. Expected Results: automount should have start normally. Additional info: We mount /home via autofs, and store mount information on LDAP. Our "client" configuration: /etc/nsswitch.conf: automount: ldap /etc/ldap.conf: host <LDAP-SERVER-IP> base <BASEDN> ssl no pam_password md5 /etc/openldap/ldap.conf: URI ldap://<LDAP-SERVER> BASE <BASEDN> output from "/etc/init.d/autofs status" Configured Mount Points: ------------------------ /usr/sbin/automount --timeout=60 /home ldap //<LDAP-SERVER>/ou=auto.home,<BASEDN> (on a single line) LDIF's from the LDAP directory: # auto.master, <BASE, DN> dn: ou=auto.master,<BASEDN> objectClass: top objectClass: automountMap ou: auto.master # /home, auto.master, <BASE, DN> dn: cn=/home,ou=auto.master,<BASEDN> objectClass: automount cn: /home automountInformation: ldap://<LDAP-SERVER>/ou=auto.home,<BASEDN> # auto.home, <BASE, DN> dn: ou=auto.home,<BASEDN> objectClass: top objectClass: automountMap ou: auto.home # jcataldo, auto.home, <BASE-DN> dn: cn=jcataldo,ou=auto.home,<BASEDN> objectClass: automount cn: jcataldo automountInformation: trauco:/export/staff/jcataldo (and so)
Created attachment 102005 [details] Debugging output from slapd -d 4 when doing /etc/init.d/autofs start on the client
Other tests we have run: * Force-install autofs' RPM from FC1. It worked perfectly (the bug is not present). * Change LDAP entries format from automount to nis. The problem persists.
Everything looks ok, this is indeed quite puzzling. Could you please re-run your test with the --debug option? You can set this in /etc/sysconfig/autofs under DAEMONOPTIONS. -Jeff
This is what I get in the logfile: -------------------------------------------------------------- Jul 19 21:57:00 manutara automount[1241]: starting automounter version 4.1.2, path = /home, maptype = ldap, mapname = //<LDAP-SERVER>/ou=auto.home,<BASEDN> Jul 19 21:57:00 manutara autofs: automount startup succeeded Jul 19 21:57:00 manutara automount[1241]: using kernel protocol version 3.00 Jul 19 21:57:00 manutara automount[1241]: using timeout 60 seconds; freq 15 secs Jul 19 21:57:00 manutara automount[1241]: lookup(ldap): query failed for (&(objectclass=automount)) Jul 19 21:57:00 manutara automount[1241]: failed to load map, exiting Jul 19 21:57:00 manutara automount[1241]: rm_unwanted: /home --------------------------------------------------------------
This does not include the debug output. Could you add an entry to /etc/syslog.conf that looks as follows: *.* /var/log/debug Then, send a HUP signal to syslogd: # killall -HUP syslogd Rerun your tests and you should find much more verbose output in /var/log/debug. Thanks!
Created attachment 102073 [details] Debugging output from automount when it tries to start Here is the output. Please note that when running manually a ldapsearch -x -b 'ou=auto.home,<BASEDN>' '(&(objectclass=automount))' I do get results on the form: # jcataldo, <BASE, DN> dn: cn=jcataldo,ou=auto.home,<BASEDN> objectClass: automount cn: jcataldo automountInformation: trauco:/export/staff/jcataldo But the automount seems not to "see" this entries.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Can you try with latest autofs, autofs-4.1.4-5 (Fedora Core 4)? Several LDAP issues have been resolved since FC2.
No response from bug opener for several months. Should be fixed in FC4.