[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Queries to multi-ldbm dirs not like single-ldbm dirsle (ITS#177)



The behavior you describe is by design and not a bug.
Each backend is a separate Directory Service Agent (DSA).
Referrals should be added to each backend (DSA) as needed.
The client should then chase these referrals automatically.
Note, the backends MUST be listed less-significant first.
That is:

suffix ou=subtree,o=tree
...

suffix o=tree
...

For additional information on this subject, please see
the -devel list archives.  There was a discussion concerning
search traversing multiple backends and related issues
a few weeks ago.

Kurt

At 02:06 AM 5/26/99 GMT, ajf_nylorac@acm.org wrote:
>Full_Name: Albert John FitzPatrick III
>Version: 1.2.1
>OS: RedHat-5.2/Linux-2.0.31
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (207.172.124.83)
>
>
>Gentlemen,
>
>If I create an LDAP directory using multiple ldbm databases then I
>cannot locate all records with a simple query.  Whereas the same query
>issued against the same data stored in a directory using a single ldbm
>database returns the expected result.
>
>I loaded the directory with entries similar to the following:
>
>  dn: o=myorg
>  objectClass: top
>  objectClass: organization
>  o: myorg
>
>  dn: ou=People,o=myorg
>  objectClass: top
>
>  dn: ou=Roaming,o=myorg
>  objectClass: top
>
>  dn: uid=test,ou=People,o=myorg
>  objectClass: top
>
>I then used the command "
>	ldapsearch \
>		-h 127.0.0.1 \
>		-s sub \
>		-b o=myorg \
>		-D 'uid=root,ou=People,o=myorg' \
>		-w 'stupidpw' \
>		'objectClass=*'
>" to query *all* entries within the directory.
>
>The above query, assuming that the bindDN is the rootDN and the bindPW is
>the rootPW (for all databases), should return all of the above entries.  It
>will if they are all store within a single ldbm database.  It will not if
>the ou=People,o=myorg subtree and the ou=Roaming,o=myorg subtree are each
>stored in separate ldbm databases (making for a total of three ldbm
>databases).
>
>
>Albert FitzPatrick