NFS - Network File System

ArticleCategory:

System Administration

AuthorImage:

TranslationInfo:

Original in fr Fr�d�ric Raynal

fr to en Philippe Trbich and Emmanuel Bonnel

en to de Katja Socher

AboutTheAuthor:

Fr�d�ric Raynal schreibt an seiner Diplomarbeit in Informatik �ber Bildert�towierung an der INRIA. Er liest gerade einen sehr guten Detektivroman, der auf Th. Roosevelt zu Beginn des letzten Jahrhunderts anspielt, als er Polizeipr�fekt war. Die Atmosph�re ist sehr dunkel. Es geht um die Untersuchung einer Gruppe von Personen, um einen Serienm�rder zu finden, der Kinder verletzt. Die Gruppe wird von neuen Technologien unterst�tzt (Psychologie, Fingerabdr�cke, etc...), um die L�sung zu finden. Der Roman von Caleb Carr, L'ange des t�n�bres, zeichnet ein �berraschendes Bild �ber den Beginn des letzten Jahrhunderts.

Abstract:

A Ein Network File System (NFS) erlaubt das Verwalten von Dateien auf mehreren Computern innerhalb eines Netzwerkes so, als ob sie auf der lokalen Festplatte gespeichert w�ren. Dadurch ist es nicht n�tig zu wissen, wo die Dateien physikalisch gespeichert sind, um auf sie zuzugreifen.

ArticleIllustration:

ArticleBody:

Einf�hrung

NFS erlaubt auf einfache Weise, Daten zwischen mehreren Computern zu teilen. Zum Beispiel mu� sich ein Benutzer, der in einem Netzwerk eingeloggt ist, nicht auch noch auf einem speziellen Computer einloggen: �ber NFS hat er Zugriff auf sein home directory (wir sagen exportiert) auf der Maschine, auf der er gerade arbeitet.

NFS ist kein sehr effizientes Protokol und deshalb sehr langsam �ber eine Modemverbindung. Es wurde f�r ein lokales Netzwerk entwickelt und ist sehr flexibel. Es bietet eine Menge M�glichkeiten f�r Benutzer und Administratoren.

Du mu�t diesen Dienst mit Vorsicht verwalten. Jedem zu erlauben, Daten in dein Netz zu schreiben, w�re keine gute Politik ;-) Einige essentielle Ma�nahmen reduzieren dieses Risiko.

Dieser Artikel beginnt mit einer sehr kurzen Einf�hrung zu Dateisystemen. Dann schauen wir uns das NFS Protokol an. Danach geht es zum weniger theoretischen Teil und wir f�hren eine NFS Server und eine Client Installation durch. Wir werden uns auch die minimalen Sicherheitsvorkehrungen anschauen, die man treffen sollte. Dann illustrieren wir an einem Beispiel, wie man NFS, NIS und autofs kombinieren kann.
 

Allgemeine und nicht-ersch�pfende Darstellung von Dateisystemen

Bevor wir �ber NFS reden, sollte man den Ausdruck Dateisystem verstehen. Ein Dateisystem ist ein Weg, um Daten auf einem Medium zu speichern, der Weg, wie es organisiert und verwaltet wird. Es gibt viele davon, einige sehr oft, andere weniger oft benutzt (New Technology FileSystem (NTFS), High Performance FileSystem (HPFS), DOS, FAT 12/16/32, VFAT, Macintosh Hierarchical Filesystem (HFS), ISO 9660 (f�r CD-ROM), extended file systems (Ext, Ext2, Ext3),und viele andere).

Zum Beispiel k�nnen wir jedes physikalische Medium f�r Daten (eine Festplatte z.B.) als Feld von kleinen Einheiten, die Informationen speichern, betrachten: wir reden �ber Bl�cke. Jedes Dateisystem verwaltet diese Bl�cke auf verschiedene Weise. Zum Beispiel versuchen wir in Abbildung 1 eine Datei einzuf�gen, die zwei Bl�cke benutzt. Auf der oberen Illustration wurde die Datei hinter den letzten besetzten Block gesetzt, wobei leere Stellen am Anfang auftreten. Im unteren Teil des Bildes (ein anderes Dateisystem) wurde es an die erste freie Stelle gesetzt. Diese Politik hat Einflu� darauf, wie stark eine Platte fragmentiert wird. Einige Dateisysteme vermeiden Fragmentierung automatisch, w�hrend andere von Hand defragmentiert werden m�ssen.
 
 


Fig. 1 : 2 different ways to place blocks





Das bekannteste Dateisystem unter Linux ist ext2fs (extended 2 file system). Jede Datei wird durch eine Inode1 dargestellt. Verzeichnisse speichern die Dateiliste und der Zugriff geschieht durch Operationen wie lesen/schreiben auf besondere Dateien.

Die Aufgabe des NFS Servers ist es, seinen Clienten die Inoden zu geben, auf die sie zugreifen m�chten. Allerdings w�rde ein Client nur allein mit den Dateiinoden nicht sehr gut arbeiten. Ein NFS Server gibt eine zus�tzliche Netzschicht, die es remote-Rechnern erlaubt, Inoden zu handhaben.

Das NFS Protokol

Was wir gew�hnlich NFS nennen, setzt sich aus 4 verschiedenen Protokollen zusammen. Jedes h�ngt von Remote Procedure Calls(RPC) und portmap (auch rpc.portmap genannt) ab. Ein portmapper wandelt RPC Programmnummern in Portnummern um. Wenn ein RPC Server startet, erz�hlt er portmap , welchen Port er benutzen wird und die verwaltete RPC Programmnummer. Wenn ein Client eine RPC Abfrage an eine gegebene Programmnummer senden m�chte, kontaktiert er zuerst den Server portmap, um die Portnummer zu bekommen, die ihm Zugang zu dem gew�nschten Programm gibt. Dann adressiert er die RPC Pakete an den korrespondierenden Port.

Die 4 Dienste, die es NFS erlauben zu arbeiten, sind:
 
Protokol
Beschreibung
Daemon
nfs Dieses Protokol ist die Basis und erlaubt das Erzeugen von Dateien, Suche, Lesen oder Schreiben. Dieses Protokol verwaltet auch die Autentifizierung und die Dateistatistiken.
nfsd
mountd Dieser ist verantwortlich f�r das Mounten exportierter Systeme, um auf sie mit nfs zugreifen zu k�nnen. nfs.Der Server empf�ngt Anfragen wie mount und umount und mu� auf diese Weise Informationen �ber exportierte Dateisysteme behalten.
mountd
nsm
(Network Status Monitor) 		 Es wird benutzt, um Netzwerknodes zu �berwachen, um den Zustand einer Maschine (Client oder Server) zu kennen. Es informiert, z.B. �ber einen Neustart.
statd
nlm
(Network Lock Manager) 		 Um Daten�nderungen durch mehrere Clienten zur gleichen Zeit zu vermeiden, verwaltet dieses Protokol ein Locksystem. Es wei�, welche Dateien benutzt werden. Auf diese Weise ist es mit Hilfe des Nsm Protokols m�glich zu wissen, wenn ein Client erneut startet. Nsm befreit alle Locks des Clienten, bevor sie zur�ckgegeben werden.
lockd

Der Daemon knfsd, verf�gbar mit den neuesten Kernelversionen, unterst�tzt direkt die nfs und nlm Protokolle. Andererseits werden mountd und nsm noch nicht unterst�tzt. Wenn der NFS Server installiert und gestartet wird, k�nnen wir mit dem folgenden Befehl verifizieren, da� alles l�uft:
 

