[Freeipa-users] Realm distrubuted across data centers

[de Jong, Mark-Jan]

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.

> >
> >     ----- Original Message -----
> >     *From:* Peter Brown <mailto:rendhalver at gmail.com>
> >     *To:* Michael ORourke <mailto:mrorourke at earthlink.net>
> >     *Cc:* freeipa-users <mailto:freeipa-users at 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 <mrorourke at earthlink.net
> >     <mailto:mrorourke at 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 at redhat.com <mailto:Freeipa-users at redhat.com>
> >         https://www.redhat.com/__mailman/listinfo/freeipa-users
> >         <https://www.redhat.com/mailman/listinfo/freeipa-users>
> >
> >
> >     No virus found in this message.
> >     Checked by AVG - www.avg.com <http://www.avg.com>
> >     Version: 2013.0.2904 / Virus Database: 2641/6156 - Release Date:
> >     03/08/13
> >
> >
> >
> > _______________________________________________
> > Freeipa-users mailing list
> > Freeipa-users at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>


PRIVILEGED AND CONFIDENTIAL
PLEASE NOTE: The information contained in this message is privileged and confidential, and is intended only for the use of the individual to whom it is addressed and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please contact sender. Thank you.

Please consider the environment before printing this e-mail.