[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: syncrepl root suffix issue when updatedn != rootdn (ITS#3056)

Fixed in HEAD. Please test.

----- Original Message ----- 
From: <subbarao@computer.org>
To: <openldap-its@OpenLDAP.org>
Sent: Sunday, April 04, 2004 3:42 PM
Subject: syncrepl root suffix issue when updatedn != rootdn (ITS#3056)

> Full_Name: Kartik Subbarao
> Version: 2.2
> OS: Red Hat Linux 7.3
> URL:
> Submission from: (NULL) (
> The OpenLDAP 2.2 Administrator's guide recommends setting the updatedn in
> syncrepl consumer to NOT be the same as the rootdn.
> =====
> The updatedn parameter specifies the DN in the consumer site which is
allowed to
> make changes to the replica. [...] The DN should have read/write access to
> replica database. Generally, this DN should not be the same as rootdn.
> =====
> However, when I do this, and try to initialize a consumer from scratch
(start it
> up with no data, and suck over all of the entries the first time it starts
> I find that the root suffix entry is not properly created on the consumer
> server. I get the following error in the consumer debug log:
> bdb_add: suffix denied
> This is due to the check that happens at line 301 in
> servers/slapd/back-bdb/add.c:
> if (( !be_isroot( op->o_bd, &op->o_ndn ) || pdn.bv_len > 0 )
>             && !is_entry_glue( op->oq_add.rs_e ))
> Since the updatedn is NOT the same as the rootdn, this condition triggers,
> causing the suffix entry not to be added properly as a structural object
> gets added later as a "glue" object which is not the desired behavior).
> It would appear that the code is out of sync with the intended design for
> syncrepl. I agree with the Administrator's guide that the updatedn should
NOT in
> general be the same as the rootdn.
> The workaround in the meantime is to set the updatedn to be the same as
> rootdn.