![[Amiga]](images/_amiga.gif){kind=small}
![[Down]](images/_krumm_lo.gif){kind=small}
![[Scene]](images/_scene.gif){kind=small}
![[Workshop]](images/_workshop_.gif){kind=small}
| | Diskarchive | REXX | TCP/IP: Die Exoten | |
![[Cover]](images/_cover.gif){kind=small}
![[Editorial]](images/_editorial.gif){kind=small}
![[Inhalt]](images/_inhalt.gif){kind=small}
![[News]](images/_news.gif){kind=small}
![[Hardware]](images/_hardware.gif){kind=small}
![[Software]](images/_software.gif){kind=small}
![[Workshop]](images/_workshop.gif){kind=small}
![[Spiele]](images/_spiele.gif){kind=small}
![[Special]](images/_special.gif){kind=small}
![[Feedback]](images/_feedback.gif){kind=small}
![[Etc]](images/_etc.gif){kind=small}
TCP/IP: Die Exoten - DNS, Envoy, Samba, NFS (Teil 5)
Nachdem nun so einigermassen geklärt sein sollte, wie man die grundlegenden Netzkonfigurationen vornimmt, soll hier nun auf die Interessantheiten Bezug genommen werden, die nicht mehr ganz so offensichtlich sind.
DNS
Der DNS, das für Domain Name Service steht, ist dafür zuständig, das nicht immer die kryptischen IP-Adressen eingegeben werden müssen, um auf andere Rechner zu gelangen, sondern mit mehr oder weniger sinnvollen Namen gearbeitet werden kann. Dabei ist die Ordnung, nach der ein Name gesucht wird, hierarchisch aufsteigend vom lokalen File, in dem nachgeschaut wird, zum ersten DNS (hier: Domain Name Server), weiter zum Darüberstehenden usw, bis sich ein Name findet.
Die lokale Instanz bildet dabei das File AmiTCP:db/hosts, bzw. die entsprechende Seite im Genesis, die gleich aufgebaut ist. Auch beim Miami und beim I-Net 225 ist die Struktur die Gleiche. Dieses File weist IP-Adressen nun Namen und Aliases zu, nach denen ein Rechner identifiziert werden kann. Eine Zeile referenziert dabei einen Rechner. Als erstes steht immer die IP-Adresse, dahinter, durch Leerzeichen getrennt, folgen die Namen unter der der Rechner erreichbar ist. Die Reihenfolge der Namen ist dabei irrelevant, unter jedem ist der Rechner erreichbar. Mögliche Einträge kann man sich so vorstellen:
|
127.0.0.1 localhost ; 192.168.1.1 a2000.rockus.at a2000 192.168.1.2 a4000.rockus.at a4000 ; 192.168.1.11 dn5500.rockus.at dn5500 tiger 192.168.1.12 dn3500.rockus.at dn3500 puma ; 192.168.1.21 next.rockus.at next |
Damit ist der Rechner an der IP-Adresse 192.168.1.11 zum Beispiel unter drei Namen erreichbar, ohne daß es einen Unterschied machen würde, unter welchem Namen ihn man jetzt wirklich anspricht, da im Endeffekt wieder nur die IP-Adressen zum Einsatz kommen.
Wird ein Name im hosts-File nicht gefunden, so wird der primäre Nameserver gefragt, ob er denn was weiß. Unter welcher IP-Adresse der nun erreichbar ist, muß im AmiTCP:db/resolv.conf, bzw. wieder den entpsrechenden Files bei den anderen Stacks, eingetragen werden. Der Eintrag erfolgt dabei wieder zeilenweise: an erster Stelle das Wort NAMESERVER, dahinter, durch ein oder mehrere Leerzeichen getrennt, die entsprechende IP-Adresse. Das kann dann zum Beispiel so aussehen:
|
; Name servers NAMESERVER 195.34.133.10 NAMESERVER 129.27.2.3 NAMESERVER 195.34.133.11 NAMESERVER 129.27.3.3 |
Daß hier vier Server angegeben sind, ist nicht wirklich relevant, da einerseits AmiTCP ohnehin nur die ersten drei verwendet. Der Sinn dahinter ist aber, stes die Chance zu haben, einen Nameserver finden zu können, sollte der erste, oder gar mal zwei davon ausfallen.
Weiß dieser gefragte Server auch nicht weiter, fragt er einen weiteren Server, und der wieder und wieder und wieder, aber das braucht den Benützer am Ende der Schlange ncht zu kümmern, das merkt er nicht mehr.
Will man nachschauen, was ein Nameserver so alles weiß, gibt es schöne kleine Tools dafüer, wie zum Beispiel askhost, das zu Namen die Adressen, aber auch zu Adressen die Namen liefern kann. Eine mögliche Ausgabe kann dann so aussehen:
|
13.Work:> askhhost puma host: dn3500.rockus.at addrtype: 2 length: 4 aliases: dn3500 puma address list: 192.168.1.12 13.Work:> |
Daraus ist auch ersichtlich, daß ein Name mehreren Rechnern zugeordnet sein kann, was aber wieder eigene Verwaltung benötigt, auf die hier nicht genauer eingegangen werden soll. Als Beispiel soll askhost sbox.tu-graz.ac.at genügen.
Eine richtige Funktionalität bieten die Namen indes nicht, sie sind einfach dazu da, um leichter merkbare Zeichenketten zu bieten. Mit den IP-Adressen kommt man aber genausoweit, selbst WebBrowser können mit diesen Ziffern was anfangen. Somit kommt man auch dann noch weiter, wenn einmal wirklich kein Nameserver erreichbar sein sollte.
Envoy
Das Hauptargument, um überhaupt Netzwerke zwischen Computern zu bauen, dürfte der Datenaustausch sein. Dafür gibt es das kleine unscheinbare FTP plus zugehöriger Daemons, die die Anfragen abwickeln. Komfortabel ist das aber nicht.
Die wohl einfachste Möglichkeit, unter Amigas Daten auszutauschen, besteht im kommerziellen Envoy (dessen brandneue Version 3 in der nöchsten Ausgabe unter die Lupe genommen werden wird). Damit können Verzeichnisse, somit komplette Festplatten, oder auch nur Assigns in das Netz exportiert werden und andere Amigas können dieses dann wieder bei sich einbinden.
Auf deren Workbench erscheint dann das Laufwerks-Icon so, als ob es ein lokales Laufwerk wäre. Sogar diverse .backdrop-Files werden berücksichtigt, sodaß ausgelagerte Icons auch auf dem Amiga ausgelagert werden, auf dem dieses Device importiert wird. In der neuen Version 3 werden auch Wechselmedien, wie CD-Laufwerke unterstützt. Nimmt man die CD aus dem Laufwerk, verschwindet das entsprechende Icon auch von der Workbench aller Amigas, die dieses CD-Laufwerk importiert haben. Sehr praktisch.
Ein rudimentäres Sicherheits-System ist auch enthalten, das aber abschaltbar ist, sodaß man sich im kleinen Netz zuhause nicht um diverse Zugriffsrechte kümmern muß, wenn man nicht will.
Das Schöne am Envoy ist, daß auch Drucker ex- und importierbar sind. Das ist umso erstaunlicher, als diese Möglichkeit im AmigaOS schon viel weniger leicht unterzurbingen ist, als irgendwo irgendwelche Devices zu mounten. Primär durch Ersetzen, bzw. Patchen des parallel.devices und des printer.devices ist dies aber möglich, solange nicht irgendein absonderliches Programm in der Hardware herumpfuscht.
Die Konfiguration ist einfach über eine simple, aber funktionale Oberfläche möglich und der modulare Aufbau scheint auch die Einbindung weiterer Services zu ermöglichen. Derzeit gibt es ein printspool.service und ein filesystem.service, was will man da denn eigentlich noch?
Mit Envoy wird es auch möglich sein, komplexere Netzwerke über mehrere Segmente und verschiedene Realms (wo nicht jeder alle sieht, sondern nur die im gleichen Realm zugeordneten Rechner) zu realisieren, auch wenn in der Doku davon eher abgeraten wird, da der Support dafür nicht gewährleistet werden könne.
Samba
Envoy ist zwar gut und schön, aber damit kann man eben nur Amigas vernetzen, das dafür aber mit ungeahntem Komfort und Funktionalität. Will man sich aber auch nicht zur PC-Welt (und auch unixoiden Systemen) abgrenzen, so fällt das Auge auf das (unixoid) komplexe Samba, für das es auch einen Port für den Amiga gibt und die Möglichkeit bietet, vom Amiga aus Devices (Partitionen, Verzeichnisse, etc.) und Drucker ins Netz zu exportieren, die ein Windows (sei es nun ein 3.11 oder auch NT - egal) einfach in der "Netzwerkumgebung" erkennen kann und einfach gemountet werden können.
So wird hier schon seit längeren von den PCs im Netz auf einem Drucker am Amiga gedruckt. Was hier abgeht, ist die Spool-fähigkeit. Das hei0t, wenn gerade ein Druckjob in Arbeit ist, wird ein zweiter einfach nicht angenommen, ohne dass der PC-User was davon merkt, da die Daten einwandfrei zum Amiga geschickt werden konnten. Um diesem Mißstand abzuhelfen, gibt es SambaPM, das auf der Amiga-Seite einen einfach zu bedienenden Druckerspooler nachbildet. Das Paket ist zwar noch in einem frühen Entwicklungsstadium, dessen Funktionalität aber schon für einen großräumigen Einsatz ausreicht. Wenn genügend Leute den lieben Jürgen treten, wird er schon dran weiterbauen :-))
Die Konfiguration von Samba ist bei Weitem nicht so elegant wie bei Envoy, aber warum auch, ist ja ein Unix-Tool. Im File Samba:lib/smb.conf findet alles statt, was man so verkonfigurieren kann. Die Grundstruktur besteht aus diversen Teilen, der erste ([global]) bestimmt, was für alle folgenden Teile gilt. Jeder dieser folgenden Teile exportiert ein Device oder einen Drucker ins Netz, auf daß die PCs ihre Fänge danach auswerfen, aber meistens tappen sie eh im Dunkeln, wenn's ums Netzwerk geht...
Die Dokumenation zu Samba ist soweit vollständig, daß die einzelnen Punkte ausreichend genau, aber halt auf englisch, darinnen beschrieben sind. Zur Konfiguration selber ist allerdings wichtig, daß der os-level angepaßt wird. Es hilfts nichts, wenn der ganze Rest paßt. Ein Windows-NT wird bei einem OS-Level-Wert unter 32 einfach nichts finden wollen.
Ganz praktisch ist auch, wenn man preferred-master auf yes stellt, da dadurch auf PC-Seite durch die freigegebenen Shares (das Sammelwort für Devices und Drucker) geblättert werden kann. Weiters läßt sicher der workgroup-String nicht einfach so verändern, er muß auf allen Rechnern der Gleiche sein, sonst sind diverse Shares nur schwer zu finden. In den neueren Windows-Generationen kann man über die sogenannte Netzwerkumgebung ja auch durch verschiedene Workgroups durchwandern und so eine gewisse Einteilung und Strukturierung erreichen. Das Konzept ist den Realms von Envoy nicht unähnlich.
Am Einfachsten um Probleme mit rechten und Benutzern kommt man herum, wenn man überall valid users = guest angibt. Dafür muß im [global] dann auch guest account = yes gesetzt sein. Funktioniert so einmal alles, kann man sich immer noch um Zugriffsrechte kümmern.
In Zeiten, in der ein Windows nur 8.3-Filenamen beherrschte, war das sogenannte Name-Mangling unumgänglich, wenn es um Filetransfer zwischen unixoiden Systemen und dem PC geggangen ist. Das Thema ist ja glücklicherweise mehr oder minder vom Tisch (über diverse Altlasten mag ich mich jetz nicht aufregen), aber Samba kommt auch damit klar, indem man im globalen Teil das mangled names auf yes setzt. Damit erscheinen zu lange Dateinamen so abgekürzt, daß auch ähnliche noch als eindeutig erkannt werden können. Der Nachteil davon ist, daß oft nur mehr der "DateiManager" vom 3.11er auf die Dateien zugreifen kann, sie aber nicht mehr direkt geladen werden können. Dieses problem tritt aber nur eher selten auf, allerdings habe ich einen hartnäckigen Fall, in dem ich dieses Verhalten nicht wegbekommen kann.
Ist ein Share browseable (oder auch browsable), so erscheint es im Windows in den Listen zum Anklicken. Der path gibt mitunter noch Rätsel auf, da er in Unix-Konvention angegeben werden muß. Aus einem "Work:" wird als ein "/Work/", ein "Spool1:Docs" zu "Spool1/Docs/", usw.
Zum Exportieren von Druckern wird ebenfalls so eine Abteilung eingefügt, die mit einer in eckige Klammern gefaßten Bezeichunng begonnen wird. Hier sind aber die mitgelieferten Dokumentationen nur mehr sehr dünn gesät, deshalb hier eine Beispielkonfiguration aus meinem (funktionierendem) Skript:
|
; Epson Styus Color printer [Stylus] comment = Epson Stylus Color valid users = guest path = /T/spool/ print command = sh -c "echo %T Printing %s >>/AmiTCP/samba/log/print.log.stylus; /sys/c/copy T:Spool/%f par: >>/AmiTCP/samba/log/print.log.stylus; /sys/c/delete T:Spool/%f >>/AmiTCP/samba/log/print.log.stylus" writable = yes public = yes browsable = yes create mode = 0700 sps device = par: sps enable = yes |
Unter dem String in den eckigen Klammern taucht dieser Drucker in den Windows-Rechnern auf, auf denen muß natürlich ein passender Treiber installiert sein, da die Daten, die übers Netz kommen, direkt zum Drucker geschickt werden. Der comment erscheint auch auf der PC-Seite als Kommentar. valid users gibt an, wer diesen Drucker verwenden darf. In diesem Falle hier alle. Der path zeigt, wo die Daten zwischengespeichert werden sollen. Bei print command wird es interessant, denn das ist zustäädnig dafür, daß überhaupt was aus dem Drucker kommt. Samba legt nur die Daten im angegebenen Spool-VErzeichnis ab und ruft die Zeile nach print command auf. Was dann passiert, ist dem Samba egal.
Hat man hier die GNU-Utilities, ist man gut dran, denn ohn einer sh geht dahier gar nichts. Ich habe das Kommando hier ein wenig ausgebaut, um auch diverse LogFiles füllen zu können, was nicht unbedingt nötig ist. Nach dem Drucken wird das File auch wieder gelöscht.
Die letzten beiden Zeilen (sps device und sps enable) sind für den SambaPM notwendig. Wird dieser eingesetzt, so muß das print command durch ein vorangestelltes Komma auskommentiert werden, da ansonsten der PrintManager nicht auf die Files zugreifen kann und einfach nichts tut.
Die umgekehrte Richtung, der Import von auf PCs freigegebenen Laufwerken, war lange Zeit nicht möglich. Mit dem SMB-Handler, derzeit v0.12 im Umlauf, ist aber genau das auch möglich. Passt man die Beispiel-MountIcons an die eigenen Bedürfnisse an, was sich auf ein Ausbessern des Rechner- und Freigabe-namens beschränkt, so kann man auf einmal per Doppelklick die PC-Platten am Amiga besichtigen. Praktische Sache.
Noch praktischer wird das, wenn man Samba als netzweites System einsetzt. PCs unter Windows können damit sowieso in beiden Richtungen umgehen, ein Amiga ja nun auch, und da die ganze Sache aus der Unix-Welt stammt, können "die" auch in einem Samba-Netz mitmischen. So sind in äußerst freizügiger Weise quer über Systemgrenzen hinweg die Datenträger einfach austauschbar. Irgendwer sollte nun dafür nur noch eine brauchbare GUI bauen, damit man Samba auch dem nicht so erfahrendem User beibringen kann.
Derzeit aktuell ist die Version 1.9.17p4 von Samba. V2.0.0alpha ist ebenfalls verfügbar, aber für Systeme, die sicher funktionieren sollen, wohl nicht anzuraten. Der SMB-Handler ist in Version 0.12 verfügbar, aber so weit gediegen, daß er problemlos verwendet werden kann. Weiters gibt es eine Samba-Mailingliste, die unter rask@kampsax.dtu.dk erreichbar ist.
NFS
Ein anderes Konzept verfolgt NFS, das für Network File System steht. Auch hier wird im Grunde nichts anderes gemacht, als Devices ins Netz zu exportieren, um sie woanders wieder importieren zu können. Für den Amiga gibt es zwar NFS-Clients, mit denen es möglich ist, von UNIX-Rechnern exportierte Devices zu importieren, aber es gibt keinen NFS-Server, der frei verfügbar wäre. Einzig bei I-Net 225 ist einer dabei, und der kostet was.
Das Importieren hat auch wieder zum Ziel, daß schlußendlich ein Icon mit dem entsprechenden Device dahinter auf der Workbench auftaucht. Dazu ist es notwendig, das File AmiTCP:db/ch_nfstab anzupassen, damit die Devices auch gemountet werden können. Nhemen wir mal an, auf einem NeXT wäre das Root-Verzeichnis freigegeben, dann müßte der Eintrag im File ungefähr so aussehen:
|
next.rockus.at:/ NeXT: USER root |
Zuerst der Rechnername, wie immer. Nach dem Doppelpunkt folgt der Pfad zum freigegebenem Teil. NeXT: steht an der Stelle, die festlegt, wie das importierte Device auf der Amiga-Seite heißen soll, und zu guter Letzt wird dem armen NeXT auch noch der root als User vorgespiegelt, damit er bei der Freigabe nicht zum Motschgern anfängt.
Gemountet wird dieses Device durch ch_nfsmount NeXT:. Kurze Zeit danach sollte das entsprechende Icon am Screen erscheinen und ist im root-Verzeichnis dieses Devices aus welchen Gründen auch immer ein Disk.info zu finden, so gibt's auch andere Icons und fixierte Positionen auf der Amiga-Seite. Mit ch_die NeXT läßt sich das Device wieder unmounten und im Idealfall verschwindet auch das Icon nach einiger Zeit wieder.
netfs
Stöbert man ein wenig in den Konfigurationsfiles von AmiTCP herum, so stößt man irgendwann auf den netfs-Eintrag in AmiTCP:db/services, wo unter "Amiga specific services" ein amiganetfs auf Port 2500 angepriesen wird.
In der inetd.conf findet man auch einen dazupassenden Eintrag, dem man nur das vorangestellte "#" wegnehmen muß, damit er "funktionsfähig" wird. Selbst ein AmiTCP:serv/netfs-server existiert. Und im doc-Verzeichnis von AmiTCP kann man die dazugehörige Anleitung finden.
Dieses Service ist zwar ausdrücklich nicht NFS-kompatibel, aber es lassen sich damit über Mountfile-Einträge und Shell-Befehle zwischen Amigas verschiedene Devices mounten und gegenseitig abspenstig machen.
Ob der nicht vorhandenen Oberfläche ist das sehr rudiementär, aber es funktioniert und erfüllt seinen Zweck. Ein Envoy, daß ja nun auch nicht die Welt kostet, allerdings nur für jeweils zwei Rechner lizenziert ist, bringt da schon erheblich mehr Komfort und Funktionalität mit.
Ein File, viele Amigas?
Mit diesen Konzepten und Programmen ist es nun nicht mehr nötg, auf jedem Rechner immer wieder alle möglichen Files doppelt und dreifach zu halten. Samba stellt sicher die universellste Lösung unter den angegebenen dar, da es auch einen Übergang zu anderen Betriebssystemen und Plattformen ermöglicht. Die komfortabelste Variante ist sicher Envoy und in der Unix-Welt am weitesten verbreitet dürfte wohl NFS sein. Angesichts dieser Einteilung sollte nun eine Entscheidung, welches File-Verwurschtungs-Utility am besten geeignet ist, an das Netz gelassen zu werden, nicht mehr unmöglich sein.
Oliver Gerler ...........
![[Up]](images/_krumm_hi.gif){kind=small}
....