Description of problem: Given an LDIF that looks like the following (and assuming the databases and suffixes have already been setup): ==== dn: cn=replica,cn="dc=my,dc=net",cn=mapping tree,cn=config objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot: dc=my,dc=net nsds5replicaid: 12345 nsds5replicatype: 3 nsds5flags: 1 nsds5ReplicaPurgeDelay: 1036800 nsds5ReplicaBindDN: cn=replication manager,cn=config dn: cn=replica,cn="ou=other1,dc=my,dc=net",cn=mapping tree,cn=config objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot: ou=other1,dc=my,dc=net nsds5replicaid: 12345 nsds5replicatype: 3 nsds5flags: 1 nsds5ReplicaPurgeDelay: 1036800 nsds5ReplicaBindDN: cn=replication manager,cn=config dn: cn=replica,cn="ou=other2,dc=my,dc=net",cn=mapping tree,cn=config objectclass: top objectclass: nsds5replica objectclass: extensibleObject cn: replica nsds5replicaroot: ou=other2,dc=my,dc=net nsds5replicaid: 12345 nsds5replicatype: 3 nsds5flags: 1 nsds5ReplicaPurgeDelay: 1036800 nsds5ReplicaBindDN: cn=replication manager,cn=config === When added to dse.ldif via a ConfigFile line item in an install .inf file passed to setup-ds-admin.pl, the nsDS5ReplicaName attribute is not automatically added to the object correctly. Instead, it is added as "nsDS5ReplicaName: #" which causes the following errors in the logfile, after restarting the dirsrv service: === [03/Feb/2010:21:39:23 +0000] - CentOS-Directory/8.1.0 B2009.134.1334 starting up [03/Feb/2010:21:39:23 +0000] NSMMReplicationPlugin - replica_add_by_name: replica with name (#) already in the hash [03/Feb/2010:21:39:23 +0000] NSMMReplicationPlugin - replica_add_by_name: replica with name (#) already in the hash [03/Feb/2010:21:39:23 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests ==== This causes replication to break for the latter two replicas mentioned in dse.ldif. Note that replication does function correctly until the restart occurs. When the same LDIF is added via the ldapmodify tool, the nsds5ReplicaName attribute is added automatically and correctly as "nsDS5ReplicaName: d8928023-111111df-926aa9c0-50c96a32" and replication continues as expected with no errors in the log. Version-Release number of selected component (if applicable): CentOS-Directory/8.1.0 B2009.134.1334 How reproducible: Always Steps to Reproduce: 1. Create replicas for multiple databases/OU's via setup-ds-admin using an LDIF passed in via a ConfigFile statement 2. Restart dirsrv 3. Check logs and replication Actual results: Replication is disabled for several replicas Expected results: Replication functions for replicas Additional info: When running setup-ds-admin.pl with debug enabled, I can see that the ldif file to create the replicas is being called and added after the database, suffix and replication manager ldifs are run to create those objects. However, the actual OU entries have not been created yet. I took this into account when doing tests to reproduce this issue and things works (eg: ReplicaName was added correctly) but thought this might be useful additional information.
Created attachment 404253 [details] 0001-Bug-561575-setup-ds-admin-fails-to-supply-nsds5Rep.patch
Pushing to ssh://git.fedorahosted.org/git/389/ds.git 322cb3e..df5b545 Directory_Server_8_2_Branch -> Directory_Server_8_2_Branch f232bda..4b520bf master -> master commit df5b545c13720de2b9996d8dc0cb1babc936bea7 Author: Rich Megginson <rmeggins> Date: Fri Apr 2 17:38:57 2010 -0600 Reviewed by: nhosoi (Thanks!) Branch: Directory_Server_8_2_Branch Fix Description: The main problem was that the mod val was a berval, so we needed |LDAP_MOD_BVALUES for the mod_op. The other problem is that the mod and values were being used out of scope. While this seems to work, it better to make sure all of the values are in scope. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no (cherry picked from commit 4b520bfed95c10ecf9239f7a42f3fb38b673d203) commit 4b520bfed95c10ecf9239f7a42f3fb38b673d203 Author: Rich Megginson <rmeggins> Date: Fri Apr 2 17:38:57 2010 -0600 Branch: HEAD