RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 726785 - If replication fails while setting up a clone it will wait forever
Summary: If replication fails while setting up a clone it will wait forever
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pki-core
Version: 6.2
Hardware: All
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Ade Lee
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On: 683990
Blocks: 530474 688225
TreeView+ depends on / blocked
 
Reported: 2011-07-29 19:35 UTC by Ade Lee
Modified: 2015-01-04 23:50 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 683990
Environment:
Last Closed: 2011-12-06 16:29:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
patch to fix (5.34 KB, patch)
2011-08-04 17:33 UTC, Ade Lee
awnuk: review+
rmeggins: review+
Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1655 0 normal SHIPPED_LIVE pki-core bug fix and enhancement update 2011-12-06 00:50:24 UTC

Description Ade Lee 2011-07-29 19:35:47 UTC
+++ This bug was initially created as a clone of Bug #683990 +++

Description of problem:

I have been trying to set up replication in a clone to use TLS. Doing so during the initial set up requires care so your 389-ds instance comes pre-configured with a set of certificates.

If this is done incorrectly, such as not properly trusting the CA or not restarting 389-ds after configuring the NSS database and adding the SSL config, the initial replication setup will fail.

dogtag does not detect this failure, it just loops looking for the root to appear in the directory server, which it never will because replication is not working.

Rich Megginson says that the agreement status can be monitored to detect this kind of error.

Comment 1 Rich Megginson 2011-08-03 18:17:05 UTC
The attributes that can be used for this are described here:
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Configuration_and_Command-Line_Tool_Reference/Core_Server_Configuration_Reference.html#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig

The main ones are nsDS5ReplicaLastInitStatus and nsDS5ReplicaLastUpdateStatus.  The format is this

N <SPACE> String...

Where N is an integer - if 0, this means success, otherwise, usually an LDAP error code.  <SPACE> is a single space character.  String... is a character string with more information about the status.

Comment 2 Ade Lee 2011-08-04 17:33:23 UTC
Created attachment 516756 [details]
patch to fix

Comment 3 Ade Lee 2011-08-04 18:47:19 UTC
6.1:

[vakwetu@goofy-vm6 base]$ svn ci -m "Resolves #726785 - If replication fails
while setting up a clone it will wait forever" 
Sending       
base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
Transmitting file data .
Committed revision 2106.

tip:

[vakwetu@dhcp231-121 base]$  svn ci -m "Resolves #726785 - If replication fails
while setting up a clone it will wait forever"
Sending       
base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
Transmitting file data .
Committed revision 2107.

Comment 4 Ade Lee 2011-08-04 19:22:44 UTC
8.2:

[vakwetu@goofy-vm4 base]$ svn ci -m "Resolves #726785 - If replication fails while setting up a clone it will wait forever" 
Sending        base/common/src/com/netscape/cms/servlet/csadmin/DatabasePanel.java
Transmitting file data .
Committed revision 2108.

Comment 7 Kashyap Chamarthy 2011-11-11 09:21:22 UTC
VERIFIED.

Version Info:
============
[root@ratchet ~]# rpm -qa ipa-server
ipa-server-2.1.3-9.el6.x86_64
[root@ratchet ~]# 
[root@jetfire ~]# rpm -qa ipa-server
ipa-server-2.1.3-9.el6.x86_64
[root@jetfire ~]# 
============
[root@ratchet ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.2 Beta (Santiago)
[root@ratchet ~]# 
[root@jetfire ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.2 Beta (Santiago)
[root@jetfire ~]# 
============

Procedure:
----------
1] Setup Master IPA server
# ipa-server-install --setup-dns -N ; configure w/ DNS forwarder(same as local
IP)

2] Prepare replica info. on Master:
========
[root@jetfire ~]#  ipa-replica-prepare  jetfire.testrelm --ip-address 10.65.201.69
========

3] Copy the replica prepare file over to replica machine
========
[root@jetfire ~]# scp /var/lib/ipa/replica-info-ratchet.testrelm.gpg root.201.69:/var/lib/ipa/
========

4] Run the replica install command on the replica server(w/ forwarder as Master IP)
========
[root@ratchet ~]# ipa-replica-install --setup-dns
/var/lib/ipa/replica-info-ratchet.testrelm.gpg --forwarder
10.65.201.71
========

5] Now, let's mangle replicationdb(change it 'abcd' instead of orignial one)
========
[root@jetfire ~]# cat /var/lib/pki-ca/conf/password.conf 
internal=408873824911
internaldb=Secret123
replicationdb=abcd
[root@jetfire ~]# 
========

6] Restart IPA Master server
========
[root@jetfire ~]# ipactl restart
========

7] Now, let's create a clone of CA on replica. This should *FAIL* (as we mangled w/ Master replicationdb password)

[root@ratchet ~]# ipa-ca-install  /var/lib/ipa/replica-info-ratchet.testrelm.gpg 
Directory Manager (existing master) password: 

Run connection check to master
Check connection from replica to remote master 'jetfire.testrelm':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK
   PKI-CA: Directory Service port (7389): OK

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@TESTRELM password: 

Execute check on remote master
Check connection from master to remote replica 'ratchet.testrelm':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: port 80 (80): OK
   HTTP Server: port 443(https) (443): OK
   PKI-CA: Directory Service port (7389): OK

Connection from master to replica is OK.

Connection check OK
Configuring directory server for the CA: Estimated time 30 minutes 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
done configuring pkids.
Configuring certificate server: Estimated time 33 minutes 30 seconds
  [1/11]: creating certificate server user
  [2/11]: creating pki-ca instance
  [3/11]: configuring certificate server instance
root        : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' 'ratchet.testrelm' '-cs_port' '9445' '-client_certdb_dir' '/tmp/tmp-K0677k' '-client_certdb_pwd' XXXXXXXX '-preop_pin' 'fZynlmE3VHTQ82q0q2iE' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' 'root@localhost' '-admin_password' XXXXXXXX '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' '-agent_cert_subject' 'CN=ipa-ca-agent,O=TESTRELM' '-ldap_host' 'ratchet.testrelm' '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=TESTRELM' '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=TESTRELM' '-ca_server_cert_subject_name' 'CN=ratchet.testrelm,O=TESTRELM' '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=TESTRELM' '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=TESTRELM' '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' '-clone_p12_password' XXXXXXXX '-sd_hostname' 'jetfire.testrelm' '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' 'https://jetfire.testrelm:443'' returned non-zero exit status 255
creation of replica failed: Configuration of CA failed

Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
[root@ratchet ~]#

RESULT: Replication fails as expected and doesn't loop forever.

Comment 8 errata-xmlrpc 2011-12-06 16:29:21 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1655.html


Note You need to log in before you can comment on or make changes to this bug.