samba fails when ServiceGuard package fails over to new node

[Adam DuPont]

I have a ServiceGuard package running samba on three HP-UX 11.31 nodes with samba security mode set to DOMAIN. When I fail the package over to another node, samba quits working meaning users cannot authenticate to our domain server. Every time the package fails over to another node I have to reset the account (SG package) on Active Directory and then run ‘/opt/samba/bin/net rpc join’ and samba works just fine again. Are there any ideas why I this happens after failover and is there anyway this can be prevented?

[Matti_Kurkela · Accepted solution]

I guess your "net rpc join" sets up the domain membership using the hostname of the individual SG node, or the domain membership data does not fail over along with the package for some reason.

After the package moves to another node, the domain servers "see" that the triplet of hostname + IP address + domain member info is not what it's supposed to be.

The important directories would be /var/opt/samba/private and /etc/opt/samba for a HP standard Samba installation. Of course, the directory paths can be changed by configuration. These directories (or their equivalents) must travel along with the package.

You should also make sure that Samba communicates with the domain server using the package IP address(es) only.

When joining the domain, the join must be done using the identity of the package, not with the identity of the individual node. I'm afraid the "net rpc join" command assumes that you'll want to use the identity (hostname) of the node unless explicitly specified otherwise.

MK

[Adam DuPont]

Thanks Matti. The key was the /var/opt/samba/private directory. I have it setup so that part of the smb.conf file follows the package while part stays local. The fix was to specify the private directory to follow the package as well. I had to set "private dir = " in smb.conf to make sure it followed the package and now samba works when the package fails over to the other nodes.

[Adam DuPont]

See previous comment.