On ti, 12 maalis 2019, Callum Smith wrote:
Yep you're not wrong, one of our IPA replica was being evil and
spitting errors. That replica is destined for the bin anyway so i've
not worried about it. All of the kerberos issues have now gone away -
except one which is more of a question than anything. Is it intentional
that the sub-zone _kerberos._tcp SRV records are ignored and only the
top level SRV records are used. We were hoping that defining
_kerberos._tcp in .virt.in.bmrc.ox.ac.uk would work and over-ride the
_kerberos._tcp SRV records in .in.bmrc.ox.ac.uk
I have a feeling this behaviour is only in the installer however.
Installer uses _ldap SRV records to discover IPA masters. This is
documented in the manual page for ipa-client-install.
You can also pass --domain virt.in.bmrc.ox.ac.uk and then clients will
use this one to discover servers and use them. I guess you'll need to
add _kerberos TXT record there with 'IN.BMRC.OX.AC.UK' to properly glue
Kerberos clients but LDAP SRV records should just work.
Another (smaller) issue is that the DNS record creation as part of
`ipa-client-install` isn't working. I'm having trouble finding where to
look for the error:
Found zone name: virt.in.bmrc.ox.ac.uk
The master is: ipa-a.in.bmrc.ox.ac.uk
start_gssrequest
send_gssrequest
; Communication with 10.141.247.129#53 failed: timed out
Authoritative server is not available, thus failing to communicate with
it. I don't think it will be possible to fix this as you are running the
very same servers as dual network ones and we don't have DNS views that
would rewrite IP addresses of the authoritative servers.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland