SAMBA CLUSTER PUNJAB GOVT IFMS-IWDMS PROJECT

Samba Cluster for Punjab's IFMS-IWDMS project

Shashank Shekhar Tewari & Navdeep Mathur Tetra Information Services

Introduction

The client wanted a high-availability Domain Controller, with a centralized authentication mechanism. To ensure this, Samba 3.5 was installed with 389-Directory server at the backend.

This document has been divided into two parts, one detailing the installation of the Samba cluster; and the other showing the steps taken to integrate it with the ldap server, 389-DS and configuring it as a Primary Domain Controller (PDC).

Prerequisites

1) yum must be configured to ensure Samba and other dependencies can be downloaded

2) Setup ssh logins via auth-keys. (Password-less login). While not necessary, this makes things work MUCH faster between all the servers.

3) 389-DS must already be setup prior to this installation

Servers

Two servers have been set up as follows:

pbifmsntp1.pbifmsiwdms.pjb - 192.168.10.81

pbifmsntp2.pbifmsiwdms.pjb - 192.168.10.82

The two servers are connected to a SAN, and the Samba shares as well as the cluster configuration files are stored here. The cluster used is Red Hat Cluster Suite (RHCS).

They are being fenced using HP's ILO v3.

Architecture Diagram

Installation of the cluster

The Samba service will be clustered using CTDB (Clustered TDB), with RHCS supporting it. The Red Hat Enterprise Linux 6.1 release provides support for running Clustered Samba. This requires that you install and configure CTDB on all nodes in a cluster, which you use in conjunction with GFS2 clustered file systems.

Active node: pbifmsntp1.pbifmsiwdms.pjb

Standby node: pbifmsntp2.pbifmsiwdms.pjb

Cluster service hostname: samba.pbifmsiwdms.pjb

Mounted HDD: /dev/mapper/csmb_vg-csmb_lv ; /dev/mapper/csmb_vg-csmb_lv

CTDB Overview

CTDB is a cluster implementation of the TDB database used by Samba. To use CTDB, a clustered file

system must be available and shared on all nodes in the cluster. CTDB provides clustered features

on top of this clustered file system. CTDB manages node membership, recovery/failover, IP relocation and Samba services.

Required Packages

In addition to the standard packages required to run the Red Hat High Availability Add-On and the Red Hat Resilient Storage Add-On, running Samba with Red Hat Enterprise Linux clustering requires the following packages. Install via 'yum':

• ctdb

• samba

• samba-common

• samba-winbind-clients

• pacemaker

• gfs2-utils

GFS2 Configuration

Configuring Samba with the Red Hat Enterprise Linux clustering requires two GFS2 file systems: One small file system for CTDB, and a second file system for the Samba share.

Before creating the GFS2 file systems, first create an LVM logical volume for each of the file systems.

We use the following volumes:

• /dev/csmb_vg/csmb_lv, which will hold the user data that will be exported via a Samba share.

• /dev/csmb_vg/ctdb_lv, which will store the shared CTDB state information and needs to be 1GB in size.

Clustered Samba Configuration

You create clustered volume groups and logical volumes on one node of the cluster only.

To create a GFS2 file system on a logical volume, run the mkfs.gfs2 command. You run this command on one cluster node only.

To create the file system to host the Samba share on the logical volume /dev/csmb_vg/csmb_lv, execute the following command:

# mkfs.gfs2 -j3 -p lock_dlm -t csmb:gfs2 /dev/csmb_vg/csmb_lv

The meaning of the parameters is as follows:

-j

Specifies the number of journals to create in the filesystem. This example uses a cluster with two nodes, so we create one journal per node. One journal is extra for future use.

-p

Specifies the locking protocol. lock_dlm is the locking protocol GFS2 uses for inter-node communication.

-t

Specifies the lock table name and is of the format cluster_name:fs_name. In our structure, the cluster name as specified in the cluster.conf file is csmb, and we use gfs2 as the name for the file system.

The /dev/csmb_vg/csmb_lv file system will be mounted at /mnt/gfs2 on all nodes. This mount point must match the value that you specify as the location of the share directory with the path = option in the /etc/samba/smb.conf file.

