Sie sind auf Seite 1von 20

NFS = Network File System RPC = Remote Procedure Call

------------------------- ---------------------------

Inhalt:
- Ueberblick - NFS
- Unterschied Produkt und Protokoll
- Gegenueberstellung OSI - NFS
- NFS-relevante RFC-Standards
- 1.Teil RPC
- 2.Teil Portmapper
Zweck des Portmappers
Arbeitsweise des Portmappers
- 3.Teil NFS ## NFS-Protokoll ##
- 3.Teil NFS ## Mount-Protokoll ##
Ablauf eines Mountvorgangs
Mount-Optionen
Hard- und Softmount
/etc/export
- 3.Teil NFS ## LOCK-Mechanismuss (lockd + statd) ##
Ablauf eines Lockvorgangs
lockd + statd nach einem Systemabsturz
- 3.Teil NFS ## NFS-Daemons ##
Funktionen der einzelnen Daemonen (nfsd/biod/mountd/lockd/statd)
- 4.Teil NFS in der Praxis
- 5.Teil NFS und Firewall
- 6.Teil NFS AIX + Linux
- 7.Teil Trace eines Mount/UMOUNT

Ueberblick - NFS:
-----------------
- von SUN Mircosystem entwickelt
- SUN hat von Anfang an die Spezifikation der NFS-Protokolle veroeffent-
licht und fuer geringe Lizenzgebuehren abgegeben
- NFS erlaubt Programme, auf Dateien in NFS-Serverrechnern schreibend
und lesend zuzugreifen; der Zugriff erfolgt transparent durch ein-
haengen (Unix-Jargon=mount) in das Dateisystem
- die Bereitstellung der Zugriffsmoeglichkeit des gemounteten Datei-
systems muss vor dem Zeitpunkt des Zugriffs erfolgen
- urspruengliches Entwicklungsziel von NFS war es, etwa 80% des Daten-
durchsatzes einer lokalen Festplatte zu erreichen - fuer Diskless-
Workstations
- Unix-Systeme koennen Client und Server gleichzeitig sein
- es gibt diverse NFS-Implementierungen fuer andere OS-Systeme
- de-facto Standard unter den Unix-Systemen um auf entfernte Systeme
zuzugreifen

Unterschied Produkt und Protokoll:


----------------------------------
Bei der Beschaeftigung mit NFS muss man zwischen dem Produkt NFS und dem
NFS-Protokoll unterscheiden:
- Das Produkt NFS besteht aus einer Reihe von Protokollen (NFS/RPC/XDR/
Portmapper/Mount/Yellow-Pages), die die unterschiedlichsten Funktionen
beinhalten. Neben dem Zugriff auf Dateien sind im Netzwerk auch andere
Aufgaben (z.B. im Bereich der Verwaltung) zu erledigen. Fuer jede
dieser Aufgaben definiert NFS in der Regel ein eigenes Protokoll.
- Eines der Protokolle im NFS-Produkt ist das gleichnamige NFS-Protokoll,
das zum Zugriff auf Dateien verwendet wird und dem Produkt NFS seinen
Namen gegeben hat.

Fuer die Pruefung der Kompatibilitaet zwischen einzelnen Implementier-


ungen gibt es folgende Kriterien:
- Die im NFS-Produkt verwendeten Protokolle tragen Versionsnummern -
nur Implementierungen mit gleicher Protokollversion sind kompatibel;
hoeherwertige sind gewoehnlich abwaertskompatibel.
- Der Funktionsumfang des NFS-Produkts auf einem UNIX-Rechner ist nicht
spezifiziert: welche Protokolle, Programme und Kommandos zum Einsatz
kommen, ist von Hersteller zu Hersteller verschieden. In der Regel
orientieren sich die Hersteller aber an der jeweils neuesten NFS-
Version auf der Sun Workstation.

Gegenueberstellung von OSI und zu NFS-Daemons:


----------------------------------------------

--------------------------------------------------------------------

OSI-Schicht-7 Anwendung ----> nfsd + mountd + biod + Portmapper


----> lockd + statd (alles Daemonen!)
--------------------------------------------------------------------

OSI-Schicht-6 Darstellung ----> XDR


--------------------------------------------------------------------

OSI-Schicht-5 Kommunikation ----> RPC


--------------------------------------------------------------------

OSI-Schicht-4 Transport ----> TCP/UDP


--------------------------------------------------------------------

OSI-Schicht-3 Vermittlung ----> IP


--------------------------------------------------------------------

OSI-Schicht-2 Sicherung ----> Ethernet/TR ....


--------------------------------------------------------------------

OSI-Schicht-1 Bituebertr. ----> Ethernet/TR ....


--------------------------------------------------------------------

NFS-relevante RFC-Standards:
----------------------------
- Application ==> NFS+Mount+YP+YPBIND+REX+NLM ---> RFC 1094
==> dto. NFS-Version 3 --------------> RFC 1813
==> dto. NFS-Version 4 --------------> RFC 3010
- Presentation ==> XDR ----------------------------> RFC 1014
- Session ==> RPC ----------------------------> RFC 1050

XDR muss durch den Hersteller bei der Implementierung des NFS-Prgramm-
Packetes beruecksichtigt werden und soll in dieser Dokumentation nur
belaeufig erwaehnt werden. Daher erfolgt hier nur eine kurze Beschrei-
bung von XDR bevor die NFS-Dienste und RPC-Programme erlaeutert werden:

XDR = External Data Representation (OSI-6):


-------------------------------------------
Ziel der offenen Datenkommunikation ist es, Daten zwischen Rechnern
und Betriebssystemen auch unterschiedlicher Herkunft und Praegung auszu-
tauschen. Damit ein Rechner die von einem anderen Rechner gesendeten
Daten verstehen kann, muss deren DARSTELLUNG entweder gleich oder in
einem zwischen beiden Rechnern vereinbarten Format gehalten sein - anders
waere es dem Empfaenger nicht moeglich, die Daten in ein eigenes internes
Format umzuwandeln.
Ohne naeher auf Details einzugehen sind folgende Punkte genannt:
- unterschiedliche Kodierungen fuer Text und komplexe Datenobjekte
- ASCII vs. EBCDIC
- niederwertiges Bit (little-endian) vs. hoeherwertiges Bit (big-endian)
- Gleitkommazahlen-Format

-------------------------------------------------------------------------
NFS und die dazugehoerigen Daemonen bauen alle auf das RPC-Protokoll auf.
Daher laesst sich NFS nur richtig verstehen, wenn man auch die Funktions-
weise des RPC-Protokolls verstanden hat.
Im 1.Teil wird RPC erklaert
Im 2.Teil wird der PORTMAPPER erklaert
Im 3.Teil wird NFS, deren PROTOKOLLE und DAEMONEN erklaert
Der 4.Teil widmet sich der Praxis von NFS

Der praktische Teil ist AIX-bezogen, sollte jedoch aehnlich bei anderen
Unix-Sytemen funktionieren.
-------------------------------------------------------------------------

## 1.Teil RPC

Ein Remote Procedure Call ist ein PROTOKOLL der Kommunikationssteuerungs-


schicht (OSI-Layer-5). RPC WURDE EIGENS FUER NSF ENTWICKELT, wird aber
auch in vielen vernetzten Applikationen verwendet.
RPC bildet die Basis fuer den Austausch von Nachrichten in allen NFS-
Applikationen!!! DAS RPC-PROTOKOLL IST SOZUSAGEN DAS FAHRGESTELL FUER
DEN TRANSPORT VON AUFTRAEGEN ZUM RPC-SERVER.
Mit Hilfe von RPC koennen Netzwerkdienste entworfen und abgewickelt
werden, die sich, wie der Name bereits andeutet, aehnlich wie normale
Subroutingen-Aufrufe oder Prozeduren in hoeheren Programmiersprachen
verwenden lassen. Diese Arbeitsweise entlastet den Programmierer beim
Entwurf und der Implementierung von verteilten Programmen.
Im Protokollkopf eines RPC-Packetes befinden sich: (nur wichtige genannt)
- Transaktions-ID (muss eindeutig und einmalig sein)
- Senderichtung
0=Senden zum Server / 1=Antwort vom Server
- Berechtigungsnachweis
Client muss sich gegenueber Server ausweisen, damit wird den Servern
ermoeglicht nur Dienste den berechtigten Clients zugaenglich zu machen
- Berechtigungsnachweis-Verifizierung
mit dieser Information koennen Clients feststellen, ob die zurueckge-
sendete Antwort tatsaechlich authentisch vom gewuenschten Server ist
- Programmnummer

