© Alex Hinds, Fotolia.de

Wenn Sie Admin einer kleineren Firma mit zu klein und zu schwach gewordenen Fileserver sind, können Sie natürlich bei einem Anbieter eine neue Komplettlösung kaufen. Oder Sie nehmen nur die Hardware und machen den Rest mit freier Software und der folgenden Anleitung selbst.

Zentraler Bestandteil einer jeden Infrastruktur ist der Fileserver. Reine Unix-Landschaften setzen gern das klassische NFS (Network File System) ein – meist als v3, das als gut getestet und zugleich steinzeitlich gilt. Obwohl schon länger am Markt kommt NFS v4 recht selten zum Einsatz. Die wichtigste Neuerung besteht im firewallfreundlichen Wechsel von UDP/TCP-Kommunikation unter RPC-Portmapper-Steuerung hin zu reinem TCP mit einem definierten Port 2049/TCP. Außerdem bündelt NFS 4 die Anfragen, die der Server ausgeführt und nur eine Antwort zurückgemeldet – gut im WAN. Zu guter Letzt ist eine Verschlüsselung viel einfacher zu handhaben und echter Bestandteil der Spezifikation.

Hängen auch PCs am Linux-Fileserver, dann in der Regel welche mit Windows-System – so die unvernünftige Realität. Hier schlägt die Stunde des SMB-Protokolls (Server Message Block) und Samba. Außerdem bietet SMB eine User-Authentifizierung, nicht nur eine von Hosts wie NFS 3. Beginnend mit den Basissetup inklusive Netz- und Storage-Konfiguration zeigt Ihnen dieser Artikel anhand zweier Szenarien, wie die Installation eines Samba-Fileservers für eine heterogenen Landschaft aussehen kann.

Server als Domänen-Mitglied oder -Controller

Das erste Szenario bindet den Server in eine bestehendes Active Directory ein (Abbildung 1). Das zweite Modell weist einen Weg, der mit Samba und OpenLDAP eine Domäne aufbaut, die auf einen Windows-Domänencontroller verzichtet (Abbildung 2). Als Sahnehäubchen etablieren Access Control Lists (ACL) ein Berechtigungskonzept, welches über die Granularität der Unix- Berechtigungen weit hinaus geht.

Abbildung 1: Ein Fileserver als Client im Active Directory – Szenario 1.

Abbildung 2: Fileserver als Samba-PDC mit LDAP-Backend – Szenario 2.

Das Linux-Fundament des Fileservers besteht hier aus Cent OS 5.2. Dessen Quellen fußen auf einer Enterprise-Distribution, was eine entsprechende Qualität annehmen lässt. Die Wahl ermöglicht zudem Softwarepakete und Installationsquellen von Red Hat einzusetzen. Sie dürfen aber natürlich auch jede andere Distribution benutzen – die Instruktionen dieses Artikels werden Sie dadurch nur wenig variieren müssen.

Nach der Basisinstallation schaffen Sie eine ausfallsichere und performante Netzanbindung mit Hilfe von Bonding und binden das Storage über I-SCSI an. Bonding bündelt mehrere physikalischen Netzwerkinterfaces zu einem logischen Bonding-Device. Dieser Workshop setzt auf diese Technik nicht nur aus Gründen der Verfügbarkeit, sondern auch um den Durchsatz zu steigern.

Bonding kennt unterschiedliche Modi, um Devices zusammenzuschaltet. Die gängigsten heißen simpel »1« (Active/Backup) und »0« (Lastverteilung per Round Robin). Um Bonding zu aktivieren, legen Sie im ersten Schritt in der Datei »/etc/modprobe.conf« die Bonding-Devices über den »alias«-Eintrag an und stellen über »options« den Modus ein. Listing 1 versetzt mit »mode=1« das Client-Netz auf Active/Backup und mit »mode=0« das Storage-Netz in den Balancing Modus. Eine detaillierte Beschreibung der Modi und Parameter finden Sie im Linux Ethernet Bonding Driver Howto. [1]

01 # Bonding Interfaces
02 alias bond0 bonding
03 options bond0 mode=1 miimon=100
04 alias bond1 bonding
05 options bond1 mode=0 miimon=100

