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
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
> 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.
> 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 Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list