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.