To create the file system to host the CTDB state information on the logical volume /dev/csmb_vg/ ctdb_lv, execute the following command:

# mkfs.gfs2 -j3 -p lock_dlm -t csmb:ctdb_state /dev/csmb_vg/ctdb_lv

Note that this command specifies a different lock table name than the lock table in the example that created the filesystem on /dev/csmb_vg/csmb_lv. This distinguishes the lock table names for the different devices used for the file systems.

In this example, the /dev/csmb_vg/ctdb_lv file system will be mounted at /mnt/ctdb on all nodes. This mount point must match the value that you specify as the location of the .ctdb.lock file with the CTDB_RECOVERY_LOCK option in the /etc/sysconfig/ctdb file.

CTDB Configuration

The CTDB configuration file is located at /etc/sysconfig/ctdb. The mandatory fields that must be configured for CTDB operation are as follows:

• CTDB_NODES

• CTDB_PUBLIC_ADDRESSES

• CTDB_RECOVERY_LOCK

• CTDB_MANAGES_SAMBA (must be enabled)

The following is our configuration file for CTDB operation:

CTDB_RECOVERY_LOCK="/mnt/ctdb/.ctdb.lock"

CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses

CTDB_MANAGES_SAMBA=yes

CTDB_MANAGES_WINBIND=no

CTDB_NODES=/etc/ctdb/nodes

CTDB_DEBUGLEVEL=ERR

The meaning of these parameters is as follows.

CTDB_NODES

Specifies the location of the file which contains the cluster node list.

The /etc/ctdb/nodes file that CTDB_NODES references simply lists the IP addresses of the cluster nodes, as in the following example:

192.168.10.81

192.168.10.82

CTDB_PUBLIC_ADDRESSES

Specifies the location of the file that lists the IP addresses that can be used to access the Samba shares exported by this cluster. These are the IP addresses that you should configure in DNS for the name of the clustered Samba server and are the addresses that CIFS clients will connect to.

The contents of the /etc/ctdb/public_addresses file on node1 is:

192.168.10.93/0 eth1

And node 2:

192.168.10.93/0 eth0

CTDB_RECOVERY_LOCK

Specifies a lock file that CTDB uses internally for recovery. This file must reside on shared storage such that all the cluster nodes have access to it. We use the GFS2 file system that will be mounted at /mnt/ctdb on all nodes. This is different from the GFS2 file system that will host the Samba share that will be exported. This recovery lock file is used to prevent split-brain scenarios.

CTDB_MANAGES_SAMBA

When enabling by setting it to yes, specifies that CTDB is allowed to start and stop the Samba service as it deems necessary to provide service migration/failover.

When CTDB_MANAGES_SAMBA is enabled, you should disable automatic init startup of the smb daemons by executing the following commands:

# chkconfig smb off

CTDB_MANAGES_WINBIND

When enabling by setting it to yes, specifies that CTDB is allowed to start and stop the winbind daemon as required.

The smb.conf configuration file must be identical on all of the cluster nodes. We will modify the file when we integrate it with 389-DS.

After starting up the cluster, you must mount the GFS2 file systems that you created. The permissions on the Samba share directory and user accounts on the cluster nodes should be set up for client access.

Fencing

We now change cluster.conf manually to define our fencing devices.

(While luci-ricci can be used, I personally prefer editing the conf file directly due to the random bugs that keep popping up in luci-ricci.)

The fence that we are using is HP's ILO v3. This version specifically uses 'fence_ipmilan', and NOT 'fence_ilo' as was the case with v2.

The cluster packages also need to be updated, (at least the files from RHEL 6.2) else it will not work.

The fence-agents used here was "fence-agents-3.1.5-10.el6.x86_64".

We need the IP address, username and password for access the ILO interface.

/etc/cluster.conf is edited as follows:

<fencedevices>

<fencedevice agent="fence_ipmilan" ipaddr="192.168.10.181" lanplus="1" login="user" name="smb1ilo" passwd="password" power_wait="15"/>

<fencedevice agent="fence_ipmilan" ipaddr="192.168.10.182" lanplus="1" login="user" name="smb2ilo" passwd="password" power_wait="15"/>

