Paul B. Henson wrote:
> Okay, here is the start of the search:
>
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: conn=1001 op=1 do_search
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: >>> dnPrettyNormal: <dc=cpp,dc=edu>
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <<< dnPrettyNormal: <dc=cpp,dc=edu>,
> <dc=cpp,dc=edu>
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: SRCH "dc=cpp,dc=edu" 2 0 0 0 0
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: filter: (uid=henson)
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: attrs:
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: ==> limits_get: conn=1001 op=1
> self="[anonymous]" this="dc=cpp,dc=edu"
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <== limits_get: type=DN
> match=ANONYMOUS
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_search
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: mdb_dn2entry("dc=cpp,dc=edu")
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_dn2id("dc=cpp,dc=edu")
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_dn2id: got id=0x1
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_entry_decode:
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_entry_decode
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: search_candidates:
> base="dc=cpp,dc=edu" (0x00000001) scope=2
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => mdb_equality_candidates
> (objectClass)
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: => key_read
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: mdb_idl_fetch_key: [d913076f]
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_index_read 132354 candidates
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: <= mdb_equality_candidates: id=-1,
> first=3, last=132356
> Oct 21 17:14:35 ldap-dev-03 slapd[4335]: mdb_search_candidates: id=-1 first=3
> last=132356
>
> It looks like is is looking for an objectClass match and then doing a full
> scan of my entire directory? These lines are followed by thousands and
> thousands of
> entries like:
> Then it does a lookup on memberUid, presumably because I am using the dynlist
> module to maintain memberOf:
>
> dynlist-attrset cppEduPerson memberURL memberOf
>
> and my entry has this attribute:
>
> memberURL: ldap:///dc=cpp,dc=edu??sub?(memberUid=henson)
Then this is probably dynlist searching for objectclass=cppEduPerson.
You should change this configuration to use 2.5 dynlist's memberOf support.
Indexing is not broken.
> My configuration between 2.4 and 2.5 is pretty much identical. Any idea why
> it might be fully traversing the directory looking for object class matches?
>
>
> On 10/21/2021 4:55 PM, Howard Chu wrote:
>> Paul B. Henson wrote:
>>
>>> Any thoughts on what might be going on or how I can debug it to track down
>>> exactly what is causing it? There was obviously a lot more debug info in
>>> the logs
>>> that I didn't include, but none of it jumped out to me as "smoking gun".
>>
>> Try the search again with -d5. Also include the lines showing which
>> attribute it's checking in the index.
>> e.g.:
>>
>> 6171fcb7.1be5a183 0x7f28b65fd640 search_candidates: base="dc=example,dc=com"
>> (0x00000001) scope=2
>> 6171fcb7.1be5b227 0x7f28b65fd640 => mdb_equality_candidates (objectClass)
>> 6171fcb7.1be5cfe4 0x7f28b65fd640 => key_read
>> 6171fcb7.1be5e088 0x7f28b65fd640 mdb_idl_fetch_key: [b49d1940]
>> 6171fcb7.1be5faff 0x7f28b65fd640 <= mdb_index_read: failed (-30798)
>> 6171fcb7.1be60a00 0x7f28b65fd640 <= mdb_equality_candidates: id=0, first=0,
>> last=0
>> 6171fcb7.1be61901 0x7f28b65fd640 => mdb_equality_candidates (sn)
>> 6171fcb7.1be62f1a 0x7f28b65fd640 => key_read
>> 6171fcb7.1be63fbf 0x7f28b65fd640 mdb_idl_fetch_key: [03915b69]
>> 6171fcb7.1be659a9 0x7f28b65fd640 <= mdb_index_read 2 candidates
>> 6171fcb7.1be66a94 0x7f28b65fd640 <= mdb_equality_candidates: id=2, first=8,
>> last=9
>> 6171fcb7.1be68cae 0x7f28b65fd640 mdb_search_candidates: id=2 first=8 last=9
>>
>>
>>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
