[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

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: ohama at jabbim.cz
IRC: ohamada