Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

UUCP-Transfer und Remote-Befehle

Das Konzept der Jobs ist für das Verständnis von UUCP von elementarer Bedeutung. Jeder Datentransfer, den ein Benutzer mit uucp oder uux initiiert, wird Job genannt. Er besteht aus einem Befehl, der auf dem Remote-System ausgeführt wird, einer Reihe von Dateien, die zwischen Sites übertragen werden sollen, oder aus beidem zusammen.

Im folgenden Beispiel wird UUCP dazu benutzt, die Datei netguide.ps zu einem entfernten Host namens pablo zu übertragen und den Befehl lpr auf pablo auszuführen, um die Datei zu drucken:

$ uux -r pablo!lpr !netguide.ps

UUCP ruft üblicherweise das entfernte System nicht direkt an, um einen Job auszuführen (sonst könnten Sie das auch mit kermit erledigen). Statt dessen wird vorübergehend eine Beschreibung des Jobs zwischengespeichert. Diese Technik wird Spooling genannt. Der Verzeichnisbaum, unter dem die Jobs gespeichert werden, wird daher auch Spool-Verzeichnis genannt und befindet sich üblicherweise in /var/spool/uucp. In unserem Beispiel würde die Job-Beschreibung Informationen zum Befehl (lpr) enthalten, der ausgeführt werden soll, zum Benutzer, der die Ausführung angefordert hat, und zu einigen weiteren Details. Neben der Job-Beschreibung muß UUCP auch die Eingabedatei netguide.ps speichern.

Der exakte Ort und die Bezeichnungen von Spool-Dateien können, abhängig von einigen Optionen während des Kompilierens, variieren. HDB-kompatible UUCPs speichern Spool-Dateien üblicherweise in einem /var/spool/uucp-Unterverzeichnis mit dem Namen der entfernten Site. Wurde UUCP für die Taylor-Konfiguration kompiliert, erzeugt es Unterverzeichnisse für verschiedene Arten von Spool-Dateien im Site-spezifischen Spool-Verzeichnis.

In regelmäßigen Intervallen wählt UUCP das entfernte System an. Steht die Verbindung zum entfernten System, überträgt UUCP die den Job beschreibenden Dateien sowie alle Eingabedateien. Die eingehenden Jobs werden nicht sofort ausgeführt, sondern erst nachdem die Verbindung unterbrochen wurde. Dies wird im allgemeinen durch uuxqt erledigt, das auch dafür sorgt, daß alle Jobs weitergeleitet werden, die für eine andere Site bestimmt sind.

Um zwischen wichtigen und weniger wichtigen Jobs zu unterscheiden, verknüpft UUCP mit jedem Job eine Klasse (Grade). Dabei handelt es sich um ein einzelnes Zeichen von 0 bis 9, A bis Z und a bis z, bei abnehmender Wichtigkeit. Mail wird normalerweise mit der Klasse B oder C gespoolt, während News mit Klasse N gespoolt werden. Jobs mit höheren Klassen werden früher übertragen. Sie können Spool-Klassen mit der Option –g vergeben, wenn Sie uucp bzw. uux starten.

Sie können auch den Transfer von Jobs zu bestimmten Zeiten unterbinden, wenn eine bestimmte Klasse unterschritten wird. Dieser Wert wird als die maximale Spool-Klasse bezeichnet, ab dem eine Übertragung verboten ist. Sie ist normalerweise auf z voreingestellt, so daß alle Klassen übertragen werden dürfen. Beachten Sie die terminologische Doppeldeutigkeit an dieser Stelle: Eine Datei wird nur dann übertragen, wenn ihre Klasse gleich oder größer der maximalen Spool-Klasse ist.

Die interne Arbeitsweise von uucico

Um zu verstehen, warum uucico bestimmte Dinge wissen muß, ist eine kurze Beschreibung darüber hilfreich, wie es die eigentliche Verbindung zu einem entfernten System herstellt.

Wenn Sie uucico –s system von der Kommandozeile aus ausführen, muß uucico zuerst eine physikalische Verbindung herstellen. Die durchzuführenden Aktionen sind von der Verbindungsart abhängig. Wird eine Telefonleitung verwendet, muß ein Modem gefunden und herausgewählt werden. Unter TCP muß gethostbyname aufgerufen werden, um den Namen in eine Netzwerkadresse umzuwandeln. Der zu öffnende Port muß ermittelt und die Adresse an den entsprechenden Socket gebunden werden.

Nachdem die Verbindung aufgebaut worden ist, muß eine Autorisierungsprozedur durchgeführt werden. Diese Prozedur besteht normalerweise darin, daß das entfernte System nach einem Login-Namen und eventuell nach einem Paßwort fragt. Dies wird im allgemeinen als Login-Chat bezeichnet. Die Autorisierungsprozedur wird entweder vom normalen getty/Login-Paket oder, bei TCP-Sockets, von uucico selbst durchgeführt. Ist die Autorisierung erfolgreich verlaufen, wird am anderen Ende uucico gestartet. Die lokale Kopie von uucico, die die Verbindung initiiert hat, wird als Master, die entfernte Kopie als Slave bezeichnet.

Als nächstes folgt die Handshake-Phase: Der Master sendet nun seinen Hostnamen zusammen mit einigen Flags. Der Slave überprüft diesen Hostnamen auf Login-Erlaubnis, Senden und Empfangen von Dateien usw. Die Flags beschreiben unter anderem die maximale Klasse der zu übertragenden Dateien. Falls aktiviert, wird ein Kommunikationszähler, die Call Sequence Number, an dieser Stelle überprüft. Mit dieser Option verwalten beide Seiten jeweils die Anzahl erfolgreicher Verbindungen, die nun miteinander verglichen werden. Stimmen sie nicht überein, schlägt der Handshake fehl. Diese Option ist nützlich, um sich vor Eindringlingen zu schützen.

Zum Schluß versuchen sich beide uucicos auf ein gemeinsames Übertragungsprotokoll zu einigen. Dieses Protokoll legt fest, wie Daten übertragen, auf ihre Konsistenz hin überprüft und im Fehlerfall erneut übertragen werden. Wegen der verschiedenen möglichen Verbindungsarten müssen auch verschiedene Protokolle unterstützt werden. So benötigen Telefonverbindungen ein “sicheres” Protokoll, das pingelig auf Fehler achtet, während die TCP-Übertragung ausreichend zuverlässig ist und daher ein effizienteres Protokoll verwenden kann, bei dem viele der zusätzlichen Fehlerprüfungen weggelassen werden können.

Nachdem der Handshake durchgeführt wurde, beginnt die eigentliche Übertragungsphase. Beide Seiten aktivieren den vereinbarten Protokolltreiber. An diesem Punkt führen die Treiber gegebenenfalls eine protokollspezifische Initialisierungssequenz durch.

Der Master sendet dann alle aufgelaufenen Dateien, deren Spool-Klasse ausreichend hoch ist, an das entfernte System. Ist die Übertragung beendet, wird der Slave darüber informiert, daß die Übertragung abgeschlossen ist. Der Slave kann nun die Verbindung unterbrechen oder die Kommunikation selbst übernehmen. In diesem Fall werden also die Rollen getauscht: Das entfernte System wird zum Master, und das lokale wird zum Slave. Der neue Master überträgt nun seine Dateien. Ist auch diese Übertragung abgeschlossen, tauschen beide uucicos Terminierungsnachrichten miteinander aus und schließen die Verbindung.

Wenn Sie mehr über UUCP wissen wollen, sehen Sie sich bitte den Quellcode an. Im Netz kursiert außerdem einwirklich antiquierter Artikel von David A. Novitz, der eine detaillierte Beschreibung des UUCP-Protokolls enthält.¹ Auch die Taylor UUCP-FAQ enthält einige Details darüber, wie UUCP implementiert wurde. Sie wird regelmäßig an comp.mail.uucp gepostet.

Kommandozeilenoptionen von uucico

In diesem Abschnitt beschreiben wir die wichtigsten Kommandozeilenoptionen für uucico.

– – system, –s system

Ruft das angegebene system an, wenn dies durch Rufzeitbeschränkungen nicht unterbunden wird.

–S system

Ruft das angegebene system ohne jede Vorbedingung an.

– –master, –r1

Startet uucico im Master-Modus. Dies ist Standard, wenn die Optionen –s oder –S angegeben sind. Steht die Option –r1 für sich allein, versucht uucico, alle in der sys-Datei eingetragenen Systeme anzurufen (wie im nächsten Abschnitt dieses Kapitels beschrieben), solange dies durch Ruf- oder Wiederholungs-Zeitbeschränkungen nicht unterbunden wird.

– –slave, –r0

Startet uucico im Slave-Modus. Dies ist Standard, wenn die Optionen –s oder –S nicht angegeben sind. Im Slave-Modus wird davon ausgegangen, daß entweder die Standardeingabe/-ausgabe mit einem seriellen Port verbunden ist oder daß der mit der Option –p angegebene TCP-Port verwendet wird.

– –ifwork,–C

Diese Option ist eine Ergänzung zu –s oder –S und weist uucico an, das genannte System nur dann anzurufen, wenn dafür Jobs gespoolt worden sind.

– –debug typ, –x typ, –X typ

Aktiviert das Debugging für den angegebenen Typ. Verschiedene Typen können in einer durch Kommata getrennten Liste angegeben werden. Die folgenden Typen sind zulässig: abnormal, chat, handshake, uucp-proto, proto, port, config, spooldir, execute, incoming und outgoing. Mit all werden alle Optionen aktiviert. Zwecks Kompatibilität mit anderen UUCP-Implementierungen kann statt dessen auch eine Nummer angegeben werden, die das Debugging für die ersten n Einträge aus der obigen Liste aktiviert.

Debugging-Nachrichten werden in die Datei Debug unter /var/spool/uucp eingetragen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center