Kapitel 13

NFS – Network File System

IN DIESEM KAPITEL

  • POSIX-Netzwerkverzeichnis
  • Sicherheit auf Computerebene
  • Automatisches Einhängen von Freigaben bei Bedarf

NFS (Network File System) wurde seinerzeit von der Firma Sun für UNIX entwickelt und stellt entsprechend ein POSIX-Dateisystem über das Netzwerk zur Verfügung.

So kann ein POSIX-Client auch auf dem Netzwerklaufwerk beispielsweise Dateirechte auf 600 setzen oder Links verwenden. Damit ist es auch möglich, Heimatverzeichnisse für Linux auf einem Server auszulagen oder auch Linux-Systembereiche zentral zur Verfügung zu stellen.

Da Windows-Systeme nur mit großen Klimmzügen zur Zusammenarbeit mit NFS zu bewegen sind und diese auch von den Vorteilen eines POSIX-Dateisystems keinen Nutzen ziehen können, sollte man in einem solchen Umfeld lieber auf einen Samba-Server (siehe Kapitel 12) ausweichen.

NFS ist für lokale Netzwerke gedacht und so ausgelegt, dass Server und Client eine Sicherheitseinheit darstellen. Idealerweise hat also jeder Benutzer netzwerkweit seine eindeutige UID.

Laborumgebung

Sie benötigen einen Computer für den NFS-Server und einen für den Client. Beide müssen Linux-Systeme sein. Das können Sie natürlich in einem LAN mit zwei Geräten hinbekommen.

Insbesondere, wenn Sie mit Automount arbeiten wollen, sind aber virtuelle Maschinen hilfreich, weil Sie durch das Klonen von Maschinen funktionierende Zwischenstände sichern können und im Zweifelsfall fehlerhafte Installationsversuche einfach entfernen können.

Ein einfacher NFS-Server

Einen NFS-Server für Linux können Sie mit dem folgenden Befehl installieren:

# apt update
# apt install nfs-kernel-server

Die Konfiguration eines NFS-Servers erfolgt in der Datei /etc/exports. Die Datei /etc/exports enthält die Verzeichnisse, die der NFS-Server zur Verfügung stellt. Der Aufbau der exports-Datei hat folgende Struktur:

  • Das Doppelkreuz (#) ermöglicht es, Kommentare in der Datei zu hinterlegen.
  • Jede Zeile beginnt mit dem Verzeichnis, das angeboten wird.
  • Nach einem oder mehreren Leerzeichen folgt die Beschreibung, welche Rechner auf diese Freigabe zugreifen dürfen. Im Beispiel unten erlaubt der Stern dies allen.
  • In der folgenden Klammer stehen, durch Kommata getrennt, die Rechte der Nutzer. Im Beispiel unten steht rw für das Recht zu lesen und zu schreiben.

Im folgenden betrachten wir eine sehr einfache exports-Datei. Sie enthält eine Freigabe für das Verzeichnis /var/nfs/fotos, das wir später noch anlegen werden.

# /etc/exports
/var/nfs/fotos *(rw)

Die grundlegende Konfiguration eines Servers wird hier im Kapitel dargestellt. Detailliertere Informationen und spezielle Optionen erhalten Sie über die Manpage von exports mit dem folgenden Befehl:

$ man 5 exports

Wie versprochen wird nun das Verzeichnis angelegt, in dem die Dateien Platz finden sollen, die zwischen Client und Server geteilt werden. Als Ort bietet sich wieder das Verzeichnis /var an, wo Serverdateien gern abgelegt werden.

# mkdir /var/nfs
# mkdir /var/nfs/foto

Immer wenn die Konfiguration des NFS-Servers in der Datei /etc/exports verändert wurde, muss der NFS-Server sie einlesen. Dazu verwenden Sie wieder systemctl. Der NFS-Dienst heißt aus dessen Sicht nfs-kernel-server.

# systemctl reload nfs-kernel-server

Der Server sollte bereits funktionieren. Wir wenden uns dem Client zu.

Ein einfacher NFS-Client

Eine NFS-Ressource ist ein POSIX-Dateisystem und wird darum immer mit dem Befehl mount irgendwo im Verzeichnisbaum eingehängt. Wollen Sie also einen NFS-Client installieren, benötigen Sie das Paket nfs-common, das den entsprechenden Mount-Befehl enthält.

# apt update
# apt install nfs-common

Informationen über den Server

Bevor Sie die NFS-Freigabe einhängen, können Sie erst einmal schauen, was der NFS-Server so zu bieten hat. Von der Clientseite aus zeigt der Befehl showmount, welche Exporte der NFS-Server anbietet und mit welchen Rechnern er verbunden ist. Um zu ermitteln, welche Verzeichnisse ein NFS-Server anbietet, wird der Befehl showmount mit der Option -e verwendet:

$ showmount -e server
Export list for server:
/var/nfs/foto *

In diesem Fall enthält die Datei /etc/exports offensichtlich nur einen Eintrag. Das Verzeichnis /var/nfs/foto wird allen interessierten Clients angeboten.

Einhängen einer NFS-Ressource

Der Client kann eine NFS-Ressource wie eine gewöhnliche Festplatte mit dem Befehl mount (siehe Kapitel 7) in seinen Verzeichnispfad integrieren. Dazu benötigt er, wie immer bei mount, root-Rechte.

# mount -t nfs server:/var/nfs/foto /mnt

  • -t nfs

    Die Option -t legt fest, dass NFS als Dateisystemtyp eingebunden wird. Allerdings erkennt Linux bereits anhand des Hostnamens, gefolgt vom Doppelpunkt, dass es sich um einen NFS-Export handelt, sodass eine explizite Angabe der Option -t nfs nicht unbedingt erforderlich ist.

  • server

    Die Bezeichnung des Rechners steht vor dem Doppelpunkt. Da im UNIX-Umfeld keine Laufwerksbuchstaben verwendet werden, ist der Doppelpunkt für die Adressierung eines Computers eindeutig. Der Rechner kann durch den Hostnamen oder die IP-Adresse spezifiziert werden.

  • Pfadname

    Dem Host folgt der Pfad der Ressource auf dem NFS-Server. Die Pfadangabe muss so lauten, wie sie in der Datei /etc/exports auf dem Server aufgeführt wird. Host, Doppelpunkt und Pfad dürfen nicht durch ein Leerzeichen voneinander getrennt werden.

  • Mountpoint

    Durch ein Leerzeichen abgesetzt, wird der lokale Pfad angegeben, an dem das NFS-Dateisystem in den Verzeichnisbaum eingehängt wird.

Das Beispiel hängt also das Verzeichnis /var/nfs/foto auf dem Computer server auf dem lokalen Rechner ins Verzeichnis /mnt ein. Dazu muss das Verzeichnis vor dem Einhängen angelegt worden sein, was bei /mnt immer der Fall ist.

Durch das Einhängen werden alle Dateioperationen, die unterhalb des Verzeichnisses /mnt stattfinden, auf der Festplatte des Rechners server erfolgen. Alle Dateiänderungen gehen über das Netzwerk vonstatten.

Einhängen beim Booten: /etc/fstab

Es ist eher untypisch, dass NFS-Dateisysteme nur kurzzeitig eingehängt werden. Normalerweise werden sie automatisch beim Booten eingebunden. Das erreichen Sie durch einen Eintrag in der Datei /etc/fstab. Der Eintrag sieht aus wie jeder andere, nur als Dateisystemtyp wird nfs angegeben, und statt der Partition wird die Adresse der Freigabe aus Host, Doppelpunkt und Pfad angegeben. Für das Beispiel würde der Eintrag folgendermaßen lauten:

# /etc/fstab
server:/var/nfs/foto /media/foto nfs user 0 0

Der Eintrag user ermöglicht es, dass auch ein Anwender und nicht nur root den Befehl mount ausführen kann.

Da dieser Eintrag in der fstab-Datei steht, braucht der Anwender nur die Quelle oder das Ziel anzugeben. Der jeweils andere Parameter und die Optionen werden automatisch hinzugefügt. Zum Beispiel:

$ mount /media/foto

Erlaubte Client-Computer

Bisher wurden mit dem Stern in der Datei /etc/exports alle Clients zugelassen. Diese Großzügigkeit sollte begrenzt werden. Zulässige Clients können auf verschiedene Arten beschrieben werden.

Eintrag in den Exporten

Bei jeder Freigabe können die Computer aufgezählt werden, die Zugriff auf die Freigabe haben. Dafür hatten wir bisher einen Stern verwendet, der allen Clients Zutritt erlaubt.

  • Ein einzelner Rechner kann über seinen Namen oder seine IP-Adresse spezifiziert werden.
  • Hosts können über ihren Hostnamen identifiziert werden. Dabei ist der Einsatz der Wildcards Stern und Fragezeichen möglich. Die Bezeichnung sekr* könnte also für alle PCs des Sekretariats stehen.
  • Netzwerke werden sinnvollerweise über ihre IP-Adresse angegeben. Die Subnetmask wird in der »Dotted«-Darstellung durch einen Schrägstrich abgetrennt angegeben. Beispielsweise:

    192.168.109.0/255.255.255.0

hosts.allow und hosts.deny

Die Dateien /etc/hosts.allow und /etc/hosts.deny erlauben beziehungsweise beschränken den Zugriff auf die angebotenen Dienste. In jeder Zeile dieser Dateien wird zunächst der Server genannt, der einen bestimmten Dienst verwaltet, und nach einem Doppelpunkt werden die Rechner aufgeführt. Die hier genannten Computer beziehen sich auf alle Dienste des Servers. Als Server wird für NFS portmap verwendet, auf dem NFS basiert. Um nur einzelnen Rechnern die Rechte zu gestatten, müssten Sie zunächst in der Datei hosts.deny alle denkbaren Rechner ausschließen:

# /etc/hosts.deny
portmap: ALL

Nun können Sie in der Datei hosts.allow die Rechner aufführen, die eine Erlaubnis haben:

# /etc/hosts.allow
portmap: 192.168.109.0/255.255.255.0

Einstellungen der Exportdatei

Die wichtigste Datei bleibt aber die Datei /etc/exports. Darum betrachten wir noch einmal die bisher etwas karge Version von oben.

# /etc/exports
/var/nfs/fotos *(rw)

Der Stern besagt, dass alle interessierten Computer berechtigt sind, die Ressource einzuhängen. Hier kann statt des Sterns ein Computername stehen. Allerdings ist das nicht ganz unproblematisch, weil dann sicher sein muss, dass der Namensdienst bereits laufen muss, wenn NFS diesen Namen benötigt. Darum verwendet man häufiger die IP-Adresse, auch gern die IP-Adresse des Netzwerks, das zugreifen darf. Dazu wird die Subnetmask hinter einem Schrägstrich angegeben (192.168.109.0/255.255.255.0).

In den runden Klammern hinter den berechtigten Computern werden Optionen in runden Klammern angegeben.

  • Durch die Option ro kann die Freigabe nur gelesen werden. Die Option rw erlaubt das Lesen und Schreiben.
  • Die Schreiboperationen laufen normalerweise synchron. Der Client kann also erst weiterarbeiten, wenn die Veränderung auf dem Server vollzogen ist. Das entspricht der Option sync. Wird stattdessen async verwendet, ist die Verarbeitung schneller, mit dem Risiko, einen inkonsistenten Zustand zu hinterlassen.
  • Auch die Option no_subtree_check beschleunigt den Zugriff. Dabei wird die Überprüfung unterlassen, ob die angeforderte Datei wirklich unterhalb des exportierten Baums liegt. Die Überprüfung wird durch subtree_check erzwungen.
  • Damit ein mit root-Rechten bewaffneter Client nicht diese auch auf dem Server anwendet, werden diese auf dem Server nicht root, sondern anonymous zugeordnet. Dies vollzieht die Option root_squash. Soll dies nicht erfolgen, dann muss die Option no_root_squash gesetzt sein.

Export mit Basisverzeichnis: fsid

Mit der Option fsid=0 oder fsid=root wird ein Basisverzeichnis festgelegt. Alle weiteren Exporte beziehen sich auf dieses Verzeichnis.

/var/nfs *(ro,fsid=0,no_subtree_check)
/var/nfs/foto *(rw,sync,no_subtree_check)
/var/nfs/home *(rw,sync,no_subtree_check)

Die Option fsid=0 sagt dem NFS-Server, dass das Verzeichnis /var/nfs das Basisverzeichnis ist. Die zweite Zeile setzt nun auf dem Verzeichnis auf. Das Verzeichnis /var/nfs/foto wird allerdings aus Sicht des Clients als /foto exportiert.

# mount -t nfs server:/foto /mnt

Benutzer

Der Schutz der Dateien gegen den Zugriff Unbefugter stört eigentlich immer die Zusammenarbeit. Aber spätestens beim ersten Einbruch wird sofort gefragt, warum der Schutz so lax gehandhabt wurde. Darum müssen Benutzer gegeneinander abgegrenzt werden. Wenn man zuvor mit Samba gearbeitet hat, ist es irritierend, dass NFS gar keine Benutzeranmeldung einfordert, sondern die Zugriffsrechte auf Computer-Basis vergibt.

Eindeutige Benutzerkennungen

Das Konzept hinter NFS geht davon aus, dass alle Benutzer im Netzwerk eindeutig sind, also eine zentrale Benutzerverwaltung erfolgt, die dafür sorgt, dass die User-ID immer eindeutig ist. Wenn das gegeben ist, ist NFS die konsequente Weiterentwicklung des POSIX-Benutzerkonzept, nur auf das Netzwerk ausgedehnt.

Bei kleinen Netzwerken mit wenigen Computern kann der Administrator noch dafür sorgen, dass die im Netzwerk eingesetzten Benutzer auf allen Systemen dieselbe UID haben. Die professionellere Lösung ist der Einsatz von NIS, das für den Zweck entwickelt wurde, POSIX-Einstellungen zu zentralisieren.

http://willemer.de/informatik/srvlinux/nis.htm

Heutzutage wird häufiger LDAP (siehe Kapitel 15) verwendet, da es plattformübergreifend arbeitet.

root

Problematisch ist das root-Konto. Es ist auf fast allen UNIX-artigen Systemen vorhanden und hat auf der lokalen Maschine unbegrenzte Macht. Es wäre fatal, wenn ein ungesicherter root-Zugang eines Arbeitsplatzes das komplette Netzwerk kompromitieren würde. Aus diesem Grund erhalten root-Konten im NFS explizit geringe Rechte.

Automatisches Mounten

Linux verfügt über einen Automounter. Er bindet Dateisysteme ein, sobald der Pfad, für den sie eingetragen wird, zugegriffen wird. Man kann natürlich im vorauseilenden Gehorsam alles einbinden, was eventuell benötigt wird. Das aber bindet Ressourcen unnötig und kann sogar zu Verklemmungen führen. In Kombination mit NFS können Sie Dateisysteme erst dann einbinden, wenn die Mount-Punkte angesprochen werden. Das dazu notwendige Paket heißt autofs und wird mit dem folgenden Befehl installiert:

# apt install autofs

Der Automounter überwacht vorher festgelegte Verzeichnisse. Sobald in diesen eine Datei oder ein Verzeichnis angefordert wird, wird das in der Konfiguration festgelegte Dateisystem eingebunden.

Konfigurationsdateien

Das AutoFS verwendete klassischerweise für die zentrale Steuerung die Masterdatei /etc/auto.master. Diese gibt es immer noch, allerdings bindet sie heute das Verzeichnis /etc/auto.master.d ein, indem Sie Ihre Konfigurationen ablegen sollten.

In dem Verzeichnis wird eine Masterdatei angelegt. Der Name ist nicht wichtig, allerdings muss er auf .autofs enden. In der Masterdatei werden die Verzeichnisse aufgelistet, für die jeweils eine eigene Konfigurationsdatei zuständig ist. Diese Masterdatei legen wir als /etc/auto.master.d/master.autofs an.

Jede Zeile der Masterdatei beginnt mit dem zu überwachenden Verzeichnis. Dann wird die Konfigurationsdatei genannt, in der die einzubindenden Dateisysteme stehen. Im folgenden Beispiel wird für das Verzeichnis /media/nfs die Datei /etc/auto.master.d/nfs zuständig sein:

# /etc/auto.master.d/master.autofs
/media/nfs /etc/auto.master.d/nfs

Hier ist es wichtig, nicht das Verzeichnis /media direkt zu verwenden, da Autofs das Verzeichnis in Beschlag nehmen wird und damit keine anderen mount-Versuche auf /media mehr zulassen wird. Danach wäre es nicht einmal mehr möglich, auf einen eingesteckten USB-Stick zuzugreifen.

Für das Einhängen in das Verzeichnis /media/nfs ist nun die Datei nfs im Verzeichnis /etc/auto.master.d zuständig. Darin stehen die Mount-Paramter für das Einhängen des NFS-Dateisystems.

# /etc/auto.master.d/nfs
foto -fstype=nfs,rw,retry=0 server:/var/nfs/foto

Damit wird ein Verzeichnis foto unter dem Basisverzeichnis /media/nfs überwacht und bei Bedarf angelegt. Es folgen die Optionen und anschließend die Quelle, beginnend mit dem Host, getrennt mit einem Doppelpunkt der Pfad, exakt wie er in der /etc/exports des Servers steht. Die Optionen:

  • fstype=nfs gibt an, dass es ein NFS-Dateisystem ist.
  • rw ermöglicht Schreiben und Lesen.
  • retry=0 sorgt dafür, dass der Client nach dem ersten gescheiterten Versuch aufgibt. Ansonsten würde der Automount minutenlang blockieren, falls der Server nicht erreichbar ist.

Start des AutoFS

Der Automounter basiert auf einem virtuellen Dateisystem namens AutoFS. Daraus resultiert der Name der Unit autofs. Nachdem Sie die Konfiguration fertig haben, können Sie den Automounter starten:

# systemctl start autofs

Ab diesem Augenblick wird für jeden Eintrag in der Automaster-Datei ein virtuelles Verzeichnis angelegt und ein Prozess namens automount gestartet, der sein virtuelles Verzeichnis überwacht. Sobald Sie in diesem Einhängepunkt auf eines der in der Konfigurationsdatei aufgeführten Verzeichnisse zugreifen, wird automatisch das Verzeichnis eingehängt. Die Verzeichnisse huhu und test hatte ich bei vorigen Experimenten eingelegt.

$ ls -al /media/nfs/foto
insgesamt 16
drwxrwxrwx 5 root root 4096 Dez 30 05:36 .
drwxr-xr-x 3 root root 0 Dez 31 11:08 ..
drwxr-xr-x 2 nobody nogroup 4096 Dez 28 08:44 huhu
drwxrwxr-x 2 linux linux 4096 Dez 30 05:36 test

Wildcards

Sie können in der Ressourcenkonfiguration auch Wildcards verwenden. Der folgende Eintrag in der Datei nfs sorgt dafür, dass bei jedem Zugriff auf irgendein Verzeichnis im Einhängepunkt automatisch das passende Gegenstück auf dem Server anhand des Benutzernamens gesucht wird.

* -fstype=nfs,rw,user,retry=0 server:/var/nfs/home/&

Auf der Serverseite wird ein Verzeichnis /var/nfs/home angelegt. Für jeden potientiellen User wird ein Verzeichnis angelegt, beispielsweise paul. Falls nun ein Benutzer paul auf dem Client das Verzeichnis /media/nfs/paul anfordert, wird es automatisch eingehängt.

Benutzerverzeichnisse zentral ablegen

Diese Flexibilität lässt sich nutzen, um die Benutzerverzeichnisse zu zentralisieren. Sie legen in der Masterdatei einen Eintrag für das Verzeichnis /home an. Sobald eines der Verzeichnisse angesprochen wird, wird es vom zentralen Server eingebunden. Auf diese Weise können Sie erreichen, dass Sie auf allen Arbeitsplätzen des Netzwerks immer das gleiche Benutzerverzeichnis haben.

# /etc/auto.master
/home /etc/auto.home

Bedenken Sie, dass das bisherige Verzeichnis /home verschwinden wird, wenn Sie den Automounter jetzt starten und damit auch alle bisher angelegten /home-Verzeichnisse. Darum ist es vermutlich sinnvoller für die zentral verwalteten Benutzer ein anderes Home-Verzeichnis zu definieren. Tatsächlich käme also /media/nfs/home infrage.

* -fstype=nfs,rw,nosuid 193.175.188.253:/home/nfs/homes/&

Sobald sich ein Anwender auf diesem System anmeldet, wird auf sein Benutzerverzeichnis zugegriffen. Der Automounter wird aktiv und bindet es vom Server server ein.

Wenn Sie nun noch die Benutzerverwaltung zentralisieren, müssen die Clients von den Benutzern überhaupt nichts mehr wissen.

Klassischerweise verwendet man für diese Verwaltung NIS (Network Information System). Dies ist zwar auf UNIX-Systeme wie Linux, Mac oder UNIX beschränkt, aber das gilt für NFS ja auch. Und bei einem Heimatverzeichnis für ein solches System ist es von entscheidender Bedeutung, dass die Dateieigenschaften zum System passen. In vielen Umgebungen gibt es aber bereits einen LDAP-Server für die Verwaltung der Benutzer im Netzwerk. In diesem Fall können Sie auch diesen nutzen.

Kombination aus LDAP und Automounter

Das folgende Beispiel nutzt den Automaounter und kombiniert ihn mit einem LDAP-Server so, dass die Benutzerverwaltung über den LDAP-Server laufen und die Heimatverzeichnisse der Benutzer auf einem NFS-Server liegen, die dann mithilfe des Automounters in den Arbeitsplatz-Computer eingehängt hat.

Als Ergebnis können wir in einem Büro mehrere PCs aufstellen, an denen sich jeder Mitarbeiter anmelden kann und immer den Zustand vorfindet, den er auf einem beliebigen anderen PC zuletzt bearbeitet hat.

Es werden zwei Server benötigt. Ich habe diese ldapsrv und nfssrv genannt. Beide können auf dieselbe IP-Adresse zeigen, aber auch getrennt werden. Für meine Installation wurde der LDAP-Server von anderer Seite zu Verfügung gestellt, also musste beides getrennt laufen. Diese Zuordnung kann man in der lokalen Datei /etc/hosts pflegen, oder Sie installieren ein lokales DNS, wie in Kapitel 8 beschrieben.

  • Der LDAP-Server speichert die Benutzerkennung, das Passwort und den Pfad zum Heimatverzeichnis auf dem lokalen PC.
  • Der NFS-Server ist mit viel Plattenplatz ausgestattet und stellt für alle Anwender der Firma diesen zur Verfügung.

Der Client, also der Arbeitsplatz-PC muss nun die Netzwerkressourcen nutzen:

  • Bei der Anmeldung des Benutzers wird der LDAP-Server angesprochen. Dieser prüft das Passwort und wenn er erfolgreich war, liefert er den Pfad des Heimatverzeichnisses.
  • Der Automount sorgt dafür, dass beim Betreten des Heimatverzeichnis direkt nach der Anmeldung der zugehörige Festplattenspeicher an der Position eingehängt wird, die im LDAP hinterlegt ist.

Mit den Kenntnissen, die wir in diesem Kapitel über NFS und Automount gewonnen haben, kombiniert mit der Benutzerverwaltung, die im Kapitel 15 über LDAP vorgestellt wird, müsste das ja alles kein Problem sein. Aber der Teufel ist ein Eichhörnchen.

Zugriff auf den LDAP-Server

Die Benutzerverwaltung wird im Kapitel 15 ausführlich dargestellt. Und da zusätzliche Seiten Papier das Buch nur teurer machen, werde ich das hier nicht noch einmal vollständig ausrollen.

Der LDAP-Server stellt eine posixAccout-Objektklasse zur Verfügung, die User, Passwort und den Pfad des Home-Directorys liefert. Typischerweise wird dort /home/anna für den Benutzer anna hinterlegt. So war es jedenfalls in meinem Umfeld.

Was so naheliegend aussieht, macht es ein klein wenig komplizierter. Das Verzeichnis /home muss nun von AutoFS verwaltet werden und darum können dort keine anderen Verzeichnisse liegen. Lokale Benutzer können dort also nicht mehr eingerichtet werden. Wir wollen natürlich mindestens einen lokalen Benutzer zulassen, damit wir den PC noch administrieren können.

Die Lösung ist, dass die lokalen Benutzer umziehen müssen. Ich habe dazu ein Verzeichnis /local angelegt und in der Datei /etc/passwd für alle lokalen Benutzer das Verzeichnis von /home auf /local umgestellt.

# mkdir /local
# mv /home/* /local

Nun sollte auf jeden Fall möglichst sofort einmal der Computer neu gestartet werden.

Zugriff zum LDAP-Server

Der Client muss bei der Anmeldung auf den LDAP-Server zugreifen. Bei der Installation der Pakete libnss-ldapd und libpam-ldapd wird die Adresse des Servers angegeben. In der Datei /etc/nslcd.conf stehen dann hoffentlich Zeilen, wie etwa diese:

# /etc/nslcd.conf
uri ldap://ldapsrv
base dc=willemer,dc=edu

Natürlich müssen Sie die Eintragungen an Ihre Verhältnisse anpassen. Eine kleine Gemeinheit stellte sich heraus. Der LDAP-Server lieferte als Login-Shell /bin/false. So konnte sich niemand einloggen. Hier hilft das map-Kommando.

# /etc/nslcd.conf
uri ldap://ldapsrv
base dc=willemer,dc=edu
map passwd loginShell “/bin/bash”

Erzeugen des Heimatverzeichnisses

Es ist mindestens beim ersten Mal erforderlich, das Heimatverzeichnis für einen Benutzer anzulegen. Das macht das System allerdings nicht von allein. Es beklagt sich lieber, dass nichts da ist. Um das zu ändern, rufen Sie den Befehl pam-auth-update auf. Dort wird eingestellt, dass das Heimatverzeichnis für den Benutzer erzeugt wird, sofern es noch nicht vorhanden ist.

Wenn ich meinen LDAP-Server frage, liegen alle Benutzerverzeichnisse direkt unter /home. Das wird in den meisten Installationen so sein, weil das ja eigentlich auch Standard ist. Das sollte auf den ersten Blick auch kein Problem sein. Schließlich könnten Sie /home als Ausgangspunkt für den Automount definieren. Allerdings kann PAM dort keine Verzeichnisse erzeugen, da Automount dieses Verzeichnis gegen lokale Änderungen blockiert.

Um das auszutricksen, legen Sie auf dem Server ein Zwischenverzeichnis an, das mit dem Einhängen der Freigabe auch auf dem Client erscheint. In diesem Verzeichnis hat der Client Schreibberechtigung. Gehen wir von der oben genannten Situation aus, wird vom Server /home/nfs/homes exportiert. Nun hängen wir noch ein Verzeichnis namens auto an. Wie das Verzeichnis heißt, ist eigentlich egal.

Allerdings glaubt PAM immer noch, dass die Benutzerverzeichnisse direkt unter /home liegen. Wir können PAM aber weismachen, dass das auch hier der Fall ist, indem wir das Verzeichnis /home durch einen symbolischen Link ersetzen. Bevor Sie den Löschbefehl ausführen, sollten Sie sicher sein, dass Sie unter /home nicht noch Daten haben, die Sie vermissen würden.

# rm -rf /home
# ln -s /media/homes/auto /home

Legt PAM nun ein Verzeichnis /home/anna an, wird tatsächlich ein Verzeichnis anna unter /media/homes/auto erzeugt. Meldet sich anna später an, wird sie durch den symbolischen Link in das Verzeichnis /media/homes/auto/anna umgeleitet. Alle sind zufrieden.

Der NFS-Server

Auf dem NFS-Server muss eine Konfigurationsdatei /etc/exports erstellt werden. Danach müssen die exportierten Verzeichnisse angelegt werden.

/etc/exports

# /etc/exports
/home/nfs *(ro,fsid=0,sync,no_subtree_check)
/home/nfs/homes *(rw,sync,no_root_squash,no_subtree_check)

Wichtig ist die Option no_root_squash. Bei fehlendem Benutzerverzeichnis wird PAM nämlich ein Verzeichnis unter root-Rechten anlegen wollen. Dieser hat auf NFS-Dateisysteme normalerweise aus Sicherheitsgründen keine Rechte. Damit würde das Anlegen des Benutzerverzeichnisses scheitern, sofern nicht die Option no_root_squash gesetzt ist.

Der Stern sorgt dafür, dass alle Computer, die den Server erreichen können, dort auch auf die NFS-Ressourcen zugreifen dürfen. Diese Großzügigkeit sollten Sie im Realbetrieb vielleicht ein wenig einschränken.

Anlegen der exportierten Verzeichnisse

Das exportierte Verzeichnis muss natürlich auch existieren. Es kann mit wenigen Befehlen angelegt werden. Die Option -p erlaubt dem Befehl mkdir, die Eltern des Verzeichnisses gerade mitzuerzeugen, falls sie noch nicht existieren.

# mkdir -p /home/nfs/homes/auto
# chmod 777 /home/nfs/homes/auto

Das exportierte Verzeichnis liegt bei mir unterhalb des /home-Verzeichnisses, weil bei meinem Server dort die große Datenfestplatte mit vielen Terrabytes eingehängt ist. Also habe ich einen Pseudobenutzer erfunden und fand den Namen nfs ganz passend. Allerdings gibt es keinen analogen Eintrag in der /etc/passwd.

Wozu das Verzeichnis auto dient, wurde oben schon beschrieben.

Das automatische Einhängen

Wenden wir uns wieder dem Arbeitsplatz zu. Sie müssen natürlich das Paket autofs installieren. Danach geht es an die Konfiguration. Im Verzeichnis /etc/auto.master.d wird eine Datei main.autofs angelegt. Aufgrund der Endung .autofs wird diese von Automount ausgewertet.

# /etc/auto.master.d/main.autofs
/media/homes /etc/auto.master.d/mediahomes

Die Datei sorgt dafür, dass sich die Datei mediahomes darum kümmert, wenn das Verzeichnis /media/homes angefasst wird.

# /etc/auto.master.d/mediahomes
* -fstype=nfs,rw,retry=0 nfssrv:/home/nfs/homes/&

Sobald auf /media/homes zugegriffen wird, wird vom NFS-Server das Verzeichnis /home/nfs/homes eingebunden.

Der Stern am Anfang besagt, dass ganz gleich, welches Verzeichnis angefordert wird, der entsprechende Name zu laden ist. Das kaufmännische Und bezeichnet den einzuhängenden Pfadnamen.

Meldet man sich auf dem Client mit einem Namen an, der im LDAP steht, für den es aber noch kein Home-Verzeichnis gibt, wird PAM eines erzeugen und dabei auf dem symbolischen Link zum Verzeichnis /media/homes/auto reiten.

linux@lmde:˜$ su - paul
Passwort:
Erstelle Verzeichnis '/home/paul'.
$ ls -l
insgesamt 0
$ pwd
/media/homes/auto/paul
$ ls -la
insgesamt 36
drwxr-xr-x 4 paul users 4096 20. Jan 13:26 .
drwxrwxrwx 6 root root 4096 20. Jan 13:26 ..
-rw-r--r-- 1 paul users 220 20. Jan 13:26 .bash_logout
-rw-r--r-- 1 paul users 3526 20. Jan 13:26 .bashrc
drwx------ 2 paul users 4096 20. Jan 13:26 .cache
drwxr-xr-x 5 paul users 4096 20. Jan 13:26 .config
-rw-r--r-- 1 paul users 22 20. Jan 13:26 .gtkrc-2.0
-rw-r--r-- 1 paul users 516 20. Jan 13:26 .gtkrc-xfce
-rw-r--r-- 1 paul users 807 20. Jan 13:26 .profile
$

Auf dem Server kann man sich die erzeugten Dateien ansehen. Man kann dann sehen, dass alle Dateien dem Benutzer paul gehören. Da der Server aber keinen Eintrag für paul in seiner /etc/passwd findet, wird die uid angegeben, die im LDAP mit 2002 hinterlegt ist.