On ti, 26 maalis 2019, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 26 maalis 2019, Kat via FreeIPA-users wrote:
>Hi all,
>
>Another weird question to ponder. In a client, working perfectly,
>and DNS is defined in resolv.conf as the IPA master within the
>LOCATION (yes, using the location feature of IPA). If I try to
>upgrade this same client to a replica using ipa-replica-install it
>fails with
>
>ipaserver.install.server.replicainstall: ERROR Could not resolve
>hostname
ipa-master.example.com using DNS.
>
>And here is the kicker - when you look at the log of the install you
>see that the reason it could noto resolve
ipa-master.example.com is
>NOT because it was not defined, but because it was now attempting to
>use the IPA master running DNS from another location and it timed
>out because firewalls block DNS lookup across these locations
>(although the masters can talk to each other)
>
>So my question is - why does replica-install pass a different DNS
>server to do the lookup rather than what was in /etc/resolv.conf? It
>is like it is asking to the master - "Hey, why not give me a random
>DNS server I can use?" and not relying on defined LOCATIONS. BTW -
>location features work perfectly for everything else, and you do see
>the proper weighting to SRV records so clients are not trying to
>contact the wrong IPA master to work.
>
>This has me baffled and I am trying to understand how I can get
>ipa-replica-install to NOT use a random DNS server in another
>location. Any ideas?
It might be a logical error in the code or something driven by options
you specified. To understand that, actual installation logs are needed
and a description of your environment to accompany that. Feel free to
send them off-list.
Closing down: a workaround is to do few actions:
- use --server when setting up a client on a replica-to-be to point to
the location-specific master
- set ca_host value in /etc/ipa/default.conf before promoting a client
to replica to a hostname of a CA available on this location
- use --no-host-dns or run ipa-replica-install interactively so that a
failure to verify DNS resolution of a replica-to-be and a master
wouldn't cause abort of the installation
This should allow getting around the issues when a master is
unreachable. Christian filed
https://pagure.io/freeipa/issue/7890 and
commented on
https://pagure.io/freeipa/issue/7444 that we want to
backport an updated patch to 4.6/4.7.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland