Dieses Handbuch wird mit freundlicher Genehmigung von Sebastian Hetze auf den Servern der Linux Information Systems AG gehosted.

next up previous contents index
Next: Elektronische Post mit smail Up: Datenreisen und reisende Daten Previous: Seriell einloggen

Subsections


UUCP - Das Internet der Armen Leute

 Wer seinen Rechner an ein Netzwerk anschließen will und nicht gerade das Glück hat, über einen lose herumliegenden Internet-Anschluß zu stolpern, muß sich gewöhnlich nach kostengünstigeren Alternativen umschauen. Die erste und beste Wahl ist in diesem Fall das Telefon. In Deutschland existieren mehrere, zum Teil bundesweite Computernetze, die ihre Mitglieder auf diese Weise miteinander verbinden.

Ein Teil der Netze, vor allem diejenigen, deren Mehrzahl aus UN*X-Systemen besteht, verwenden UUCP, um über das Telefonnetz miteinander zu kommunizieren.  Der Name UUCP ist eine Abkürzung und steht für Unix-to-Unix-Copy. UUCP wurde 1978 von den Bell Laboratories  entwickelt, um einen flexiblen Datenaustausch zwischen einzelnen Zweigniederlassungen zu ermöglichen. Dank seines einfachen Designs und seiner relativen Anspruchslosigkeit, was Installation und Wartung betrifft, hat sich UUCP rasch einen Spitzenplatz erobert, den es wohl noch einige Jahre behalten wird.

Im Laufe der Jahre hat es verschiedene Implementationen von UUCP gegeben. Dabei können grob zwei ``Grundtypen'' unterschieden werden, die sich im Format der Konfigurationsdateien stark unterscheiden. Der eine Typ, sogenannte ``Version 2''-Implementationen, folgen einem einfacheren Konzept und stellen den älteren Zweig der Familie dar (Version 1 wurde nur innerhalb der Bell Laboratories verwendet). Der neuere Zweig stammt von einer Implementation aus 1983 von P. Honeyman, D.A. Novitz und B.E. Redman ab und heißt nach seinen Autoren auch HoneyDanBer oder HDB.   Das HoneyDanBer-UUCP wurde unter der Bezeichnung Basic Network Utilities (BNU) ins AT&T Unix SVR3 integriert, so daß dieser Name ebenfalls in Verwendung ist.

UUCP-Anschluß - aber wie?

 Ein zentrales Dogma im Usenet, dem weltweiten News-Netz, ist ``Get a feed and you're on it,'' zu deutsch: Besorg' Dir einen Anschluß, und Du bist dabei. Das ist oft leichter gesagt als getan, denn Informationen über Anschlußmöglichkeiten erhält man oft nur, wenn man bereits Kontakt zu dieser Netzwelt aufgenommen hat.

Derzeit gibt es zwei größere gemeinnützige Vereine in Deutschland, die ihren Mitgliedern Netz-Dienste wie Mail und News über UUCP - und in zunehmendem Maße auch über TCP/IP - bieten. Dies sind einerseits Individual Network e.V. (kurz IN), andererseits der Verein zur Förderung der privat betriebenen Datenkommunikation e.V. (kurz Vz* oder auch Sub-Netz, weil sich den vollen Namen im allgemeinen niemand merken kann). Beide Vereine kaufen Kontingente bei kommerziellen Service-Providern ein (s.u.), um auch die Versorgung mit internationaler Mail und News bieten zu können. Gleichzeitig gibt es immer mehr Domains im IN und VzFdpbDk, die über ISDN ans Internet angeschlossen sind, so daß dort auch Dienste wie FTP, WWW und anderes angeboten werden. Während der VzFdpbDk in gewissem Rahmen auch kommerziellen Kunden offensteht, können dem IN nur Privatpersonen beitreten. Kontaktadressen für beide Vereine entnehmen Sie bitte dem Anhang.

Neben diesen gemeinnützigen Vereinen existiert die Möglichkeit, die Dienste von kommerziellen Providern in Anspruch zu nehmen. Mittlerweile bieten viele Provider Mail und News auch für private Benutzer an, liegen aber mit ihren Preisen im Allgemeinen immer noch wesentlich über denen des IN und des VzFdpbDk.

Was kann UUCP?

UUCP ermöglicht es, das öffentliche Telefonnetz  zur Datenübertragung zu verwenden. Im Unterschied zu Terminal-Programmen, wie sie im vorigen Abschnitt vorgestellt wurden, arbeitet es aber nicht interaktiv, sondern erlaubt Ihnen, über verschiedene Dienstprogramme Aufträge zu erteilen, die zu festgelegten Zeiten selbsttätig ausgeführt werden. Um beispielsweise eine Datei von einem fremden Rechner anzufordern, können Sie folgendes Kommando ausführen:[*]

$ uucp -r flarp\!\~/archiv/Inhalt.Z Inhalt.Z

Dies erteilt UUCP den Auftrag, bei der nächsten Verbindung, die es mit dem System flarp aufbaut, aus einem allgemein zugänglichen Verzeichnis (unter Linux ist das nach dem neuen File-System-Standard /var/spool/uucppublic)   die Datei archiv/Inhalt.Z zu übertragen und im momentanen Verzeichnis in Inhalt.Z abzulegen. Das Flag -r fordert uucp auf, nicht sofort zu versuchen, die Verbindung aufzubauen.

Ebenso können Sie mit Hilfe von UUCP Kommandos auf einem fremden Rechner ausführen - sofern dieser es Ihnen erlaubt. Um beispielsweise die Datei handbuch.dvi auf dem Rechner flarp auszudrucken, müßten Sie das folgende eingeben:

