backend provision samba4-ol-multimaster
abartlet at samba.org
Sun Sep 7 03:06:11 GMT 2008
On Sat, 2008-09-06 at 18:40 +0200, Oliver Liebel wrote:
> Andrew Bartlett schrieb:
> > On Fri, 2008-09-05 at 10:37 +0200, Oliver Liebel wrote:
> >> e.g. rid=serverid*100 instead of ...*10
> > Sure, but then we have a maximum of 9 replicating servers, which seemed
> > like rather a low limit.
> sorry, youre right - i missed that point, was just looking at the
> but there is another point to mention: we should add the "sizelimit
> unlimited" ( or just a value greater 552 [cn=schema] )
> to slapd.conf-template again, otherwise we are running into trouble
> during initial content cload on the secondary dcs.
> > Yep, we need a separate account, but I can't see a good way to move away
> > from cleartext passwords.
> > ...
> > No, we cannot use GSSAPI. We must use something like DIGEST-MD5 because
> > we are creating the backend for the KDC, so we can't use kerberos to do
> > it :-)
> okay, if we would use digest-md5, what do you think about the following
Excellent. Please give me a patch with the sizelimit and these
> as there is no need for rootpws for the subcontexts now
> (which surely also can be kept there - maybe for debugging issues,
> using pre-crypted slappasswd-ssha-values),
> the only thing remaining in cleartext are the authcid and credentials in
> syncrepl-config, but as
> the replicator-account has only ro-privileges on the dit,
> its not that bad, even if someone could catch a look on the config...
Let's remove all the rootpw entries.
> another option could be (with the advantage of having no passwords at
> all in slapd.conf / slapd.d/ )
> to use mech external, but in that case we would have to setup
> the ca and all host-certs during provisioning, maybe using a fixed
> cert-dn, e.g. cn=<hostname>,cn=samba4dc,dc=<names.domaindn>
> or something like that.
> but as we have to setup tls for replication anyway, maybe its worth a
> so what do you think about the mech we should use?
> > I'm certainly quite OK with having a switch to inhibit the creation of
> > the actual cn=samba data.
> > If we do actually get as far as replicating cn=config, then perhaps this
> > same switch might be used to create a 'stub' slapd.conf with only enough
> > to replicate in cn=config?
> hm... do you mean (after we have converted the complete slapd to olc on
> the first dc) a switch (for the other dcs) that will activate
> a very small olc-replication config "from the scratch", which will fetch
> everything needed from the first dc?
> yes, i think we can get that done.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080907/50788468/attachment.bin
More information about the samba-technical