Details zur Programmnummer:


---------------------------
Im RPC-Protokoll wird mit der Angabe der Programmnummer das entsprechende
Zielprogramm angegeben. Mehrere Programmnummern wurden in Bereiche einge-
teilt, wobei SUN fuer sich den ersten Programmnummern-Bereich beansprucht.

Tabelle zur Festlegung der RPC-Programmnummer:


Beginn Ende Verwendung
00 00 00 00 1F FF FF FF
SUN --->---------->--------->--------+
20 00 00 00 3F FF FF FF
frei |
40 00 00 00 5F FF FF FF
transiente Programme |
60 00 00 00 7F FF FF FF
reserviert |
80 00 00 00 9F FF FF FF
reserviert |
A0 00 00 00 BF FF FF FF
reserviert |
C0 00 00 00 DF FF FF FF
reserviert |
E0 00 00 00 FF FF FF FF
reserviert |
|
Auflistung der Programmnummern im Programmnummernbereich von SUN, <---+
(zu finden in /etc/rpc) hier sind nur einige aufgefuehrt:
Progr.-Bezeichnung Progr.-Nummer Alias
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
sprayd 100012 spray
nlockmgr 100021
autofs 100099 automount #209812

Welches Protokoll (TCP oder UDP) fuer welche Anwendung?


-------------------------------------------------------
Das RPC-Protokoll kann sowohl ueber TCP als auch ueber UDP betrieben
werden. Manche Server bieten beide Protokolle an und ueberlassen es
dem Client.
In der Regel wird RPC zusammen mit UDP verwendet, da die meisten Appli-
kationen transaktionsorientiert sind. Bei Verwendung von UDP ist die max.
Groesse des Datenteils eines RPC-Pakets beschraenkt, da UDP-Pakete aus
praktischen Gruenden nicht beliebig gross sein koennen. Fuer TCP gibt es
keine theoretische Obergrenze: wenn groessere Datenmengen verschickt
werden muessen, sollte man deshalb diesem Protokoll den Vorzug geben!
Normalerweise geht man davon aus, dass Datenmengen bis zu 8 KByte via UDP
versendet werden koennen. Bei der Verwendung von TCP werden RPC-Nach-
richten in Bloecke mit einem 4 Byte grossen Laengenfeld verpackt:
auf diese Weise koennten theoretisch mehrere Milliarden Bytes in einem
einzigen (TCP-)RPC-Aufruf bewegt werden.
Da bei Verwendung von UDP die Zustellung einer Nachricht auf der Trans-
portschicht nicht garantiert ist, muss hier die RPC-Schicht die Sicherung
uebernehmen. Spezielle Techniken sind implementiert worden, aber die
Sicherstellung der korrekten Uebertragung kann auch hier nicht 100%ig
gewaehrleitstet werden!!!
UDP liefert ueber die Leistungen von IP hinaus lediglich eine Portnummer
und ein Pruefsumme (Parameter *udpchecksum* im AIX mit dem Command:
nfso -l) der Daten. Im Gegensatz zu TCP gibt es hier keine Transportquit-
tungen oder andere Sicherheitsmassnahmen - allerdings macht das Fehlen
dieser Zusaetze UDP besonders effizient und daher geeignet fuer Hochge-
schwindigkeitsanwendungen wie z.B. verteilte Dateisysteme (NFS) oder der-
gleichen, die ohnehin nur auf schnellen und sicheren Uebertragungsmedien
wie z.B. in Local Area Networks (LANs) sinnvoll eingesetzt werden.
----
Bei Verwendung von TCP werden keine Wiederholungen auf der RPC-Ebene ge-
startet, da das TCP-Protokoll selbst die Nachricht so oft wiederholt, bis
sie beim Server eingetroffen ist. Anders gesagt: der Server enthaelt die
Nachricht entweder nur einmal oder ueberhaupt nicht. Ist die Zustellung
einer Nachricht erfolglos, wird die RPC-Schicht davon verstaendigt und
kann das Applikationsprogramm davon in Kenntnis setzen. Dasselbe gilt
auch fuer die RPC-Antwortnachricht vom Server.
DA DIE DATENUEBERTRAGUNG MITTELS TCP SICHER IST, laesst sich bei Bedarf
eine weitere Arbeitsweise verwenden: das Batching....

## 2.Teil PORTMAPPER

Zweck des Portmappers (RPC-Bind) (OSI-7)


----------------------------------------
Fuer eine Verbindung zwischen Client- und Serverprozessen initiiert der
Client ein Auruf an den Server mit einer bestimmten Portnummer, die dem
Client bekannt sein muss (Socket-Aufbau).
Wuerde man das Prinzip der definierten Portnummer auch bei RPC-Programmen
verwenden - von denen in Zukunft mit fortschreitender Vernetzung der
Rechner Tausende existieren koennen - wuerden bald Probleme mit der
Vergabe freier Portnummern auftreten. FUER DAS RPC-PROTOKOLL HAT MAN
DESHALB DEN PORTMAPPER GESCHAFFEN, DER EINE DYNAMISCHE ZUORDNUNG VON
IP-PORTNUMMERN UND RPC-PROGRAMMEN VORNIMMT. HINTER EINEM RPC-PROGRAMM
VERBIRGT SICH EIN DIENST/DAEMON (z.B. NFSD, MOUNTD etc.)

Arbeitsweise des Portmappers:


-----------------------------
Der Portmapper-Server arbeitet wie ein Verzeichnis-Dienst, der im wesent-
lichen eine Zuordnungstabelle zwischen RPC-Programm- bzw. Versionsnummern
und den lokalen UDP- oder TCP-Portnummern fuehrt, ueber die ein Dienst
(sprich: Server z.B. nfsd) zur Verfuegung steht. Der Portmapper selbst
belegt sowohl in TCP als auch in UDP die Portnummer Well-Known Portnummer
111 (SUNRPC in /etc/services).

Jedes RPC-Programm, hinter dem letztendlich ein Service/Dienst steht


(z.B. RPC-Programm-Nummer: 100005 => Service/Dienst: mountd) laesst
sich beim Programmstart eine, vom Betriebs-System vergebene, freie
Portnummer geben und hinterlegt diese zusammen mit den Parametern des von
ihm angebotenen Dienstes beim Portmapper. Daher sind die Zuordnung zwi-
schen RPC-Programmen und Portnummern auf jedem System unterschiedlich!
Welches RPC-Programm mit welcher IP-Portnummer vom Portmapper verwaltet
und an den RPC-Clients weitergereicht wird laesst sich mit dem Kommando
*rpcinfo -p* abfragen (Auszug):

program vers proto port service


100000 4 tcp 111 portmapper #Port fest definiert in /etc/services
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs #Port fest definiert in /etc/services
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
200006 1 udp 2049
200006 1 tcp 2049
100005 1 udp 32779 mountd #Port variabel
100005 2 udp 32779 mountd
100005 3 udp 32779 mountd
100005 1 tcp 32771 mountd
100005 2 tcp 32771 mountd
100005 3 tcp 32771 mountd
100024 1 udp 850 status #Port variabel
100024 1 tcp 850 status
100021 1 udp 32792 nlockmgr #Port variabel
100021 2 udp 32792 nlockmgr
100021 3 udp 32792 nlockmgr
100021 4 udp 32792 nlockmgr
100021 1 tcp 32772 nlockmgr
100021 2 tcp 32772 nlockmgr
100021 3 tcp 32772 nlockmgr
100021 4 tcp 32772 nlockmgr

