-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, I'm sure this is a really stupid question, and I'm sorry for asking it, but I'm testing a migration from Sun DSEE to OpenLDAP 2.4.35 at the moment.
I am creating a DIT similar to the following:
dn: ou=people,dc=example,dc=com dn: ou=ftp,dc=example,dc=com dn: ou=groups,dc=example,dc=com dn: ou=hosts,dc=example,dc=com dn: ou=us,ou=people,dc=example,dc=com dn: ou=bd,ou=people,dc=example,dc=com dn: ou=id,ou=people,dc=example,dc=com dn: ou=users,ou=ftp,dc=example,dc=com dn: ou=groups,ou=ftp,dc=example,dc=com dn: ou=us,ou=groups,dc=example,dc=com dn: ou=bd,ou=groups,dc=example,dc=com dn: ou=id,ou=groups,dc=example,dc=com dn: ou=us,ou=hosts,dc=example,dc=com dn: ou=bd,ou=hosts,dc=example,dc=com dn: ou=id,ou=hosts,dc=example,dc=com
When I perform a ldapsearch against our current Sun DSEE environment (with the same layout) I see the following:
ldapsearch -x -h ldap.example.com -b example.com objectclass=organizationalUnit 1 -LLL
dn: ou=people,dc=example,dc=com dn: ou=ftp,dc=example,dc=com dn: ou=groups,dc=example,dc=com dn: ou=hosts,dc=example,dc=com dn: ou=us,ou=people,dc=example,dc=com dn: ou=bd,ou=people,dc=example,dc=com dn: ou=id,ou=people,dc=example,dc=com dn: ou=users,ou=ftp,dc=example,dc=com dn: ou=groups,ou=ftp,dc=example,dc=com dn: ou=us,ou=groups,dc=example,dc=com dn: ou=bd,ou=groups,dc=example,dc=com dn: ou=id,ou=groups,dc=example,dc=com dn: ou=us,ou=hosts,dc=example,dc=com dn: ou=bd,ou=hosts,dc=example,dc=com dn: ou=id,ou=hosts,dc=example,dc=com
When I perform the same search against OpenLDAP, I get the following:
dn: ou=ftp,dc=example,dc=com dn: ou=hosts,dc=example,dc=com dn: ou=us,ou=people,dc=example,dc=com dn: ou=bd,ou=people,dc=example,dc=com dn: ou=id,ou=people,dc=example,dc=com dn: ou=users,ou=ftp,dc=example,dc=com dn: ou=groups,ou=ftp,dc=example,dc=com dn: ou=us,ou=groups,dc=example,dc=com dn: ou=bd,ou=groups,dc=example,dc=com dn: ou=id,ou=groups,dc=example,dc=com dn: ou=us,ou=hosts,dc=example,dc=com dn: ou=bd,ou=hosts,dc=example,dc=com dn: ou=id,ou=hosts,dc=example,dc=com
Notice the destinct lack of ou=people,dc=example,dc=com and ou=groups,dc=example,dc=com.
I know they're there, because I can create objects etc in them, but I'm at a complete loss as to why they don't show up in the ldapsearch.
I know I'm obviously doing something stupid here, and again, I apologize, but any assistance would be appreciated.
Thanks.
Adam writes:
(...) ldapsearch -x -h ldap.example.com -b example.com objectclass=organizationalUnit 1 -LLL
If that command gave the results you show, it's not OpenLDAP ldapsearch. example.com is not a valid DN, it should be -b dc=example,dc=com.
Also the command asks for attributes "1" and "-LLL" to be returned. Put options before the filter. Also the standard way to ask for no attrs to be returned is "1.1", not "1". It's a guaranteed unused OID (object identifier), and OIDs always have at least 2 components.
When I perform the same search against OpenLDAP, I get the following: (...) Notice the destinct lack of ou=people,dc=example,dc=com and ou=groups,dc=example,dc=com.
I know they're there, because I can create objects etc in them, but I'm at a complete loss as to why they don't show up in the ldapsearch.
Maybe your config has access controls which hides them.
Or maybe these actually do not have objectClass: organizationalUnit. Try the True filter "(&)" instead: ldapsearch -x -LL -h ldap.example.com -s base -b cn=people,dc=example,dc=com "(&)" objectClass
Or maybe you edited the slapd.conf to add an objectClass index after loading a few entries? Then the already-added objects would not get indexed. If so, stop slapd, run slapindex and restart slapd. (OTOH if you use slapd.d/cn=config and modify the cn=config over the LDAP protocol, such reindexing happens automatically.)
Or if the tree is really large and you have not indexed objectclass, maybe the search hit a time limit and didn't return everything. Then there should be an error message at the end of the ldapsearch output.
I know I'm obviously doing something stupid here, and again, I apologize, but any assistance would be appreciated.
Hey, relax. And show us your config, after deleting any passwords, if this doesn't help. It's hard to diagnose without guessing otherwise. Also show the exact command you used, and whether it said success or something else.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
See, I told you it would be something stupid.
Thanks for the suggestions.
After going through my ACLs I noticied I'd forgotten to include a break on a couple of them.
Thanks again for the help.
Cheers,
- -- - ----------------------- Adam Nye Spoon Technologies PO Box 608 Mylor 5153 SA - -----------------------
On 18/08/13 01:16, Hallvard Breien Furuseth wrote:
Adam writes:
(...) ldapsearch -x -h ldap.example.com -b example.com objectclass=organizationalUnit 1 -LLL
If that command gave the results you show, it's not OpenLDAP ldapsearch. example.com is not a valid DN, it should be -b dc=example,dc=com.
Also the command asks for attributes "1" and "-LLL" to be returned. Put options before the filter. Also the standard way to ask for no attrs to be returned is "1.1", not "1". It's a guaranteed unused OID (object identifier), and OIDs always have at least 2 components.
When I perform the same search against OpenLDAP, I get the following: (...) Notice the destinct lack of ou=people,dc=example,dc=com and ou=groups,dc=example,dc=com.
I know they're there, because I can create objects etc in them, but I'm at a complete loss as to why they don't show up in the ldapsearch.
Maybe your config has access controls which hides them.
Or maybe these actually do not have objectClass: organizationalUnit. Try the True filter "(&)" instead: ldapsearch -x -LL -h ldap.example.com -s base -b cn=people,dc=example,dc=com "(&)" objectClass
Or maybe you edited the slapd.conf to add an objectClass index after loading a few entries? Then the already-added objects would not get indexed. If so, stop slapd, run slapindex and restart slapd. (OTOH if you use slapd.d/cn=config and modify the cn=config over the LDAP protocol, such reindexing happens automatically.)
Or if the tree is really large and you have not indexed objectclass, maybe the search hit a time limit and didn't return everything. Then there should be an error message at the end of the ldapsearch output.
I know I'm obviously doing something stupid here, and again, I apologize, but any assistance would be appreciated.
Hey, relax. And show us your config, after deleting any passwords, if this doesn't help. It's hard to diagnose without guessing otherwise. Also show the exact command you used, and whether it said success or something else.
openldap-technical@openldap.org
-
Adam -
Hallvard Breien Furuseth