11:58 a.m.
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.
Greetings
Christian Kratzer
CK Software GmbH
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
3:25 p.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:09 a.m.
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
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Schwarzwaldstr. 31
Phone: +49 7452 889 135 D-71131 Jettingen
Fax: +49 7452 889 136 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
3:28 p.m.
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.
4934
days inactive
4935
days old
openldap-software@openldap.org
3 comments
3 participants
participants (3)
-
Christian Kratzer -
Howard Chu -
masaratiļ¼ aero.polimi.it