Configuration Restrictions

The configuration restrictions in the subsections that follow apply only to Sun Cluster HA for Samba.

Your data service configuration might not be supported if you do not observe these restrictions.

Restriction for the supported configurations of Samba

Sun Cluster HA for Samba supports Samba in the following configurations.

• Primary Domain Controller (PDC).

• Backup Domain Controller (BDC) to a Samba PDC.

• NT4 domain member server with or without winbind.

• Active Directory domain member server with or without winbind.

• Standalone configuration.

Sun Cluster HA for Samba is supported in the following Sun Cluster configurations.

• smbd and nmbd can only be configured to run within a failover resource group.

• winbindd can be configured to run within a failover or scalable resource group.

• All components can run in a global, non-global or failover zone. See Restriction for multiple Samba instances that require winbind for more information.

Restriction for the Location of Samba files

The Samba files are where the Samba shares and smb.conf files are stored. The Sun Cluster HA for Samba data service requires that these files are stored within a configuration directory that reflects the NetBIOS name for the Samba or winbind instance. The Samba files needs to be placed on shared storage as either a cluster file system or a highly available local file system.

The following deployment example has been taken from Appendix A, Deployment Example: Installing Samba packaged with Solaris 10, where the configuration directory is /local/samba/smb1 which is a highly available local file system and the NetBIOS name is smb1.

Vigor5# mkdir -p /local/samba/smb1
Vigor5# cd /local/samba/smb1
Vigor5# mkdir -p lib logs private shares var/locks

If Samba is downloaded and compiled from http://www.samba.org you may also want to consider placing these binaries on a cluster file system or highly available local file system.

Refer to Determining the Location of Application Binaries in Sun Cluster Data Services Planning and Administration Guide for Solaris OS for a discussion on cluster file systems and highly available local file systems.

Restriction for the Samba smb.conf files

The Samba smb.conf file is a configuration file that is used by the Samba and winbind instances.

The Sun Cluster HA for Samba data service requires that these files are located at configuration-directory/lib/smb.conf. Depending on how Samba is deployed the following restrictions apply.

Each Samba instance requires a unique configuration directory that reflects the NetBIOS name of the Samba instance.

A winbind instance may share a Samba instance configuration directory and subsequent smb.conf file, together with the NetBIOS name of the Samba instance, if the Samba and winbind instances are deployed within the same failover resource group.

If a winbind instance is configured within a scalable resource group, a unique configuration directory that reflects the NetBIOS name for the winbind instance is required.

Each Samba instance smb.conf file must have a [scmondir] share. The Sun Cluster HA for Samba fault monitor uses smbclient to access the directory specified within [scmondir] to verify that smnd is operating correctly.

Example 1 Sample [scmondir] entry within smb.conf.

[scmondir]
comment = Monitor directory for Sun Cluster
path = /tmp
browseable = No

For illustration purposes the following example shows Samba installed from http://www.samba.org onto a cluster file system with two Samba instances (smb1 and smb2) and a winbind instance (winbind).

The Samba instances will run as failover services within separate failover resource groups on highly available local file systems with their own unique configuration directories. winbind will run as a scalable service on a cluster file system with it's own unique configuration directory.

Within this example:

• Samba has been downloaded into /global/samba/software.

• Samba has been compiled into /global/samba/3.0.22.

• The NetBIOS name for the Samba instances are smb1 and smb2.

• The NetBIOS name for the winbind instance is winbind.

• The Samba instance smb1 has its configuration directory as /local/samba/config/smb1.

• The Samba instance smb2 has its configuration directory as /local/samba/config/smb2.

• The winbind instance winbind has its configuration directory as /global/samba/config/winbind.

• The Samba instance smb1 has its smb.conf file located at /local/samba/config/smb1/lib/smb.conf.

• The Samba instance smb2 has its smb.conf file located at /local/samba/config/smb2/lib/smb.conf.

• The winbind instance winbind has its smb.conf file located at /global/samba/config/winbind/lib/smb.conf.

Example 2 Samba and winbind configuration directories