RPC-Kommunikation zwischen RPC-Client und RPC-Server:


-----------------------------------------------------
Will ein RPC-Client einen RPC-Server ansprechen, sendet er zunaechst eine
Anfrage an den Portmapper (Daemon: /usr/sbin/portmap) des RPC-Servers mit
Angabe von Programmnummer + Versionsnummer + Protokolltyp (tcp oder udp)
Der Client bekommt die IP-Portnummer des Dienstes zurueckgeliefert und
sendet mittels IP-Socket-Verbindung Auftraege direkt an den Server.
Da der Client die Portnummer abspeichert, sind Wiederholungen der Port-
mapper-Abfrage fuer weitere RPC-Auftraege nicht noetig solange kein
Reboot der Client-Maschine erfolgt.
Diese dynamische Zuordnung hat neben vielen Vorteilen aber auch den
Nachteil, dass bei Ausfall des Portmappers (usr/sbin/portmap) kein RPC-
Dienst mehr erreichbar ist.

Zusammenfassung Portmapper:
---------------------------
Will ein RPC-Client mit einem bestimmten Programm eines RPC-Servers
kommunizieren so sendet der Client eine einmalige Anfrage an den Port-
mapper (Port 111 UDP/TCP) des Servers. Von dem Portmapper erhaelt der
Client eine IP-Portnummer des angeforderten RPC-Programms (Dienst/Service)
mitgeteilt. Diese speichert der Client bis zum naechsten Reboot im RAM.
Die weitere Kommunikation (Socket-Verbindung) fuehrt der Client mit dem
Server ohne Portmapper selbststaendig aus.
Eine RPC-Verbindung kann ohne Portmapper nicht stattfinden!

-------------------------------------------------------------------------

## 3.Teil NFS ## NFS-Protokoll ##

Das NFS-Protokoll besteht aus einer Anzahl von Prozeduren, die z. B.


lesend und schreibend auf entfernte Dateisysteme zugreifen koennen.

Die Designer von NFS waren daran interessiert, einen sehr robusten Datei-
zugriffsdienst zu entwerfen, der vor allem das leidige Problem des Wieder-
anlaufs nach einem Absturz des Server- oder Client-Rechners beseitigt.
Die Loesung war ein zustandsloses Protokoll, bei dem der Server keine
Informationen ueber den augenblicklichen Zustand oder Fortschritt des
Dialogs mit dem Client speichern muss - wie etwa die Frage, ob eine Datei
geoeffnet oder geschlossen wurde. Aus diesem Grund fehlen dem NFS-Proto-
koll auch die sonst ueblichen Prozeduren open und close; die augenblick-
liche Schreib- oder Lese-Position wird im Gegensatz zu den Standard-UNIX-
Ein-/Ausgaberoutinen immer im Auftrag an den Server mitgeliefert.

Da auch der File-Handle (fhandle) fuer eine Datei immer eindeutig sein
muss, ist es nun nach einem Server-Absturz und dem folgenden Wiederanlauf
moeglich, eine Leseoperation transparent fuer das Client-Programm fortzu-
setzen. Waehrend der Server nicht verfuegbar ist, wiederholt das Client-
System in regelmaessigen Zeitabstaenden den Leseauftrag mit den gleichen
Parametern an den Server - so lange, bis dieser wieder antwortet (Mount-
Vorgang). Diese Verhaltensweise ist insbesondere bei plattenlosen Work-
stations vorteilhaft, die ohne den Server ohnehin keine sinnvolle Taetig-
keit ausfuehren koennen.

Das Wiederaussenden von Auftraegen nach Ausbleiben einer Antwort ist ein
Bestandteil des RPC-Mechanismus. Die Wartezeit zwischen den Wiederholun-
gen - die nach jedem erfolglosen Versuch exponentiell erhoeht wird - und
die Anzahl der Wiederholungen bis zum gaenzlichen Abbruch sind mit dem
Kommando *mount* parametrisierbar.

Zusatzdetails zu NFS
--------------------

NFS und Sicherheitsaspekte (Verschluesselung und User nobody):


--------------------------------------------------------------
- Ab NFS-Version 4.0 findet der Austausch fuer eine Zugriffsberechtigung
zwischen Client und Server in verschluesselter Form statt.
- Legt ein Root-User in einem NFS-gemounteten Dateisystem eine Datei an,
dann wird die root-Benutzer-ID 0 in -2 vom Server umgewandelt. Somit
unterliegt die Benutzer-ID -2 allen Zugriffsbeschraenkungen, denen auch
ein normaler Benutzer unterworfen ist. Die Benutzer-ID -2 ist auf einigen
Systemen in /etc/passwd auch als *nobody* eingetragen. Da die Benutzer-
ID in den Datenstrukturen von System V als Wert ohne Vorzeichen gespei-
chert ist, wird dort aus -2 der Wert 65534.
Wuerde diese Umsetzung der Benutzer-ID nicht erfolgen, so waere es mit
der Benutzerkennung ROOT moeglich, auf alle Dateien ohne Einschraenkung
zuzugreifen. Dieses Verhalten ist im vernetzten Betrieb aus Sicherheits-
gruenden nicht wuenschenswert!
Eine Umgehung dieser Umsetzung erlaubt der Systemaufruf *exportfs*, mit
dem man auf den meisten NFS-Implementierungen Dateisysteme gezielt auch
dem Superuser zugaenglich machen kann - was eine Notwendigkeit fuer
plattenlose Workstations ist.
- Zusaetzlich kann der Mount-Daemon die Internet-Adresse (Host-Namen=
Netzwerkkartennamen) und den Namen des Clients mit den lokalen Informa-
tionen in /etc/hosts vergleichen bevor es zu einer Verbindung kommt.

Warum verwendet der nfs-Daemon immer den Port 2049?


---------------------------------------------------
Der nfs-Daemon wird beim Hochfahren des NFS-Systems gestartet. Obwohl
sich der nfs-Daemon (nfs-Server) beim Portmapper registriert, verwendet
er IMMER die TCP/UDP-Portnummer 2049 !!!
Dies wird aus Kompatibilitaetsgruenden mit alten NFS-Clients beibehalten,
die standardmaessig eine Verbindung zum nfs-Daemon aufbauen ohne zuvor
den Portmapper zu befragen.

## 3.Teil NFS ## MOUNT-Protokoll ##

Die Bereitstellung und der Zugriff auf Dateien in NFS-Servern geschieht


durch das *Einhaengen* eines Dateibaums auf dem Server-Rechner in den
lokalen Dateibaum des Client-Rechners. Danach kann ueber normale Betriebs-
mittel (Systemaufrufe, Programme) auf die Dateien dieses Baums zugegrif-
fen werden. DAS NFS-PROTOKOLL IST ALLERDINGS EIN PROTOKOLL FUER DEN
DATEIZUGRIFF - UND DEFINIERT DESHALB SELBST KEINE PROZEDUR, DIE DEN
EINHAENGEVORGANG ANSTOESST.

Der Vorgang des Dateisystem-Einhaengens ist eine davon voellig getrennt


zu betrachtende Problemstruktur, die mit Hilfe des ebenfalls im RFC 1094
spezifizierten MOUNT-Protokolls geloest wird.

Die einzige Information, die ein NFS-Client zu Beginn fuer den Zugriff
auf ein entferntes Dateisystem benoetigt, ist der File-Handle eines
Dateiverzeichnisses, z.B. der Wurzel eines Dateisystems. Aufgabe des
Mount-Protokolls ist es nun, diesen ersten File-Handle fuer des Start zu
liefern. Darueber hinaus enthaelt das Mount-Protokoll noch weitere Pro-
zeduren, u.a. fuer das Abfragen der sogenannten Exportliste (etc/
exports), in der die via NFS bzw. Mount verfuegbaren Dateisysteme ver-
zeichnet sind.

Ablauf eines Mountvorganges: (mount HOST:/export_fs /mnt \\ umount /mnt)


