[Freeipa-users] Realm distrubuted across data centers

[Simo Sorce]

On Wed, 2013-03-13 at 14:36 -0430, Loris Santamaria wrote:
> El mié, 13-03-2013 a las 14:44 +0100, Petr Spacek escribió:
> > On 13.3.2013 14:28, Rob Crittenden wrote:
> > > Michael ORourke wrote:
> > >> I think SRV records are only part of the problem.  We are using
> > >> integrated BIND/DNS with our IPA servers and I'm not sure it supports
> > >> views.  But thanks for the suggestion.
> > >> I guess we could create custom krb5.conf files in each DC and mange them
> > >> with Puppet, but there are other config files (e.g. resolv.conf and
> > >> ldap.conf) that would need to be managed too.  Maybe there are some
> > >> other IPA client config files that setup static mappings during the join
> > >> process.  Anyone know which ones to look at?
> > >
> > > No, we don't support views yet.
> > Views are not supported in IPA admin tools, but generally views can be 
> > configured with some hacking around. The price for that is losing IPA admin 
> > tools for DNS and generally, it is ugly and hard to maintain. I wouldn't 
> > recommend that.
> > 
> > Our latest & greatest proposal for location auto-discovery in summarized at 
> > http://www.freeipa.org/page/V3/DNS_Location_Mechanism . Any comments are welcome!
> 
> Hi!
> 
> The proposal seems to me too complicated, I really liked the old
> proposal where you could query the DNS which was the most appropriate
> "site" for your IP address. Choosing the right site by IP address is not
> perfect, there will be always some corner cases, but it is good enough
> and way better than what we have now.

Can you explain what is complicated about the current proposal ?

The reason I thought hard about this one is that the previous proposal
would require * a lot* of work on both client and server and was, as you
note, not great.

The current proposal is a lot easier to implement both on the server and
the client and reduces considerably the amount of code for both,
especially for the client, where in many case no changes are required at
all, just a client reconfiguration.

> The problem could be addressed in two parts:
> 
> 1) Add the concepts of "sites" to the IPA realm, and associate every
> server with one (and just one?) site, the generate the appropriate SRV
> record for every site. I did this manually, creating the SRV records one
> by one:
> 
> _kerberos._udp.site1._sites.mydomain.com. IN SRV 0 100 88 ipa1.mydomain.com.
> ...  
> 
> When joining the host to the domain the admin may add the option
> --domain=site1._sites.mydomain.com to ipa-client-install to use the
> right ipa servers for that site.
> 
> This first step could be added to IPA fairly easy and it would be a
> great improvement.
> 
> 2) Add some kind of configurable locator policy to SSSD. There could
> be: 
> 
> 2.1) "fixed site" policy, which would use always the same site
> 2.2) "CLDAP ping" AD-like policy
> 2.3) a policy which reads and remember the right site per client or per
> ip address from LDAP on first connection...

The problem with this is that you need to explicitly configure the
client, and invent these new things in SSSD.
In our new proposal you do not need to do anything on the client, except
pointing it to  ... itself!

So I am a bit confused about why you say the new proposal would be more
complicated ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York