Nun legen Sie pro Bonding-Interface eine Interface-Konfiguration wie bei physikalischen gewohnt unter »/etc/sysconfig/network-script« an – zu sehen in Listing 2 und 3. Die Konfigurationsdateien der vier physikalischen Interfaces (Listing 4 und 5) machen per »MASTER« die Zuordnung zum jeweiligen Bonding-Device klar und definieren die Interfaces als »SLAVE«. Die Interface-Geschwindigkeit lässt sich hier bei Bedarf mit der Option »ETHTOOL_OPTS« fixieren:

ETHTOOL_OPTS="speed 1000 duplex full autoneg off"

Das Beispiel weist 1000 MBit/s, Full Duplex zu und schaltet die Autonegotiation ab. Wenn Sie fertig mit konfigurieren sind, macht »service network restart« die Änderungen wirksam.

01 DEVICE=bond0
02 IPADDR=192.168.168.15
03 NETMASK=255.255.255.0
04 NETWORK=192.168.168.0
05 BROADCAST=192.168.168.255
06 GATEWAY=
07 ONBOOT=yes
08 BOOTPROTO=none
09 USERCTL=no

01 DEVICE=bond1
02 IPADDR=172.16.164.15
03 NETMASK=255.255.255.0
04 NETWORK=172.16.164.0
05 BROADCAST=172.16.164.255
06 GATEWAY=
07 ONBOOT=yes
08 BOOTPROTO=none
09 USERCTL=no

01 # Client-Netz: ethX=eth0/eth1
02 DEVICE=ethX
03 ONBOOT=yes
04 BOOTPROTO=none
05 USERCTL=no
06 MASTER=bond0
07 SLAVE=yes

01 # Storage-Netz: ethY=eth2/eth3
02 DEVICE=ethY
03 ONBOOT=yes
04 BOOTPROTO=none
05 USERCTL=no
06 MASTER=bond1
07 SLAVE=yes

Storage anbinden per I-SCSI

I-SCSI [2] transferiert das SCSI-Protokoll über TCP. Storage, Festplatte oder Bandlaufwerk sind hierbei das Target und der Controller, der auf das jeweilig Gerät zugreift, der Initiator. Im Gegensatz zu einem SAN mit Fibre Channel erfordert I-SCSI im ersten Schritt keine extra Komponenten abzuschaffen, soweit die vorhandene Infrastruktur ansonsten ausreicht. Meist ist das Setup mit wenig Aufwand und Geld zu erledigen.

Um den Server fit für I-SCSI-Targets zu machen, spendieren Sie ihm das Paket »iscsi-initiator-utils«. Für die Authentifizierung am Target editieren Sie die Datei »/etc/iscsi/iscsid.conf« dem Listing 6 entsprechend. Eventuelle Zusatzparameter setzen Sie ebenfalls hier. Dann starten Sie mit »service iscsi start« den I-SCSI-Dienst und führen ein Discovery des Targets durch:

iscsiadm -m discovery -t sendtargets -p 172.16.164.10

Dadurch erhalten Sie eine Liste der durch das Target exportierten I-SCSI-Devices:

172.16.164.10:3260,1 iqn.1994-04.org.netbsd.iscsi-target:target0

Der folgende Befehl benutzt das Device gleich an Ort und Stelle:

iscsiadm -m node -T iqn.1994-04.org.netbsd.iscsi-target:target0 -p 172.16.164.10 --login

War er erfolgreich, verfügen Sie ab sofort über »/dev/sd*«, auf das Sie mit den üblichen Tools zugreifen dürfen, beispielsweise mit Fdisk wie in Listing 7. Taucht das Device nicht auf, fahnden Sie in »/var/log/messages« nach dafür ursächlichen Fehlern.

01 node.session.auth.username = I-SCSI-User
02 node.session.auth.password = Password
03 discovery.sendtargets.auth.username = I-SCSI-User
04 discovery.sendtargets.auth.password = Password