$ uux -r flarp\!lpr -d \!handbuch.dvi
 

Das Ausrufezeichen vor handbuch.dvi weist uux darauf hin, daß es sich dabei nicht um ein einfaches Befehlsargument handelt, sondern um eine Eingabedatei, die zusätzlich zu dem Druckauftrag übertragen werden muß.

Wie Sie an den Beispielen sehen, verwendet UUCP das Ausrufezeichen, um den Namen eines Rechners von weiteren Parametern wie Datei- oder Befehlsnamen zu trennen. Es kann aber auch dazu verwendet werden, mehrere Rechnernamen voneinander zu trennen. Dieser Fall tritt beispielsweise auf, wenn Sie auf ein System zugreifen wollen, das Sie nicht direkt erreichen können. In diesem Fall müssen Sie auf die Vermittlung eines Systems zurückgreifen, das bereit ist, Ihren Auftrag an den Zielrechner weiterzuvermitteln. Läge in obigem Beispiel das Archiv nicht auf flarp, sondern auf tauris, einem Nachbarn von flarp, so müßte der Befehl stattdessen lauten:

uucp -r flarp\!tauris\!\~/archiv/Inhalt.Z Inhalt.Z
 

UUCP wird in diesem Beispiel den Auftrag, die Datei von tauris zu kopieren, an flarp weiterreichen. Zu geeigneter Zeit wird flarp diesen dann ausführen und die Datei bei sich zwischenspeichern. Bei der nächsten Verbindung mit Ihrem System wird diese dann endgültig an Sie übertragen.

Wie Sie sehen, gibt flarp!tauris hier den Pfad von Ihrem System zum Zielsystem an. Da das Ausrufezeichen im Computer-Englisch oft als bang bezeichnet wird, bezeichnet man dies auch als bang path. 

Neben diesen allgemeinen, allen Benutzern zugänglichen Befehlen kennt UUCP noch weitere, die hinter den Kulissen für das eigentliche Funktionieren eines UUCP-Knotens sorgen. Dies ist einerseits uucico , das Haupt- und Staats-Programm, das für die eigentliche Übermittlung der Daten zwischen zwei Systemen zuständig ist. Befehle wie uucp legen nämlich die zu übertragenden Daten und die Beschreibung ihres Auftrags im allgemeinen nur in einer Temporärdatei im sogenannten Spool-Verzeichnis ab. 

Um beispielsweise den uux-Auftrag aus dem vorangehenden Beispiel an flarp zu übertragen, muß eine Verbindung zu diesem System hergestellt werden. Dies geschieht durch den Befehl

$ uucico -s flarp

uucico versucht nun, die (Telefon-) Verbindung mit flarp aufzubauen, und loggt sich dort ein. Dabei wird auf flarp ebenfalls ein uucico gestartet, mit dem uucico dann Daten austauscht. Im vorliegenden Falle sendet der lokale uucico die Datei handbuch.dvi an flarp, sowie den Auftrag, mit dieser Datei das Druckprogramm lpr aufzurufen.

Dieser Auftrag wird auf flarp anschließend von uuxqt ausgeführt, das nach Beendigung der Verbindung automatisch von uucico aufgerufen wird.

Wie sicher ist UUCP?

 Diese Frage hat sich Ihnen vielleicht sofort aufgedrängt, als in den vorigen Abschnitten so freizügig die Rede davon war, daß mit UUCP Kommandos auf anderen Rechnern ausgeführt und Dateien nach Belieben hin- und herkopiert werden konnten.

Dieser Eindruck ist etwas irreführend. All diese Sachen sind im Prinzip möglich; es hängt aber immer vom Verwalter des einzelnen Systems ab, was er einzelnen Gästen erlaubt, die über UUCP auf die Maschine zugreifen. Gewöhnlich erlaubt UUCP fremden Systemen nur, zwei Kommandos auszuführen: rmail und rnews, die traditionellen Befehle zum Einliefern von Mail und News. Ebenso ist es fremden Systemen in der Regel nicht erlaubt, einfach beliebige Kommandos auf Ihrem System ausführen zu lassen, wie es beispielsweise mit dem Druckbefehl im Beispiel oben geschah. Es liegt in Ihrem Belieben, ob Sie einigen Systemen weitergehende Rechte einräumen, oder diese sogar weiter einschränken.

Normalerweise bietet UUCP eine Art ``rechtsfreien Raum'': in der Voreinstellung dürfen fremde Systeme im Verzeichnis /var/spool/uucppublic beliebige Daten ablegen oder sie daraus herunterladen.

Im allgemeinen wird man diese Voreinstellungen unverändert bestehen lassen. Bitte lesen Sie in den Handbüchern oder weiterführender Dokumentation nach, wenn Sie diese ändern wollen.

Taylor-UUCP

   Die auf UN*X-Systemen am weitesten verbreitete ``freie'' UUCP-Implementation ist Taylor UUCP, so genannt nach ihrem Autor, Ian Taylor. Die derzeit aktuelle Version ist Version 1.5, die auch in den meisten Linux-Distributionen und CDs enthalten ist.

Eine Besonderheit von Taylor-UUCP ist, daß es sowohl die Konfigurationsformate des Version 2-UUCP als auch die der HoneyDanBer-Implementationen versteht. Diese Formate lassen sich bei der Kompilierung voreinstellen. Daneben gibt es noch ein drittes Format, das sich vor den anderen durch eine wesentlich übersichtlichere Syntax auszeichnet. Im folgenden wird diese Taylor-spezifische Konfiguration behandelt. Die allermeisten der in den diversen Linux-Paketen enthaltenen UUCP-Binaries unterstützen dieses Konfigurationsformat.

