- 1. Grundlagen
- 2. Anwendungen
- 3. Betrieb der IP-Protokolle im MHN
- 4. Weitere Informationsquellen
1.Grundlagen
- 1.1.1: Historie
Das Internet wurde Ende der 60er Jahre aus einem Forschungsprojekt des amerikanischen Verteidigungsministeriums namens ARPAnet geboren. Das Ziel dieses experimentellen Projektes war, ein Netzsystem zu entwickeln, das auch partielle Ausfälle verkraften konnte. Kommunikation sollte immer nur zwischen einem Sender und einem Empfänger stattfinden. Das Netz dazwischen wurde als unsicher angesehen. Jegliche Verantwortung für die richtige Datenübertragung wurde den beiden Endpunkten der Kommunikation, Sender und Empfänger, auferlegt. Dabei sollte jeder Rechner auf dem Netz mit jedem anderen kommunizieren können.
Mit diesen Vorgaben entstand die Internet Protokoll Spezifikation TCP/IP. Da etwa zur gleichen Zeit an der University of California an einem neuen Betriebssystem mit Namen UNIX entwickelt wurde, konnte diese Netzwerksoftware gleich fester Bestandteil dieses Betriebssystems werden.
Ein weiterer Meilenstein beim Aufbau des Internet war die Gründung des NSFNET der National Science Foundation (NSF) Ende der achtziger Jahre, die damit fünf neugegründete Super Computer Centers den amerikanischen Hochschulen zugänglich machte. Dies war ein wichtiger Schritt, da bis zu diesem Zeitpunkt Super Computer nur der militärischen Forschung und einigen wenigen Anwendern sehr großer Firmen zur Verfügung gestanden waren.
Parallel zu den Entwicklungen im ARPAnet und NSFNET arbeitete die ISO (International Organisation for Standardization) seit den achtziger Jahren an der Standardisierung der Rechner-Kommunikation. Die Arbeiten mündeten in der Definition des sogenannten ISO/OSI Referenzmodells, welches die Kommunikation in 7 funktionellen Schichten beschreibt. Die Entwicklung entsprechender OSI-Protokolle und Anwendungen gestaltete sich aber als ein äußerst zäher Prozeß, der bis heute nicht als abgeschlossen anzusehen ist. Hersteller und Anwender konnten darauf natürlich nicht warten und so wurde die Internet Protokoll-Familie TCP/IP im Lauf der Zeit in immer mehr Betriebssystemen implementiert. TCP/IP entwickelte sich so unabhängig von den offiziellen Standardisierungsbestrebungen zum Quasi-Standard.
Erst 1991 wurden die Protokolle für das World Wide Web (WWW) entwickelt, den heute populärsten Internet-Dienst. Durch das WWW wurde das Internet in den letzten Jahren zum modernen Kommunikationsmittel für jedermann.
- 1.1.2 Struktur
Das Internet, wie es sich heute darstellt, ist ein Geflecht aus über 1 Million einzelnen Netzen. Es wird geschätzt, daß zur Zeit mehr als 40 Mio. Rechner daran angeschlossen sind und es über 100 Millionen Nutzer gibt. In den letzten Jahren fand etwa alle 9 Monate eine Verdopplung der Anzahl der angeschlossenen Rechner statt.
Diese an das Internet angeschlossenen Rechner sind oft in lokale Netze (LAN) eingebunden. Organisatorisch zusammengehörende LANs sind zumeist in regionalen Netzwerkverbunden organisiert (MAN), welche wiederum mindestens einen überregionalen Zugang besitzen, den WAN (Wide Area Network) Anschluß. Die Verbindungskomponenten, die LANs zu MANs und diese wiederum zum WAN kombinieren, werden Router genannt. Die Funktionen eines Routers werden im Abschnitt 1.2.1 detaillierter behandelt. Sehr oft werden diesen Teilnetzen Namen gegeben [z.B. Europanet, B-WiN (Deutsches Breitband-Wissenschaftsnetz), MWN (Münchner Wissenschaftsnetz)]. Meist sind diese Netze auch für anderen als den Internetverkehr eingerichtet. So werden auf dem Münchner Wissenschaftsnetz neben dem Internetverkehr auch die Daten des München-weiten Novell-Netzwerkverbunds sowie anderer Netzwerkprotokolle transportiert. Das weltumspannende Internet bietet so ein homogenes Erscheinungsbild, obwohl es technisch auf einem heterogenen Konglomerat an Netzwerken aufgebaut ist.
Das MWN ist mit einer Bandbreite von 155 MBit/s am deutschen Wissenschaftsnetz B-WiN angebunden. Das B-WiN besitzt seinerseits breitbandige Verbindungen zu den anderen Teilen des Internets. Die wichtigsten sind hier die Leitungen nach USA (155 MBit/s), zum DE-CIX (68 MBit/s) und zu den anderen europäischen Wissenschaftsnetzen (155 MBit/s). Eine ausführlichen Beschreibung der Anbindung des MWN an das weltweite Internet finden Sie in einem Artikel der LRZ-Mitteilungen vom März 1999
- 1.1.3 Administration
Es erhebt sich natürlich die Frage, wer im Internet bestimmt, wie was gemacht wird. Dazu gibt es keinen Präsidenten oder Direktor, sondern allgemein anerkannte Arbeitskreise, die ihre Mitglieder aus der Benutzerschaft rekrutieren. Die Entscheidungen dieser Versammlungen werden von den Internet-Anwendern als verbindlich akzeptiert. Es steht jedem frei, ebenfalls an der Entwicklung des Internet mitzuarbeiten. Dies führt insbesondere dazu, daß Firmen sich in diese Arbeitskreise einbringen, um möglichst früh die Weichen "richtig" stellen zu können.
Das höchste Gremium im Internet ist das Internet Architecture Board (IAB). Es segnet Entscheidungen über Standards und Adreßvergabe ab und läßt diese Entscheidungen bekannt geben. Technische und betriebliche Probleme werden zuvor in der Internet Engineering Task Force (IETF) behandelt, deren Treffen für jedermann offen sind. Hier werden Standards entwickelt und dokumentiert. Die Standards werden dann in sogenannten RFCs (Request for Comments) niedergelegt. Die Verwaltung der Namens- und Adreßräume wird durch die Internet Corporation for Assigned Names and Numbers (ICANN) geregelt. Als ausführende Institutionen arbeiten sogenannte NICs (Network Information Centers) und NOCs (Network Operation Centers), die auf weltweiter, kontinentaler, nationaler und regionaler Ebene existieren.
Die Aufgabe des NIC ist die Vergabe und Koordination von eindeutigen Adressen und Namen im Internet. Z.B. vergibt das zentrale Internic in USA ganze Adreßbereiche an das europäische NIC, das RIPE-NCC (Reseaux IP Europeens - Network Coordination Center), das wiederum die deutsche Organisation, das DE-NIC, mit einem Teil dieses Adreßbereiches beglückt. Das DE-NIC hat wiederum die Möglichkeit, eigenständig aus diesem Bereich Adressen zu vergeben, z.B. an das LRZ, welches wiederum diese Adressen auf die Institute der Münchener Universitäten verteilt. Das DE-NIC wird zur Zeit von der Universität Karlsruhe betrieben.
Das NOC kümmert sich um den Betrieb des Netzes. Dazu gehören die Konfiguration der Netzkomponenten ( i.d.R. Router), die Behebung von Netzfehlern und die Beratung und Koordination der Netzteilnehmer. Das deutsche NOC für den wissenschaftlichen Bereich, das DFN-NOC, ist zur Zeit an der Universität Stuttgart angesiedelt. Dieses NOC betreut natürlich auch den wichtigen internationalen Anschluß des WiN. Das LRZ ist als NOC für das Münchner Wissenschaftsnetz (MWN) anzusehen.
- 1.1.4 Benutzungsrichtlinien im Internet
Da das Internet ein Netz von Netzwerken ist, gibt es von Region zu Region unterschiedliche Benutzungsregeln, die den Gebrauch bestimmen. Große Teile des Internets werden von der öffentlichen Hand bezahlt, so daß z.B. der kommerzielle Gebrauch dieser Netze von vorneherein beschränkt sein muß. Das Deutsche Wissenschaftsnetz, betrieben von der Deutschen Telekom, wird bezahlt vom Verein zur Förderung eines Deutschen Forschungsnetzes (DFN-Verein) durch die Anschlußgebühren, die die Mitglieder des Vereins entrichten. Finanziert wird der Verein hauptsächlich durch das BMFT und die Beiträge seiner Mitglieder. Diese sind zum größten Teil die deutschen Universitäten, aber auch Forschungsabteilungen von Firmen können Mitglied im DFN-Verein werden. Der Gebrauch des WiNs ist also zu Forschungszwecken auch kommerziellen Einrichtungen erlaubt. Rein kommerzielle Zwecke wie Werbung, Angebots- und Rechnungsstellung sind dagegen im WiN nicht gestattet. Die Grauzone ist hier natürlich beliebig groß. Ähnliche Strukturen findet man überall im Internet. So wurde in USA vor ein paar Jahren beschlossen, die bis zu diesem Zeitpunkt parallel gefahrenen Netzwerke jeder Bundesbehörde im Bereich Lehre und Forschung (NFSNET, NASA Science Internet, ...) zusammenzulegen, um das NREN zu bilden (National Research and Education Network). Das Netz darf zu Zwecken der Forschung und Lehre oder der Unterstützung der Forschung und Lehre verwendet werden. Dieser zweite Teil ist sehr wichtig, da er Firmen erlaubt, Kundenkontake zu Forschungsinstitutionen zu pflegen.
Auch für den einzelnen, "authorisierten" Benutzer gibt es einige Dinge beim Gebrauch des Netzes zu beachten. Der Aufbau des Internet läßt sehr viel Raum für Individualismus, birgt aber auch gleichzeitig viele Gefahren für Mißbrauch. Formen einer unsachgemäßen Nutzung sind etwa
Vielfach führen die Anwendungen der beiden ersten Kategorien zu einer Belastung des Netzes, die anderen Netzwerkbenutzern oder den NOCs nicht unbemerkt bleibt. In der Regel folgt eine freundliche Mitteilung an den Verursacher, die störende Netznutzung zu unterlassen. Falls keine Reaktion erfolgt, wird man sich noch öfters bemühen, mit dem Nutzer ins Gespräch zu kommen, bis vom zuständigen NOC der Zugang zum Internet für diesen Nutzer im Interesse der anderen gesperrt werden muß.Exzessive Nutzung des Netzes (eventuell unbeabsichtigt durch fehlerhafte oder unangepaßte Anwendungen) Beispiele:
Andauernde sich wiederholende Abfragen an Server (durch falsche Konfiguration)
Einbinden von fremden Dateisystemen in das eigene über WAN (mit NFS)Betreiben von Netzwerkspielen Moralisch verwerfliche Nutzung Beipiele:
Verbreitung gewaltverherrlichenden und diskriminierenden Gedankenguts
Verbreitung pornografischen MaterialsIm Sinne der Schonung einer für viele Hochschulangehörige wertvollen Ressource bitten wir die Nutzer des MHN daher um einen sachgemäßen und verantwortungsvollen Gebrauch ! Im übrigen sei an dieser Stelle auf die folgenden Regeln hingewiesen, die für alle Nutzer des Kommunikationsnetzes verbindlich sind:
Benutzungsrichtlinien für die Informationsverarbeitungssysteme des LRZ
Leitfaden zur verantwortungsvollen Nutzung von Datennetzen
DFN-Betriebsregeln für die Nutzung der Netzdienste - 1.1.5 Sicherheit
Jeder Hochschulangehörige, der seinen Rechner an das MHN anschließt, sich eine Internetadresse sowie die TCP/IP-Software besorgt und installiert, muß sich darüber im klaren sein, daß er damit seinen Rechner potentiell mit einigen Millionen anderer Rechner in Verbindung bringt. So wie man selbst alle möglichen fremden Rechner erreichen kann, ist man auch für jedermann kontaktierbar. Für Nutzer von UNIX-Maschinen, bei denen in der Regel Server-Prozesse automatisch im Hintergrund laufen, heißt dies, daß sie ihre Maschinen gegen unberechtigten Gebrauch zu schützen haben. Das Internet ist offen und um den Individualismus auf dem Netz sowenig wie möglich einzuschränken, müssen Sicherheitsvorkehrungen an den Endgeräten vorgenommen werden. Wichtigste Maßnahme bei UNIX-Rechnern ist der Schutz des Zugangs durch Wahl geeigneter Paßwörter (mind. 6 Zeichen lang, bedeutungsloser Mix aus Groß-, Kleinbuchstaben und Ziffern). Weitere Sicherheitsvorkehrungen können in den Manualen der Maschinen nachgeschlagen werden.
In der Betriebssystemsoftware (und auch der Anwendungssoftware) treten immer wieder Fehler auf, die unauthorisierten Zugang für "Hacker" durch Ausnutzen von Sicherheitslöchern zuläßt. Eine Hardware-unabhängige Sammlung dieser Fehler sowie die Initiative zur Behebung derselben unternehmen die CERTs (Computer Emergency Response Team). Wie viele Einrichtungen im Internet existieren CERTs auf mehreren Ebenen. Das deutsche CERT (DFN-CERT) ist an der UNI Hamburg lokalisiert.
Sicherheits-Aspekte aus Sicht des Internet-Benutzers sind in der Studie des Landes Baden-Württemberg Sicherheit für Benutzer der Internet-Technologie zusammengestellt.
- 1.2.1 Internet Protocol IP
Hier soll kurz erklärt werden, wie die zu übertragenden Informationen im Internet von einem auf den anderen Rechner kommen. Daten werden im Internet paketweise übertragen. Man spricht daher von einem paketvermittelten Netz.
- Zur Veranschaulichung ein Gegenbeispiel und ein Beispiel:
- Im Telefonnetz wird für jedes Gespräch eine Leitung zwischen zwei
Gesprächspartnern benötigt. Diese Leitung bleibt auch belegt, wenn keine
Information übertragen wird, also keiner spricht. Hier handelt es sich um
ein leitungsvermitteltes Netz.
- Im Briefverkehr wird dagegen ganz anders vorgegangen. Wenn Informationsübertragung ansteht, wird ein Brief geschrieben und dieser mit einer Adresse versehen. Sodann wird dieses Informationspaket dem Netz überlassen, indem man es in einen Briefkasten wirft. Das örtliche Postamt entscheidet dann aufgrund der Empfängeradresse, ob der Brief direkt an den Empfänger (wenn dieser also im Versorgungsbereich dieses Postamtes wohnt) auszuliefern ist, oder durch Einschalten von mehr oder weniger Zwischenstationen. In der Regel findet der Brief dann ein Postamt, das die Auslieferung des Briefes an den Empfänger aufgrund der Adresse vornehmen kann. Schwierigkeiten bei der Auslieferung können dem Absender aufgrund der Absendeadresse mitgeteilt werden. In den Adressen stecken Anteile, die das Empfänger-Postamt charakterisieren (Postleitzahl, Ort) und Anteile, die den Empfänger im Bereich dieses Postamtes festlegen. Diese Art der Informationsübertragung hat große Parallelen zur paketvermittelten Kommunikation im Internet.
- Beispiele:
- 141.84.101.2
- 129.187.10.25
Jedes Datenpaket steckt quasi in einem "Umschlag", der Absende- und Empfängeradressen enthält. Diese Adressen-Information wird den Nutzdaten vorangestellt, so daß jede Komponente im Netz, die das Protokoll TCP/IP beherrscht, aus dem Anfang des Datenpaketes herauslesen kann, woher das Paket kommt und wohin es soll. Komponenten, die das können und die zusätzlich die Möglichkeit haben, Datenpakete auf verschiedenen Wegen weiterzuschicken, sind die obengenannten Router. Diese nehmen von den Adressen immer erst die Netzanteile und entscheiden, ob das Netz direkt angeschlossen ist oder nicht und - wenn es nicht direkt angeschlossen sein sollte - an welchen nächsten Router es zu schicken ist. Dies kann man wiederum in Analogie zum Beispiel der Briefpost sehen.
Das Internet Protocol IP ist also hauptverantwortlich dafür, daß Daten den richtigen Weg im Internet finden. Wenn ein Datenpaket nur korrekt in einen "IP-Briefumschlag" gesteckt wird, kann es beruhigt dem Netz übergeben werden. Was aber ist, wenn mal ein Datenpaket verloren geht ? Wie versendet man überhaupt mehr Daten als die maximale Paketgröße von 1500 Bytes ? Was passiert, wenn auf einer größeren Maschine, die mehrere Benutzer gleichzeitig haben kann, Datenpakete für verschiedene Benutzer eintreffen? Hierfür gibt es die Transportprotokolle TCP und UDP.
- 1.2.2 Transportprotokolle TCP und UDP
Innerhalb jedes IP-Briefumschlages befindet sich nun ein weiterer Briefumschlag, der vom Transportprotokoll geschrieben wird. In den meisten Fällen handelt es sich dabei um TCP. Auf diesem Umschlag steht die Information, die auf die obengenannten Probleme eingeht. Im TCP-Briefumschlag befinden sich dann endgültig die zu übertragenden Daten.
Falls man also eine große Menge an Daten zu übertragen hat, wird diese in Pakete gestückelt und die Pakete mit Nummern versehen. Die Nummern stehen dann auf dem TCP-Briefumschlag, damit die Information auf der Empfängerseite wieder richtig zusammengehängt werden kann. Vom Empfänger muß für jedes Paket eine Empfangsbestätigung geschickt werden, damit der Sender weiterarbeiten kann. Fehlt die Empfangsbestätigung für eine Nummer, so wird diese nach einer gewissen Zeit noch einmal gesandt.
Weiter berechnet TCP eine Prüfsumme (eine Art Quersumme über alle Daten), die ebenfalls auf den TCP-Briefumschlag geschrieben wird. Der Empfänger berechnet die Prüfsumme ebenfalls und nimmt das Paket nur an, wenn er zum selben Ergebnis wie der Sender kommt.Einzelne Verbindungen zwischen zwei Programmen oder zwei Benutzern werden durch sog. Portnummern gekennzeichnet, die auch auf dem TCP-Briefumschlag hinterlegt sind. Mit dieser Information können Daten für verschiedene Programme oder Benutzer auf derselben Maschine unterschieden werden.
Diese und weitere Eigenschaften - die hier darzustellen zu sehr ins Detail führen würde - von TCP machen das Verfahren der Datenübertragung allerdings auch recht aufwendig. Außerdem können (z.B. durch Warten auf die Empfangsbestätigung) durch TCP auch Verzögerungen auftreten.
Es gibt nun Fälle, in denen sich der Aufwand nicht lohnt und stattdessen eine schnelle Übertragung sehr wichtig ist und auch möglich erscheint (weil z.B. die Leitung sehr stabil und schnell ist). Für diese Fälle gibt es das Transportprotokoll UDP. Hier existieren keine Empfangsbestätigungen. Die Anwendung, also das Programm, das UDP benutzt, muß damit fertig werden, wenn gesendete Daten nicht ankommen. Dafür können die Daten ohne großen Aufwand beliebig schnell ins Netz hinausgeschoben werden.
- 1.2.3 Domain Name System (DNS)
In den vorigen Abschnitten wurde erklärt, wie Information im Internet von einem auf das andere Gerät, ja vom einzelnen Anwendungsprogramm zum korrekten Partner findet. Es mag vielleicht noch nicht ganz klar geworden zu sein, was der einzelne (menschliche) Benutzer von Internet-Diensten nun tatsächlich tun muß und was die Protokolle für ihn automatisch tun. Nun, in der Regel startet der Benutzer ein Anwendungsprogramm für einen Internet-Dienst (siehe 2.) und gibt eine Zieladresse (eines mehr oder weniger entfernten Rechners) dazu ein, mit der diese Internetanwendung betrieben werden soll. Die internen Dinge der Transportprotokolle sowie die Absendeadresse, die Paketierung usw. werden automatisch von den Protokollen (in Form von speicherresidenten Programmen) eingefügt.
Es hat sich ziemlich früh herausgestellt, daß menschliche Benutzer die IP-Adressen nicht benutzen wollen, sondern Namen bevorzugen. Außerdem ist es ein großer Nachteil der IP-Adressen, daß aus ihnen keinerlei geographische Information zu entnehmen ist. Man sieht einer Zieladresse nicht an, ob sie in Australien oder in Regensburg lokalisiert ist, außer man kennt zufällig die gewählten Zahlen. Es wurde daher das Domain Name System (DNS) entwickelt, das den Aufbau von Rechnernamen regelt. Es ordnet jedem (weltweit eindeutigen) Namen eine IP-Adresse zu. Dabei gibt es einige Varianten. Eine Maschine mit einer IP-Adresse kann mehrere Funktionen haben und daher auch mehrere Namen, die auf diese Funktionen hinweisen. Genauso kann eine Maschine (z.B. ein Router) viele IP-Adressen haben, aber nur einen Namen.
Die Namen im DNS sind hierarchisch aufgebaut. Das gesamte Internet ist in Domains aufgeteilt, die wiederum durch Subdomains strukturiert werden. In den Subdomains setzt sich die Strukturierung fort. Diese Hierarchie spiegelt sich im Namen wieder. Die entsprechenden Domains werden durch Punkt getrennt.
- Beispiele:
- cezanne.pst.informatik.uni-muenchen.de
- pollux.edv.agrar.tu-muenchen.de
com Kommerzielle Organisationen edu (education) Schulen und Hochschulen gov (government) Regierungsinstitutionen mil militärische Einrichtungen net Netzwerk betreffende Organisationen org andere
Für die Aufnahme einer Verbindung zwischen zwei Rechnern muß in jedem Fall der Rechnername in eine zugehörige IP-Adresse umgewandelt werden. Aus Sicherheitsaspekten ist es manchmal wünschenswert, auch den umgekehrten Weg zu gehen, nämlich zu einer sich meldenden Adresse den Namen und damit die organisatorische Zugehörigkeit offenzulegen.Damit das DNS funktioniert, muß es Instanzen geben, die Namen in IP-Adressen und IP-Adressen in Namen umwandeln ("auflösen") können. Diese Instanzen sind durch Programme realisiert, die an größeren Maschinen ständig (meist im Hintergrund) im Betrieb sind und "Nameserver" heißen. Aus Zuverlässigkeitsgründen sollten für jede eingerichtete Domain mindestens zwei Nameserver, ein Primaryserver und ein Secondaryserver, existieren. Jeder Rechner, der an das Internet angeschlossen wird, muß die Adresse eines oder mehrerer Nameserver wissen, damit die Anwendungen auf diesem Rechner mit Namen benutzt werden können. Die Nameserver sind für bestimmte Bereiche - domains - zuständig (Institute, Organisationen, Regionen) und haben Kontakt zu anderen Nameservern, so daß jeder Name aufgelöst werden kann. Die Nameserver für die Domains uni-muenchen, tu-muenchen, fh-muenchen, badw-muenchen und fh-weihenstephan haben die Adressen:
- 129.187.10.25 (München)
- 129.187.16.1 (München)
- 141.40.10.35 (Weihenstephan)
- 129.187.16.1 (München)
Um einen Nameserver abfragen zu können, ist eine spezielle Software erforderlich, der sogenannte Name-Resolver. Dieser Resolver kennt sowohl den Namen der eigenen Domain als auch einige Nameserver, an die zwecks Namensauflösung ein entsprechender Request zu schicken ist. Anschließend kommt die Antwort zurück oder - falls der befragte Server keine rekursiven Anfragen durchführen kann oder soll - ein Verweis auf einen anderen Nameserver, falls z.B. der gerufene Server nicht selbst für die gewünschte (Sub-) Domain zuständig ist aber den Zuständigen weiß.
Folgendes ist bei der Verwendung eines Namens, z.B. bei einem Telnet- oder Ftp-Aufruf (telnet <Rechnername>, ftp <Rechnername>, s.u.), zu beachten: Wird für <Rechnername> nur ein Name ohne '.' am Ende verwendet, ergänzt die TCP/IP-Software diesen Namen um den Namen der Domain, in der der Rechner selbst liegt. Erreicht den Nameserver eine Anfrage mit einem Namen ohne '.', sucht er in den Tabellen der Domain, zu der er selbst gehört. Wird z.B. von dem PC mit dem Namen wd-105.lrz-muenchen.de der Aufruf telnet sun1 getätigt, um die Sun in der Informatik zu erreichen, schickt der PC an seinen zugehörigen Nameserver die Anfrage nach der Adresse für den Namen sun1.lrz-muenchen.de. Falls nun zufälligerweise solch ein Name existiert (ist hier der Fall) , erhält der PC eine Adresse, die er nicht gesucht hat oder - falls der Name nicht existiert - die Meldung: unkown host name. Um die richtige zu erhalten, muß der telnet-Aufruf also
telnet sun1.informatik.tu-muenchen.de
lauten. Damit die Software schließlich auch 'weiß', an welchen Nameserver - hier z.B. die Rechner mit den Adressen 129.187.10.25 und 129.187.16.1 - sie sich zwecks Auflösung von Rechnernamen wenden kann, können meist mehrere Adressen von Nameservern konfiguriert werden.
Der Name-Resolver ist i.d.R. automatisch Teil der TCP/IP Software und wird durch Eintrag des eigenen Hostnamens, der eigenen Domain und der zuständigen Nameserver konfiguriert.
Weiterhin gibt es auch die Möglichkeit, Nameserver interaktiv abzufragen. Auf PCs mit z.B. der PC/TCP-Software gibt es dazu das Programm host und auf Workstations die Programme nslookup oder dig.
Da durch falsche Konfiguration von Instituts- bzw. Lehrstuhl-Nameservern zeitweise Nameserver und damit auch das Transportnetz außerhalb des LRZ-Netzes unsinnigerweise belastet wurden, ist die Anfrage nach außen nur noch wenigen gut installierten Fakultätsnameservern vorbehalten. Allein von diesen Maschinen ist eine umfassende Nameserver-Abfrage mit z.B. nslookup möglich. Es wird deshalb empfohlen, Benutzern, denen diese Möglichkeit zugestanden werden soll, auf den entsprechenden Servermaschinen geeignete Kennzeichen einzurichten. Außerdem steht jedem Benutzer auf dfvgate.lrz-muenchen.de das Kennzeichen nslook (Paßwort: Leereingabe) zur Nameserver-Abfrage zur Verfügung. Die Syntax der einzelnen Anweisungen kann durch die Eingabe von help abgerufen werden.
Mehr zum DNS finden Sie im Dokument Betrieb des Nameserver-Dienstes im MHN.
- 1.3 Das Client-Server-Prinzip
Die meisten der im folgenden beschriebenen Anwendungen funktionieren nach dem Client-Server-Prinzip. Deshalb soll auf diese Funktionsweise kurz eingegangen werden. Im einfachsten Fall kommunizieren dabei zwei Rechner miteinander, wobei auf dem einen ein Client- und auf dem anderen der Serverprozeß laufen. Diese tauschen Informationen über die TCP/IP - Protokolle aus. Der Clientprozeß ist meistens mit einem Benutzerinterface verbunden (ein Programm, das es einem Benutzer erlaubt, komfortabel Eingaben zu machen und Ausgaben des Anwendungsprogramms zu lesen). Der Client-Prozeß wird in der Regel auch erst bei Bedarf gestartet und versucht dann, Kontakt mit dem Serverprozeß aufzunehmen. Dies setzt natürlich voraus, daß der Server schon "wartet", d.h. ständig an einem System (in der Regel im Hintergrund) speicherresident läuft. Der Server verhält sich also eher passiv und wartet auf die Anfragen eines Clients. Da der Server für seine Aufgaben meistens Zugang zu wichtigen System-Ressourcen (z.B. Filesystem) einer größeren Maschine braucht, sind zur Serverinstallation in der Regel besondere Rechte vonnöten. Der Clientprozeß dagegen ist meist ein recht einfach zu startendes Programm (oft auch für PC) ohne besondere Zugriffsbeschränkungen. Typischerweise kann ein Server mehrere Client-Prozesse parallel bedienen.
2.Anwendungen
- Im folgenden sollen einige Anwendungsprogramme vorgestellt werden, die die
Nutzung von Internet-Diensten ermöglichen. In den Beispielen wird von Geräten
ausgegangen, die direkt an das Ethernet des MHN angeschlossen sind.
Dies kann ein PC sein, der die notwendigen Treiber der TCP/IP Software geladen
hat oder ein X-Terminal. Andere Situationen (mit Workstations oder anderen
Geräten) sind recht ähnlich vorstellbar. Es können hier nur einige
prinzipielle Anwendungsbeispiele zur Verdeutlichung des jeweiligen
Funktionsumfanges aufgezeigt werden. Informationen über die Verwendung von
TCP/IP-Anwendungen über Wählanschlüsse finden Sie in den Dokumenten über den
Modembetrieb
und über ISDN.
Bei den Beispielen sind Zeilen-orientierte Programme dargestellt, die es praktisch unter jeder Systemplattform gibt. Daneben existieren eine Fülle von Bildschirm-orientierten Oberflächen, die intuitiv auf einfache Weise zu bedienen sind, wenn man die zugrunde liegenden Konzepte kennt.
- Das World-Wide Web (WWW) ist die populärste Anwendung im Internet. Es
ermöglicht auf kinderleichte Art und Weise das Entdecken von interessanten
Informationen aller Art, was oft als Internet-Surfen bezeichnet wird.
Das WWW wurde am CERN (dem Europäischen Kernforschungszentrum in Genf)
entwickelt und basiert auf einer Technologie namens Hypertext. Im Hypertext
wird die Information so präsentiert, daß bestimmte (Schlüssel-)wörter eines
Textes zu weiterer Information expandiert werden können. Die Benutzer von
MS-Windows kennen diesen Mechanismus von den üblichen Windows-Hilfe-Dateien.
- FTP
Das WWW ist aber nicht nur ein weiterer verbesserter Informationsservice wie Gopher (s.u.) , sondern auch der Versuch, die gesamte Information im Internet zusammenzufassen und über ein einziges Benutzerinterface zugänglich zu machen. Dazu existieren verschiedene Programme ("Browser" genannt), die das WWW verfügbar machen. An den Workstations des LRZ wird durch Eingabe von netscape ein solcher Browser gestartet. Was man per Voreinstellung dann präsentiert bekommt, ist die Homepage des LRZ-WWW-Servers. Die ausgewählten Wörter sind blau dargestellt und können per Mausklick expandiert werden. Damit beginnt die Reise durch das WWW.
Auf dieser Reise begegnen Sie unter Umständen recht unterschiedlichen Quellen des Internet (FTP, News, Telnet, Gopher ...). WWW ist dabei aber höchst flexibel und kann Ihnen sowohl einen FTP-Server als auch einen Telnet-Zugang, einen News-Reader oder weiteres immer sehr komfortabel präsentieren, so daß es für viele Nutzer nur noch dieses einzige Tool gibt, um im Internet zu recherchieren.
Da man auf Anhieb nicht weiß, wie ein Wort, das man anklickt expandiert wird, kann es sein, daß hinter dem Wort eine große Menge an (z.B. grafischer) Information liegt, die über eine sehr "dünne" Leitung transportiert werden muß, weil das Ziel z.B. sehr weit weg liegt. Dies erkennt man in der untersten Zeile des Anzeigefensters. Wenn man also bemerkt, daß der Transport der Information wahrscheinlich den Aufwand nicht lohnt, so empfiehlt es sich, die Verbindung abzubrechen, indem man mit der Maus auf den roten Knopf rechts in der Buttonleiste klickt. Auf diese Weise läßt sich die wertvolle Resource WAN-Anschluß schonen.
Oft hat man schon eine recht große Anzahl an Bildschirmen und WWW-Schritten hinter sich, bis man an der gewünschten Stelle oder interessanter Information angekommen ist. Um sich einen relativ langen oder umständlichen Weg bis zu dieser Stelle ein zweites Mal zu ersparen, kann man solche Stellen im WWW in der persönlichen "Hotlist" eintragen.
Ein weiteres Merkmal des WWW ist die Schreiboption. Damit ist es möglich, Bestellscheine von Bibliotheken auszufüllen oder Anmeldungen für Konferenzen, über die mit dem WWW-Server vorab informiert wird.
Auch für PCs unter Windows empfehlen wir als WWW-Browser Netscape einzusetzen.
Sie finden weitere vielfältige Informationen über das World Wide Web und den Betrieb des LRZ-WWW-Servers unter /services/netzdienste/www/.
- 2.2.1 FTP mit authorisiertem login
Mit diesem Protokoll können Dateien zwischen dem eigenen System und einem fremden ausgetauscht, gelöscht und umbenannt werden. Weiterhin können der Arbeitskatalog geändert und Inhaltsverzeichnisse übertragen werden. Die möglichen Kommandos innerhalb eines Zeilen-orientierten FTP-Programms erhält man, indem FTP ohne Parameter aufgerufen und anschließend das Kommando 'help' abgesetzt wird. Der Filetransfer zwischen der Sun1 und einem PC sieht dann in etwa so aus:
PC-Prompt>ftp sun1.lrz-muenchen.de Connected to sun1.lrz-muenchen.de 220 sun1 FTP server (SunOS 4.1) ready. Name (sun1:a2824aa): 331 Password required for a2824aa. Password: (Passwordeingabe) 230 User a2824aa logged in. ftp> (ab hier ftp-Kommandos) ftp>pwd 257 "/AM/homesys/home2/a/a2824aa" is current directory (Homedirectory ist das voreingestellte Directory!) ftp>lpwd The current local directory is C:\TCPIP ftp>dir drwx------ 2 a2824aa a2824aa 512 Mar 30 09:27 .elm -rw-r----- 1 a2824aa a2824aa 29 Aug 5 1992 .forward -rw-r--r-- 1 a2824aa a2824aa 0 Apr 14 16:34 .gopherrc drwxr-x--- 2 a2824aa a2824aa 512 Mar 30 1992 .nn ... drwxr-x--- 2 a2824aa a2824aa 512 Mar 29 1992 rfc -rw-r----- 1 a2824aa a2824aa 3359 Dec 9 15:20 yoda -rw-r--r-- 1 a2824aa a2824aa 81 Nov 6 1991 zeilen Transferred 2367 bytes in 1 seconds (18936 bits/sec, 2367 bytes/sec) 226 Transfer complete. ftp>cd rfc 250 CWD command okay: current directory is "rfc". ftp>dir -rw-r--r-- 1 2836 1005 9786 Mar 14 1989 rfc980 -rw-r--r-- 1 2836 1005 20431 Mar 14 1989 rfc983.Z . . Transferred 1462 bytes in 1 seconds (11696 bits/sec, 1462 bytes/sec) 226 Transfer complete. ftp>get rfc980 (Sun1 -> PC) local file (default rfc980):\huhu Transferred 9850 bytes in 1 seconds (78800 bits/sec, 9850 bytes/sec) 226 Transfer complete. ftp>ldir \ ......... ......... HUHU (unter allen angegebenen Files ist auch das unter dem Namen 'HUHU' abgelegte File rfc980) ftp>put \huhu (PC -> Sun1) foreign file (default huhu):rfc980a Transferred 9850 bytes in 1 seconds (78800 bits/sec, 9850 bytes/sec) 226 Transfer complete. ftp>dir -rw-r--r-- 1 2836 1005 9786 Mar 14 1989 rfc980 -rw-r--r-- 1 2836 1005 9786 Mar 14 1989 rfc980a -rw-r--r-- 1 2836 1005 20431 Mar 14 1989 rfc983.Z . . Transferred 1525 bytes in 2 seconds (6100 bits/sec, 763 bytes/sec) 226 Transfer complete. ftp>quit PC-Prompt>
Wie im obigen Beispiel gezeigt, ist beim Login in die Sun1 $HOME das voreingestellte Verzeichnis. Bei den Befehlen 'put' und 'get' kann als zweiter Parameter sofort das gewünschte Zielverzeichnis und der neue Dateiname angegeben werden. Geschieht dies nicht, fragt das Programm nach. Der Default ist, daß das zu sendende File am Zielsystem im momentanen Arbeitsverzeichnis unter demselben Namen abgelegt wird, wie er auch im absendenden System lautet. Es ist zu unterscheiden, ob eine Datei im ASCII-Format übertragen werden soll (dann wird die Datei eventuell verändert, um den unterschiedlichen ASCII-Darstellungen auf verschiedenen Maschinen gerecht zu werden) oder binär (d.h. bit-identisch). Letzteres wird z.B. benötigt, wenn kompilierte, lauffähige Programme oder komprimierte Dateien übertragen werden sollen (z.B. .exe- oder .zip-Dateien für PCs).
Auch mit dem WWW-Browser Netscape kann der FTP-Dateitransfer in beiden Richtungen durchgeführt werden. Zum Anmelden gibt man in der Locationzeile die URL in einer der beide folgenden Formen an:
- ftp://kennung:passwort@rechnername
ftp://kennung@rechnername - 2.2.2 FTP mit anonymem Login (aFTP)
Innerhalb des Internets gibt es Server (aFTP-Server), die Teile ihres Dateisystems der Öffentlichkeit im Internet zum Lesen und Kopieren zur Verfügung stellen. Diese Verzeichnisse enthalten Public-Domain- bzw. Shareware-Software und andere mehr oder weniger interessante Dokumente (z.B. Pläne, Bilder, Texte). In der Regel hat jeder Zugriff unter dem Benutzernamen anonymous oder ftp und Paßwort <eigene Mailadresse>.
Manche FTP-Server wie ftp.leo.org erlauben den Zugriff allerdings nur nach einer Identifikation des anfragenden Rechners, indem sie versuchen, der IP-Adresse einen Domain-Namen zuzuordnen. Dies gelingt nur, wenn der Rechner mit sogenanntem Reverse Mapping im zuständigen Nameserver (siehe 1.2.3) eingetragen ist.
Viele Software-Pakete sind auf mehreren Servern abgelegt, es sollte möglichst immer der nächstgelegene Server genutzt werden. Zuerst sollten also die lokalen ftp-Server nach den benötigten Dateien durchsucht werden:
Folgende größere aFTP-Server existieren im MHN:
- ftp.lrz-muenchen.de
- ftp.informatik.tu-muenchen.de
- ftp.informatik.uni-muenchen.de
- ftp.e-technik.tu-muenchen.de
- ftp.leo.org
- ftp.informatik.tu-muenchen.de
- ftp.lrz-muenchen.de
- 2.2.3 Archie
- Im Internet existieren Datenbanken, in der die Inhaltsverzeichnisse aller
ftp-Server abfragbar sind. Dieses Inhaltsverzeichnis wird dauernd aktuell
gehalten. Das System dieser Datenbanken heißt Archie. Die Abfrage kann
entweder per email oder mit Hilfe von speziellen Archie-Clientprogrammen
erfolgen.
- ftp-Server im Münchner Hochschulnetz sind immer vorzuziehen, da hier nur Verkehr im lokalen Netz verursacht wird;
- ftp-Server in Deutschland sind ausländischen Servern vorzuziehen, da dadurch die Links in die USA bzw. zu anderen europäischen Ländern nicht belastet werden.
Per Mail schickt man einfach eine eine Nachricht an den Mailserver
mit dem Suchbegriff hinter dem Schlüsselwort prog entweder im Betrifftfeld (Subject) oder im Inhalt der Mail. Beispiel:. mit Subject oder erster Zeile prog isode werden die Namen aller Archive mit Dateien, die den Namen isode enthalten, in einer Mail zurückgeschickt. Informationen zur Benutzung des Archie-Servers bekommt man, indem man einfach eine Mail mit dem Inhalt help schickt.
An den Workstations des LRZ ist auch die interaktive, Xwindow-basierte Abfrage-Facility xarchie benutzbar. Es ist dabei darauf zu achten, eine möglichst genau spezifizierte Anfrage anzugeben, um nicht zuviele Dateien auszuwählen. Eine weitere Einführung ist auf dem ftp-Server des LRZ verfügbar.
Der anzusprechende ftp-Server ist schließlich in folgender Reihenfolge aus
der erhaltenen Antwort von der Archie-Datenbank (oder ftp-Liste) auszuwählen:
- 2.3 NFS (Network File System)
Das NFS der Firma SUN verfolgt das Ziel, in einem Netz, bestehend aus verschiedenen Systemen mit durchaus unterschiedlichen Betriebssystemen, eine gemeinsame Datenhaltung (File Sharing) zu ermöglichen. Im Unterschied zum FTP, bei dem die interessierenden Dateien erst zwischen den Systemen hin und her transferiert werden müssen, um sie jeweils lokal verwenden zu können, ermöglicht das NFS den (transparenten) Zugriff auf Dateien an einem fremden System so, als existierten sie auf dem eigenen Rechner. Nachdem auf dem entsprechenden NFS-Server-System die Zugriffsrechte eingerichtet sind, kann durch einen mount-Befehl auf dem Client die Zuordnung zwischen den Directories auf dem fremden (Server) und dem eigenen (Client-) System hergestellt und durch umount wieder gelöst werden. Ein Vorteil ist, daß eine Reihe von Dateioperationen direkt am Serversystem durchgeführt werden, ohne dazu die Daten auf den Client zu kopieren. Der wesentliche Nachteil bei NFS ist, daß jeder, z.B. lesende, Zugriff auf eines der gemounteten Files immer über das Netz geht und somit eine Steigerung der Netzlast bedeutet. Da NFS mit dem ungesicherten Transportprotokoll UDP arbeitet, können kleine Instabilitäten im Netz schnell zu einer hohen Zahl von sogenannten retransmissions (wiederholtes Senden des gleichen Pakets) führen. Dies ist unbedingt zu bedenken, wenn NFS über Weitverkehrsverbindungen betrieben werden soll, wo Antwortzeiten stark schwanken können. Ein wichtiger Vorteil ist die mögliche Reduzierung eventuell knapper Speicherkapazität, da ein benötigtes File nur noch einmal vorhanden sein und nicht jeder Benutzer sich eine eigene Kopie davon anlegen muß. NFS ist auf einer Reihe von UNIX-Systemen (SUN, HP usw.) vorhanden, wobei jeder Rechner Server wie auch Client sein kann. Für MS-DOS-PCs ist die Client-Version verfügbar, bei PC/TCP ist sie z.B. unter dem Namen idrive integriert.
Das Arbeiten am PC erfolgt derart, daß zu den lokalen Laufwerken (z.B. A: bis E:) ein weiteres (z.B. F:) hinzugefügt wird, das auf ein Directory am NFS-Server verweist. Alle Operationen auf dem sogenannten Network-Drive werden am Server durchgeführt, erscheinen am PC aber so, als wären sie lokal. Das PC-NFS-Paket von SUN unterstützt die bekanntesten Ethernet-Karten und enthält bereits die TCP/IP-Programme.
Wichtig: Der mount-Befehl erfordert root-Berechtigung!
Im LRZ wird statt NFS wird das Andrew-File-System (AFS) eingesetzt, welches gegenüber NFS wesentlich mehr Sicherheit und gleichzeitig mehr Flexibilität (z.B. bei der individuellen Vergabe von Zugriffsrechten) bietet. Ausgehend von einem PC verläuft das Mounten von Files mit NFS zwischen zwei Sun-Workstations folgendermaßen:
Die Ausgangssituation auf den zwei Sun-Workstations sei durch die beiden Directory-Strukturen angedeutet: sun1-Prompt> ls /home/a/a2824aa brief1 (d.h. im Directory /home/a/a2824aa existiert lediglich das File 'brief1') sun1-Prompt> ....... suntest-Prompt>ls /home/suntest/a2824aa (es folgen verschiedene Files aber kein 'brief1') suntest-Prompt> ...................... PC-Prompt>telnet suntest . (einloggen unter <User Name> . suntest-Prompt>mkdir /home/suntest/a2824aq/nfstest suntest-Prompt>su (einloggen unter root für mount-Befehl) . (diverser Text) . suntest-Prompt>mount sun1:/home/a/a2824aa \ /home/suntest/a2824aa/nfstest . suntest-Prompt> ls /home/suntest/a2824aa/nfstest brief1 (In dem Directory 'nfstest' auf der suntest findet sich nun alles, was unter dem Directory 'a2824aa' auf der sun1 einge- richtet worden ist, ohne jedoch auf die suntest transferiert worden zu sein!) . suntest-Promt> cd nfstest suntest-Prompt>more brief1 (Erst im Falle der Verwendung eines der gemounteten Files wer- den die benötigten Teile über das Netz auf die suntest trans- feriert, wie hier im Beispiel für das Lesen der Datei 'brief1'.) . cd .. suntest-Prompt>umount /home/suntest/a2824aa/nfstest (Durch diesen Befehl wird die Zuordnung der Dateien zwischen der suntest und der sun1 wieder aufgelöst.) . suntest-Prompt>logout Connection closed PC-Prompt>
- 2.4 SMTP-Mail
Eine wichtige Anwendung, die auf den Domain-Name-Service (siehe dazu 1.2.3) zurückgreift, ist der Mailservice. Das Mailsystem mittels SMTP steht i.d.R. auf allen TCP/IP-fähigen Rechnern zur Verfügung. Auf PCs ist diese Anwendung dadurch beschränkt, daß das Gerät, um eine Mail erhalten zu können, als Server konfiguriert werden muß. Da PCs bisher zumeist jedoch nicht für Multitasking eingerichtet sind, d.h. es können nicht gleichzeitig zwei oder mehr Prozesse abgearbeitet werden, kann man also nicht weiterarbeiten und gleichzeitig auf den Empfang einer Mail warten. Einzelheiten der Mailmöglichkeiten am LRZ könne Sie im Dokument über Email nachlesen. Es existieren verschiedene Programme zum Verschicken und Bearbeiten von Mail-Messages (sogenannte User Agents, UAs). Eine einfach zu bedienende Benutzerschnittstelle unter UNIX bietet das Programm "pine". Es kann an allen UNIX-Workstations des LRZ aufgerufen werden.
User Agents für PCs existieren inzwischen in größerer Anzahl. Public-Domain-Programme, die auch von ftp.lrz-muenchen.de bezogen werden können sind: PMail (Pegasus Mail) und Eudora. Diese Programme beherrschen auch das POP-Protokoll, welches es ermöglicht, automatisch nach dem Start des Programmes Verbindung zum Mailserver (gleichzeitig POP-Server) aufzunehmen und die dort vorhandene, im PC konfigurierte, Mailbox zu lesen, als ob sie auf dem PC liegen würde. Desweiteren kann damit natürlich auch Mail verschickt werden. Das POP-Protokoll kann auch über einen Wählanschluß verwendet werden (siehe Modem/ISDN).
- 2.5 X-Windows
Unter X-Windows versteht man eine Client-Server-Applikation, die dem Benutzer an einem entfernten Endgerät eine graphische Oberfläche zur Verfügung stellt. Dabei verwaltet der Server lokal an einem Arbeitsplatz (z.B. PC oder X-Window-Terminal) Bildschirm und Eingabegeräte, während die X-Applikationen (die Clients) die Dienste des Servers für Ein- und Ausgabe in Anspruch nehmen. Diese X-Clients können an irgendeinem TCP/IP-Host im Netz ablaufen und verwenden zur Kommunikation mit dem Server das sog. X-Protokoll. In der UNIX-Welt hat sich X-Windows zu einem Quasi-Standard in pixelorientierten Anwendungen entwickelt. Weitere Details zu X-Windows finden sich in einem speziellen Schrift X-Windows.
- 2.6 News
Aufbauend auf NNTP (dem Network News Transfer Protocol, s.o.) bietet News dem Benutzer die Möglichkeit, weltweit oder regional Meinungen und Informationen zu bestimmten Themengebieten (den sogenannten News-Gruppen) öffentlich auszutauschen. Dazu benötigt ein Benutzer eine bestimmte Schnittstelle, den sogenannten News-Reader (z.B. nn unter Unix), der über NNTP Verbindung mit dem News-Server aufnimmt. Diese sind für bestimmte Regionen zentrale Rechner, welche die News-Datenbank halten, die in bestimmten Zeitabständen aktualisiert wird und welche für die Verbreitung von "geposteten" Artikeln sorgen. Unter "Posten" versteht man dabei das Absetzen eigener Artikel. In München kann der zentrale Newsserver unter news.lrz-muenchen.de erreicht werden. Über den Umgang mit News informiert eine extra Schrift News.
Durch die am Internetzugang des LRZ eingestellten Filter (siehe Betrieb der IP-Protokolle im MHN) kann nicht direkt mit fremden Newsservern kommuniziert werden. Fremde Gruppen, deren Newsserver bekannt sind, können aber auf Anfrage (Mail an boetsch@lrz.de) in unseren Newsproxy-Server eingetragen werden. Über newsproxy.lrz-muenchen.de können sie dann zugegriffen werden.
Für PCs unter Windows gibt es verschiedene Newsreader, wir empfehlen zum Lesen von News den Internetbrowser Netscape zu verwenden.
- 2.7 Network Time Protocol (NTP)
Mit NTP können TCP/IP-Rechner mit einer hochgenauen Zeit von einem NTP-Server versorgt werden. Verschiedene Client-Programme synchronisieren die eigene Maschine einmalig oder kontinuierlich an die Zeit des NTP-Servers. Falls möglich, ist die zweite Variante vorzuziehen (z.B. mit xntp-Software für UNIX auf ftp.lrz-muenchen.de). Im LRZ werden zwei Server-Rechner betrieben, deren Uhren auf die DCF77-Zeit synchronisiert werden und die abgefragt werden können:
Es wird empfohlen, daß sich pro Institut ein oder zwei Rechner auf die Zeit von ntp1.lrz-muenchen.de oder ntp2.lrz-muenchen.de synchronisieren, während der Rest der Institutsrechner sich die Zeit von diesen ausgewählten Rechnern holen sollte. Damit wird die Netzbelastung mit NTP minimiert. Als Backup können auch weitere NTP-Server konfiguriert werden, wobei davon abgeraten wird, die internationalen Leitungen damit zu belasten, da dies wegen der größeren Laufzeiten nicht sinnvoll ist.ntp1.lrz-muenchen.de 129.187.10.32 ist direkt an die Funkuhr angeschlossen. ntp2.lrz-muenchen.de 129.187.14.10 erhält die Uhrzeit von ntp1. Unter Windows 95 kann als NTP-Client etwa das Sharewareprogramm Tardis95 eingesetzt werden.
- 2.8 Gopher
Unter Gopher versteht man ein weltweit verteiltes Informationssystem, das ebenfalls nach dem Client-Server-Prinzip arbeitet. Gopher-Server verwalten einen Informationsbaum von Objekten. Diese Objekte sind entweder Verzeichnisse oder Dateien mit darstellbarem Inhalt (Text,Bild,Ton usw.), können aber auch Verweise sein auf Informationsäste anderer Gopher-Server oder auf Übergänge zu anderen Informationssystemen (WAIS (Wide Area Information Server), News, anonymous FTP). Die Gesamtheit der Informationen aller Gopher-Server bildet den sogenannten Gopher-Space. Das Informationsangebot im Gopher-Space ist allerdings rückläufig, da die meisten Inhalte auf das neuere WWW migriert werden. Auch das LRZ betreibt keinen eigenen Gopher-Server mehr.
Über ein spezielles Protokoll verständigen sich die Gopher-Clients und Gopher-Server. Die Clients bilden den Informationsbaum auf eine Benutzer-Oberfläche ab, leiten die Eingaben des Benutzers weiter und präsentieren ihm die Ergebnisse. Als Client können die meisten WWW-Browser wie etwa Netscape genutzt werden, die anzugebende URL hat dabei die Form gopher://rechner.domain
Ein Public-domain PC-Client ist z.B. pcgopher, er kann hier von unserem FTP-Server geholt werden.
Gopher hat durch den Erfolg des WWW stark an Bedeutung verloren. Gopher-Informationen können insbesonder auch mit WWW-Browsern wie Netscape dargestellt werden. Man benötigt also keinen extra Gopher-Client.
- 2.9 TELNET
Zweck des TELNET-Programms ist, von einem beliebigen TCP/IP-fähigen Rechner einen interaktiven Zugang zu anderen Rechensystemen zu schaffen. Diese Programme machen also aus Ihrem PC z.B. ein Terminal an einem anderen Rechner (Terminal-Emulations Programm). Im einfachsten und häufigsten Fall ist dies ein Terminal nach dem VT100 Standard. Dabei kann es zu Problemen kommen, wenn am Zielrechner Programme gestartet werden, die Vollbildschirme erzeugen und auf Funktionstasten-Eingaben warten. Der Telnet-Aufruf kann sowohl mit der IP-Hostadresse als auch mit dem DNS-Hostnamen erfolgen. Im letzten Fall löst der Nameserver diesen Namen zuerst in eine IP-Adresse auf, bevor die Verbindung geschaltet werden kann (siehe 1.2.3). Dies ist der unbedingt vorzuziehende Weg, da die Verwendung von IP- Adressen oder gar das Halten eigener Namenstabellen (hosts-Dateien) sehr fehleranfällig sind. IP-Adressen ändern sich öfters einmal, Namen dagegen nur sehr selten. Die Verwendung der IP-Adresse anstelle des Namens ist dagegen für Testzwecke sehr zu empfehlen, insbesondere wenn nicht sicher ist, ob der Nameserver erreichbar ist oder nicht richtig arbeitet.
PCs und X-Terminals mit Ethernetanbindung und installierter TCP/IP-Software können mittels TELNET auf alle LRZ-Systeme zugreifen. Die Applikation TELNET bietet mehrere Steuerfunktionen an. Wird TELNET ohne Parameter aufgerufen, erscheint der TELNET-Prompt: telnet> . Durch Eingabe von 'help' bekommt man angezeigt, welche Steuermöglichkeiten im Rahmen einer TELNET-Sitzung zur Verfügung stehen.
Bei Windows 95 ist ein Telnet-Programm integriert, das mit Start -> Ausführen -> telnet <Rechner> aufgerufen werden kann.
Die vollständigen Hostnamen (in Klammer zur Information die derzeit gültige IP-Adresse) einiger zentraler Rechensysteme des LRZ lauten wie folgt:
Hostname System t90.lrz-muenchen.de (129.187.13.1) Cray T90 sp2.sp2.lrz-muenchen.de (129.187.23.7 ) IBM SP2 sun1.lrz-muenchen.de (129.187.10.20) sun1 sun2.lrz-muenchen.de (129.187.10.21) sun2 sun3.lrz-muenchen.de (129.187.10.22) sun3 sun4.lrz-muenchen.de (129.187.10.23) sun4 sun5.lrz-muenchen.de (129.187.10.24) sun5 vpp.lrz-muenchen.de (129.187.13.100 ) vpp ibm0.lrz-muenchen.de (129.187.14.14) ibm0 ibm1.lrz-muenchen.de (129.187.14.15) ibm1 ibm2.lrz-muenchen.de (129.187.14.16) ibm2 Beispiele für eine Telnet-Anwendung
a) Zu einer LRZ-Sun
PC-Prompt> telnet sun1 (oder telnet sun1.lrz-muenchen.de) Trying 129.187.10.20 ... Connected to sun1. Escape character is '^]'. SunOS UNIX (sun1) login: ... (Ab hier beginnt die Login-Prozedur einer Sun-Sitzung)
b) Zu einem TCP/IP-Rechner außerhalb des LRZ-Versorgungsbereichs.
Auf dieselbe Weise können auch Rechner erreicht werden, die nicht direkt am LRZ-Netz, sondern an über Router erreichbaren entfernten Netzen angeschlossen sind. Die Router übernehmen dabei die Weiterleitung der Datenpakete. Eine Sitzung z.B. an der Sun btr0x1 in Bayreuth sieht dann folgendermaßen aus:
PC-Prompt> telnet btr0x1.hrz.uni-bayreuth.de ( oder telnet 132.180.8.29) Trying 132.180.8.29 ... Connected to btr0x1.hrz.uni-bayreuth.de. Escape character is '^]'. SunOS UNIX (btr0x1) login: ... (Ab hier beginnt die Login-Prozedur einer Sun-Sitzung.)
- 2.10 Sonstige Anwendungen
- Neben den beschriebenen Diensten sind im Interent noch einige weitere
möglich, etwa das in manchen Kreisen beliebte "Inter Relay Chat" (IRC), auch
kurz "Chatten" genannt. Dieses und andere Protokolle sind im MHN zwar möglich
und erlaubt, werden aber nicht extra unterstützt. Dies bedeutet, daß es auch
keinen vom LRZ betriebenen IRC-Server gibt. Wir halten für wissenschaftliche
Zwecke die Dienste Email und News für besser geeignet und
ausreichend. Wer unbedingt IRC probieren will, kann den öffentlichen
IRC-Server des Instituts für Informatik der TUM
irc.informatik.tu-muenchen.de nutzen.
Ein anderer Dienst von wachsender Bedeutung ist das Telefonieren über das Internet. Damit lassen sich im Prinzip eine Menge von Gebühren für Ferngespräche einsparen. Allerdings ist die Qualität der Sprache, insbesondere bei überlasteten Netzen oft noch mangelhaft. Informationen zur Internet-Telefonie gibt es z.B. bei der Uni Mainz.
3.
Betrieb der IP-Protokolle im MHN
- Prinzipiell werden alle IP-Daten im ganzen MWN ohne Ausnahmen geroutet, es
sind also alle Dienste zu betreiben. Voraussetzung ist natürlich, daß ein
Rechner eine korrekte IP-Adresse innerhalb seines Subnetzes hat und richtig
konfiguriert ist.
- Als IP-Absendeadressen sind nur die im MWN zulässigen Netzadressen möglich. Damit wird das sogenannte IP-Spoofing, also das Vorspiegeln falscher Identität im Netz verhindert.
- Nameserveranfragen dürfen nur von einigen bekannten, gut gepflegten Systemen (Fakultätsnameserver) gestellt werden. Näheres dazu steht in Betrieb des Nameserver-Dienstes im MHN.
- Das News-Protokoll NNTP ist auf die 3 Server news.lrz-muenchen.de, news.informatik.tu-muenchen.de und news.informatik.uni-muenchen.de beschränkt.
- Die Verwendung des SNMP-Protokolls zum Management von Netzkomponenten über das eigene Subnetz hinaus ist nur nach Absprache mit dem LRZ möglich.
- Außerdem gibt es Beschränkungen für Email, um den Mißbrauch der Maildienste für Spamming und kommerzielle Zwecke zu unterbinden. Näheres dazu finden Sie unter http://www.lrz.de/services/netzdienste/email/policy/
Einige Einschränkungen gibt es allerdings bei den Verbindungen aus dem MHN
heraus ins Internet. Hier wurden zum Schutz von essentiellen Netzfunktionen
und Vermeidung unnötigen Verkehrs folgende Regelungen eingeführt:
