zurück zu Linux Zertifizierungen LPIC
1.113.4 – Richtiges Verwalten von NFS, smb und nmb Dämonen
Prüfungskandidaten sollten wissen, wie man im Netzwerk freigegebene Dateisysteme mittels NFS einbindet, wie man NFS für den Export lokaler Dateisysteme konfiguriert und wie man den NFS-Server startet, anhält und neustartet. Ebenfalls enthalten ist die Installation und Konfiguration von Samba unter Verwendung des mitgelieferten GUI-Tools oder durch direkte Bearbeitung von /etc/smb.conf (Achtung: Bewußt ausgeschlossen sind fortgeschrittene Themen der NT-Domänen; einfaches Freigeben von Verzeichnissen und Druckern sowie das korrekte Einrichten von nmbd als WINS-Client sind jedoch enthalten).

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/exports
* /etc/fstab
* /etc/smb.conf
* mount
* umount

Einhängen freigegebener Verzeichnisse
Unter Linux werden freigegebene Verzeichnisse ähnlich wie bei Windows als Netzlaufwerke betrachtet. Allerdings werden sie nicht mit einem Laufwerksbuchstaben versehen, sondern – wie alle anderen Laufwerke auch – in den Dateibaum gemountet.

Es gibt prinzipiell zwei grundlegende Techniken der Freigabe. Entweder ist ein Verzeichnis über das Network File System (NFS) freigegeben, oder über das Server Message Block Protokoll (SMB). NFS ist in der Regel von Unix/Linux Maschinen angeboten, SMB ist die Technik der Windows-Freigaben.

Einhängen von NFS-Freigaben
Eine NFS-Freigabe wird durch einen einfachen mount Befehl eingebunden. Dazu muß aber statt einer Gerätedatei ein NFS-Pfad eingegeben werden. Dieser Pfad hat die Form

Hostname:/absoluter/Pfad

Um beispielsweise das freigegebene Verzeichnis /usr/public des Rechners hal in unser lokales Verzeichnis /mnt einzuhängen, wird der Befehl

mount -t nfs hal:/usr/public /mnt

eingegeben. Normalerweise kann die Angabe des Dateisystemtyps (-t nfs) auch weggelassen werden, da der mount-Befehl aus der Struktur der Pfadangabe erkennt, daß es sich um NFS handeln muß.

Dieser Prozess kann natürlich auch automatisiert werden, damit das Verzeichnis bei jedem Start des Rechners wieder gemountet wird. Dazu muß wie bei lokalen Partitionen ein Eintrag in die Datei /etc/fstab gemacht werden. Unsere Beispielfreigabe würde folgenden Eintrag benötigen:

hal:/usr/public /mnt nfs defaults 0 0

Dabei ist allerdings darauf zu achten, daß der Fileserver (in diesem Fall hal) schon läuft, bevor der Computer gestartet wird, dessen /etc/fstab diese Zeile enthält. Sonst versucht der Rechner das Verzeichnis von hal zu mounten und es kann eine ganze Weile dauern, bis der Timeout dafür sorgt, daß der Bootvorgang weitergeht.

Einhängen von SMB-Freigaben
Freigaben von Windows-Rechnern (oder von Samba-Servern) werden über das SMB-Protokoll gesteuert. Diese Freigaben müssen im Gegensatz zu NFS-Freigaben nicht mit ihrem vollen Pfad angegeben werden, sondern besitzen einen sogenannten Freigabenamen. Dieser Name wird normalerweise unter Windows in der folgenden Form zusammen mit dem Rechnernamen zu einem Netzwerkpfad:

HostnameFreigabename

Da der Backslash aber eine Sonderbedeutung für die Shell hat, gibt es unter Linux verschiedene Möglichkeiten, wie diese Angabe gemacht werden darf:

HostnameFreigabename
//Hostname/Freigabename
“HostnameFreigabename”

Entweder wird also für jeden Backslash ein doppelter Backslash angegeben, oder statt Backslashs werden normale Slashs benutzt. Die dritte Alternative ist die Ausblendung der Sonderbedeutung des Backslashes durch Anführungszeichen.

Um eine SMB-Freigabe einzuhängen, wird entweder der spezielle Befehl smbmount benutzt, oder der normale mount-Befehl, zusammen mit dem Dateisystemtyp smbfs. Um also die Windows-Freigabe mit dem Freigabenamen public des Rechners winserver1 ins lokale Verzeichnis /mnt zu mounten, kann einer der beiden folgenden Befehle verwendet werden:

mount -t smbfs //winserver1/public /mnt
smbmount //winserver1/public /mnt

Allerdings wird auf diese Weise immer nach einem Passwort gefragt, selbst wenn das Verzeichnis auf dem Windows-Rechner ohne Passwort freigegeben wurde. Mit den folgenden Optionen kann mit diesen Passwörtern umgegangen werden:

username=Name
Der Usernamen des Windows-Users wird angegeben
password=Passwort
Das Passwort für die Freigabe wird angegeben
guest
Es existiert kein Passwort, es muß also auch nicht nach einem gefragt werden.

Diese Optionen werden dem mount-Befehl zusammen mit dem Schalter -o angegeben, also etwa

mount -t smbfs -o guest //winserver1/public /mnt

Der smbmount Befehl hängt diese Optionen – auch durch -o eingeleitet an den Befehl hinten an:

smbmount //winserver1/public /mnt -o guest

Um den Prozeß zu automatisieren, wird wiederum ein Eintrag in die Datei /etc/fstab gemacht, der unbedingt als Option entweder guest oder Username und Passwort benötigt.

//winserver1/public /mnt smbfs defaults,guest 0 0

Wenn die Windows-Freigabe die Angabe eines Usernamens und Passwortes erwartet, so könnten hier natürlich auch die Optionen username=… und password=… angegeben werden. Das ist aber keine gute Idee, denn die Datei /etc/fstab ist von allen Usern lesbar. Aus diesem Grund gibt es die Möglichkeit, hier einen Dateinamen anzugeben, mit der Option credentials=Dateiname. Die angegebene Datei kann dann Einträge der Form

username = Wert
password = Wert

enthalten. Diese Datei wird nicht von aller Welt lesbar sein, also sind die Passwörter sicher.

Verzeichnisse mit NFS freigeben
Um selbst Verzeichnisse mit NFS freizugeben, müssen ein paar Bedingungen erfüllt sein, die hier näher erläutert werden sollen.

Technisch gesehen baut das Network-File-System auf einer Entwicklung auf, die Remote Procedure Call (RPC) genannt wird. Dieser “entfernte Prozeduraufruf” nutzt die Portnummern oberhalb 10000 um es zu ermöglichen, Client-Server Software zu steuern. Der Server stellt bestimmte Prozeduren zur Verfügung, die jeweils einer bestimmten Portnummer zugeordnet sind. Ein Client im Netz kann nun diese Prozeduren aufrufen, es entsteht eine Art gemischtes Programm, ein Teil läuft auf dem Client ab, ein anderer Teil auf dem Server.

Die Zuweisung der Ports für das RPC-System übernimmt der portmapper, ein Programm, das immer laufen muß, wenn ein Rechner RPC-Service anbieten will.

Die oben genannte Aufteilung macht sich NFS zu Nutzen, indem dieses System Prozeduren zur Verfügung stellt, die sich auf den Zugriff auf Dateisysteme beziehen. Diese Prozeduren werden jetzt vom NFS-Client aufgerufen, um Zugriff auf ein Dateisystem zu bekommen.

Die folgenden Voraussetzungen müssen erfüllt sein, um Verzeichnisse mit NFS freizugeben:

* Der portmapper muß laufen.
* Die Daemonen rpc.nfsd und rpc.mountd müssen laufen.
* Beide erhalten ihre Konfigurationsinformationen über die Datei /etc/exports – Diese Datei enthält die Informationen, wer was mounten darf.

Probleme bei den Zugriffsrechten
Linux erweckt zwar den Anschein, als ob es die Zugriffsrechte nach Usernamen verwalten würde, hinter den Kulissen arbeitet es aber ausschließlich mit den numerischen UserIDs. Das führt beim Mounten von Dateisystemen übers Netz zu Problemen mit der Sicherheit, was Dateizugriffe angeht.

Ein Beispiel:

Auf dem Rechner hal existieren die User:

Username UID
root 0
peter 501
hans 502

Der Rechner hal exportiert sein /usr Verzeichnis jetzt an alle anderen Rechner im Netz. Dabei bleiben natürlich die Zugriffsrechte erhalten. Doch die exportierten Dateien

-rw-r—– root root geheim.txt
-rw——- peter user noch_geheimer.txt

werden eben nicht nach Usernamen (root, peter) verwaltet sondern nach ihren User IDs also 0 und 501.

Der Rechner marvin will das freigegebene Verzeichnis von hal jetzt mounten. marvin hat jedoch andere User:

Username UID
root 0
otto 501
hugo 502

Die oben genannten UserIDs sind also auch auf marvin vergeben, was dazu führt, daß marvin jetzt mit den neuen Namen arbeitet, nicht nur mit den Namen sondern eben auch mit den Rechten dieser User. Die gemounteten Dateien sähen jetzt also so aus:

-rw-r—– root root geheim.txt
-rw——- otto user noch_geheimer.txt

Die ganze Sache hätte zur Folge, daß otto plötzlich Dateien lesen und beschreiben kann, die eigentlich peter gehören und für alle anderen unlesbar sein sollten.

In den Fällen, in denen diese Erscheinung unvermeidbar ist (weil es z.B. nicht möglich ist, alle User überall gleich zu nummerieren) kann ein Mechanismus angewandt werden, der etwas genauere Betrachtung verdient, das Squashing.

Diese Technik wird vorwiegend bei root-Zugängen angewandt; root hat immer die UserID 0 egal ob es sich um die selbe Person handelt oder nicht. Also kann dafür gesorgt werden, daß sich der root-Zugriff auf ein gemountetes Dateisystem in eine andere UserID verwandelt. NFS versucht es zunächst mit dem Usernamen nobody, wenn es den nicht gibt, so weist es dem zugreifenden root die UID und GID -2 zu. Man spricht hier von der anonymen UserID.

Manchmal ist es auch erwünscht, anderen Usern ebenfalls die anonyme UserID zuzuweisen, NFS bietet die Möglichkeit diese Zuweisung zu übernehmen.

Der Aufbau der Datei /etc/exports
Die Datei /etc/exports steuert die Zugriffsrechte anderer Rechner auf die Verzeichnisse des Servers. Hier werden Verzeichnisse freigegeben und die entsprechenden Optionen (etwa ReadOnly) gesetzt.

Die Datei hat eine einfache Form, zeilenweise werden die einzelnen Verzeichnisse angegeben und mit Zugriffsbestimmungen versehen. Dabei sind Wildcards möglich um möglichst flexibel in der Unterscheidung zu sein, wer was mounten darf.

In Klammern können noch Optionen gesetzt werden, die die Zugriffsrechte betreffen (Read only …) oder die das Squashing (siehe oben) steuern. Am Besten sehen wir uns das einmal an einem Beispiel (der Handbuchseite entnomme) an:

# Beispielhafte /etc/exports Datei
/ master(rw) trusty(rw,no_root_squash)
/projects proj*.mydomain.de(rw)
/usr *.mydomain.de(ro)
/home/joey pc007(rw,all_squash,anonuid=501,anongid=100)
/pub (ro,all_squash)

Der erste Eintrag bestimmt zwei Rechner (master und trusty) die das ganze Wurzeldateisystem mounten dürfen. Das rw in Klammern besagt, daß sie auch schreibenden Zugriff haben. Standardmäßig ist vorgegeben, daß der root-account über Squashing auf die Anonyme UID gelegt wird. Mit der Option no_root_squash wird dieses Squashing ausgeschaltet. Der Systemverwalter von trusty hat also tatsächlich auf dem gemounteten Dateisystem Rootrechte.

Der nächste Eintrag beschreibt die Möglichkeit aller Rechner, deren Namen mit proj beginnen und auf .mydomain.de enden, das Verzeichnis /projects zu mounten. Schreibender Zugriff ist möglich.

Das Verzeichnis /usr wird in der dritten Zeile für alle Rechner der Domain mydomain.de freigegeben. Es kann aber nur Read-Only gemountet werden, Veränderungen sind also nicht möglich.

Die nächste Zeile beschreibt den Rechner pc007, der das Verzeichis /home/joey mounten darf. Es handelt sich um einen typischen Eintrag für PCs, alle User werden gesquasht, als Anonyme UID wird 501 angenommen, als GID 100.

Das letzte Beispiel zeigt einen Eintrag, der von der ganzen Welt (sofern sie Zugriff auf unser Netz hat) benutzt werden kann und das Verzeichnis /pub als Read-Only freigibt. Alle UserIDs werden auf die Anonyme UID (nobody) gesetzt.

Eine genaue Möglichkeit zu bestimmen, welche UserIDs auf die anonyme abgebildet werden sollen, gibt es auch noch. Die Optionen squash_uids und squash_gids ermöglichen eine genaue Angabe, welche UIDs und GIDs verwandelt werden sollen. Eine gültige Angabe kann so aussehen:

… (squash_uids=0-15,20,25-50)

Jedesmal, wenn Einträge in der Datei /etc/exports verändert werden, muß den beiden Daemonen rpc.mountd und rpc.nfsd ein HUP-Signal geschickt werden, um sie zu zwingen, diese Datei neu einzulesen.

Statt einem HUP-Signal kann auch der Befehl exportfs -a eingegeben werden, der die Daemonen zwingt, die Datei neu einzulesen.

Einfache Freigaben mit Samba
In den meisten Fällen arbeiten in Computernetzen heute die Arbeitsstationen mit Windows-Betriebssystemen, entweder Windows 95/98/ME oder WindowsNT/2000/XP. Es wäre natürlich genauso möglich, alle Arbeitsstationen mit Linux auszurüsten, das würde aber eine sehr große Umstellung bedeuten, sowohl für die einzelnen Anwender, als auch für die Verwaltung. Oft kommen auch Programme zur Anwendung, die für Linux nicht zur Verfügung stehen und die Akzeptanz von Linux ist sicher auch nicht besonders hoch, bei Menschen, die eben gerade mal gelernt haben, mit Windows umzugehen…

Damit Linux als Server für Windows-Systeme eingesetzt werden kann, ist es nötig, daß ein Serverprogramm installiert wird, das die Netzwerktechnik von Windows zur Verfügung stellt. Die Protokollfamilie, mit der Windows-Netze ihre Datei- und Druckerdienste verwalten, heißt SMB (Server Message Block) und wird von allen Windows-Systemen (von Win 3.11 bis Win 2000/XP) verwendet. Die Implementierung dieser Protokollfamilie unter Linux (und anderen Unixen) heist Samba.

Samba bietet von der einfachen Fähigkeit, Datei- und Druckerdienste in Arbeitsgruppen zur Verfügung zu stellen, über die Integration in bestehende NT-Domains bis hin zur kompletten Emulation eines NT-PDC alle Funktionen, die gebraucht werden, um Linux-Rechner in ein bestehendes oder neu zu erstellendes Windows-Netz zu integrieren. Die Windows-Arbeitsstationen merken gar nicht, daß es sich bei dem Server um einen Linux-Rechner handelt, aus ihrer Sicht arbeitet hier ein Windows Server.

Das grundlegende Prinzip ist zunächst einmal sehr einfach. Um Samba auf einem Linux-Rechner zu installieren müssen zwei Daemonen gestartet werden:

* smbd
Der SMB-Daemon, der die Datei- und Druckerdienste zur Verfügung stellt.
* nmbd
Der NetBIOS Name Server, der das Prinzip der Rechnernamen in einem Windows-Netz unter Linux zur Verfügung stellt.

Beide dieser Daemonen erhalten ihre Konfigurationsinformationen aus einer einzigen Datei, /etc/smb.conf. Diese Datei enthält alle Einstellungen, die nötig sind, um SMB-Dienste zu aktivieren.

Samba ist üblicherweise ein Stand-alone Dienst, kann aber auch via inetd gestartet werden. Nachdem aber in den meisten Fällen ein Rechner mit Samba-Dienst hauptsächlich als solcher arbeitet, wird der stand-alone Variante meist der Vorzug gegeben. In diesem Fall erledigt das entsprechende Init-Script (z.B.: /etc/init.d/smb/) die Aufgabe, sowohl den SMB-Server smbd, als auch den NetBIOS-Nameserver nmbd jeweils mit dem Parameter -D (für Daemon) zu starten (oder zu stoppen).

Eine erste Samba Konfiguration
Samba wird grundsätzlich über eine einzige Konfigurationsdatei verwaltet, /etc/smb.conf. Diese Datei muß existieren, bevor der Server selbst gestartet wird, damit er überhaupt weiß, was er tun und lassen soll.

Wir werden jetzt eine sehr einfache smb.conf Datei durchsprechen, die die grundlegenden Prinzipien dieser Konfigurationsdatei zeigt. Die einzelnen Bereiche werden jeweils kommentiert, erklärt und denkbare Alternativen werden aufgezeigt.

Der grundsätzliche Aufbau dieser Konfigurationsdatei entspricht dem von Windows-INI-Dateien. Das heißt, die Datei besteht aus einzelnen Abschnitten, die immer durch Überschriften in eckigen Klammern voneinander getrennt sind. Kommentare innerhalb der Konfigurationsdatei werden durch Strichpunkte eingeleitet, nicht durch Doppelkreuze (Doppelkreuze funktionieren jedoch auch).

Alle Freigaben, also sowohl Drucker, als auch Dateifreigaben werden als sogenannte shares bezeichnet. Jedes Verzeichnis und jeder Drucker, der freigegeben wird ist also ein share und hat einen eigenen Abschnitt innerhalb der Konfigurationsdatei. Ein spezieller solcher Abschnitt ist [global], der globale Einstellungen ermöglicht. Aber genug der Theorie, fangen wir an. Das folgende steht in unserer /etc/smb.conf:

[global]
workgroup = ARBEITSGRUPPE
netbios name = MARVIN
security = SHARE
guest account = nobody

[public]
comment = Oeffentliches Verzeichnis
path = /usr/public
guest ok = Yes
read only = Yes