----------------------------
Clientrechner A | Serverrechner B
--------------------------------+-----------------------------------
mount <----(0)---> portmapper
mount -----(1)---> mountd
| mountd ---(2)---> NFS-Server
| mountd <--(3)---- NFS-Server
mount <---(4)---- mountd
NFS-Client <--(5)-- mount |
NFS-Client <-------------------(6)----------------------> NFS-Server
...
NFS-Client <-------------------(7)----------------------> NFS-Server
|

Erklaerung zum Ablauf eines Mountvorganges:


-------------------------------------------
(0)das Mount-Kommando auf dem Client fragt den Portmapper auf der Server-
Seite nach der Portnummer seines mount-Daemons
(1)mit dem Mount-Kommando auf dem Clientrechner wird der Mount-Daemon
auf dem Serverrechner angesprochen
(2)der Mount-Daemon auf dem Serverrechner spricht den NFS-Server an um
sich ein File-Handle (fhandle) geben zu lassen
(3)der NFS-Server uebergibt ein File-Handle
(4)der Mount-Daemon uebergibt dem Clientrechner den File-Handle,
(5)dieser File-Handle wird an den NFS-Client uebergeben
(6)NFS-Client und -Server tauschen Filehandles aus
(7)NFS-Client und -Server uebertragen Daten (read/write)

mount:
------
Mit diesem Befehl wird ein entferntes Verzeichnis in die lokale Verzeich-
nisebene eingehangen. Das entfernte Verzeichnis, also der Remote-Host
auf dem der Mount-Daemon laeuft muss den Zugriff erlauben -> /etc/exports

Mount-Optionen:
---------------
soft|hard wenn hard-mounted eingestellt wird, dann versucht der Client
unbarmherzig eine Verbindung zum NFS-Server herzustellen; ein
soft-mounted Filesystem versucht die Anzahl *retry* festgelegte
Versuche bevor es mit einer Fehlermeldung abbricht;
bei hard-mounted sollte die Option *intr* eingestellt sein
siehe unten unter -> *Zusatzdetail zu dieser Mount-Option ...*
rsize=n Setzen der maximalen Transfergroesse bei Leseoperationen auf
n Bytes. Damit laesst sich verhindern, dass zu grosse Pakete vom
Server angefordert werden, die z.B. durch die UDP Implementierung
oder vom Ethernet-Kontroller nicht verarbeitet werden koennen.
Transfergroesse sollte eine durch 1024 teilbare Zahl und kleiner
als 8 KByte sein.
wsize=n Setzen der maximalen Transfergroesse bei Schreiboperationen auf
n Bytes. Transfergroesse sollte eine durch 1024 teilbare Zahl und
kleiner als 8 KByte sein.
timeo=n Setzen des Weckers fuer die Wiederholung eines RPC-Auftrags in
Einheiten von 1/10 Sekunden. Langsame Server koennen durch eine
vorschnelle (d.h. redundante) Wiederholung eines Auftrags
(Voreinstellung 7/10 Sekunden) noch zusaetzlich unnoetig belastet
werden. Wenn unverhaeltnismaessig hohe Wiederholungsraten auf-
treten (s.a. nfsstat), sollte ueerprueft werden, ob ein Anheben
der Wartezeit durch diese Option eine Verbesserung bringt.
retrans=n Setzen der Anzahl der Wiederholungen eines RPC-Auftrags beim
SOFT MOUNT, bis der Abbruch der Operation erfolgt.
port=n Angabe der Portnummer des NFS-Servers, falls diese nicht 2049
ist. Parallel zum normalen NFS-Server laufende Server, z.B. der
Automounter muessen eine andere UDP-Portnummer verwenden.
retry Auf BSD-Systemen kann man mit der Option retry noch einstellen,
nach welcher Zahl erfolgloser Kommunikationsversuche mit dem
mountd-Server (soft-mount)ein Abbruch erfolgen soll.
bg/fg Mit der Option *bg* wird versucht im BACKGROUND eine Mount-Verbin-
dung herzustellen. Diese Option IST UNBEDINGT ZU EMPFEHLEN, da
sonst beim Hochfahren des Systems so lange wartet bis der NFS-
Server verfuegbar ist oder erst nach einer festgelegten
Zeitspanne der Prozess abgebrochen wird, was lange sein kann!
Wird die Option *bg* verwendet dann auch unbedingt die Option
*intr* angeben!
intr Programme, die auf die Beendigung von NFS-Operationen warten,
koennen mittels Keyboard abgebrochen werden, dies ist notwendig
bei haengenden Hard-Mounted Filesystemen; andernfalls wartet das
Programm endlos
ro|rw Read Only|Read Write

Zusatzdetails zu der Mount-Option: Hard- und Softmount


------------------------------------------------------
HARD MOUNTS sind permanente Mounts, die sich verhalten als waeren sie lo-
kale Filesysteme. Falls ein hard gemountetes Verzeichniss nicht mehr zur
Verfuegung steht, dann versuchen die Client-Programme staendig Zugriff
darauf zu bekommen. Das ist der Grund warum lokale Prozesse geblockt
werden, wenn ein hard gemountetes Verzeichniss abreisst.
Hard Mounts werden auch eingesetzt wenn die File-Integritaet wichtig ist.

SOFT MOUNTS: Prozesse, die auf Verzeichnisse zugreifen, die soft gemountet
sind, erhalten erst einen Fehler, wenn es nach mehreren Versuchen nicht
moeglich war das entfernte Verzeichnis zu erreichen. Lokale Prozesse
werden waehrend des nicht-erreichen des entfernten Verzeichniss nicht
geblockt. General sollte man Soft Mounts nur einsetzen bei lesenden
Zugriffen und wenn man weiss, dass die Mount-Verbindung instabil und unzu-
verlaessig ist. Will man auf ein soft gemountetes Verzeichniss auch
schreibend zugreifen, dann wird es zu Problemen kommen!

unmount oder umount:


--------------------
Dieser Befehl wird beim Aushaengen von entfernten Dateisystemen aufge-
rufen. Eintraege in der /etc/filesystems verbunden mit dem Mount/Unmount-
Befehl haengen die Dateisysteme ein oder aus.
Besonders interessant ist das umount-Kdo. mit der Option -a (umount -a)
Diese Option wird in der Regel als Vorsichtsmassnahme beim Systemstart
des NFS-Clients aufgerufen. Damit wird allen Rechnern im Netz mitgeteilt,
dass der Mount-Eintrag dieser Maschine geloescht werden soll, denn bei
einem Systemabsturz war der Client nicht mehr in der Lage die Eintraege
der NFS-Verbindungen zu den Mount-Daemons mittels unmount zu loeschen!
Ein unmount kann nur erfolgen, wenn kein User oder Prozess auf dem Datei-
system Zugriff hat. Um den User/Prozess zu ermitteln verwendet man den
Befehl *fuser MOUNT-DATEIVERZEICHNIS*. Anhand der Prozess-ID kann der
Verursacher ermittelt werden.

/etc/exports:
-------------
Die Datei /etc/exports wird vom Mount-Daemon ausgelesen. Ein entfernter
Rechner, der eine NFS-Verbindung aufbauen will, verwendet das mount-KDO.
Dieses spricht den Mount-Daemon an. Anhand der IP des entfernten Rechners
und den Uebergabeparametern welches Verzeichnis gemountet werden soll
ueberprueft der Mount-Daemon mit Hilfe der /etc/exports ob ein Zugriff
erlaubt ist. Die Datei /etc/exports ist also nichts weiter als eine
Freibageliste ueber bestimmte Formen des erlaubten Netzwerkzugriffs auf
den eigenen Host.

/etc/exports-Optionen:
----------------------
ro Das Filesystem darf nur gelesen eingehangen werden
rw=host1:host2 Das Filesystem darf nur von den genannten Rechnern
schreibend eingehangen werden; sind keine Rechner-
namen angegeben, koennen alle Clients schreiben
access=host1:host2 Das Filesystem darf nur von den angegebenen Rechnern
eingehangen werden
root=host1:host2 Super-User-Zugriff wird fuer die angegebenen Rechner
erlaubt

