Re: contextCSN with empty suffix

> 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.