---

Workshop: Verteilte Dateisysteme - Teil 1 (von Uwe Pannecke)

Der Amiga als NFS-Client und -Server
Teil 1 NFS-Client Amiga

Das der Amiga in einem Netzwerk eine durchaus brauchbares Mitglied sein kann, habe ich in diesem Magazin bereits mehrfach mit Beiträgen versucht, zu verdeutlichen. Auch in dieser Ausgabe soll ein weiteres Beispiel folgen. Ist Euer Amiga über einen TCP/IP-Stack mit einem oder mehreren Linux- Rechnern verbunden, bietet das von SUN Microsystems entwickelte 'Network File System, kurz NFS, eine elegante Möglichkeit, Dateien in diesem Netz zur Verfügung zu stellen. Dabei sind mindestens ein NFS-Server und ein NFS-Client beteiligt, wobei ein Rechner in solch einem 'Network File System' durchaus gleichzeitig sowohl als Server als auch Client auftreten kann. Der Dateizugriff über das NFS erfolgt völlig transparent. Ihr könnt auf die freigegebenen Laufwerke, Partitionen und Dateien der beteiligten Rechner zugreifen, als wären sie lokal auf dem jeweiligen Netzwerkrechner vorhanden.

So könnt Ihr etwa für Euren Amiga die Festplattenkapazität des Linux- Rechners anzapfen, indem Ihr ein Linux-Laufwerk oder -verzeichnis als Amiga-Partition mountet. Texte, Musikstücke und Bilder können auf nur einem Rechner vorgehalten und allen Netzwerkteilnehmern zentral zur Verfügung gestellt werden. Backups über NFS lassen den Datengau weniger dramatisch erscheinen. In diesem Szenario kann der Amiga neben einer passiven Rolle als Client auch die Aufgabe eines NFS-Servers übernehmen. Auf beide Aspekte soll nachfolgend eingegangen werden.

1. Systemvoraussetzungen

Neben dem/den Linux-Rechner(n) kann jeder Amiga mit einem TCP/IP-Stack Verwendung finden. Dabei spielt es keine Rolle, ob Miami, AmiTCP oder Genesis zum Einsatz kommen. Um eine angenehm hohe Zugriffsgeschwindigkeit zu realisieren, empfiehlt sich die Anbindung des Amiga ans Netzwerk über eine Ethernet-Karte. Aber prinzipiell funktioniert das Ganze auch über eine serielle oder parallele Nullmodem-Verbindung. Und demzufolge ist es ebenso möglich, nicht nur im LAN ein Network File System aufzusetzen, sondern das Internet als Basis für mittels NFS miteinander vernetzte Rechner zu nutzen. Ein Beispiel für letzteres ist der internetbasierte SuSE-NFS-Server, dessen Verzeichnisse Ihr auf Eurem heimischen Rechner mounten könnt.

Für diesen Workshop wurden ein Desktop-PC sowie ein Notebook mit jeweils SuSE 7.2 und ein Amiga 3000 mit der Ethernet-Karte XSurf und dem TCP/IP- Stack Miami aufeinander losgelassen.
2. NFS Client Amiga
2.1 Die Linux-Seite

Software und Dienste

Da der Linux-Rechner in diesem Fall als Server dienen soll, muss die passende Software installiert sein. Jede Linux-Distribution sollte die notwendigen Pakete mitliefern. Unter SuSE 7.2 findet Ihr selbige im Verzeichnis 'n' der Installations-CDs. Linux-Kernel ab Version 2.1 enthalten bereits NFS-Support. In diesem Fall ist unter SuSE zusätzlich das Paket 'nfs-utils' mittels YAST zu installieren.

Außerdem muss ein RPC (Remote Procedure Calls)-Portmapper gestartet werden. In YAST setzt Ihr die Variablen 'START_PORTMAP' und 'NFS_SERVER' auf 'yes' und schon passt YAST für Euch die Einträge in /etc/rc.config entsprechend an.

Freigabe von Laufwerken und Verzeichnissen