## 3.Teil NFS ## LOCK-Mechanismuss (lockd + statd) ##

Unix-Systeme sperren von sich aus einen Lese- oder Schreibzugriff, wenn
ein weiterer Prozess auf eine bereits geoeffnete Datei zugreift. Somit
ist gesichert das es nicht zu Inkonsitstenzen von Dateien kommt. Dieser
Locking-Mechanismuss geschieht jedoch nur lokal fuer jedes einzelne
Unix-System!

Da NFS jedoch ueber Rechnergrenzen hinweg Dateien zur Verfuegung stellen


kann, musste der Locking-Mechanismuss auch auf NFS-Server/-Clients abge-
bildet werden. Erst ab NFS Version 3.2 ist ein Lock-Manager-Mechanissmuss
hinzugefuegt worden. Somit war SUN der Forderung nach kompatiblen Schnitt-
stellen auch fuer NFS und eine vollstaendige Abbildung der lokalen Daten-
symantik nachgekommen.

Der NFS Locking Service ist einer der kompliziertesten Dienste innerhalb
von NFS, er besteht aus mehreren Protokollen und Serverprogrammen.
Die Serverprogramme sind:
- lockd = Lock Daemon
- statd = Status Monitor Daemon
Beide Serverprogramme sind entsprechend der RPC-Philosophie RPC-Programme.

Die Schwierigkeit bei der Implementierung des Locking-Services in ein


bestehendes Unix-System ist es die Betriebssystemkern und die NFS-basier-
enden Sperrmechanismen sicher miteinander zu verbinden.

Zusatzdetails zum Status-Monitor (statd):


-----------------------------------------
Einer der wichtigsten Punkte bei Lock-Operationen ist die Frage, wie
lange die dabei beteiligten Rechner aktiv sind. Ein Beispiel zur Ver-
deutlichung: Gehen wir davon aus, dass ein Prozess auf Rechner A einen
Bereich in einer Datei gesperrt haelt, die sich in einem ueber NFS einge-
haengten Dateisystem auf Rechner B befindet. Wenn B nun eine Anforderung
eines Rechners C fuer denselben Bereich erhaelt, existieren zwei Moeg-
lichkeiten: entweder wartet B (unter Umstaenden bis in alle Ewigkeit) auf
das Ende des Prozesses von A - oder Rechner B prueft, ob A ueberhaupt
noch am Netz haengt (d.h.abgestuerzt ist). Sollte das der Fall sein,
existiert auch der sperrende Prozess nicht mehr - und C kann die Freigabe
(durch B) sofort erhalten. ZUR UEBERWACHUNG DER AKTIVITAET VON RECHNERN
EXISTIERT DER SOGENANNTE STATUS MONITOR STATD.

Ablauf eines Lockvorgangs:


--------------------------
Clientrechner A | Serverrechner B
--------------------------------+-----------------------------------
Programm --- (1)--> NFS-Client |
NFS-Client --(2)--> lockd A |
lockd A -----(3)--> statd A |
statd A ---(4)---> statd B
lockd A ---(5)---> lockd B
| lockd B ---(6)---> statd B
| lockd B ---(7)---> NFS-Server

Erklaerung zum Ablauf eines Lockvorganges:


------------------------------------------
(1)Ein Benutzerprogramm auf Rechner A setzt einen Aufruf an das System
ab, um einen Bereich einer Datei zu sperren.
(2)Der Lock-Daemon auf Rechner A erhaelt vom NFS-Client einen Lock-Auf-
trag fuer eine Datei auf dem Rechner B.
(3)Der Lock-Daemon von A registriert sich beim lokalen Status-Monitor von
A mittels einer RPC-Prozedur. Der RPC-Aufruf enthaelt als Parameter
eine Rueckruf-Prozedur im Lock Daemon und den Hostnamen des zu ueber-
wachenden Rechners (also Rechner B).
(4)Der Status-Monitor A wendet sich an den Status-Monitor auf B, der
daraufhin den Hostnamen des anfordernden Rechners A als Dateinamen im
Dateiverzeichnis /etc/sm abspeichert.
(5)Nachdem die Ueberwachung gestartet ist, setzt der Lock-Daemon A
mittels eines RPC-Aufrufs das gewuenschte Lock ueber den Lock-Daemon
auf Rechner B.
(6)Lock-Daemon B veranlasst die Ueberwachung von Rechner A
(7)und setzt schliesslich die Sperre in der Datei.

Stuerzt der Rechner B mit Status-Monitor und Lock Daemon ab, arbeitet der
Status-Monitor B nach einem darauffolgenden Neustart die gespeicherte
Liste von Hostnamen ab und verstaendigt den Status-Monitor A von seinem
Wiederanlauf. Dieser verstaendigt wiederum den Lock-Daemon A, der nun
beim ebenfalls neu gestarteten Lock Daemon B das fruehere Lock wieder
erzeugt (reclaim). Wie sich an diesem Beispiel erkennen laesst findet die
Ueberwachung nicht durch regelmaessigen Austausch von Nachrichten,
sondern durch eine Rueckmeldung nach dem Wiederanlauf des abgestuerzten
Status-Monitors statt.

Verhalten von lockd + statd nach einem Systemabsturz:


-----------------------------------------------------
Wie bei den restlichen Diensten von NFS ist auch beim netzwerkweiten
Locking das oberste Gebot die Transparenz zur lokalen Dateisystemsemantik.
Wenn ein Server abstuerzt, versucht der Lock-Dienst, nach dem Wiederan-
lauf den Status vor dem Absturz wiederherzustellen - und die auf dem
Client laufende Applikation sollte ausser einer Zeitverzoegerung von der
Unterbrechung nichts bemerkt haben. Selbstverstaendlich ist dies nur beim
Absturz des Servers moeglich und sinnvoll, ein Client-Rechnerabsturz
wuerde auch den Kontext der Applikationen selbst zerstoeren. In diesem
Fall kann und muss der Server das Lock des nicht mehr existierenden
Prozesses freigeben. In beiden Faellen erfaehrt der davon betroffene
Partner jedoch ERST NACH DEM WIEDERANLAUF DES ABGESTUERZTEN RECHNERS von
der Unterbrechung - was unter Umstaenden zu langen Verzoegerungen fuehren
kann.
Bevor der Lock Manager nach dem Systemstart in den Normalbetrieb ueber-
geht, wartet er eine kurze Zeit, die als *grace period* bezeichnet wird.
Waehrend dieser Zeitspanne haben Client-Rechner die Moeglichkeit, vor
einem eventuellen Absturz besetzte Locks erneut einzurichten. Erst nach
dieser Wartezeit koennen auch neue Locks angefordert werden. Standard-
maessig betraegt die grace period 45 Sekunden, sie laesst sich aber beim
Start des lockd veraendern.
Ist das Wiedereinrichten eines Locks nach dem Wiederanlauf des Servers
durch den Client nicht moeglich, sendet der Lock Daemon des Client das
fuer den Lock-Dienst neu definierte Signal SIGLOST an den betroffenen
Prozess. Das SIGLOST-Signal verhaelt sich wie andere UNIX-Signale: der
Prozess kann es entweder auffangen und Rettungsmassnahmen einleiten oder
ignorieren (und wird dann im Normalfall abgebrochen). Auch wenn dieses
Verfahren etwas rabiat wirkt: die Alternative waere eine Arbeit mit
eventuell verfaelschten Daten.

## 3.Teil NFS ## NFS-Daemons ##

NFS ist eine Ansammlung von Daemonen. Diese Daemonen laufen auf dem
Server und/oder auf dem Client, als da waeren:
nfsd, biod, mountd, lockd, statd

NFS-Client-Daemons NFS-Server-Daemons
------------------ ------------------
- +----<-> nfsd !!! Kommunikation: biod <-> nfsd
- + mountd
biod <->----+ - !!! wenn biod, dann auf Client
lockd lockd !!! laufen auf Client und Server !!!
statd statd !!! laufen auf Client und Server !!!

Funktionen der einzelnen Daemonen:


----------------------------------
- nfsd
Dieser Daemon laeuft auf dem Server und nimmt Anfragen vom Client ent-
gegen, d.h. der Client-Daemon *biod* kommuniziert mit dem *nfsd*.
Der *nfsd* verarbeitet die Anfragen und fuehrt lokale I/O-Operationen
aus. Waehrend der I/O-Operation kann der gestartete Daemon keine wei-
teren NFS-Anfragen entgegennehmen, erst wieder wenn der I/O-Prozess ab-
geschlossen ist. Daher werden gewoehnlich mehrere Daemonen auf dem
System gestartet um gleichzeitig mehrere Clients bedienen zu koennen.
Die NFS-Server nehmen Auftraege aus einer gemeinsamen Warteschlange
entgegen und arbeiten diese sequentiell ab.
Default-Einstellung ist *8*, kann jedoch entsprechend der Systembe-
lastung angepasst werden.
Ermittlung der Anzahl vorhandener NFS-Daemons auf dem System:
ps -ef|grep nfsd -> /usr/sbin/nfsd 8 # 8 NFS-Daemons vorhanden

- biod = Block Input/Output Daemon


Zur Verbesserung des Datendurchsatzes werden in Unix die Datenblocks in
einem Puffer gehalten, der auch als buffer cache bezeichnet wird.
Dieser Mechanismus gilt auch fuer Daten, die mit Hilfe von NFS gelesen
oder geschrieben werden. Es kommt somit zum asynchronen lesen/schreiben
beim Systemaufruf eines Programms. Es werden Daten im voraus gelesen
und spaeter geschrieben. Diese Technik nennt man Read-Ahead und
Delayed-Write. Der biod-Daemon setzt diese Technik in NFS-Auftraegen
ein. Er verbessert den Datendurchsatz der Verbindung zwischen NFS-
Client und -Server, ist jedoch NICHT ZUM BETRIEB UNBEDINGT NOTWENDIG.
Ohne diesen Daemon findet lediglich kein asynchrones Lesen und Schrei-
ben ueber NFS statt. In der Regel sind mehrere biod-Prozesse gleich-
zeitig aktiv, um mehrere Operationen parallel durchfuehren zu koennen.
Das Starten von zu vieler biod-Daemons kann auch nachteilige Ergebnisse
haben, naemlich dann, wenn durch gleichzeitiges Delayed-Write aller
Daemons die UDP/TCP-Ausgabepufferkapazitaet erschoepft wird!
Ermittlung der Anzahl vorhandener biod-Daemons auf dem System:
ps -ef|grep biod -> /usr/sbin/biod 6 # 6 biod-Daemons vorhanden

- mountd
Der Mount-Daemon laeuft nur auf dem NFS-Server und nimmt *mount-Komman-
dos* der Clients entgegen. Ausserdem gibt es pro NFS-Server nur einen
einzigen mount-Daemon (also nicht mehrere wie beim nfsd).
Setzt der NFS-Client einen *mount-Befehl* ab, dann erzeugt der NFS-
NFS-Daemon ein File-Handle, welches dem NFS-Client uebergeben wird.
Erst mit diesem File-Handle kann der NFS-Client read/write-Operationen
auf dem NFS-Server absetzen.
Des weiteren obliegt dem Mount-Daemon die Export-Liste /etc/exports, in
der festgelegt wird, ob und von wem (Host besser Interface! welche in
der /etc/host definiert ist) ein Dateisystem eingehaengt werden darf.

- lockd/statd
Der Lock-Daemon (lockd) und der Status-Monitor-Daemon (statd) arbeiten
zusammen sowohl auf dem NFS-Client als auch auf dem NFS-Server.
Beide Daemons sorgen dafuer, dass es nicht zu Dateninkonsistenzen ueber
gemountete Dateisysteme (Netzwerkgrenzen hinweg) kommt.
Zu einer Dateninkonsistenz kann es kommen, wenn z.B. der NFS-Server
eine Datei dem NFS-Client zur Dateiveraenderung zur Verfuegung stellt
UND das lokale Betriebssystem auf dem der NFS-Server laeuft auch auf
die gleiche Datei zugreifen moechte.

## 4.Teil NFS in der Praxis ## NFS-Befehle ##

NFS-Befehle:
------------
### showmount ###
Das Kommando *showmount* spricht den Mount-Daemon an. Wird als Paramter
ein HOST-Name uebergeben dann wird der Remote-Mount-Daemon angesprochen,
sonst wird der lokale mount-Daemon angesprochen. Showmount verwendet fuer
seine Anfragen beim Mount-Daemon das Mount-Protokoll (RPC-Protokoll!).
showmount -e zeigt die aktuelle Liste der exportierten Verzeichnisse,
liest die lokale Datei /etc/xtab (AIX-Kdo: exportfs)
In der Dokumentation wird oft angegeben, dass die Option
-e die Datei /etc/exports ausliest, das ist falsch!
Im Grunde jedoch ist der Inhalt der /etc/xtab identisch
mit der Datei /etc/exports, es sei denn man hat manuell
mit dem Befehl *exportfs -i DIR* ein Verzeichnis hinzu-
gefuegt -> siehe Hinweis /etc/xtab und /etc/rmtab
showmount -e HOST siehe showmount -e, nur das nicht lokal abgefragt wird,
sondern der Rechner mit dem Name HOST.
showmount -a zeigt alle remote mounts im Format Hostname:Verzeichnis,
wobei der Hostname der Name des NFS-Clients ist und das
Verzeichnis gibt an das lokale Verzeichnis welche ge-
mountet wurde. Diese Information holt sich der Mount-
Daemon NICHT aus der Datei /etc/rmtab (remote mount
table)!
siehe Hinweis /etc/xtab und /etc/rmtab
showmount -a HOST siehe showmount -a, nur das nicht lokal abgefragt wird,
sondern der Rechner mit dem Namen HOST.
showmount -d Ausgabe wie mit Option *-a*, nur das der Hostname des
NFS-Clients nicht angezeigt wird, besser die Option
-a als -d waehlen!

### exportfs ###


Das Kommando *exportfs* exportiert lokale Verzeichnisse fuer NFS-Zugriffe.
Dieses Kommando wird beim Systemstart mit der Option *-a* (alle Verzeich-
nisse in /etc/exports exportieren) durch das Startscript /etc/rc.nfsfile
aufgerufen.

exportfs ohne Parameterangabe liest die Datei /etc/xtab


exportfs -a exportiert alle lok.Verzeichnisse aus Datei /etc/exports
und schreibt die Information in /etc/xtab (Kernel)
exportfs -i DIR exportiert das Verzeichnis DIR - diese Einstellung ist
nur temporaer bis zum naechsten Systemstart
exportfs -u DIR entfernt das exportierte Verzeichnis DIR aus der Datei
/etc/xtab
exportfs -o mit dem Parameter *-o* koennen dem export-Kommando wei-
tere Optionen mitgegeben werden, siehe Man-Pages

Hinweis /etc/xtab und /etc/rmtab:


---------------------------------
/etc/xtab listet alle aktuell zur Verfuegung stehenden exportierten Ver-
zeichnisse (showmount -e) auf, zeigt aber keinen Status an ob
die exportierten Verzeichnisse gerade gemountet sind oder
nicht!!! Diese Information legt der Mount-Daemon in der Datei
/etc/rmtab ab.
Die Datei /etc/xtab sollte nicht manuell editiert werden, denn
das Kommando *exportfs* veraendert den Inhalt dieser Datei!
/etc/rmtab enthaelt Informationen ueber den gegenwaertigen Status aller
zugreifenden NFS-Clients, welche auf lokale und exportierte
Verzeichnisse zugreifen. Der Inhalt dieser Datei wird vom
Mount-Daemon verwaltet. Mit Hilfe dieser Datei erhaelt der
Mount-Daemon nach einem Systemstart wieder die Information
welcher NFS-Client gemountet war ohne das sich der NFS-Client
ein erneutes mal beim NFS-Server mittels mount-Kommando
anmelden muss - zustandsloses Protokoll - siehe oben.
### rpcinfo ###
Das Kommando *rpcinfo* arbeitet in Verbindung mit dem Portmapper. Es kann
der lokale als auch der entfernte Portmapper angesprochen werden. Es be-
steht sogar die Moeglichkeit RPC-basierende Server auf dem lokalen/
entfernten Rechner anzustossen um somit seine Funktionsweise zu testen.

