[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Thu, 2012-05-03 at 19:37 +0200, Ondrej Hamada wrote:
> On 04/24/2012 10:47 AM, Ondrej Hamada wrote:
> > On 04/23/2012 07:58 PM, Simo Sorce wrote:
> >> On Mon, 2012-04-23 at 13:50 -0400, Dmitri Pal wrote:
> >>> Ah OK. Another semantic difference. Doing it in phases is one thing and
> >>> delivering is another. Let us say we identified 10 things that needs to
> >>> be implemented. The problem is so huge that Ondrej would likely be able
> >>> to tackle only couple items from the list. So what should be do with 
> >>> the
> >>> rest if it is not possible to deliver until all 10 items are completed?
> >> Ok, so most of the work here is in the KDC, so I think we should first
> >> go to MIT, present the problem and see what htey think about the
> >> solution we have in mind. I will try to have a preliminary discussion
> >> With Tom and Greg about the general idea this week to see what they
> >> think.
> >>
> >> Once that is done we can slice the implementation how we want in a
> >> private branch until it is fully backed. MIT wouldn't, rightly so,
> >> accept a half backed solution I would guess, but we also do not need to
> >> try to rush patches in. Once cleanup work in the KDC has been done as
> >> part of the 1.11 work I think these interfaces will change little so
> >> there shouldn't be a risk of wasting too much time to follow upstream
> >> while we work on one of these problems at a time.
> >>
> >>> IMO the work can be started and deferred till someone else can come 
> >>> back
> >>> and continue what Ondrej have started and bring it to the shape when we
> >>> are comfortable releasing it.
> >> Absolutely, esp if we can start after he changes MIT plans to make in
> >> 1.11 or at least if we plan together so we know which internal
> >> interfaces are going to be destabilized so we can plan ahead.
> >>
> >>> Ondra it time for you to sit down, read this thread thoroughly and 
> >>> craft
> >>> a design out of it.  Then you would be able to focus on a reasonable
> >>> subset of what is possible to complete in the remaining time frame.
> > Ok, will do. I would like to start with the login server scenario. It 
> > will be possible to use it later as a 'training field' for the 
> > fractional replication and help deciding what entries should and 
> > shouldn't be replicated.
> >> Ok.
> >> Simo.
> >>
> >
> >
> As I said before, I'm going to start with "authentication only" server. 
> That will be the first iteration. (I also want to present it in my 
> thesis as the implementation part)
> 
> Both the Hub and Consumer will be read only. In case of Hub the machine 
> should contain only directory server that will be configured to behave 
> as a hub. Consumers should behave same way as Dmitri described few posts 
> above - means they will use ldap with pam-proxy to sssd. The sssd will 
> be authenticating the user against master server. It might use caching 
> to enable some user to authenticate when the master is unreachable. The 
> consumer should be using chaining and trying to contact the master 
> directly.

No this is useless, just let it replicate userPassword, so that you do
not need to set up this complicated pam-proxy+sssd. It really is not
worth it.

> Replicas will replicate all data, just the confidential attributes such 
> as passwords will be excluded from replication.

exclude only kerberos keys, let userPassword replicate for now, later we
weill find how to replicate it only for a subset of users.

> Main enhancements will be made in ipa-tools, mainly the 
> ipa-replica-install and ipa-replica-manage. Also the ipa-client-install 
> will be updated as the client in such environment won't use Kerberos. I 
> think that at this stage those changes should be stored separately - I 
> mean not pushing them into upstream.
> 
> Can you agree on that?

Agree on not pushing some of it.
Cleanups are always welcome though.

> The second iteration should be focusing on development of plugins for 
> handling the account locking situation and similiar situations that need 
> to write some data to the replica. It might also focus on fractional 
> replication if it will be available in directory server. I suppose that 
> there won't be any more iterations necessary for the authentication server.

Hopefully not.

> Besides working on the second iteration we can also start with the eSSO 
> part. I assume that the account locks and fractional replication will 
> definitely have something in common.

Probably not, but the main part with SSO is managing the krb changes.

Simo.



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