Taylor-UUCP ist nicht nur in der Lage, Verbindungen über Telefonleitungen und Modems aufzubauen, sondern kann auch Transfers über ein TCP/IP-Netzwerk durchführen. Es würde hier allerdings zu weit führen, dies auch zu diskutieren, weshalb sich das hier beschriebene Beispiel auf den ``traditionellen'' Fall einer Wählverbindung beschränkt. Interessierte Leserinnen und Leser seien auf weiterführende Dokumentation verwiesen.

Besonders empfehlenswert ist in diesem Zusammenhang die umfangreiche Original-Dokumentation zu Taylor-UUCP, die im TEXinfo-Format vorliegt. Sie ist auf den meisten FTP-Sites[*]   erhältlich, die GNU-Software anbieten. Einige Linux-Distributionen dürften sie auch enthalten. Ebenfalls zu empfehlen ist das bei O'Reilly & Associates erschienene Buch Managing UUCP and Usenet, das zwar auch (noch) nicht die Taylor-Konfiguration beschreibt, aber ansonsten alles behandelt, was im Zusammenhang mit UUCP von Interesse ist.

Überblick über die Konfigurationsdateien

    Bevor wir uns den einzelnen für die Konfiguration nötigen Schritten zuwenden, lohnt es sich, darüber nachzudenken, welche Informationen UUCP überhaupt benötigt, um mit einem anderen System zu kommunizieren und Daten auzutauschen.

Nehmen wir beispielsweise an, Sie wohnen in Berlin und haben sich bereits mit der Firma LunetIX in Verbindung gesetzt, die auf ihrer Maschine cicero ein Gateway für Mail und News betreibt. LunetIX hat Ihnen einen UUCP-Zugang eingerichtet. Als UUCP-Namen des Rechners haben Sie vorläufig isis vereinbart. Ihr Login-Name ist in diesem Fall Uisis, als Paßwort ist gniggl eingetragen, und die Telefonnummer ist 123 45 67. Damit hätten Sie zunächst die Information über den Zielrechner zusammen.

Aber das reicht natürlich nicht. Um überhaupt anrufen zu können, muß UUCP natürlich auch wissen, an welcher seriellen Schnittstelle sich das Modem überhaupt befindet und wie es angesprochen wird. Wir nehmen an, daß das Modem an COM2 hängt und ein Hayes-kompatibles Modem mit einer maximalen Übertragungsrate von 9600bps ist.

Mit diesen Informationen sollte UUCP nun in der Lage sein, eine Verbindung mit cicero herzustellen. Bei systematischer Betrachtung lassen sich die Informationen in mehrere Sinneinheiten zusammenfassen:

