backend provision samba4-ol-multimaster working
oliver at itc.li
Mon Aug 18 11:18:34 GMT 2008
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
>> 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
>> *** 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
More information about the samba-technical