Wir haben nur zwei einfache Abschnitte in dieser Datei, [global] und [public]. Der erste Abschnitt beschreibt die globalen Einstellungen und muß diesen Namen tragen. Der zweite beschreibt eine Freigabe, deren Namen willkürlich auf “public” gesetzt wurde. Der Name könnte auch anders heißen, es ist einfach nur ein Name.
Die Sektion [global]
Sehen wir uns die [global]-Sektion einmal genauer an: Die erste Anweisung ist klar, hier wird die Windows-Workgroup definiert. Das Prinzip der Workgroups wurde von Windows 3.11 (Windows for Workgroups) eingeführt und definiert eine Arbeitsgruppe, um ein Netz überschaubarer zu halten. Windows NT (und Win 2000) arbeiten stattdessen mit dem Domain-Prinzip, aber Samba benutzt den Workgroup Eintrag später auch, um die Domain-Einstellungen vorzunehmen. Wir definieren hier also die Zugehörigkeit des Samba Servers zur Workgroup “Arbeitsgruppe”.

Der zweite Eintrag (netbios name = marvin) definiert den Namen, der aus der Sicht von Windows Rechnern für den Samba Server gültig ist. Wir dieser Eintrag weggelassen, dann wird der Standard-Unixname (DNS Name) des Servers gewählt.

Der Eintrag security = share legt fest, daß die Zugangssteuerung auf Freigabeebene erfolgt, das ist die simpelste Möglichkeit, die einzige, um keine Passwörter zu brauchen. Wir werden uns später mit dieser Einstellung noch intensiv auseinandersetzen.

Der nächste (und letzte) Eintrag der Sektion [global] beschreibt, unter welcher UserID der Dateizugriff stattfinden soll, wenn ein nicht authorisierter User (also ein Gast ohne Passwort) auf einen Dienst zugreift. Die Tatsache, daß Windows selbst keine vergleichbaren Usereinstellungen kennt, zwingt uns hier, einen User anzugeben, damit Linux weiß, welche Rechte hier zur Verfügung stehen. In diesem Fall ist es also der User nobody, ein User ohne besondere Rechte.

Wenn wir jetzt also von einem Windows-Rechner aus die Netzwerkumgebung ansehen und die Workgroup Arbeitsgruppe aufrufen, werden wir folgendes Bild zu sehen bekommen:

pic

Der Kommentar Samba 2.0.6 ist der voreingestellte Kommentar, den wir in der Sektion [global] auch ändern könnten, indem wir die Anweisung

server string = …

eingefügen. Diese Einstellung bietet noch die Möglichkeit, den Rechnernamen mit einem %h darzustellen, die Version von Samba bekommen wir mit %v. Hätten wir also in der Sektion [global] geschrieben:

server string = Samba Versuchsserver auf %h (Samba %v)

dann stünde im Kommentarfeld der Netzwerkumgebung unter Windows

Samba Versuchsserver auf marvin (Samba 2.0.6)

Das %h und %v sind also sogenannte Zeichenkettensubstitutionen, die vom Server durch eine bestimmte Zeichenkette ausgetauscht (substituiert) werden. Alle denkbaren Zeichenkettensubstitutionen, die Samba unterstützt, finden Sie hier:
Zusammenfassung Zeichenkettensubstitutionen

Samba kennt eine Menge von Zeichenkettensubstitutionen, die jeweils mit einem Prozentzeichen beginnen und vom Server durch eine bestimmte Zeichenfolge ausgetauscht (substituiert) werden. So ist es z.B. möglich, userbezogene Pfade zu setzen, wie in

path = /home/%u

Dieser Pfad würde – da %u für den aktuellen Usernamen ersetzt wird – zu /home/hans, wenn sich der User mit dem Namen hans eingeloggt hätte, sie würde aber zu /home/otto. wenn otto angemeldet wäre…

Samba 2.0 unterstützt die folgenden Substitutionen:

* %S
Der Name des aktuellen shares – sofern es einen gibt.
* %P
Das Wurzelverzeichnis des aktuellen shares – sofern es einen gibt.
* %u
Der Name des Users, der die Anfrage macht.
* %g
Name der primären Gruppe des Users %u.
* %U
Session User Name – Der Name, den der Client angab, nicht notwendigerweise der, den er dann bekommen hat.
* %G
Name der primären Gruppe von %U
* %H
Das Homeverzeichnis des Users %u
* %v
Die Versionsnummer von Samba
* %h
Der Internet Hostname des Rechners, auf dem Samba läuft.
* %m
Der NetBIOS Name des Windows-Clients – Sehr nützlich
* %L
Der NetBIOS Name des Servers. Das erlaubt es, unterschiedliche Konfigurationen anzubieten, je nachdem, wie der Server vom Client angesprochen wurde.
* %M
Der Internet Name der Client-Maschine
* %N
Der Name des NIS Home Directory Servers.
* %p
Der NIS Pfad des Homedirectories des aktuellen shares.
* %R
Der SMB-Protokoll-Level nach dem Handshake. Eins von CORE, COREPLUS, LANMAN1, LANMAN2 oder NT1.
* %d
Die Prozess ID des aktuellen Server-Prozesses.
* %a
Die Architektur der Client-Maschine. Nicht hundertprozent verlässlich. Eins von Samba, WfWg, WinNT, Win95 und UNKNOWN.
* %I
Die IP-Adresse der Client-Maschine.
* %T
Aktuelles Datum und Uhrzeit

Die Sektion [public]
Unserer zweite Sektion in der Datei /etc/smb.conf heißt [public]. Das ist – wie oben schon erwähnt – nur ein beliebiger Name und hat keinerlei syntaktische Bedeutung. Der Name ist allerdings der Freigabename, unter dem das freigegebene share (Verzeichnis) unter Windows dann zu sehen sein wird. Die Zeilen in diesem Abschnitt haben folgende Bedeutung:
Die erste Anweisung (comment = Oeffentliches Verzeichnis) definieren einen Kommentar, den wir dann in der Netzwerkumgebung unter Windows wiederfinden werden. Beachten Sie, daß Unix und Windows völlig anders mit Umlauten umgehen. Hätten wir Öffentlich statt Oeffentlich geschrieben, so hätte der Windows-User statt dem Ö ein | gesehen, was sicherlich weniger informativ gewesen wäre…
Die zweite Anweisung definiert den absoluten Pfad unter Linux, auf den sich diese Freigabe bezieht. Die Angabe path = /usr/public bedeutet also, daß unter dem Freigabenamen public das Verzeichnis /usr/public zu erreichen ist.
Die Angabe guest ok = yes bedeutet, daß dieses share ohne Passwort erreichbar ist. Stattdessen hätten wir auch schreiben können:

public = Yes

Es ist also ein öffentlich zugängliches Verzeichnis für alle Windows-User. Kein Passwort wird verlangt. Allerdings haben alle User in diesem Verzeichnis dann auch nur das Recht des Gast-Users.
Die letzte Zeile erklärt sich von selbst, read only = Yes meint natürlich, daß die Freigabe nur ReadOnly erfolgt, daß die Windows-User also dort nur lesen dürfen. Aus der Sicht von Windows bekommen wir also jetzt folgendes Bild, wenn wir oben den Rechner marvin angeklickt hätten:
pic
Beachten Sie, daß die Dateien, die auf dem Rechner marvin im Verzeichnis /usr/public liegen nur dann lesbar sind, wenn sie – aus der Sicht von Linux – vom User nobody lesbar sind. Wir haben ja oben angegeben, daß ein Gastzugriff unter dieser UserID verwaltet wird. Jeder passwortlose Zugriff auf dieses Verzeichnis wird jetzt unter der UserID von nobody vorgenommen.
Es ist auch möglich, für jedes angegebene share einen eigenen Gast-User festzulegen. Wenn die Anweisung guest account = … in einem Abschnitt vorkommt, der nicht die Sektion [global] ist, so gilt diese spezielle Abmachung nur für diesen share.
Zwei weitere interessante Anweisungen für jeden share sind

* browseable = Yes|No
Wenn die Option browseable = No gesetzt wurde, dann erscheint der share nicht in der Liste der freigegebenen Verzeichnisse in der Windows Netzwerkumgebung, steht aber trotzdem zur Verfügung, wenn man den entsprechenden Pfad (RechnernameFreigabename) angibt.
Standardmäßig steht browseable auf Yes.
* available = Yes|No
Mit dieser Option kann – wenn sie auf No gesetzt ist, ein share für den Augenblick abgeschaltet werden, ohne ihn aus der Datei /etc/smb.conf zu streichen oder langwierig auszukommentieren. Standardmäßig ist available auf Yes gestellt.

Selbstverständlich können beliebig viele shares angelegt werden, um verschiedene Verzeichnisse auf unterschiedliche Arten freizugeben. Jedes share bekommt einen eigenen Abschnitt in der smb.conf, beginnend mit dem Freigabenamen in eckigen Klammern, gefolgt von den entsprechenden Angaben…
Userverzeichnisse einbeziehen
Die primäre Aufgabe eines Fileservers ist es nicht nur öffentliche Dateisysteme anzubieten, sondern auch userbezogene Verzeichnisse anzubieten. Linux hat ja für jeden User der dem System bekannt ist, ein Verzeichnis, in dem dieser User alle Rechte bekommt. Er kann dort Dateien und Verzeichnisse anlegen und ist alleiniger Eigentümer dieser Daten.
Samba bietet einen sehr einfachen Mechanismus, der einem Windows User erlaubt, sein Home-Verzeichnis auf dem Linux-Rechner zu nutzen, wenn sein Username unter Linux der selbe Name wie der unter Windows ist. Erweitern wir unsere /etc/smb.conf Datei doch einmal um diesen Mechanismus zum laufen zu bringen:

[global]
workgroup = ARBEITSGRUPPE
netbios name = MARVIN
security = SHARE
guest account = nobody

[homes]
comment = Heimatverzeichnis
read only = No
create mask = 0750
browseable = No

[public]
comment = Oeffentliches Verzeichnis
path = /usr/public
guest ok = Yes
read only = Yes

Um diese Erweiterung auch aktiv zu machen müssen wir den Samba Server neu starten, am einfachsten mit

/etc/init.d/smb restart

Wenn wir uns jetzt auf unserem Windows-Rechner als – sagen wir mal – User hans anmelden – und ein User hans auf dem Linux-Rechner existiert, dann sieht die Liste der freigegebenen Shares in der Netzwerkumgebung jetzt folgendermaßen aus:
pic
Hätten wir uns aber als otto eingeloggt (und gäbe es einen User otto unter Linux) so hätten wir statt der Angabe der Freigabe von hans jetzt eben die von otto gesehen.
Die konsequente nächste Fragestellung ist jetzt natürlich die des Passworts, das wir für diesen Zugriff benötigen. Grundsätzlich gilt:

* Wenn das Passwort unter Windows das selbe Passwort wie unter Linux ist, so gewährt Samba Zugriff.
* Wenn das Windows-Passwort nicht das selbe wie das unter Linux ist, so muß ein Passwort angegeben werden.

Windows frägt im zweiten Fall dann einfach nach dem Passwort nach und gibt auch die Möglichkeit frei, das angegebene Passwort in einer Passwortliste zu speichern. Wird das Passwort gespeichert, so muß es beim nächsten Mal nicht erneut angegeben werden.

pic

Probleme ab Windows 98
Diese Passwort-Weitergabe funktioniert so bis Windows 95 ohne Probleme, ab Windows 98 kommt es aber nur zu der befremdlichen Fehlermeldung, das eingegebene Passwort sei falsch. Das liegt nicht daran, daß Sie es falsch eingegeben haben, sondern an einer Eigenschaft von Windows 98/NT/2000, die festlegt, daß Passwörter nicht unverschlüsselt über das Netz gegeben werden. Das ist ja eine eigentlich erfreuliche Eigenschaft, weil es die Sicherheit im Netz vergrößert, aber andererseits funktioniert jetzt der normale Mechanismus der Passwortüberprüfung des Unix-Passworts natürlich nicht mehr.
Die Lösung besteht darin, eine eigene Passwortverwaltung für den Sambadienst zu installieren. Das geschieht durch zwei einfache Schritte:

1. Die Zeile

encrypt passwords = Yes

wird in die [global] Sektion der /etc/smb.conf aufgenommen

2. Eine spezielle Datei /etc/smbpasswd enthält die Userinformationen über die Samba-User samt ihrer verschlüsselten Passwörter.

Um jetzt also diese Passwort-Datei anzulegen und verschlüsselte Passwörter zu generieren benötigen wir wiederum ein kleines Programm mit Namen smbpasswd. Dieses Programm erlaubt es, sofern es der Superuser root anwendet, neue Samba-User anzulegen und ihnen Passwörter zu vergeben. Ein Normaluser kann nur sein Passwort damit ändern. Um einen neuen User anzulegen schreibt root jetzt

smbpasswd -a Username

Er wird dann gleich nach dem Passwort des neuen Users gefragt, das Passwort wird verschlüsselt und zusammen mit der UserID des Users in der Datei /etc/smbpasswd abgelegt.
Damit also alles jetzt wirklich funktioniert muß die [global]-Sektion unserer smb.conf Datei jetzt folgendermaßen aussehen:

[global]
workgroup = ARBEITSGRUPPE
netbios name = MARVIN
security = SHARE
guest account = nobody
encrypt passwords = Yes

Und schon funktioniert die Freigabe der Userverzeichnisse.
Die Sektion [homes] ist also – wie die Sektion [global] eine spezielle Möglichkeit. Sie muß grundsätzlich diesen Namen tragen denn Samba übernimmt ja sehr spezielle Ersetzungsmechanismen, wenn dieser share angesprochen wird.
Drucker freigeben
Um Drucker für Windows-Rechner freizugeben, die an Linux Rechnern hängen, sind ein paar kleine Erweiterungen an unserer smb.conf Datei nötig. Zunächst einmal muß geklärt werden, wie Linux druckt. In der Regel wird Linux das BSD-Drucksystem benutzen, manchmal – seltener – aber auch das PLP System. Samba muß in der [global]-Sektion einen entsprechenden Eintrag besitzen:

[global]
workgroup = ARBEITSGRUPPE
netbios name = MARVIN
security = SHARE
guest account = nobody
encrypt passwords = Yes
printing = BSD

Um jetzt Drucker selbst freizugeben haben wir zwei Möglichkeiten:

* Alle Drucker werden freigegeben
* Bestimmte Drucker werden freigegeben

Wenn alle Drucker freigegeben werden sollen wird ein Mechanismus benutzt, der dem der Userverzeichnisse ähnelt. Wir legen ein spezielles share an, das zwingend [printers] heissen muß. Dieses share enthält folgende Anweisungen:

[printers]
comment = All Printers
path = /tmp
create mask = 0700
printable = Yes
browseable = No
guest ok = Yes

Der angegebene Pfad bezieht sich auf ein Verzeichnis, in dem alle User Schreibrecht haben (und dem also das Sticky-Bit gesetzt sein sollte). Die Create Mask legt fest, welche Permissions Druckaufträge haben sollen, die in diesem Verzeichnis liegen. Die Angabe printable = Yes bedeutet, daß – selbst wenn das Verzeichnis selbst Read only = Yes als Parameter hat, Druckaufträge dort abgelegt werden dürfen. Die Angabe browseable = No bedeutet, daß der share [printers] selbst nicht erscheint.

Auf diese Weise werden alle Drucker, die unter Linux in der /etc/printcap Datei auftauchen, dem Windows-Rechner angezeigt und freigegeben. Das heißt, daß auch wenn – wie bei vielen Distributionen üblich – mehrere logische Drucker angelegt werden, all diese logischen Drucker auch angezeigt werden:

pic

Das kann einen unbedarften Windows-User natürlich verwirren. Um aber nur einen einzigen Drucker anzuzeigen, wird statt des [printers] Abschnitts ein Abschnitt für den freizugebenden Drucker angelegt, dessen Name jetzt wieder frei wählbar ist:

[PSLaser]
comment = PS_600dpi-a4-auto-mono-600
path = /tmp
create mask = 0700
guest ok = Yes
printable = Yes
printer name = lp2

Der entscheidende Unterschied zu einem share für Verzeichnisse sind eigentlich nur die Anweisungen printable = yes und printer name = lp2

Daran merkt Samba, daß es sich hierbei um einen Drucker-Dienst und nicht um einen Dateidienst handelt. Der Windows-User bekommt jetzt folgendes Bild zu sehen:

pic

Die Angabe printer name = lp2 bezieht sich auf den Namen des Druckers, der unter Linux gültig ist. In diesem Fall darf natürlich auch nicht browseable = No eingetragen werden, sonst sieht der Windows-User den Drucker nicht in seiner Liste.

Die Angabe guest ok = yes ermöglicht das Drucken ohne Passworteingabe.
Sicherheitsebenen

Samba kennt verschiedene Sicherheitsebenen, die alle durch die Angabe

security = …

in der [global]-Sektion eingestellt werden. Das heißt, sie gelten immer für den gesammten Server und sind nicht für jedes einzelne share einstellbar. Denkbare Werte für security sind share, user, server und domain. Diese vier Sicherheitsebenen werden hier einzeln erläutert.

security = share

Bisher haben wir in unsere Samba Konfiguration immer die Zeile

security = share

in die [global]-Sektion eingetragen. Dieser Eintrag entspricht der “Zugriffssteuerung auf Freigabeebene” unter Windows. Es ist die geringste Sicherheitsstufe, die Zugriff auf bestimmte shares nur über die Frage klärt, ob ein share öffentlich ist oder nicht. Allerdings kann auch unter dieser Einstellung mit Samba eine userbezogene Freigabe realisiert werden, indem dem share die Anweisung

guest ok = No

gesetzt wird. In diesem Fall wird Samba ein Passwort anfordern, das zu dem Usernamen passen muß, der unter Windows angegeben wurde. Auch hier gilt, daß ab Win98 die Passwörter verschlüsselt übermittelt werden, also die Zeile

encrypt passwords = Yes

