On 3/18/21 9:37 AM, Alexander Bokovoy via FreeIPA-users wrote: > On to, 18 maalis 2021, Kees Bakker via FreeIPA-users wrote: >> Hi, >> >> We have FreeIPA with three masters. To get to the LDAP server >> we can use either of the three. To configure a service you must >> come up with a FQDN for the LDAP server. Until now we have >> simply selected one of the three. But that's not very convenient >> because we want to do maintenance on that IPA master. >> >> What possibilities are there to have something that switches >> automatically to another server? How is the SRV _ldap._tcp record >> used? > > It very much depends on the application side. DNS SRV-based location > service discovery is defined by RFC 2782. How many applications support > it? Good question. > > Some applications allow to specify multiple LDAP servers in their > configuration and would go to the one that responds in some order. > > OpenLDAP command line tools support RFC 2782 to discover LDAP servers: > > -H ldapuri > Specify URI(s) referring to the ldap server(s); a list of > URI, separated by whitespace or commas is expected; only > the protocol/host/port fields are allowed. As an > exception, if no host/port is specified, but a DN is, the > DN is used to look up the corresponding host(s) using the > DNS SRV records, according to RFC 2782. The DN must be a > non-empty sequence of AVAs whose attribute type is "dc" > (domain component), and must be escaped according to RFC > 2396. > > > Something like > > ldapsearch -H dc=example,dc=test ... > > PostgreSQL does support the same when compiled with OpenLDAP support: > > host ... ldap ldapbasedn="dc=example,dc=net" > > For other applications, I haven't seen much of it used. >
This is in the same fashion we saw provision for linux to report a list of available dns resolvers, and NS record lookups similarly, but applications failing if the first on the list fails. End-user systems enabled systemd resolvers or network managers or os-local 'middle ware DNS systems' that tried to overcome that. The the freeipa case, to overcome the spotty implementation Alexander mentioned, and in keeping with the 'replica' capability in freeipa, I had to implement a cert with SAN entries for all the replicas, and implement a failover 'freeipa ip' for a working instance to provide a HA system of sorts (for both ipv4 and v6). At least in that way, client systems that are rarely if ever rebooted can use more common re-kinit / link-lost logic to maintain service across freeipa lossage/reboots. It wasn't enough just to HAProxy, if you want/need ssl on the ldap lookups (you need failover management somewhere, either on the HAProxy setups, but better I think managed on the freeipa side). And, really, freeipa has so much 'replica' management going on and cert management going on, adding a cert with a SAN for all the replicas and implementing a failover IP is a reasonable feature to implement .. that way I don't have to maintain the one I wrote.... HC _______________________________________________ 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
