Administratorhandbuch:NFS
|
Seite fertig: Sollten Sie Änderungvorschläge oder Ergänzungen zu diesem Punkt haben, dann nutzen Sie bitte den Punkt Diskussion (oben). |
| NFS wird auf dem Arktur-Schulserver in Verbindung mit der Anmeldung mittels LDAP genutzt. Die aus älteren Arkturversionen stammende Anmeldung per NIS wird nicht mehr unterstützt. Die auf den Clients dadurch notwendig gewordene Umstellung von NIS auf LDAP ist bei SuSE-Linux problemlos. |
Der NFS Server
Was ist NFS?
NFS, das "Network File System", ist eine Client-Server-Applikation, welche entfernte Laufwerke (von einem Server) für den lokalen Rechner (den Client) transparent zur Verfügung stellt. Der Nutzer bekommt im Normalfall überhaupt nicht mit, das er seine Daten gar nicht "lokal" speichert oder lädt, sondern sie über das Netzwerk zum Server übertragen und von dort geladen werden. Dafür werden verschiedene Programme genutzt, die für eine konsistente Datenübertragung sorgen.
NFS basiert auf dem RPC (remote procedure call) Protokoll, welches ursprünglich 1980 (!) von Sun Microsystems entwickelt wurde, um Filesharing auf Unix-Plattformen zu ermöglichen.
Was ist die Gefahr von NFS?
Normalerweise benutzen die von NFS eingesetzten Programme keine weiteren Mittel um die Authentizität der Benutzer zu überprüfen. Das macht das System so gefährlich. Im Schulnetz brauchen Sie sich darüber allerdings nur dann Gedanken machen, wenn externe Rechner Zugriff auf das Intranet haben können.
Einerseits ist hierfür sicherlich das benutzte Übertragungsprotokoll UDP verantwortlich, welches als "zustandsloses" Protokoll keine Möglichkeit bietet, die Verbindung zwischen zwei Stationen zu überprüfen. Das macht das UDP-Protokoll zwar wesentlich schneller als das heute sehr bekannte TCP Protokoll und war seinerzeit sicherlich auch der Hauptgrund für Sun Micosystems auf diese Übertragungstechnik zu setzen (weniger "Protokoll" = weniger Serverbelastung) - allerdings mussten so auch zusätzliche Sicherungsmassnahmen eingeführt werden, um auch nur eine sichere Übertragung der Pakete sicherzustellen: so versucht NFS für jeden ausgesendeten Befehl eine Antwort zu bekommen. Bleibt diese aus, so wird der Befehl immer wieder wiederholt. (Anmerkung: bei TCP ist das Verfahren zwar ähnlich - setzt aber schon auf "Protokollebene" an; der das Protokoll nutzende Dienst braucht sich darum nicht zu kümmern.)
NFS-Server einrichten
In Unix-Netzwerken wird auf diese Weise meist das Heimatverzeichnis /home auf allen Rechnern gleichartig zur Verfügung gestellt, aber auch das Mailverzeichnis kann exportiert werden.
Dazu muss zunächst dem Arktur-Schulserver gesagt werden, welche Verzeichnisse er wie freigeben soll. Das geschieht in der Datei /etc/exports . Die folgende Abbildung enthält ein Beispiel für diese Datei an einem Arktur-Schulserver:
# /etc/exports beim Arktur-Schulserver # wir geben folgendes im ganzen Netz frei /cdrom 192.168.0.0/255.255.192.0(ro) /home 192.168.0.0/255.255.192.0(rw) /var/spool/mail 192.168.0.0/255.255.192.0(rw) # und das bekommt nur der Lehrerrechner zu sehen /var/log Lehrer.rg1.dd.sn.schule.de(rw)
- Abbildung: Beispiel für /etc/exports
Hier wird das CD-ROM-Laufwerk an alle Clients des Netzes 192.168.0.0 mit der Netzmaske 255.255.192.0 mit der Option ro=read-only, also zur zum Lesen freigegeben. Das Home-Verzeichnis hingegen wird mit der Option rw=read&write, also zum Lesen und Schreiben freigegeben, ebenso das Mailverzeichnis /var/spool/mail. Das Verzeichnis /var/log wird hingegen nur einem Rechner, dafür aber mit vollem Lese- und Schreibzugriff freigegeben.
Zusätzlich lassen sich noch einige Sicherheitsattribute setzen:
secure Hier werden nur Anfragen von einem hohen Port an einen niedrigeren (und damit priviligierten) Port erlaubt. Damit wird die Gefahr verringert, dass ein normaler Nutzer einen NFS-Server aufsetzt und diesen dann mit ihrem Server "unter gleichen" reden lässt. Diese Einstellung ist zwar Standard - Sie ausdrücklich zu setzen beruhigt aber auf jeden Fall das Gewissen.
noaccess Mit diesem Parameter können Unterverzeichnisse eines exportierten Verzeichnisses gesperrt werden.
link_relative Hiermit werden vorhandene Links relativ zum eigentlichen Root-Verzeichnis des Servers gesetzt. Sollte der Server z.B. mit einer Chroot-Umgebung laufen, so würden Links auf das reale Dateisystem des Servers sonst ins Leere zeigen.
link_absolute Hier werden die Links im exportierten Verzeichnis absolut gesetzt. Ein "relativer" Link auf dem Server wird dem Client also als "absolut" vorgegaukelt.
root_squash Standardeinstellung: Hier wird der Nutzer root des entfernten Systems behandelt, als wäre er nobody. Damit bekommt ein Hacker von einem fremden Rechner keine Möglichkeit sich auszubreiten.
no_root_squash Hier hat der Nutzer "root" des fremden Systems dieselben Rechte wie der lokale root.
squash_uids und squash_gids Mit dieser Option können bestimmte UIDs und GIDs vom fremden System behandelt werden, als wären sie "nobodys" - was sich besonders bei Systemaccounts als nützlich erweist. Beispiel: squash_uids=0-499 Lässt alle Anfragen von Nutzern mit einer ID kleiner als 500 nur als "nobodys" zu.
all_squash Alle UIDs werden "gesquasht", d.h. dem Nutzer nobody angerechnet. Damit haben alle fremden Nutzer die geringsten Rechte.
map_daemon Damit werden UIDs und GIDs vom entfernten System dynamisch an die im lokalen System vorhandenen angepasst. Ein Nutzer "lars" auf dem entfernten System bekommt dann dieselben Rechte wie der lokale "lars" - auch wenn dieser eine andere Nutzer-ID hat. Allerdings muss dazu auf beiden Systemen der rpc.ugidd laufen.
map_static Hiermit wird ein statisches Mapping eingeführt. Dazu muss eine Datei mit den entsprechenden Zuweisungen vorhanden und als Parameter angegeben sein.
Ein Beispiel: map_static=/etc/nfs/foobar.map
Die Datei /etc/nfs/foobar.map könnte dann so aussehen:
# Mapping for client foobar: # remote local uid 0-99 - # squashen - also eigentlich keine Rechte uid 100-500 1000 # Mappe die UIDs von 100-500 nach 1000-1400 gid 0-49 - # Gruppen squashen gid 50-100 700 # Mappe Gruppen mit IDs von 50-100 nach 700-750
anonuid and anongid Hiermit werden die UIDs und GIDs für den Nutzer nobody und die entsprechende Gruppe festgelegt.
no_exec Das Dateibit für ausführbare Dateien wird im entfernten System nicht gestattet: aus diesem exportierten Verzeichnis heraus dürfen keine Programme aufgerufen werden.
no_suid Das setzen des "User-ID"-Bits wird nicht gestattet. Dateien können nur mit den Rechten des jeweils angemeldeten Benutzers ausgeführt werden.
no_sgid Das setzen des "Group-ID"-Bits wird nicht gestattet. Dateien können nur mit den Gruppen-Rechten des angemeldeten Benutzers ausgeführt werden.
NFS-Server einschalten
Das NFS-Protokoll aktivieren Sie als Benutzer sysadm über das Menü "Verwalten" -> "Dienste" und dort "NFS-Server" wählen und mit der Leertaste das (x) setzen. Vergessen Sie danach nicht das Aktivieren.
Beachten Sie noch: Damit nach einer Änderung der Datei /etc/exports diese Veränderung auch aktiv wird, muss der NFS-Dienst neu gestartet werden.
Das geht am einfachsten als root mit den Befehlen:
root@Arktur# /etc/init.d/nfsserver stop root@Arktur# /etc/init.d/nfsserver start
NFS-Clients einrichten
Wenn Sie Linux-Clients einbinden wollen, benutzen Sie am einfachsten den mitgelieferten Konfigurationsmanager wie YaST bei SuSE. Näheres dazu finden Sie im Installationshandbuch Client. Sie können den Client aber auch von Hand einrichten, wie es im folgenden beschrieben wird.
Damit ein Client ein freigegebenes Verzeichnis in sein Dateisystem einklinken kann, muss es in den Verzeichnisbaum des Clients eingebunden ("gemountet") werden. Dabei wird als Dateisystemtyp "nfs" angegeben. Statt der üblichen Device-Angabe wird der Servername bzw. die IP-Adresse angegeben und das Verzeichnis des Servers, das freigegeben ist. Außerdem ist natürlich der Mount-Punkt anzugeben, an dem das Verzeichnis eingebunden wird, z.B.
root@Client# mount -t nfs Arktur:/home /home
Damit wird das Homeverzeichnis von Arktur auf dem Client in das Verzeichnis /home auf dem Client eingebunden - das übliche Verfahren, wenn das Verzeichnis im Netzwerk verteilt werden soll. Statt dem Servernamen Arktur können Sie auch die IP-Adresse von Arktur (oder Capella) verwenden, also z.B. mount -t nfs 192.168.0.1:/home /home schreiben. Wenn /home einmal freigegeben ist, kann der Client auch Unterverzeichnisse davon einbinden, also z.B.
root@Client# mount -t nfs Arktur:/home/adm /opt/adm
Damit wird nur "/home/adm" vom Server eingeklinkt, allerdings an einem anderen Mount-Punkt auf dem Client, also hier nach "/opt/adm" . Wenn das Verzeichnis, welches als Mount-Punkt benutzt wird, nicht leer ist, wird alles andere einfach ausgeblendet - nur das eingeklinkte Verzeichnis ist "sichtbar".
Meist sollen die NFS-Verbindungen gleich beim Start des Clients eingebunden werden. Dazu trägt man diese Laufwerke in die Datei /etc/fstab ein:
/dev/hda1 / ext2 defaults 1 1 Arktur:/home /home nfs nodev,nolock 0 0 Arktur:/var/spool/mail /var/spool/mail nfs nodev,nolock 0 0 Arktur:/home/adm /Arkturpub nfs nodev,nolock 0 0 Arktur:/home/tmp /Arkturtmp nfs nodev,nolock 0 0 Arktur:/cdrom /media/cdrom nfs nodev,nolock 0 0
- Abbildung: Beispiel für die /etc/fstab auf dem Client
So können Sie also das Homeverzeichnis, das Mailverzeichnis, das Programmverzeichnis "/home/adm" und das Tauschverzeichnis "/home/tmp" vom Arktur-Schulserver allen Clients zur Verfügung stellen. Damit hat in einem Unix-/Linux-Netz jeder seine persönlichen Daten auch auf dem lokalen Client zur Verfügung. Damit startet zum Beispiel KDE so, als hätte man sich als lokalen Benutzer angemeldet. Alle dabei notwendigen privaten Einstellungen liegen aber auf dem Server. Und unter "/home/<Benutzer>" befindet sich in Wirklichkeit das Homeverzeichnis des Benutzers auf Arktur. Deswegen ist auch in "/home" auch der ganze Inhalt von "/home" auf Arktur zu sehen. In einer Schule sind dies hunderte von Verzeichnissen.
Aus Erfahrung empfehle ich Ihnen, "/home/adm" und "/home/tmp" auf eigene Verzeichnisse "/Arkturpub" und "/Arkturtmp" zu legen. Es macht auf die Dauer keinen Spass, diese beiden immer wieder durch langes Scrollen suchen zu müssen.
Natürlich können Sie mit den oben angegebenen Befehlen auch Arktur selbst als NFS-Client benutzen. Das ist besonders interessant, wenn Arktur nicht der einzige Linux-Server im Netzwerk ist. Auch die Einrichtung von NFS-Laufwerken in der "/etc/fstab" unterstützt Arktur.
Weitere Hinweise finden Sie im Installationshandbuch zur jeweiligen Distribution (also beispielsweise für SUSELinux).
