backend provision samba4-ol-multimaster

Andrew Bartlett abartlet at samba.org
Fri Sep 5 21:49:39 GMT 2008


On Fri, 2008-09-05 at 10:37 +0200, Oliver Liebel wrote:
> hi andrew,
> 
> i checked the latest version from git.
> there is still an (invisible) typo in setup/mmr_syncrepl.conf (tabulator 
> in the last line),
> which must be removed. else we catch an "bad config"-error when starting 
> slapd with mmr-config.
> another point -maybe just cosmetic- :  i think the rids are looking 
> better and
> are easier to read  when, we use a 3-value integer, as you mentioned the 
> first time.
> 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. 

> i tried several setups to test the cn=samba replication, which can 
> surely be done the easiest way
> by adding the following acl:
> access to dn.subtree="cn=samba"
>        by dn=cn=samba-admin,cn=samba read
>        by anonymous auth
> 
> as i understand it, the cn=samba-admin should not be created on
> all other dcs, except on the first one, and will then be replicated to 
> the others.
> if this is so, we must add a setup-directive to prevent the creation
> of this object during setup of the "secondary" dcs.
> 
> but i think to move away from the cleartext-passwords and
> get the replication of subcontexts done in a clean way,
> we should create a separate account (e.g. cn=replicator,cn=samba)

Yep, we need a separate account, but I can't see a good way to move away
from cleartext passwords. 

> that is mapped bei authz-regexp and has ro-access to all subcontexts.
> i would prefer to use syncrepl with saslmech GSSAPI (and authcid), but
> in this case we would need a principal for that object.

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 :-)

> would that be okay for you? and if yes, where should we start?

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?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080906/5fd75d94/attachment.bin


More information about the samba-technical mailing list