Hi,
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1. The upgrade worked without any itches except for one thing - it seems I can't search for the attribute uidNumber anymore. I've had a look at my schema files but they didn't contain a definition for uidNumber, so after reading I found out this is a builtin attribute. So here's what happens:
this works without problems: ldapsearch -D cn=admin,dc=wogri,dc=at -b dc=wogri,dc=at -h ldap.wogri.at '(&(uid=user))' -W -x
this results - amongst others in:
dn: uid=user,ou=People,o=myOrg,dc=wogri,dc=at gidNumber: 100 uidNumber: 1000 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount gecos: Wolfgang Hennerbichler uid: user
but this search, which should bring the same result doesn't work: ldapsearch -D cn=admin,dc=wogri,dc=at -b dc=wogri,dc=at -h ldap.wogri.at '(&(uidNumber=1000))' -W -x
# search result search: 2 result: 0 Success
Using my LDAP-Browser I found out that the schema definition for uidNumber looks like this: OID: 1.3.6.1.1.1.1.0 Syntax: 1.3.6.1.4.1.1466.115.121.1.27 Equality: integerMatch
I don't quite get this (as I also don't see why it shouldn't work), unfortunately this breaks more or less my whole setup, so I'd be very thankful for an answer!
wogri
Wolfgang Hennerbichler writes:
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1.
You didn't mention the old OpenLDAP version, but: Maybe that implies an OpenLDAP version change too, which may mean you need to rebuild your database: Take down slapd. sbin/slapcat > old.ldif to save the old datbase. Move away the files in the database directory except DB_CONFIG. (Don't delete them yet in case something goes wrong.) sbin/slapadd < old.ldif to rebuild.
Actually you might need to slapcat with your old version, but hopefully not.
Wolfgang Hennerbichler wrote:
Hi,
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1. The upgrade worked without any itches except for one thing - it seems I can't search for the attribute uidNumber anymore. I've had a look at my schema files but they didn't contain a definition for uidNumber, so after reading I found out this is a builtin attribute. So here's what happens:
this works without problems: ldapsearch -D cn=admin,dc=wogri,dc=at -b dc=wogri,dc=at -h ldap.wogri.at '(&(uid=user))' -W -x
this results - amongst others in:
dn: uid=user,ou=People,o=myOrg,dc=wogri,dc=at gidNumber: 100 uidNumber: 1000 objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount gecos: Wolfgang Hennerbichler uid: user
but this search, which should bring the same result doesn't work: ldapsearch -D cn=admin,dc=wogri,dc=at -b dc=wogri,dc=at -h ldap.wogri.at '(&(uidNumber=1000))' -W -x
# search result search: 2 result: 0 Success
Using my LDAP-Browser I found out that the schema definition for uidNumber looks like this: OID: 1.3.6.1.1.1.1.0 Syntax: 1.3.6.1.4.1.1466.115.121.1.27 Equality: integerMatch
I don't quite get this (as I also don't see why it shouldn't work), unfortunately this breaks more or less my whole setup, so I'd be very thankful for an answer!
If uidNumber is indexed, try running slapindex (after stopping slapd).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Wolfgang Hennerbichler wrote:
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1. The upgrade worked without any itches except for one thing - it seems I can't search for the attribute uidNumber anymore.
1. 2.4.11 is quite old. I'd recommend to use a more recent release.
2. Not sure what your upgrade path was. uidNumber is indexed? So I'd suggest to stop slapd and re-index the whole database since the index format was modified.
I've had a look at my schema files but they didn't contain a definition for uidNumber, so after reading I found out this is a builtin attribute.
You should query the subschema subentry for finding out which schema elements are actually there.
Ciao, Michael.
On 05.03.2009, at 13:51, Michael Ströder wrote:
Wolfgang Hennerbichler wrote:
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1. The upgrade worked without any itches except for one thing - it seems I can't search for the attribute uidNumber anymore.
- 2.4.11 is quite old. I'd recommend to use a more recent release.
I like to stick to debian stable, automatic security fixes are important for me. I'm not the compile-it-yourself guy.
- Not sure what your upgrade path was. uidNumber is indexed? So I'd
suggest to stop slapd and re-index the whole database since the index format was modified.
thanks, as stated in my other e-mails this was the answer I was looking for, I didn't know about this (and didn't think of it).
I've had a look at my schema files but they didn't contain a definition for uidNumber, so after reading I found out this is a builtin attribute.
You should query the subschema subentry for finding out which schema elements are actually there.
thanks, wolfgang
Ciao, Michael.
Wolfgang Hennerbichler wrote:
On 05.03.2009, at 13:51, Michael Ströder wrote:
Wolfgang Hennerbichler wrote:
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1. The upgrade worked without any itches except for one thing - it seems I can't search for the attribute uidNumber anymore.
- 2.4.11 is quite old. I'd recommend to use a more recent release.
I like to stick to debian stable, automatic security fixes are important for me. I'm not the compile-it-yourself guy.
Whatever the definition of "stable" is...
This has been discussed before. See also: http://www.openldap.org/faq/data/cache/1456.html
Ciao, Michael.
Wolfgang Hennerbichler wrote:
On 05.03.2009, at 13:51, Michael Ströder wrote:
Wolfgang Hennerbichler wrote:
Sorry if this question has been asked before (but I have looked through the archives and didn't find anything). After upgrading from debian etch to lenny, I'm running the slapd version 2.4.11-1. The upgrade worked without any itches except for one thing - it seems I can't search for the attribute uidNumber anymore.
- 2.4.11 is quite old. I'd recommend to use a more recent release.
I like to stick to debian stable, automatic security fixes are important for me. I'm not the compile-it-yourself guy.
- Not sure what your upgrade path was. uidNumber is indexed? So I'd
suggest to stop slapd and re-index the whole database since the index format was modified.
thanks, as stated in my other e-mails this was the answer I was looking for, I didn't know about this (and didn't think of it).
Note that when changing between minor versions it is usually required to slapcat/slapadd the database, as binary compatibility is not guaranteed. In the case of OpenLDAP 2.3/2.4, as far as I recall, no database changes occurred. However, there were minor changes (significantly, support for indexing on more matching rules for more syntaxes) which required to rebuild the indexes.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
--On Thursday, March 05, 2009 5:29 PM +0100 Pierangelo Masarati ando@sys-net.it wrote:
thanks, as stated in my other e-mails this was the answer I was looking for, I didn't know about this (and didn't think of it).
Note that when changing between minor versions it is usually required to slapcat/slapadd the database, as binary compatibility is not guaranteed. In the case of OpenLDAP 2.3/2.4, as far as I recall, no database changes occurred. However, there were minor changes (significantly, support for indexing on more matching rules for more syntaxes) which required to rebuild the indexes.
The Debian upgrade process slapcat/slapadd's the DB on upgrade, so that should have already been done if the debian upgrade steps were followed.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, March 05, 2009 5:29 PM +0100 Pierangelo Masarati ando@sys-net.it wrote:
thanks, as stated in my other e-mails this was the answer I was looking for, I didn't know about this (and didn't think of it).
Note that when changing between minor versions it is usually required to slapcat/slapadd the database, as binary compatibility is not guaranteed. In the case of OpenLDAP 2.3/2.4, as far as I recall, no database changes occurred. However, there were minor changes (significantly, support for indexing on more matching rules for more syntaxes) which required to rebuild the indexes.
The Debian upgrade process slapcat/slapadd's the DB on upgrade,
wow!
so that should have already been done if the debian upgrade steps were followed.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
openldap-software@openldap.org