Rich Megginson wrote:
Tim Hartmann wrote:
>
>>
>
> So after playing with logconv a bit, it looked like finger was making
> this call in the logs...
>
> [26/Jun/2009:10:59:36 -0400] conn=283289 op=-1 fd=80 closed - B1
> [26/Jun/2009:10:59:36 -0400] conn=283289 op=2 RESULT err=11 tag=101
> nentries=0 etime=1 notes=U
> [26/Jun/2009:10:59:35 -0400] conn=283289 op=2 SRCH
> base="ou=really,ou=long,o=name,dc=school,dc=edu" scope=2
> filter="(objectClass=posixAccount)" attrs="uid userPassword uidNumber
> gidNumber cn homeDirectory loginShell gecos description objectClass"
> [26/Jun/2009:10:59:35 -0400] conn=283289 op=1 RESULT err=0 tag=101
> nentries=1 etime=0
> [26/Jun/2009:10:59:35 -0400] conn=283289 op=1 SRCH
> base="ou=systems,ou=services,o=hascs,dc=fas,dc=harvard,dc=edu" scope=2
> filter="(&(objectClass=posixAccount)(uid=foo))" attrs="uid
userPassword
> uidNumber gidNumber cn homeDirectory loginShell gecos description
> objectClass"
> [26/Jun/2009:10:59:35 -0400] conn=283289 op=0 RESULT err=0 tag=97
> nentries=0 etime=0 dn=""
> [26/Jun/2009:10:59:35 -0400] conn=283289 op=0 BIND dn="" method=128
> version=3
> [26/Jun/2009:10:59:35 -0400] conn=283289 fd=80 slot=80 connection from
> 1.2.3.4 to 4.3.2.1
>
>
>
> But even after indexing "uid userPassword uidNumber gidNumber cn
> homeDirectory loginShell gecos description objectClass" finger still
> responds slower then it does on comparison to the older openLDAP
> servers... where we don't do indexing on all of these attributes, AND
> still claims that I'm running an search that hasn't been indexed! I'm
> I missing something glaringly obvious?
You only need to index the attributes used for searching:
(&(objectClass=posixAccount)(uid=foo))
You need an equality index on objectClass (which should already be
there, it is one of the default indexes) and an equality index on uid
(again, should already be there).
Ok, thats cool, those are both being indexed correctly....
The problem is this:
[26/Jun/2009:10:59:36 -0400] conn=283289 op=2 RESULT err=11 tag=101
nentries=0 etime=1 notes=U
[26/Jun/2009:10:59:35 -0400] conn=283289 op=2 SRCH
base="ou=really,ou=long,o=name,dc=school,dc=edu" scope=2
filter="(objectClass=posixAccount)" attrs="uid userPassword uidNumber
gidNumber cn homeDirectory loginShell gecos description objectClass"
The notes=U and err=11 mean that either the lookthrough limit has been
exceeded, or you need to increase your nsslapd-idlistscanlimit:
http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Comma...
This is not a good search anyway - the client is basically asking for
all entries that match objectClass=posixAccount which could be
thousands or more - what does the client intend to do with all of
those entries?
Thats apparently the search that "finger foo" on RHEL 5.2 generates!
"finger foo" on Ubunutu 8.04 responds notibly faster, so I'm assuming
that it's generating a different search... hmmm