Bug 561575

Summary: setup-ds-admin fails to supply nsds5ReplicaName when configuring via ConfigFile
Product: [Retired] 389 Reporter: nathan r. hruby <nhruby>
Component: Install/UninstallAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.1.0CC: jgalipea, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 16:57:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 434914, 543590    
Attachments:
Description Flags
0001-Bug-561575-setup-ds-admin-fails-to-supply-nsds5Rep.patch nhosoi: review+

Description nathan r. hruby 2010-02-03 23:17:45 UTC 
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.
Comment 2 Rich Megginson 2010-04-02 23:41:10 UTC 
Created attachment 404253 [details]
0001-Bug-561575-setup-ds-admin-fails-to-supply-nsds5Rep.patch
Comment 3 Rich Megginson 2010-04-05 14:12:23 UTC 
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