Genau entlang dieser Einteilung ordnet Taylor-UUCP die benötigten Informationen nun auch drei verschiedenen Konfigurationsdateien zu: sys für die systemspezifischen Daten, ports für die Konfiguration der Schnittstellen und die Zuordnung der angeschlossenen Geräte, und schließlich dial für die Beschreibung der Modemtypen. Allgemeine Daten, wie beispielsweise der UUCP-Name Ihres Rechners, sind in der Datei config abgelegt.

  Alle diese Dateien, die im folgenden einzeln beschrieben werden, haben ein gemeinsames Format. Ein Eintrag besteht immer aus einem Schlüsselwort, gefolgt von Leerzeichen und/oder Tabulatorzeichen sowie einem oder mehreren Argumenten. Er kann über das Zeilenende fortgesetzt werden, wenn das letzte Zeichen der Zeile ein Backslash (\) ist. Kommentare werden durch ein Doppelkreuz (#) eingeleitet und erstrecken sich ebenfalls bis zum Zeilenende.

Die Konfigurationsdateien sind in einem gemeinsamen Verzeichnis versammelt. Nach dem Filesystem Standard sollten sie in /usr/lib/uucp zu finden sein; es waren aber auch Verzeichnisse wie /usr/local/lib/uucp oder /usr/conf/uucp in Gebrauch. Die Slackware-Distribution schließlich legt die Dateien in Unterverzeichnissen von /usr/lib/uucp ab - wenn Sie das HDB-Format wählen, müssen Sie die Dateien in hdb_config einrichten; im Falle der Taylor-Konfiguration heißt das Verzeichnis taylor_config.

Wenn Sie UUCP aus einer der diversen Linux-Distributionen installieren, wird dieses Verzeichnis normalerweise angelegt und enthält oft auch Beispieldateien.

Wenn Sie Taylor-UUCP in guter alter Tradition sogar selbst kompilieren, können Sie dieses Verzeichnis auch selber festlegen. Sollten Sie Linux in einem lokalen Netz betreiben und das /usr-Verzeichnis verteilt nutzen (d.h. per NFS von einem zentralen Server mounten), können Sie dem File-System-Standard entsprechend die UUCP-Konfigurationsdateien in das Verzeichnis /etc oder /etc/uucp installieren.

Im folgenden wird angenommen, daß die UUCP-Programme so konfiguriert wurden, daß sie die Konfigurationsdateien an ihrem traditionellen Platz im Verzeichnis /usr/lib/uucp suchen.

Log-Dateien

   Da UUCP-Befehle oft im Hintergrund aufgerufen werden, senden sie Ausgaben wie Fehler- oder Diagnose-Meldungen nicht auf die Konsole, sondern in mehrere Log-Dateien, die unterhalb des Verzeichnisses /var/spool/uucp abgelegt werden.

Abhängig davon, wie UUCP konfiguriert wurde, werden die Log-Files unterschiedlich gehandhabt. Die meisten UUCP-Pakete unter Linux sind dafür konfiguriert, HDB-kompatible Log-Dateien zu erzeugen. Diese Konvention kennt einerseits gewöhnliche Log-Dateien, in denen jede Transaktion vermerkt wird, und Debugging-Logs, in die zusätzliche Information abgelegt werden kann, wenn es vom Benutzer verlangt wird.

Die erste Kategorie von Log-Dateien ist unterhalb von /var/spool/uucp/.Log zu finden. Dieses Verzeichnis ist in drei weitere Unterverzeichnisse aufgeteilt; je eins für uucp, uux und uucico. Jedes dieser Unterverzeichnisse enthält ein separates Log für jedes fremde System. Ein Auftrag an uux, auf flarp das Handbuch auszudrucken, würde beispielsweise von uux in der Datei uux/flarp vermerkt. Beim nächsten Verbindungsaufbau mit flarp würde dann uucico einen weiteren Eintrag in der Datei uucico/flarp machen, mit dem die Übertragung des Auftrags protokolliert würde.

Die zweite Kategorie von Log-Dateien wird nur erzeugt, wenn Sie dies ausdrücklich von einem Programm verlangen. Debbugging-Logs werden gewöhnlich nur benötigt, um Fehlern nachzugehen. Diese Daten werden ausgegeben, indem Sie als Kommando-Parameter die Option -x mit einem Argument zwischen 1 und 11 angeben. Das Argument gibt an, wie detailliert die Information sein soll; höhere Werte bedeuten mehr Information. Diese Informationen werden in der Datei audit.local im Verzeichnis /var/spool/uucp/.Admin abgelegt. Es ist auch möglich, daß ein fremdes UUCP-System zu Beginn einer Verbindung Ihr System veranlaßt, Debug-Informationen aufzuzeichnen; diese wird dann in der Datei audit anstelle von audit.local abgelegt. Dies können Sie mit Taylor-UUCP dadurch erreichen, daß Sie zusätzlich die Option -X mit einem entsprechenden Wert zwischen 1 und 11 angeben.[*]

Ebenfalls im Verzeichnis .Admin findet sich schließlich auch die Datei xferstats, in der die übertragenen Dateien mit Größe, Übertragungsdauer, usw aufgezeichnet werden. Sie wird von einigen im Quellcode zu Taylor-UUCP enthaltenen Utilities genutzt, um Benutzungsübersichten und ähnliches zu erstellen.

Ist Ihr UUCP so konfiguriert, daß er Taylor-spezifische Log-Dateien erzeugt, finden Sie diese in /var/spool/uucp als Log beziehungsweise Debug und Stats.

Die config-Datei

   Die config-Datei kann zentral die in den Binärdateien gespeicherten Einstellungen verändern. Beispielsweise können hier Namen und Anordnung der Konfigurationsdateien und deren Formate neu definiert werden. Allerdings sind alle möglichen Parameter mit sinnvollen Voreinstellungen belegt.

Der wichtigste und meist einzige Eintrag, den Sie in dieser Datei vornehmen müssen, ist der UUCP-Name Ihres Rechers:

# /usr/lib/uucp/config
hostname        isis

Mehr brauchen Sie hier zunächst nicht einzutragen.

Falls Sie Ihr System auch für Anonymous UUCP öffnen wollen, werden in diese Datei auch die Zugangsrechte für unbekannte UUCP-Systeme eingetragen. Für Details konsultieren Sie bitte die Original-Dokumentation zu Taylor-UUCP.

Die sys-Datei

   So einfach wie mit der config-Datei geht es natürlich nicht weiter. Bei den System-Daten wird es schon etwas kniffliger. Wie bereits erwähnt, werden diese in der Datei sys eingetragen. Das folgende Beispiel zeigt die passenden Einträge für die Verbindung zum Rechner cicero, wie sie am Anfang des Kapitels vorgestellt wurde.

# /usr/lib/uucp/sys
# Defaults
chat            ogin: \L ssword: \P
port            modem1
time            Any 2
protocol-parameter  g window      7
protocol-parameter  g packet-size 512

# 1. cicero.
# Kontakt: Sebastian; Tel: 1234568
system          cicero
phone           1234567
call-login      isis
call-password   gniggl

# 2. flarp
# Archiv-Site; Anonymous UUCP.
# Bem.: Miese Telefonleitung.
system          flarp
phone           7654321
call-login      uucp
call-password   nuucp
protocol-parameter  g window      7
protocol-parameter  g packet-size 64

Diese sys-Datei beschreibt zwei Systeme, cicero und flarp. Jede Systembeschreibung beginnt in einer Zeile, die das Schlüsselwort system enthält. Alle Informationen, die zwischen zwei system-Zeilen auftauchen, beziehen sich ausschließlich auf die angegebene Site.

Anweisungen, die vor der ersten system-Zeile auftreten, werden als Default-Angaben für alle Systeme verwendet. Taucht dieselbe Angabe auch noch im System-Eintrag auf, so verdeckt diese Angabe den Default für das spezielle System. Beispielsweise haben die Protokoll-Parameter, die in der Beschreibung von flarp auftauchen, Vorrang vor den Default-Werten. (Was es mit diesen Protokoll-Parametern auf sich hat, wird später verraten).

Telefonnummer und Login-Information

 In der Beschreibung eines Systems geben die Einträge phone, call-login und call-password die beim Einwählen in dieses System zu verwendende Telefonnummer, den Loginnamen und das Paßwort an. Wichtig ist außerdem noch das Gerät, das zum Wählen verwendet werden soll. Das wird mit dem port-Befehl angegeben. Da in diesem Beispiel nur ein Modem benutzt wird, kann diese Angabe in den Defaults-Teil geschrieben werden.

Sollten Sie mehrere Modems verwenden, können Sie den Port auch für jedes System einzeln angeben. Praktischer ist es dann allerdings, anstelle des Geräts mit dem speed-Befehl die gewünschte Übertragungsgeschwindigkeit anzugeben; UUCP übernimmt es dann, anhand dieser Information ein passendes Gerät auszuwählen. Das hat den Vorteil, daß UUCP unter mehreren vorhandenen Geräten mit passender Übertragungsrate ein freies auswählen kann.

Erlaubte Zeiten

 Mit dem Befehl time können Sie kontrollieren, wann ein System angerufen werden darf. Der Wert Any erlaubt Verbindungen zu jeder Zeit. Sie können allerdings auch kompliziertere Zeitangaben machen, wie beispielsweise Mo-Fr0800-1700; dies bezeichnet den Zeitraum von 8 Uhr bis 17 Uhr an Werktagen. Man kann dies auch durch Wk0800-1700 abkürzen. Zeitangaben bestehen also aus einer Zeitspanne (in 24-Stunden-Schreibweise), und einer optionalen Angabe von Wochentagen (in den üblichen englischen Abkürzungen Mo, Tu, We, Th, Fr, Sa und Su).

Sie können auch mehrere Zeitangaben kombinieren, zum Beispiel Wk2305-0755,Sa,Su; dies schließt die Nachtzeit an Wochentagen sowie das gesamte Wochenende mit ein.

Der zweite Parameter des time-Befehls ist optional und bezeichnet die Zeit, die uucico verstreichen läßt, bevor es einen erneuten Anruf bei dem Zielsystem zuläßt. Wenn uucico vorher aufgefordert wird, das System anzurufen, wird es die Arbeit verweigern und in der Log-Datei die Meldung ``Retry time not reached'' hinterlassen. Sie können uucico zwingen, das System trotzdem anzuwählen, indem Sie statt der Option -s die Option -S verwenden:

$ uucico -S cicero
$ _

UUCP merkt sich die Zeit des letzten Anrufs und den Status in privaten Dateien; Sie können diese Information mit dem folgenden Befehl anzeigen lassen:

$ uustat -m
cicero         12-06 19:25 Dial failed (3 tries, next after 12-06 19:28)
tauris         12-06 19:10 Conversation complete
$ _
 

Das Chat-Skript

   Sehr wichtig ist außerdem die chat-Information. Ein solches ``chat script'' (zu deutsch: Tratsch-Anweisung) erklärt UUCP, wie es sich mit dem fremden System zu unterhalten hat, damit es sich einloggen darf. Es setzt sich aus mehreren Teilen zusammen, die abwechselnd beschreiben, auf welche Ausgabe des fremden Systems UUCP warten muß, und was es darauf zu antworten hat. Das oben angegebene Skript ist sehr simpel: es beschreibt im Grunde genau das, was auch Sie immer tun, wenn Sie sich bei Ihrem System anmelden: Am Login-Prompt geben Sie Ihre Benutzerkennung ein, warten auf den Paßwort-Prompt und geben Ihr Paßwort ein. In obigem Beispiel wartet UUCP auf die Aufforderung ogin: und schickt daraufhin die Benutzerkennung. Das Chat-Skript gibt diese Benutzerkennung nicht direkt an, sondern verwendet den Platzhalter \L, der bei der Ausführung von UUCP durch den Wert von der call-login-Angabe ersetzt wird. Anschließend wartet es auf die Aufforderung ssword:, und schickt daraufhin das Paßwort (symbolisiert durch \P).

Sie mögen sich jetzt vielleicht fragen, warum im Chat-Skript die Eingabeaufforderungen so verstümmelt auftauchen. Der Grund ist, daß das Skript unabhängig davon funktionieren soll, ob das fremde System Login: oder login: ausgibt. Beim Paßwort-Prompt hat man den zweiten Buchstaben aus ästhetischen Gründen dann gleich auch noch weggelassen.

Chat-Skripts können natürlich beliebig kompliziert werden, beispielsweise, wenn das andere System gelegentlich dazu gebracht werden muß, den Login-Prompt erneut auszugeben. Dies können Sie mit einer Art Verzweigung erreichen, die immer dann ausgeführt wird, wenn UUCP eine Weile vergeblich auf eine Äußerung des fremden Systems warten mußte. Eine Allround-Version des Chat-Skripts, das in den meisten Situationen funktionieren sollte, ist folgende:

chat        "" \r\n\c ogin:-BREAK-ogin: \L ssword: \P

Die erwähnte Verzweigung sehen Sie im Mittelteil: wartet UUCP vergeblich auf ogin:, so schickt es einen BREAK und wartet erneut auf ogin:. Erst wenn es diesen nach einer Weile immer noch nicht gesehen hat, gibt es dann auf.

Die ersten beiden Teile des Skripts sind für Systeme gedacht, die erst auf ein Zeichen des Anrufers warten, bevor sie ihren Prompt ausgeben; bei allen anderen Systemen sollte dies unschädlich sein. Die beiden Anführungszeichen bewirken, daß UUCP zunächst auf gar nichts wartet, sondern sofort das zweite Feld sendet: ein Carriage-Return (ASCII 13) und ein Linefeed (ASCII 10). Das Zeichen \c bewirkt, daß kein weiteres Linefeed ausgegeben wird, wie es normalerweise geschieht.

Zuletzt sei noch erwähnt, daß manche Systeme einen Moment Bedenkzeit benötigen, bevor man ihnen die Benutzerkennung oder das Paßwort senden kann (z.B. SCO Unix). In solchem Falle sollten Sie eine kleine Verzögerung einbauen, indem Sie vor die Angaben \L und \P ein \d angeben.

Protokoll-Parameter

   Um sich an verschiedene Gegebenheiten anpassen zu können, bietet UUCP eine Auswahl von Protokollen zur Übertragung von Daten an. Traditionell werden diese Protokolle durch einen einzelnen Buchstaben benannt. Das ist zwar nicht sehr einprägsam, aber so viele sind's ja auch gar nicht.

Das wohl wichtigste dieser Protokolle ist das g-Protokoll.   Es ist das älteste und am weitesten verbreitete UUCP-Protokoll, das eigentlich jede UUCP-Implementation akzentfrei sprechen sollte. Bei g handelt es sich um ein paketorientiertes Protokoll, d.h. Daten werden nicht am Stück, sondern in einzelnen Paketen übertragen, die auf Fehlerfreiheit überprüft und im Bedarfsfalle erneut gesendet werden. Diese Eigenschaft hat zur Folge, daß g in hohem Maße für die Datenübertragung über Telefonleitungen geeignet ist.

Sie könnten nun an dieser Stelle einwenden, daß Ihr Modem aber in der Lage ist, Fehler zu erkennen und zu korrigieren, ist der Aufwand denn nötig? Ja, und zwar deshalb, weil das Protokoll des Modems zwar in der Lage ist, die meisten in der Telefonleitung auftretenden Fehler zu korrigieren, aber überhaupt keine Kontrolle darüber hat, was auf der Strecke zwischen Modem und Rechner passiert.

Für jedes fehlerfrei empfangene Paket sendet g eine Empfangsbestätigung (ACK)  an den Absender; bleibt eine solche aus oder erhält der Sender stattdessen eine Fehlermeldung (NAK) , geht er davon aus, daß das Paket bei der Übertragung verlorenging oder beschädigt wurde, und sendet es erneut. Wenn nun g für jedes einzelne Paket auf ein ACK warten müßte, wäre dies äußerst langsam, da ja beide Seiten die meiste Zeit nur Däumchen drehen würden. Deshalb kennt g ein ``Fenster'' (engl. sliding window), das es ihm erlaubt, eine Anzahl von Päckchen zu schicken, bevor es auf das Eintreffen des ersten ACK warten muß. Damit kann erreicht werden, daß die Leitung zu nahezu 100% ausgelastet wird, denn oft hat das empfangende System die Quittung für das erste Päckchen bereits geschickt, bevor der Sender das letzte im Fenster liegende Päckchen auf die Leitung geben konnte.

Ganz so rosig, wie die DFÜ-Welt zunächst aussieht, ist sie aber nicht: Wenn ein Päckchen im Fenster fehlerhaft ist, müssen alle Pakete des Fensters neu übertragen werden, egal, ob sie korrekt empfangen worden sind oder nicht. Die Wahrscheinlichkeit dafür, daß ein komplettes Fenster neu übertragen werden muß, hängt auch von der Größe des Fensters ab. Wenn immer die maximale Päckchen- und Fenster-Größe verwendet wird, kann es bei schlechten Verbindungen zu einem enormen Überhang doppelt übertragener Daten kommen.

Aus diesem Grund hatten früher die meisten UUCP-Varianten feste Werte hierfür vorgegeben, nämlich eine Paketgröße von 64 Bytes und ein Fenster von 3 Paketen. Die Taylor-Konfiguration erlaubt Ihnen hingegen, diese Werte an Ihre Gegebenheiten anzupassen. Hierzu dient das Schlüsselwort protocol-parameter. Das erste Argument ist immer der Protokoll-Name (z.B. g), gefolgt von dem zu setzenden Parameter. Welche Parameter überhaupt gesetzt werden können, und welche Werte zulässig sind, hängt natürlich von dem Protokoll ab. Dies ist sehr ausführlich in der offiziellen Dokumentation zu Taylor-UUCP beschrieben. Für unser Beispiel sind nur das g-Protokoll und dessen Paket- und Fenster-Größe interessant.

Die Paketgröße kann über den Parameter packet-size eingestellt werden. Erlaubt sind alle Zweierpotenzen zwischen 32 und 4096; die Voreinstellung liegt bei 64. Das Fenster wird über den Parameter window gesetzt und darf zwischen 1 und 7 liegen; Default ist 7.

Neben dem g-Protokoll versteht Taylor-UUCP unter anderem noch die   Protokolle e und f, die zur Übertragung über TCP/IP-Verbindungen verwendet werden, G, das eine System V-spezifische Variante von g ist, und das neue i-Protokoll. Dieses Protokoll kann über eine Modemleitung gleichzeitig Pakete empfangen und senden: Protokolle wie g kennen zu jedem Zeitpunkt jeweils nur einen Sender und einen Empfänger (Master und Slave); ersterer schickt Datenpäckchen, und letzterer sendet nur die Bestätigungen (ACK und NAK) zurück, d.h. in der Richtung vom Slave zum Master ist die Leitung nur schlecht ausgelastet. Diesen Mißstand behebt i, indem es die Unterscheidung zwischen Master und Slave aufhebt, und Datenpakete und Bestätigungen kombiniert. Ein weiterer Vorteil des i-Protokolls ist eine deutlich höhere Fenstergröße: sie kann bis auf 31 hochgesetzt werden.

Die port-Datei

   Damit UUCP Ihr Modem überhaupt ansprechen kann, müssen Sie die port-Datei entsprechend konfigurieren. Das ist schnell getan:

# /usr/lib/uucp/port
# Modem with V42bis compression
port            modem1
type            modem
device          /dev/cua1
speed           9600
dialer          hayes

Diese Datei enthält nur einen einzigen Eintrag, der das Modem am Port COM2 beschreibt. Ein solcher Eintrag wird durch das Schlüsselwort port eingeleitet, das dem Port einen eindeutigen Namen zuweist. Dies ist derselbe Name, wie Sie ihn in der Datei sys mit dem port-Befehl angegeben haben.

Die nächste Zeile benennt den Typ der Schnittstelle; anstelle von modem sind hier unter anderem Typen wie direct für eine Direktleitung, oder tcp für eine TCP/IP-basierte Verbindung zulässig.

Der Befehl device bezeichnet die Gerätedatei, durch die das Modem angesprochen werden soll. Unter UN*X erfolgt der Zugriff auf Peripherie-Geräte über spezielle ``Dateien'' im Verzeichnis /dev. Linux verwendet für serielle Schnittstellen die Gerätedateien cua0, cua1, usw. bzw. ttyS0, ttyS1, etc. Dabei greifen die Gerätedateien mit der gleichen Nummer (minor number) auf dasselbe Gerät zu, nur auf unterschiedliche Art. cua1 beispielsweise wird zum aktiven Ansprechen des Geräts verwendet, wie zur Anwahl eines anderen Rechners oder zum Konfigurieren des Modems; dagegen wird ttyS1 im allgemeinen verwendet, um das Einloggen über die serielle Schnittstelle zu ermöglichen.[*]

Dabei entsprechen die Gerätedateien cua0 bis cua3 den Standard-Schnittstellen COM1 bis COM4.[*] Da Ihr Modem an COM2 angeschlossen ist, tragen Sie hier /dev/cua1 ein.

Bitte beachten Sie, daß Sie hier auf jeden Fall den tatsächlichen Namen der Gerätedatei eintragen müssen. UUCP ignoriert symbolische Links, wie beispielsweise /dev/modem.

Der nächste Eintrag, speed, legt die Übertragungsgeschwindigkeit fest, die UUCP zur Kommunikation mit dem Modem benutzen soll. Da ein Modem mit 2400 Baud bei eingeschalteter V42bis-Kompression einen maximalen Datendurchsatz von 9600 Bit/s erreichen kann, tragen Sie hier 9600 ein. Damit sendet der Rechner zwar oft schneller, als das Modem die Daten auf die Leitung schicken kann, das ist aber nicht schlimm, wenn auf der seriellen Schnittstelle Hardware-Handshake eingeschaltet worden ist. So kann das Modem den Datenfluß vom Rechner regulieren. Schimmer wäre, wenn Sie diesen Wert zu niedrig wählen, weil dann der hohe Durchsatz auf der Modem-zu-Modem-Verbindung durch eine langsame Modem-zu-Rechner-Verbindung wieder zunichte gemacht wird.

Der letzte Eintrag teilt UUCP mit, um welchen Typ von Modem es sich bei dem angeschlossenen Gerät handelt. In diesem Fall ist dies ein Hayes-kompatibles Modem. Der Name, den Sie dabei vergeben, tut wenig zur Sache, da Sie die Beschreibung des Modems selber erstellen müssen.

Die dial-Datei

   Dies ist die letzte wichtige Datei. Sie beschreibt, wie UUCP das Modem veranlassen kann, die gewünschte Telefonnummer zu wählen. Die Konfiguration für das Hayes-Modem aus unserem Beispiel könnte beispielsweise folgendermaßen aussehen:

# /usr/lib/uucp/dial
# Dialer information for Hayes-compatible modem
dialer          hayes
chat            "" ATZ OK \dATV1E0Q0 OK \dATDP\D CONNECT
chat-fail       ERROR
chat-fail       BUSY
chat-fail       NO\sCARRIER
chat-fail       NO\sDIALTONE
dtr-toggle      true

Diese Datei enthält wiederum nur einen einzigen Eintrag, der den Modem-Typ hayes beschreibt. Im wesentlichen wird hier definiert, in welchen Bahnen die Unterhaltung zwischen UUCP und dem Modem verlaufen soll. Wieder wird dies in Form eines Chat-Skripts angegeben, wie Sie ihm bereits im Zusammenhang mit dem Einloggen im Abschnitt 7.4.8 begegnet sind.

Der wichtige Teil des Chat-Skripts wird durch den Befehl chat angegeben. In dem Beispiel wartet UUCP zunächst auf keinerlei Reaktion des Modems (d.h. den leeren String), sondern schickt von sich aus die Sequenz ATZ. Dies ist die Aufforderung an das Modem, sich zu initialisieren und interne Variablen mit vordefinierten Werten zu besetzen. Diese Sequenz sollte auf jeden Fall geschickt werden, damit sich das Modem in einem definierten Anfangszustand befindet.

Als Antwort auf dieses Kommando wartet UUCP auf den String OK. Erhält es diesen, sendet es den nächsten String, der mit einer kurzen Verzögerung (\d) beginnt, und anschließend den Befehl ATV1E0Q0 absetzt. Dieser schaltet das lokale Modem-Echo aus, und stellt das Gerät auf Klartext-Antwortcodes ein. Wieder erwartet UUCP als Antwort hierauf OK und fordert das Modem anschließend auf, die gewünschte Telefonnummer zu wählen. Dies geschieht durch den Befehl ATDP, gefolgt von der eigentlichen Nummer. Anstelle von \D setzt UUCP die der sys-Datei entnommene Nummer ein. Zuletzt wartet es auf die Meldung CONNECT, mit der das Modem den erfolgreichen Verbindungsaufbau mit der Gegenstelle anzeigt.

Sollte UUCP innerhalb einer gewissen Zeit nicht den String finden, den das Chat-Skript angibt, so bricht es den Anwahlvorgang mit einer Fehlermeldung ab. Dieser Fehler wird in der Log-Datei als ``Timed out in modem chat'' vermerkt. Das kann beispielsweise passieren, wenn das Modem nicht eingeschaltet ist, aber auch, wenn beispielsweise die Gegenstelle besetzt ist. In diesem Fall liefert das Modem allerdings eine Fehlermeldung zurück, die im allgemeinen aufschlußreicher ist als ein bloßes ``Timed out''. Auf diese Fehlermeldungen können Sie UUCP trainieren, indem sie diese mit dem chat-fail Kommando angeben. Wann immer UUCP einen dieser chat-fail Strings erkennt, bricht es den Anwählvorgang ab und vermerkt die erhaltene Fehlermeldung in der Log-Datei.

Die in unserem Beispiel angegebenen Fehlermeldungen werden von einem Hayes-kompatiblen Modem zurückgegeben, wenn etwa der Anschluß besetzt ist (BUSY) oder nach dem Abheben kein Freizeichen zu hören ist (NO DIALTONE). Das Zeichen \s in diesem String markiert ein Leerzeichen.

Der letzte Befehl in diesem Eintrag beginnt mit dem Schlüsselwort dtr-toggle. Dieser Befehl veranlaßt UUCP, die DTR-Leitung (Data Terminal Ready) der seriellen Schnittstelle auf LOW zu ziehen, bevor es das Modem anspricht. Dies ist für manche Modems notwendig, die an dem Zustand der DTR ablesen, ob die Rechnerseite sie ansprechen will.

Testen der Konfiguration

 Nachdem Sie UUCP nun installiert haben, sollten Sie das System testen, indem Sie eine Verbindung mit cicero aufzubauen versuchen. Sie führen dazu folgende Kommandos aus:

$ uucico -s cicero -x 2
$ tail -f /var/spool/uucp/.Admin/audit.local
uucico cicero - (1993-12-06 21:55:02.18 4172) Calling system cicero (port cua1)
uucico cicero - (1993-12-06 21:55:37.42 4172) Login successful
uucico cicero - (1993-12-06 21:55:38.02 4172) Handshake successful (protocol 'g
' sending packet/window 256/7 receiving 256/7)
uucico cicero - (1993-12-06 22:01:35.45 4172) Protocol 'g' packets: sent 3, re
sent 0, received 3
uucico cicero - (1993-12-06 22:01:40.58 4172) Call complete (1 seconds 0 bytes 0 bps)

 

Der zweite Befehl erlaubt Ihnen, den Aufbau der Verbindung zu verfolgen.

Regelmäßige Verbindungen

 Wenn Sie Ihr System einmal soweit konfiguriert haben, daß Mail und News einwandfrei funktionieren, können Sie dazu übergehen, UUCP unbeaufsichtigt laufen zu lassen. Dazu können Sie beispielsweise für den Benutzer uucp einen cron-Auftrag anlegen, der zu festgelegten Zeiten uucico aufruft oder alte Log-Dateien wegwirft. Zum Beispiel könnten Sie folgendes in eine Datei crontab.uucp eintragen:

PATH=/usr/lib/uucp
0     22    *     *     *     uucico -s cicero
0     6     *     *     *     uucico -s cicero

Dies würde jeweils um 6 Uhr und 22 Uhr uucico aufrufen, um Daten mit cicero auszutauschen. Sie können den cron-Auftrag anschließend als Superuser mit folgendem Befehl installieren:

# crontab -u uucp -r crontab.uucp

Diese Lösung ist allerdings noch nicht ganz befriedigend, denn es ist möglich, daß bei cicero beispielsweise kurzzeitig besetzt ist; Ihr Anruf um 22 Uhr würde beispielsweise fehlschlagen, obwohl er vielleicht eine Minute später Erfolg gehabt hätte. Die Lösung ist hier, uucico mehrfach im Abstand von wenigen Minuten aufzurufen. Damit dies korrekt funktioniert, müssen Sie aber in der sys-Datei bei cicero noch eine Änderung vornehmen. Entweder für das in Frage stehende System oder im Defaults-Teil der sys-Datei tragen Sie die Option

success-wait            900

ein. Dies verhindert, daß uucico nach einer erfolgreichen Verbindung sofort wieder anruft. Das obige Beispiel setzt die Wartezeit auf 15 Minuten (gleich 900 Sekunden). Jetzt können Sie den cron-Job abändern, so daß uucico mehrere Male in Folge aufgerufen wird, aber höchstens einmal die Verbindung aufbaut:

PATH=/usr/lib/uucp
0,2,4,6     22    *     *     *     uucico -s cicero
0,2,4,6     6     *     *     *     uucico -s cicero


next up previous contents index
Next: Elektronische Post mit smail Up: Datenreisen und reisende Daten Previous: Seriell einloggen

Das Linux Anwenderhandbuch
(C) 1997 LunetIX