directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@gmail.com>
Subject Re: Replication configuration : second thought
Date Mon, 16 Mar 2009 19:47:32 GMT
On Mon, Mar 16, 2009 at 3:42 PM, Emmanuel Lecharny <elecharny@apache.org>wrote:

>
>  We should consider three cases :
>>> - no replication at all, nor as a consumer neither as a producer. This is
>>> what you describe.
>>>
>>>
>>
>>
>> Yes this is what the core DirectoryService should be.  If replication is
>> needed then LdapService needs to be used.
>>
>>
> Ok, let's start from here then. Assuming that the core is free of network
> is a good base.
>
>
>>
>>> - embedded server with a consumer
>>> - embedded server which is also a producer
>>>
>>>
>>>
>>
>> By embedded you don't mean just the core? Let's be exacting with this
>> term.
>>
>>
> I mean, the core. Not the network part.
>
>> The following embedded configurations of ApacheDS are possible:
>>
>>   (1) Only the core without any network services enabled.
>>     (2) The core and the LDAP server together with potentially other
>> network
>> services enabled.
>>
>>
> Right. This is from this starting point I'm trying to figure out the best
> possible place to put the replication layer.
>
>  Now in the 1st configuration I don't see replication as available.  It
>> should not be available.  Trustin broke this order by developing mitosis
>> in
>> a vacuum.  I intend to correct this mistake.
>>
>>
> I agree.
>
>> Now that we're using syncrepl which sits on top of the LDAP line protocol,
>> it makes sense to have it enabled with the frontend in the 2nd
>> configuration
>> I wrote above.
>>
>>
> Ok. There is one little things remaining then (see later).
>
>>
>>
>>> In case 3, then better start the LdapService, as it has everything
>>>
>>> In case 2, i don't see why we should also get all the LDAP machinery when
>>> just a client would be enough ?
>>>
>>>
>>>
>>
>> Consumer or actual LDAP client don't understand.
>>
>>
> Consumer. Sorry for the confusion.
>
>>
>>
>>
>>> Maybe we need an intermediate machinery, not in the core but not in the
>>> service ?
>>>
>>>
>>>
>>
>> These are bad choices IMHO. It's yet another new way things can be setup.
>>  I
>> think you should keep the LDAP protocol stack and replication together as
>> part of the frontend since it is inherently part of the frontend.
>>
>>
> Hmmm, you may be right.
>
>> Just remember we cannot please everyone.  There will be people who want
>> just
>> the core but then find they will want replication too.  Those folks can
>> just
>> enable the frontend and get replication.  I don't see any other way.
>>
>>
> The only thing we can do is to allow a use who want to embed the server
> _and_ benefit from the replication as a consumer (not a producer). That
> means we must allow users to disable the incoming LDAP part in the
> LdapService. Should be easy.
>

Yeah.  But we need not do this now.  Let's just get this working and
organized properly wrt to the configuration.  Anyways users can use ACI and
other techniques to constrain what can be done through the LDAP service if
they want replication but do not want to expose LDAP.  This is definitely
icing on the configuration cake.

Alex

Mime
View raw message