Hello,
I am using OpenLDAP 2.4.9 on CentOS 5.1 (32 bit) with a custom schema and I have added ~7500 objects and I am not able to search successfully for these objects by uid. What must I do to be able to search for these objects by uid?
Sample object:
# 496user, People, example.com dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user@nest.tld mailid: 496user@nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S
If I search for this user by uid, I will get no results back:
# ldapsearch -xZZ -b "ou=people,dc=example,dc=com" uid=496user # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=496user # requesting: ALL #
# search result search: 3 result: 0 Success
# numResponses: 1
Searching by mailid does work:
# ldapsearch -xZZ -b "ou=people,dc=example,dc=com" mailid=496user@nest.tld ...<snip>... dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user@nest.tld mailid: 496user@nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S
# search result search: 3 result: 0 Success
# numResponses: 2 # numEntries: 1
The schema is as follows (downloaded from riseuplabs.org):
objectIdentifier OID 1.1 objectIdentifier ldapOID OID:2 objectIdentifier attributetypeOID ldapOID:1 objectIdentifier objectclassOID ldapOID:2
attributeType ( attributetypeOID:1 NAME 'mailAddress' DESC 'email address(es)' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
attributeType ( attributetypeOID:2 NAME 'maildrop' DESC 'Mail addresses where mail is delivered -- ie forwards' SUP mailAddress )
attributeType ( attributetypeOID:3 NAME 'mailid' DESC 'Mail addresses accepted by this account -- ie aliases' SUP mailAddress )
attributeType ( attributetypeOID:4 NAME 'mailquota' DESC 'Bytes of mail quota' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE )
attributetype ( attributetypeOID:5 NAME 'maildir' DESC 'where mail is stored' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE )
objectclass ( objectclassOID:1 NAME 'mailAccount' DESC 'users who receive mail' AUXILIARY MAY (maildrop $ mailid $ mailquota $ maildir) )
TIA, Josh Miller, RHCE
Hello,
I am using OpenLDAP 2.4.9 on CentOS 5.1 (32 bit) with a custom schema and I have added ~7500 objects and I am not able to search successfully for these objects by uid. What must I do to be able to search for these objects by uid?
Sample object:
# 496user, People, example.com dn: uid=496user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 496user@nest.tld mailid: 496user@nest.tld maildir: 496user/ userPassword:: secret mailquota: 35969216S
It looks like my issue deals with the uid not being defined as an attribute, although it is part of the DN. Is there any way to address these objects, rather than purging the directory and starting fresh? Modrdn maybe?
Thanks, Josh Miller, RHCE
It looks like my issue deals with the uid not being defined as an attribute, although it is part of the DN. Is there any way to address these objects, rather than purging the directory and starting fresh? Modrdn maybe?
N/m, I was able to use ldapmodify to address these objects, and now I am able to search by uid.
]# ldapmodify -xZZ -D "cn=manager,dc=example,dc=com" -W <<EOF
dn: uid=2user,ou=People,dc=example,dc=com changetype: modify add: uid uid: 2user EOF
Enter LDAP Password: modifying entry "uid=2user,ou=People,dc=example,dc=com"
# ldapsearch -xZZ -D "cn=manager,dc=example,dc=com" -W uid=2user Enter LDAP Password: ... # 2user, People, example.com dn: uid=2user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 2user@nest.tld mailid: 2user@nest.tld maildir: 2user/ userPassword:: e2NyeXB0fSQxJERCQS5wdmZYJHblah mailquota: 35969216S uid: 2user
# search result search: 3 result: 0 Success
# numResponses: 2 # numEntries: 1
woohoo! :)
Thanks, Josh Miller, RHCE
Did you add an index on uid after creating the database, and then forget to slapindex it?
--Quanah
--On June 12, 2008 10:25:21 AM -0700 joshua@itsecureadmin.com wrote:
It looks like my issue deals with the uid not being defined as an attribute, although it is part of the DN. Is there any way to address these objects, rather than purging the directory and starting fresh? Modrdn maybe?
N/m, I was able to use ldapmodify to address these objects, and now I am able to search by uid.
]# ldapmodify -xZZ -D "cn=manager,dc=example,dc=com" -W <<EOF
dn: uid=2user,ou=People,dc=example,dc=com changetype: modify add: uid uid: 2user EOF
Enter LDAP Password: modifying entry "uid=2user,ou=People,dc=example,dc=com"
# ldapsearch -xZZ -D "cn=manager,dc=example,dc=com" -W uid=2user Enter LDAP Password: ... # 2user, People, example.com dn: uid=2user,ou=People,dc=example,dc=com objectClass: mailAccount maildrop: 2user@nest.tld mailid: 2user@nest.tld maildir: 2user/ userPassword:: e2NyeXB0fSQxJERCQS5wdmZYJHblah mailquota: 35969216S uid: 2user
# search result search: 3 result: 0 Success
# numResponses: 2 # numEntries: 1
woohoo! :)
Thanks, Josh Miller, RHCE
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Did you add an index on uid after creating the database, and then forget to slapindex it?
No, the index on uid has been in effect since this db was created. I also re-ran slapindex on the database before posting to make sure without any success.
Is it a bug that no results were returned until the uid attribute was explicitly added?
Thanks, Josh Miller, RHCE
--On June 12, 2008 10:35:35 AM -0700 joshua@itsecureadmin.com wrote:
Did you add an index on uid after creating the database, and then forget to slapindex it?
No, the index on uid has been in effect since this db was created. I also re-ran slapindex on the database before posting to make sure without any success.
Is it a bug that no results were returned until the uid attribute was explicitly added?
Sounds like a bug to me. Can you reproduce this with OpenLDAP 2.4.10?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Did you add an index on uid after creating the database, and then forget to slapindex it?
No, the index on uid has been in effect since this db was created. I also re-ran slapindex on the database before posting to make sure without any success.
Is it a bug that no results were returned until the uid attribute was explicitly added?
Sounds like a bug to me. Can you reproduce this with OpenLDAP 2.4.10?
I will try to reproduce. It will take me a day or two.
Thanks, Josh Miller, RHCE
Quanah Gibson-Mount wrote:
--On June 12, 2008 10:35:35 AM -0700 joshua@itsecureadmin.com wrote:
Did you add an index on uid after creating the database, and then forget to slapindex it?
No, the index on uid has been in effect since this db was created. I also re-ran slapindex on the database before posting to make sure without any success.
Is it a bug that no results were returned until the uid attribute was explicitly added?
Sounds like a bug to me. Can you reproduce this with OpenLDAP 2.4.10?
No bug in search, at least. The uid attribute was not part of the entry until he explicitly added it with ldapmodify. Seems like he must have used slapadd to create the entries in the first place though, since ldapadd would not have created an entry without its RDN being present in the entry.
--On June 12, 2008 11:36:25 AM -0700 Howard Chu hyc@symas.com wrote:
No bug in search, at least. The uid attribute was not part of the entry until he explicitly added it with ldapmodify. Seems like he must have used slapadd to create the entries in the first place though, since ldapadd would not have created an entry without its RDN being present in the entry.
I thought OL was recently updated to allow entry creation without RDN values. I.e., wouldn't ldapadd silently add it (not complain), and I'd assume slapadd should do the same thing. Either way, it seems like a bug to me that the RDN value was not added to the entry (and thus the index), whatever method was used to create the entry.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Sounds like a bug to me. Can you reproduce this with OpenLDAP 2.4.10?
No bug in search, at least. The uid attribute was not part of the entry until he explicitly added it with ldapmodify. Seems like he must have used slapadd to create the entries in the first place though, since ldapadd would not have created an entry without its RDN being present in the entry.
The entries were created with slapadd.
Regards, -- Josh Miller, RHCE
--On June 12, 2008 10:35:35 AM -0700 joshua@itsecureadmin.com wrote:
Did you add an index on uid after creating the database, and then forget to slapindex it?
No, the index on uid has been in effect since this db was created. I also re-ran slapindex on the database before posting to make sure without any success.
Is it a bug that no results were returned until the uid attribute was explicitly added?
Sounds like a bug to me. Can you reproduce this with OpenLDAP 2.4.10?
I have successfully reproduced this behavior on OpenLDAP 2.4.10 using ldapadd to add the record without the uid attribute.
Please see the following txt document for details on add/query, etc. http://itsecureadmin.com/uid-test.txt
Thanks, -- Josh Miller, RHCE
--On June 13, 2008 8:47:50 AM -0700 Josh Miller joshua@itsecureadmin.com wrote:
Sounds like a bug to me. Can you reproduce this with OpenLDAP 2.4.10?
I have successfully reproduced this behavior on OpenLDAP 2.4.10 using ldapadd to add the record without the uid attribute.
Please see the following txt document for details on add/query, etc. http://itsecureadmin.com/uid-test.txt
Thanks!
Please file an ITS for this at http://www.openldap.org/its/
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Howard Chu -
Josh Miller -
joshua＠itsecureadmin.com
-
Quanah Gibson-Mount