(ITS#6006) slapcat data invalid when using glued dbs

[quanah@OpenLDAP.org]

Full_Name: Quanah Gibson-Mount
Version: 2.4.15
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.29.239)


In looking at moving to 2.4 from 2.3, I was examining how glue entries are
handled (particularly since my databases are rooted at "", and thus always
glued).  In particular, I'm looking at using cn=config, and of course, setting
up replication.  In 2.3 I used slapd.conf, so enabling replication was always an
offline process.  For 2.4 with cn=config, my goal is to specifically limit how
often people have to restart the server.  With that in mind...

(a) In 2.4, if you enable replication via cn=config, the glue entry does not
exist in the slapcat output until after the server has been stopped/started. 
While this doesn't break anything (the data you get from slapcat can be used on
a replica), it also isn't particularly consistent.

(b) In 2.4 (after restarting), the glue entry data from slapcat simply looks
like:

dn:
contextCSN: 20090306030736.912707Z#000000#000#000000

while in 2.3, it looks like:

dn:
objectClass: glue
structuralObjectClass: glue
contextCSN: 20060825091501Z#000000#00#000000
entryCSN: 20060825091501Z#000000#00#000000
modifiersName: uid=zimbra,cn=admins,cn=zimbra
modifyTimestamp: 20060825091501Z
entryUUID: 956a60ba-c8a6-102a-86ac-5d3a048562c0
creatorsName: uid=zimbra,cn=admins,cn=zimbra
createTimestamp: 20060825165749Z


I.e., in 2.3 it is a real entry, while in 2.4, it does not appear to be a real
entry at all.

The major problem with this, of course, is that this is invalid LDIF, and cannot
be loaded by slapadd:

[zimbra@freelancer tmp]$ /opt/zimbra/openldap/sbin/slapadd -F
/opt/zimbra/data/ldap/config -b "" -l ldap.bak.2
slapadd: dn="" (line=1): no objectClass attribute
_                       0.09% eta   none elapsed            none spd 203.7 k/s
Closing DB...

Which of course is a major problem, since I should be able to restore my DB as
exported by slapcat.

--Quanah