Red Hat Bugzilla – Bug 867682
Cannot install an ipa replica from existing ipa replica not running DNS
Last modified: 2012-10-24 11:56:18 EDT
Description of problem:
I was not able to install a new replica from an existing replica that was not running DNS
Version-Release number of selected component (if applicable):
Seems always, though I have only tried in one setup, I could not get around the problem.
Steps to Reproduce:
1. Create an IPA Server (first replica) with --setup-dns
2. Run ipa-replica-prepare and set up another replica (second replica)
3. On the second replica run ipa-replica-prepare for yet another replica and try to set another replica (third replica)
Installation on the third replica complains that the hostname of the second replica is unresolvable.
Installation should complete.
I was trying to follow along with https://fedoraproject.org/wiki/QA:Testcase_freeipav3_replication
There is nothing to indicate that the second replica must have DNS running, but once it was the third replica installed without issue.
In my test I set up s01.ipa.montleon.intra with the --setup-dns option. Once done I proceeded to run ipa-replica-prepare --ip-address=172.16.1.3 s02.ipa.montleon.intra
and then on s02.ipa.montleon.intra
ipa-replica-install /root/replica-info-s02.ipa.montleon.intra.gpg and
ipa-replica-prepare --ip-address=172.16.1.4 s03.ipa.montleon.intra
on s03.ipa.montleon.intra I continually tried to run:
ipa-replica-install /root/replica-info-s03.ipa.montleon.intra.gpg, which continually failed with the message:
Connection check OK
ipa : ERROR Could not resolve hostname s02.ipa.montleon.intra using DNS. Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.)
Until I went back to s02.ipa.montleon.intra and ran:
I verified prior to setting up DNS on s02 that the following worked:
[root@s02 ~]# ipa dns-resolve s02.ipa.montleon.intra
as did host, dig, etc.
I also verified that name resolution was working on s03, and rebooted for the heck of it to make sure no odd caching problems were occurring, even though I did not have nscd installed.
[root@s03 ~]# dig s02.ipa.montleon.intra
; <<>> DiG 9.9.2-RedHat-9.9.2-2.fc18 <<>> s02.ipa.montleon.intra
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26495
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;s02.ipa.montleon.intra. IN A
;; ANSWER SECTION:
s02.ipa.montleon.intra. 1200 IN A 172.16.1.3
;; AUTHORITY SECTION:
ipa.montleon.intra. 86400 IN NS s01.ipa.montleon.intra.
;; ADDITIONAL SECTION:
s01.ipa.montleon.intra. 1200 IN A 172.16.1.2
;; Query time: 1 msec
;; SERVER: 172.16.1.2#53(172.16.1.2)
;; WHEN: Thu Oct 18 00:07:18 2012
;; MSG SIZE rcvd: 101
Jason, thanks for the report. I checked our code and this is indeed a bug in our code, we expect the origin master to be a DNS server, which is not right. I will file an upstream ticket to fix this.
In your case, when installing the third replica (s03.ipa.montleon.intra) you can safely answer "yes" to "Continue? [no]: " question to workaround the issue (the question is not asked at all in --unattended mode).