On Sat, 2008-08-16 at 12:01 +0200, Oliver Liebel wrote:
> 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.
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)
> *** 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.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.