Quanah Gibson-Mount wrote:
--On Tuesday, October 03, 2006 3:11 PM -0400 Robert Petkus rpetkus@bnl.gov wrote:
Folks, We had a major meltdown of LDAP this morning. I understood why, but the problem was restoring the database. slapcat, no matter how invoked, would simply not dump the full contents of the database. I needed to do a ldapsearch -L. This one doesn't make sense to me -- any ideas?? openldap-2.3.24 db4-4.2.52
Hard to say without knowing how your configuration is, for example, if you have multiple databases configured. You also don't say how the database melted down, which make give some helpful clues.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
I hate making these things long because folks lose interest and stop reading but my environment is complex so:
Along with the main database, I am also using monitor and accesslog. Recently I began storing ssh public keys in LDAP for use with ssh-lpk. This past weekend ~15k accounts were added to LDAP and maybe 700 ssh keys (I manage LDAP not account management..). Replication failed on 2 nodes. I noticed on these nodes incoherency because I was using an outdated custom schema file (my fault) so I decided to wipe the database and reload it from backup. Not a big deal but I notice that my nightly slapcat ldifs (slapcat -n 2 -l ldap.ldif) are polluted with accesslog entries that *replace* the original entries. For example, my account dn won't include, say, sshPublicKey, but I'd see a reqMod entry with this attribute.
I can see every dn with a ldapsearch but am missing many dns using slapcat. Obversely, when I do slapcat, I get dn attributes from accesslog that I can't see with ldapsearch. It looks like some weird cross-pollination of the 2 databases.
Maybe there is something I am missing in my config. Here is a snippet -- the full config is available upon request.
Thanks!