lejeczek via FreeIPA-users wrote: > > > On 07/04/2022 18:04, Rob Crittenden wrote: >> lejeczek via FreeIPA-users wrote: >>> >>> On 06/04/2022 16:50, Rob Crittenden wrote: >>>> lejeczek via FreeIPA-users wrote: >>>>> On 30/03/2022 09:19, Alexander Bokovoy via FreeIPA-users wrote: >>>>>> On ke, 30 maalis 2022, Boris Behrens via FreeIPA-users wrote: >>>>>>> Hi, >>>>>>> I am currently trying to cleanup our IPA installation and saw that >>>>>>> all our >>>>>>> clients only got a single server configured, which doesn't sound >>>>>>> good. >>>>>>> (we've currently got two IPA servers). >>>>>>> >>>>>>> Is there some sort of record that can be used? >>>>>> Look into man page for 'ipa' tool: >>>>>> >>>>>> SERVERS >>>>>> The ipa client will determine which server to connect to in >>>>>> this order: >>>>>> >>>>>> 1. The server configured in /etc/ipa/default.conf in the >>>>>> xmlrpc_uri directive. >>>>>> >>>>>> 2. An unordered list of servers from the ldap DNS SRV >>>>>> records. >>>>>> >>>>>> If a kerberos error is raised by any of the requests then it >>>>>> will stop processing and display the error message. >>>>>> >>>>>> >>>>> But is that really a problem, and if not, when could that be a >>>>> problem? >>>>> I see all my clients end up with only single server in config files - >>>>> the which client hooked to at the installation time - is that not >>>>> how it >>>>> should be? >>>> It is only a potential problem if you don't use DNS discovery and that >>>> server goes away. >>>> >>>> In /etc/ipa/default.conf the server value is deprecated. The value of >>>> xmlrpc_uri is used to determine the API endpoint of an IPA server. >>>> >>>> This mostly affects the IPA tools and certmonger, all of which try DNS >>>> discovery first. >>>> >>>> There is no way to specify multiple servers in /etc/ipa/default.conf. >>>> >>>> So the worse case scenario is you don't use DNS discovery and a server >>>> goes away permanently never to be re-created. Any client with that >>>> hardcoded server value won't be able to use certmonger or IPA tools >>>> like >>>> ipa-certupdate, ipa, etc. >>>> >>>> Similarly SSSD is by default configured with: ipa_server = _srv_, >>>> ipa.example.test >>>> >>>> So if there is no DNS discovery and that one server dies, you're done >>>> until you restore the server or change the value (SSSD caching can >>>> mitigate this to some extent, it will be treated as offline). >>>> >>>> Going into your clients to evenly divide them between the two servers >>>> could save you some work if one went down forever but relying on DNS >>>> discovery to find servers is recommended and preferred. >>>> >>>> rob >>>> >>> How about bit "twisted" way of having things run, when only one - for >>> whatever imaginary reason - server is available to clients. Not at all >>> times but at a given time, say... today it's masterA but tomorrow will >>> be masterB >>> That would brakes some clients some times, correct? >>> And if so - would IPA be okay with a primitive remedy such as >>> 'xmlrpc_uri' pointing to a URI/record with a non-existing/not actual >>> host's hostname (still IPA server)? which would be always accessible to >>> all clients? >> If you have DNS SRV records then it should continue to work fine. There >> just may be a delay in some requests until failover occurs. >> >> We do not recommend putting a load balancer in front of IPA. It's a lot >> of manual effort and lots of room to make mistakes. >> >> rob >> > not a load-balancer - a record with a non-existing/non-actual server's > hostname, but still IPA server. > Better described as a "floating" record perhaps? > srv1.ipa.com A x.x.x > srv2.ipa.com A x.x.x > some more.. > mama.ipa.com A z.z.z (which IP, "physically" will travel from server to > server on "whatever" basis) > > then 'xmlrpc_uri' points to 'mama.ipa.com' > ? > As long as this does not brake IPA in some way, it's a "workaround" > which makes my setups very happy.
Are you saying this works? I wouldn't expect it to. With TLS and Kerberos if you ask for host/service "foo" and get "bar" back it should fail. Unless you've done the work to add additional SAN and Kerberos naming. rob _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