</fencedevices>

Please note that 'lanplus' needs to be enabled, and 'power_wait' has to be at least 15, else the fence will fail. Also ensure that the user has the privileges to manage the machine in the ILO. To check whether the fencing is working, we can run the following command:

fence_ipmilan -a 192.168.10.181 -l username -p password \

-o status -P -T 15

rsync the edited file to the standby node as well.

Starting the cluster

After the cluster configuration file is copied to the standby node, you can start the Red Hat Cluster Suite Daemons.

Important: In order to start the cluster daemons correctly, you must be

logged on to each node before proceeding, and to see any errors, you should have two sessions open for each node. You enter a command for one node, then enter the same command for the second. You must enter each command on both nodes, before proceeding to the next command.

Important:

Run tail -f /var/log/messages, on each node to watch for any errors.

To recap, we need two sessions on each node, one running 'tailf /var/log/messages', and the other to run commands. tmux is highly recommended to make all of this easier.

Log on to each node as root.

To start the Red Hat Cluster Service on a member, execute the following commands on all of the nodes to start up the cluster. Since we have configured CTDB with CTDB_MANAGES_SAMBA=yes, CTDB will also start up the Samba service on all nodes and export all configured Samba shares.

# service cman start

This is the cluster manager. This starts all the relevant services.

# service ctdb start

This is the ctdb daemon.

It can take a couple of minutes for CTDB to start Samba, export the shares, and stabilize. Executing ctdb status shows the status of CTDB, as in the following example:

# ctdb status

Number of nodes:2

pnn:0 192.168.10.81 OK (THIS NODE)

pnn:1 192.168.10.82 OK

Generation:1101525957

Size:2

hash:0 lmaster:0

hash:1 lmaster:1

Recovery mode:NORMAL (0)

Recovery master:1

When you see that all nodes are "OK", it is safe to move on to use the clustered Samba server.

Problem with NMB

The NMB daemon fails when ctdb starts. When started manually, it works as expected. This has been found to be a bug, and was prevented by running a script in crontab.

Execute the following to start it manually:

# service nmb start

The script is located in /root/scripts on both the servers and is listed in crontab:

*/3 * * * * /root/scripts/nmbstartup.sh

The script is as follows:

#!/bin/sh

if ! /sbin/service nmb status

then

/sbin/service nmb start

fi

Testing the Cluster Set up

To perform a quick test to see if failover works:

1. Log in to the remote power switch and turn off the active node.

2. Run tail -f /var/log/messages on the standby node. You will observe the cluster becomes aware of the failed node, I/O fence it, and bring up the failed service on the standby node.

Configuration files

Node1:

# cat /etc/ctdb/public_addresses

192.168.10.93/0 eth1

Node2:

# cat /etc/ctdb/public_addresses

192.168.10.93/0 eth0

Common to both:

# cat /etc/ctdb/nodes

192.168.10.81

192.168.10.82

# grep gfs2 /etc/fstab

/dev/mapper/csmb_vg-csmb_lv /mnt/gfs2 gfs2 defaults 0 0

/dev/mapper/csmb_vg-ctdb_lv /mnt/ctdb gfs2 defaults 0 0

# cat /etc/cluster/cluster.conf

<?xml version="1.0"?>

<cluster name="csmb" config_version="1">

<clusternodes>

<clusternode name="pbifmsntp1.pbifmsiwdms.pjb" nodeid="1">

<fence>

<method name="fence-smb1ilo">

<device name="smb1ilo"/>

</method>

</fence>

</clusternode>

<clusternode name="pbifmsntp2.pbifmsiwdms.pjb" nodeid="2">

<fence>

<method name="fence-smb2ilo">

<device name="smb2ilo"/>

</method>

</clusternode>

</clusternodes>

<cman two_node="1" expected_votes="1"/>

<fencedevices>

<fencedevice agent="fence_ipmilan" ipaddr="192.168.10.181" lanplus="1" login="user" name="smb1ilo" passwd="password" power_wait="15"/>

