backend provision samba4-ol-multimaster working

[Oliver Liebel]

Andrew Bartlett schrieb:
> On Fri, 2008-08-15 at 23:11 +0200, Oliver Liebel wrote:
>   
>> hi andrew,
>>
>> as you have said:
>>     
>>> The biggest challenge will be making the
>>> configuration completely general (ie, working for any number of
>>> replicas). 
>>>       
>> here are the good news: i got the provision-backend script working with 
>> (n) mmr-servers now, tested it with 4 ...
>>     
>
> Great!
>
>   
>> the provisioning-backend script takes now --ol-mmr-urls=<list of (n) 
>> whitespace-separated urls> as
>> input, the urls are splitted internally; thanks to michael for the 
>> "(none,*.split(' '))"-tip.
>>
>> i made use of all mmr-related pre-configured variables, but i didnt
>> made it with templating. instead, the script generates 4 configs on the 
>> fly with everything needed:
>> - auto-generated server-ids with correspondig ldap-urls:<port>
>>     
>
> Nicely done.
>
>   
>> - replica -blocks for all 3 subcontexts (schema|config|user) with 
>> auto-generated rids, provider-dns, searchbases and binddns for every 
>> mmr-node
>> which are included into slapd.conf.
>>     
>
> I would still really prefer it used the template system (rather than the
> hand-pasted strings).  It makes it much easier to see the options that
> can be modified, from the set of templates rather than deep in
> provision.py.  
>
>   
maybe i understood you wrong, but here are no hand-pasted string... or 
do you mean the auto-generated-strings
written during setup into the confs?

i did it this way (in a loop) for several reasons:
in this special case, there are not so many options (exactly: none) that 
could -or should- be modified anyway, except the
provided urls (or sasl/tls-options later, see below), and these options 
are given during setup.
the 3 dns of the sub-contexts are auto-generated as they have always the 
same dn and are
always related to the base dn. 
its very easy to increase the serverids and rids for every context in 
conjunction with the ldap-urls,
i couldnt get the concept of how to get this done with templates.
>> if mmr is not chosen during setup, the confs are created empty with just 
>> a comment line (### no mmr config active ###).
>> so the include-statements dont cause any trouble.
>>  
>> the advantage of the excluded confs is a more clearly structure of 
>> slapd.conf,
>> in particular when a high count of mmr-nodes has been set up.
>>     
>
> This is also how I used to have the memberOf configuration.  I moved it
> into the main file so that when I filed bugs with the OpenLDAP folks,
> everything important was in a single file.  
>   
okay, surely one point of view.  but includes are a main concept of 
slapd.conf, exactly for the reason
to keep the main file "clean".  and i think its easy to paste them 
together in case of filing an its.

> I don't mind too much, but perhaps include it in the slapd.conf for now,
> and we can move them both out as a separate patch?
>   
i had the same proposal concerning excluding the whole memberof-conf 
part (as its really a big part),
but yesterday it was late, and i forgot to add this point in my mail.
>   
>> apropos high count of mmr-nodes:
>> although its surely a nice feature to use (n) ol- (or fds-) server in 
>> multimaster-setup
>> configuration -  maybe we should mark with a little comment during 
>> setup, that a
>> high count of mmr-servers may (or better -will-) cause a lot of 
>> additional traffic on the net.
>>     
>
> How much?  What is the replication topology?
>   
that depends on some factors, that howard can surely better explain.
first is the amount of data, thats modified ***,
second the count of nodes (every node speaks to every other node,
every time a modification is made in the dit (- more mmr nodes, more 
traffic),
and third surely the bandwith of the used network.

replication topology in mmr is always on the same hierarchy-level (flat)
as all nodes are masters/providers.

*** this could be reduced in our case, as we dont make use of the 
online-config (ldif-db)
for the schema- and config-subcontexts. so we can use delta-syncrepl, 
which will
reduce the overhead a lot.

>> phhh... think i got me a beer or two tomorrow, before i start with the 
>> to-do list ;-)
>>     
>
> You deserve it, you have done very well. 
>
> Thanks!
>
> Andrew Bartlett
>
>   

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 18.5009 from 16.08.2008
Virus news: www.antiviruslab.com