Lernen aus dem Netz

Der Kommunikationsserver und das Internet

Wissen | Hintergrund

Nach der Netzwerkeinführung in der letzten Folge beschäftigt sich dieser Artikel mit der anderen Seite des c't/ODS-Kommunikationsservers: dem Anschluß ans Internet. Er enthält eine Sammlung der notwendigen Informationen, die ein Provider liefern muß, damit man den Zugang nutzen kann. Außerdem beschreibt er, wie die Dienste WWW, EMail und News in der Schule bereitgestellt werden.

Die Anbindung des Kommunikationsservers erfolgt über eine Telefonleitung. Dazu dient entweder ein V.34-Modem, mit dem sich in der Praxis bis zu 3,2 KByte/s übertragen lassen, oder ein ISDN-Adapter, der rund die doppelte Geschwindigkeit bietet. Eine sinnvoll gestaltete WWW-Seite (ohne Riesengrafiken) ist demnach in 5 bis 15 Sekunden zu übertragen, beim ersten Zugriff auf die entsprechende Web-Adresse vergehen schon mal 20 Sekunden. Bei einem langsamen Internet-Zugang oder zu Stoßzeiten kann sich diese Zeit beliebig verlängern. Man muß sich also etwas einfallen lassen, um mit zwanzig bis dreißig Schülern gleichzeitig in vernünftiger Geschwindigkeit arbeiten zu können - doch dazu später mehr.

Zunächst gilt es, die notwendigen Daten für den Internet-Zugang zu sammeln, um sie unter dem Menüpunkt `System/Einstellen/PPP´ einzugeben. Dazu muß man als erstes einen beliebigen Namen wählen, unter dem der Zugang später im Auswahlmenü erscheint. Wem mehrere Zugänge zur Verfügung stehen, der sollte an dieser Stelle eine unmißverständliche Beschreibung wählen. Doch Vorsicht: Leider fängt die erste Version des c't/ODS-Kommunikationsservers an dieser Stelle nicht alle Fehleingaben ab. Geben Sie auf gar keinen Fall eine Bezeichnung ein, die ein Leerzeichen enthält. Dadurch entsteht ein Durcheinander, das sich nicht ohne weiteres wieder beheben läßt (z.B.[../faq.shtml https://www.heise.de/ct/schan/faq.shtml).]

Zudem müssen Sie die Telefonnummer angeben, unter welcher der Provider erreichbar ist. Vergessen Sie dabei nicht die Null zur Amtsholung, falls der Anschluß über eine Telefonanlage hergestellt werden soll. Während der Server zur Nutzung eines analogen Modems keine zusätzlichen Informationen zur Verbindungsart benötigt, müssen ISDN-Anwender, abhängig vom verwendeten Adapter, mehr Fragen beantworten. Die erste betrifft den Typ des eigenen Anschlusses. Obwohl die Telekom heute fast ausschließlich Euro-ISDN-Anschlüsse verlegt, kann es sich bei Telefonanlagen auch um einen 1TR6-Anschluß handeln. Im Zweifelsfalle sollte der Hausmeister oder der für die Telefonanlage zuständige Techniker im Hause diese Frage zweifelsfrei klären können.

Die zweite Alternative, vor die sich ISDN-Anwender gestellt sehen, betrifft das Protokoll, über das die Verbindung zum Provider aufgebaut wird. Zur Auswahl stehen dabei X.75 und HDLC (auch SyncPPP genannt). So eigenartig das klingen mag, wir haben bei unseren Tests von Internet-Zugängen festgestellt, daß längst nicht alle Provider das von ihnen verwendete Protokoll benennen können. Zur Not muß man eben beide Varianten ausprobieren - passieren kann dabei nichts.

Die folgenden Eingaben sind unabhängig von der verwendeten Hardware obligatorisch. Der Zugang zu dem System des Providers, das Sie anrufen, ist durch ein Kennwort geschützt, damit ihn nicht jeder auf Kosten der Schule benutzen kann. Sie müssen daher eine Zugangskennung und ein geheimes Paßwort eingeben, die ihnen der Provider mitgeteilt hat und mit denen sich der Server später automatisch anmeldet. Die Anmeldung kann auf zweierlei Wegen erfolgen: entweder im Klartext oder über ein spezielles Protokoll (Challenge-Handshake Authentication Protocol, CHAP, oder Password Authentication Protocol, PAP).

Für eine Klartextanmeldung benötigt der Server ein Skript, also eine Art Drehbuch, das genau vorgibt, welche Stichworte in welcher Reihenfolge ausgetauscht werden. Dieses Drehbuch ist in einer speziellen Sprache geschrieben, deren Bedeutung dem Laien verschlossen bleibt. Deshalb haben wir ein Skript eingebaut, das in den meisten Fällen funktionieren dürfte. Sie können aber auch ein anderes Skript eingeben, sofern Ihnen der Provider ein solches liefert; fragen Sie ihn nach einem `Chat-Skript für Linux´. Sollte beides nicht zum Erfolg führen, hilft Ihnen unsere Hotline weiter.

