Administratorhandbuch:NFS
|
Nach Meinung des Autors ist diese Seite fertig. Es wäre schön, wenn ausgiebige Tests durch viele Nutzer eventuell noch vorhandene Fehler beseitigen helfen. |
| 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. |
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 Dateiü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.
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 Anwort 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(ro)
- 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äßt. 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äßt 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 muß 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 über das Menü "Verwalten" -> "Netzdienste" und dort "NFS-Server EINschalten".
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
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. 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 /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:/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 und das Mailverzeichnis vom Arktur-Schulserver allen Clients zur Verfügung stellen. Damit hat in einem Unix-/Linux-Netz jeder seine persönlichen Daten auf dem lokalen Client. 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 Installationshandbuch:SuSELinux oder Installationshandbuch:DebianLinux).
PCNFS
Ein Problem in Unix-Netzen ist generell die Authentifizierung: In klassischen Unix-Netzen ist der Client dafür zuständig. Auf Rechnern mit DOS oder Windows kann diese Authentifizierung nicht vom Client vorgenommen werden. Deshalb wurde eine veränderte Variante mit der Bezeichnung "PCNFS" entwickelt. Beim Arktur-Schulserver können Sie auch dieses Protokoll freigeben. Nutzen können Sie es mit der Shareware XNFS oder den Werkzeugen aus dem LAN-Workgroup-Paket von Novell (Groupwise-Funktionen).
Achtung: Schalten Sie PCNFS nur ein, wenn Sie es wirklich benötigen! Für Clients mit Linux wird es nicht benötigt.