[Freeipa-users] Realm distrubuted across data centers

Thu Mar 14 01:40:40 UTC 2013

El mié, 13-03-2013 a las 15:57 -0400, Simo Sorce escribió:
> 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.

Maybe I don't get the proposal completely but these dynamically
generated DNAME record which won't work when you need them the most
(when you are a roaming user querying a non-ipa DNS server...) don't
seem very helpful. The "complicated" part seems to me all the magic (or
rather, policy) that would go into bind-dyndb-ldap, which can not be
easily modified by the admin, and as you note in the proposal DNSSEC
interaction is problematic.

In general DNSSEC doesn't play well with views and with dynamically
generated records.

What if the company doesn't want to manage their DNS with IPA? What if
the user is outside the company's network? What if the user is
connecting to the company's network via vpn but is using the DNS servers
of his ISP?

Your first proposal, even if it required the admin to add some info in
the server (site list, servers per site, ip networks per site) would
work even outside the company's firewall, could be managed with any dns
server and would play well with DNSSEC.

Loris

> > 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.
> 

-- 
Loris Santamaria   linux user #70506   xmpp:loris at lgs.com.ve
Links Global Services, C.A.            http://www.lgs.com.ve
Tel: 0286 952.06.87  Cel: 0414 095.00.10  sip:103 at lgs.com.ve
------------------------------------------------------------
"If I'd asked my customers what they wanted, they'd have said
a faster horse" - Henry Ford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6173 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20130313/f68269f9/attachment.bin>