Jetzt ist es an der Zeit, die gewünschten Laufwerke bzw. Verzeichnisse auf dem NFS-Server freizugeben. Zu diesem Zweck ediert Ihr die Datei '/etc/exports' in einem beliebigen Editor. Für jedes zu exportierende Verzeichnis wird eine eigene Zeile angelegt. In dieser Zeile könnt Ihr die Rechner und ihre jeweiligen Berechtigungen für den Zugriff auf die freigegebenen Verzeichnisse festlegen. Dies schließt gleichzeitig auch alle Unterverzeichnisse mit ein.

Die Syntax der 'exports'-Datei folgt dem Schema

'freizugendes_Verzeichnis 

berechtigter_Rechner(Zugriffsrechte)'. 

Wir wollen das an eigigen Beispielen verdeutlichen. Nehmen wir an, das lokale Netzwerk der verwendeten Rechner liegt im Adressbereich 192.168.1.x und besitzt die Domain '.xwing.de'. Auf dem Linux-NFS-Server haben wir in der Datei 'etc/hosts' im Vorfeld die am Netzwerk beteiligten Rechner mit folgenden Einträgen festgelegt:

192.168.1.101 linux.xwing.de linux # Linux-Desktop
192.168.1.102 amiga.xwing.de amiga # Amiga 3000
192.168.1.103 bbs-linux-nb.xwing.de bbs-linux-nb # Notebook-Desktop

Auf eben diesem Linux-Rechner existieren die Verzeichnisse '/ablage', '/daten' und '/opt/texte'. Diese sollen exportiert werden. Alle am Netzwerk beteiligten Rechner sollen Lese- und Schreibrechte für das Verzeichnis '/ablage' bekommen, auf '/daten' soll das Linux-Notebook nur lesend, der Amiga jedoch lesend und schreibend zugreifen können. Das Verzeichnis '/opt/texte' wiederum soll lediglich dem Amiga und diesem nur mit Lese- rechten zur Verfügung stehen.

Die Datei '/etc/exports' könnte dann wie folgt aussehen:

# See exports(5) for a description.
# This file contains a list of all directories exported to other computers.
# It is used by rpc.nfsd and rpc.mountd.

/ablage 192.168.1.*(rw)
/daten bbs-linux-nb(ro) amiga(rw)
/opt/texte amiga.xwing.de(ro)

Wie Ihr sicherlich bemerkt habt, ist sowohl der Rechnername, der Rechnername einschließlich Domain oder die IP-Nummer als Angabe zur Identifikation möglich. Als Jokerzeichen sind '*' und '?' einsetzbar. So ermöglicht die IP-ID-Eingabe 192.168.1.* allen im Adressbereich 192.168.1.0 bis 192.168.1.255 befindlichen Rechnern den Zugriff.

Das Dateisystem wird durch 'rw' mit Schreib- und Leserechten, durch 'ro' nur mit Leserechten exportiert. Weitere Berechtigungen sind möglich, sollen aber an dieser Stelle ausgelassen werden. Bei Interesse klärt Euch ein 'man exports' über Einzelheiten auf.

Habt Ihr alle gewünschten Änderungen an 'etc/exports' vorgenommen, startet Ihr den NFS-Daemon mit 'rcnfsserver restart' neu.

Testphase

Testet anschließend als 'root' oder 'su' mit der Shell-Eingabe 'rpcinfo - p', ob Portmapper, NFS-Daemon und mountd auch wirklich laufen.

Ob die Verzeichnisse tatsächlich entsprechend unserer Vorgaben exportiert wurden, verrät ein anschließendes 'exportfs'.

Damit ist die Linux-Server-Konfiguration abgeschlossen. Wir wechseln die Tastatur und wenden uns dem Amiga zu.
2.2 Die Amiga-Seite

AmiTCP und Genesis

