Bug 896699
| Summary: | ipa-replica-manage -H does not delete DNS SRV records | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Scott Poore <spoore> | ||||||
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | IDM QE LIST <seceng-idm-qe-list> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 7.0 | CC: | dpal, ksiddiqu, mbabinsk, mbasti, mkosek, pvoborni | ||||||
| Target Milestone: | rc | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-04-06 17:14:10 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
Scott Poore
2013-01-17 19:35:18 UTC
I think the problem is that it deletes the agreements and then removes the SRV records on the local IPA server. Because we've already broken replication these changes are lost. Upstream ticket: https://fedorahosted.org/freeipa/ticket/3362 Upstream ticket: https://fedorahosted.org/freeipa/ticket/4235 Update: I needed to uninstall, then reinstall the replica multiple times to reproduce this bug. I needed to go through 6 install/uninstall cycles on several machines before this behavior started. I am still getting this behavior on various systems: [root@nocp11 ~]# ipa-replica-manage -p $ADMINPW -H $MASTER del $REPLICA -f Deleting replication agreements between nocp11.testrelm.test and blade04.testrelm.test ipa: INFO: Setting agreement cn=meToblade04.testrelm.test,cn=replica,cn=dc\=testrelm\,dc\=test,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch ipa: INFO: Deleting schedule 2358-2359 0 from agreement cn=meToblade04.testrelm.test,cn=replica,cn=dc\=testrelm\,dc\=test,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 'blade04.testrelm.test' to 'nocp11.testrelm.test' Background task created to clean replication data. This may take a while. This may be safely interrupted with Ctrl+C [root@nocp11 ~]# dig @$MASTER +short _kerberos-master._tcp.testrelm.test srv 0 100 88 nocp11.testrelm.test. 0 100 88 blade04.testrelm.test. Thank you taking your time and submitting this request for Red Hat Enterprise Linux. Unfortunately, this bug was not given a priority and was deferred both in the upstream project and in Red Hat Enterprise Linux. Given that we are unable to fulfill this request in following Red Hat Enterprise Linux releases, I am closing the Bugzilla as WONTFIX. To request that Red Hat re-considers the decision, please re-open the Bugzilla via appropriate support channels and provide additional business and/or technical details about its importance to you. Note that you can still track this request or even contribute patches in the referred upstream Trac ticket. This appears to still be an issue. Is there a new way to handle this? [root@vm2 ~]# ipa-replica-manage -p Secret123 list vm2.example.com: master vm1.example.com: master [root@vm2 ~]# dig @vm1.example.com +short vm2.example.com 192.168.122.152 [root@vm2 ~]# dig @vm1.example.com +short -x 192.168.122.152 vm2.example.com. [root@vm2 ~]# dig @vm1.example.com +short _kerberos._tcp.example.com srv 0 100 88 vm1.example.com. 0 100 88 vm2.example.com. [root@vm2 ~]# ipa-replica-manage -p Secret123 -H vm1.example.com del vm2.example.com Updating DNS system records ipa: ERROR: unable to resolve host name vm2.example.com. to IP address, ipa-ca DNS record will be incomplete ------------------------------------ Deleted IPA server "vm2.example.com" ------------------------------------ [root@vm2 ~]# dig @vm1.example.com +short _kerberos._tcp.example.com srv 0 100 88 vm1.example.com. 0 100 88 vm2.example.com. [root@vm1 ~]# ipa dnsrecord-find example.com | grep vm2 NS record: vm2.example.com., vm1.example.com. SRV record: 0 100 88 vm2.example.com., 0 100 88 vm1.example.com. SRV record: 0 100 88 vm2.example.com., 0 100 88 vm1.example.com. SRV record: 0 100 464 vm1.example.com., 0 100 464 vm2.example.com. SRV record: 0 100 389 vm1.example.com., 0 100 389 vm2.example.com. SRV record: 0 100 88 vm2.example.com., 0 100 88 vm1.example.com. SRV record: 0 100 88 vm2.example.com., 0 100 88 vm1.example.com. SRV record: 0 100 464 vm1.example.com., 0 100 464 vm2.example.com. SRV record: 0 100 123 vm1.example.com., 0 100 123 vm2.example.com. Record name: vm2 Created attachment 1200668 [details]
vm1 var log dir
Created attachment 1200669 [details]
vm2 var log dir
I inspected the code and it looks that option -H was omitted in new code for server-del (which is used for ipa-replica-manage del in domain level 1) So effectively you hit this ticket, because replica is removing itself: https://fedorahosted.org/freeipa/ticket/6176 For domain level 0, it should work. Martin may know more about server-del/ipa-replica-manage del In domain level 1, option -H does not work for ipa-replica-manage del as the command `server-del` (which is called by ipa-replica-manage) is always run against the master specified in XMLRPC uri. This means that when you call `server-del FQDN` on master FQDN it means that the code is run locally and the master tries to remove itself. Closing with same explanation as written in Comment 7 |