389-ds-base

#49393 When replica is not named `cn=replica`, agreements don't come up after server restart
Closed: wontfix by spichugi. Opened by misko.

Closed: wontfix
Reopen Issue

Issue Description

If a replica is not named cn=config, agreements don't come up after server restart.

Package Version and Platform

Ubuntu 16.04
389-ds 1.3.7.5

Steps to reproduce

1) setup two ldap servers, create dc=example,dc=com
2) setup replica manager DN on both

# kokot, config
dn: cn=kokot,cn=config
cn: kokot
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
sn: kokot
userPassword:: e1NTSEE1MTJ9ajY3MFVUVURPMGFQZjhrQWRFT2d4M25VQTBXL2piYnM4YTVXZ09
 4NnMvdEJReWcyNE9uUFk3SENLNWR0a20wSGZBVVRhRDBaMGNFS0NvYkFPRnRYY05HV0dVZSs5Y01C

3) setup changelog on both

# changelog5, config
dn: cn=changelog5,cn=config
nsslapd-changelogmaxage: 10d
objectClass: extensibleObject
objectClass: top
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap-master01/changelogdb
cn: changelog5

4) setup a nsds5replica object named dn: cn=velmivelkaklobasovina,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config on both:

# velmivelkaklobasovina, dc\3Dexample\2Cdc\3Dcom, mapping tree, config
dn: cn=velmivelkaklobasovina,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=con
 fig
nsDS5Flags: 1
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaBindDN: cn=kokot,cn=config
nsDS5ReplicaType: 3
objectClass: extensibleObject
objectClass: nsds5replica
objectClass: top
nsDS5ReplicaId: 45569
cn: velmivelkaklobasovina

5) create agreement on ldap-master01

# rw-to-ldap-master02.sandbox.in.pan-net.eu, velmivelkaklobasovina, dc\3Dexampl
 e\2Cdc\3Dcom, mapping tree, config
dn: cn=rw-to-ldap-master02.sandbox.in.pan-net.eu,cn=velmivelkaklobasovina,cn=d
 c\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaUpdateSchedule: 0001-2359 0123456
description: rw agreement between ldap-master01.sandbox.in.pan-net.eu and ldap
 -master02.sandbox.in.pan-net.eu
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaPort: 389
objectClass: nsds5replicationagreement
objectClass: top
nsDS5ReplicaBindDN: cn=kokot,cn=config
nsDS5ReplicaHost: ldap-master02.sandbox.in.pan-net.eu
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE authorityRevocationLis
 t
nsDS5ReplicaBindMethod: SIMPLE
cn: rw-to-ldap-master02.sandbox.in.pan-net.eu
nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
 RERBNEJDUTFNbU5tTVRrNVlpMDBPRGc1TXpjMA0KTmkxaE5UazFaVFV5WmkxalpqUTFPVEJrTWdBQ
 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRHJEVHpMRmlUVk93di
 thQ3VVV0VQcA==}ZjrhH1Ud9xL0HrQk5bqw7A==
nsDS5BeginReplicaRefresh: start

6) create agreement on ldap-master02:

# rw-to-ldap-master01.sandbox.in.pan-net.eu, velmivelkaklobasovina, dc\3Dexampl
 e\2Cdc\3Dcom, mapping tree, config
dn: cn=rw-to-ldap-master01.sandbox.in.pan-net.eu,cn=velmivelkaklobasovina,cn=d
 c\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
nsDS5ReplicaUpdateSchedule: 0001-2359 0123456
description: Agreement between ldap-master02.sandbox.in.pan-net.eu and ldap-ma
 ster01.sandbox.in.pan-net.eu
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaPort: 389
objectClass: nsds5replicationagreement
objectClass: top
nsDS5ReplicaBindDN: cn=kokot,cn=config
nsDS5ReplicaHost: ldap-master01.sandbox.in.pan-net.eu
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE authorityRevocationLis
 t
nsDS5ReplicaBindMethod: SIMPLE
cn: rw-to-ldap-master01.sandbox.in.pan-net.eu
nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG
 RERBNEJDUXdOalpqTUdZMk1DMDNOemhtTTJNNQ0KWkMxaVlUY3hORFJoWkMwd1pqQTFOek13WlFBQ
 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQ0J0MnlvY0hJeGZTVn
 pvcEthOHJ3VA==}jQcKTvqE8sjte54DG21qQQ==
nsds5replicaUpdateInProgress: FALSE

7) test the replication - works

8) 

ldap-master01# service dirsrv@ldap-master01 restart

... wait

9) test the replication: broken

Actual results

Agreement status after server restart:

nsds5replicaLastUpdateStatus: Error (6) Replication error acquiring replica: Unable to acquire replica: there is no replicated area on the consumer server. Replication is aborting. (no such replica)

Expected results

If replica is named cn=replica, then replication works after restart.

8:42 <@wibrown> That name shouldn't matter :)

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 1.4 backlog

The bug may be that the replica worked in the first place, not that we disallow the name. A mapping tree can only have one cn=replica attached to it, so the uniqueness constraint of cn=replica is a valid construct for this.

I suspect that the issue is that we check for oc=nsds5replica rather than (&(cn=replica)(oc=nsds5replica)).

I think that @lkrispen would have a better understanding of this, and may have some input.

PS: I misunderstood the original issue, so the name does matter,

Metadata Update from @firstyear:
- Issue set to the milestone: None (was: 1.4 backlog)

Metadata Update from @mreynolds:
- Issue set to the milestone: 1.4 backlog

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2452

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.