> Hi, > > we have a customer who runs an openldap installation with an empty suffix > as in > > suffix "" > > which is a potential problem when migrating to syncrepl as they do not > have > an entry to store the contextCSN. > > In our lab using openldap 2.4.19 we succeeded in inserting an entry with > an empty dn as follows: > > dn: > objectClass: organization > o: root > > This entry received the contextCSN entries and everything looks good > from what I can see: > > dn: > objectClass: organization > o: root > structuralObjectClass: organization > entryUUID: 6bd316a2-6f10-102e-904e-c754373eef36 > creatorsName: cn=Manager > createTimestamp: 20091126194832Z > entryCSN: 20091126194832.284443Z#000000#000#000000 > modifiersName: cn=Manager > modifyTimestamp: 20091126194832Z > contextCSN: 20091126194832.864794Z#000000#000#000000 > > I have no idea how ugly this hack is and am concerned this might break > with a future release when either searching for contextCSN below the > suffix > is perhaps supported again or entries with an empty dn break. > > I am about to advise the customer to move to a directory with an > nonempty suffix matching their root entry but would like to hear > nevertheless what you think of above.
Whatever you plan to do with empty DN as the context suffix of a replicated database, you should consider using 2.4.20 (about to be released) as it introduces explicit support for this case by moving the contextCSN in a subentry, in response to ITS#6373 <http://www.openldap.org/its?findid=6373>. p.
