Andrew Bartlett schrieb:
maybe i understood you wrong, but here are no hand-pasted string... or
do you mean the auto-generated-strings
On Fri, 2008-08-15 at 23:11 +0200, Oliver Liebel wrote:
as you have said:
here are the good news: i got the provision-backend script working with
(n) mmr-servers now, tested it with 4 ...
The biggest challenge will be making the
configuration completely general (ie, working for any number of
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
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>
- replica -blocks for all 3 subcontexts (schema|config|user) with
auto-generated rids, provider-dns, searchbases and binddns for every
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
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.
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.
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
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.
i had the same proposal concerning excluding the whole memberof-conf
part (as its really a big part),
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?
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
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
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
for the schema- and config-subcontexts. so we can use delta-syncrepl,
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.
Virus checked by G DATA AntiVirusKit
Version: AVK 18.5009 from 16.08.2008
Virus news: www.antiviruslab.com