Alle diejenigen, die AmiTCP oder Genesis installiert haben, besitzen bereits alle notwendigen Voraussetzungen für das NFS-Clienten-Daseins ihres Amigas. Im '/bin'-Verzeichnis beider Programmpakete finden sich die für den NFS-Client-Einsatz benötigten Programme. Sie wurden von Carsten Heyl erstellt und tragen wohl auch deshalb als Namensbeginn ein 'ch_' (übrigens erwies sich Carsten Heyl in Vorbereitung dieses Workshops als sehr hilfsbereiter und netter Kommunikationspartner).

Die für das Einbinden der gewünschten Laufwerke entscheidende Konfigurationsdatei 'ch_nfstab' befindet in 'AmiTCP:db'.

Miami

Miami-Anhänger müssen zuvor ein wenig mehr Aufwand betreiben, da ihr TCP/IP-Stack ohne integrierte NFS-Unterstützung daherkommt. Dies stellt aber kein wirkliches Problem dar. In den Demoversionen von AmiTCP [1] und Genesis [2] sind die bereits genannten Programme ebenso enthalten und können ohne weiteres gemeinsam mit Miami genutzt werden. Um die Ähnlichkeit zur AmiTCP/Genesis-Installation herzustellen, könnt Ihr im Miami- Verzeichnis eine '/bin'-Schublade erstellen und alle mit 'ch_' beginnenden Programme aus dem 'AmiTCP:bin'-Verzeichnis dorthin kopieren. Dann muss aber dieses neu erstellt 'Bin'-Verzeichnis dem Suchpfad hinzugefügt werden. Oder Ihr kopiert die genannten Programme einfach nach 'Sys:C'. Die Datei 'db/ch_nfstab' kann wiederum in ein zuvor erstelltes Verzeichnis 'Miami:db' oder z.B. nach "Devs:", dem Amiga-eigenen Mountlist-Verzeichnis, transferiert werden.

Konfiguration

Dem NFS-Clienten 'ch_nfsc' muss mit seinem Start natürlich auch mitgeteilt werden, welche Laufwerke oder Verzeichnisse in das Amiga-Dateisystem einzubinden sind. Diese Aufgabe übernimmt die bereits genannte Datei 'ch_nfstab'. Selbige laden wir deshalb in einen Texteditor und passen den Inhalt unseren Bedürfnissen an. Die Syntax der Einträge folgt dem Schema

NFS-Server:/export_Verzeichnis import_Verzeichnis: USER user_name UMASK XXX

Für die Angabe des NFS-Servers sind sowohl die IP-ID als auch der Rechnername möglich.

User-ID (UID) und Group-ID (GID)

Mit dem Parameter 'USER user_name' kann dem NFS-Server jeder im TCP/IP- Stack angemeldete User untergeschoben werden. Besitzt ein Linux-User etwa bestimmte Dateirechte auf dem zu exportierenden Laufwerk/Verzeichnis, kann in der Standardeinstellung des NFS-Servers nur ein Client-User mit gleicher UID/GID diese Dateirechte erlangen. (Serverseitig lässt sich über den Parameter 'map_identity' in '/etc/exports' dieses Verhalten ebenso beeinflussen.) Sind User- sowie Group-ID der Linux-Seite bekannt, kann ich diesen User mit passender UID/GID im Amiga-TCP/IP-Stack anlegen und mit dem User-Parameter in 'ch_nfstab' die gleichen Dateirechte im importierten Laufwerk/Verzeichnis erhalten.

Da in unserem Workshop alle Dateien im Linux-Verzeichnis '/daten' dem User 'uwep' mit der UID 500 gehören, und dieser User zur Gruppe 'users' mit der GID 100 angehört, legen wir einen solchen User auch in unserem TCP/IP-Stack an. Nachfolgend ein Beispiel für Miami, sinngemäß ebenso in AmiTCP bzw. Genesis.

Dateirechte

Mit dem Parameter 'UMASK XXX' könnt Ihr jeder Datei, die im importierten Verzeichnis von Euch erzeugt/angelegt wird, bestimmte Datei-Rechte mit auf den Weg geben.

