backend provision samba4-ol-multimaster working

[Oliver Liebel]

Andrew Bartlett schrieb:
>>> 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.
>>     
>
> Rather than use python string concatenation and appending writes, like
> the memberOf code does, read in the teamplate and use it to sub the
> variables.  (and then place that into the main config file multiple
> times, by means of a very long variable)
>   
okay, i will try to move the setup to make use of templating.
but to do this, please provide me just one little working example (i 
think the block/template of the
serverids and corresponding ldap-urls wil be a good point to start on 
it, as there will be
a various count too) and i will then try to adapt the procedure for the 
syncrepl-blocks.

>
>   
>> *** 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.
>>     
>
> Part of why I wasn't to worried about the 'look' of the config file (and
> once we get this patch in, we can discuss that) is that I would like to
> see this migrated to cn=config (eventually).  Having that set up and
> working with the MMR backend would be very neat.
>   
the context where delta-sync makes most sense
is the user/base-dn context, as this is the normal "working" context,
where most modifications are made.
 normally, the count of modification ops on schema/config is quite small,
so i think theres no need for delta-sync in these two cases,

and the use of cn=config should be possible:
-  as long as no delta-sync is used
-  as long as there is no need for some samba-specific
olc-attributes (as the corresponding objectclasses and attributes for olc
are hardcoded into slapd)

but we should keep both points til the template-based-mmr setup is working.
> Andrew Bartlett
>
>   

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