Editing SAMBA CLUSTER PUNJAB GOVT IFMS-IWDMS PROJECT

[[category:SAMBA]]
[[category:Punjab's IFMS-IWDMS Project]]

== Samba Cluster for Punjab's IFMS-IWDMS project ==
<center>Shashank Shekhar Tewari & Navdeep Mathur</center>

<center>Tetra Information Services</center>


= 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 ==

[[Image:Samba_pun.png]]

= <center>389-DS (Ldap Server)</center> =


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


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


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: 


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


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: 

<nowiki># chkconfig smb off </nowiki>


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: 


<nowiki><fencedevices></nowiki>

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

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

<nowiki></fencedevices> </nowiki>


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. 


<nowiki># service cman start</nowiki>


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


<nowiki># service ctdb start </nowiki>


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: 


<nowiki># ctdb status </nowiki>


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:

<nowiki># service nmb start</nowiki>


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

<nowiki>*/3 * * * * /root/scripts/nmbstartup.sh </nowiki>


The script is as follows:


<nowiki>#!/bin/sh </nowiki>

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: 

<nowiki># cat /etc/ctdb/public_addresses </nowiki>

192.168.10.93/0 eth1 


Node2: 

<nowiki># cat /etc/ctdb/public_addresses </nowiki>

192.168.10.93/0 eth0 


Common to both:

<nowiki># cat /etc/ctdb/nodes </nowiki>

192.168.10.81 

192.168.10.82 


<nowiki># grep gfs2 /etc/fstab </nowiki>

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

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


<nowiki># cat /etc/cluster/cluster.conf </nowiki>

<nowiki><?xml version="1.0"?> </nowiki>

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

<nowiki><clusternodes> </nowiki>

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

<nowiki><fence> </nowiki>

<nowiki><method name="fence-smb1ilo"> </nowiki>

<nowiki><device name="smb1ilo"/> </nowiki>

<nowiki></method> </nowiki>

<nowiki></fence> </nowiki>

<nowiki></clusternode> </nowiki>

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

<nowiki><fence> </nowiki>

<nowiki><method name="fence-smb2ilo"> </nowiki>

<nowiki><device name="smb2ilo"/> </nowiki>

<nowiki></method> </nowiki>


<nowiki></clusternode> </nowiki>

<nowiki></clusternodes> </nowiki>

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

<nowiki><fencedevices> </nowiki>

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

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

<nowiki></fencedevices> </nowiki>

<nowiki></cluster> </nowiki>


<center>End of PART 1 – Samba cluster installation</center>


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


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


• 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 http://directory.fedoraproject.org/download/ol-schema-migrate.pl]


We do this on the 389-DS server. 


Use of this script is straight forward : 


<nowiki># perl ol-schema-migrate.pl -b \</nowiki>

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

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


Once the ldif is in place restart the slapd service : 


<nowiki># service dirsrv restart </nowiki>


== PAM Configuration  ==
Chack if nss_ldap is installed with: 


<nowiki># rpm -qa|grep -i nss-ldap </nowiki>


otherwise: 


<nowiki># yum install nss-pam-ldapd</nowiki>


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.

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


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 


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


<nowiki>[global] </nowiki>

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 

<nowiki>;server string = PunjabGovt </nowiki>

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 


<nowiki>[netlogon] </nowiki>

path = /mnt/gfs2/samba/netlogon 

read only = yes 

browsable = no 

guest ok = yes 


<nowiki>[profiles] </nowiki>

path = /mnt/gfs2/samba/profiles 

read only = no 

create mask = 0600 

directory mask = 0700 


<nowiki>[homes] </nowiki>

browsable = no 

writable = yes 

path = /mnt/gfs2/share/%u 


<nowiki>[nitrobit] </nowiki>

path = /mnt/gfs2/samba/nitrobit 

read only = no 

public = yes 

browsable = yes 

writable = yes 

guest ok = yes 


<nowiki>[csmb] </nowiki>

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 : 


<nowiki># mkdir -p /mnt/gfs2/samba </nowiki>

<nowiki># mkdir /mnt/gfs2/samba/{netlogon,profiles} </nowiki>

<nowiki># chown root:root -R /mnt/gfs2/samba </nowiki>

<nowiki># chmod 0755 /mnt/gfs2/samba/netlogon </nowiki>

<nowiki># chmod 1755 /mnt/gfs2/samba/profiles </nowiki>


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


<nowiki># smbpasswd -w <ldap-admin-password> </nowiki>

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: 


<nowiki># service ctdb stop</nowiki>

<nowiki># net getlocalsid </nowiki>

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


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


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

objectclass: sambaDomain 

objectclass: sambaUnixIdPool 

objectclass: top 

<nowiki>sambaDomainName: <PUNJABGOVT> </nowiki>

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'


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


== 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- 

<nowiki># yum install migrationtools </nowiki>


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'} <nowiki>= "ou=Group"; </nowiki>


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


$NAMINGCONTEXT{'group'} <nowiki>= "ou=Groups"; </nowiki>


The rest can be modified as seen below : 


<nowiki># Default DNS domain </nowiki>

$DEFAULT_MAIL_DOMAIN = "pbifmsiwdms.pjb"; 


<nowiki># Default base </nowiki>

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


<nowiki># turn this on to support more general object clases </nowiki>

<nowiki># such as person.</nowiki>

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


<nowiki># /usr/share/openldap/migration/migrate_group.pl \</nowiki>

/tmp/sambaGroups > /tmp/sambaGroups.ldif 

<nowiki># cat /tmp/sambaGroups.ldif </nowiki>


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 : 


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


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


<nowiki># net groupmap add rid=512 ntgroup='Domain Admins' </nowiki>\

unixgroup='Domain Admins' 

<nowiki># net groupmap add rid=513 ntgroup='Domain Users' \</nowiki>

unixgroup='Domain Users' 

<nowiki># net groupmap add rid=514 ntgroup='Domain Guests' \</nowiki>

unixgroup='Domain Guests' 

<nowiki># net groupmap add rid=515 ntgroup='Domain Computers'\</nowiki>

unixgroup='Domain Computers' 


Verify : 


<nowiki># net groupmap list </nowiki>


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 : 


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

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


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


<nowiki># smbpasswd -a Administrator</nowiki>

<nowiki># pdbedit -U $( net getlocalsid | \</nowiki>

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 


<nowiki>[global] </nowiki>

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 <nowiki>*Retype\snew\sUNIX\spassword:* %n\n *password\supdated\ssuccessfully* . </nowiki>

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 

<nowiki>;server string = PunjabGovt </nowiki>

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 


<nowiki>[netlogon] </nowiki>

path = /mnt/gfs2/samba/netlogon 

read only = yes 

browsable = no 

guest ok = yes 


<nowiki>[profiles] </nowiki>

path = /mnt/gfs2/samba/profiles 

read only = no 

create mask = 0600 

directory mask = 0700 


<nowiki>[homes] </nowiki>

browsable = no 

writable = yes 

path = /mnt/gfs2/share/%u 


<nowiki>[nitrobit] </nowiki>

path = /mnt/gfs2/samba/nitrobit 

read only = no 

public = yes 

browsable = yes 

writable = yes 

guest ok = yes 


<nowiki>[csmb] </nowiki>

comment = Clustered Samba 

public = yes 

path = /mnt/gfs2/share 

writeable = yes 

ea support = yes 


Finally start the Samba service: 


<nowiki># service ctdb start; chkconfig ctdb on</nowiki>


= Troubleshooting =
== Cluster-specific troubleshooting ==
This following will show the current status of the cluster. Both nodes should show 'OK'.

<nowiki># ctdb status</nowiki>


The ctdb logs are generated here:

<nowiki># less /var/log/log.ctdb</nowiki>


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

<nowiki># service ctdb start</nowiki>


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

<nowiki># clustat </nowiki>


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

<nowiki># service nmb start</nowiki>


To check if an account can connect:

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


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

<nowiki># getent passwd <username></nowiki>

For example: 

<nowiki># getent passwd admin </nowiki>

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:

<nowiki># getent group 'Domain Admins' </nowiki>

Domain Admins:*:5122:admin 


== 'net' commands: ==
To see the group mappings:

<nowiki># net groupmap list</nowiki>


To add a group:

<nowiki># net groupmap add rid=513 \ </nowiki>

ntgroup='PUNJABGOVT\Domain Users' \

unixgroup='Domain Users'


To see a group's members:

<nowiki># net rpc group members "Domain Admins”</nowiki>


To see a members's groups:

<nowiki># net rpc user info admin</nowiki>


To get the SID:

<nowiki># net getdomainsid</nowiki>


If Samba root/administrator users are blocked

<nowiki># pdbedit –c=’[]’ –-user=root</nowiki>

<nowiki># pdbedit –c=’[U]’ –-user=root</nowiki>