[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LDAP entries missing from search results depending on search base.
- To: openldap-technical@openldap.org
- Subject: LDAP entries missing from search results depending on search base.
- From: Brandon Hume <hume-ol@bofh.ca>
- Date: Wed, 04 Apr 2012 16:15:17 -0300
- User-agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20110417 Lightning/1.0b2 Thunderbird/3.1.4
I have a large number of mail aliases stored in LDAP used by sendmail.
They're stored off by themselves as opposed to hung off the user
objects, so that the mail servers can have their own LDAP replicas
containing only a portion of the tree rather than all the user objects
as well. An example entry would be thus:
dn: cn=broken2,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA
objectClass: top
objectClass: applicationProcess
objectClass: inetLocalMailRecipient
cn: broken2
mailRoutingAddress: broken2@dal.ca
mailLocalAddress: broken2@imap.dal.ca
However, this entry will not show up in searches, depending on what I
use as a search base:
A successful search looks like:
$ /opt/csw/bin/ldapsearch -x -W -D cn=noc,dc=dal,dc=ca -h
kil-ds-3.its.dal.ca -b dc=dal,dc=ca -LLL -s sub '(cn=broken2)' dn
Enter LDAP Password:
dn: cn=broken2,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA
$
However, if I change *only* the search base:
$ /opt/csw/bin/ldapsearch -x -W -D cn=noc,dc=dal,dc=ca -h
kil-ds-3.its.dal.ca -b cn=services,dc=dal,dc=ca -LLL -s sub
'(cn=broken2)' dn
Enter LDAP Password:
$
A base of cn=Mailmaps,cn=Services,dc=DAL,dc=CA likewise doesn't work,
but the entry appears again if I use
cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA.
This server is running 2.4.30 built with BerkeleyDB 5.3.15. The backend
I'm using is HDB. I've *completely* removed any ACLs I had defined and
it made no difference... not that I expected it to, since
cn=noc,dc=dal,dc=ca is the rootDN.
I thought I might have been running into a limit of number of objects
inside a container (there's about 123k entries under cn=dal) so I tried
dumping the DIT, and moving everything into subcontainers based on first
character of the alias (cn=a,cn=dal ; cn=b,cn=dal and so on) which made
sure there was no container with more than 10k objects... it still made
no difference.
I've run the server with olcLogLevel=Any, and I see the following
difference in the syslog:
A "good" search:
Apr 4 16:12:43 kil-ds-3 slapd[29544]: conn=1035 op=1 SRCH
base="dc=dal,dc=ca" scope=2 deref=0 filter="(cn=broken2)"
Apr 4 16:12:43 kil-ds-3 slapd[29544]: conn=1035 op=1 SRCH attr=dn
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => hdb_search
Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_dn2entry("dc=dal,dc=ca")
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => access_allowed: search
access to "dc=DAL,dc=CA" "entry" requested
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= root access granted
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => access_allowed: search
access granted by manage(=mwrscxd)
Apr 4 16:12:43 kil-ds-3 slapd[29544]: search_candidates:
base="dc=dal,dc=ca" (0x00000001) scope=2
Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: activity on 1 descriptor
Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: activity on:
Apr 4 16:12:43 kil-ds-3 slapd[29544]:
Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => hdb_dn2idl("dc=dal,dc=ca")
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011AND
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa0
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011OR
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa1
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011EQUALITY
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates
(objectClass)
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => key_read
Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [b49d1940]
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_index_read: failed
(-30988)
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates:
id=0, first=0, last=0
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=0 first=0 last=0
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011EQUALITY
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates (cn)
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => key_read
Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [2714190a]
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_index_read 1 candidates
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates:
id=1, first=338261, last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=1 first=338261 last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=1
first=338261 last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=1 first=338261 last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=1
first=338261 last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=1 first=338261 last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_search_candidates: id=1
first=338261 last=338261
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => test_filter
Apr 4 16:12:43 kil-ds-3 slapd[29544]: EQUALITY
Apr 4 16:12:43 kil-ds-3 slapd[29544]: => access_allowed: search
access to
"cn=broken2,cn=b,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA" "cn"
requested
And a "bad" search:
Apr 4 16:13:43 kil-ds-3 slapd[29544]: conn=1036 op=1 SRCH
base="cn=services,dc=dal,dc=ca" scope=2 deref=0 filter="(cn=broken2)"
Apr 4 16:13:43 kil-ds-3 slapd[29544]: conn=1036 op=1 SRCH attr=dn
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => hdb_search
Apr 4 16:13:43 kil-ds-3 slapd[29544]:
bdb_dn2entry("cn=services,dc=dal,dc=ca")
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => access_allowed: search
access to "cn=Services,dc=DAL,dc=CA" "entry" requested
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= root access granted
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => access_allowed: search
access granted by manage(=mwrscxd)
Apr 4 16:13:43 kil-ds-3 slapd[29544]: search_candidates:
base="cn=services,dc=dal,dc=ca" (0x00000003) scope=2
Apr 4 16:13:43 kil-ds-3 slapd[29544]: =>
hdb_dn2idl("cn=services,dc=dal,dc=ca")
Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: activity on 1 descriptor
Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: activity on:
Apr 4 16:13:43 kil-ds-3 slapd[29544]:
Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=9
active_threads=0 tvp=zero
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011AND
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011OR
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa1
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011EQUALITY
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates
(objectClass)
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => key_read
Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [b49d1940]
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_index_read: failed
(-30988)
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates:
id=0, first=0, last=0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=0 first=0 last=0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates
Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011EQUALITY
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates (cn)
Apr 4 16:13:43 kil-ds-3 slapd[29544]: => key_read
Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [2714190a]
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_index_read 1 candidates
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates:
id=1, first=338261, last=338261
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=1 first=338261 last=338261
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=1
first=338261 last=338261
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=1 first=338261 last=338261
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=0
first=3 last=0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates:
id=0 first=3 last=0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_search_candidates: id=0
first=3 last=0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: hdb_search: no candidates
Apr 4 16:13:43 kil-ds-3 slapd[29544]: send_ldap_result: conn=1036
op=1 p=3
Apr 4 16:13:43 kil-ds-3 slapd[29544]: send_ldap_result: err=0
matched="" text=""
Apr 4 16:13:43 kil-ds-3 slapd[29544]: send_ldap_response: msgid=2
tag=101 err=0
Apr 4 16:13:43 kil-ds-3 slapd[29544]: conn=1036 op=1 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Notable is hdb_search finding no candidates.
Is there anything obviously wrong, here?