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?
Thanks -K
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.
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.
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.
freeipa-users@lists.fedorahosted.org