rpcinfo -p [localhost] listet alle dem Portmapper registrierten Dienste


rpcinfo -p HOST dto. auf dem entfernten Rechner HOST
rpcinfo -s HOST wie Option *-p* nur noch knapper!
rpcinfo -u HOST mountd TESTET den UDP-basierten Mount-Daemon von HOST
... program 100005 version 3 ready and waiting
rpcinfo -t localhost nfs TESTET den eigenen TCP-basierten NFS-Daemon
rpcinfo -m HOST Statistic zum Portmapper
rpcinfo -b nfs 3 listet alle im Netz (b=Broadcast) aktiven nfsd

### nfsstat ###


Das Kommando *nfsstat* zeigt statistische Angaben ueber RPC-Verbindungen
sowie auch NFS-Verbindungen. Mit Hilfe der Statistik ist es eventuell
moeglich Fehler von Verbindungen herausfinden.

nfsstat zeigt alle Statistiken zu RPC-/NFS-Server und -Clients


nfsstat -s zeigt Statistiken zu RPC-/NFS-Server
nfsstat -c zeigt Statistiken zu RPC-/NFS-Client
nfsstat -n zeigt Statistiken zu NFS-Server und -Client
nfsstat -r zeigt Statistiken zu RPC-Server und -Client
nfsstat -rs zeigt Statistik zu RPC-Server
nfsstat -m zeigt Statistiken zu gemounteten Dateisystemen (interessant)
nfsstat -z Reset aller Statistiken

Hinweise zu den RPC-Statistiken des Kommandos *nfsstat*


-------------------------------------------------------
badcalls enthaelt die Summe aller fehlerhaften RPC-Nachrichten
nullrecv + badlen weisen auf leere oder zu kurze RPC-Nachrichten hin
xdrcall steht fuer XDR-Dekodierungsfehler eines Aufrufs
wait Zaehler wird erhoeht, wenn keine freien UDP-Kommuni-
kationsendpunkte zum Senden vorhanden sind
badxid zaehlt die empf.Nachrichten mit, die keine Antworten
auf unmittelbar vorher ausgesendeten RPC-Auftraege waren
timeout + retrans im Client: ein verbundener NFS-Server ist zu langsam
oder verliert Pakete

Ermittlung der Anzahl der nfsd und biod


---------------------------------------
Ermittlung der Anzahl vorhandener NFS-Daemons auf dem System:
ps -ef|grep nfsd -> /usr/sbin/nfsd 8 # 8 NFS-Daemons vorhanden
Ermittlung der Anzahl vorhandener biod-Daemons auf dem System:
ps -ef|grep biod -> /usr/sbin/biod 6 # 6 biod-Daemons vorhanden

Mount-Kommandos die im Hintergrund ausgefuehrt werden


-----------------------------------------------------
Enthaelt das Mount-Kommando die Option *bg* = background, dann wird bei
einem zunaechst nicht zustandegekommenen Mount dieser Befehl als Hinter-
grundprozess im System ausgefuehrt:
root@icaet087:/>mount -o=bg icaet018:/tmp /mnt
mount: 1831-010 server icaet018 not respondingmount: backgrounding icaet018:/tmp
Prozess:
/sbin/helpers/nfsmnthelp M 0 icaet018 /tmp /mnt bg,hard,intr,proto=tcp,rw

NFS-relevante Parameter
-----------------------
Synonym zu den Netzwerkparameter, die man sich mit *no -a* anzeigen kann,
gibt es fuer NFS auch Parameter mit denen sich die NFS-Eigenschaften be-
einflussen lassen:
nfso -l zeigt alle Parameter an
nfso -o xyz=abc setzt Parameter xyz bis zum naechsten Reboot;
permanent einstellen in /etc/rc.nfs

NFS-Server neu starten (AIX)


----------------------------
Wenn ein NFS-Client partout die NFS-Dienste auf einem Host nicht er-
reichen kann (vorausgesetzt: Netzwerk ok), dann fuehrt man folgendes
auf dem NFS-Server aus:
- stopsrc -g nfs
- stopsrc -s portmap
- cd /etc
- rm -rf state sm sm.bak xtab rmtab
- startsrc -s portmap
- startsrc -g nfs
- exportfs -a
- showmount -e (client: showmount -e NFS-SERVER)

Probleme beim Mounten


---------------------
folgt folgender Fehler, obwohl der shomount-Befehl sagt, dass "everyone"
exportieren kann, dann kann keine Namensaufloesung auf dem NFS-Server
erfolgen -> Abhilfe auf NFS-Server /etc/hosts oder DNS-Eintrag vornehmen
mit dem Interface/IP von welchem darauf zugegriffen wird.

caga0101:/root > mount ehnsds01:/sds/aix/aix530 /mnt


nfsmnthelp: 1831-019 ehnsds01: System call error number -1.

mount: 1831-008 giving up on:


ehnsds01:/sds/aix/aix530
System call error number -1.

Probleme beim Mounten


---------------------
nfsmnthelp: 1831-019 HOSTNAME: A socket is connected to a host that is no
longer available.
mount: 1831-008 giving up on:

Hier wird versucht auf ein exportiertes Verzeichnis zuzugreifen, welches


selbst auf eine andere Maschine gemountet ist !

## 5.Teil NFS und Firewall ##

NFS-Verbindungen durch eine Firewall zu schleusen ist keine einfache


Aufgabe. Grund ist der Einsatz des RPC-Protokolls mittels Portmapper.
Bei jedem Neustart des Systems erhalten die NFS-Daemonen neue IP-Port-
nummern (rpcinfo -p [localhost]). Die Clients erfahren diese durch den
Portmapper, allerdings gibt es Firewalls, die nicht in der Lage sind die
Ports beim Verbindungsaufbau zu erlernen und freizugeben. Es bleibt nur
die FW weit genug zu oeffnen :-(
Der NFS-Daemon (Port 2049) und der Portmapper (Port 111) bleiben konstant
auf dem Port bestehen, wie sonst wuerde sonst eine Verbindung zustande
kommen? ;-)
Die restlichen 3 NFS-Daemonen (mountd/statd/lockd) erhalten immer neue
Werte beim Systemstart.

Empfehlungen fuer Port-Einstellung der Firewall:

| AIX 4.3.3.9 | AIX 4.3.3.10 | AIX 5.2


-------+-------------+--------------+----------
mountd | 600-1010 | 32-34000 | 32-34000
statd | 32-34000 | 32-34000 | 32-34000
lockd | 32-34000 | 32-34000 | 32-34000

Laesst sich der Port fest einstellen? (PMR 27207,101,616 + 71173,999,000)


-------------------------------------
Ja, leider nur mit dem *mountd*-Daeomn, nicht jedoch mit den *statd*- u.
dem *lockd*-Daemon! Und das hilft der Firewall auch nicht weiter !!!
AIX 4.3.3 -> bos.net.nfs.client 4.3.3.53
AIX 5.1 -> bos.net.nfs.client 5.1.0.0
/etc/services -> mountd xxxx/tcp #xxxx => <1024
mountd yyyy/udp #yyyy => <1024
nfso -o nfs_use_reserved_ports=1 (permanent in /etc/rc.net eintragen)
refresh -s rpc.mountd

## 6.Teil NFS AIX + Linux ##


Mounten vom AIX zum Linux nur mit folgenden Optionen moeglich:
entweder im AIX:
PMR 50028, 070, 724
# nfso -o portcheck=1
# nfso -o nfs_use_reserved_ports=1 (siehe einige Zeilen weiter oben!)
Explanation:
LINUX response the client mount request will using reserved_ports.
AIX default nfs_use_reserved_ports is 0
oder im Linux:
die Option insecure setzen

