[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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.