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:lo...@lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford
Description: S/MIME cryptographic signature
_______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users