[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#8465) ldapsearch & slapcat : different output



Full_Name: Norbert MASSA
Version: 2.4.40
OS: CentOS 7.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (62.240.254.57)


Hi everyone,

I'm struggling to find a root cause on a weird problem which recently happened
on one of our servers, let me give you some history :

- server installed beginning of April
- openldap 2.4.40 installed via packages
- client data loaded into ldap, no problem
- server had never been rebooted since

We have a script that (luckily, see why below) makes a backup every night, with
2 different commands :
- slapcat > file-slapcat.ldif
- ldapsearch -b "dc=our_root" -x -D "cn=admin,dc=our_root" -w password >
file-ldapsearch.ldif

So far so good, the application behind was running fine, users were added and
authentication was successful.

That's for the background.

Now, 3 days ago during night, there was a planned reboot of the server, and
after it came back, it appeared our LDAP server was missing lots and lots of
entries that should have been here since months. Even some passwords were "back
to their values weeks ago". Weird.

So let's have a look at the backups, that's where the fun stuff begins : it
appeared that the ldapsearch backups were always complete whereas the slapcat
ones never where ! It looked like slapcat was not seeing any other data than
what was added at the beginning.

The final solution was to perform a restore / import of the ldapsearch generated
file. 

So from a system perspective, it would appear the behavior was something like :
- new data was storred in "some kind of memory"
- slapcat, as it's reading the files on the drive, would not see it :-(
-dadapsearch, as it's using ldap protocol, would see it :-)
- after the reboot => everything was lost, slapcat & ldapsearch were seeing the
same (incomplete) data.

Is it something possible ? I was unable to find anything related on google, and
sadly have no idea how to reproduce

Thanks a lot,

Regards,

Norbert