https://bugzilla.redhat.com/show_bug.cgi?id=754539
Description of problem: Have a master and replica installed. From master do a del - to delete the replica # ipa-replica-manage del <replica hostname> -v -p XXX From master connect this replica # ipa-replica-manage connect <replica hostname> -v -p Secret123 unexpected error: list index out of range From deleted replica, connect to master: # ipa-replica-manage connect <master hostname> -p Secret123 unexpected error: list index out of range Version-Release number of selected component (if applicable): ipa-server-2.1.3-9.el6.x86_64 How reproducible: always Steps to Reproduce: 1.see above Actual results: cannot connect deleted replica back Expected results: be able to connect the deleted replica back Additional info: Rob looked into this and got the info below: Traceback (most recent call last): File "/usr/sbin/ipa-replica-manage", line 487, in <module> main() File "/usr/sbin/ipa-replica-manage", line 476, in main add_link(realm, replica1, replica2, dirman_passwd, options) File "/usr/sbin/ipa-replica-manage", line 383, in add_link repl1.setup_gssapi_replication(replica2, "cn=Directory Manager", dirman_passwd) File "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", line 796, in setup_gssapi_replication self.setup_krb_princs_as_replica_binddns(self.conn, r_conn) File "/usr/lib/python2.6/site-packages/ipaserver/install/replication.py", line 506, in setup_krb_princs_as_replica_binddns mod = [(ldap.MOD_ADD, "nsds5replicabinddn", a_pn[0].dn)] IndexError: list index out of range filter_a (krbprincipalname=ldap/ibm-x3650-04.testrelm@TESTRELM) filter_b (krbprincipalname=ldap/hp-xw4200-01.testrelm@TESTRELM), b_pn krbprinci palname=ldap/hp-xw4200-01.testrelm@TESTRELM,cn=services,cn=accounts,dc=testrelm hp-xw4200-01.testrelm is remove master ibm-x3650-04.testrelm is local, machine, former replica [root@ibm-x3650-04 ~]# ldapsearch -LLL -x -h hp-xw4200-01.testrelm -s base -b ' krbprincipalname=ldap/ibm-x3650-04.testrelm@TESTRELM,cn=services,cn=accounts,dc =testrelm' dn No such object (32) Matched DN: cn=services,cn=accounts,dc=testrelm [root@ibm-x3650-04 ~]# ldapsearch -LLL -x -h ibm-x3650-04.testrelm -s base -b ' krbprincipalname=ldap/ibm-x3650-04.testrelm@TESTRELM,cn=services,cn=accounts,dc =testrelm' dn dn: krbprincipalname=ldap/ibm-x3650-04.testrelm@TESTRELM,cn=services,cn=accoun ts,dc=testrelm possibly related bug: https://fedorahosted.org/freeipa/ticket/2088
This was caused by changes 550. It is cleaning up too much by removing the service principals and host. It means we can't re-establish a connection to the remote master because we don't have the ldap principal.
If we re-create the agreement using TLS with the intention of converting to GSSAPI it gets worse. The deletes on the deleted master get replayed. So basically you have a replication agreement, then wipe out all service principals on the master you just connected to.
I think we need to back out some of the deletes in replication.py::replica_cleanup()
I talked to Simo about this. This is by design. Deleting a replica like this says you no longer want it around at all. The expectation is that the remote replica is going away completely or will be re-installed with a new prepared file.
What I'm going to add is some extra verbiage that makes this clear and see if I can figure out a way so if you try to re-connect to that now deleted replica you get a reasonable error message back.
Moving to next month iteration.
attachment freeipa-rcrit-968-connect.patch
The patch does two things:
master: 2d55525[[BR]] ipa-2-2: 4e7e98f
Metadata Update from @mkosek: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.2 Core Effort - 2012/02
Login to comment on this ticket.