Bug 156819

Summary:	autofs complains about objectclass but works using ldap
Product:	[Fedora] Fedora	Reporter:	Paul Gienger <pgienger>
Component:	autofs	Assignee:	Chris Feist <cfeist>
Status:	CLOSED ERRATA	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3	CC:	george.liu, jmoyer
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-04-19 21:06:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Paul Gienger 2005-05-04 14:22:52 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Description of problem:
Using what appears to be a RH/Fedora standard ldap automount map, every mount attempt gives a similar error to the following:

May  4 09:00:26 gold automount[6374]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=pgienger))

Regardless of the error, the mount is successful and things go happily on their way.  The relevant LDIF information is below for this particular entry.  It doesn't make much sense that a fully working system should error so consistantly.

I don't believe there are any other relevant system configuration changes to the  client or the server.  The latest server was a fresh install/patched stock FC3 machine and exhibits the behavior as soon as it is configured as an LDAP client and autofs is restarted.


LDIF follows

dn: ou=auto.master,ou=AutomountMaps,dc=ae-solutions,dc=com
objectClass: automountMap
objectClass: top
ou: auto.master
structuralObjectClass: automountMap

dn: cn=/home,ou=auto.master,ou=AutomountMaps,dc=ae-solutions,dc=com
objectClass: automount
objectClass: top
cn: /home
automountInformation: ldap:ou=auto_home,ou=AutomountMaps,dc=ae-solutions,dc=co
 m soft,bg,rsize=32768,wsize=32768
structuralObjectClass: automount

dn: ou=auto_home,ou=AutomountMaps,dc=ae-solutions,dc=com
objectClass: automountMap
objectClass: top
ou: auto_home
structuralObjectClass: automountMap

dn: cn=pgienger,ou=auto_home,ou=AutomountMaps,dc=ae-solutions,dc=com
objectClass: automount
objectClass: top
cn: pgienger
automountInformation: fgoserv.fargo.ae-solutions.com:/export/home/pgienger
structuralObjectClass: automount


Version-Release number of selected component (if applicable):
autofs-4.1.3-114

How reproducible:
Always

Steps to Reproduce:
1. configure LDAP client
2. (re)start autofs
3. change to an automounted directory
  

Actual Results:  Directory was mounted, error logged

Expected Results:  Directory mounted, no errors on client side except maybe a notification of the directory being mounted.

Additional info:

Comment 1 Chris Feist 2005-10-04 16:19:13 UTC

This is caused because of the support for extra ldap schemas.  Those errors can
be safely ignored and should only be present when logging debug messages in FC-5.

Comment 2 George 2005-10-04 16:37:08 UTC

Could you specify the extra schemas that caused problem? Thanks.

Comment 3 Chris Feist 2005-10-04 16:52:59 UTC

Initially autofs would only look for objectClass=nisObject, the autofs in FC-3
adds support for objectClass=nisObject & objectClass=automount.  Because autofs
checks for both types of maps it prints an error when it looks for maps in the
schema that the site is not using, but it will still succeed if it finds maps in
the other schema.

Comment 4 Jeff Moyer 2006-04-19 21:06:41 UTC

new packages should suppress this warning.

Comment 5 George 2006-04-19 21:13:31 UTC

Could you specify the packages? I am using RHEL 3 & 4, and will be very happy to
see the problem be fixed on those OS versions too.

Comment 6 Jeff Moyer 2006-04-19 21:18:48 UTC

This bug has been fixed in autofs-4.1.3-158 and later.