Inhaltsverzeichnis
Um zu der angestrebten Lösung zu kommen, vernetzte Computer als einen virtuellen Großrechner zu nutzen, fehlen uns noch zwei wesentliche Voraussetzungen. Zum einen brauchen wir die Möglichkeit, Dateisysteme auf anderen Rechnern im Netz zu nutzen, zum anderen benötigen wir eine zentrale Verwaltung der wichtigsten Systemdaten.
Die Werkzeuge zur Lösung dieser Probleme stammen von der Firma SUN, die sie zunächst für ihre eigenen Netze entwickelte. Bald nach Einführung gab SUN dann aber die Rechte für diese Protokolle frei, so dass heute fast alle größeren Systeme darauf aufbauen.
Das Linux Network File System (NFS)
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.
Der prinzipielle Aufbau von NFS
Das Prinzip des NFS ähnelt dem der Windows-Netze, wenn es um die Freigabe von Verzeichnissen geht. Wir haben also auch einen Rechner, der als Fileserver dient und Verzeichnisse freigibt, und verschiedene andere, die die freigegebenen Verzeichnisse nutzen können.
Auf der Serverseite müssen folgende Voraussetzungen erfüllt sein:
- 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.
Die Clientseite muß jetzt nur noch über einen Kernel verfügen, der den Dateisystemtyp NFS kennt, dann können sie die exportierten (freigegebenen) Verzeichnisse mit dem mount Befehl mounten, als ob es lokale Laufwerke wären.
Probleme bei den Zugriffsrechten
Unix 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 efka 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------- efka user noch_geheimer.txt
werden eben nicht nach Usernamen (root, efka) 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 peter 502
Die oben genannten UserIDs sind also auch auf marvin vergeben, was dazu führt, dass 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 jatzt also so aus:
-rw-r----- root root geheim.txt -rw------- otto user noch_geheimer.txt
Die ganze Sache hätte zur Folge, dass otto plötzlich Dateien lesen und beschreiben kann, die eigentlich efka 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, dass 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 entlehnt) 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, dass sie auch schreibenden Zugriff haben. Standardmäßig ist vorgegeben, dass 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 Zeile kann so aussehen:
squash_uids=0-15,20,25-50
Jedesmal, wenn diese Einträge verändert werden, muß den beiden Daemonen rpc.mountd und rpc.nfsd ein HUP-Signal geschickt werden, um sie zu zwingen, die Datei /etc/exports neu einzulesen.
Die Client-Seite
Auf der Seite des Clients, also des Rechners, der auf ein Dateisystem eines anderen Rechners zugreifen will, gibt es nicht viel zu tun. Ein einfacher mount-Befehl reicht aus, um ein freigegebenes Verzeichnis in den Dateibaum zu hängen.
Um z.B. das Verzeichnis /usr/public auf dem Rechner hal in das lokale Verzeichnis /usr/local/public zu mounten, genügt es, den folgenden Mountbefehl anzugeben:
mount -t nfs hal:/usr/public /usr/local/public
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, in etwa so:
hal:/usr/public /usr/local/public nfs defaults 0 0
Dabei ist allerdings darauf zu achten, dass der Fileserver (in diesem Fall hal) schon läuft, bevor der Computer gestartet wird, dessen 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, dass der Bootvorgang weitergeht…
Das Network Information System (NIS)
Manchmal, gerade, wenn es erwünscht ist, dass alle Rechner gleich behandelt werden sollen, ist es von Vorteil, wenn es eine Methode gibt, die wichtigsten Systemdateien (z.B. /etc/hosts /etc passwd /etc/group …) zentral auf einem Server zu verwalten. Alle Zugriffe auf diese Dateien sollten auf diesen Server umgeleitet werden.
Genau diesen Mechanismus stellt NIS zur Verfügung. In einem lokalen Netz werden zwei Server zur Verfügung gestellt, die diese Dateien als zentrale Datenbank verwalten. Alle Nachfragen (etwa ein GetHostByName Systemaufruf auf die Datei /etc/hosts oder ein Einloggvorgang mit Passwortvergleich) werden auf den primären Server umgeleitet, falls dieser nicht erreichbar ist, wird der sekundäre Server (Slave) herangezogen.
Der primäre Server sorgt selbstständig dafür, dass alle Veränderungen auch an den Slave weitergegeben werden. So ist dieses System verhältnismäßig ausfallsicher. Immerhin ginge im gesamten Netz nichts mehr, wenn kein NIS-Zugriff auf die Passwort-Datenbank mehr möglich wäre.
Der Vorteil dieser Methode liegt auf der Hand, jeder User kann sich überall im Netz einloggen, sein Passwort verändern und mit dem neuen Passwort sich gleich darauf auf einem anderen Rechner anmelden. Jeder neu ins Netz aufgenommene Host muß nur in eine /etc/hosts aufgenommen werden, in die zentrale Datenbank. Probleme mit der Zugriffsverwaltung bei NFS (siehe oben) sind ausgeschlossen, weil sicher gewährleistet ist, dass alle User überall die gleiche UID und GID besitzen. Das Squashing ist damit also nicht mehr nötig.