[Freeipa-users] Replication for sites not using FreeIPA for DNS?

[Ian Levesque]

On Jan 18, 2012, at 2:08 PM, Stephen Gallagher wrote:

> On Wed, 2012-01-18 at 12:17 -0500, Ian Levesque wrote:
>> Hello,
>> 
>> I'm running IPA version 2.1.3-9 on RHEL 6.2 and just configured
>> master/master replication. From what I can tell in the documentation
>> [1], all of the client-discovering-a-replica magic happens via SRV
>> records in DNS. This is quite different from what I'm used to, coming
>> from managing an Open Directory service in which the replicated
>> server's FQDN is passed on to the client through LDAP as an additional
>> LDAP/KDC server to add to the client's local config.
>> 
>> My question is how can I take advantage of replication if we're not
>> using the FreeIPA-blessed DNS server? Do I need to manually tweak the
>> SSSD config to make it aware of a second LDAP/KDC server? Is there a
>> hidden flag I can pass ipa-client-install to do this for me?
> 
> 
> In addition to Dmitri's comments (and mine in the "Forcing IPA clients
> to prioritise different IPA Servers" thread) you should be aware that
> just because you're not using FreeIPA as the DNS server, it doesn't mean
> that you can't use SRV records to solve this problem.
> 
> The SRV records are looked up on whatever DNS server is configured
> in /etc/resolv.conf. So if you ask your DNS administrator to add SRV
> records for your FreeIPA replicas, you can still continue this way.
> 
> Otherwise, your best bet is to edit the sssd.conf directly (for now. As
> Dmitri says, we're looking at other approaches for future FreeIPA
> releases).

Many thanks to both of you for your replies. I'm curious why you don't employ a feature similar to Apple's approach, where replica information is passed to the client. In this scenario, SSSD can be notified of the configuration and handle it automatically... I'm personally not a big fan of using DNS for service management, and would prefer to have the server and client hash it out amongst themselves. That said, I appreciate the workaround and can easily incorporate it into our deployment workflow.

Best regards,
Ian