Faq #1111 states that given ...
dn: uid=alias,ou=People,dc=example,dc=net objectclass: alias objectclass: extensibleObject uid: alias aliasedobjectname: uid=target,ou=Retired People,dc=example,dc=com
... then
ldapsearch -x -a always -b uid=alias,ou=People,dc=example,dc=net 'objectclass=*'
will return results from the "target" DN. Should the same results be expected from searching with ...
ldapsearch -x -a always -b ou=People,dc=example,dc=net uid=alias
... assuming uid was indexed for equality.
Dave --- Dave Lewney IT Services, University of Sussex, Brighton BN1 9QT
It took me a while to realize you actually had a question here, you might want to repost being a bit more explicit about what it is you are asking.
--Quanah
--On Tuesday, January 22, 2008 12:29 PM +0000 Dave Lewney d.m.lewney@sussex.ac.uk wrote:
Faq #1111 states that given ...
dn: uid=alias,ou=People,dc=example,dc=net objectclass: alias objectclass: extensibleObject uid: alias aliasedobjectname: uid=target,ou=Retired People,dc=example,dc=com
... then
ldapsearch -x -a always -b uid=alias,ou=People,dc=example,dc=net 'objectclass=*'
will return results from the "target" DN. Should the same results be expected from searching with ...
ldapsearch -x -a always -b ou=People,dc=example,dc=net uid=alias
... assuming uid was indexed for equality.
Dave
Dave Lewney IT Services, University of Sussex, Brighton BN1 9QT
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
It took me a while to realize you actually had a question here, you might want to repost being a bit more explicit about what it is you are asking.
--Quanah
--On Tuesday, January 22, 2008 12:29 PM +0000 Dave Lewney d.m.lewney@sussex.ac.uk wrote:
Faq #1111 states that given ...
dn: uid=alias,ou=People,dc=example,dc=net objectclass: alias objectclass: extensibleObject uid: alias aliasedobjectname: uid=target,ou=Retired People,dc=example,dc=com
... then
ldapsearch -x -a always -b uid=alias,ou=People,dc=example,dc=net 'objectclass=*'
will return results from the "target" DN. Should the same results be expected from searching with ...
ldapsearch -x -a always -b ou=People,dc=example,dc=net uid=alias
... assuming uid was indexed for equality.
Dave
Dave Lewney IT Services, University of Sussex, Brighton BN1 9QT
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
My intention is to have a tree of aliases which point to "real" posixaccount entries. A search such as ...
ldapsearch -x -a search -b 'ou=test,ou=Services,o=University of Sussex' uid=dml
*does* actually retrieve the posixaccount entry but this method will not scale. Instead of retrieving the aliasedobjectname and dereferencing, it appears to generate a search for every entry in the alias tree. With 30,000+ entries this is effectively unworkable. So, my real question is why are all these searches being generated and am I correct in thinking that I have misunderstood alias dereferencing?
The alias tree, containing just 3 entries for testing ...
# dml, test, Services, University of Sussex dn: uid=dml,ou=test,ou=Services,o=University of Sussex objectClass: extensibleObject objectClass: alias aliasedObjectName: uid=dml,ou=unix,ou=uscs,o=University of Sussex uid: dml
# dml24, test, Services, University of Sussex dn: uid=dml24,ou=test,ou=Services,o=University of Sussex objectClass: extensibleObject objectClass: alias aliasedObjectName: uid=dml24,ou=unix,ou=uscs,o=University of Sussex uid: dml24
# dml25, test, Services, University of Sussex dn: uid=dml25,ou=test,ou=Services,o=University of Sussex objectClass: extensibleObject objectClass: alias aliasedObjectName: uid=dml25,ou=unix,ou=uscs,o=University of Sussex uid: dml25
... and one of the posixaccount entries pointed to ...
# dml, unix, USCS, University of Sussex dn: uid=dml,ou=unix,ou=USCS,o=University of Sussex uid: dml uidNumber: 24964 gidNumber: 100 homeDirectory: /home/csrv/dml objectClass: uosUnixObject objectClass: shadowAccount objectClass: posixAccount sn: Lewney cn: Dave Lewney gecos: Dave Lewney loginShell: /bin/tcsh
... and the log - notice the search for dml, dml24 and dml25 ...
Jan 25 09:30:16 murray slapd[278]: bdb_db_open: "o=University of Sussex"\n Jan 25 09:30:16 murray slapd[278]: => bdb_entry_get: ndn: "o=university of sussex"\n Jan 25 09:30:16 murray slapd[278]: => bdb_entry_get: oc: "(null)", at: "contextCSN"\n Jan 25 09:30:16 murray slapd[278]: bdb_idl_fetch_key: \n Jan 25 09:30:16 murray slapd[278]: bdb_idl_fetch_key: \n Jan 25 09:30:16 murray slapd[278]: send_ldap_result: err=0 matched="" text=""\n Jan 25 09:30:16 murray slapd[278]: slapd starting\n Jan 25 09:30:25 murray slapd[278]: conn=0 fd=13 ACCEPT from IP=139.184.134.180:61127 (IP=139.184.132.109:389)\n Jan 25 09:30:25 murray slapd[278]: connection_get(13)\n Jan 25 09:30:25 murray slapd[278]: conn=0 op=0 BIND dn="" method=128\n Jan 25 09:30:25 murray slapd[278]: send_ldap_result: err=0 matched="" text=""\n Jan 25 09:30:25 murray slapd[278]: conn=0 op=0 RESULT tag=97 err=0 text=\n Jan 25 09:30:25 murray slapd[278]: connection_get(13)\n Jan 25 09:30:25 murray slapd[278]: SRCH "ou=test,ou=services,o=university of sussex" 2 1 Jan 25 09:30:25 murray slapd[278]: 0 0 0\n Jan 25 09:30:25 murray slapd[278]: filter: (uid=dml)\n Jan 25 09:30:25 murray slapd[278]: attrs: Jan 25 09:30:25 murray slapd[278]: \n Jan 25 09:30:25 murray slapd[278]: conn=0 op=1 SRCH base="ou=test,ou=services,o=university of sussex" scope=2 deref=1 filter="(uid=dml)"\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: [01872a84]\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @ou=test,ou=services,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @uid=dml,ou=unix,ou=uscs,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @uid=dml24,ou=unix,ou=uscs,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @uid=dml25,ou=unix,ou=uscs,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: [b49d1940]\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: [c49b2cb3]\n Jan 25 09:30:25 murray slapd[278]: send_ldap_result: err=0 matched="" text=""\n Jan 25 09:30:25 murray slapd[278]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=\n Jan 25 09:30:25 murray slapd[278]: connection_get(13)\n Jan 25 09:30:25 murray slapd[278]: conn=0 op=2 UNBIND\n Jan 25 09:30:25 murray slapd[278]: conn=0 fd=13 closed\n
Dave --- Dave Lewney IT Services, University of Sussex, Brighton BN1 9QT
--On Friday, January 25, 2008 9:51 AM +0000 Dave Lewney d.m.lewney@sussex.ac.uk wrote:
Jan 25 09:30:25 murray slapd[278]: conn=0 op=1 SRCH base="ou=test,ou=services,o=university of sussex" scope=2 deref=1 filter="(uid=dml)"\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: [01872a84]\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @ou=test,ou=services,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @uid=dml,ou=unix,ou=uscs,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @uid=dml24,ou=unix,ou=uscs,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: @uid=dml25,ou=unix,ou=uscs,o=university of sussex\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: [b49d1940]\n Jan 25 09:30:25 murray slapd[278]: bdb_idl_fetch_key: [c49b2cb3]\n Jan 25 09:30:25 murray slapd[278]: send_ldap_result: err=0 matched=""
You fail to mention what version of OpenLDAP you are running, which would be useful information. But I would not that if you have a poorly designed DIT, this may be the expected behavior as the query will look at every entry in the scope.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Monday, January 28, 2008 10:04 AM -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:
But I would not that if you have a poorly
s/not/note/
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
You fail to mention what version of OpenLDAP you are running, which would be useful information. But I would not that if you have a poorly designed DIT, this may be the expected behavior as the query will look at every entry in the scope.
It will look at every *alias* in the scope.
For the original question:
dn: uid=alias,ou=People,dc=example,dc=net objectclass: alias objectclass: extensibleObject uid: alias aliasedobjectname: uid=target,ou=Retired People,dc=example,dc=com
... then
ldapsearch -x -a always -b uid=alias,ou=People,dc=example,dc=net 'objectclass=*'
will return results from the "target" DN.
Yes, this would give the same result as a subtree search with a baseDN of uid=target,ou=Retired People,...
Should the same results be expected from searching with ...
ldapsearch -x -a always -b ou=People,dc=example,dc=net uid=alias
... assuming uid was indexed for equality.
Probably not, because the filters are not the same. This search would only return results that match the (uid=alias) filter. If all of the entries in the target branch have a matching uid attribute, then the result sets might look the same.
openldap-software@openldap.org
-
Dave Lewney -
Howard Chu -
Quanah Gibson-Mount