Bug 819111

Summary:	non-existent container ou=cmsusers breaks replication
Product:	Red Hat Enterprise Linux 6	Reporter:	Ade Lee <alee>
Component:	pki-core	Assignee:	Ade Lee <alee>
Status:	CLOSED NOTABUG	QA Contact:	IDM QE LIST <seceng-idm-qe-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.3	CC:	dpal, jgalipea, mharmsen, shaines, spoore
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	The following text was added to the problem description area of RHBA-2012:12464-01: * The CS replication code was recently changed so that the replication user was created in the container ou=csusers, cn=config., rather than directly under cn=config. This container may not exist in older updated servers, and for those servers, the replication user would not be created, and replication would not succeed. The replication setup code has been modified to create the ou=csusers container if it does not exist. (BZ#819111)	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-14 18:34:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ade Lee 2012-05-04 21:15:36 UTC

Description of problem:

Changes recently checked in https://www.redhat.com/archives/pki-devel/2012-March/msg00029.html  moved the replication user under the ou=cmusers,cn=config instead of just cn=config.  This works just fine when doing replication between two NEW servers.  On old updated servers though, this container does not exist - and so the attempt to create a replication user under that container fails.  As a result, setting up replication agreements with old updated servers fails.

There is a workaround, which is to manually create the container first.  But this is better fixed in code, by adding coding to create the ou if it does not exist when setting up the replication agreement.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Ade Lee 2012-05-04 21:18:51 UTC

Note: the effect of this bug is to break replication in IPA as described above.

Comment 3 Ade Lee 2012-05-08 18:03:58 UTC

Patch checked into dogtag 9, 10 and rhel 6.3

rhel 6.3 checkin:

commit e11f90c85738eebc1af16fc9180109df4cab9538
Author: Ade Lee <alee>
Date:   Tue May 8 13:38:44 2012 -0400

    Resolves #819111 - non-existent container ou=csusers breaks replication

Patch as below:

diff --git a/base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java b/base/common/src/com/
index bdd0b0d..8a26ce4 100644
--- a/base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
+++ b/base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
@@ -1210,7 +1210,27 @@ public class DatabasePanel extends WizardPanelBase {
       throws LDAPException {
         LDAPAttributeSet attrs = null;
         LDAPEntry entry = null;
-        String dn = "cn=" + bindUser + ",cn=config";
+
+        // for older subsystems, the container ou=csusers, cn=config may not yet exist
+        String dn = "ou=csusers, cn=config";
+        try {
+            attrs = new LDAPAttributeSet();
+            attrs.add(new LDAPAttribute("objectclass", "top"));
+            attrs.add(new LDAPAttribute("objectclass", "organizationalUnit"));
+            attrs.add(new LDAPAttribute("ou", "csusers"));
+            entry = new LDAPEntry(dn, attrs);
+            conn.add(entry);
+        } catch (LDAPException e) {
+            if (e.getLDAPResultCode() == LDAPException.ENTRY_ALREADY_EXISTS) {
+                CMS.debug("createReplicationManager: containing ou already exists");
+            } else {
+                CMS.debug("createReplicationManager: Failed to create containing ou. Exception: "
+                        + e.toString());
+                throw e;
+            }
+        }
+
+        dn = "cn=" + bindUser + ",ou=csusers,cn=config";
         try {
             attrs = new LDAPAttributeSet();
             attrs.add(new LDAPAttribute("objectclass", "top"));

Comment 5 Matthew Harmsen 2012-05-08 19:01:21 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The following text was added to the problem description area of RHBA-2012:12464-01:

* The CS replication code was recently changed so that the replication user was created in the container ou=csusers, cn=config., rather than directly under cn=config. This container may not exist in older updated servers, and for those servers, the replication user would not be created, and replication would not succeed. The replication setup code has been modified to create the ou=csusers container if it does not exist. (BZ#819111)

Comment 6 Scott Poore 2012-05-09 23:24:56 UTC

Just to confirm this wasn't fixed until 5/8/2012 in pki-core-9.0.3-25.el6?

This only affects RHEL IPA servers upgraded from 6.2 and earlier right?

How can I see the replication user?  

I tried this on a couple of new IPA RHEL 6.3 servers and can't find it:

ldapsearch -LLL -x -D "cn=Directory Manager" -w "$ROOTDNPWD" -b "ou=csusers, cn=config"

I also tried grepping ldapsearch of all of cn=config but, didn't find anything.

Comment 7 Ade Lee 2012-05-14 18:34:03 UTC

This fix is not needed because the ou=csusers change was not ported to the rhel branch.  It only exists in dogtag 9.

We will be reverting to the previous build in dogtag 9 -- pki-core-9.0.3-24