So könnt Ihr in der dreistelligen Ziffernmaske die Rechte für User (also Eigner der Datei), Gruppe und Sonstige festlegen. Im Gegensatz zu 'chmod' ist die Bedeutung der Bits jedoch genau umgekehrt. Die Rechte (4 für Lesen, 2 für Schreiben und 1 für Ausführen) sind von für die einzelne Ziffernstelle von 7 zu subtrahieren.

Ein kurzes Beispiel: der User (Eigner) der Datei soll alle Rechte besitzen, die Gruppe dagegen nur Lese- und Ausführberechtigung (z.B. für ein Programm) und Sonstige sollen gar keinen Zugriff erhalten. Dies ergäbe dann UMASK '027'.

Konfigurationsbeispiel der 'ch_nfstab'

Auf dem NFS-Server mit der IP-ID 192.168.1.101 und dem Rechner/Domainnamen 'linux.xwing.de' haben wir das Verzeichnis '/daten' für den Amiga mit Schreib- und Leserechten freigegeben. Die Dateien in diesem Verzeichnis gehören dem Linux-User 'uwep', das Verzeichnis soll auf dem Amiga als 'LinuxDaten:' gemountet werden. Somit erstellen wir in der 'ch_nfstab' den nachfolgenden Eintrag:

linux.xwing.de:/daten LinuxDaten: USER uwep

Alle in dem vom NFS-Server exportierten Verzeichnis '/ablage' zu erstellenden Dateien sollen alle Dateirechte für den User 'uwep' aufweisen, die Gruppe und Sonstige sollen lediglich Lese- und Ausführrechte erhalten. Das Verzeichnis soll als 'Ablage' importiert werden. Der Eintrag lautet:

linux.xwing.de:/ablage Ablage: USER uwep UMASK 022

Die so präparierte Datei 'ch_nfstab' in unserem Fall nach 'Miami:db/' kopiert. In der Shell sorgt nun die Eingabe von

'ch_nfsmount LinuxDaten: from Miami:db/ch_nfstab USER uwep'

augenblicklich für ein 'neues' Laufwerk 'LinuxDaten' auf dem Amiga.

Analog kann nach

'ch_nfsmount Ablage: from Miami:db/ch_nfstab USER uwep'

auf das neue Verzeichnis 'Ablage' zugegriffen werden.

Um das Mounten der Verzeichnisse bequem über die Workbench per Mausklick zu ermöglichen, könnt Ihr den Befehl 'ch_nfsmount xxx' auch als Datei abspeichern, mit einem Projekt-Icon versehen und als dessen Standardwerkzeug 'IconX' eingetragen.

Die auf dem Amiga gemounteten Verzeichnisse lassen sich jederzeit mit dem Befehl 'ch_die Verzeichnisname:' aus dem Amiga-Dateisystem aushängen.

Ausblick

Im nächsten Monat wird im 2. Teil des NFS-Workshops der Amiga als NFS- Server konfiguriert. Bis dahin viel Spaß beim Einsatz des NFS-Clienten Amiga.

[1] ftp://de.aminet.net/pub/aminet/comm/tcp ... emo-40.lha
[2] ftp://de.aminet.net/pub/aminet/comm/tcp/gendemo104.lha


Uwe Pannecke

Workshop: Verteilte Dateisysteme - Teil 2 (von Uwe Pannecke)

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.

1. NFS Daemon

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.

1.1 Installation

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.

1.2 Konfiguration

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.

2. TCP/IP-Stack

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.

2.1 Miami

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.

3. Der Deamon

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.

4. Die Linux-Seite

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.

5. Fazit

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.html
[2] http://www.oreilly.de/german/freebooks/ ... egIVZ.html
[3] ftp://de.aminet.net/pub/aminet/comm/tcp/Miamixxx.lha
[4] ftp://de.aminet.net/pub/aminet/comm/tcp ... emo-40.lha
[5] ftp://de.aminet.net/pub/aminet/comm/tcp/gendemo104.lha

Uwe Pannecke