Setting Up a Samba Service

Red Hat Cluster Suite: Configuring and Managing a Cluster
Prev | Chapter 6. Network File Sharing Services | Next

# 6.6. Setting Up a Samba Service

Highly available network file services are one of the key strengths of the clustering infrastructure. Advantages of high availibility Samba services include:

- Heterogeneous file serving capabilities to Microsoft® Windows™ clients using the CIFS/SMB protocol.

- Allows the same set of file systems to be simultaneously network served to both NFS and Windows based clients.

- Ensures that Windows-based clients maintain access to key data, and can quickly reestablish connection in the event of server failure.

- Facilitates planned maintenance by allowing the transparent relocation of Samba services to one cluster member, enabling you to fix or upgrade the other cluster member.

- Allows the setup of an active-active configuration to maximize equipment utilization.

| Note
| A complete explanation of Samba configuration is beyond the scope of this document. Rather, this documentation highlights aspects which are crucial for clustered operation. Refer to Red Hat Enterprise Linux System Administration Guide for more details on Samba configuration.

## 6.6.1. Samba Server Requirements

If you intend to create highly available Samba services, each cluster member on which the services will run must meet the following requirements:

- The Samba RPM packages must be installed. Note that there have been no modifications to the Samba RPMs to support high availability.

- The Samba daemons will be started and stopped by the cluster infrastructure on a per-service basis. Consequently, the Samba configuration information should not be specified in the conventional `/etc/samba/smb.conf` file. The Cluster Configuration Tool writes a `smb.conf.`sharename`` file to the `/etc/samba/` directory for each Samba share (where `sharename` is the name you specified for the Samba share).

- The automated system startup of the Samba daemons `smbd` and `nmbd` should be disabled in `init.d` runlevels. For example: `chkconfig --del smb`.

- Since the cluster infrastructure stops the cluster-related Samba daemons appropriately, do not manually run the conventional Samba stop script (`service smb stop`) as this will terminate all cluster-related samba daemons.

- File system mounts for clustered Samba services should not be included in `/etc/fstab`. Rather, for clustered services, the parameters describing mounts are entered via the Cluster Configuration Tool.

- Failover of Samba printer shares is not currently supported.

## 6.6.2. Samba Operating Model

This section provides background information describing the implementation model in support of Samba high availability services. Knowledge of this information will provide the context for understanding the configuration requirements of clustered Samba services.

The conventional, non-clustered Samba configuration model consists of editing the `/etc/samba/smb.conf` file to designate which file systems are to be made network accessible to the specified clients. It also designates access permissions and other mapping capabilities. In the single system model, a single instance of each of the `smbd` and `nmbd` daemons are automatically started up by the `/etc/rc.d/init.d/smb` runlevel script.

To implement high availibility Samba services, rather than having a single `/etc/samba/smb.conf` file, each service has its own Samba configuration file. These files are named `/etc/samba/smb.conf.`sharename``, where `sharename` is the specific name of the individual configuration file associated with a Samba service. For example, if you created a share called `mktg`, the corresponding Samba configuration file would be `/etc/samba/smb.conf.`mktg``.

| Note
| A Samba share must be in a service with at least one IP address.

The format of the `smb.conf.`sharename`` file is identical to the conventional `smb.conf` format. No additional fields have been created for clustered operation. There are several fields within the `smb.conf.`sharename`` file which are required for correct cluster operation; these fields will be described in Section 6.8 Fields in the `smb.conf.`sharename`` File. When a new Samba service is created using the Cluster Configuration Tool, the corresponding `smb.conf.`sharename`` file is created based on the service-specific parameters, including appropriate client systems, specific directories to share, and read-write permissions.

Copy the `/etc/samba/smb.conf.`sharename`` files onto all members in the cluster (or all members in an unrestricted failover domain, if used); refer to Section 3.9 Configuring a Failover Domain for more information. After the initial configuration, should any changes be made to any `smb.conf.`sharename`` file, you must also copy the updated version to the other members.

To facilitate high-availability Samba functionality, each individual Samba service configured within the cluster (through the Cluster Configuration Tool) will have its own individual pair of `smbd` and `nmbd` daemons. Consequently, if there are more than one Samba services configured with the cluster, you may see multiple instances of these daemon pairs running on an individual cluster server. These Samba daemons `smbd` and `nmbd` are not initiated via the conventional `init.d` run level scripts; rather they are initiated by the cluster infrastructure based on whichever member is the active service provider.

To allow a single system to run multiple instances of the Samba daemons, every pair of daemons is required to have both its own locking directory and its own process ID (pid) directory. Consequently, there will be a separate per-service Samba daemon locking and running process directory. These directories are given the name `/var/cache/samba/`sharename`/` for lock files and `/var/run/samba/`sharename`/` for pid files (where `sharename` is replaced by the Samba share name specified within the service configuration information set using the Cluster Configuration Tool). Continuing the prior example, the corresponding directories for our `mktg` share would be `/var/cache/samba/`mktg`/` and `/var/run/samba/`mktg`/`.

Prev | Home | Next
NFS Configuration: Active-Active Example | Up | Using the Samba Druid