VOICE-Homepage: http://de.os2voice.org
Inhaltsverzeichnis
< Vorherige Seite | Nächste Seite >
Artikelverzeichnis
|
VOICE-Homepage: http://de.os2voice.org |
Mai 2004
Inhaltsverzeichnis
|
| Von Chris Clayton © Mai 2004, Übersetzung: Marckus Kraft |
Alles fing an, als ich mich dazu entschied, meinen alten 1995er Gateway Pentium-Computer, welchen ich zur Entwicklung von Anwendungen und anderen experimentellen Aktivitäten verwende, gegen ein modernes ASUS-Motherboard auszutauschen. Da nur wenige Komponenten aus dem alten Gerät wiederverwendet werden konnten, hatte ich am Ende eigentlich zwei Rechner.
So beschloß ich, den Gateway-Rechner als File-Server zu benutzen. Zusätzlich ist mein Laptop, ein Thinkpad i-Series 1721, das ich als "Produktionssystem" verwende, wegen der vielen, zusätzlich angeschlossenen Geräte kein wirklich tragbarer Rechner mehr.
Überhaupt benutze ich die ganze Zeit das Turnschuh-Netzwerk, um Dateien vom einen zum anderen Rechner zu transferieren. Es war also Zeit für ein echtes Heim-Netzwerk.
Meine Frau hatte bereits angedroht mich, unter den Kabeln zu begraben und ich wollte diesen Vorgang nicht beschleunigen. Daher beschloß ich, ein drahtloses Netzwerk einzurichten, das in der ursprünglichen Planung eine Verbindung zum Wide Area Network (WAN) per Wählverbindung herstellen sollte, aber mit der Möglichkeit, eine zukünftige Hochgeschwindigkeitsverbindung (z.B. DSL) zu unterstützen.
Es gibt im Internet viele Stellen, um Informationen für das Netzwerken unter OS/2 zu finden. Ich habe einige am Ende dieses Artikel aufgelistet. Darüberhinaus bin ich recht geübt darin, ein Netzwerk unter OS/2 zum Laufen zu bringen, da ich den letzten verbliebenen OS/2-Rechner im LAN auf der Arbeit habe, der von einem Ozean von Windows umgeben und wo der LAN-Help-Desk keine wirkliche Hilfe ist.
Neben der Einrichtung des Peer-Netzwerks wollte ich, da ich ein bißchen altmodisch bin, eine Reihe von "veralteten" Kommunikationsmethoden, wie z.B. Telnet, benutzen. Daher mußte ich sicherstellen, daß sie in meinem Heimnetzwerk leicht zu benutzen sind. Ich glaube auch an das KISS-Prinzip (Keep it simple and stupid: man sollte alles so einfach wie möglich halten).
Die Drucker sollen an einer Stelle stehen, aber für alle zugänglich sein. Anstatt mich physisch von Computer zu Computer zu bewegen, benötigte ich die Möglichkeit, sie über das Netzwerk fernzubedienen.
Das neue Netzwerk ist geradlinig und vielseitig. In den folgenden Abschnitten beschreibe ich Hardware-Arrangement, Netzwerk-Konfiguration einschließlich Internet-Protokoll-Adressierung und Routing, verschiedene Verbindungsprogramme, die ich benutze, Netzwerk-Performance, Sicherheit und einige ungelösten Sachfragen.
Auf dem Gateway-Computer läuft OS/2 Warp 4.0 (Client) mit FixPak 15, aber als Server ist es mit einem LAN-Port eines D-Link-614+ Wireless Broadband-Routers verbunden. Eine Modem wird zur Anbindung an das Internet verwendet. Der Rechner steht jetzt in einem Schrank mit den beiden angeschlossenen Druckern.
Der ASUS-Rechner ist über eine Realtek-Netzwerkkarte mit einem D-Link-900+ Access-Point verbunden, der als Wireless Client konfiguriert ist. Dieses Modell erfordert den Einsatz eines Crossover-Kabels für den Wireless-Client-Modus.
Es gibt verschiedene Wireless-Router und -Brigdes, aber es ist wichtig, im Hinterkopf zu behalten, daß sie zwar alle 802.11b unterstützen, aber nicht unbedingt zueinander kompatibel sind.
Normalerweise funktionieren Funknetzwerkkarten mit den Routern der anderen Marken. Jedoch sind Router und Bridges unterschiedliche Firmen evtl. nicht kompatibel, daher wählte ich jeweils ein Modell von D-Link.
Die D-Link-Geräte werden über den Web-Browser konfiguriert. Ich habe herausgefunden, daß es besser ist, wenn man den IBM Web Browser verwendet statt Netscape Communicator 4.61. Einige Vorgänge wurden bei Verwendung des Communicators nicht ordnungsgemäß beendet.
Beide D-Link-Geräte unterstützen die Einrichtung über einen Konfigurationsassistenten (s. Abb. 1).
Abb. 1: Konfigurationsassistent des D-Link 614+-Router (Klicken Sie auf die Abbildung, um diese zu
vergrößern.)
Über den Assistenten stellte ich die Zeitzone ein, die Einstellungen für die drahtlose Verbindung und die Verschlüsselung. Der D-Link 900AP+ erfordert einen zusätzlichen Schritt. Er muß auf den Wireless-Client-Modus umgestellt werden.
Auf der Seite Advanced wählte ich im Abschnitt Mode den Radioknopf Wireless Client und gab dort die MAC-Adresse des D-Link 614+-Routers (s. Abb. 2). Ich nahm hier später noch einige manuelle Änderungen vor, die ich im Abschnitt "Sicherheit" noch erläutern werde.
Abb. 2: Modus-Einstellungen beim D-Link 900AP+. (Klicken Sie auf die Abbildung, um diese zu
vergrößern.)
Ich habe zwei IBM Thinkpads, die mit IBM High Rate Funknetzwerkkarten ausgerüstet sind. Treiber für diese Karte finden Sie auf den eComStation Download-Seiten. Leider wird die IBM High Rate Funknetzwerkkarte nicht mehr hergestellt. Ich konnte eine Ersatzkarte bei ebay ersteigern.
Als Alternative ist die Jacaranda Blue Wireless Card noch bei Mensys erhältich. Diese Karte benutzt den Artem-Treiber, der mit eComStation 1.1 ausgeliefert wird.
Ich schäme mich fast, es zuzugeben, aber ich benutze auch einen Computer mit Microsofts ® Windows ® XP Home Edition darauf. Es ist ein Toshiba Satellite 1135 Laptop mit einer D-Link 650+ Funknetzwerkkarte.
Ich setze voraus, daß TCP/IP und Peer-Netzwerke erfolgreich installiert wurden, da eComStation (eCS) 1.1 das eigentlich sehr gut macht. Was ich diskutieren möchte, ist der Netzwerktyp, den ich eingerichtet habe.
Der D-Link-Router verbindet zwei Subnetze, das Ethernet und das Funknetz. Ich bin mir nicht sicher, vermutet aber, daß die meisten Wireless-Router dies tun. Das macht das Heim-Netzwerk zu einem gerouteten LAN, wenn man sowohl drahtlose als auch drahtgebundene Computer anschließt.
Auf jeden Fall muß zur Nutzung des Peer-Netzwerks das Protokoll NetBIOS über TCP/IP installiert sein. Die Verwendung des ungerouteten Protokolls NetBIOS ist redundant, also habe ich dieses Protokoll entfernt, als ich das Netzwerk konfiguriert habe.
Nachträglich läßt sich diese Änderung über Multi-Protocol Transport Services (MPTS) vornehmen, zu finden im Ordner Lokales System, Ordner Systemkonfiguration, Ordner Netzwerk.
Abbildung 3 zeigt mein typisches Arrangement von Adaptern und Protokollen.
Abb. 3: MPTS-Konfiguration
An dieser Stelle möchte ich etwas abschweifen. In einigen Referenzen, die ich zitierte, sind Anweisungen, um sowohl NetBIOS als auch NetBIOS over TCP/IP einzusetzen. Dies ist nicht wirklich notwendig. Um zu verstehen warum, muß man sich den Weg ansehen, wie die beiden Protokolle die Namen auflösen.
Reines NetBIOS löst Namen dadurch auf, daß Anfragen ans Subnetz gesendet werden, die den Computer der Arbeitsgruppe, der einen Namen hat, der auf die Anfrage paßt, auffordern zu antworten. Erfolgt die Antwort innerhalb einer bestimmten Zeit, wird die Verbindung hergestellt, andernfalls wird eine Fehlermedlung erstellt. Ein Problem ist, daß viele Router diese Anfragen nicht weiterleiten. Der Grund ist, daß das Protokoll als nicht routingfähig angesehen wird.
Das Protokoll NetBIOS erzeugt eine Menge Daten im Netzwerk, reduziert dadurch die Leitungskapazität und wird in kommerziellen Anwendungen häufig nicht mehr unterstützt.
NetBIOS over TCP/IP hat verschiedene Arten, um Namen aufzulösen, die hauptsächlichen sind b-node und p-node. b-node entspricht der Art von NetBIOS, ist aber oft mit einer interessanten Veränderung implementiert, genannt Modifiziertes b-node, die in gerouteten Netzwerken unterstützt wird. Diese modifizierte Version löst Namen dadurch auf, daß auf dem Client-Rechner eine Datei gesucht wird, die Namen und Adresse des Rechners enthält. Unter OS/2 ist dies die Datei rfcnames.lst zu finden im Verzeichnis \IBMCOM und unter Windows ® lautet der Dateiname lmhosts (in \Windows\system32\drivers\etc). Wird der Name des Servers nicht gefunden, werden Anfragen gesendet.
Als p-node, einem Point-to-Point-Modus, wird ein NetBIOS-Namen-Server zur Auflösung der Namen verwendet. Microsoft ® nennt den NetBIOS-Namen-Server WINS-Server.
Entsprechend der Namensauflösung unter TCP/IP gibt es primäre NetBIOS-Namen-Server und Backup-Server, denn wenn die Server nicht online sind, können keine Peer-Verbindungen hergestellt werden.
Es gibt noch einen dritten Modus, h-node genannt, beim dem versucht wird, dieses Problem zu umgehen, indem zuerst p-node und dann b-node (normalerweise Modifiziertes b-node) verwendet wird, wenn der NetBIOS-Server die Adreßauflösung nicht schafft.
Heutzutage ist mit modifiziertem b-node die gleichzeitige Verwendung von NetBIOS und NetBIOS über TCP/IP redundant und dann das Netzwerk verlangsamen. Außerdem macht die Verwendung von nur einem NetBIOS-Protokoll das Netzwerk einfacher in der Handhabung und dann sind da noch die Bedenken bezüglich der Sicherheit. Dieses Problem werde ich später erläutern.
Zusammengefaßt, die einzigen installierten Protokollen in meinem Netzwerk sind "IBM TCP/IP" und 'IBM OS/2 NetBIOS über TCP/IP'.
Konfiguriert habe ich NetBIOS über TCP/IP dadurch, daß ich den Protokolleintrag in MPTS markiert und dann auf die Schaltfläche Bearbeiten klickte. In dem dann folgenden Dialog (siehe Abb. 4) gibt es drei Optionen.
Für mein Heimnetzwerk ließ ich alle Optionen für die "Treiberparameter" auf den vorgegebenen Einstellungen. Für eCS ist dies b-node und die übrigen Parameter sind entsprechend eingestellt.
Auf der Arbeit habe ich h-node gewählt und die Adressen der WINS-Server in die Felder "Adresse des NetBIOS-Names-Server" und "Adresse des NetBIOS-Ausweichnamens-Servers" eingetragen.
Abb. 4: Konfigurationsdialog für NetBIOS über TCP/IP
Um das modifizierte b-node einzuschalten, wählte ich nacheinander die Optionen "Namensliste" (Abb. 5) und die "Rundsendenachrichtenliste" (Abb. 6). Ich verwendete die Schaltfläche "Hinzufügen", um die IP-Adressen und die NetBIOS-Namen für die verschiedenen Systeme, die mit meinem Heimnetzwerk verbunden sind, einzugeben, einschließlich der Sitzungen von Virtual PC.
Abb. 5: Dialog Einträge in die Namensliste
Abb. 6: Dialog Einträge in die Rundsendenachrichtenliste
Für mein Netzwerk verwende ich feste IP-Adressen. Der D-Link-Router verfügt über einen DHCP-Server zur dynamischen Verteilung von IP-Adressen, was unter eCS auch gut funktioniert. Aber diese Methode, eine IP-Adresse zu erhalten, bereitet bei mir Routing-Probleme. Der D-Link-Router macht sich per DHCP zum Default-Router. Um die Wählverbindung des Gateway-Computers als Internetzugang zu verwenden, muß der Gateway-Rechner Default-Router sein.
Ich werde diese Problematik später darlegen, zusammen mit einer Erklärung, warum die Verwendung fester IP-Adressen eine Reihe anderer angenehmer Features für ein vielseitiges Netzwerk ermöglicht.
Die Datei d:\mptn\bin\setup.cmd mag evtl. von Hand bearbeitet werden, aber die TCP/IP-Konfiguration über die Ordner Systemkonfiguration, Netzwerk, TCP/IP ist der einfachste Weg, die Einstellungen für IP und Routing zu ändern.
Auf der Seite Netzwerk habe ich sichergestellt, daß das LAN interface 0 aktiviert war und der Radioknopf "Manuell über" gewählt war in den "Konfigurationsoptionen - LAN interface 0'. Dann füllte ich die Felder "IP-Adresse" und "Teilnetzwerkmaske" mit den für mein Netzwerk notwendigen Daten aus. Siehe Abbildung 7.
Abb. 7: Seite Netzwerk im TCP/IP-Konfiguration-Notizbuch
Auf der Seite Leitweg (Abb. 8) sorgte ich dafür, daß die Adresse des Gateway-Servers als Standardleitweg eingestellt war. Das TCP/IP-Konfigurationsnotizbuch wird auch dazu verwendet, die auf dem Gateway-Rechner laufenden Server einzurichten.
Abb. 8: Seite Leitweg im TCP/IP-Konfigurationsnotizbuch
Folgende Dienste werden automatisch OS/2-Systemstart auf dem Gateway-Server gestartet:
Die vier TCP/IP-Dienste werden auf der Seite "Autostart" im TCP/IP-Konfigurationsnotizbuch eingeschaltet und konfiguriert. Das Vorgehen ist zwischen eCS und OS/2 Warp 4 leicht unterschiedlich.
Unter eCS habe ich der Reihe nach die Einträge der gewünschten Server in der Liste "Dienste für automatischen Start" markiert, die Option "Dienst automatisch starten" markiert, die Option "Vordergrundsitzung" gewählt und "In Symbolgröße".
Für lpd (Abb. 9) habe ich im Feld "Parameter" -b -c eingegeben. Diese Optionen unterdrücken das Ausdrucken unbenötigter Banner und Kontrollseiten.
Abb. 9: Seite Autostart im TCP/IP-Konfigurationsnotizbuch, LPD-Server-Einstellungen
Als nächstes müssen die Benutzerberechtigungen eingestellt werden. Auf der Seite "Sicherheit" habe ich mich selbst als Benutzer hinzugefügt und den Zugriff auf FTP- und Telnet-Server konfiguriert.
Für den FTP-Server habe ich die beiden Option "Lesezugriff aktivieren" und "Schreibzugriff aktivieren" gewählt, ohne weitere Dateneingaben in dazugehörigen Eingabefeldern. Dadurch hatte ich vollen Lese-/Schreibzugriff auf alle Laufwerke des Servers.
Unter OS/2 Warp werden die gleichen vier TCP/IP-Dienste automatisch gestartet. Der Unterschied ist, dass ich zusätzlich den Server Inetd starte und die Option "INETD-Super-Server-Dämon" für ftpd und telnetd gewählt habe.
Die Dinge sind nicht so sicher, wenn unter OS/2 Benutzer eingeschaltet sind. Auf der Seite "Sicherheit" wird ein einzelnes Paßwort im Feld "Telnet-Kennwort" eingetragen. Es wird hier nicht angezeigt, dafür aber im Klartext in der Datei CONFIG.SYS.
Für den FTP-Zugriff muß die Datei d:\mptn\trusers angelegt werden. Dies geschieht durch das Hinzufügen von Benutzern über die Liste "File Access Protection (TRUSERS)". Dieser Prozeß erlaubt es, den Benutzer Zugriffsprivilegien zu gewähren. Die Datei trusers ist zwar auch im Klartext, aber zumindest kann das Attribut "Versteckt" gesetzt werden.
Kai Uwe Rommel hat eine Alternative zum Standardanmeldeprozeß von Telnet unter Warp 4 erstellt, die eine verschlüsselte Paßwortdatei verwendet und den Zugriff für beliebig viele Benutzer erlaubt. Sie finden diesen alternativen Telnet-Server auf Hobbes. http://hobbes.nmsu.edu/os2/apps/internet/telnet/server/tnlogin.zip.
Ich entpackte das Archiv und folgte dann den klaren Anweisungen in der Readme-Datei.
Peer wird auf dem Gateway-Rechner automatisch durch eine Referenz auf das Symbol "Start File and Print Client" im Ordner Verbindungen | Netzwerk | Anmelden gestartet, die im Ordner "Systemstart im Ordner "System" plaziert ist.
Für eComStation heißen die entsprechenden Ordner "Lokal Netzwerk" | "Netzwerk-Dienstprogramme" und "Lokales System" | "Systemstart".
Die Server HTTPD und Time werden in den nachfolgenden Abschnitten beschrieben.
Wie ich oben schon erwähnt habe, steht der Gateway-Server in einem Schrank. Ein Monitor ist zwar angeschlossen, aber der wird selten eingeschaltet; normalerweise nur, wenn ich das monatliche Backup erstelle und die Server vorübergehend abschalte.
Jeder sonstige Zugriff erfolgt über das Netzwerk mit "Desktop-On-Call". Diese Anwendung ist Teil des eCS-Lieferumfangs. Bei eCS 1.0 ist sie auf CD 3 und bei eCS 1.1 auf CD 2 zu finden.
Die Version 4 von Desktop-On-Call kann von IBM bezogen werden. http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=1826745&storeId=1&catalogId=-840&langId=-1. Ich habe jetzt nicht versucht die letzte Version zu installieren, da ich vor einigen Jahren Version 2.5 bei IBM gekauft habe. Daher werde ich hier nichts zur Installation schreiben.
Es gibt zwei Sachen bei Desktop-on-Call (DoC). Die erste ist, daß der IBM Web Browser nicht so gut mit DoC zusammenarbeitet, wenn überhaupt. Ich benutze Netscape 4.61 und gebe die IP-Adresse für den Gateway-Ccomputer in das Feld "Location:" ein.
Die zweite Sache ist schwerwiegender und ihre Lösung nicht nicht offensichtlich und augenscheinlich auch nicht dokumentiert. Der Desktop braucht bis zu zwei Minutenm um im Heim-Netzwerk überhaupt zu erscheinen. Es sieht so aus, als ob Netscape versuchte, die Adresse über einen nicht existierenden Namen-Server aufzulösen, auch wenn eine IP-Adresse angegeben wird.
Die Lösung ist elegant: Man erzeugt eine Datei hosts (d:\mpts\etc\hosts) und ergänzt folgende Zeile in der CONFIG.SYS:
set use_hosts_first=1
Das normale Format der Datei hosts ist:
ip.addresse name.internet.domäne alias1 alias2 ... # kommentar
Ein Heimnetzwerk hat keinen echten Internet-Domänennamen, daher ersetzte ich den Eintrag "name.internet.domäne" einfach durch "name" und für "alias1" entsprechend:
192.168.2.52 nanook nanook #gateway
Diese Einträge können von Hand in die Datei eingetragen werden oder über das TCP/IP-Konfigurationsnotizbuch (vgl. Abb. 10).
Abb. 10: Seite Host-Namen im TCP/IP-Konfigurationsnotizbuch
Eine zusätzliche Nebenwirkung der Datei hosts ist, daß ich auf der
Kommandozeile eingeben kann:
telnet nanook und verbunden werde.
Praktischerweise habe ich alle IP-Adressen und Rechnernamen meines
Heimnetzwerks in die Datei hosts eingetragen.
Auf diese Weise kann ich 'mal eben FTPD oder TELNETD auf einem Client-Computer starten und mich von einem anderen Computer damit verbinden. So brauche ich nur einige Ordner freizugeben und habe doch einen Weg, alle Laufwerke zu erreichen, wenn es notwendig ist.
Damit mein Netzwerk synchron bleibt, lasse ich auf dem Gateway-Rechner einen Zeit-Server laufen. Die verwendete Anwendung ist Norbet Days Time868, zu finden auf Hobbes unter http://hobbes.nmsu.edu/pub/os2/apps/internet/time/time868f.zip.
Diese Anwendung holt sich die Zeit über TCP oder UDP. Unglücklicherweise funktioniert die Server-Option nur mit dem Protokoll UDP, was die Auflösung auf eine Sekunde limitiert. Diese Einschränkung ist für mein Heimnetzwerk kein Problem.
Um Time868 als Server einzurichten, wählte ich "NIST, Boulder CO, USA" in der Auswahlliste "Well-known sites", klickte auf den Radioknopf UDP und aktivierte das Markierungsfeld "Enable" im Bereich "Server", wie in Abb. 11. Die Anwendung läuft ständig auf dem Gateway-Rechner und manchmal, wenn ich eine Internet-Verbindung habe, klicke ich auf die Schaltfläche "Run now", um die Zeit zu synchronisieren.
Der Gateway-Rechner hat eine sehr zuverlässig laufende Systemuhr und benötigt keine regelmäßigen Updates. Ich habe einmal drei Monate mit dem Update gewartet und die Differenz betrug nur einige Sekunden.
Abb. 11: Time868 als Server
(Klicken Sie auf die Abbildung, um diese zu vergrößern.)
Auf den anderen OS/2-Rechnern im Netzwerk habe ich Time868 als Client eingerichtet. Am Ende der Auswahlliste "Well-known sites" sind zwei Einträge, die bearbeitet werden können. Ich habe einen ausgewählt und Namen und IP-Adresse des Gateway-Rechners in die Felder "Host Name" und "IP Address" eingetragen.
Auf dem ASUS-Computer habe ich sowohl die Option "Auto run" als auch "Continuous" gewählt. Anders als der Gateway-Rechner hat der ASUS-Computer eine sehr unzuverlässige Systemuhr. Sie weicht leicht innerhalb von Stunden um Sekunden ab. Daher habe ich das Aktualisierungsintervall auf 30 Minuten gesetzt (s. Abb.12).
Ich versetzte meine Laptops gerne in den Ruhezustand, wenn ich sie nicht brauche. Die Funknetzwerkkarten müssen zuvor aber abgeschaltet und entfernt werden. Daher ist hier die Option "Continuous" leider nicht eingeschaltet.
(Klicken Sie auf die Abbildung, um diese zu vergrößern.)Für Windows ®-Systeme gibt es eine nette "CareWare"-Anwendung names AboutTime. Programmiert von Paul Lutus; erhältlich auf seiner Web-Site www.arachnoid.com.
Es gibt sie in zwei Versionen. Ich habe die Version gewählt, die nicht den Microsoft Internet Explorer 4.0+ ® voraussetzt. Sie funktioniert sehr gut mit dem Time868-Server und ist einfach einzurichten.
Auf der Seite "Time Hosts" in den Einstellungen klickte ich auf die Schaltfläche "Add", gab die Koordinaten des Gateway-Servers ein und wählte das Protokoll "Time/UDP". Auf der Seite "Options" aktivierte ich die Markierungsfelder "Start hidden" und "Put icon on system tray". Schließlich setzte ich noch einen Verweis auf AboutTime in den Ordner "Autostart".
Es gibt drei Wege, mit eCS über das Netzwerk zu drucken. Der erste nutzt Peer und Freigabe eines Druckerobjektes auf dem Server. Ich habe meine Drucker auf dem Gateway-Rechner freigegeben. Ich drucke über diese freigegebenen Ressourcen von meinem Windows ® XP-Computer und allen Virtual PC Windows ®-Sitzungen. Diese Methode ist schneller als die nächste, aber nicht so schnell wie die letzte.
Der zweite Weg ist der LPD-Client, der von eCS automatisch installiert wird. Um Druckjobs absetzen zu können, müssen zwei Daemons laufen: lprportd (line printer port daemon) auf dem Client und lpd (line printer server daemon) auf dem Server. Die Einrichtung ist einfach: Wählen Sie den Anschluß \pipe\lpd0 im Drucker-Notizbuch, Doppelklick, geben Sie dann die Daten für den LPD-Server und den LPD-Drucker (siehe unten) sowie den Namen des lokalen Rechners und ihre Namen in den entsprechenden Eingabefeldern ein. Von den drei Wegen ist dies der langsamste.
SLPR (streaming line printer port) ist der Weg, den ich für alle eCS-Rechner gewählt habe. Den Anschlußtreiber gibt es auf der eComStation download site.
Die Installation ist einfach. Ich entpackte das Archiv in ein temporäres Verzeichnis, öffnete dann das Einstellungsnotizbuch des Druckerobjektes. Auf der Seite "Ausgabenanschluß klickte ich auf die Schaltfläche "Neuen Anschluß installieren" und wählte dann die Option "Neue Anschlußtreiber". Dann gab ich im Feld "Verzeichnis" das temporäre Verzeichnis mit dem Treiber an und klickte auf die Schaltfläche "Aktualisieren". Im Bereich "Ausgabeanschluß" wählte ich das Symbol "SLPR" und klickte auf die Schaltfläche "Installieren".
Die Einstellungsseite für den Anschluß SLPR1 wurde angezeigt. Hier gab ich die IP-Adresse des Gateway-Rechners und den Namen der Drucker-Warteschlange in die entsprechenden Felder ein. Den Namen der Drucker-Warteschlange fand ich heraus, indem ich mir die Verzeichnisname im Verzeichnis "Spool" auf dem Gateway-Rechner anschaute.
Ein anderer Weg ist das Öffnen des Druckereinstellungsnotizbuchs. Dort schaut man dann auf die Seite "View". Da ich keine Experimente wollte, beließ ich die anderen Felder in ihren Standardeinstellungen.
Die Installation zusätzlicher SLPR-Anschlüsse ist lediglich eine Formsache: Klicken Sie auf die Schaltfläche "Neuen Anschluß installieren", im nächsten Dialog wählen Sie die Option "Vorhandene Anschlußtreiber", wählen "SLPR" und wiederholen die Installationsschritte.
Damit gedruckt werden kann, muß der Daemon LPD auf dem Server laufen.
Drucken über das Netzwerk aus einer Win-OS/2-Sitzung ist möglich. Zuerst stellte ich sicher, daß die Win-OS/2-Drucker mit den Anschlüssen LPTn.OS2 verbunden waren. Dann, wieder unter eCS, öffnete ich im Ordner "Systemkonfiguration" das Objekt "Spooler" und wählte die Seite "Umleitung". Dort wählte ich die LPT-Anschlüsse von Win-OS/2 (Auswahlliste "Umgeleiteter Anschluß") und markierte die entsprechenden Drucker in der Auswahllsite "Drucker".
Damit von allen Computern ein Internetzugang über die Wählverbindung
möglich ist, müssen drei Dinge eingerichtet sein:
Der Server muß der Netzwerk-Router sein, am Server muß die IP-Weiterleitung
eingeschaltet sein und das Einwählprogramm muß NAT (Network Address
Translation) beherrschen.
Der Gateway-Rechner ist bereits Netzwerk-Router, wie ich oben gezeigt habe. IP-Weiterleitung wurde über das Markierungsfeld "IP-Weiterleitung" auf der Seite "Leitweg" des TCP/IP-Konfigurationsnotizbuches eingeschaltet. IP-Weiterleitung kann auch manuell über den Befehl: "ipgate on" eingeschaltet werden.
Ich setze die erweiterte Version des Programms F/X Communications Injoy Dialer ein. Diese Version bietet NAT für bis zu vier Computer gleichzeitig. Es ist einfach zu konfigurieren.
Zuerst schaltete ich NAT auf der Seite "PPP[SLIP] Setup" (s. Abb. 13) ein: Markierungsfeld "Firewall/NAT".
Abb. 13: NAT im Injoy-Dialer einschalten
Auf der Seite "Firewall Options" aktivierte ich die Markierungsfelder "Network Address Translation" und "Disable NAT for Injoy PC". Alles übrige blieb unaktiviert oder unverändert mit den Standardeinstellungen. Meine Einstellungen entnehmen Sie Abb. 14. Nach dem Speichern der Änderungen war das Internet von jedem System im Haus-Netzwerk zu erreichen, sogar von dem unaussprechlichen Betriebssystem, welches in einer Virtual PC-Sitzung läuft.
Abb. 14: Injoy-Firewall-Optionen.
Wenn ich von einem der Rechner ins Internet will, starte ich Netscape 4.61, rufe den Gateway-Server auf, wo Desktop On-Call die Arbeitsoberfläche anzeigt. Auf dem Gateway-Rechner starte ich eine Injoy-Sitzung, wähle meinen ISP und klicke auf die Schaltfläche "Dial".
Innerhalb weniger Momente bin ich verbunden und surfe im Web mit dem IBM Web Browser. Wenn ich online bin, maximiere ich normalerweise Time868 und synchroniziere die Systemzeit. Eine typische Sitzung zeigt Abb. 15.
Abb. 15: Der Desktop des Gateway-Servers angezeigt mit Desktop On-Call
(Klicken Sie auf die Abbildung, um diese zu vergrößern.)
Gelegentlich verbinde ich mich mit dem Internet über ein Modem am Client-Rechner. Ich starte einfach Injoy lokal und wähle. Ich kann immer noch alle Rechner und Dienste im Netzwerk erreichen, aber die anderen Rechner haben keine Zugriff aufs Internet. Sehr praktisch, wenn ich in Eile bin und die schmale Bandbreite mit niemandem teilen will.
Die Koexistenz zwischen OS/2- und Windows ®-Rechner im gleichen Netzwerk ist nicht schwierig zu erreichen. Es ist nur so, daß Bill Gates es nicht unkompliziert gemacht hat.
Im folgenden nehme ich an, daß TCP/IP bereits mit richtigen Adressen und Routing konfiguriert wurde. Windows ® 95/98 und NT 4.0 sollten direkt ohne Anpassungen funktionieren. Normalerweise ist "Microsoft ® Networking" als Standard eingestellt.
"Microsoft ® Networking" ist nicht mehr als NetBIOS über TCP/IP. Allgemein verwendet Windows ® b-node, wenn nicht WINS-Server angegeben sind. Dann wird h-node verwendet. Ich habe sichergestellt, daß ich nicht versuche, mich in eine NT-Domäne einzuloggen, der Name der Arbeitsgruppe ist gleich dem NetBIOS-Namen meines Heimnetzwerkes, die WINS-Einträge sind alle leer und gemeinsame Benutzung ist eingeschaltet. Diese Einstellungen habe ich über das Notizbuch "Netzwerk" im Ordner "Systemeinstellungen".
Ich habe NT/2000 zu Hause nicht benutzt, aber ich habe es auf der Arbeit (Konfiguration durch die Netzwerker; für mich nicht sichtbar). Ich war aber in der Lage, mein OS/2-System auf der Arbeit zu einer friedvollen Koexistenz mit einem Windows ® dominierten LAN zu bewegen, mit h-node mode für NetBIOS über TCP/IP, wie oben beschrieben.
Der Netzwerkadministrator braucht Zugriff auf die WINS-Server. Manchmal sind Netzwerkressourcen für den OS/2-Computer nicht zu erreichen. Dies wird normalerweise durch unkorrekte Einstellungen auf der Windows ®-Seite verursacht. In solchen Fällen braucht man wirklich einen Netzwerkadmin, der bereit ist, eine Lösung des Problems zu suchen.
Windows ® XP Home Edition ist etwas problematischer. Ich habe es zu Laufen gebracht, aber unglücklicherweise die Aufzeichnungen über die Installation verloren, so daß ich mich jetzt auf mein lückenhaftes Gedächtnis verlassen muß.
Als erstes stellte ich sicher, daß "File and Printer Sharing for Microsoft ® Networks" installiert und aktiviert war. Danach schaltete ich "NetBIOS über TCP/IP" ein. Dies macht man über die Einstellungseite "Internet Protokoll (TCP/IP)" (aufrufen über Start | Einstellungen | Systemsteuerung | Netzwerkverbindungen | LAN-Verbindung oder WLAN-Verbindung, "Einstellungen"). Dort klickte ich auf die Schaltfläche "Erweitert..." und wechselte auf die Seite "WINS".
Hier wählte ich den Radioknopf "NetBIOS über TCP/IP aktivieren". Zuletzt aktivierte ich "Gemeinsame Nutzung". Ich glaube, daß ich das mit dem Netzwerkkonfigurationsassistenten unter Netzwerkverbindungen durchgeführt habe, jedoch können dort noch andere Option verfügbar gewesen sein, die aber entfernt wurde, als die Gemeinsame Nutzung aktiviert wurde. Ich erinnere mich, daß ich, als ich auf die Seite mit den Einstellungen für die gemeinsame Nutzung kam, XP den vorgeschlagenen Pfad für die gemeinsame Nutzung habe festlegen lassen.
Großer Fehler. Die "Gemeinsame Nutzung" war zwar eingeschaltet, aber ich stand vor einem Durcheinander von "Bridges" und keinem Netzwerk. Es dauerte mehrere Stunden, das Netzwerk zu entfernen und neuzuinstallieren. Ich hätte wohl besser die Option "Just enable sharing" aktiviert.
Ein vielseitiges Heimnetzwerk ist nutzlos ohne einige Sicherheitsmaßnahmen, die ergriffen werden, um unliebsame Benutzer draußen zu halten. Das Funknetzwerk muß geschützt werden und der Zugriff über WLAN muß beschränkt werden. Leider ist der aktuelle Stand der Sicherheit von 802.11b-WLANS schwach. Die von mir getroffenen Maßnahmen sollten neue und versehentliche Zugriffe verhindern, werden aber keinen hartnäckigen Experten am Zugriff hindern.
Als erstes habe ich WEP mit 128bit-Verschlüsselung implementiert. Ich bin überrascht, wie viele Leute WEP nicht einsetzen. Als ich meine Tochter in Phoenix besuchte und ihr Netzwerk benutzte, gab es vier WLANs in der Nachbarschaft, auf die man zugreifen konnte. Nur eines war verschlüsselt. Guter Weg, unwissentlich ein Internet Access Provider zu werden!
Dann änderte ich die WLAN-ID (SSID) von den Standardwerten. Dies hat eher einen ästhetischen Wert und ist weniger ein Schutz, da die SSID immer unverschlüsselt gesendet wird.
Der Einsatz von fixen IP-Adressen, der Verzicht auf DHCP und die Verwendung eine anderen IP-Subnetzmaske als die Standardwerte hilft auch ein bißchen.
Schließlich implementierte ich noch das Filtern der MAC-Adressen. Für den D-Link-Router wird dies auf der Seite "Advanced" eingestellt (s. Abb. 16).
Abb. 16: D-Link 614+ Router Filterseite für MAC-Adressen
(Klicken Sie auf die Abbildung, um diese zu vergrößern.)
Meine Meinung nach sollte der Schutz der MAC-Adresse ein bißchen mehr bieten als augenblicklich. Erstens: Das Filtern der MAC-Adressen des D-Link-Routers verhindert nicht, daß sich irgendjemand mit dem WLAN verbindet, nur der Zugriff auf den Router wird verhindert. Zweitens: Die MAC-Adressen werden unverschlüsselt gesendet. Der beste Schutz, den ich verwende, ist die regelmäßige Kontrolle der Protokolldateien (Router Status Logs).
Diese enthalten eine Liste aller Rechner, die sich mit dem WLAN verbunden haben. Ich habe bislang keine unbekannten Computer entdeckt, aber wenn dem einmal so sein sollte, werde ich sofort das WEP-Paßwort ändern.
Meine Injoy-Version hat kein Firewall-Plugin. Zum Glück hat mein ISP eine gute Firewall installiert, und standardmäßig ist Peer Sharing über eine Wählverbindung nicht möglich. Wiederholte Überprüfungen meiner Netzwerkaktivitätsprotokolldateien haben keine Schwierigkeiten aufgezeigt. Wie dem auch sei, ich muß irgendwann einmal eine Firewall installieren, wenn ich den aktuellen ISP nicht mehr verwenden kann oder wenn ich auf eine Hochgeschwindigkeitsverbindung umsteige. Für den letzteren Fall hat mein Wireless-Router eine eingebaute Firewall. Als eine Minimallösung müssen alle Ports der Server, die bei mir laufen, blockiert werden.
Ich finde die zu blockierenden Ports heraus, indem ich den Befehl "netstat -s" auf der Kommandozeile ausführe. Dieser Befehl zeigt eine Liste der offenen Ports. Hier ein Auszug aus der Liste des Gateway-Servers:
292 DGRAM 0 time..37 0.0.0.0 UDP 306 STREAM 0 25345 0.0.0.0 LISTEN 305 STREAM 0 25346 0.0.0.0 LISTEN 304 STREAM 0 www-http..80 0.0.0.0 LISTEN 18 STREAM 0 printer..515 0.0.0.0 LISTEN 17 STREAM 0 ftp..21 0.0.0.0 LISTEN 16 STREAM 0 telnet..23 0.0.0.0 LISTEN 11 DGRAM 0 emfis-data..140 0.0.0.0 UDP 10 STREAM 0 netbios-ssn..139 0.0.0.0 LISTEN 9 DGRAM 0 netbios-ns..137 0.0.0.0 UDP 8 DGRAM 0 netbios-dgm..138 0.0.0.0 UDP
Alles was mit "LISTEN" oder "UDP" gekennzeichnet ist, muß blockiert werden. Windows ® bereitet etwas mehr Schwierigkeiten. Es gibt eine Vielzahl von laufenden Diensten und das Gegenstück zum OS/2-Befehl zeigt nicht alle offenen Ports. Viele haben einen Namen, aber keine Nummer.
Meine bevorzugte Vorgehensweise ist, das WLAN abzuschalten, wenn der XP-Computer läuft. Dies ist nicht immer möglich. Daher habe ich so viele Auto-Updates und Benachrichtigungsdienste wie möglich deaktiviert. Aber es gibt immer noch ein paar unsichere "Features". Diese plane ich mit einem Programm von Gibson Research Corporation zu entdecken. Das Programm ist auf der Web-Site Gibson Research Corporation zu finden. Diese Web-Site ist eine gute Informationsquelle für die Verwundbarkeit von Microsofts ® "Features" und zeigt Wege, diese auszuschalten.
Die Leistung des Netzwerks wurde mit Kai Uwe Rommels Programm NetIO gemessen http://hobbes.nmsu.edu/cgi-bin/h-search?key=netio&pushbutton=Search.
Ich habe zwischen zwei Systemen gemessen, die auf der Ethernet-Seite des LANs (100 Mbps) waren, einem verdrahtetem System und einem WLAN-Rechner, sowie zwei WLAN-Systemen.
Die Funkverbindungen laufen mit dem Standard 11 Mbps 802.11b und der erweiterten D-Link-Version mit behaupteten 22 Mbps. Zwei verschiedene Tests liefen. Bei dem einen war die entfernte Maschine der Server (download), bei dem anderen war die lokale Maschine der Server (upload).
Ein einzelner Test mißt die Transferrate für Paketgrößen von 1KB, 2KB, 4KB, 8KB, 16KB und 32KB. Für die vier verschiedenen Arten der Verbindung wiederholte ich den Test zehn Mal und bildete ein Durchschnittsergebnis, um für alle Verbindungstypen und Transferrichtungen einzelne Ergebnisse zu haben.
Die Werte in Tabelle 1 sind die Ergebnisse des Verbindungstests über TCP/IP. Ich machte auch einige Test mit dem Protokoll NetBIOS, aber nicht genug für ein anständiges Ergebnis. Wie auch immer, der Trend der NetBIOS-Performance war ungefähr die Hälfte der Datenübertragunsgrate des Protokolls TCP/IP.
Verbindungstyp Download Upload 100 Mbps LAN 11318 11556 22 Mbps WLAN zu LAN 728 766 11 Mbps WLAN zu LAN 441 531 22 Mbps WLAN 243 322 11 Mbps WLAN 206 208 Tabelle 1: Netzwerk-Performance (Kb/s)
Die Performance des WLANs ist solange akzeptabel, bis größere Transfers notwendig werden, dann ist das LAN vorzuziehen. Die erweiterte Version von D-Link ist schneller, aber nicht die behaupteten 100%.
Es scheint so, als seien Computer wie eine Dose Ölsardinen. Es gibt immer kleine Rest, die man nicht erreichen kann. In meinem Fall sind es zwei ungelöste Aufgaben, für die ich noch Lösungen brauche.
Das erste Problem ist, daß Netscan von Object Desktop die Workplace Shell einfriert, wenn es über länger Zeit läuft. Es ist für kurze Zeit zu gebrauchen, aber ich habe es schließlich überhaupt nicht eingesetzt.
Das zweite Problem ist, das nei langen Hochgeschwindigkeitsübertragungen die Leistung schwankt und das Netzwerk gelegentlich auch die Arbeit einstellt. Diese Problem ist anscheinend auf WLAN-Verbindungen beschränkt, da ich im LAN-Bereich etwas ähnliches noch nicht gesehen habe. Wenn ich den Wireless-Router aus- und wieder anschalte, funktioniert das Netzwerk wieder. Diese Problem mag daher rühren, daß die Konsumer-Produkte nicht für "Schwerlastverkehr" ausgelegt sind oder daher, daß ich eher über den Gateway-Server route als über den D-Link-Router.
Mein Lösung ist, kontinuierlich zwischen den beiden beteiligten Systemen, die am Transfer beteiligt sind, und dem Gateway-Server Pings auszuführen. Ich starte die Pings vor der Dateiübertragung und pinge weiter, bis die Übertragung beendet ist.
Denkanstösse, wie diese Problem zu lösen sind, sind sehr willkommen.
In diesem Artikel habe ich dargelegt, wie ich ein sehr vielseitiges Heimnetzwerk eingerichtet habe. Die Netzwerkarchitektur basiert auf drahtloser Verbindung mit einem zentralen Server, der verschiedene nützliche Netzwerkdienste anbietet. Der Internetzugang erfolgt über eine Wählverbindung. Das Upgrade auf eine Hochgeschwindigkeitsverbindung ist möglich. Obwohl ich kein Netzwerk-Guru mit Ausbildung bin, habe ich Lösungen für einige Probleme gefunden, die während des Installationsprozesses auftraten. Ich hoffe, daß diese Lösungen für andere hilfreich sind. Natürlich sind noch ein paar Fragen für die Gemeinschaft der OS/2-Anwender zur weiteren Bearbeitung übriggeblieben.
Daten und Quellen:
|
Artikelverzeichnis
editor@os2voice.org
< Vorherige Seite | Inhaltsverzeichnis | Nächste Seite >
VOICE-Homepage: http://de.os2voice.org
Abb. 12: Time868 als Client.