## 7.Teil Trace eins Mount/UMOUNT ##

Mount (einfache Darstellung):


1) mount-Client fragt Portmapper ueber udp nach Portnummer des mountd
2) Mount-Programm des mount-Client ruft mountd ueber tcp auf
3) mount-Client fragt Portmapper ueber udp nach Portnummer des nfsd
4) NFS-Programm des nfs-Client ruft nfsd ueber tcp auf
5) Parameter-Uebergabe des Mount-Prog. v. mount-Client ueber tcp an mountd
6) NFS-Client und Server handeln NFS-Filehandles aus
7) Mount-Client bestaetigt die NFS-Verbindung an den mountd

Umount (einfache Darstellung):


1) mount-Client fragt Portmapper ueber udp nach Portnummer des mountd
2) Parameter-Ueberg.d.mount-Client zum Abbau der Verbdg. ueber udp an mountd
3) mountd bestaetigt Abbau des Mount-Points ueber udp

##########

Mount/Umount-Vorgang on detail: (keine Uebertragung von Daten!)

--- Mount -->


Mount-Client RPC-Calls/Flags Mount-Server
-------------------------------------------------
Pack-Nr. Port Port
039 683 ------RPC-CALL------> 111 sunrpc udp! *1
040 683 <-----RPC-REPLY------ 111 sunrpc udp! Returning 32775
042 683 --------syn---------> 32775 tcp
043 683 <------syn ack------- 32775 tcp
044 683 --------ack---------> 32775 tcp
045 683 --RPC-CALL/push ack-> 32775 tcp *2
046 683 <-RPC-REPLY/push ack- 32775 tcp *3
047 683 --RPC-CALL----------> 111 sunrpc udp *4
048 683 <-RPC-REPLY---------- 111 sunrpc udp *5 Returning 2049
049 684 --------syn---------> 2049 nfsd tcp
050 684 <------syn ack------- 2049 nfsd tcp
051 684 --------ack---------> 2049 nfsd tcp
052 684 --RPC-CALL/push ack-> 2049 nfsd tcp *6
053 684 <-RPC-REPLY/push ack- 2049 nfsd tcp *7
054 684 -------fin ack------> 2049 nfsd tcp
055 684 <-------ack---------- 2049 nfsd tcp
056 684 <------fin ack------- 2049 nfsd tcp
057 683 --RPC-CALL/push ack-> 32775 tcp *8
058 684 --------ack---------> 2049 nfsd tcp
059 683 <-RPC-REPLY/push ack- 32775 tcp *9
060 683 -------fin ack------> 32775 tcp
061 683 <-------ack---------- 32775 tcp
062 33180 --RPC-CALL/push ack-> 2049 nfsd tcp *10
063 33180 <-RPC-REPLY/push ack- 2049 nfsd tcp *11
064 683 <------fin ack------- 32775 tcp
065 683 --------ack---------> 32775 tcp
066 33180 --------ack---------> 2049 nfsd tcp !!Verbindung steht!!

--- Umount -->

Mount-Client RPC-Calls/Flags Mount-Server


-------------------------------------------------
Pack-Nr. Port Port
118 683 --RPC-CALL----------> 111 sunrpc udp *12
119 683 <-RPC-REPLY---------- 111 sunrpc udp *13 Returning 32778
120 683 --RPC-CALL----------> 32778 udp *14
121 683 <-RPC-REPLY---------- 32778 udp *15

Details:
--------
*1 RPC: **CALL** XID=1049979767
RPC: Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
PMP: Prog=100005 Vers=3 Prot=6 Port=0

*2 RPC: Program=100005 (MOUNTPROG) Version=3 Procedure=0 (MOUNTPROC3_NULL)

*3 RPC: 100005(MOUNTPROG) 0(MOUNTPROC3_NULL)


RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS

*4 RPC: **CALL** XID=1049935976


RPC: Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
PMP: Prog=100003 Vers=3 Prot=6 Port=0

*5 RPC: **REPLY** XID=1049935976


RPC: 100000(PMAPPROG) 3(PMAPPROC_GETPORT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS
PMP: Returning 2049

*6 RPC: **CALL** XID=1050089675


RPC: Program=100003 (NFS_PROGRAM) Version=3 Procedure=0 (NFSPROC3_NULL)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0

*7 RPC: **REPLY** XID=1050089675


RPC: 100003(NFS_PROGRAM) 0(NFSPROC3_NULL)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS

*8 RPC: **CALL** XID=1049928997


RPC: Program=100005 (MOUNTPROG) Version=3 Procedure=1 (MOUNTPROC3_MNT)
RPC: AUTH_UNIX
RPC: Cred:
RPC: Time=0x3e9582ef (Thu Apr 10 16:42:55 2003)
RPC: Machine=icacw002 Uid=0 Gid=0 Group List Length=7
RPC: Groups= ( 0 2 3 7 8 10 11 )
MNT: Path: /sds/aix

*9 RPC: **REPLY** XID=1049928997


RPC: 100005(MOUNTPROG) 1(MOUNTPROC3_MNT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS
MNT: Fhandle: .... * * *
MNT: Authentication Flavors:
MNT: Length: 0001 Flavors: AUTH_UNIX
MNT: Status=OK (0)

*10 RPC: **CALL** XID=446962462


RPC: Program=100003 (NFS_PROGRAM) Version=3 Procedure=19 (NFSPROC3_FSINFO)
RPC: AUTH_UNIX
RPC: Cred:
RPC: Time=0x3e9582ef (Thu Apr 10 16:42:55 2003)
RPC: Machine=icacw002 Uid=0 Gid=0 Group List Length=7
RPC: Groups= ( 0 2 3 7 8 10 11 )
NFS: Fhandle:
NFS: 00410004 00000003 000a0000 00023be8
NFS: f12e0000 000a0000 00023be8 f12e0000

*11 RPC: **REPLY** XID=446962462


RPC: 100003(NFS_PROGRAM) 19(NFSPROC3_FSINFO)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS
NFS: Stat: (0) NFS3_OK
NFS: File System Attributes: ......
Access-,Modify-,Create-Time + Buffergroessen + max.Filesise

*12 RPC: **CALL** XID=1050501069


RPC: Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT)
RPC: AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0
PMP: Prog=100005 Vers=1 Prot=17 Port=0
*13 RPC: **REPLY** XID=1050501069
RPC: 100000(PMAPPROG) 3(PMAPPROC_GETPORT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS
PMP: Returning 32778

*14 RPC: **CALL** XID=1050500913


RPC: Program=100005 (MOUNTPROG) Version=1 Procedure=3 (MOUNTPROC_UMNT)
RPC: AUTH_UNIX
RPC: Cred:
RPC: Time=0x3e9582fe (Thu Apr 10 16:43:10 2003)
RPC: Machine=icacw002 Uid=0 Gid=0 Group List Length=7
RPC: Groups= ( 0 2 3 7 8 10 11 )
MNT: Path: /sds/aix

*15 RPC: **REPLY** XID=1050500913


RPC: 100005(MOUNTPROG) 3(MOUNTPROC_UMNT)
RPC: Reply Stat: MSG_ACCEPTED
RPC: Accepted Reply Stat: SUCCESS

*************************************************************************

Literatur-Hinweiss
------------------
TCP/IP und NFS in Theorie und Praxis/Michael Santifaller/Addison-Wesley *
AIX-Online-Dokumentation 4.3.3 Base Documentation
Managing NFS and NIS / by Hal Stern / O�Reilly / *
TCP/IP Illustrated Volume I / by Richard Stevens / Addison Wesley / *
IBM Mega-Database

* = IBM-Bibliothek vorhanden

Office-File-Name : help nfs a2


Ascii-File-Name : nfs.asc
Tag der Erstellung : 02.04.2003
Update : 16.10.2006
Courier New 8
bearbeiten mit DOS-ASCII-Editor:EDIT
erstellt von : Peter Brinker
e-Mail : no_spam_p.brinker(at)gmx.net