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
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
