Bug 190096 - autofs complains about objectclass but works using ldap
autofs complains about objectclass but works using ldap
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-27 11:07 EDT by Mark Chappell
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: autofs-4.1.4-27
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-22 06:55:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Chappell 2006-04-27 11:07:29 EDT
Bug 156819 claims to have be resolved but as of 4.1.4-16.2.2 the message is
still there.  The following extracts demonstrate where and why the message is
still there and are from the FC5 autofs SRPM where the SPEC file has been built
with "rpmbuild -bp".

/usr/src/redhat/BUILD/autofs-4.1.4/modules/lookup_ldap.c :

    455         e = ldap_first_entry(ldap, result);
    456         if (!e) {
    457                 crit(MODPREFIX "got answer, but no first entry for %s",
query);
    458                 ldap_msgfree(result);
    459                 ldap_unbind(ldap);
    460                 return CHE_MISSING;
    461         }

This code is called 3 times with different object classes, suggesting that the
crit should be reduced to a debug.

/usr/src/redhat/BUILD/autofs-4.1.4/modules/lookup_ldap.c :

    630 
    631         ret = lookup_one(root, key, "nisObject", "cn", "nisMapEntry", ctxt);
    632         ret2 = lookup_one(root, key,
    633                             "automount", "cn", "automountInformation",
ctxt);
    634         ret3 = lookup_one(root, key,
    635                         "automount", "automountKey",
"automountInformation", ctxt);
    636 


Mark

--
+++ This bug was initially created as a clone of Bug #156819 +++

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:

-- Additional comment from cfeist@redhat.com on 2005-10-04 12:19 EST --
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.

-- Additional comment from George.Liu@noaa.gov on 2005-10-04 12:37 EST --
Could you specify the extra schemas that caused problem? Thanks.

-- Additional comment from cfeist@redhat.com on 2005-10-04 12:52 EST --
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.

-- Additional comment from jmoyer@redhat.com on 2006-04-19 17:06 EST --
new packages should suppress this warning.

-- Additional comment from George.Liu@noaa.gov on 2006-04-19 17:13 EST --
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.

-- Additional comment from jmoyer@redhat.com on 2006-04-19 17:18 EST --
This bug has been fixed in autofs-4.1.3-158 and later.
Comment 1 Ian Kent 2006-04-27 13:04:35 EDT
(In reply to comment #0)

> 
> This code is called 3 times with different object classes, suggesting that the
> crit should be reduced to a debug.

Absolutlely, Ithought they had been, my mistake.
I'll change them to debug prints.

Sorry about this.

Ian
Comment 2 Ian Kent 2006-06-21 21:06:11 EDT
(In reply to comment #1)
> (In reply to comment #0)
> 
> > 
> > This code is called 3 times with different object classes, suggesting that the
> > crit should be reduced to a debug.
> 
> Absolutlely, Ithought they had been, my mistake.
> I'll change them to debug prints.
> 

This one slipped through the cracks.
The most recent FC-5 update has a patch that does this.

Can you check and confirm that this problem is resolved.


Comment 3 Mark Chappell 2006-06-22 06:52:30 EDT
(In reply to comment #2)
> This one slipped through the cracks.
> The most recent FC-5 update has a patch that does this.
> 
> Can you check and confirm that this problem is resolved.

Ian, many thanks, this appears to have done the job.
(autofs-4.1.4-27)


Mark

Note You need to log in before you can comment on or make changes to this bug.