Bug 133063 - lookup(ldap): query failed for (&(objectclass=nisObject))
lookup(ldap): query failed for (&(objectclass=nisObject))
Status: CLOSED DUPLICATE of bug 106354
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-21 09:26 EDT by Marc Schmitt
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-28 18:12:40 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 Marc Schmitt 2004-09-21 09:26:39 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803

Description of problem:
Having updated my system from U2 to U3, the new autofs version
4.1.3-12 breaks the ldap lookups that used to work under 3.1.7-41. 

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

How reproducible:
Always

Steps to Reproduce:
1. Create an entry in auto.master as follows:

/home                   ldap:nismapname=auto_home,dc=inf,dc=ethz,dc=ch

2. `service autofs reload`
3. `service autofs status` will not list /home as active mount point
    

Actual Results:  Error message in /var/log/messages:

Sep 21 14:55:30 vslab1 automount[4219]: starting automounter version
4.1.3-12, path = /home, maptype = ldap, mapname =
nismapname=auto_home,dc=inf,dc=ethz,dc=ch
Sep 21 14:55:30 vslab1 automount[4219]: using kernel protocol version 4.05
Sep 21 14:55:30 vslab1 automount[4219]: using timeout 60 seconds; freq
15 secs
Sep 21 14:55:31 vslab1 automount[4219]: lookup(ldap): query failed for
(&(objectclass=nisObject))
Sep 21 14:55:31 vslab1 automount[4219]: failed to load map, exiting
Sep 21 14:55:31 vslab1 automount[4219]: rm_unwanted: /home


Expected Results:  Automounter should start /home as it does under
autofs-3.1.7-41.

Additional info:

The ldap server works properly. I have still some clients running U2
and /home works flawlessly there. Doing an ldapsearch on U3 shows the
correct result:

[root@vslab1 root]# ldapsearch -x -b
nismapname=auto_home,dc=inf,dc=ethz,dc=ch cn=mschmitt
version: 2
 
#
# filter: cn=mschmitt
# requesting: ALL
#
 
# mschmitt, auto_home, inf, ethz, ch
dn: cn=mschmitt,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
nisMapName: auto_home
cn: mschmitt
objectClass: nisobject
objectClass: top
nisMapEntry: localhost:/afs/ethz.ch/users/m/mschmitt/infk/$OSNAME
 
# search result
search: 2
result: 0 Success
 
# numResponses: 2
# numEntries: 1

Is there something broken or is a ldap map containing the word
nismapname simply not allowed anymore under autofs-4.1.3-12? I ask
because I have other ldap entries in auto.master that look like this:
/pub                    ldap:ou=mattern,dc=inf,dc=ethz,dc=ch
and they work under both, U2 and U3.
Comment 1 Jaak Simm 2004-10-14 06:09:48 EDT
I had the same problem when switching to new version of autofs.
The syntax of auto.master file has changed:

In autofs-3.1 it was:
/home    ldap:nismapname=auto_home,dc=inf,dc=ethz,dc=ch

In autofs-4.1 it is now:
/home    ldap://<servername>/nisMapName=auto_home,dc=inf,dc=ethz,dc=ch

Replace <servername> with your LDAP server. Worked for me.
Good luck.
Comment 2 Marc Schmitt 2004-10-14 09:05:04 EDT
Jaak,

Thanks, I'll try that once I'm back in the office. Looks like it's a
step backwards, though, because by hardcoding the <servername> in
auto.master, it won't do failover anymore as it used to by defining
several ldap servers in /etc/ldap.conf...
Comment 3 Marc Schmitt 2004-10-15 13:31:06 EDT
I've tried it and it didn't work. I still get the same error message.
I'm swiching to program: for the moment that calls a perl script to do
the LDAP lookups.
Comment 4 Derek T. Yarnell 2004-12-01 17:04:47 EST
My solution is to just not put auto.master into ldap. You can just put
something like this in auto.master:

/fs  ldap:nisMapName=fs,dc=blah,dc=blah

Then it will use the ldap servers from /etc/ldap.conf
Comment 5 Chris Feist 2004-12-22 12:09:21 EST
I'm trying to replicate the problem on my system, but it seems to work
for me.  However, I may have slightly different LDAP maps than you. 
Can you provide me with the output of this command:

ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch
cn=mschmitt' '(objectClass=nismap)'
Comment 6 Marc Schmitt 2004-12-22 12:27:19 EST
The way you put the command, I get:

ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch
cn=mschmitt' '( objectClass=nismapentry )'
version: 2

#
# filter: ( objectClass=nismapentry )
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1


But taking the cn=mschmitt out of the base dn gives:
ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch'
cn=mschmitt '( objectClass=nismapentry )'
version: 2

#
# filter: cn=mschmitt
# requesting: ( objectClass=nismapentry )
#

# mschmitt, auto_home, inf, ethz, ch
dn: cn=mschmitt,nismapname=auto_home,dc=inf,dc=ethz,dc=ch

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1



and a final run w/o the filter:
ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch' cn=mschmitt
version: 2

#
# filter: cn=mschmitt
# requesting: ALL
#

# mschmitt, auto_home, inf, ethz, ch
dn: cn=mschmitt,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
nisMapName: auto_home
cn: mschmitt
objectClass: nisobject
objectClass: top
nisMapEntry: localhost:/afs/ethz.ch/users/m/mschmitt/infk/$OSNAME

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


HTH
Comment 7 Chris Feist 2004-12-22 17:56:49 EST
Can you try running the command without the cn=mschmitt.

ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch'
'(objectClass=nismapentry)'