bash-3.00# ls -l /opt/samba
lrwxrwxrwx   1 root     root     20 Jul 13 11:24 /opt/samba -> /global/samba/latest
bash-3.00#
bash-3.00# ls -l /global/samba
total 8
drwxrwx---   2 root     root     512 Jul 13 11:20 3.0.22
drwxrwx---   3 root     root     512 Jul 13 11:20 config
lrwxrwxrwx   1 root     root      20 Jul 13 11:20 latest -> /global/samba/3.0.22
drwxrwx---   2 root     root     512 Jul 13 11:20 software
bash-3.00#
bash-3.00# ls -l /global/samba/config
total 2
drwxrwx---   2 root     root     512 Jul 13 11:20 winbind
bash-3.00#
bash-3.00# ls -l /local/samba/config
total 4
drwxrwx---   2 root     root     512 Jul 13 11:25 smb1
drwxrwx---   2 root     root     512 Jul 13 11:25 smb2
bash-3.00#

Restriction for multiple Samba instances that require winbind

The Sun Cluster HA for Samba data service can support multiple Samba instances. However, only one winbind instance is supported per global zone, non-global zone or failover zone.

If you intend to deploy multiple Samba instances that also require winbind, then you will need to consider if winbind needs to be a scalable service. The following discussion will help you determine how to deploy single or multiple Samba instances with winbind.

Disregard any reference to winbind if it is not required.

Within these examples:

• There are two nodes within the cluster, node1 and node2.

• Both nodes have two non-global zones each named z1 and z2.

• Additional non-global zones are represented by z[n].

• Each example listed simply shows the required Nodelist property value when creating a failover or scalable resource group.

• Benefits and drawbacks are listed within each example as + and -.

Although these examples show non-global zones z1 and z2, you may also use global as the zone name or omit the zone entry within the Nodelist property value to use the global zone.

Example 3 Run all Samba instances and a winbind instance within the same failover resource group.

Create a single failover resource group that will contain all the Samba instances and a winbind instance in non-global zones across node1 and node2.

# clresourcegroup create -n node1:z1,node2:z1 RG1

• + Only one non-global zone per node is required.

• - All Samba/winbind instances do not have independent failover as they are all within the same failover resource group.

Example 4 Run each Samba/winbind instance within separate failover resource groups.

Create multiple failover resource groups that will each contain one Samba/winbind instance in exclusive non-global zones across node1 and node2.

# clresourcegroup create -n node1:z1,node2:z1 RG1
#
# clresourcegroup create -n node1:z2,node2:z2 RG2
#
# clresourcegroup create -n node1:z[n],node2:z[n] RG[n]

• + All Samba/winbind instances have independent failover in separate failover resource groups.

• + All Samba/winbind instances are isolated within their own exclusive non-global zones.

• -Each resource group requires a unique non-global zone per node.

Example 5 Run each Samba instance within separate failover resource groups and winbind in a scalable resource group.

Create multiple failover resource groups that will each contain one Samba instance and one scalable resource group that will contain a scalable winbind resource in shared non-global zones across node1 and node2.

# clresourcegroup create -n node1:z1,node2:z1 RG1
#
# clresourcegroup create -n node1:z1,node2:z1 RG2
#
# clresourcegroup create -n node1:z1,node2:z1 RG[n]
#
# clresourcegroup create -S -n node1:z1,node2:z1 RG3

• + All Samba instances have independent failover within separate failover resource groups.

• + Only one non-global zone per node is required.

• +/- All Samba instances share the same non-global zone.

For a scalable resource group different zones from the same node cannot be specified in the Nodelist parameter, thereby limiting a scalable resource group for winbind to one zone from the same node.

Example 6 Run each Samba/winbind instance in separate failover resource groups that contain separate failover zones across node1 and node2.

Create multiple failover resource groups that will each contain a failover zone. Each failover zone will then contain one Samba/winbind instance.

# clresourcegroup create -n node1,node2 RG1
#
# clresourcegroup create -n node1,node2 RG2
#
# clresourcegroup create -n node1,node2 RG[n]

• + All Samba instances have independent failover within separate failover resource groups.

• + The same failover zone per resource group is used per node.

• + Each failover zone is only active on one node at a time.

• - Each resource group requires a unique failover zone per node.

If your requirement is simply to make Samba highly available you should consider choosing a global or non-global zone deployment over a failover zone deployment. Deploying Samba within a failover zone will incur additional failover time to boot/halt the failover zone.