01 [...] 
02 Disk /dev/sdb: 212 MB, 212860928 bytes 
03 7 heads, 58 sectors/track, 1024 cylinders 
04 Units = cylinders of 406 * 512 = 207872 bytes

Partitionieren

Das sich das I-SCSI-Storage nun wie ein lokales verhält, können Sie es nun wie gewohnt partitionieren. Die für einen Fileserver meist nötige Flexibilität erzielen Sie am ehesten mit Logical Volume Manager (LVM, Howto unter [3]). Sie legen dazu initial mit Fdisk oder einem Derivat eine große Partition des Typs »Linux LVM« (»8e«) an. Dann erzeugen Sie in vier Schritten mit den LVM Tools das benötigte Volume:

pvcreate /dev/sdb1
vgcreate storage_group /dev/sdb1
vgchange -a y storage_group
lvcreate -L100M -nfiles storage_group

Der erste Schritt legt ein Physical Volume an, in das der zweite eine Volumegroup erzeugt, die der dritte aktiviert. Lvcreate erzeugt als Viertes ein 100 MByte großes logisches Volume mit dem Namen »files«. Ein beherztes

mkfs -t ext3 /dev/storage_group/files

legt darauf ein Dateisystem an. Tipp: Sehr große Volumes lohnt es mit »nohup mkfs -t … &« im Hintergrund zu formatieren. Das Mounten geht wieder ganz wie von der Stange:

mkdir /mnt/iscsi
mount -t ext3 /dev/storage_group/files /mnt/iscsi/

Damit Linux das Device ab dem nächsten Reboot automatisch einbindet, etablieren Sie den I-SCSI-Dienst mit »chkconfig iscsi on« und tragen die Partition in der »/etc/fstab« ein:

/dev/storage_group/files /mnt/iscsi ext3 _netdev 0 0

Um das Weitere nicht zu verkomplizieren, deaktivieren Sie besser die lokale Firewall und SE Linux temporär:

service iptables stop
chkconfig iptables off

Über die Änderung des Eintrags »SELINUX=disabled« in der Konfiguration »/etc/selinux/config« ließe sich SE Linux auch dauerhaft abschalten. Den Enforce-Modus auf die Schnelle zu deaktivieren, geht übrigens mit »echo 0 >/selinux/enforce«.

Die folgenden, alternativen Szenarien basieren auf der eben aufgebauten Basis, die den Zugriff auf ein redundant angeschlossenes Storage konfiguriert hat.

Szenario 1: Samba als Domain Member

Um einen Linux-Server [4] an ein vorhandenes Active Directory anzubinden (Abbildung 1), bedarf es außer Samba noch des Kerberos-Pakets und der exakten Synchronisation mit einem NTP-Server. Damit eine AD-Domäne das System aufnimmt, müssen Sie ein paar Anpassungen in der Datei »/etc/samba/smb.conf« vornehmen. Listing 8 tut das und erstellt zwei Freigaben.

Damit Linux die AD-User und -Gruppen nutzt, erweitern Sie die Datei »/etc/nsswitch.conf« um:

passwd: files winbind
group:  files winbind

Anschließend tritt das System mit dem Befehl »net join -U Administrator« nach einer Passwortabfrage der Domäne bei. Jetzt noch die Samba-Dienste neu: »service smb start && service winbind start «, und schon listen »wbinfo -u« und »wbinfo -g« alle Domänen-Benutzer und -Gruppen auf. Legen Sie jetzt die in Listing 6 freigegebenen Verzeichnisse an und passen deren Berechtigungen an:

