Samba konfigurieren

Wer ein Samba mit Cluster-Support vorliegen hat (siehe Kasten "Bau-Anleitung für Samba"), konfiguriert es mit einigen »smb.conf«-Parametern:

• »clustering = yes« aktiviert das Clustering zur
  Laufzeit. Ohne diesen Parameter verhält sich ein fürs
  Clustern gebautes Samba wie eines ohne Cluster-Support.
• Entgegen den Informationen auf einigen Seiten im Samba-Wiki,
  etwa [23], muss der Admin das »private dir« nicht ins
  Cluster-Dateisystem verlegen (höchstens wegen einer lokalen
  »smbpsswd«). Diese Information gilt nur für
  frühere CTDB-Versionen, die ihre persistenten TDB-Datenbanken
  wie die »secrets.tdb« und »passdb.tdb« im
  »private dir« nicht behandeln können. Aktuelle
  CTDB-Versionen jedoch verteilen auch die persistenten TDBs
  automatisch im Cluster.
• Wer Group-Mappings braucht, muss mit »groupdb:backend =
  tdb« das Backend vom Standardwert »ldb« auf
  »tdb« ändern.

Samba speichert die Locking-Informationen einer Datei anhand ihres Identifikationscode - den bildet der »smbd« normalerweise aus einem »stat()«-Systemaufruf aus der Device- und Inode-Nummer der Datei. Das Clustersetup benötigt aber eine knotenübergreifend gültige ID, denn die Device-Nummer ist keine Cluster-Invariante einer Datei.

Mit dem VFS-Modul »fileid« lässt sich jedoch eine alternative, clusterweit gültige File-ID bilden. Es unterstützt zwei Methoden: Die Variante »fsname« zimmert eine Device-Nummer als Hash aus dem Dateisystemnamen (»fsname«) des »getmntent()«-Aufrufs. Die Variante »fsid« bildet die Device-Nummer aus der Dateisystem-ID (»f_fsid«) des »statfs()«-Aufrufs. Default beim »fileid«-Modul ist »fsname«.

• Der Parameter »vfs objects = fileid« im
  entsprechenden Konfigurationsabschnitt aktiviert für ein Share
  oder global das »fileid«-Modul. Der Wert der Option
  »fileid:algorithm« im Abschnitt »[global]«
  konfiguriert die Methode. Etwa so wie

vfs objects = fileid
fileid:algorithm = fsid

kann ein Beispiel aussehen und in der »[global]«-Sektion angesiedelt sein.

cd samba/source
./autogen.sh
./configure --with-cluster-support --with-ctdb=/usr/include  --with-shared-modules=idmap_tdb2 [Weitere Optionen] 
./make everything
./make install

cd samba/source
./packaging/RHEL-CTDB/makerpms.sh

Lauscher aufstellen

Es ist extrem wichtig für das reibungslose Funktionieren der Monitoring- und Failover-Mechanismen von CTDB, die IP-Adressen oder Netzwerk-Interfaces auf denen Samba lauschen soll, nicht per Konfigurationsparameter »interfaces« oder »bind interfaces only« einzuschränken! Das Monitoring der Samba-Dienste beruht nämlich darauf, dass Samba auf der Wildcard-Adresse »0.0.0.0« lauscht, beziehungsweise auf »::« bei IPv6.

Listing 3 zeigt beispielhaft eine Samba-Konfigurationsdatei, die der Admin auf alle Clusterknoten verteilen sollte. Das Kommando »smbstatus« zeigt im Cluster die Verbindungen auf allen Knoten an. Dazu listet es nicht nur die Prozess-ID der »smbd«-Prozesse, sondern gibt deren Knoten-Nummern-Präfix aus (Abbildung 5). Analog kann der Admin auch mit »smbcontrol« clusterweit auf die Samba-Daemons Einfluss nehmen.

01 [global]
02 clustering = yes
03 netbios name = cifscluster
04 workgroup = mydomain
05 security = ads
06 passdb backend = tdbsam
07 
08 idmap backend = tdb2
09 idmap uid = 1000000-2000000
10 idmap gid = 1000000-2000000
11 
12 groupdb:backend = tdb
13 fileid:algorithm = fsname
14 
15 [share]
16 path = /storage/share
17 vfs objects = fileid

Es ergibt übrigens beim Betrieb von geclustertem Samba keinen Sinn, den Netbios-Namensdienst »nmbd« auf mehreren Knoten zu starten - der Broadcast-Dienst hadert mit der gespaltenen Persönlichkeit. Auch der WINS-Dienst ist nicht dafür gewappnet, da Samba die »wins.dat«-Datenbank nicht wie TDBs über CTDB verhandelt.

Abbildung 5: Das Kommando »smbstatus« zeigt im Cluster die Verbindungen auf allen Knoten an.