Einfacher liegt der Fall, wenn der Provider die Anmeldung über eines der beiden genannten Protokolle unterstützt. Bei ISDN/SyncPPP ist dies immer der Fall, in allen anderen Fällen können Sie die CHAP/PAP-Authentifizierung durch Eingabe eines Sterns (*) im entsprechenden Menü aktivieren.

Mit diesen Angaben haben Sie alles eingestellt, was notwendig ist, damit Ihr Kommunikationsserver und das System des Providers miteinander Daten austauschen können. Die Menüoberfläche des Kommunikationsservers fragt danach noch zwei weitere Informationen ab, die aber bereits zu einer anderen Ebene der Kommunikation gehören. Daher zunächst zu dem, was nach dem Anruf und der Übermittlung des Paßworts beim Provider geschieht.

Welches dieser beiden Verfahren der Provider wählt, kann der Kunde nur selten beeinflussen. Sofern die Adresse und alle anderen notwendigen Informationen wie die Netzmaske wie üblich per PPP übertragen werden, spielt die Art der Adreßvergabe für den Netzanschluß und die Konfiguration des Servers keine Rolle. Viele Schulen sind verunsichert, weil ihr Provider dem Kommunikationsserver zusammen mit einer festen Adresse auch einen anderen Namen als den fest eingestellten (Arktur) zuteilt. Dieser Name besitzt jedoch nur im lokalen Schulnetz eine Bedeutung und sollte nicht geändert werden.

Angenommen, der Kommunikationsserver ruft von einem WWW-Server eine Seite ab. Mit der Anfrage teilt er seine IP-Adresse mit, an welche die Antwort übermittelt werden soll. Dabei ist es ganz unerheblich, ob diese Adresse ihm fest gehört oder nur für eine kurze Zeit zugeteilt wurde. Allerdings gibt es ganz selten Server, die ihre Dienste (WWW, Telnet etc.) nur ganz bestimmten Internet-Teilnehmern zur Verfügung stellen. Solche Server haben eine Liste von IP-Adressen, denen sie Zugriff gewähren. Da sie eine ständig wechselnde IP-Nummer nicht verläßlich identifizieren können, benötigt man in diesen Ausnahmefällen eine feste Adresse.

Um mit dem Kommunikationsserver selbst WWW-Seiten im Internet anzubieten, benötigt man ebenfalls eine feste IP-Adresse. Dann muß auch der Name des Servers mit dem übereinstimmen, den der Provider dafür vergeben hat. Außerdem benötigt man, und das dürfte das größte Problem sein, eine (teure) Standleitung zum Provider, damit der Server auch stets erreichbar ist. Diesen Betriebsfall haben wir beim c't/ODS-Kommunikationsserver nicht vorgesehen. Schulen, die ein eigenes Web-Angebot realisieren wollen, sollten ihren Server entweder bei einer kooperationswilligen Hochschule einrichten oder bei ihrem Provider. Dies ist der übliche Weg; auch der Server des Heise-Verlags (www.heise.de) steht in Karlsruhe bei unserem Provider.