mkdir /mnt/iscsi/data /mnt/iscsi/public
chgrp "domänen-benutzer" /mnt/iscsi/*
chmod 2770 /mnt/iscsi/data
chmod 2777 /mnt/iscsi/public

Ab sofort kann ein AD-Client bereits auf die Freigaben »data« oder »public« des Servers zugreifen. Wer SE Linux wieder aktivieren will, passt mit

chcon -t samba_share_t /mnt/iscsi/data
chcon -t samba_share_t /mnt/iscsi/public

die Policies für den Einsatz als Domänen-Controller an und ordnet die Freigaben dem Kontext »samba_share_t« zu.

01 [global]
02 workgroup = AD                      # Windows Domänenname
03 security = ADS                      # AD als Sicherheitsmodell
04 realm = AD.LOCAL                    # FQDN der Domäne
05 server signing = auto
06 netbios name = fs2009               # Netbios Name des Servers
07 winbind use default domain = yes
08 encrypt passwords = yes             # Verschlüsselte Passwortübertragung
09 password server = w3k.ad.local      # Anstelle von w3k.ad.local ist
10                              auch * für alle Server der Domäne möglich
11 idmap uid = 10000-20000              # Bereich für Domänenuser
12 idmap gid = 10000-20000              # Bereich für Domänengruppen
13 
14 [data]
15 comment = Data Share using AD
16 path = /mnt/iscsi/data
17 valid users = @"ADdomänen-benutzer" # Zugriff für User der Gruppe domänen-benutzer
18 writeable = yes
19 browseable = yes
20 
21 [public]                        # Freigabe eines freien Zugriffsbereich
22 comment = Public Stuff
23 path = /mnt/iscsi/public
24 create mode = 0777
25 directory mode = 0777
26 public = yes
27 writable = yes
28 printable = no

Szenario 2: Samba als LDAP-gestützter PDC

Das zweite Szenario kombiniert Samba als Primären Domänen Controller mit OpenLDAP [5] als Backend für Benutzer- und Gruppenverwaltung, wobei das Benutzermanagement weiter über die bekannten Windows-Werkzeuge erfolgt. Für dieses Setup brauchen Sie Samba- und OpenLDAP-Pakete, für Testzwecke auch die Samba- und LDAP-Clients. Die Objekte für Useraccounts und Gruppenzuordnung finden Sie in einem eigenen LDAP-Schema. Das ist zwar in Samba enthalten, müssen es aber noch ins richtige Konfiurationsverzeichnis kopieren:

cp /usr/share/doc/samba-3.0.28/LDAP/samba.schema /etc/openldap/schema/

Als nächstes passen Sie die LDAP-Konfigurationsdatei des Servers »/etc/openldap/slapd.conf« wie in Listing 9 an, indem Sie zunächst die beiden Schemata ergänzen (Zeilen 1 und 2) und den Suffix, Rootdn und das zugeordnete Passwort festlegen (Zeilen 4 bis 6). Das Rootdn-Passwort sollte hier ausschliesslich verschlüsselt liegen, der von »slappasswd -h {MD5} Passwort« generierte String (»{MD5}Xr4il…«) landet statt des Klartext-Passwortes in der Zeile 6 (»rootpw«).

Typischerweise darf jeder Benutzer darf sein eigenes Passwort ändern, der Administrator sogar die von anderen Usern. Das regelt im LDAP der Zugriff (»access«) auf spezielle Attribute (»attrs«), zu sehen ab Zeile 8.

01 include    /etc/openldap/schema/misc.schema
02 include    /etc/openldap/schema/samba.schema
03 [...]
04 suffix     "dc=mx,dc=local"
05 rootdn     "cn=Manager,dc=mx,dc=local"
06 rootpw     {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
07 [...]
08 access to attrs=userPassword,sambaLMPassword,sambaNTPassword
09         by self write
10         by dn="cn=administrator,dc=mx,dc=local" write
11         by * auth
12 
13 access to *
14         by dn="cn=administrator,dc=mx,dc=local" write
15         by * read

Hilfreiche Vorlage

Wenn die Konfiguration der LDAP-Datenbanken fehlt, erweist sich das Template der Standardkonfiguration »/etc/openldap/DB_CONFIG.example« als hilfreich. Jetzt starten Sie den LDAP-Dienst mit »service ldap start« und »chkconfig ldap on«. Die meisten Fehlermeldungen an dieser Stelle entstehen, wenn die Berechtigungen unterhalb des LDAP-Datenverzeichnis »/var/lib/ldap« nicht ausreichen. Das behebt ein schnelles »chown ldap /var/lib/ldap/*«.

Ldap.conf und Samba

Als nächsten Schritt definieren Sie in der Datei »/etc/nsswitch.conf« LDAP als Quelle für die Abfragen von Usern, Gruppen und Hosts und aktivieren für letztere auch Wins:

passwd:     files ldap
group:      files ldap
hosts:      files dns wins

Damit das System Anfragen an den lokalen Server stellen kann, ergänzen Sie die Datei »/etc/ldap.conf« mit den passenden LDAP-Informationen:

base dc=mx,dc=local
uri ldap://127.0.0.1/
ssl no
pam_password md5

Nun kommt der Samba-Teil an die Reihe. Listing 10 zeigt eine für einen PDC geeignete Konfiguration für die Datei »smb.conf«. Damit Samba User-, Gruppen- und Rechner-Informationen aus dem LDAP beziehen kann, braucht es einen dedizierten User, der in Produktionsumgebungen besser nicht mit dem LDAP-Rootdn identisch ist. Smbpasswd speichert diese Daten in »secrets.tdb«, wie »smb passwd -w secret« zuverlässig verrät.

01 [global]
02 workgroup = MX                 # Windows Domänen Name
03 security = user
04 domain logons = Yes            # Domänen Logons
05 domain master = Yes            # Host ist Domänen Master
06 wins support = Yes
07 
08 hosts allow = 192.168.168.0/24 172.16.164.0/24 127.0.0.1/32
09 # Zugriffs Berechtigung auf den Server
10 
11 netbios name = fs2009          # Netbios Name des Servers
12 passdb backend = ldapsam:ldap://127.0.0.1   # Password Backend ist LDAP
13 username map = /etc/samba/smbusers          # User Mapping Datei
14 
15 log level = 2                  # Definition des Loglevels
16 log file = /var/log/samba/%m   # jeder Host erhält eigene Logdatei
17 
18 time server = Yes              # Fungiert der nmbd als Zeitserver für
19                                # Windows Clients
20 # Logon Einstellungen
21 logon script = logon.bat       # Logon Script
22 logon path = \fs2009profiles%u           # Pfad für roaming Profile
23 logon drive = H:               # Home auf dieses Laufwerk verbinden
24 
25 # LDAP Einstellungen
26 ldap admin dn = "cn=Manager,dc=mx,dc=local" # LDAP Admin User
27 ldap ssl = Off    # keine SSL-verschlüsselte Verbindung zum LDAP-Server
28 ldap suffix = dc=mx,dc=local   # LDAP Suffix Basis für Samba Objekte
29 ldap user suffix = ou=Users    # User Suffix relativ zum LDAP Suffix
30 ldap group suffix = ou=Groups  # Group Suffix relativ zum LDAP Suffix
31 ldap machine suffix = ou=Computers          # Suffix für Maschinen Konten relativ zum LDAP Suffix
32 ldap idmap suffix = ou=Idmap   # Suffix für idmap mappings relativ zum
33                                # LDAP-Suffix 
34 # User Mapping
35 idmap backend = ldap://127.0.0.1
36 idmap uid = 1000-20000 # lokaler reserv. UID-Bereich für Domänenbenutzer
37 idmap gid = 1000-20000 # Lokaler reserv. GID-Bereich für Domänengruppen
38 
39 # Definition der Freigaben
40 [homes]                        # Freigabe der Homelaufwerke
41 comment = Home Directories
42 valid users = %S
43 browseable = yes
44 writable = yes
45 create mask = 0600
46 
47 [netlogon]                     # Freigabe für Netlogon
48 comment = Network Logon Service
49 path = /mnt/iscsi/netlogon
50 writeable = yes
51 browseable = yes
52 read only = no
53 
54 [profiles]                     # Freigabe für roaming Profile
55 path = /mnt/iscsi/profiles
56 writeable = yes
57 browseable = no
58 read only = no
59 create mode = 0777
60 directory mode = 0777
61 
62 [data]                         # Freigabe des Daten-Shares
63 comment = data share
64 path = /mnt/iscsi/data
65 writeable = yes
66 browseable = yes
67 read only = no
68 valid users = "@Domain Users"
69 
70 [public]                       # Freigabe eines freien Zugriffsbereich
71 [...]

SE Linux wieder aktivieren

Auch in diesem Szenario müssen Sie die SE-Linux-Policies für den Einsatz als Domänen-Controller anpassen. Setsebool setzt Samba als Domänen-Controller ein und aktviert die Home-Directories auf dem Server. Chcon ordnet anschließend die Freigaben dem Kontext »samba_share_t« zu:

setsebool -P samba_domain_controller on
setsebool -P samba_enable_home_dirs on
chcon -t samba_share_t /mnt/iscsi/data
chcon -t samba_share_t /mnt/iscsi/public
chcon -t samba_share_t /mnt/iscsi/netlogon

Die Management-Tools zur Benutzerverwaltung sind nicht Bestandteil von CentOS, aber Server wie RPMforge bieten passende Pakete mit den Perl-Modulen und Skripten an. Nach deren Installation passen Sie die Konfigurationsdateien unter »/etc/smbldap-tools« für den Zugriff auf das LDAP Verzeichnis an. Im ersten Schritt ermitteln Sie dafür mit »net getlocalsid« die SID. Die Antwort:

SID for domain FS2009 is: S-1-5-21-1296147596-3054910190-1361742739

Dieser String setzen Sie in »/etc/smbldap-tools/smbldap.conf«, zu sehen in Listing 11. Jetzt noch in der Datei »/etc/smbldap-tools/smbldap_bind.conf« die Parameter »masterDN« und »masterPw« für den LDAP-Zugriff anpassen:

_
masterDN="cn=Manager,dc=mx,dc=local"
masterPw="secret"

und fertig ist die Integration der Skripte. Ab sofort können Sie das LDAP-Verzeichnis befüllen.

Auch hierfür liefert das »smbldap-tools«-Paket ein passendes Skript namens »smbldap-populate«. Es fügt der Domäne alle notwendigen Einträge hinzu und gestattet die Eingabe eines Root-Passwords für den Administrator. Wenn Sie das automatische Hinzufügen von User- oder Maschinen-Konten gestatten wollen, müssen Sie den »[global]«-Abschnitt der Samba-Konfiguration um die Zeilen in Listing 12 erweitern.

Auch in diesem Szenario braucht der Samba-Server einen Restart. Außerdem müssen Sie die in der Konfiguration erwähnten Verzeichnisse anlegen und mit den korrekten Rechten ausstatten.

01 SID="S-1-5-21-1296147596-3054910190-1361742739"
02 sambaDomain="MX"
03 masterLDAP="fs2009.mx.local"
04 ldapTLS="0
05 suffix="dc=mx,dc=local"
06 userSmbHome="\fs2009%U"
07 userProfile="\fs2009profiles%U"
08 mailDomain="mx.local"

01 add user script = /usr/sbin/smbldap-useradd -a -m '%u'
02 delete user script = /usr/sbin/smbldap-userdel '%u'
03 add group script = /usr/sbin/smbldap-groupadd -p '%g'
04 delete group script = /usr/sbin/smbldap-groupdel '%g'
05 add user to group script = /usr/sbin/smbldap-groupmod -m '%g' '%u'
06 delete user from group script = /usr/sbin/smbldap-groupmod -x '%g' '%u'
07 set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'
08 add machine script = /usr/sbin/smbldap-useradd -w '%u'

Konfiguration testen

Zu diesem Zeitpunkt ist es günstig, das Setup einem Test zu unterwerfen: Im ersten Schritt legen Sie den Domänen-User-Administrator an und ordnen ihn der Gruppe »Domain Admins« zu:

smbldap-useradd -m -a administrator
smbldap-passwd administrator
smbldap-usermod -G "Domain Admins" administrator

Es folgt ein ein Testuser in der Gruppe »Domain Users«, der Check, ob das auch im LDAP angekommen ist, sowie die Überprüfung der Freigaben mit dem Samba-Client:

smbldap-useradd -m -a test
smbldap-passwd test
smbldap-usermod -G "Domain Users" test
ldapsearch -b "dc=mx,dc=local" -h 127.0.0.1 -x -LLL "uid=test" 
smbclient -L fs2009 -U test

Jetzt lässt sich der erste Windows-Client auf die herkömmliche Weise zur Domäne hinzufügen (Abbildung 3). Wer dafür die Gruppe »Domain Admins« verwenden möchte, muss dieser noch die benötigten Rechte dazu erteilen:

net -U root%Passwort rpc rights grant 'MXDomain Admins' SeMachineAccountPrivilege

Ersetzen sie dabei »Passowort« durch das des Root-Users.

Abbildung 3a und b: Einen Windows-Client tritt der Domäne des Samba-Servers bei.

Abbildung 3a und b: Einen Windows-Client tritt der Domäne des Samba-Servers bei.

Individuelle ACLs für beide Szenarien

Ein hilfreiches Feature, das viele Administratoren immer noch links liegen lassen, ist sind individuelle Zugrifsslisten [6]. Über die Registerkarte »Security« im Windows-Client vergeben Benutzer damit granulare Berechtigungen für Kollegen und setzen erweiterte Zugriffsmöglichkeiten auf Dateien und Verzeichnisse (Abbildung 4). Wollen Sie solche ACLs auf dem Server aktivieren, müssen Sie dafür sorgen, dass das darunterliegende Filesystem diese auch unterstützt – was die meisten modernen sofort tun, wenn Sie beim Mounten beziehungsweise in der »/etc/fstab« in der vierten Spalte die Option »acl« angeben.

Abbildung 4a und b: Von Windows aus lassen sich erweiterte Berechtigungen auf einem Samba-LDAP-Domänencontroller vergeben – den auf dem Access Control Lists sei Dank.

Abbildung 4a und b: Von Windows aus lassen sich erweiterte Berechtigungen auf einem Samba-LDAP-Domänencontroller vergeben – den auf dem Access Control Lists sei Dank.

Zwei Tools für die Benutzer

Danach dürfen die Benutzer ACLs einsetzen, unter Linux mit dem Befehl »setfacl«. »getfacl« zeigt dagegen die gesetzten ACLs an. Soll zum Beispiel jeder Domänen-Benutzer auf das freigegebene Datenverzeichnis »/mnt/iscsi/data« Schreibrechte erlangen und diese auch für alle untergeordneten Verzeichnisse gelten, bieten sich Default-ACLs und deren Vererbung an:

setfacl -m d:g:"Domain Users":rw /mnt/iscsi/data

Hier ist ein schneller Check mit »getfacl /mnt/iscsi/data« nicht verkehrt.

Die ACL-Funktionalität in Samba ist standardmäßig aktiviert, sobald das verwendete Filesystem dies unterstützt. Allerdigs vererbt Windows Berechtigungen auf Verzeichnissen automatisch an die darunterliegenden Directories. Damit Samba das ebenfalls abbildet, platzieren Sie in der jeweiligen Freigabe den Parameter »inherit acls = yes«.

Hochverfügbarkeit per Heartbeat

Um die entsprechenden Szenarien Ausfallsicher zu gestalten gibt es mehrere Möglichkeiten. Die einfachste: Ein Active-Passive-Cluster mit Heartbeat [7], eine sehr bewährte Failover-Software. Sie ist einfach zu konfigurieren, überzeugt durch ihre Stabilität und wenig Probleme im Betrieb. Die Kommunikation zwischen den Clusterknoten passiert seriell oder via Ethernet. Darüber tauschen sie ihre Lebenszeichen aus, die so genannten Heartbeats. Um das Szenario 2 redundant auszulegen, passen Sie Ihre bisherigen Systemkonfiguration anhand folgender Punkte an:

• Sie ändern die IP-Adresse für das Produktivnetz zum
  Beispiel auf 192.168.168.16 (Knoten 1) und 192.168.168.17 (Knoten
  2).
• Sie ändern des Hostnamen auf »node1.mx.local«
  und »node2.mx.local«.
• Die mounten das I-SCSI-Device nicht mehr automatisch per
  Fstab.
• Die Dienste LDAP und Samba steuert in Zukunft der
  Cluster-Service. Deshalb nehmen Sie sie aus den Runlevels.

Nach der Installation des Heartbeats-Paketes konfigurieren Sie »/ets/ha.d«. Für die Authentifizierung der beiden Clusterknoten legen Sie einen Schlüssel, ähnlich wie ein Passwort, in der Datei »authkeys« fest:

auth 1
1 sha1 ClusterPasswort

Wichtig ist, dass die Datei auf beiden Knoten die richtigen Berechtigungen erhalten. (»chmod 600 /etc/ha.d/authkeys«). Listing 13 zeigt die Clusterkonfiguration, wie sie die Datei »/etc/ha.d/ha.cf« aufweisen sollte.

01 # Die gleiche Konfiguration auf beiden Knoten
02 keepalive 1          # So oft wird ein Hearbeat gesendet
03 deadtime 5           # Zeit nach der angenommen wird, dass der Knoten nicht verfügbar ist
04 warntime 3
05 initdead 20          # Warte beim Starten des Service diese Zeit. Das ist z.B. beim
06                      # Systemstart notwendig, bis alle Netzwerk Devices verfügbar sind.
07 bcast bond1          # Kommunikation zwischen den Clusterknoten mittels Broadcast über bond1
08 auto_failback yes    # Services schwenken auf Default-Knoten zurück, wenn er wieder verfügbar ist.
09 node node1.mx.local  # Cluster-Knoten uname -n
10 node node2.mx.local
11 crm no               # Heartbeat-1-Cluster

Kommt als No-Name nicht infrage

Es ist enorm bedeutsam, dass die konfigurierten Cluster-Knoten per DNS auflösbar sind. Dazu muss der DNS-Dienst selbst hochverfügbar sein oder Sie tragen die beiden Knoten in die lokalen Host-Dateien ein:

172.16.164.15  node1.mx.local  node1
172.16.164.16  node2.mx.local  node2

Im vorletzten Schritt erzeugen Sie die eigentlichen Services, die der Cluster bereitstellt. Dafür schreiben Sie in die Datei »haresources« einfach:

node1.mx.local 192.168.168.15
Filesystem::/dev/mapper/storage_group-files::/mnt/iscsi::ext3::_netdev,acl ldap smb

Ist der erste Knoten fertig konfiguriert, kopieren Sie per DCP die Konfigurationen auf den zweiten und lassen den Cluster-Service automatisch starten:

chkconfig heartbeat on

Ab sofort stellt der Master-Knoten alle konfigurierten Ressourcen bereit. Sollte er ausfallen, schwenken die Services auf den bisher passiven Knoten über. Um Datenverlust und doppeltes Mounten zu verhindern, ist ratsam dies mit einer Stonith Resource zu verhindern oder ein Clusterfilesystem einzusetzen. Die Stonith-Funktionalität erlaubt es dem entfernten Knoten, bei einer Split-Brain-Situation diesen auszuschalten oder zu reseten. Unter Split Brain versteht man eine Situation, in der beide Knoten aktiv werden können, zum Beispiel infolge eine gestörten Verbindung zwischen beiden.

Das hier gezeigten Szenario setzt auf herstellerunabhängige Storage-Anbindung mit I-SCSI. DRBD [8] könnte eine standortübergreifende Datenreplikation realisieren. Dabei empfiehlt es sich den initialen Datenabgleich im lokalen Netzwerk durchzuführen.

Für einen Active-Active-Cluster böte sich dagegen eine CTDB-Lösung und ein Fibre-Channel-SAN infrage, wie die folgenden Artikel es beschreiben.

Bastelstunde mit professionellem Ergebnis

Unter Anleitung dieses Workshops können Sie mit Linux einen Fileserver für heterogene Netze bereitstellen, dem es an keiner Funktionalität gegenüber einem Windows-Fileserver fehlt – außer vielleicht der Notwendigkeit Lizenzkosten zu entrichten. Statt der hier nur skizziert gezeigten einfachen Cluster-Methode dürfen auch die im nächsten Artikel gezeigt CTDB-Methode benutzen.

Je nach Anforderung und Infrastruktur entscheiden Sie über Verbesserungen und Modifikationen aller Art selbst – es ist ja freie Software. (mfe,jk)