>> ps auxwww | egrep "nfs|mount|lock|stat"
root      1370  0.0  0.2  1176  580 ?        S    22:28   0:00 rpc.mountd --no-nfs-version 3
root      1379  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1380  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1381  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1382  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1383  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1384  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1385  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1386  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [nfsd]
root      1399  0.0  0.0     0    0 pts/0    SW   22:28   0:00 [lockd]
root      1409  0.0  0.2  1156  560 ?        S    22:28   0:00 rpc.statd
root      1652  0.0  0.1  1228  484 pts/3    S    22:49   0:00 egrep nfs|mount|lock|stat
Momentan sind 2 NFS Versionen verf�gbar (Versionen 2 und 3 - sie werden NFSv2 bzw. NFSv3 genannt, um sie zu unterscheiden). Linux's NFS Server unterst�tzen nur Version 2 (daher die Option auf der mountd Zeile im vorhergehenden Beispiel).

Bei NFS geht es um eine Datenstruktur, die file handle genannt wird. Es ist eine Bitserie, die auf eindeutige Weise erlaubt, jedes Dateisystemobjekt (wie eine Datei, aber nicht nur Dateien) zu identifizieren. Es enth�lt z.B. die Dateiinode, aber auch einen Eintrag, der das Ger�t, wo die Datei sich befindet, enth�lt. Daher k�nnen wir NFS als ein Dateisystem betrachten, das in ein Dateisystem eingebettet ist.

Installation

Der Server

Das erste, was wir tun m�ssen, wie wir bereits gesehen haben, ist portmap zu starten, da dieses Protokol von NFS gebraucht wird.
root >>/usr/sbin/rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused
root >>/sbin/portmap
root >>/usr/sbin/rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
Der rpcinfo Befehl zeigt die auf der Maschine laufenden RPC Dienste, spezifiziert als das Argument (-p option). Wir bemerken, da� portmap noch nicht l�uft: wir starten es (die meisten Linuxdistributionen enthalten Skripte, um dies beim Starten zu automatisieren) und wir �berpr�fen, ob es l�uft. Ein anderer oft vorkommender Grund f�r eine negative Antwort auf rpcinfo ist, da� der portmapper nicht antworten darf aufgrund von Sicherheitsrestriktionen in den /etc/hosts.{allow, deny} Verzeichnissen. In diesem Fall f�ge einen "portmap: hosts" Eintrag zu der hosts.allow Datei hinzu.

Vor dem Starten von NFS selbst, mu� es konfiguriert werden. Es gibt nur eine Konfigurationsdatei und sie hei�t /etc/exports. Jede Zeile zeigt einen Verzeichnisbaum der exportiert werde soll gefolgt von einer Liste von Clienten, die auf ihn zugreifen d�rfen. Es ist m�glich, am Ende jedes Clientennamens Optionen hinzuzuf�gen. Die man exports page erkl�rt die Syntax f�r Clientennamen und Optionen.

Die akzeptierten Formen f�r Clientennamen sind:

Wir werden hier nicht detailliert alle verf�gbaren mount Optionen beschreiben, aber hier sind die wichtigesten: Wir m�ssen jetzt rpc.mountd und rpc.nfs daemons starten, um einen laufenden NFS Server zu bekommen. Wir �berpr�fen nochmal mit dem rpcinfo Befehl, da� alles l�uft. Wir k�nnen den Server sogar f�r die nsm und nlm Protokolle initalisieren ( rpc.statd bzw. rpc.lockd). Sie sind aber nicht unbedingt notwendig, um einen NFS Server laufen zu lassen... aber stark empfohlen im Fall, da� eine Maschine ausf�llt, von selbst rebootet, etc...

Wenn wir die /etc/exports Konfigurationsdatei �ndern, m�ssen wir die betroffenen Daemons informieren, da� �nderungen gemacht wurden. Der exportfs Befehl �bermittelt diese Information an unsere Server. Die -r Option synchronisiert die /etc/mtab2 Datei mit der /etc/exports Datei. Die -v Option zeigt die exportierten Dateisysteme zusammen mit ihren Optionen.

