Christian Kratzer wrote:

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.

Actually it's no problem at all.

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

syncrepl and back-bdb/hdb would have created this entry automatically anyway, if it was needed.

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.

There are some situations where this type of config may run into problems, but in most cases it works fine. For the rare problem cases, (e.g., using proxy syncrepl) an option has been introduced in 2.4.20 to allow the contextCSN to be stored in a dedicated subentry instead of in the suffix entry (See ITS#6373). But if you're not using proxy syncrepl, there's nothing to worry about.

Hi,

On Thu, 26 Nov 2009, Howard Chu wrote:

Christian Kratzer wrote:

...

Hi,

we have a customer who runs an openldap installation with an empty suffix as in

suffix ""

<snipp/>

There are some situations where this type of config may run into problems, but in most cases it works fine. For the rare problem cases, (e.g., using proxy syncrepl) an option has been introduced in 2.4.20 to allow the contextCSN to be stored in a dedicated subentry instead of in the suffix entry (See ITS#6373). But if you're not using proxy syncrepl, there's nothing to worry about.

thanks for the clarification. I will leave it up to them to decide if they want to clean up the otherwise unnessary empty suffix or just leave it as is.

Greetings Christian