Workshops
|
Workshops
|
|
Der Amiga als NFS-Client und -Server
Teil 2 - NFS-Server Amiga
Das ursprünglich von SUN Microsystems entwickelte Network File System (rfc 1094), kurz auch als NFS bezeichnet, erlaubt mehreren Rechnern, Ressourcen zusammen- zufassen und gemeinsam über ein TCP/IP-Netzwerk zu nutzen. Mit installiertem NFS wird es so möglich, von beliebiger Stelle des Netzes auf installierte Programme zuzugreifen oder für alle beteiligten Rechner erreichbar an zentraler Stelle Datenbestände wie Dokumentationen, Bildersammlungen, Lexika u.ä. abzulegen. In der Unix/Linux-Welt ist das NFS ein gängiges Verfahren, um Verzeichnisse entfernter Rechner in den lokalen Verzeichnisbaum einzubinden und selbige so benutzen zu können, als wären sie auf dem eigenen Rechner vorhanden.
Nachdem im ersten Teil des Workshops der Amiga als Client in ein Network File System integriert wurde, soll diesmal der Amiga seine Festplatten- Ressourcen zur Verfügung stellen.
Um dem Amiga die Möglichkeit zu geben, Verzeichnisse anderen Netzwerk- Teilnehmern bereitzustellen, muss ein NFS-Server her. Vor diesem Problem stand auch Joseph Walton, der seinen Amiga mit einem PC gekoppelt hatte und mit seinem Amiga-NFS-Clienten leider nur in einer Richtung problemlos Daten transferieren konnte. Da keine Abhilfe in Sicht war, griff er zu DiceC und dem MiamiSDK und programmierte kurz entschlossen einen Amiga-NFS- Server. Er nannte ihn schlicht "nfsd" und stellte ihn freundlicherweise unter die GPL und damit allen interessierten Usern auf seiner Homepage [1] kostenlos als Binary und Source zur Verfügung. Klasse.
Zum Testzeitraum war die Version vom 14. Oktober 2000 verfügbar und mit einem Umfang von knapp 20 KByte als LZX-Archiv in wenigen Augenblicken herunter geladen. Neben dem eigentlichen Daemon "nfsd" enthält das Paket im "nfsd"-Verzeichnis eine Readme-Datei sowie eine Beispielkonfiguration und "nfsd.inode". Das komplette Verzeichnis könnt Ihr an einen beliebigen Platz kopieren. Einzige Bedingung ist eine Schreibberechtigung für dieses Verzeichnis.
Da in unserem Fall "nfsd" gemeinsam mit Miami verwendet werden soll, habe ich die Schublade kurzerhand ins Miami-Verzeichnis verfrachtet.
Entscheidend für eine erfolgreiche Freigabe von Laufwerken und/oder Verzeichnissen ist die Datei "nfsd.config". Selbige könnt Ihr in einem beliebigen Editor Euren Erfordernissen anpassen. Die Einträge folgen einem einheitlichen Schema: Das lokale Laufwerk bzw. Verzeichnis mit komplettem Pfad folgt der Name, unter dem dieses Laufwerk/Verzeichnis exportiert werden soll. Dem schließt sich eine Definition der zugriffsberechtigten IP-IDs sowie Attributen zu User-ID und Gruppen-ID mit den gewünschten Zugriffs-Rechten. Konstruieren wir zur Veranschaulichung einige Beispiele:
A)
Das lokale Verzeichnis "Work2:maildaten/" wird als Verzeichnis "/amiga"
exportiert werden. Auf dieses Verzeichnis darf lediglich der Rechner mit
der IP-ID 192.168.1.101 Zugriff erhalten. Eigner soll der User mit der ID
500 sein, dieser User gehört zur Gruppe mit der ID 100. Es werden Rechte
zum Lesen, Schreiben und Ausführen der Daten im Verzeichnis für Eigner,
Gruppe und Sonstige vergeben. Der passende Eintrag lautet
Work2:Maildaten /amiga 192.168.1.101 RW UID=500 GID=100 PERM=777 FORCEALL
B)
Das Verzeichnis "Ram:" soll als "/amigaram" für alle Rechner des lokalen
Netzwerkes (hier alle Rechner mit einer IP-ID 192.168.1.x) exportiert
werden. Die Dateien sollen "root" gehören und nur mit Leserechten versehen
sein. Der passende Eintrag lautet diesmal
Ram: /amigaram 192.168.1.0/255.255.255.0 UID=0 GID=0 PERM=444 FORCEALL
C)
Die Festplatte "Work:" soll mit Lese- und Ausführungsrechten als
Verzeichnis "/daten" freigegeben und allen Rechnern unabhängig von ihrer
IP-ID zugänglich sein. Die Daten gehören dem User mit der ID 600. Die
zugehörige Gruppen-ID ist 200.
Work: /daten - UID=600 GID=200 PERM=555 FORCEALL
Für einen detaillierten Einstieg zur Vergabe der Dateirechte auf Unix/Linux- Systemen sei an dieser Stelle auf das im O'Reilly Verlag bereits in dritter Auflage veröffentlichte und auch online verfügbare [2] Buch "Linux - Wegweiser zur Installation & Konfiguration" von M. Welsh, M. Dalheimer und L. Kaufmann verwiesen.
Speichert abschließend die Euren Wünschen entsprechend geänderte Konfiguration unter einem aussagekräftigen Namen ab.
Hier habt Ihr die Qual der Wahl. Neben AmiTCP und Genesis ist gleichermaßen auch Miami geeignet. Da bei Miami etwas mehr Aufwand zu treiben ist, soll an dieser Stelle für die Konfiguration eben jener TCP/IP-Stack [3] als Beispiel dienen. Sinngemäß lassen sich die Aussagen auch auf die beiden anderen Vertreter übertragen.
Ist Miami gestartet, solltet Ihr überprüfen, ob unter "Datenbank/Dienste" die Einträge
Name ID Protokoll sunrpc 111 tcp sunrpc 111 udp
vorhanden sind und gegebenenfalls ergänzen.
Da "nfsd" ein RPC-Dienst ist, benötigt der Server zwingend einen laufenden Portmapper. In der Miami-Distribution werdet Ihr einen solchen Portmapper jedoch vergeblich suchen. Doch keine Panik- auch hier können die Kontrahenten AmiTCP bzw. Genesis aushelfen. Bereits in den Demoversionen [4] und [5] ist im Verzeichnis "BIN:" mit "portmap" das passende Programm enthalten. Kopiert dieses z.B. in das C-Verzeichnis. In einer Shell könnt Ihr dann den Portmapper, nachdem Miami auf "Online" gesetzt ist, durch Eingabe von "portmap" starten. Ob der Portmapper auch wirklich aktiv ist, verrät das Tool "rpcinfo", welches ebenso wie "portmap" im "BIN:"- Verzeichnis von AmiTCP bzw. Genesis zu finden ist. Tauchen in der "rpcinfo"-Ausgabe der Port 111 und die Protokolle tcp und udp auf, war der Start erfolgreich.
Jetzt kann der NFS-Server endlich zum Zug kommen. Bei seinem Aufruf übergeben wir ihm die zu verwendende Konfigurationsdatei.
Ist alles nach Plan gelaufen, teilt uns "nfsd" seinen aktiven Zustand mit der Shell-Ausgabe "Serving." mit. Zusätzlich können wir seine Arbeitsbereitschaft mit erneutem Aufruf von "rpcinfo" überprüfen.
Ich gehe davon aus, dass wie im ersten Teil beschrieben, die NFS- Unterstützung der jeweiligen Linux-Distribution bereits installiert ist. Somit bleiben für die Einbindung der freigegebenen Amiga- Laufwerke/Verzeichnisse nur noch wenige Handgriffe. Unter Linux setzt man zu mountende Geräte und damit auch Laufwerke sowie Verzeichnisse auf ein im Linux-Dateisystem vorhandenes Verzeichnis, dem Mountpoint, auf. Entweder Ihr erstellt ein gewünschtes Verzeichnis zu diesem Zweck oder aber Ihr benutzt das auf den meisten Systemen zu findende "/mnt"- Verzeichnis. Der eigentliche Mount-Befehl besitzt folgendes Format:
mount -t typ gerät mount-point
Konstruieren wir wieder zwei konkrete Beispiele:
A)
Für das freigegebene Amiga-Verzeichnis soll im Wurzelverzeichnis eine
eigene Schublade mit dem Namen "amiga" erstellt werden. Dies gelingt in
einer Shell im Handumdrehen und als Superuser mit der Kommandofolge "mkdir
/amigadaten". Nun kann das auf dem Amiga als "/amiga" freigegebene
Verzeichnis "Work2:Maildaten" (wiederum als Superuser) mit Hilfe der
Eingabe
mount -t nfs 192.168.1.102:/amiga /amigadaten
in das lokale Dateisystem eingehängt werden. Ab sofort könnt Ihr nun von Linux aus auf das Amiga-Verzeichnis mit den fest- gelegten Rechten zugreifen.
B)
Soll die weiter oben als "/amigaram" freigegebene RAM-Disk unter "/mnt"
ein- gebunden werden, sorgt der Befehl
mount -t nfs 192.168.1.102:/amigaram /mnt
für das gewünschte Ergebnis.
Wollt Ihr nicht nur als "root" oder "su", sondern auch als normaler Benutzer den Befehl "mount" ausführen, solltet Ihr den betreffenden Gerätenamen für das Amiga-Verzeichnis mit einem entsprechenden Eintrag in der Datei "/etc/fstab" auflisten.
Wenn man sich erst einmal mit dem für Amiga-Verhältnisse ungewöhnlichen Aspekten von Eigentümerschaft und Gruppenzugehörigkeit der Dateien auf dem einzubindenden Dateisystem vertraut gemacht hat, bietet das Network File System auch dem Amiga eine transparente und zugleich elegante Möglichkeit, Dateien netzwerkweit verfügbar zu machen.
[1] http://www.pr0n.freeserve.co.uk/nfsd.htmlUwe Pannecke <Uwe.Pannecke@t-online.de>
