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

[subbarao@computer.org]

It works now, thanks.

	-Kartik

Jong wrote:
> 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) (68.39.64.142)
>>
>>
>>The OpenLDAP 2.2 Administrator's guide recommends setting the updatedn in
> 
> a
> 
>>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
> 
> the
> 
>>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
> 
> up),
> 
>>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
> 
> (It
> 
>>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
> 
> the
> 
>>rootdn.
>>
>>
> 
> 
>