Nach dem Start enthalten die folgenden Dateien wichtige Informationen:

Wenn ein Client auf ein Dateisystem zugreifen m�chte, f�ngt er damit an, mountd zu fragen. Er sucht dann in etab, ob die Abfrage verf�gbar ist. Er �berpr�ft den Kernel, um zu wissen, ob der Client zu dieser Abfrage berechtigt ist (check hosts.{allow, deny}, firewall rules, ...). Der Kernel benutzt exportfs f�r die �berpr�fung, er ist berechtigt die /var/lib/nfs/etab Datei upzudaten. Wenn in dieser Datei das exportierte System berechtigt ist, zu der Gruppe, zu der der Client geh�rt, exportiert zu werden, dann informiert mountd den Kernel, der daraufhin xtab mit dem neuen host updatet.

Der Client

Hier gibt es nichts zu tun ... normalerweise. Der Zugriff auf ein Dateisystem, das von NFS exportiert wurde, wird direkt vom Kernel verwaltet. Es mu� mit Unterst�tzung f�r NFS kompiliert worden sein. Die Datei /proc/filesystems listet alle Dateisysteme auf, die direkt vom Kernel unterst�tzt werden. Man mu� dann nur dem Kernel sagen, da� man Zugriff auf ein von NFS exportiertes System haben m�chte.

Der mount Befehl berechtigt zum Zugriff auf verschiedene Dateisysteme. Es informiert den Kernel, da� ein neues Dateisystem verf�gbar ist, mit Angabe seines Typs, des device und seinem Mountpunkt. Die -t  Option kann dazu benutzt werden, um den Typ des benutzten Dateisystems zu spezifizieren. F�r NFS schreiben wir: -t nfs.

mount hat seine eigenen Optionen f�r NFS. Zum Beispiel k�nnen die Optionen rsize und wsize dazu benutzt werden, um die Blockgr��en f�r Lesen und Schreiben zu �ndern. Man kann NFS spezifische Optionen mit allgemeineren Optionen wie intr, noexec oder nosuid verbinden. Die mount man page listet alle diese Optionen auf.

La�t uns annehmen, der Rechner charly hat einen NFS Server und exportiert sein /usr/local Verzeichnis. Wenn man darauf vom Rechner jill aus zugreifen will, dann mu� man nur das exportierte Vrzeichnis von charly zu jill mounten:

root@jill >> mount -t nfs -o nosuid,hard,intr charly:/usr/local /usr/local
Der Befehl zeigt an, da� wir ein NFS Dateisystem mounten (-t nfs), mit den nosuid, hard und intr Optionen. Die beiden letzten Argumente sind die interessantesten. Das erste spezifiziert das zu mountende device. F�r NFS ist die Syntax anders als in der gew�hnlichen mount Befehlszeile, wo man den device und das Verzeichnis spezifiziert. Hier spezifizieren wir server:exported_directory anstelle von einem device. Das letzte Argument zeigt die Stelle des Dateisystems auf der Clientenseite an. Wir teilen einfach charlys /usr/local mit jill und k�nnen dadurch vermeiden, Programme mehr als einmal in /usr/local zu installieren. Um dies permanent zu machen, k�nnen wir es auf jill in der /etc/fstab Datei spezifizieren. fstab enth�lt alle devises, die beim Start gemounted werden m�ssen. Die Syntax f�r /etc/fstab lautet:
 
#    device           mount point   file system   options     dump  fsckorder
charly:/usr/local    /usr/local       nfs       nosuid,hard,intr    0      0

Sei jedoch mit permanenten Eintr�gen vorsichtig. Man kann es nur benutzen, wenn der Server (charly) immer an ist oder vor jill eingeschaltet wird.

Vorsicht