in der [global]-Sektion stehen muß. Zusätzlich muß der entsprechende User sowohl Linux bekannt sein, als auch ein verschlüsseltes Passwort in der Datei /etc/smbpasswd besitzen. (Siehe Userverzeichnisse)

Die Frage, wer dann nun was in dem Verzeichnis anstellen darf wird wiederum von Linux selbst beantwortet. Es gelten die normalen Unix-Dateizugriffsrechte des jeweiligen Users. Das ist auch der Grund, warum jeder Samba-User auch eine gültige Unix UserID besitzen muß.

Zusammenfassend ist also zu sagen, daß Samba mit dieser Methode noch wesentlich sicherere Zugriffe zulässt, als es Windows95/98 zulassen würde. Andererseits ist diese Methode erheblich eingeschränkt, was die Möglichkeiten der userbasierten Zugriffskontrolle angeht.

security = share wird hauptsächlich in Systemen eingesetzt, die alle Dienste frei – ohne Passwörter – anbieten wollen, oder in Systemen, deren User nicht identisch mit den Windows-Usern sind.

security = user

Eine andere Möglichkeit wird durch die Einstellung

security = user

in der [global]-Sektion ermöglicht. Das ist – seit Samba 2.0 – die voreingestellte Methode. In dieser Einstellung muß sich ein Windows-User zuerst “einloggen”, bevor er irgendwelche Dienste des Samba-Servers in Anspruch nehmen darf. Das heißt, er muß einen Usernamen und ein Passwort an den Samba-Server schicken, der wiederum überprüft, ob die beiden Angaben stimmen und erst nach erfolgreicher Prüfung Zugriff gewährt. Der Zugriff ist dann wiederum abhängig von den Linux-Rechten, die dieser User auf dem Samba-Server hat. Das heißt, daß diese Methode nur dann funktioniert, wenn auf dem Windows-Rechner die selben Usernamen existieren, wie auf dem Samba-Server.

Wie schon bei früheren Passwortübermittlungen wird auch hier wieder zwischen unverschlüsselter Passwortübermittlung (bis einschließlich Win95) und verschlüsselter Passwortübergabe (ab Win98) unterschieden. Das heißt, wenn die Windows-Rechner mindestens Win98 fahren, muß die Zeile

encrypt passwords = Yes

in der [global]-Sektion stehen und die User müssen mittels smbpasswd angelegt werden.

Beachten Sie, daß der Name der angeforderten Resource nicht an den Server weitergeschickt wird, bevor sich der Windows-User nicht korrekt angemeldet hat. Das ist der Grund, warum Gast-shares (guest ok) in diesem Modus nicht funktionieren, ohne daß User automatisch in einen Gastaccount umgewandelt werden. Aber auch dazu müssen sie sich zuerst korrekt anmelden, also einen Useraccount besitzen.

security = server

In diesem Modus versucht Samba die Passwortüberprüfung nicht selbst vorzunehmen, sondern die angegebenen Username/Passwort Kombinationen an einen anderen SMB-Server zur Überprüfung weiterzuleiten (z.B. einen NT-Rechner). Wenn das fehlschlägt, wird automatisch auf die Einstellung security = user zurückgeschaltet.

Damit Samba weiss, an welchen Server es die Passwortüberprüfung weiterleiten soll, muß der entsprechende Server mit der Angabe password server = … in der [global]-Sektion angegeben werden. Der angegebene Name muß ein NetBIOS Name sein, also der Name, unter dem der Rechner auch unter Windows ansprechbar ist. Dieser angegebene Server muß selbst im security = user Modus laufen, um die entsprechende Überprüfung vorzunehmen.

Achtung: Versuchen Sie niemals hier den Samba Server selbst einzutragen! Es würde zu einer Endlosschleife kommen, die den gesammten Samba-Server blockieren würde.

Aus der Sicht des Windows-Clients ist der Server-Modus absolut identisch mit dem User-Modus. Der Unterschied bezieht sich nur auf die Frage, wie der Samba-Server die Überprüfung der Zugriffsrechte vornimmt. Im User-Modus macht er es selbst, im Server-Modus leitet er es an einen anderen Server weiter. Natürlich kann dieser andere Server auch wieder ein Samba Rechner sein, der dann aber eben im User-Modus laufen muß…

Beachten Sie, daß der Name der angeforderten Resource nicht an den Server weitergeschickt wird, bevor sich der Windows-User nicht korrekt angemeldet hat. Das ist der Grund, warum Gast-shares (guest ok) in diesem Modus nicht funktionieren, ohne daß User automatisch in einen Gastaccount umgewandelt werden. Aber auch dazu müssen sie sich zuerst korrekt anmelden, also einen Useraccount besitzen.

security = domain

Dieser Modus funktioniert nur dann, wenn der Samba-Server mittels des Programms smbpasswd an eine bestehende Windows NT Domain angeschlossen wurde. Der Parameter encrypted passwords muß aktiviert sein. In diesem Modus versucht der Samba-Server alle Authentifizierungen an einen Primären- oder Backup Domain Controller einer Windows-NT Domain weiterzuleiten, genau so, wie es eine NT-Maschine selbst tun würde.

Trotzdem müssen User dem Linux-System bekannt sein, damit eine Bestimmung ihrer Zugriffsrechte auf einzelne Verzeichnisse möglich ist. Jeder User braucht also einerseits einen Account auf dem PDC der Windows-Domain und andererseits einen gültigen Acccount auf dem Linux-Server.

Wie schon bei dem Server-Modus, so ist dieser Modus aus der Sicht des Windows-Clients einfach der User-Modus. Der Unterschied liegt nur darin, auf welche Weise der Samba-Server die Passwörter authentifiziert.

Wie schon im Server-Modus, so muß auch hier der Rechner angegeben werden, der die Passwortüberprüfung vornimmt. Wieder benutzen wir die Angabe

password server = …

in der [global]-Sektion. Nur jetzt geben wir nicht einen Server an, sondern eine Liste, durch Kommata getrennt. Hier können wir den PDC und alle existierenden BDCs angeben, also etwa

password server = NT-PDC, NT-BDC1, NT-BDC2

Wird statt einer Liste einfach nur ein Pluszeichen (+) angegeben, so versucht Samba den PDC und die BDCs selbst herauszufinden.

