I'm using OpenLDAP 2.4.31 which I locally compiled on RHEL 6.3 64-bit. Last night as part of the nightly update process, a slapcat of the main suffix. There were 312,576 dn's in this database, and the last 4,794 entries printed were written out with in the form: dn: objectClass: groupOfNames cn: COURSE-201209-92184 member: uid=notreal,ou=people,dc=uvm,dc=edu structuralObjectClass: groupOfNames entryUUID: 1ee49f30-245e-4804-9be9-9faf0bb7f0c5 creatorsName: cn=theboss,dc=uvm,dc=edu createTimestamp: 20120803002051Z entryCSN: 20120803002051.460963Z#000000#000#000000 modifiersName: cn=theboss,dc=uvm,dc=edu modifyTimestamp: 20120803002051Z which is (as far as I know) not valid. I believe there has to be a dn value (and this morning, slapcat's performed are showing dn's in the output). I am using back-hdb to store this database. This is on the master server which has 10 replicas pulling changes off it using delta-syncrepl. A quick search of the ITS system shows ITS#6365 which hasn't been updated since February 2010 that seems to indicate the same (though in that one it was completely consistent) issue with an hdb database and slapcat. Any ideas? I have never seen this happen before, but I did just move to both OpenLDAP 2.4.31 and RHEL6 (was previously running OpenLDAP 2.4.28 plus fixes on RHEL5u8 64-bit). -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)
Attachment:
signature.asc
Description: OpenPGP digital signature