one issue that is incorrect here -- using --server (with domain and
realm) does NOT correct the action. You can do normal DNS resolution for
the client install, and then the ca_host in default.conf resolves the
problem along with adding --no-host-dns.
So correct order:
1. ipa-client-install (no mods, except make --force-ntpd)
2. add "ca_host = specific ipa-master" to /etc/ipa/default.conf
3. ipa-replica-install --setup-dns --no-forwarders --setup-ca
--no-host-dns (I setup DNS and CA servers on my replicas, but you should
do what you want/need)
There is one other issue I am finding, and still looking to resolve.
When I added the new replca to the proper location, and then regenerated
the DNS records, nothing I do changes the weight of the new replca. It
remains at half of the original replica. Still investigating. In the UI,
they both show 50% weight. But the resulting SRV records for LDAP or any
other service end with with the original server at 0 and the new server
at 50 - which means they are not equal. 0 is higher and will always be
used, and the 50 server will be ignored for the most part. Have to
change it by hand to get it to set correctly.
UPDATE -- even though the server shows in the correct location in the UI
- when running ipa server-show, it does NOT show in the correct
location, therefore the SRV records are not rated properly. So there
may be another bug that needs to be addressed for some reason?
Anyway, thanks to the RedHat team for all their help in solving this
one. I am back to a 100% functional environment, and when the perm fix
comes, we will all be much happier.
Kat
On 3/27/19 08:17, Alexander Bokovoy wrote:
> 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.
>
>