Thanks,
Chris
Comment 8 Marc Schmitt 2004-12-23 04:05:53 EST
ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch'
'(objectClass=nismapentry)'
version: 2

#
# filter: (objectClass=nismapentry)
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
Comment 9 Chris Feist 2005-01-28 18:20:18 EST
For some reason it appears that your ldap server is not returning the
auto_home map unless a map below it is specified.

Can you changing the entry in your auto.master file from this:
/home   ldap:nismapname=auto_home,dc=inf,dc=ethz,dc=ch
to this:
/home   ldap:cn=mschmitt,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
Then restarting autofs (as root: service autofs restart) or rebooting,
and then let me know what you see in /home and what entries are
appended to /var/log/messages.

Can you also send me the output of this command as well:
ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch'
('objectClass=nisObject')

Comment 10 Don Felix 2005-02-08 18:19:04 EST
Hope I'm not being rude barging in on someone else's 'bug' but a more 
fundamental question would be: why does autofs try to get all entries 
in the autofs map?  When user 'cn=joe' logs in, the automounter 
should be querying with 
-b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch'
and a filter of
"(&(objectclass=nisObject)(cn=joe))" (or uid=joe, depending on the 
naming attribute that would have to be specified somewhere.)  If you 
cat the whole map everytime somebody logs in you will kill any LDAP 
server in short order (we are seeing that here, with loads on some 
ldap servers running at 30 due entirely to this one issue; it appears 
in our logs like:
[08/Feb/2005:13:57:20 -0800] conn=1610738 op=-1 msgId=-1 - fd=246 
slot=246 LDAP connection from 158.140.28.180 to 158.140.28.210
[08/Feb/2005:13:57:49 -0800] conn=1610738 op=0 msgId=1 - BIND dn="" 
method=128 version=3
[08/Feb/2005:13:57:49 -0800] conn=1610738 op=0 msgId=1 - RESULT err=0 
tag=97 nentries=0 etime=0 dn=""
[08/Feb/2005:13:58:10 -0800] conn=1610738 op=1 msgId=2 - SRCH 
base="automountmapname=auto_home,ou=automount,ou=default,ou=sanjose,ou
=services,o=cadence.com" scope=2 filter="(&(objectClass=nisObject))" 
attrs="cn nisMapEntry"
[08/Feb/2005:13:58:31 -0800] conn=1610738 op=1 msgId=2 - RESULT err=0 
tag=101 nentries=3137 etime=21
[08/Feb/2005:13:58:47 -0800] conn=1610738 op=2 msgId=3 - UNBIND
[08/Feb/2005:13:58:47 -0800] conn=1610738 op=2 msgId=-1 - closing - U1
[08/Feb/2005:13:58:47 -0800] conn=1610738 op=-1 msgId=-1 - closed.
rcus05 # pwd

(it takes 21 seconds for the server to serve up all 3137 entries that 
this client is asking for but does not need.  It takes that long 
because the poor server is responding to the same inane query every 
second or two.)  

Is this issue fixed at any particular revision of autofs?
Comment 11 Chris Feist 2005-02-09 11:56:31 EST
This sounds like a totally separate issue (but important).  Please
open a new bug for this and we'll begin working on it.
Comment 12 Marc Schmitt 2005-03-01 09:20:22 EST
Sorry for the long delay...

Ok, I've done what you suggested. Using
/home   ldap:cn=mschmitt,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
works great for user mschmitt, there are zero error messages in
/var/log/messages and I get the correct home mounted under /home.

The result of the ldap query
`ldapsearch -x -b 'nismapname=auto_home,dc=inf,dc=ethz,dc=ch'
'(objectClass=nisObject)'` is

version: 2

#
# filter: (objectClass=nisObject)
# requesting: ALL
#

# fthommen, auto_home, inf, ethz, ch
dn: cn=fthommen,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
nisMapEntry: localhost:/afs/ethz.ch/users/f/fthommen/infk/$OSNAME
nisMapName: auto_home
cn: fthommen
objectClass: nisobject
objectClass: top

# mschmitt, auto_home, inf, ethz, ch
dn: cn=mschmitt,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
nisMapName: auto_home
cn: mschmitt
objectClass: nisobject
objectClass: top
nisMapEntry: localhost:/afs/ethz.ch/users/m/mschmitt/infk/$OSNAME

.
.
.

# prog19, auto_home, inf, ethz, ch
dn: cn=prog19,nismapname=auto_home,dc=inf,dc=ethz,dc=ch
nisMapEntry: localhost:/afs/ethz.ch/users/p/prog19/infk/$OSNAME
objectClass: top
objectClass: nisObject
nisMapName: auto_home
cn: prog19

# search result
search: 2
result: 4 Size limit exceeded

# numResponses: 2001
# numEntries: 2000
Comment 13 Chris Feist 2005-03-09 11:36:17 EST
Looking at the results from the last comment it looks like you're
running into the LDAP_SIZELIMIT_EXCEEDED bug #133063.  This will be
fixed in RHEL3U5.

Are you using the --ghost option?  You can check if this option is set
in the /etc/sysconfig/autofs file.
Comment 14 Chris Feist 2005-03-14 11:11:52 EST
Sorry, I should be referring to bug #106354 in the previous comment.
Comment 15 Chris Feist 2005-04-28 18:12:40 EDT
No response from bug submitter it appears that this bug is a duplicate of bz #106354

*** This bug has been marked as a duplicate of 106354 ***

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