Red Hat Bugzilla – Bug 1183279
ipa-replica-manage disconnect fails without password
Last modified: 2015-03-05 05:19:26 EST
Description of problem: Trying to disconnect a replication agreement, I'm seeing ipa-replica-manage try but not work completely. It's showing errors and when I try to re-connect, it fails saying it already exists. This is only happening when I'm relying on GSSAPI with kerberos and NOT specifying -p Password on the command line. If I specify password, it works. [root@rhel7-1 yum.repos.d]# ipa-replica-manage disconnect rhel7-1.example.com rhel7-2.example.com ipa: INFO: Setting agreement cn=meTorhel7-1.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meTorhel7-1.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config ipa: INFO: Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 Unable to remove agreement on rhel7-2.example.com: no such entry [root@rhel7-1 yum.repos.d]# ipa-replica-manage connect rhel7-1.example.com rhel7-2.example.com A replication agreement to rhel7-2.example.com already exists But, here you see it works if I specify password on command line: [root@rhel7-1 yum.repos.d]# ipa-replica-manage -p Secret123 disconnect rhel7-1.example.com rhel7-2.example.com ipa: INFO: Setting agreement cn=meTorhel7-1.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meTorhel7-1.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config ipa: INFO: Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 Deleted replication agreement from 'rhel7-1.example.com' to 'rhel7-2.example.com' Version-Release number of selected component (if applicable): ipa-server-4.1.0-15.el7.x86_64 389-ds-base-1.3.3.1-11.el7.x86_64 How reproducible: always. Steps to Reproduce: 1. Setup IPA MASTER 2. Setup IPA REPLICA1 from MASTER 3. Setup IPA REPLICA2 from REPLICA1 ON MASTER: 4. ipa-replica-manage -p PASSWORD connect REPLICA2 5. kinit admin 6. ipa-replica-manage disconnect MASTER REPLICA1 Actual results: fails as shown above but, works if specifying password instead of relying on kerberos ticket. Expected results: works without needing to specify password. Additional info:
Created attachment 981103 [details] /var/log dir from master
Created attachment 981104 [details] /var/log dir from replica1
Created attachment 981105 [details] /var/log dir from replica2
Thanks for the bug report. I verified this is indeed a regression caused by PermissionV2 ACI refactoring. I will clone an upstream bug
Upstream ticket: https://fedorahosted.org/freeipa/ticket/4848
Fixed upstream master: https://fedorahosted.org/freeipa/changeset/251c97cf96edccaec5ce034007068609ad69227f ipa-4-1: https://fedorahosted.org/freeipa/changeset/338831aea3cdf04a27f5ea9159f84f9ce933e0c1
Verified. Version :: ipa-server-4.1.0-16.el7.x86_64 Results :: [root@rhel7-1 ~]# kdestroy -A [root@rhel7-1 ~]# ipa-replica-manage -p Secret123 connect rhel7-3.example.com ipa: INFO: Getting ldap service principals for conversion: (krbprincipalname=ldap/rhel7-1.example.com@EXAMPLE.COM) and (krbprincipalname=ldap/rhel7-3.example.com@EXAMPLE.COM) Connected 'rhel7-1.example.com' to 'rhel7-3.example.com' [root@rhel7-1 ~]# ipa-replica-manage list rhel7-3.example.com Directory Manager password: rhel7-1.example.com: replica rhel7-2.example.com: replica [root@rhel7-1 ~]# kinit admin Password for admin@EXAMPLE.COM: [root@rhel7-1 ~]# ipa-replica-manage disconnect rhel7-1.example.com rhel7-2.example.com ipa: INFO: Setting agreement cn=meTorhel7-1.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meTorhel7-1.example.com,cn=replica,cn=dc\=example\,dc\=com,cn=mapping tree,cn=config ipa: INFO: Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 ipa: INFO: Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update succeeded: start: 0: end: 0 Deleted replication agreement from 'rhel7-1.example.com' to 'rhel7-2.example.com' [root@rhel7-1 ~]# [root@rhel7-1 ~]# ipa-replica-manage list rhel7-2.example.com rhel7-3.example.com: replica [root@rhel7-1 ~]# ipa-replica-manage list rhel7-1.example.com rhel7-3.example.com: replica [root@rhel7-1 ~]# ipa-replica-manage list rhel7-3.example.com rhel7-1.example.com: replica rhel7-2.example.com: replica [root@rhel7-1 ~]# ipa-replica-manage connect rhel7-1.example.com rhel7-2.example.com ipa: INFO: Getting ldap service principals for conversion: (krbprincipalname=ldap/rhel7-1.example.com@EXAMPLE.COM) and (krbprincipalname=ldap/rhel7-2.example.com@EXAMPLE.COM) Connected 'rhel7-1.example.com' to 'rhel7-2.example.com' Looks good.
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. https://rhn.redhat.com/errata/RHSA-2015-0442.html