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 veroeffentlicht und fuer geringe Lizenzgebuehren abgegeben - NFS erlaubt Programme, auf Dateien in NFS-Serverrechnern schreibend und lesend zuzugreifen; der Zugriff erfolgt transparent durch einhaengen (Unix-Jargon=mount) in das Dateisystem - die Bereitstellung der Zugriffsmoeglichkeit des gemounteten Dateisystems muss vor dem Zeitpunkt des Zugriffs erfolgen - urspruengliches Entwicklungsziel von NFS war es, etwa 80% des Datendurchsatzes einer lokalen Festplatte zu erreichen - fuer DisklessWorkstations - 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 Implementierungen 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 NFSVersion 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 ---> ==> dto. NFS-Version 3 --------------> ==> dto. NFS-Version 4 --------------> - Presentation ==> XDR ----------------------------> - Session ==> RPC ---------------------------->

RFC RFC RFC RFC RFC

1094 1813 3010 1014 1050

XDR muss durch den Hersteller bei der Implementierung des NFS-PrgrammPacketes beruecksichtigt werden und soll in dieser Dokumentation nur belaeufig erwaehnt werden. Daher erfolgt hier nur eine kurze Beschreibung 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 auszutauschen. 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 Funktionsweise 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 Kommunikationssteuerungsschicht (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 NFSApplikationen!!! 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 zurueckgesendete 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 eingeteilt, wobei SUN fuer sich den ersten Programmnummern-Bereich beansprucht. Tabelle zur Festlegung der RPC-Programmnummer: Beginn Ende Verwendung

00 20 40 60 80 A0 C0 E0

SUN --->---------->--------->--------+ frei | transiente Programme | reserviert | reserviert | reserviert | reserviert | 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 Applikationen 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-Nachrichten 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 Transportschicht 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 Transportquittungen oder andere Sicherheitsmassnahmen - allerdings macht das Fehlen dieser Zusaetze UDP besonders effizient und daher geeignet fuer Hochgeschwindigkeitsanwendungen wie z.B. verteilte Dateisysteme (NFS) oder dergleichen, 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 gestartet, 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

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00

1F 3F 5F 7F 9F BF DF FF

FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF

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 wesentlichen 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 zwischen 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 100024 100021 100021 100021 100021 100021 100021 100021 100021

1 1 1 2 3 4 1 2 3 4

udp tcp udp udp udp udp tcp tcp tcp tcp

850 850 32792 32792 32792 32792 32772 32772 32772 32772

status status nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr

#Port variabel #Port variabel

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 Portmapper-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 RPCDienst 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 Portmapper (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 Dateizugriffsdienst zu entwerfen, der vor allem das leidige Problem des Wiederanlaufs 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-Protokoll auch die sonst ueblichen Prozeduren open und close; die augenblickliche Schreib- oder Lese-Position wird im Gegensatz zu den Standard-UNIXEin-/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 fortzusetzen. 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 (MountVorgang). Diese Verhaltensweise ist insbesondere bei plattenlosen Workstations vorteilhaft, die ohne den Server ohnehin keine sinnvolle Taetigkeit ausfuehren koennen. Das Wiederaussenden von Auftraegen nach Ausbleiben einer Antwort ist ein Bestandteil des RPC-Mechanismus. Die Wartezeit zwischen den Wiederholungen - 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 BenutzerID in den Datenstrukturen von System V als Wert ohne Vorzeichen gespeichert 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 Sicherheitsgruenden 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 Informationen 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 Betriebsmittel (Systemaufrufe, Programme) auf die Dateien dieses Baums zugegriffen 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 Prozeduren, u.a. fuer das Abfragen der sogenannten Exportliste (etc/ exports), in der die via NFS bzw. Mount verfuegbaren Dateisysteme verzeichnet 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 ServerSeite 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 Verzeichnisebene 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 auftreten (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-Verbindung herzustellen. Diese Option IST UNBEDINGT ZU EMPFEHLEN, da sonst beim Hochfahren des Systems so lange wartet bis der NFSServer 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 lokale 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 unzuverlaessig 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 aufgerufen. 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 Dateisystem 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 Rechnernamen 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) ## von sich aus einen Lese- oder Schreibzugriff, wenn auf eine bereits geoeffnete Datei zugreift. Somit nicht zu Inkonsitstenzen von Dateien kommt. Dieser geschieht jedoch nur lokal fuer jedes einzelne

Unix-Systeme sperren ein weiterer Prozess ist gesichert das es Locking-Mechanismuss Unix-System!

Da NFS jedoch ueber Rechnergrenzen hinweg Dateien zur Verfuegung stellen kann, musste der Locking-Mechanismuss auch auf NFS-Server/-Clients abgebildet werden. Erst ab NFS Version 3.2 ist ein Lock-Manager-Mechanissmuss hinzugefuegt worden. Somit war SUN der Forderung nach kompatiblen Schnittstellen auch fuer NFS und eine vollstaendige Abbildung der lokalen Datensymantik 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-basierenden 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 Verdeutlichung: Gehen wir davon aus, dass ein Prozess auf Rechner A einen Bereich in einer Datei gesperrt haelt, die sich in einem ueber NFS eingehaengten Dateisystem auf Rechner B befindet. Wenn B nun eine Anforderung eines Rechners C fuer denselben Bereich erhaelt, existieren zwei Moeglichkeiten: 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-Auftrag 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 ueberwachenden 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 Wiederanlauf 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 uebergeht, 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. Standardmaessig 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 -----------------+----<-> + biod <->----+ lockd statd NFS-Server-Daemons -----------------nfsd !!! Kommunikation: biod <-> nfsd mountd !!! wenn biod, dann auf Client lockd !!! laufen auf Client und Server !!! statd !!! laufen auf Client und Server !!!

Funktionen der einzelnen Daemonen: ---------------------------------- nfsd Dieser Daemon laeuft auf dem Server und nimmt Anfragen vom Client entgegen, 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 weiteren NFS-Anfragen entgegennehmen, erst wieder wenn der I/O-Prozess abgeschlossen 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 Systembelastung 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 NFSClient und -Server, ist jedoch NICHT ZUM BETRIEB UNBEDINGT NOTWENDIG. Ohne diesen Daemon findet lediglich kein asynchrones Lesen und Schreiben ueber NFS statt. In der Regel sind mehrere biod-Prozesse gleichzeitig 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-Kommandos* 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 NFSNFS-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 hinzugefuegt -> 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 gemountet wurde. Diese Information holt sich der MountDaemon 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 Verzeichnisse in /etc/exports exportieren) durch das Startscript /etc/rc.nfsfile aufgerufen. exportfs exportfs -a ohne Parameterangabe liest die Datei /etc/xtab 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 weitere Optionen mitgegeben werden, siehe Man-Pages Hinweis /etc/xtab und /etc/rmtab: --------------------------------/etc/xtab listet alle aktuell zur Verfuegung stehenden exportierten Verzeichnisse (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 besteht sogar die Moeglichkeit RPC-basierende Server auf dem lokalen/ entfernten Rechner anzustossen um somit seine Funktionsweise zu testen. rpcinfo rpcinfo rpcinfo rpcinfo -p -p -s -u [localhost] HOST HOST HOST mountd listet alle dem Portmapper registrierten Dienste dto. auf dem entfernten Rechner HOST wie Option *-p* nur noch knapper! TESTET den UDP-basierten Mount-Daemon von HOST ... program 100005 version 3 ready and waiting TESTET den eigenen TCP-basierten NFS-Daemon Statistic zum Portmapper listet alle im Netz (b=Broadcast) aktiven nfsd

rpcinfo -t localhost nfs rpcinfo -m HOST rpcinfo -b nfs 3

### 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 nfsstat nfsstat nfsstat nfsstat nfsstat nfsstat nfsstat -s -c -n -r -rs -m -z zeigt zeigt zeigt zeigt zeigt zeigt zeigt Reset alle Statistiken zu RPC-/NFS-Server und -Clients Statistiken zu RPC-/NFS-Server Statistiken zu RPC-/NFS-Client Statistiken zu NFS-Server und -Client Statistiken zu RPC-Server und -Client Statistik zu RPC-Server Statistiken zu gemounteten Dateisystemen (interessant) 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-Kommunikationsendpunkte 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 Hintergrundprozess 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 beeinflussen 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 erreichen 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-Portnummern (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: --- Mount --> (keine Uebertragung von Daten!)

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 119 683 <-RPC-REPLY---------- 111 sunrpc udp 120 683 --RPC-CALL----------> 32778 udp 121 683 <-RPC-REPLY---------- 32778 udp Details: -------*1 RPC: RPC: RPC: PMP: *2 *3

*12 *13 Returning 32778 *14 *15

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

RPC: Program=100005 (MOUNTPROG) Version=3 Procedure=0 (MOUNTPROC3_NULL) RPC: 100005(MOUNTPROG) 0(MOUNTPROC3_NULL) RPC: Reply Stat: MSG_ACCEPTED RPC: Accepted Reply Stat: SUCCESS 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

*4

PMP: Prog=100003 Vers=3 Prot=6 Port=0 *5 RPC: RPC: RPC: RPC: PMP: **REPLY** XID=1049935976 100000(PMAPPROG) 3(PMAPPROC_GETPORT) Reply Stat: MSG_ACCEPTED Accepted Reply Stat: SUCCESS 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 RPC: RPC: RPC: RPC: RPC: RPC: RPC: RPC: RPC: RPC: RPC: MNT: RPC: RPC: RPC: RPC: MNT: MNT: MNT: MNT: **REPLY** XID=1050089675 100003(NFS_PROGRAM) 0(NFSPROC3_NULL) Reply Stat: MSG_ACCEPTED Accepted Reply Stat: SUCCESS **CALL** XID=1049928997 Program=100005 (MOUNTPROG) Version=3 Procedure=1 (MOUNTPROC3_MNT) AUTH_UNIX Cred: Time=0x3e9582ef (Thu Apr 10 16:42:55 2003) Machine=icacw002 Uid=0 Gid=0 Group List Length=7 Groups= ( 0 2 3 7 8 10 11 ) Path: /sds/aix **REPLY** XID=1049928997 100005(MOUNTPROG) 1(MOUNTPROC3_MNT) Reply Stat: MSG_ACCEPTED Accepted Reply Stat: SUCCESS Fhandle: .... * * * Authentication Flavors: Length: 0001 Flavors: AUTH_UNIX Status=OK (0) **CALL** XID=446962462 Program=100003 (NFS_PROGRAM) Version=3 Procedure=19 (NFSPROC3_FSINFO) AUTH_UNIX Cred: Time=0x3e9582ef (Thu Apr 10 16:42:55 2003) Machine=icacw002 Uid=0 Gid=0 Group List Length=7 Groups= ( 0 2 3 7 8 10 11 ) Fhandle: 00410004 00000003 000a0000 00023be8 f12e0000 000a0000 00023be8 f12e0000

*7

*8

*9

*10 RPC: RPC: RPC: RPC: RPC: RPC: RPC: NFS: NFS: NFS:

*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: RPC: RPC: PMP: **CALL** XID=1050501069 Program=100000 (PMAPPROG) Version=2 Procedure=3 (PMAPPROC_GETPORT) AUTH_NULL Opaque Authorization Base 0 Opaque Authorization Length 0 Prog=100005 Vers=1 Prot=17 Port=0

*13 RPC: RPC: RPC: RPC: PMP: *14 RPC: RPC: RPC: RPC: RPC: RPC: RPC: MNT: *15 RPC: RPC: RPC: RPC:

**REPLY** XID=1050501069 100000(PMAPPROG) 3(PMAPPROC_GETPORT) Reply Stat: MSG_ACCEPTED Accepted Reply Stat: SUCCESS Returning 32778 **CALL** XID=1050500913 Program=100005 (MOUNTPROG) Version=1 Procedure=3 (MOUNTPROC_UMNT) AUTH_UNIX Cred: Time=0x3e9582fe (Thu Apr 10 16:43:10 2003) Machine=icacw002 Uid=0 Gid=0 Group List Length=7 Groups= ( 0 2 3 7 8 10 11 ) Path: /sds/aix **REPLY** XID=1050500913 100005(MOUNTPROG) 3(MOUNTPROC_UMNT) Reply Stat: MSG_ACCEPTED 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