CTDB secrets TDB issue

[miguel.sanders at arcelormittal.com]

Hi Michael

Thanks for your help.
That solved the issue! 


Met vriendelijke groet
Best regards
Bien à vous

Miguel SANDERS
ArcelorMittal Gent

UNIX Systems & Storage
IT Supply Western Europe | John Kennedylaan 51
B-9042 Gent

T +32 9 347 3538 | F +32 9 347 4901 | M +32478 805 023
E miguel.sanders at arcelormittal.com
www.arcelormittal.com/gent

-----Oorspronkelijk bericht-----
Van: Michael Adam [mailto:obnox at samba.org] 
Verzonden: woensdag 23 december 2009 23:45
Aan: SANDERS Miguel
CC: samba-technical at samba.org
Onderwerp: Re: CTDB secrets TDB issue

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.
> ****
> 


**** 
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.  
****