So weit, so gut. Dennoch bleiben noch zwei Fragen offen: Wenn mir jemand eine EMail schicken will, muß er mich erreichen. Wie geht das, wenn ich nicht online bin, und wie geht das mit einer dynamisch zugeteilten IP-Nummer? Außerdem soll nicht nur der Kommunikationsserver Zugriff auf das WWW erhalten, sondern auch alle Schülerarbeitsplätze im lokalen Netz der Schule. Wie soll das funktionieren, wenn der Provider doch nur eine gültige Internet-Adresse erteilt? Um dieses Rätsel zu lösen, gilt es zunächst noch, die beiden letzten Abfragen bei der Einrichtung des PPP-Zugangs zu diskutieren.

Die Übersetzung von Name in Adresse nimmt ein Nameserver vor. Dieser Dienst verwendet eine im ganzen Internet verteilte Datenbank, in der Adressen und Namen einander zugeordnet sind. Auch auf dem c't/ODS-Kommunikationsserver läuft ein solcher Nameserver. Allerdings wäre es wenig sinnvoll, dort alle Informationen zu den zig Millionen Servern des Internet abzulegen; zum einen reicht der Platz nicht, zum anderen ändern sich die Informationen ständig.

Dieser Nameserver ist daher nur für die Rechner im lokalen Netz der jeweiligen Schule zuständig. Er bekommt jedoch die Internet-Adresse des Nameservers beim Provider mitgeteilt und weiß, daß er jede Anfrage, die nicht in seinen Bereich fällt, an diesen weiterleiten muß. Dabei ist noch nicht einmal sichergestellt, daß der Nameserver des Providers die Antwort geben kann, unter Umständen leitet auch der die Anfrage an einen klügeren `Vorgesetzten´ weiter. Irgendwann erhält der Netscape Browser oder ein anderes Programm, das die Anfrage gestartet hat, jedenfalls eine Antwort zurück.

Um die Anfragen nach außen zu minimieren, merkt sich der Nameserver des Kommunikationsservers die zu einem Namen gehörenden IP-Adressen in einem Cache, so daß dieselbe Adresse nur alle paar Stunden über die Telefonleitung abgefragt wird. In kürzeren Abständen ändert sich die Adreßvergabe im Internet nun wirklich nicht. Die Konfiguration des Nameservers erfolgt über Dateien im Verzeichnis `/etc/named´. Die von uns vorgenommenen Einstellungen müssen aber in der Regel nicht geändert werden.

Ein weiterer Zwischenspeicher, der den Datenverkehr im Internet noch mehr vermindert als der Cache des Nameservers, ist der sogenannte Proxy. Er legt bereits abgerufene WWW-Seiten, soweit sein Plattenplatz ausreicht, lokal ab. Wenn dieselbe Seite dann erneut abgerufen wird, muß sie nicht nochmals über das Internet geholt werden. Da auf populäre Seiten häufig zugegriffen wird, sparen die Provider dadurch Leitungskapazität und können ihre Kunden schneller bedienen. Einige Provider schreiben ihren Kunden die Benutzung des WWW-Proxy sogar vor, andere stellen sie frei.

