CTDB secrets TDB issue

[Michael Adam]

Hi Miguel,

this is active-active clustering, so the samba servers running on
the nodes should appear as instances of the _same_ samba server.
Hence they should have an identical configuration.
What is missing from your config is a common "netbios name"
setting. With your config each node will pick its host nam as
netbios name, and the joins you did, actually joined different
machines... Actually, any command like "net ads join" that
affects the whole server, should only needed to be run on on of
the nodes. So please add something like "netbios name = mycluster"
to both nodes' config and retry.

Cheers - Michael

miguel.sanders at arcelormittal.com wrote:
> Hi folks
> 
> I'm currently setting up a CTDB cluster of two nodes (nodeA and nodeB),
> both of which have security = ads.
> CTDB is functioning fine but I'm observing some strange anomalies with
> the clustered secrets TDB.
> The basic smb.conf on both nodes looks like:
> [global]
>         workgroup = XYZ
>         realm = XYZ.BE
>         security = ads
>         clustering = yes
>         idmap backend = tdb2
>         fileid:mapping = fsname
>         vfs objects = gpfs fileid
>         gpfs:sharemodes = No
>         force unknown acl user = yes
>         winbind separator = +
>         idmap uid = 10000-20000
>         idmap gid = 10000-20000
> [TMP]
>         path = /gpfsFS1/tmp
>         writeable = yes
>         vfs objects = gpfs fileid
> 
> 
> Here are my chronological observations:
> 
> 1) No TDBs on nodeA and nodeB (samba/CTDB)
> 2) Start CTDB cluster with CTDB_MANAGES_SAMBA="no" and
> CTDB_MANAGES_WINBIND="no"
> 3) Run net ads join on nodeA: succesful
> 4) secrets.tdb is created on both nodes via CTDB (secrets.tdb.0 for
> nodeA and secrets.tdb.1 for nodeB)
> 5) startup winbind on nodeA
> 6) wbinfo -t on nodeA : OK (checking the trust secret via RPC calls
> succeeded)
> 7) Run net ads join on nodeB: succesful
> 8) startup winbind on nodeB
> 9) wbinfo -t on nodeB : OK (checking the trust secret via RPC calls
> succeeded)
> 10) wbinfo -t on nodeA : NOK (checking the trust secret via RPC calls
> failed ; error code was NT_STATUS_ACCESS_DENIED (0xc0000022) ; Could not
> check secret)
> 11) Run net ads join on node A
> 12) wbinfo -t on nodeA : OK (checking the trust secret via RPC calls
> succeeded)
> 13) wbinfo -t on nodeB : NOK (checking the trust secret via RPC calls
> failed ; error code was NT_STATUS_ACCESS_DENIED (0xc0000022) ; Could not
> check secret)
> 
> So the only conclusion is that that de clustered secrets TDB only
> functions for the last cluster node that successfully joined the domain.
> Did I do anything wrong? If not, any idea on how to debug this?
> 
> Cheers
> 
> Miguel
> 
> ****
> This message and any attachment are confidential, intended solely for the use of the individual or entity to whom it is addressed and may be protected by professional secrecy or intellectual property rights.
> If you have received it by mistake, or are not the named recipient(s), please immediately notify the sender and delete the message. You are hereby notified that any unauthorized use, copying or dissemination of any or all information contained in this message is prohibited.
> Arcelormittal shall not be liable for the message if altered, falsified, or in case of error in the recipient.
> This message does not constitute any right or commitment for ArcelorMittal except when expressly agreed otherwise in writing in a separate agreement.
> ****
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091223/8849cb56/attachment.pgp>