Hi,
I have an issue that just started a few days ago where when I search our LDAP for the field employeeNumber a number of my accounts will come back as not found even though they are in there, I can search by the uid and find the person and looking at the record the employeeNumber is exactly what I was searching for.
I can however do a search for (employeeNumber=*000111222) and find the employee where a search for (employeeNumber=000111222) will not find anything. On other accounts the search returns the expected result.
Comparing 2 accounts, one that works as expected and one that doesn't both and an employeeNumber field and both are set to a text value of 9 characters.
Thanks, -- Matt Brown Information Technology System Specialist V Eastern Washington University
--On Monday, November 20, 2006 10:55 AM -0800 Matt Brown mbrown@mail.ewu.edu wrote:
Hi,
I have an issue that just started a few days ago where when I search our LDAP for the field employeeNumber a number of my accounts will come back as not found even though they are in there, I can search by the uid and find the person and looking at the record the employeeNumber is exactly what I was searching for.
I can however do a search for (employeeNumber=*000111222) and find the employee where a search for (employeeNumber=000111222) will not find anything. On other accounts the search returns the expected result.
Comparing 2 accounts, one that works as expected and one that doesn't both and an employeeNumber field and both are set to a text value of 9 characters.
Did you at one point not have an index for that attribute, and then later add one? If so, it is possible that the database was not reindexed (via the slapindex command while slapd is shut offf) once it was added.
However, what would be most useful now is more information --
What version of OpenLDAP? What OpenLDAP database type are you using? (ldbm, hdb, bdb) What database store software are you using?
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Nov 20, 2006, at 10:55 AM, Matt Brown wrote:
I have an issue that just started a few days ago where when I search our LDAP for the field employeeNumber a number of my accounts will come back as not found even though they are in there, I can search by the uid and find the person and looking at the record the employeeNumber is exactly what I was searching for.
I can however do a search for (employeeNumber=*000111222) and find the employee where a search for (employeeNumber=000111222) will not find anything. On other accounts the search returns the expected result.
If it would be reasonably convenient to build a new directory somewhere, from a slapcat of the current one, I would do that and see if the new directory is any better.
Donn Cave, donn@u.washington.edu
--On Monday, November 20, 2006 11:23 AM -0800 Donn Cave donn@u.washington.edu wrote:
On Nov 20, 2006, at 10:55 AM, Matt Brown wrote:
I have an issue that just started a few days ago where when I search our LDAP for the field employeeNumber a number of my accounts will come back as not found even though they are in there, I can search by the uid and find the person and looking at the record the employeeNumber is exactly what I was searching for.
I can however do a search for (employeeNumber=*000111222) and find the employee where a search for (employeeNumber=000111222) will not find anything. On other accounts the search returns the expected result.
If it would be reasonably convenient to build a new directory somewhere, from a slapcat of the current one, I would do that and see if the new directory is any better.
I honestly think that advice is a little premature without more detail on what versions of software is being run, what database bits are being used, and whether or not the thing had an index added without the database being indexed....
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Nov 20, 2006, at 11:30 AM, Quanah Gibson-Mount wrote:
--On Monday, November 20, 2006 11:23 AM -0800 Donn Cave donn@u.washington.edu wrote:
On Nov 20, 2006, at 10:55 AM, Matt Brown wrote:
I have an issue that just started a few days ago where when I search our LDAP for the field employeeNumber a number of my accounts will come back as not found even though they are in there, I can search by the uid and find the person and looking at the record the employeeNumber is exactly what I was searching for.
I can however do a search for (employeeNumber=*000111222) and find the employee where a search for (employeeNumber=000111222) will not find anything. On other accounts the search returns the expected result.
If it would be reasonably convenient to build a new directory somewhere, from a slapcat of the current one, I would do that and see if the new directory is any better.
I honestly think that advice is a little premature without more detail on what versions of software is being run, what database bits are being used, and whether or not the thing had an index added without the database being indexed....
OK, Matt - cancel that, don't do it until Quanah gives you the go-ahead!
Donn Cave, donn@u.washington.edu
--On Monday, November 20, 2006 11:38 AM -0800 Donn Cave donn@u.washington.edu wrote:
I honestly think that advice is a little premature without more
detail on what versions of software is being run, what database bits are being used, and whether or not the thing had an index added without the database being indexed....
OK, Matt - cancel that, don't do it until Quanah gives you the go-ahead!
Very funny... My point is just more that building and loading a new server, doesn't tell you a whole lot if the problem is fixed, because then you still don't know why it occurred in the first place. And, without knowing the version of OpenLDAP, if it was a bug in an older version, and the same old version is used, that won't get one anywhere... Or if LDBM is being used, which its myriad of problems, building a new ldbm-based DB isn't all that great, either. ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
I restarted the LDAP service and now it's working fine. Very strange problem though.
We are running OpenLDAP 2.2.17
Our LDAP guy just quit and I'm trying to pickup where he left off, although I'm really have very little experience with OpenLDAP.
Thanks, -- Matt Brown Information Technology System Specialist V Eastern Washington University
--On Monday, November 20, 2006 1:54 PM -0800 Matt Brown mbrown@mail.ewu.edu wrote:
I restarted the LDAP service and now it's working fine. Very strange problem though.
We are running OpenLDAP 2.2.17
Our LDAP guy just quit and I'm trying to pickup where he left off, although I'm really have very little experience with OpenLDAP.
Well, I'll note a few things:
(a) 2.2.17 is extremely old (b) There are a number of DoS vulnerabilities that can be triggered in that old of a release, some with just a very trivial ldapsearch (c) It'd still be useful to know what database backend is being used
I'd certainly advise upgrading, but you'll want to set up another system to do that, and go through the steps, there were some configuration changes between 2.2 and 2.3, and you'll need to dump the db via slapcat, and reload via slapadd on the new server, as the way the data is stored changed as well.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
openldap-software@openldap.org
-
Donn Cave -
Matt Brown -
Quanah Gibson-Mount