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