Beachten Sie auch, daß der Name der Domain, der wir uns anschließen, wiederum mit dem Parameter workgroup = … angegeben wird.

Damit unser Samba-Server aber überhaupt Mitglied einer Domain werden kann, müssen wir erst dafür sorgen, daß er davon auch weiss. Dazu kommt wiederum das Programm smbpasswd zur Anwendung, das wir ja schon zum Anlegen der User und Wechseln der Passwörter benutzt hatten.

Mit dem Aufruf von

smbpasswd -j Domain

wird der Samba-Server in die genannte Domain aufgenommen. Damit das funktioniert, muß der Administrator der NT-Domain mit dem Programm Server Manager for Domains den primären NetBIOS Namen des Samba-Servers in die Liste der Domain-Mitglieder aufgenommen haben.

Erst nachdem dieser Befehl ausgeführt wurde, sollte die smb.conf auf security = domain gesetzt werden. Von nun an sendet der Samba-Server alle Anfragen an den PDC zur Authentifizierung weiter.

NMBD Einstellungen

Alle bisherigen Einstellungen, die wir in den vorangehenden Beispielkonfigurationen getroffen hatten, bezogen sich auf den SMB-Daemon smbd. Es ging um die Fragen der Freigaben und Sicherheitskonzepte. Damit ein Windows-Netz aber richtig funktioniert, muß zusätzlich noch ein Dienst laufen, der die NetBIOS-Namen in IP-Adressen umsetzt und die Liste der Windows-Netzwerkumgebung verwaltet, der NMBD. Dieser Daemon wird grundsätzlich zusammen mit dem SMBD gestartet, entweder über inetd oder als Stand-Alone-Server.

Die primäre Aufgabe dieses Daemons ist es, die Namensauflösung im SMB-Netz zu ermöglichen. Dabei ist es unerheblich, ob die entsprechenden NetBIOS-Namen den DNS-Namen entsprechen, es gibt aber viele Fälle, wo sich Probleme vermeiden lassen, wenn zumindestens der Samba-Server hier immer den selben Namen trägt.

Die Einstellungen des NMBD werden auch in der Datei /etc/smb.conf vorgenommen, dort aber nur in der [global]-Sektion. Dieses Kapitel beschreibt die notwendigen Einstellungen für die Namensauflösung, im nächsten Kapitel betrachten wir die Verwaltung der Browsing-List (Windows-Netzwerkumgebung), die auch vom NMBD übernommen wird.

Etwas genaueres zu NetBIOS Namen

NetBIOS ist die grundlegende Protokollfamilie für Windows-Netze. Es arbeitet mit den folgenden drei Transport/Vermittlungsschicht Protokollen:

*
TCP/IP
*
NetBEUI
*
IPX/SPX

Samba benutzt grundsätzlich nur NetBIOS über TCP/IP. NetBIOS Anwendungen (wie Samba) bieten ihre Dienste im Netz unter einem NetBIOS Namen an. Dieser Name muß vorher im Netz beansprucht worden sein. Nachdem aber diese Namen nicht zwangsläufig mit den DNS-Namen im TCP/IP Netz übereinstimmen müssen, gibt es zwei grundsätzliche Herangehensweisen, um im Netz Kommunikation zu ermöglichen. Entweder werden Broadcast-Aufrufe an alle angeschlossenen Rechner verschickt, oder es wird ein spezieller Windows Internet Name Service (WINS) angeboten, der die Auflösung von Namen in IP-Adressen vornimmt.

Größere Netze sollten grundsätzlich die zweite Möglichkeit (WINS) in Anspruch nehmen, denn sonst wird das Netz mit unnötig vielen Paketen belastet.

Um mit WINS arbeiten zu können muß ein Rechner im Netz diesen Dienst auch anbieten. Das kann entweder ein WindowsNT/2000 Rechner sein, oder eben wieder ein Samba Server. In der Regel wird der NT Rechner benutzt, wenn Samba in einer gemischten NT/Samba Umgebung arbeitet. Wenn nur Samba-Server zur Verfügung stehen, wird einer dieser Server den Dienst übernehmen.

Windows-Rechner müssen diesen Server dann entsprechend unter den Eigenschaften von TCP/IP eintragen:

pic

Zu beachten ist, daß – um die Netzwerkumgebung richtig darstellen zu können – immer nur ein WINS-Server pro Netzsegment (bzw. Workgroup) aktiv sein sollte. Ansonsten sehen die verschiedenen Windows-Clients jeweils nur die Rechner, die den entsprechend gleichen WINS-Server benutzen.
Samba als WINS-Client

Um einen Samba Server an einen bestehenden WINS-Server anzuhängen, also ihn zu zwingen, seine Dienste und Namensauflösungen über diesen Server vorzunehmen, muß nur die folgende Zeile in der [global]-Sektion eingetragen werden:

[global]
…
wins server = 123.45.67.89
…

Der Befehl wins server = erfordert entweder die IP-Adresse oder den DNS-Domainnamen des entsprechenden Servers.

Viele Dienste von Samba, die die Browsing-Liste betreffen funktionieren nur, wenn ein WINS-Server im Netz aktiv ist. Ob dieser Server jetzt ein NT-Rechner oder wiederum ein Samba-Server ist, spielt keine Rolle.
Samba als WINS-Server

Wenn in einem Netz keine NT-Maschinen laufen, so kann auch Samba selbst als WINS-Server arbeiten. Allerdings darf in diesem Netz dann absolut nur ein Samba-Server als WINS-Server agieren.

Die notwendige Einstellung in der smb.conf lautet:

[global]
…
wins support = yes
…

Beachten Sie, daß NIEMALS beide Einstellungen (Server und Client) gleichzeitig benutzt werden dürfen. Wenn Samba als Server arbeitet ist die Zeile wins server = … nicht nur unnötig, sondern schlicht verboten. Das %h und %v sind also sogenannte Zeichenkettensubstitutionen, die vom Server durch eine bestimmte Zeichenkette ausgetauscht (substituiert) werden. Alle denkbaren Zeichenkettensubstitutionen, die Samba unterstützt, finden Sie in der Zusammenfassung Zeichenkettensubstitutionen.