Die erste Version des Kommunikationsservers verwendet den Proxy, der im ebenfalls installierten WWW-Server (ein Programm namens Apache) integriert ist. Seine Konfigurationsdaten liegen im Verzeichnis `/etc/httpd´. Es handelt sich dabei jedoch um eine etwas betagte Version, die mit einigen Nachteilen belastet ist: Sie kann nur WWW-Anfragen bedienen, jedoch keine Dateien über das File Transmission Protocol (FTP) liefern. Diese im Internet verbreitete Möglichkeit zur Datenübertragung steht den Schülern daher nicht zur Verfügung. Außerdem beklagen viele Schulen, daß kein Offline-Betrieb möglich ist. Besteht also keine Verbindung zum Internet, liefert der Proxy auch keine WWW-Seiten, die bereits lokal geladen sind.

Das liegt daran, daß der Server bei jeder Anfrage zunächst versucht, die IP-Adresse des WWW-Servers zu bestimmen. Diese Anfrage versucht er an den Nameserver des Providers weiterzuleiten. Sofern keine Verbindung zum Internet besteht, schlägt dieser Versuch jedoch fehl. Anstatt dann die Daten aus dem lokalen Cache zu holen, schickt er eine Fehlermeldung an den Browser. Dieses Problem werden wir demnächst durch ein Update beheben. Mit dem neuen Proxy kann der Lehrer dann bereits vor der Unterrichtsstunde die benötigten Seiten aus dem Internet holen, so daß den Schülern dann nur das vorgegebene Material zur Verfügung steht und keine zusätzlichen Telefongebühren mehr anfallen. Zudem kann der neue Proxy auch FTP-Zugriffe bedienen und arbeitet deutlich schneller.

Weitere Einschränkungen werden jedoch bestehen bleiben: Falls WWW-Seiten Verweise auf Online-Dienste enthalten (beispielsweise in der Form (<A HREF=telnet://xyz.de>), sind diese nicht erreichbar, da Telnet nicht über einen Proxy arbeitet. Das ist allerdings kein großes Problem, da solche Seiten nur sehr selten vorkommen.

Java-Applets, das sind Benutzerschnittstellen zu verschiedenen Dienstleistungen, stellen ein größeres Problem dar, da diese Programme, die dynamisch vom WWW-Server geladen werden, in zunehmendem Maße IP-Verbindungen zum Server aufbauen wollen. Auch diese Verbindungen scheitern, weil Daten vom entfernten Server nicht ihren Weg zurück zum Arbeitsplatz im lokalen Schulnetz finden.


Vergrößern
Die Netscape-Browser im lokalen Schulnetz müssen so eingestellt werden, daß sie den Kommunikationsserver als Proxy verwenden. Denn nur er kann überhaupt auf das Internet zugreifen.

Post und Neuigkeiten

Auf dem Kommunikationsserver laufen drei Server-Programme: Eines ist für den Transport von EMail zuständig; es heißt `smail´ und verwendet das Protokoll SMTP (Simple Mail Transfer Protocol). Es wird durch Dateien in `/etc/smail´ konfiguriert. Ferner ein Server zum Lesen von EMail im lokalen Netz, der POP, das Post Office Protocol, realisiert. Außerdem ist der Server `inn´ für den Transport und die Verwaltung von Artikeln in Newsgruppen verantwortlich; seine Konfigurationsdateien liegen in `/etc/news´. Es spricht NNTP, das Net News Transport Protocol.

Das EMail-Programm auf einer Arbeitsstation im LAN (beispielsweise der Netscape Navigator) liest die Post des Anwenders aus dessen Post-Datei auf dem Kommunikationsserver mit dem POP-Protokoll. Der Server gewährt den Zugriff zu diesen Daten nur nach Eingabe eines Paßworts, welches das EMail-Programm vom Anwender abfragt und dem Kommunikationsserver über das Netz schickt. Umgekehrt sendet das EMail-Programm alle Briefe, die der Anwender schreibt, an den SMTP-Server. Dieser erkennt, ob der Brief an einen der Anwender im lokalen Netz geht und stellt ihn dann direkt zu, oder ob die Nachricht nach außen geschickt werden muß. Dann wird es interessant, doch dazu gleich mehr.

Ähnlich verlaufen Zugriffe auf die Newsgruppen: Das Client-Programm auf einer Arbeitsstation `redet´ nur mit dem NNTP-Server auf dem Kommunikationsserver. In keinem dieser Fälle benötigen die Anwender im Schulnetz einen Zugang zum Internet. Die gesamte Kommunikation läuft innerhalb des LAN ab und kostet keine Telefoneinheit.

