Bug 867682 - Cannot install an ipa replica from existing ipa replica not running DNS
Cannot install an ipa replica from existing ipa replica not running DNS
Product: Fedora
Classification: Fedora
Component: freeipa (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rob Crittenden
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-10-18 00:50 EDT by Jason Montleon
Modified: 2012-10-24 11:56 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-23 18:42:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jason Montleon 2012-10-18 00:50:49 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):

How reproducible:
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)
Actual results:
Installation on the third replica complains that the hostname of the second replica is unresolvable.

Expected results:
Installation should complete.

Additional info:
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= s02.ipa.montleon.intra

and then on s02.ipa.montleon.intra
ipa-replica-install /root/replica-info-s02.ipa.montleon.intra.gpg and
ipa-ca-install /root/replica-info-s02.ipa.montleon.intra.gpg
ipa-replica-prepare --ip-address= 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.)
Continue? [no]: 

Until I went back to s02.ipa.montleon.intra and ran:
ipa-dns-install /root/replica-info-s02.ipa.montleon.intra.gpg

I verified prior to setting up DNS on s02 that the following worked:
[root@s02 ~]# ipa dns-resolve s02.ipa.montleon.intra
Found '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.

cat /etc/resolv.conf 
domain ipa.montleon.intra
search ipa.montleon.intra

[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

; EDNS: version: 0, flags:; udp: 4096
;s02.ipa.montleon.intra.		IN	A

s02.ipa.montleon.intra.	1200	IN	A

ipa.montleon.intra.	86400	IN	NS	s01.ipa.montleon.intra.

s01.ipa.montleon.intra.	1200	IN	A

;; Query time: 1 msec
;; WHEN: Thu Oct 18 00:07:18 2012
;; MSG SIZE  rcvd: 101
Comment 1 Martin Kosek 2012-10-19 07:29:56 EDT
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).
Comment 2 Martin Kosek 2012-10-19 07:30:51 EDT
Upstream ticket:
Comment 3 Rob Crittenden 2012-10-23 18:42:24 EDT
Fixed upstream.

master: e4853ebc5910a526c74cc422fd3c1806708bc7aa

ipa-3-0: 0b81c517ef982260b2c61239f5d1450009959411

Note You need to log in before you can comment on or make changes to this bug.