Re: [Freeipa-users] Realm distrubuted across data centers
On 13.3.2013 16:17, de Jong, Mark-Jan wrote: On Wed, 2013-03-13 at 09:28 -0400, 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. You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. rob Would a bind sortlist help in this scenario to prefer IP addresses based on the requester? It's independent of the zone config and I believe can be set globally if and when views are implemented. I gave a try to sortlists in BIND: I found that it works very well for A records. Sortlist option can rearange IP addresses in the ANSWER section so 'local' addresses are on top of the ANSWER section and 'remote' IP addresses at the end of ANSWER section. Unfortunately, sortlist doesn't affect SRV records at all. IMHO it can't do that because it would be against SRV RR definition in RFC 2782. Petr^2 Spacek - Original Message - *From:* Peter Brown mailto:rendhal...@gmail.com *To:* Michael ORourke mailto:mrorou...@earthlink.net *Cc:* freeipa-users mailto:freeipa-users@redhat.com *Sent:* Wednesday, March 13, 2013 12:58 AM *Subject:* Re: [Freeipa-users] Realm distrubuted across data centers I have no idea if this counts as best practice because I am not affiliated with the FreeIPA development team I personally think SRV records are probably the best idea in this situation. You would have to setup different zones to serve to each datacentre though if you know how to do that. It's not that tricky with views in bind. On 13 March 2013 12:40, Michael ORourke mrorou...@earthlink.net mailto:mrorou...@earthlink.net wrote: We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Realm distrubuted across data centers
On Wed, 2013-03-13 at 09:28 -0400, 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. You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. Just want to note that we are working on a more manageable solution for the future: http://www.freeipa.org/page/V3/DNS_Location_Mechanism But we are not there yet. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Realm distrubuted across data centers
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! In your case with only 2 locations and 2 IPA servers in each location, it is relatively simple to prepare two sets of hand-crafted DNS records site1._locations.ipa.example.com and site2._locations.ipa.example.com and configure clients on each site to use these two domains (site1 and site2) according to their real network location. Disadvantages of hand-made records: - It can't handle mobile clients (i.e. travelling between 'sites'). - 'Domain' configured in SSSD has to be reconfigured on each client. Let me know if you want to go this way. (It should work with any IPA/DNS server.) Petr^2 Spacek You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. rob - Original Message - *From:* Peter Brown mailto:rendhal...@gmail.com *To:* Michael ORourke mailto:mrorou...@earthlink.net *Cc:* freeipa-users mailto:freeipa-users@redhat.com *Sent:* Wednesday, March 13, 2013 12:58 AM *Subject:* Re: [Freeipa-users] Realm distrubuted across data centers I have no idea if this counts as best practice because I am not affiliated with the FreeIPA development team I personally think SRV records are probably the best idea in this situation. You would have to setup different zones to serve to each datacentre though if you know how to do that. It's not that tricky with views in bind. On 13 March 2013 12:40, Michael ORourke mrorou...@earthlink.net mailto:mrorou...@earthlink.net wrote: We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Realm distrubuted across data centers
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. 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... Just my $0.02! In your case with only 2 locations and 2 IPA servers in each location, it is relatively simple to prepare two sets of hand-crafted DNS records site1._locations.ipa.example.com and site2._locations.ipa.example.com and configure clients on each site to use these two domains (site1 and site2) according to their real network location. Disadvantages of hand-made records: - It can't handle mobile clients (i.e. travelling between 'sites'). - 'Domain' configured in SSSD has to be reconfigured on each client. Let me know if you want to go this way. (It should work with any IPA/DNS server.) Petr^2 Spacek You'd also need a custom sssd.conf as well. We support this kind of configuration in 3.x. Using multiple --server and --fixed-primary options of ipa-client-install you can add multiple, hardcoded servers and still have failover. Basically you configure things to ignore the SRV records, so you shouldn't have to mess with the resolver at all. rob - Original Message - *From:* Peter Brown mailto:rendhal...@gmail.com *To:* Michael ORourke mailto:mrorou...@earthlink.net *Cc:* freeipa-users mailto:freeipa-users@redhat.com *Sent:* Wednesday, March 13, 2013 12:58 AM *Subject:* Re: [Freeipa-users] Realm distrubuted across data centers I have no idea if this counts as best practice because I am not affiliated with the FreeIPA development team I personally think SRV records are probably the best idea in this situation. You would have to setup different zones to serve to each datacentre though if you know how to do that. It's not that tricky with views in bind. On 13 March 2013 12:40, Michael ORourke mrorou...@earthlink.net mailto:mrorou...@earthlink.net wrote: We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel
Re: [Freeipa-users] Realm distrubuted across data centers
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 smime.p7s Description: S/MIME cryptographic signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Realm distrubuted across data centers
We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Realm distrubuted across data centers
I have no idea if this counts as best practice because I am not affiliated with the FreeIPA development team I personally think SRV records are probably the best idea in this situation. You would have to setup different zones to serve to each datacentre though if you know how to do that. It's not that tricky with views in bind. On 13 March 2013 12:40, Michael ORourke mrorou...@earthlink.net wrote: We have a single realm distributed across 2 data centers and 2 offices with 4 replicated IPA servers (2 in each data center). We are running IPA server and client v2.2.0 on all servers and replication appears to be functioning correctly. What I have noticed is that some servers in DC1, have no connectivity to the IPA servers in DC2, and when you try connecting to them from Office1 you sometimes get a long authentication delay. I suspect this is caused by a timeout waiting for an IPA server in DC2 to respond (which it can't). So I guess my question is, is there a 'best practices' approach to this scenario? __**_ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/**mailman/listinfo/freeipa-usershttps://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