Das ganze Internet spricht beim Mail-Transport SMTP, der Kommunikationsserver ebenfalls. Es gibt also eigentlich kein Problem: Der SMTP-Server des Absenders setzt sich direkt mit dem Kommunikationsserver in Verbindung und übermittelt ihm die Nachricht. Dies funktioniert jedoch nur `eigentlich´. Denn falls die Schule eine dynamische IP-Adresse hat, weiß der Sender überhaupt nicht, wie er sie erreichen soll.

Ein Internet-System, das EMail versenden will, erkundigt sich beim Nameserver nach dem für die Empfängeradresse zuständigen SMTP-Server. Die Zuordnung EMail-Adresse/SMTP-Server hat dabei nichts mit der Zuordnung IP-Domain/IP-Adresse zu tun; es handelt sich um zwei getrennte Datenbanken. Insbesondere hat die EMail-Adresse nichts zu tun mit dem physischen Anschluß eines Rechners bei irgendeinem Provider. Das bedeutet: Die EMail-Adresse bleibt von der dynamischen Adreßvergabe oder anderen Einschränkungen durch den Provider völlig unberührt.

Jeder Internet-Nutzer kann dadurch seine EMail völlig unabhängig vom Provider organisieren: Er muß nur dafür sorgen, daß er in einer richtigen EMail-Domain eingetragen ist, bei Schulen beispielsweise in `schule.de´. Er benötigt allerdings einen ständig erreichbaren SMTP-Server im Internet, der eintreffende Briefe zwischenspeichert und bei dem er sie abrufen kann. Ähnlich wie beim Nameservice oder Proxy gilt: Der EMail-Server kann direkt beim Provider stehen, er kann aber auch irgendwo anders im Internet von einer fremden Institution betrieben werden, die diesen Dienst für die Schule erbringt.

Durch das Konzept des Kommunikationsservers genügt der Schule ein einfacher, preiswerter Internet-Zugang, mit nur einer IP-Adresse. Dazu bieten die Provider jedoch auch nur eine einzige EMail-Adresse an - zu wenig, um darüber eine ganze Schar von Lehrern und Schülern zu erreichen. Hinzu kommt die lästige Einschränkung einer diktierten EMail-Adresse: Angenommen die Kästner-Schule erhält über die Universität in Tripstrill Zugang zum Internet, dann lautete ihre EMail-Adresse `kaestner-schule.informatik.uni-tripstrill.de´.

Nun ist aber die Kästner-Schule garantiert keine Arbeitsgruppe des Fachbereichs Informatik der Uni Tripstrill. Schlimmer noch: Wenn die Schule nach einem Jahr zu einem anderen Provider wechselt, ändert sich die Adresse zwangsläufig. Alle Netzteilnehmer, welche die alte in ihren Adreßbüchern führen, erreichen die Schule dann nicht mehr.

Die Schule sollte deshalb in eigenem Interesse eine `logische´ Adresse haben: `kaestner-schule.tt.he.schule.de´, vorausgesetzt `TT´ sei das Autokennzeichen von Tripstrill und diese Stadt liege in Hessen (was beides nicht der Fall ist). Diese Adresse wird vom Offenen Deutschen Schulnetz vergeben und bleibt auch bei einem Providerwechsel unverändert bestehen.

