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.
Replicas will replicate all data, just the confidential attributes such
as passwords will be excluded from replication.
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?
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.
--
Regards,
Ondrej Hamada
FreeIPA team
jabber: oh...@jabbim.cz
IRC: ohamada
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
