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 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]