Ein gro�es Problem mit NFS r�hrt aus der Tatsache, da� per default ein vertrauensvolles Verh�ltnis zwischen Client und NFS Server besteht. In dem Fall, da� der root account des Servers kompromittiert wird, wird auch der des Clienten kompromittiert. Das NFS-HOWTO beschreibt einige essentielle Ma�nahmen, die aus Sicherheitsgr�nden ergriffen werden m�ssen.

Ein Client darf nicht blind einem Server trauen und umgekehrt, deshalb m�ssen wir einschr�nkende Optionen spezifizieren, wenn wir den mount Befehl benutzen. Wir haben die erste schon erw�hnt: nosuid. Es macht den SUID und SGID bits Effekt r�ckg�ngig. Das hei�t, eine als root eingeloggte Person auf dem Server mu� sich zuerst als Benutzer auf dem Clienten einloggen und wird erst dann root. Eine andere, restriktivere Option ist noexec. Es verbietet das Ausf�hren von Programmen auf exportierten Dateisystemen. Diese Option ist nur auf Systemen nutzbar, die nur Daten enthalten.

Auf der NFS Serverseite k�nnen wir ebenso spezifizieren, da� wir dem root account des Clienten nicht trauen. Wir m�ssen dies in /etc/exports mit der root_squash Option spezifizieren. Dann, wenn ein Benutzer mit UID 0 (root) auf dem Clienten auf das Dateisystem, das vom Server exportiert wurde, zugreift, wird er der nobody UID f�r Abfragedateien. Diese Option ist per default unter Linux aktiv, kann aber mit der no_root_squash Option abgeschaltet werden. Eine Menge von UIDs kann spezifiziert werden, auf die diese Option angewendet werden soll. Erinnere dich auch, da� die anonuid und anongid Optionen es erlauben, die Benutzer UID/GID von nobody zu einer anderen ID zu �ndern.

Einige Aktionen sind allgemeiner und haben Auswirkungen auf den portmapper. Zum Beispiel verbieten wir den Zugriff zu allen Rechnern mit der folgenden Zeile in der /etc/hosts.deny Datei:

# hosts.deny :
#              use the portmap
portmap: ALL


Die /etc/hosts.allow Datei stellt das Gegengewicht zu diesem strikten Verbot dar und erlaubt den Zugriff auf die gew�nschten Maschinen.

Gute Firewallregel tragen auch zu einem besseren Schutz bei. Beobachte die Ports, die von verschiedenen Diensten genutzt werden und die genutzten Protokolle:
 

Service RPC Port Protocols
portmap 111 upd / tcp
nfsd 2049 udp
mountd variable udp / tcp

Benutzen von NIS, NFS und autofs

Jetzt betrachten wir ein kompliziertes Netzwerk wie man es z.B. in einem Unternehmen findet. In einem kleinen Netzwerk zu Hause wirst du wahrscheinlich in der Lage sein, ohne NIS zu leben. NIS Network Information Service ist ein Weg, um Konfigurationsdateien (z.B. in /etc) auf andere Maschinen zu veteilen.
Der Hauptserver in unserem Netzwerk ist "charly" und 3 andere Maschinen des Netzwerkes sind "sabrina", "jill" und "kelly". Wir konfigurieren charly als NIS Server f�r die Domain bosley. Die anderen Maschinen sind nur NIS Clienten von charly (wir sollten einen NIS Slave Server haben, aber dies ist heute nicht unser Thema).

La� uns zuerst die Konfiguration unseres Servers charly anschauen. Wir beginnen mit dem Definieren einiger NIS maps, die alle notwendigen Informationen enthalten.

Die /etc/netgroup Datei enth�lt Maschinengruppen mit gemeinsamen Charakteristiken (z.B. dieselbe Architektur). Eine NIS map ist f�r NFS sehr n�tzlich. Wir m�ssen nur alle Maschinen sammeln, die berechtigt sind, auf dasselbe exportierte Dateisystem zuzugreifen. Diese Gruppe wird dann in der /etc/exports Datei benutzt, anstatt alle Clienten einzeln zu spezifizieren:

# /etc/netgroup
charlysangels (sabrina,,) (jill,,) (kelly)
 Soweit wie es NFS betrifft, wissen wir, da� die Konfiguration sehr eingeschr�nkt ist. Die /etc/exports Datei von charly enth�lt:
# /etc/exports
/usr/local    @charlysangels(ro)
Wir entscheiden uns automount zu benutzen, um auf das exportierte /usr/local Verzeichnis zuzugreifen. Anstatt dieses System zur Boot-Zeit zu mounten, geschieht es automatisch, wenn ein Benutzer auf eine Datei in diesem Verzeichnis zugreift.  Wir erzeugen die /etc/auto.map Datei, um zu definieren, was zugreifbar sein wird, sowohl durch automount als auch durch NIS:
# /etc/auto.map
charly          charly:/usr/local
Da wir diese Informationen (die neuen auto.map und netgroup Dateien) in die NIS Datenbank integrieren wollen, m�ssen wir das Makefile �ndern, bevor wir es erneut bauen. Wir m�ssen sicher sein, da� netgroup in die Datenbank hinzugef�gt wird. Was auto.map betrifft, so wird diese Datei nicht per default definiert. Wir m�ssen nur einfach einen neuen Eintrag in das Makefile hinzuf�gen, mit der assoziierten Regel (benutzen der existierenden als ein Modell):
#To be added in the Yellow Pages Makefile
AUTO_MAP    = $(YPSRCDIR)/auto.map
# ...
#...
auto.map: $(AUTO_MAP) $(YPDIR)/Makefile
            @echo "Updating $@..."
            -@sed -e "/^#/d" -e s/#.*$$// $(AUTO_MAP) | $(DBLOAD) \
            -i $(AUTO_MAP) -o $(YPMAPDIR)/$@ - $@
            -@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@
Diese Produktionsregel entfernt nur Kommentare, f�gt einen neuen Eintrag in die Datenbank hinzu und �bermittelt dann die Information zu jedem Server.

Wir m�ssen nur make aus dem /var/yp Verzeichnis laufen lassen.

Jetzt zu unseren drei Clienten sabrina, jill und kelly. Here, Hier gibt es nichts zu tun :) Wir m�ssen autofs sagen, da� es eine neue map, die von YP gegeben wird, verwalten soll. In jeder /etc/auto.master Datei des Clienten informiert die folgende Zeile �ber die Anwesenheit von einem map auto.map , erhalten durch die YP Dienste.

#/etc/auto.master
/usr/local    yp auto.map    --intr,nosuid,nodev
Dann m�ssen wir autofs erneut starten, damit die neue map wirksam wird.

Jetzt haben wir ein einziges /usr/local physikalisches Verzeichnis auf charly. Dann, wenn spezifische Programme auf charly installiert werden, k�nnen alle Maschinen sie nutzen.

Dieses Beispiel k�nnte weitergehen mit der Installation nur eines /usr Systems, /usr/doc oder anderem, aber die Praxis zeigt, da� dies keine gute Idee ist. Installationen m�ssen oft Dateien im /etc Verzeichnis oder anderes ver�ndern. Wir m��ten dann alle Maschinen �ndern, um nicht exportierte Dateien upzudaten und das wird schnell langweilig.
 

Referenzen

Dateisysteme


NFS


Fu�noten

... inode1
Es ist ein File-descriptor (eine Anreihung von Bits), der u.a. Dateizugriffsberechtigungen, Eigent�mer, physikalische Blockadressen, die Daten speichern, etc... enth�lt
... /etc/mtab2
Diese Datei enth�lt eine Liste aller Dateisysteme, die vom Kernel gemountet werden, ob hart (via mount, wie die Eintr�ge in fstab) oder �ber den Automounter (autofs/automount).