<fencedevice agent="fence_ipmilan" ipaddr="192.168.10.182" lanplus="1" login="user" name="smb2ilo" passwd="password" power_wait="15"/>

</fencedevices>

</cluster>

End of PART 1 – Samba cluster installation

Integration of Samba with 389-Directory Server

Requirements

• openldap-servers (contains migration utilities used in this document)

• 389-DS (the directory server should already be installed)

• samba, samba-client, samba-common (samba server, also provides schema needed for storing samba information)

• schema to ldif migration script (can be downloaded from here:

http://directory.fedoraproject.org/download/ol-schema-migrate.pl)

First off we need to provide 389-DS with a samba schema that it understands. Now lets break down how 389-DS implements extending schemas :

• All schema files are in ldif format and loaded during server start .

• All schema's are located in /opt/389-DS/slapd-<server>/config/schema, where <server> is 'ldap1' or 'ldap2', as the case may be.

• Filenames are sequential and loaded in order and 99user.ldif is always the last schema to be loaded.

For this document we are going to name our schema file 61samba.ldif. As stated above we need to provide 389-DS with a schema it understands which involves converting the provided /usr/share/doc/samba/LDAP/samba.schema to ldif format. Luckily, there is a utility provided 3rd party that will assist in doing this which can be found at http://directory.fedoraproject.org/download/ol-schema-migrate.pl

We do this on the 389-DS server.

Use of this script is straight forward :

# perl ol-schema-migrate.pl -b \

/usr/share/doc/samba-*/LDAP/samba.schema \

> /etc/dirsrv/slapd-<server>/schema/61samba.ldif

Once the ldif is in place restart the slapd service :

# service dirsrv restart

PAM Configuration

Chack if nss_ldap is installed with:

# rpm -qa|grep -i nss-ldap

otherwise:

# yum install nss-pam-ldapd

On both the samba nodes, run this:

authconfig --enableldap --enableldapauth --disablenis \

--enablecache –ldapserver=ldap1.pbifmsiwdms.pjb\

--ldapbasedn=dc=pbifmsiwdms,dc=pjb --updateall

Rsync the 'cacert.asc' from the ldap server to the samba server.

# rsync -Pa ldap1:/etc/dirsrv/slapd-ldap1/cacert.asc \ /etc/openldap/cacerts/cacert.asc

Add the cacert.asc file of the second master below this entry.

Then ensure ldap.conf has the following settings:

URI ldap://ldap1.pbifmsiwdms.pjb/ ldap://ldap2.pbifmsiwdms.pjb/

TLS_CACERTDIR /etc/openldap/cacerts

TLS_REQCERT allow

TLS_CACERT /etc/openldap/cacerts/cacert.asc

BASE dc=pbifmsiwdms,dc=pjb

HOST pbifmsntp1.pbifmsiwdms.pjb

binddn "cn=Directory manager"

bindpw asd1234f

rootbinddn "cn=Directory manager"

port 389

bind_policy soft

nss_reconnect_tries 2

nss_base_passwd ou=People,dc=pbifmsiwdms,dc=pjb?one

nss_base_passwd ou=Computers,dc=pbifmsiwdms,dc=pjb?one

nss_base_shadow ou=People,dc=pbifmsiwdms,dc=pjb?one

nss_base_group ou=Groups,dc=pbifmsiwdms,dc=pjb?one

Without configuring ldap.conf, samba will not search posix accounts into ldap. Also, ensure that DNS has been setup.

Samba Setup

Change /etc/nsswitch.conf to have the following:

passwd: files ldap sss

shadow: files ldap sss

group: files ldap sss

Modify /etc/samba/smb.conf to have the following values (remember that 'PUNJABGOVT' string length < 14)

[global]

workgroup = PUNJABGOVT

netbios name = PUNJABGOVT1

hosts allow = 127.0.0.1 192.168.10.0/24 192.168.20.0/24 192.168.70.0/24

security = user

passdb backend = ldapsam:"ldap://ldap1.pbifmsiwdms.pjb ldap://ldap2.pbifmsiwdms.pjb"

ldap admin dn = cn=Directory manager

ldap suffix = dc=pbifmsiwdms,dc=pjb

ldap user suffix = ou=People

ldap machine suffix = ou=Computers

ldap group suffix = ou=Groups

ldap passwd sync = yes

obey pam restrictions = no

passwd program = /usr/bin/passwd %u

passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .

log file = /var/log/samba/%m.log

log level = 3

max log size = 1000

syslog only = no

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

os level = 65

domain logons = yes

domain master = yes

local master = yes

preferred master = yes

wins proxy = yes

wins support = yes

logon home = \\%L\%U

logon path = \\%L\%U\profile

logon drive = H:

template shell = /bin/false

name resolve order = wins lmhosts hosts bcast

encrypt passwords = yes

logon script = logon.cmd

add user script = /usr/sbin/adduser %u

add machine script = /usr/sbin/smbldap-useradd -W %u

lm announce = yes

pam password change = yes

enable privileges = yes

;server string = PunjabGovt

dns proxy = no

winbind enum groups = No

winbind trusted domains only = yes

winbind use default domain = no

map untrusted to domain = Yes

map to guest = bad user

username map = /etc/samba/smbusers

clustering = yes

client lanman auth = Yes

add group script = /usr/sbin/smbldap-groupadd -p "%g"

delete group script = /usr/sbin/smbldap-groupdel "%g"

add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"

admin users = root

[netlogon]

path = /mnt/gfs2/samba/netlogon

read only = yes

browsable = no

guest ok = yes

[profiles]

path = /mnt/gfs2/samba/profiles

read only = no

create mask = 0600

directory mask = 0700

[homes]

browsable = no

writable = yes

path = /mnt/gfs2/share/%u

[nitrobit]

path = /mnt/gfs2/samba/nitrobit

read only = no

public = yes

browsable = yes

writable = yes

guest ok = yes

[csmb]

comment = Clustered Samba

public = yes

path = /mnt/gfs2/share

writeable = yes

ea support = yes

Create appropriate directories/permissions for the Samba shares defined in your configuration :

# mkdir -p /mnt/gfs2/samba

# mkdir /mnt/gfs2/samba/{netlogon,profiles}

# chown root:root -R /mnt/gfs2/samba

# chmod 0755 /mnt/gfs2/samba/netlogon

# chmod 1755 /mnt/gfs2/samba/profiles

Create a password for the ldap admin dn (the Directory Manager's Password) in Samba's secret file:

# smbpasswd -w <ldap-admin-password>

Setting stored password for "cn=Directory Manager" in secrets.tdb

Populating 389-DS with PDC Entry

At this point you should have a Samba PDC and a properly configured 389-DS ready to take the appropriate Samba entries. Now we are going to provide an entry into 389-DS for your PDC.

First get the Samba SID for your PDC. Note that the samba should not be running to get local SID. To do this, we first shutdown ctdb, then get the SID:

# service ctdb stop

# net getlocalsid

SID for domain PUNJABGOVT is: S-1-5-21-4070117540-217532476-2757550252

Next create your Samba Domain ldif(/tmp/sambaDomainName.ldif) for entry:

dn: sambaDomainName=<PUNJABGOVT>,dc=pbifmsiwdms,dc=pjb

objectclass: sambaDomain

objectclass: sambaUnixIdPool

objectclass: top

sambaDomainName: <PUNJABGOVT>

sambaSID: S-1-5-21-4070117540-217532476-2757550252

uidNumber: 550

gidNumber: 550

Populate your 389-DS with the above entry. This can be run on only one server, as it will be replicated to the other.

NOTE: There is an error in ldap2ldif. Open 'ldif2ldap' script, change 'PATH=:$prefix' to 'PATH=$PATH:$prefix:' . Also change 'ldapmodify' to include '-h localhost'

# /usr/lib64/dirsrv/slapd-ldap1/ldif2ldap "cn=Directory manager" password /tmp/sambaDomainName.ldif

Migrating Samba groups and populating 389-DS with Samba Users

This is where the openldap migration scripts are going to come in handy. Run these on any one of the Samba servers:

First install the scripts-

# yum install migrationtools

Lets modify the file /usr/share/openldap/migration/migrate_common.ph to apply our default domain and base.

Search for the following OrganizationalUnit :

$NAMINGCONTEXT{'group'} = "ou=Group";

Default install of 389-DS will require this to be 'Groups', please change as follows :

$NAMINGCONTEXT{'group'} = "ou=Groups";

The rest can be modified as seen below :

# Default DNS domain

$DEFAULT_MAIL_DOMAIN = "pbifmsiwdms.pjb";

# Default base

$DEFAULT_BASE = "dc=pbifmsiwdms,dc=pjb";

# turn this on to support more general object clases

# such as person.

$EXTENDED_SCHEMA = 1;

Once complete we are now going to create our Samba Domain Groups. Open up a new file /tmp/sambaGroups and add the following :

Domain Admins:x:5122:

Domain Users:x:11503:

Domain Guests:x:11504:

Domain Computers:x:11505:

Note: These are your UNIX groups, created in LDAP! They must exist on the Directory Server group list first! (if you do not have PAM setup)

Next convert /tmp/sambaGroups into an ldif to be imported into 389-DS :

# /usr/share/openldap/migration/migrate_group.pl \

/tmp/sambaGroups > /tmp/sambaGroups.ldif

# cat /tmp/sambaGroups.ldif

dn: cn=Domain Admins,ou=Groups,dc=pbifmsiwdms,dc=pjb

objectClass: posixGroup

objectClass: top

cn: Domain Admins

userPassword: {crypt}x

gidNumber: 5122

dn: cn=Domain Users,ou=Groups,dc=pbifmsiwdms,dc=pjb

objectClass: posixGroup

objectClass: top

cn: Domain Users

userPassword: {crypt}x

gidNumber: 11503

dn: cn=Domain Guests,ou=Groups,dc=pbifmsiwdms,dc=pjb

objectClass: posixGroup

objectClass: top

cn: Domain Guests

userPassword: {crypt}x

gidNumber: 11504

dn: cn=Domain Computers,ou=Groups,dc=pbifmsiwdms,dc=pjb

objectClass: posixGroup

objectClass: top

cn: Domain Computers

userPassword: {crypt}x

gidNumber: 11505

Now rsync the sambaGroups file to one of the 389-DS servers and import /tmp/sambaGroups.ldif into 389-DS :

# /usr/lib64/dirsrv/slapd-<server>/ldif2ldap "cn=Directory manager" password /tmp/sambaGroups.ldif

Map the Samba groups to the Linux groups (Run on the Samba server):

# net groupmap add rid=512 ntgroup='Domain Admins' \

unixgroup='Domain Admins'

# net groupmap add rid=513 ntgroup='Domain Users' \

unixgroup='Domain Users'

# net groupmap add rid=514 ntgroup='Domain Guests' \

unixgroup='Domain Guests'

# net groupmap add rid=515 ntgroup='Domain Computers'\

unixgroup='Domain Computers'

Verify :

# net groupmap list

Lets create a Samba Administrator account with an RID of 500. Create a file /tmp/sambaAdmin with the following :

Administrator:x:0:0:Samba Admin:/root:/bin/bash

Migrate /tmp/sambaAdmin to the formatted ldif and import into 389-DS :

# /usr/share/openldap/migration/migrate_passwd.pl /tmp/sambaAdmin > /tmp/sambaAdmin.ldif

# /usr/lib64/dirsrv/slapd-<server>/ldif2ldap "cn=Directory manager" password /tmp/sambaAdmin.ldif

Create a Samba Administrator account and modify the account to use the correct Samba SID :

# smbpasswd -a Administrator

# pdbedit -U $( net getlocalsid | \

sed 's/SID for domain PUNJABGOVT is: //' )-500 -u Administrator -r

PDC across subnets

Windows machines find the Samba server via NetBios. With the default configuration, this takes place only in the subnet the server is in. To enable the PDC across subnets, we need to configure Samba as a WINS (Windows Internet Name Service) Server.

To ensure this, we enter the following lines in smb.conf:

domain master = yes

preferred master = yes

local master = yes

wins support = yes

wins proxy = yes

os level = 65

Samba's smb.conf

Including all the relevant settings, our final smb.conf will look as follows. The cluster has been configured with 'clustering=yes'.

Nitrobit has been configured to use this following directory:

/mnt/gfs2/samba/nitrobit

[global]

workgroup = PUNJABGOVT

netbios name = PUNJABGOVT1

hosts allow = 127.0.0.1 192.168.10.0/24 192.168.20.0/24 192.168.70.0/24

security = user

passdb backend = ldapsam:"ldap://ldap1.pbifmsiwdms.pjb ldap://ldap2.pbifmsiwdms.pjb"

ldap admin dn = cn=Directory manager

ldap suffix = dc=pbifmsiwdms,dc=pjb

ldap user suffix = ou=People

ldap machine suffix = ou=Computers

ldap group suffix = ou=Groups

ldap passwd sync = yes

obey pam restrictions = no

passwd program = /usr/bin/passwd %u

passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* .

log file = /var/log/samba/%m.log

log level = 3

max log size = 1000

syslog only = no

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

os level = 65

domain logons = yes

domain master = yes

local master = yes

preferred master = yes

wins proxy = yes

wins support = yes

logon home = \\%L\%U

logon path = \\%L\%U\profile

logon drive = H:

template shell = /bin/false

name resolve order = wins lmhosts hosts bcast

encrypt passwords = yes

logon script = logon.cmd

add user script = /usr/sbin/adduser %u

add machine script = /usr/sbin/smbldap-useradd -W %u

lm announce = yes

pam password change = yes

enable privileges = yes

;server string = PunjabGovt

dns proxy = no

winbind enum groups = No

winbind trusted domains only = yes

winbind use default domain = no

map untrusted to domain = Yes

map to guest = bad user

username map = /etc/samba/smbusers

clustering = yes

client lanman auth = Yes

add group script = /usr/sbin/smbldap-groupadd -p "%g"

delete group script = /usr/sbin/smbldap-groupdel "%g"

add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"

admin users = root

[netlogon]

path = /mnt/gfs2/samba/netlogon

read only = yes

browsable = no

guest ok = yes

[profiles]

path = /mnt/gfs2/samba/profiles

read only = no

create mask = 0600

directory mask = 0700

[homes]

browsable = no

writable = yes

path = /mnt/gfs2/share/%u

[nitrobit]

path = /mnt/gfs2/samba/nitrobit

read only = no

public = yes

browsable = yes

writable = yes

guest ok = yes

[csmb]

comment = Clustered Samba

public = yes

path = /mnt/gfs2/share

writeable = yes

ea support = yes

Finally start the Samba service:

# service ctdb start; chkconfig ctdb on

Troubleshooting

Cluster-specific troubleshooting

This following will show the current status of the cluster. Both nodes should show 'OK'.

# ctdb status

The ctdb logs are generated here:

# less /var/log/log.ctdb

To start/stop the ctdb, and subsequently the samba daemon:

# service ctdb start

This will show the status of the cluster. Only the membership details will be shown, as rgmanager is not handling the service, ctdb is.

# clustat

Samba troubleshooting

If the client computers get the error that they cannot contact the Domain Controller specified, then check if nmb is running. If not, start it.

# service nmb start

To check if an account can connect:

# smbclient -L samba.pbifmsiwdms.pjb -U <username>

To check if a user is read from the ldap server:

# getent passwd <username>

For example:

# getent passwd admin

admin:*:11071:5122:System User:/home/admin:/bin/bash

This will show the user's POSIX details, as stored on the 389-DS server.

It can be similarly used for groups, as follows:

# getent group 'Domain Admins'

Domain Admins:*:5122:admin

'net' commands:

To see the group mappings:

# net groupmap list

To add a group:

# net groupmap add rid=513 \

ntgroup='PUNJABGOVT\Domain Users' \

unixgroup='Domain Users'

To see a group's members:

# net rpc group members "Domain Admins”

To see a members's groups:

# net rpc user info admin

To get the SID:

# net getdomainsid

If Samba root/administrator users are blocked

# pdbedit –c=’[]’ –-user=root

# pdbedit –c=’[U]’ –-user=root