Die Post an alle Mailadressen der Form `<Anwender>@kaestner-schule.tt.he.schule.de´ muß also auf einem SMTP-System im Internet ankommen und dort aus dem SMTP-Verfahren herausgenommen werden. Die Nachrichten liegen dann - wie zu alten Mailbox- Zeiten - gesammelt bereit, so daß die Schule sie mit einem Anruf komplett abholen kann. Dabei lassen sich die Daten komprimieren, um die Übertragungsdauer zu minimieren.


Vergrößern
Empfang einer EMail mit dem c't/ODS-Kommunikationsserver: Obwohl eine Verbindung über den Internet-Zugang des Providers besteht (roter Pfeil), erreichen die SMTP-Systeme der Anwender die Schule nicht direkt. Vielmehr wird die EMail auf einem fremden System im Internet (beim Provider oder einem anderen Dienstleister) gesammelt und per UUCP dann zum Kommunikationsserver übertragen.

Der Versand von EMails nach außen erfolgt auf demselben Wege: Der Kommunikationsserver sammelt alle anfallenden Nachrichten, bis das nächste Mal eine UUCP-Verbindung zu dem SMTP-Host im Internet aufgebaut wird. Dann überträgt er alle Dateien gesammelt. Die Verwaltung der Newsgruppen erfolgt analog: die Diskussionsbeiträge in den einzelnen Foren werden genauso behandelt wie EMails, also per UUCP von und zum EMail-Host übertragen. Um die Datenmengen möglichst klein zu halten, muß die Schule mit dem Systemverwalter des EMail-(und News-)Host genau abklären, welche Newsgruppen übertragen werden sollen. Denn für `alt.sex.bestiality´ gibt es an Schulen wohl keine Verwendung.

Viele Provider tun sich mit UUCP allerdings schwer; sie stellen diesen Service gar nicht oder nur gegen eine zusätzliche Gebühr zur Verfügung. Doch wenn Ihr Provider Ihnen kein UUCP anbietet, brauchen Sie nicht zu verzagen: Suchen Sie sich eine andere Institution, die Ihnen diese Leistung bietet.

Das Offene Deutsche Schulnetz ist dabei, eine entsprechende Infrastruktur aufzubauen, die insbesondere den an T-Online angeschlossenen Schulen vernünftigen EMail-Zugang bieten soll. Die Finanzierung ist allerdings noch unklar; die Bundesinitiative `Schulen ans Netz e. V.´ stellt für derartige Initiativen keine Mittel zur Verfügung. Wir suchen Sponsoren und werden im Erfolgsfall beschreiben, wie sie Zugang zu diesem Service erhalten können. Eine vorbildliche Lösung dieses Problems (auf die beschriebene Weise) bietet derzeit der DFN-Verein mit seinem WIN-Shuttle-Dienst.

Da das UUCP andere Zugangsdaten benutzt als die Verbindung zum Provider, muß es auch separat eingestellt werden. Dazu dient das Menü `System/Einstellen/UUCP´. Dort geben Sie den UUCP-Namen des Systems, das sie anrufen, eine Kurzbezeichnung, die in den Menüs des Kommunikationsservers erscheint, eine Anwenderkennung samt Paßwort sowie ein Chat-Skript zur Steuerung des Anmeldevorgangs (sofern das vorgegebene Default-Skript nicht funktioniert) ein. Diese Daten müssen Sie mit dem Dienstleister, der Ihnen den UUCP-Zugang zur Verfügung stellt, abklären.

Die letzte Einstellung für UUCP betrifft den Server, von dem der Dienstleister Sie mit Newsgruppen versorgt. Daran kann der Kommunikationsserver dann erkennen, welche News er von außen bezogen hat, und sendet diese nicht unnötigerweise wieder zurück. Die Konfigurationsdateien für UUCP befinden sich im Verzeichnis `/etc/uucp´. Den UUCP-Namen des eigenen Systems (ebenfalls mit dem Dienstleister abgesprochen) gibt man zusammen mit dem Domain-Namen ein (im Menü System/Einstellen/Name).

ad c't 3/97, S. 302

Anzeige