Bug 1183279

Summary: ipa-replica-manage disconnect fails without password
Product: Red Hat Enterprise Linux 7 Reporter: Scott Poore <spoore>
Component: ipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.1CC: drieden, mkosek, rcritten
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.1.0-16.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 10:19:26 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:
Attachments:
Description Flags
/var/log dir from master
none
/var/log dir from replica1
none
/var/log dir from replica2 none

Description Scott Poore 2015-01-18 01:55:15 UTC
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:

Comment 2 Scott Poore 2015-01-18 02:03:27 UTC
Created attachment 981103 [details]
/var/log dir from master

Comment 3 Scott Poore 2015-01-18 02:03:54 UTC
Created attachment 981104 [details]
/var/log dir from replica1

Comment 4 Scott Poore 2015-01-18 02:04:12 UTC
Created attachment 981105 [details]
/var/log dir from replica2

Comment 5 Martin Kosek 2015-01-19 11:41:20 UTC
Thanks for the bug report. I verified this is indeed a regression caused by PermissionV2 ACI refactoring.

I will clone an upstream bug

Comment 6 Martin Kosek 2015-01-19 11:41:57 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/4848

Comment 10 Scott Poore 2015-01-21 16:21:36 UTC
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) and (krbprincipalname=ldap/rhel7-3.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: 

[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) and (krbprincipalname=ldap/rhel7-2.example.com)
Connected 'rhel7-1.example.com' to 'rhel7-2.example.com'

Looks good.

Comment 12 errata-xmlrpc 2015-03-05 10:19:26 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.

https://rhn.redhat.com/errata/RHSA-2015-0442.html