Copyright © 1996 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux: Wegweiser durch das Netzwerk" dann klicken Sie hier.


Kapitel 12
Verwalten von TaylorUUCP

UUCP wurde in den späten Siebzigern von Mike Lesk in den AT&T Bell Laboratories entwickelt. Es sollte ein einfaches Wähl-Netzwerk über normale Telefonleitungen zur Verfügung stellen. Weil die meisten Leute, die E-Mail und Usenet-News auf ihren Heimcomputern anwenden möchten, immer noch über Modems miteinander kommunizieren, ist UUCP bis heute recht weit verbreitet. Obwohl es eine ganze Reihe von UUCP-Implementierungen für eine Vielzahl unterschiedlicher Hardware-Plattformen und Betriebssysteme gibt, sind diese doch in hohem Maße zueinander kompatibel.

Aber wie beim größten Teil der Software, die sich über die Jahre irgendwie als »Standard« etabliert hat, gibt es kein UUCP, das man als das UUCP bezeichnen würde. Seit der ersten Version im Jahre 1976 war es einer ständigen Evolution unterworfen. Momentan gibt es zwei Hauptspezies, die sich hauptsächlich in der unterstützten Hardware und ihrer Konfiguration unterscheiden. Von diesen beiden Hauptversionen existieren die unterschiedlichsten Implementierungen, die jeweils leicht von den Ursprungsversionen abweichen.

Eine Spezies wird Version-2-UUCP genannt, was auf eine Implementierung von Mike Lesk, David A. Novitz und Greg Chessona aus dem Jahre 1977 zurückdatiert werden kann. Obwohl sie recht alt ist, wird sie noch häufig eingesetzt. Neuere Implementierungen von Version 2 bieten heute viel von dem Komfort der neueren UUCP-Arten.

Die zweite Sorte wurde 1983 entwickelt und wird allgemein als BNU (Basic Networking Utilities), HoneyDanBer-UUCP oder kurz HDB bezeichnet. Der Name wurde aus den Namen der Autoren -- P. Honeyman, D. A. Novitz und B. E. Redman -- abgeleitet. HDB wurde entwickelt, um einige Defizite der UUCP-Version 2 zu beseitigen. So wurden etwa neue Transfer-Protokolle aufgenommen, und das Spool-Verzeichnis ist so aufgeteilt worden, daß es nun ein Verzeichnis für jede Site gibt, mit der Sie Daten austauschen.

Die Implementierung von UUCP, die momentan mit Linux geliefert wird, ist Taylor-UUCP 1.05.(1) Neben den traditionellen Konfigurations-Dateien kann Taylor-UUCP auch so kompiliert werden, daß es die neuen, d. h. Taylor-Konfigurations-Dateien, interpretiert.

Version 1.06 wurde kürzlich veröffentlicht und wird in Kürze ihren Weg in die meisten Distributionen finden. Die Unterschiede zwischen diesen Versionen betreffen meist Features, die Sie niemals benutzen werden. Sie sollten also in der Lage sein, Taylor-UUCP 1.06 mit den Informationen aus diesem Buch zu konfigurieren.

So wie es in den meisten Linux-Distributionen enthalten ist, ist Taylor-UUCP üblicherweise für BNU-Kompatibilität oder für das Taylor-Konfigurations-Schema (oder beides) kompiliert. Das Taylor-Schema ist wesentlich flexibler und wohl auch einfacher zu verstehen als die häufig doch recht obskuren BNU-Konfigurations-Dateien. Ich werde also nachfolgend das Taylor-Schema behandeln.

Der Sinn dieses Kapitels ist nicht, Ihnen eine ausführliche Beschreibung jeder Kommandozeilen-Option der verschiedenen UUCP-Befehle zu geben. Vielmehr soll gezeigt werden, wie Sie einen funktionierenden UUCP-Knoten aufbauen können. Der erste Abschnitt gibt eine einfache Einführung, wie UUCP entfernte Programmausführung (remote execution) und Datei-Transfers implementiert. Wenn Ihnen UUCP nicht ganz fremd ist, können Sie zum Abschnitt UUCP-Konfigurations-Dateien springen, der die verschiedenen Dateien beschreibt, mit denen UUCP eingerichtet wird.

Allerdings setzen wir voraus, daß Ihnen die Benutzerprogramme des UUCP-Pakets bekannt sind. Dies sind uucp und uux. Eine Beschreibung können Sie den Online-Manpages entnehmen.

Neben den allgemein zugänglichen Programmen uux und uucp enthält das UUCP-Paket eine Reihe von Befehlen, die nur administrativen Zwecken dienen. Diese werden dazu genutzt, den UUCP-Transport über Ihren Knoten zu überwachen, alte Log-Dateien zu entfernen oder Statistiken zu erstellen. Keines dieser Programme wird hier beschrieben, weil sie bei den Hauptaufgaben von UUCP nur eine untergeordnete Rolle spielen. Nebenbei gesagt, sind sie sehr gut dokumentiert und recht einfach zu verstehen. Daneben gibt es noch eine dritte Kategorie, die die eigentlichen »Arbeitspferde« für UUCP stellt: uucico (wobei cico für copy-in copy-out steht) und uuxqt, das von einem entfernten Host gesandte Jobs ausführt. Auch diese werden in diesem Kapitel behandelt.

Diejenigen unter Ihnen, die in diesem Kapitel nicht alles finden, was sie benötigen, sollten die mit dem UUCP-Paket gelieferte Dokumentation lesen. Dies ist eine Reihe von Texinfo-Dateien, die die Einrichtung bei Verwendung des Taylor-Konfigurations-Schemas beschreiben.

Wenn Sie BNU- oder sogar (Oh Schreck!) Version-2-Konfigurations-Dateien verwenden wollen, kann ich das Buch Managing UUCP and Usenet von O'Reilly & Associates empfehlen. Ich fand es sehr hilfreich. Eine andere sehr gute Informationsquelle zu UUCP unter Linux ist Vince Skahans UUCP-HOWTO, das regelmäßig in comp.os.linux.announce gepostet wird.

Es existiert auch eine Newsgruppe zum Thema UUCP namens comp.mail.uucp. Wenn Sie Fragen zu Taylor-UUCP haben, sollten Sie sie lieber dort stellen als in den comp.os.linux-Gruppen.

UUCP-Transfer und entfernte Programmausführung

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 einem entfernten System ausgeführt wird, und einer Reihe von Dateien, die zwischen Sites übertragen werden sollen. Einer dieser beiden Teile kann dabei jeweils fehlen.

Nehmen wir zum Beispiel an, Sie haben den folgenden Befehl auf Ihrem Host eingegeben. Dieser sorgt dafür, daß UUCP die Datei netguide.ps auf den Host pablo kopiert und dort den Befehl lpr ausführt, mit dem die Datei gedruckt wird.

$ 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 der Job vorübergehend zwischengespeichert. Diese Technik wird Spooling genannt. Der Verzeichnisbaum, unter dem die Jobs gespeichert werden, wird daher auch Spool-Verzeichnis genannt und steht üblicherweise unter /var/spool/uucp. In unserem Beispiel würde die Job-Beschreibung Informationen zu dem Befehl (lpr) enthalten, der ausgeführt werden soll, zum Benutzer, der die Ausführung angefordert hat, sowie zu einer Reihe weiterer Dinge. Neben der Job-Beschreibung muß UUCP auch die Eingabedatei netguide.ps speichern.

Der exakte Ort und der Name 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 es für die Taylor-Konfiguration kompiliert, erzeugt UUCP Unterverzeichnisse unter Site-spezifischen Spool-Verzeichnissen für verschiedene Arten von Spool-Dateien.

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 (»Forwarding«), die für eine andere Site bestimmt sind.

Um zwischen wichtigen und weniger wichtigen Jobs zu unterscheiden, verknüpft UUCP eine Klasse (Grade) mit jedem Job. Dabei handelt es sich (bei absteigender Wichtigkeit) um einen einzelnen Buchstaben von 0 bis 9, A bis Z und a bis z. Mail wird normalerweise mit der Klasse B oder C gespoolt, während News mit N gespoolt werden. Jobs mit einer höheren Klasse werden früher übertragen. Sie können die Spool-Klasse 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, die während einer Übertragung erlaubt ist. Sie ist normalerweise auf z voreingestellt. Beachten Sie den terminologischen Widerspruch an dieser Stelle: Eine Datei wird nur dann übertragen, wenn sie 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 Netzwerk-Adresse umzuwandeln. Der zu öffnende Port muß ermittelt und die Adresse an den entsprechenden Socket gebunden werden.

Nachdem die Verbindung aufgebaut worden ist, muß eine Autorisierungs-Prozedur durchgeführt werden. Diese Prozedur besteht normalerweise darin, daß das entfernte System nach einem Loginnamen und eventuell nach einem Paßwort fragt. Dies wird im allgemeinen als Login-Chat bezeichnet. Die Autorisierungs-Prozedur 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 eine 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 etc. 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 Übertragungs-Protokoll zu einigen. Dieses Protokoll legt fest, wie Daten übertragen, auf ihre Konsistenz hin überprüft und im Fehlerfall erneut übertragen werden. Wegen der verschiedenen unterstützten 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 Protokoll-Treiber. An diesem Punkt führen die Treiber eventuell eine Protokoll-spezifische Initialisierungs-Sequenz 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 und daß er nun aufhängen kann. 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 Terminierungs-Nachrichten miteinander aus und schließen die Verbindung.

Wir gehen an dieser Stelle nicht detaillierter darauf ein: Sehen Sie sich dazu entweder die Quellen oder ein gutes Buch zu UUCP an. Im Netz kursiert auch ein wirklich antiquierter Artikel von David A. Novitz, der eine detaillierte Beschreibung des UUCP-Protokolls enthält.(2) Auch die Taylor-UUCP-FAQ beschreibt einige Details darüber, wie UUCP implementiert wurde. Es wird regelmäßig in comp.mail.uucp gepostet.

Kommandozeilen-Optionen von uucico

Dieser Abschnitt beschreibt die wichtigsten Kommandozeilen-Optionen für uucico.
-s system
Ruft das angegebene system an, wenn dies durch Rufzeitbeschränkungen nicht unterbunden wird.
-S system
Ruft das angegebene system an, wobei etwaige Bedingungen/Einschränkungen nicht beachtet werden.
-r1

Startet uucico im Master-Modus. Dies ist Standard, wenn die Optionen -s oder -S verwendet werden. Steht diese Option für sich allein, versucht uucico, alle in sys eingetragenen Dateien anzurufen, solange dies durch Ruf- oder Retry-Zeitbeschränkungen nicht unterbunden wird.

-r0
Startet uucico im Slave-Modus. Dies ist Standard, wenn die Optionen -s oder -S nicht verwendet werden. Im Slave-Modus wird davon ausgegangen, daß entweder die Standard-Ein-/Ausgabe mit einem seriellen Port verbunden ist, oder daß der mit der Option -p angegebene TCP-Port verwendet wird.
-x typ, -X typ
Schalte das Debugging für den angegebenen Typ an. Verschiedene Typen können in einer durch Kommata unterteilten Liste angegeben werden. Die folgenden Typen sind gültig: abnormal, chat, handshake, uucp-proto, proto, port, config, spooldir, execute, incoming und outgoing. Mit all werden alle Typen aktiviert. Aus Kompatibilitäts-Gründen mit anderen UUCP-Implementierungen kann statt dessen auch eine Nummer angegeben werden, die das Debugging für die ersten n Punkte aus der obigen Liste aktiviert.

Debugging-Nachrichten werden in der Datei Debug unter /var/spool/uucp festgehalten.

UUCP-Konfigurations-Dateien

Im Gegensatz zu einfacheren Datenübertragungs-Programmen wurde UUCP so konzipiert, daß es alle Übertragungen automatisch durchführen kann. Ist es einmal korrekt eingerichtet worden, ist ein tägliches Eingreifen des Administrators nicht mehr nötig. Die für diesen automatischen Transfer benötigten Informationen werden in einer Reihe von Konfigurations-Dateien festgehalten, die im Verzeichnis /usr/lib/uucp gehalten werden. Die meisten dieser Dateien werden nur beim Anwählen externer Hosts verwendet.

Eine sanfte Einführung in Taylor-UUCP

Die UUCP-Konfiguration als schwierig zu bezeichnen wäre eine Untertreibung. Tatsächlich ist sie eine haarige Angelegenheit, und das manchmal etwas kurz angebundene Format der Konfigurations-Dateien macht die Dinge auch nicht gerade einfacher (obwohl das Taylor-Format im Vergleich zu den älteren Formaten von HDB oder Version 2 schon wesentlich einfacher ist).

Um Ihnen ein Gefühl dafür zu vermitteln, wie diese Konfigurations-Dateien zusammenwirken, wollen wir Ihnen die wichtigsten vorstellen und einen Blick auf einige beispielhafte Einträge werfen. Wir gehen hier nicht ins Detail; genauere Beschreibungen folgen in späteren, separaten Abschnitten. Wenn Sie UUCP auf Ihrer Maschine einrichten möchten, sollten Sie am besten auf einige Beispieldateien zurückgreifen und diese schrittweise an Ihre Bedürfnisse anpassen. Sie können dazu entweder auf die nachfolgend aufgeführten oder auf die in Ihrer Linux-Distribution enthaltenen Dateien zurückgreifen.

Alle in diesem Abschnitt behandelten Dateien sind in /usr/lib/uucp oder einem darunterliegenden Unterverzeichnis zu finden. Manche Linux-Distributionen enthalten UUCP-Binaries, die sowohl die HDB- als auch die Taylor-Konfiguration unterstützen, und verwenden verschiedene Unterverzeichnisse für den jeweiligen Satz von Konfigurations-Dateien. Sie finden üblicherweise eine README-Datei in /usr/lib/uucp.

Damit UUCP ordnungsgemäß funktionieren kann, müssen die Dateien dem Benutzer uucp gehören. Einige enthalten Paßwörter und Telefonnummern und sollten daher die Zugriffsrechte 600 besitzen.(3)

Die zentrale UUCP-Konfigurations-Datei ist /usr/lib/uucp/config. Sie enthält die allgemeinen Parameter. Der wichtigste (und vorerst einzige) ist der UUCP-Name Ihres Host. In der virtuellen Brauerei wird vstout als UUCP-Gateway benutzt:

# /usr/lib/uucp/config -- UUCP-Haupt-Konfigurationsdatei
hostname         vstout
Die nächste wichtige Konfigurations-Datei ist sys. Sie enthält alle systemspezifischen Informationen zu Sites, mit denen Sie verbunden sind. Sie enthält den Namen der Site und Informationen zum Link selbst, beispielsweise die Telefonnummer bei einem Modem-Link. Ein typischer Eintrag für eine über Modem verbundene Site namens pablo würde wie folgt aussehen:
# /usr/lib/uucp/sys -- benenne UUCP-Nachbarn
# System: pablo
system          pablo
time            Any
phone           123-456
port            serial1
speed           38400
chat            ogin: vstout ssword: lorca
port benennt die zu verwendende Schnittstelle und time gibt die Zeit an, in der das System angerufen werden kann. chat gibt das Login-Chat-Skript an -- die Sequenz von Strings, die ausgetauscht werden müssen, damit uucico sich bei pablo einloggen kann. Wir kommen später noch auf Chat-Skripten zurück. Der port-Befehl zeigt einfach auf einen Eintrag in der port-Datei. (Siehe Abbildung 12--1.) Sie können jeden beliebigen Namen verwenden, solange er auf einen gültigen Eintrag in port verweist.

Die port-Datei enthält die Link-spezifischen Informationen. Bei Modem-Links enthält sie die zu verwendende Gerätedatei, die unterstützten Geschwindigkeiten und die an der Schnittstelle hängende Wähleinrichtung. Der nachfolgende Eintrag beschreibt /dev/cua1 (also COM 2), woran ein NakWell-Modem angeschlossen ist, das mit einer Geschwindigkeit von bis zu 38400 bps betrieben werden kann. Der Name des Ports ist so gewählt, daß er mit dem Portnamen aus sys übereinstimmt.

# /usr/lib/uucp/port -- UUCP-Ports
# /dev/cua1 (COM 2)
port            serial1
type            modem
device          /dev/cua1
speed           38400
dialer          nakwell

Die Information zur Wähleinrichtung (Dialer) wird in einer weiteren Datei namens -- Sie ahnen es -- dial festgehalten. Für jeden Wähleinrichtungs-Typ enthält sie grundsätzlich eine Reihe von Befehlen, die ausgeführt werden müssen, um eine Gegenseite anzurufen, deren Telefonnummer angegeben wurde. Auch dies ist ein Chat-Skript. Der Eintrag für das NakWell-Modem könnte etwa so aussehen:

# /usr/lib/uucp/dial -- Wähleinrichtungs-Informationen (je Wähleinrichtung)
# NakWell-Modems
dialer          nakwell
chat            "" ATZ OK ATDT\T CONNECT

Die mit chat beginnende Zeile bestimmt den Modem-Chat, d. h. die Sequenz von Befehlen, die ans Modem geschickt und vom Modem empfangen wird, um es zu initialisieren und die gewünschte Nummer zu wählen. Die Sequenz \T wird dabei von uucico durch die Telefonnummer ersetzt.

Um eine grobe Vorstellung davon zu bekommen, wie uucico mit diesen Konfigurations-Dateien umgeht, stellen Sie sich vor, Sie hätten den folgenden Befehl eingegeben:

$ uucico -s pablo

Zuallererst sucht uucico in der Datei sys nach pablo. Aus dem sys-Eintrag für pablo ersieht es, daß es den Port serial1 verwenden soll, um die Verbindung aufzubauen. Aus der Datei port erfährt es, daß dies ein Modem-Port ist, an den ein NakWell-Modem angeschlossen ist.

uucico durchsucht nun dial nach einem Eintrag, der das NakWell-Modem beschreibt. Nachdem dieser Eintrag gefunden wurde, wird aufgrund dieser Information die serielle Schnittstelle /dev/cua1 geöffnet und der Dialer-Chat ausgeführt: Es wird ATZ gesendet, auf die Antwort OK gewartet etc. Wird der String \T erkannt, wird dieser durch die Telefonnummer (123-456) ersetzt, die in der sys-Datei angegeben wurde.

Nachdem das Modem CONNECT zurückliefert, steht die Verbindung, und der Modem-Chat ist komplett. uucico kehrt nun zur sys-Datei zurück und führt den Login-Chat durch. In unserem Beispiel würde es zuerst auf den Prompt login: warten und den Loginnamen (vstout) senden. Danach würde es auf den Prompt password: warten und das Paßwort lorca übertragen.

Nachdem die Autorisierung abgeschlossen ist, wird erwartet, daß die Gegenseite ihr eigenes uucico startet. Danach beginnen beide Seiten mit der vorher beschriebenen Handshake-Phase.

Abbildung 12--1 zeigt, auf welche Weise die Konfigurations-Dateien voneinander abhängig sind.

Abbildung 12-1. Zusammenspiel der Konfigurations-Dateien bei Taylor-UUCP

Was UUCP wissen muß

Bevor Sie damit beginnen, die UUCP-Konfigurations-Dateien zu schreiben, müssen Sie zuerst einige Informationen sammeln, die UUCP benötigt.

Zuerst müssen Sie wissen, an welche serielle Schnittstelle Ihr Modem angeschlossen ist. Normalerweise sind die (DOS-)Schnittstellen COM 1 bis COM 4 auf die Gerätedateien /dev/cua0 bis /dev/cua3 abgebildet. Die meisten Distributionen wie z. B. Slackware erzeugen einen Link namens /dev/modem, der auf die entsprechende cua*-Gerätedatei zeigt, und konfigurieren kermit, seyon etc. so, daß diese Datei benutzt wird. Wenn dies der Fall ist, sollten Sie /dev/modem auch in Ihrer UUCP-Konfiguration verwenden.

Der Grund für den symbolischen Link liegt darin, daß alle Programme die serielle Schnittstelle durch eine sogenannte Lock-Dateisperren, um zu signalisieren, daß sie benutzt wird. Die Namen dieser Lock-Dateien setzen sich aus dem String LCK.. und einem Gerätenamen zusammen, beispielsweise LCK..cua1. Benutzen Programme nun unterschiedliche Namen für dasselbe Gerät, werden die entsprechenden Lock-Dateien nicht erkannt. Die Folge wäre die Unterbrechung beider Sessions, wenn sie gemeinsam gestartet worden wären. Dies ist nicht unbedingt ungewöhnlich, wenn Sie Ihre UUCP-Aufrufe durch crontab-Einträge erledigen.

Details zur Einrichtung Ihrer seriellen Schnittstellen entnehmen Sie bitte dem Kapitel 4, Konfiguration der seriellen Hardware.

Als nächstes müssen Sie herausfinden, mit welcher Geschwindigkeit Ihr Modem und Linux kommunizieren. Diese Geschwindigkeit sollten Sie auf die höchstmögliche effektive Übertragungsrate einstellen. Die effektive Übertragungsrate kann dabei wesentlich höher sein als die eigentliche physikalische Übertragungsrate Ihres Modems. Beispielsweise senden und empfangen viele Modems Daten mit 2400 Bps. Durch Verwendung von Kompressions-Protokollen wie V.42bis kann die wirkliche Übertragungsrate auf bis zu 9600 Bps erhöht werden.

Soll UUCP irgend etwas Sinnvolles anstellen, müssen Sie natürlich auch die Telefonnummer wissen, die angerufen werden soll. Außerdem benötigen Sie einen gültigen Login-ID und eventuell ein Paßwort für diese Maschine.(4)

Sie müssen auch ganz genau wissen, wie Sie sich in das System einloggen. Müssen Sie die Return-Taste drücken, bevor der Login-Prompt erscheint? Wird login: oder user: ausgegeben? Dies wird für die Erstellung des Chat-Skripts benötigt. Wenn Sie das nicht wissen, oder wenn der normale Chat fehlschlägt, wählen Sie das System mit einem Terminal-Programm wie kermit oder minicom an, und schreiben Sie genau auf, was Sie tun müssen.

Site-Namen

Genau wie bei TCP/IP-basierten Netzwerken muß Ihr Host auch in UUCP-Netzen einen Namen besitzen. Solange Sie UUCP einfach zur Datenübertragung zu und von Sites verwenden wollen, die Sie direkt anwählen, oder die in einem lokalen Netz präsent sind, muß dieser Name keinen Standards entsprechen.(5)

Wenn Sie UUCP dagegen für einen Mail- oder News-Link verwenden, sollten Sie darüber nachdenken, den Namen über das UUCP Mapping Project registrieren zu lassen. Das UUCP Mapping Project wird im Kapitel 13, Elektronische Post besprochen. Selbst wenn Sie an einer Domain teilnehmen, sollten Sie einen offiziellen UUCP-Namen für Ihre Site besitzen.

Häufig wird der UUCP-Name so gewählt, daß er dem ersten Teil des voll qualifizierten Domainnamens entspricht. Ist die Domain-Adresse Ihrer Site etwa swim.twobirds.com, könnte der UUCP-Hostname swim lauten. Stellen Sie sich einfach vor, daß UUCP-Sites einander duzen. Natürlich können Sie auch einen UUCP-Namen verwenden, der mit dem voll qualifizierten Domainnamen nichts zu tun hat.

Stellen Sie aber sicher, daß der unqualifizierte Site-Name nicht in Mail-Adressen verwendet wird, solange er nicht als offizieller UUCP-Name registriert ist.(6) Im besten Fall landet Mail an einen nicht registrierten UUCP-Host irgendwo in einem großen schwarzen Sack. Wenn Sie einen Namen verwenden, der bereits von einem anderen Server registriert ist, wird die Post an diese Site weitergeleitet und wird deren Postmaster beträchtliche Kopfschmerzen bereiten.

Standardmäßig verwendet das UUCP-Paket den über hostname gesetzten Namen als den UUCP-Namen der Site. Dieser Name wird normalerweise im Skript /etc/rc.local gesetzt. Wenn sich Ihr UUCP-Name vom gesetzten Hostnamen unterscheidet, müssen Sie die Option hostname in der config-Datei benutzen, um uucico den UUCP-Namen mitzuteilen. Dies wird nachfolgend beschrieben.

Taylor-Konfigurations-Dateien

Kehren wir wieder zu den Konfigurations-Dateien zurück. Taylor-UUCP erhält seine Informationen aus den folgenden Dateien:

config
Das ist die Haupt-Konfigurationsdatei. Sie können hier den UUCP-Namen Ihrer Site eintragen.
sys
Diese Datei beschreibt alle Ihnen bekannten Sites. Jeder Eintrag enthält den Namen, die Rufzeiten, die Rufnummer und den Gerätetyp der Site sowie Angaben zum Login.
port
Enthält Einträge, die jeden verfügbaren Port beschreiben, zusammen mit der unterstützten Übertragungs-Geschwindigkeit und dem zu verwendenden Dialer.
dial
Beschreibt die zum Aufbau einer Telefonverbindung verwendeten Dialer.
dialcode
Enthält die Definitionen der symbolischen Wählkodes, falls Sie welche benutzen.
call
Enthält den Loginnamen und das Paßwort, die beim Anruf eines Systems verwendet werden sollen. Wird selten benutzt.
passwd
Enthält Loginnamen und Paßwörter, die Systeme beim Einloggen benutzen könnten. Diese Datei wird nur verwendet, wenn uucico seine eigene Paßwortprüfung durchführt.

Taylor-Konfigurations-Dateien bestehen normalerweise aus Zeilen, die aus Schlüsselwort-/Wert-Paaren bestehen. Das Doppelkreuz (#) leitet einen Kommentar ein, der bis zum Ende der Zeile geht. Um ein Doppelkreuz in eigener Bedeutung zu verwenden, müssen Sie ihm einen Backslash (\) voranstellen.

Es gibt eine ganze Reihe von Optionen, die Sie über die Konfigurations-Dateien einstellen können. Wir können an dieser Stelle nicht alle Parameter besprechen, sondern wollen uns auf die wichtigsten beschränken. Danach sollten Sie in der Lage sein, einen Modem-basierten UUCP-Link zu konfigurieren. Weitere Abschnitte beschreiben dann die Modifikationen, die notwendig sind, wenn Sie UUCP über TCP/IP oder eine direkte serielle Leitung verwenden wollen. Eine komplette Referenz finden Sie in den den Taylor-UUCP-Sourcen beiliegenden Texinfo-Dokumenten.

Wenn Sie glauben, daß Sie Ihr UUCP-System vollständig konfiguriert haben, können Sie Ihre Konfiguration mit dem uuchk-Tool (zu finden in /usr/lib/uucp) überprüfen. uuchk liest Ihre Konfigurations-Dateien und gibt eine detaillierte Liste mit den Konfigurationswerten für jedes System aus.

Allgemeine Konfigurations-Optionen -- die config-Datei

Für viel mehr als den UUCP-Hostnamen werden Sie diese Datei nicht benutzen. Standardmäßig benutzt UUCP den mit hostname besetzten Namen, es ist aber grundsätzlich eine gute Idee, den UUCP-Namen explizit hier einzutragen. Nachfolgend eine config-Beispieldatei:

# /usr/lib/uucp/config -- UUCP-Haupt-Konfigurationsdatei
hostname        vstout
Eine Reihe weiterer Parameter kann hier stehen, z. B. der Name des Spool-Verzeichnisses oder die Zugriffsrechte für »anonymous UUCP«. Letztere werden noch in einem späteren Abschnitt beschrieben.

UUCP über andere Systeme informieren -- die sys-Datei

Die sys-Datei beschreibt die Systeme, die Ihre Maschine kennt. Ein Eintrag beginnt mit dem Schlüsselwort system und umfaßt alle Zeilen bis zur nächsten system-Direktive. Diese Zeilen beschreiben alle für diese Site spezifischen Parameter. Üblicherweise enthält ein Systemeintrag Parameter wie die Telefonnummer und den Login-Chat.

Parameter, die vor der ersten system-Zeile stehen, setzen Werte, die für alle Systeme gelten. Normalerweise enthält dieser Abschnitt solche Dinge wie allgemeine Protokoll-Parameter.

Nachfolgend werden die wichtigsten Felder etwas detaillierter besprochen.

Systemname

Der Befehl system benennt das entfernte (remote) System. Sie müssen den richtigen Namen des Systems angeben und keinen erfundenen Alias, weil uucico diesen Namen mit dem vom entfernten System gelieferten Namen während des Logins vergleicht.(7)

Jeder Systemname darf nur einmal vorkommen. Wenn Sie mehrere Konfigurationen für dasselbe System benutzen wollen (beispielsweise verschiedene Telefonnummern, die uucico nacheinander versuchen soll), können Sie »Alternativen« (alternates) beschreiben. Alternativen werden nachfolgend besprochen.

Telefonnummer

Wird das entfernte System über eine Telefonleitung erreicht, enthält das Feld phone die vom Modem zu wählende Nummer. Sie kann verschiedene Platzhalter (Tokens) enthalten, die von uucico während der Wählprozedur interpretiert werden. Ein Gleichheitszeichen sorgt dafür, daß auf einen sekundären Wählton gewartet wird; ein Bindestrich sorgt für eine Pause von einer Sekunde. So kommen etwa einige Telefonanlagen ins Stocken, wenn zwischen einem speziellen Zugriffs-Kode und der eigentlichen Telefonnummer nicht eine kurze Pause besteht.(8)

Jede eingebettete alphabetische Zeichenkette kann verwendet werden, um Site-abhängige Informationen wie Vorwahlen zu verstecken. Ein solcher String wird in eine Telefonnummer übersetzt, indem er in der Datei dialcode nachgesehen wird. Nehmen wir einfach die folgende dialcode-Datei an:

# /usr/lib/uucp/dialcode -- Übersetzung von Vorwahlnummern
Bogoham         024881
Coxton          035119
Mit solchen Eintragungen können Sie Telefonnummern wie Bogoham7732 in der sys-Datei verwenden, was die ganze Sache vielleicht ein wenig leserlicher macht.

port und speed

Die Optionen port und speed werden benutzt, um zu bestimmen, welches Gerät für die Verbindung zum anderen System verwendet werden soll, und mit welcher Geschwindigkeit die Daten über dieses Gerät übertragen werden sollen.(9) Ein system-Eintrag kann jeweils eine der beiden Optionen oder beide zusammen enthalten. Wenn in port nach einem passenden Eintrag gesucht wird, kommen nur die Ports in Frage, die den passenden Portnamen und/oder die passende Geschwindigkeit haben.

Normalerweise sollte die Option speed ausreichen. Wenn Sie nur ein serielles Gerät in port definiert haben, wird uucico sowieso immer die richtige Wahl treffen, d. h. es genügt, wenn Sie die gewünschte Geschwindigkeit angeben. Selbst wenn Sie mehrere Modems an Ihrem System hängen haben, werden Sie häufig den Ports keinen Namen zuweisen. Wenn nämlich uucico mehrere passende Einträge findet, versucht es jedes einzelne Gerät zu öffnen, bis es ein unbenutztes gefunden hat.

Der Login-Chat

Sie haben das Login-Chat-Skript ja bereits kennengelernt, mit dem uucico mitgeteilt wird, wie es sich in das entfernte System einzuloggen hat. Es setzt sich aus einer Reihe von Strings zusammen, die vom lokalen uucico-Prozeß erwartet und übertragen werden sollen. Die Intention dabei ist, uucico so lange warten zu lassen, bis die entfernte Maschine den Login-Prompt sendet, und dann den Loginnamen zu übertragen. Danach wird auf den Paßwort-Prompt gewartet und das Paßwort übertragen. Die erwarteten und zu sendenden Strings werden abwechselnd angegeben. uucico hängt automatisch ein Wagenrücklaufzeichen (\r) an jeden zu sendenden String an. Ein einfaches Chat-Skript könnte etwa wie folgt aussehen:
login: vstout ssword: catch22
Ihnen wird aufgefallen sein, daß die Felder mit den erwarteten Strings nicht den ganzen Prompt enthalten. Auf diese Weise kann aber sichergestellt werden, daß das Login auch dann erfolgreich ist, wenn das entfernte System die Meldung Login: anstelle von login: ausgibt.

uucico erlaubt auch eine Art bedingter Ausführung, z. B. wenn der getty der entfernten Maschine zuerst zurückgesetzt werden muß, bevor es einen Prompt sendet. Zu diesem Zweck können Sie einen »Unter-Chat« an den erwarteten String anhängen, der durch einen Bindestrich abgesetzt wird. Der Unter-Chat wird nur ausgeführt, wenn der Haupt-Chat fehlschlägt, etwa durch einen Timeout-Fehler. Eine Möglichkeit, dieses Feature zu benutzen, besteht darin, einen BREAK an die entfernte Site zu schicken, wenn kein Login-Prompt erscheint. Das folgende Beispiel ist ein Allzweck-Chat-Skript, das auch funktionieren sollte, wenn zuerst die Return-Taste gedrückt werden muß, bevor das Login erscheint. Das erste leere Argument ("") weist UUCP an, nicht erst auf irgendetwas zu warten, sondern den nachfolgenden String direkt zu senden.

"" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22
Eine ganze Reihe von speziellen Strings und Escape-Zeichen können in einem Chat-Skript vorkommen. Nachfolgend ist ein Teil der Sonderzeichen aufgeführt, die in dem zu erwartenden String vorkommen können:
»«
Der leere String. Er weist uucico an, nicht auf einen String zu warten, sondern direkt mit dem Senden des nachfolgenden Strings zu beginnen.
\t
Tabulatorzeichen.
\r
Wagenrücklauf (Carriage Return).
\s
Leerzeichen (Space). Notwendig, um Leerzeichen in Chat-Strings einzubetten.
\n
Zeilenvorschub (Newline).
\\
Backslash-Zeichen.

Bei zu sendenden Strings können Sie zusätzlich zu den obigen noch die folgenden Escape-Zeichen und -Strings verwenden:

EOT
Zeichen für das Ende der Übertragung (»End of Transmission«, ^D).
BREAK
Break-Zeichen.
\c
Unterdrückt die Übertragung eines Wagenrücklaufzeichens am Ende des Strings.
\d
Verzögert das Senden um eine Sekunde.
\E
Aktiviert die Überprüfung des Echos. In diesem Fall muß uucico darauf warten, daß alles, was es an die Gegenseite geschickt hat, auch zurückgeschickt wird, bevor es im Chat-Skript weitergeht. Hauptsächlich bei Modem-Chats sinnvoll (die wir später noch behandeln werden). Standardmäßig ist die Echoprüfung ausgeschaltet.
\e
Deaktiviert die Echoprüfung.
\K
Wie BREAK.
\p
Pause für einen Sekundenbruchteil.

Alternativen (Alternates)

Manchmal ist es wünschenswert, für ein System mehrere Einträge zu besitzen, beispielsweise wenn das System über mehrere Telefonnummern erreicht werden kann. Bei Taylor-UUCP ist dies durch die Definition sogenannter »Alternativen« (Alternates) möglich.

Eine Alternative übernimmt alle Einstellungen vom Haupteintrag und gibt nur solche Werte an, die überschrieben oder dem Haupteintrag hinzugefügt werden sollen. Eine Alternative ist vom Systemeintrag durch eine Zeile mit dem Schlüsselwort alternate abgesetzt.

Wenn Sie zwei Telefonnummern für pablo benutzen wollen, können Sie den entsprechenden sys-Eintrag folgendermaßen verändern:

system       pablo
phone        123456
... Einträge wie oben...
alternate
phone        123455
Wird pablo angerufen, verwendet uucico zuerst die Nummer 123456. Schlägt dies fehl, versucht es die Alternative. Der alternative Eintrag behält alle Einstellungen des Haupteintrags bei und überschreibt nur die Telefonnummer.

Einschränken der Rufzeiten

Taylor-UUCP bietet eine ganze Reihe von Möglichkeiten, die Zeiten einzuschränken, in denen Anrufe zum entfernten Rechner plaziert werden können. Dies könnte notwendig sein, wenn ein Host seine Dienste zu bestimmten Zeiten einschränkt; Sie können so aber auch Zeiten ausschließen, in denen die Telefongebühren relativ hoch sind. Rufzeiteinschränkungen können aber immer überschrieben werden, indem Sie uucico mit den Optionen -S oder -f aufrufen.

Standardmäßig unterbindet Taylor-UUCP den Verbindungs-Aufbau zu allen Zeiten, d. h. Sie müssen Zeitangaben in irgendeiner Form in Ihre sys-Datei aufnehmen. Wenn Zeitbeschränkungen für Sie kein Thema sind, können Sie in der sys-Datei die Option time mit dem Wert Any versehen.

Den einfachsten Weg, die Rufzeit einzuschränken, bietet der Eintrag time, dem ein aus einem Tag- und einem Zeit-Feld bestehender String folgt. Das Tag-Feld kann eine Kombination von Mo, Tu, We, Th, Fr, Sa, Su oder den Schlüsselwörtern Any, Never oder Wk (für Werktags) enthalten. Das Zeit-Feld besteht aus zwei Werten im 24-Stunden-Format, die durch einen Bindestrich voneinander getrennt sind. Sie bestimmen den Zeitraum, in dem Anrufe durchgeführt werden können. Die Zeichen werden ohne Leerzeichen miteinander kombiniert. Mehrere Zeitspezifikationen können durch Kommata zusammengruppiert werden.

time            MoWe0300-0730,Fr1805-2000
Dieses Beispiel erlaubt Anrufe Montags und Mittwochs von 3 Uhr bis 7:30 Uhr morgens und Freitags zwischen 6:05 Uhr und 10:00 Uhr abends. Überschreitet eine Zeitangabe die Mitternachtsgrenze, z. B. Mo1830-0600, wird dies als Montag zwischen Mitternacht und 6 Uhr morgens sowie zwischen 6:30 Nachmittags und Mitternacht interpretiert.

Die speziellen Zeit-Strings Any und Never tun genau, was Sie von ihnen erwarten: Anrufe können zu beliebigen Zeiten bzw. gar nicht getätigt werden.

Dem Befehl time kann optional ein zweites Argument folgen, das die Wahlwiederholung in Minuten enthält. Schlägt der Versuch, eine Verbindung aufzubauen, fehl, verhindert uucico für ein bestimmtes Intervall eine erneute Anwahl des entfernten Host. Legen Sie etwa ein Wiederhol-Intervall von 5 Minuten fest, verweigert uucico nach dem letzten Fehler den Anruf des entfernten Host für die Dauer von 5 Minuten. Standardmäßig arbeitet uucico mit einem Schema, bei dem sich das Wiederhol-Intervall mit jedem Fehlversuch exponentiell erhöht.

Mit dem Befehl timegrade können Sie die maximale Spool-Klasse für jeden Anruf festlegen. Nehmen wir beispielsweise an, Sie haben die folgenden timegrade-Befehle in einen system-Eintrag aufgenommen:

timegrade           N Wk1900-0700,SaSu
timegrade           C Any
Auf diese Weise können Jobs mit einer Spool-Klasse von C oder höher (üblicherweise hat Mail die Klasse B oder C) bei jedem Anruf übertragen werden. News (üblicherweise Klasse N) dagegen werden nur nachts und an Wochenenden übertragen.

Genau wie time kann auch timegrade ein Wiederhol-Intervall in Minuten als optionales drittes Argument enthalten.

Ein warnendes Wort ist hier angebracht. Zuerst einmal gilt die Option timegrade nur für das, was Ihr System überträgt. Die Gegenseite kann immer noch alles übertragen, was sie will. Sie können die Option call-timegrade verwenden, um das andere System aufzufordern, nur Jobs ab einer bestimmten Klasse zu übertragen. Es garantiert Ihnen aber niemand, daß der andere Host sich daran hält.(10)

Außerdem wird das Feld timegrade nicht überprüft, wenn sich ein entferntes System bei Ihnen einwählt, d. h. alle aufgelaufenen Jobs für dieses System werden übertragen. Jedoch kann das andere System Ihr uucico explizit auffordern, sich auf eine bestimmte Spool-Klasse zu beschränken.

Verfügbare Geräte -- die port-Datei

Die Datei port klärt uucico über die vorhandenen Ports auf. Dabei kann es sich um Modem-Ports handeln, aber auch andere Arten wie direkte Leitungen und TCP-Sockets werden unterstützt.

Genau wie die sys-Datei besteht auch port aus separaten Einträgen, die mit dem Schlüsselwort port beginnen, dem der Portname folgt. Dieser Name kann im port-Befehl der sys-Datei genutzt werden. Der Name muß nicht eindeutig sein. Existieren verschiedene Ports mit demselben Namen, probiert uucico jeden einzelnen, bis es einen findet, der momentan nicht verwendet wird.

Dem port-Befehl sollte unmittelbar der type-Befehl folgen, der anzeigt, welche Art von Port beschrieben wird. Gültige Typen sind modem, direct für direkte Verbindungen und tcp für TCP-Sockets. Fehlt der port-Befehl, ist der Port-Typ auf Modem voreingestellt.

In diesem Abschnitt werden nur Modem-Ports behandelt; TCP-Ports und direkte Leitungen werden in einem späteren Abschnitt besprochen.

Bei Modems und direkten Ports müssen Sie das Gerät angeben, über das »nach draußen« gewählt wird. Dazu dient der Befehl device. Üblicherweise handelt es sich dabei um eine spezielle Gerätedatei im /dev-Verzeichnis, wie /dev/cua1.(11)

Im Falle eines Modems bestimmt der Port-Eintrag auch, welche Art von Modem an den Port angeschlossen ist. Unterschiedliche Modems müssen auch verschieden konfiguriert werden. Selbst angeblich Hayes-kompatible Modems müssen nicht wirklich kompatibel untereinander sein. Darum müssen Sie uucico mitteilen, wie das Modem zu initialisieren ist und wie es die gewünschte Nummer wählen soll. Taylor-UUCP bewahrt die Beschreibungen aller Dialer in einer Datei namens dial auf. Soll eine dieser Beschreibungen verwendet werden, müssen Sie den Namen des Dialers mit dem Befehl dialer bekanntgeben.

Manchmal möchten Sie ein Modem auch auf verschiedene Arten einsetzen, je nachdem, welches System Sie anrufen. So verstehen es beispielsweise einige ältere Modems nicht, wenn ein Highspeed-Modem versucht, eine Verbindung mit 14400 Bps aufzubauen; sie hängen einfach auf, anstatt die Verbindung mit einer Geschwindigkeit von 9600 Bps aufzubauen. Wenn Sie wissen, daß die Site drop ein solch einfaches Modem benutzt, müssen Sie Ihr Modem anders einstellen, wenn Sie diesen Server anwählen. Dazu müssen Sie einen zusätzlichen Port-Eintrag in Ihrer port-Datei angeben, der einen anderen Dialer benutzt. Jetzt können Sie dem neuen Port einen anderen Namen wie serial1-slow geben und diesen bei der port-Direktive im drop-Systemeintrag in sys verwenden.

Eine bessere Möglichkeit besteht darin, die Ports anhand der von ihnen unterstützten Geschwindigkeiten zu unterscheiden. Die beiden Port-Einträge für die eben beschriebene Situation könnten dann wie folgt aussehen:

# NakWell-Modem; Highspeed-Verbindungen
port            serial1         # Portname
type            modem           # Modem-Port
device          /dev/cua1       # COM2
speed           38400           # unterstützte Geschwindigkeit
dialer          nakwell         # Dialer
# NakWell-Modem; langsame Verbindung
port            serial1         # Portname
type            modem           # Modem-Port
device          /dev/cua1       # COM2
speed           9600            # unterstützte Geschwindigkeit
dialer          nakwell-slow    # hohe Geschwindigkeit gar nicht erst versuchen
Der Systemeintrag für drop würde nun serial1 als Portnamen enthalten, aber nur eine Geschwindigkeit von 9600 Bps erlauben. uucico würde dann automatisch den zweiten Port-Eintrag benutzen. Alle anderen Sites, die eine Geschwindigkeit von 38400 Bps in ihrem Systemeintrag angeben, würden weiterhin den ersten Port-Eintrag verwenden.

Wie eine Nummer gewählt wird -- die dial-Datei

Die Datei dial beschreibt, wie die verschiedenen Dialer verwendet werden. Traditionell spricht man bei UUCP von Dialern und nicht von Modems, weil es früher gängige Praxis war, daß eine (teure) automatische Wähleinrichtung für eine ganze Reihe von Modems genutzt wurde. Heutzutage verfügen die meisten Modems über eingebaute Wahlunterstützung, d. h. diese Unterscheidung ist ein wenig überholt.

Dessen ungeachtet können verschiedene Dialer oder Modems auch verschiedene Konfigurationen benötigen. Diese können Sie in der Datei dial beschreiben. Einträge in dial beginnen mit dem Befehl dialer, der den Namen des Dialers festlegt.

Der wichtigste Eintrag neben dialer ist der Modem-Chat, der über den Befehl chat spezifiziert wird. Genau wie beim Login-Chat besteht er aus einer Reihe von Strings, die uucico an den Dialer sendet, und den Antworten, die es daraufhin erwartet. Dieser Befehl wird normalerweise benutzt, um das Modem in einen definierten Zustand zurückzusetzen und die gewünschte Nummer zu wählen. Der folgende dialer-Eintrag zeigt einen typischen Modem-Chat für ein Hayes-kompatibles Modem:

# NakWell-Modem; Highspeed-Verbindung
dialer          nakwell         # Dialername
chat            "" ATZ OK\r ATH1E0Q0 OK\r ATDT\T CONNECT
chat-fail       BUSY
chat-fail       ERROR
chat-fail       NO\sCARRIER
dtr-toggle      true
Der Modem-Chat beginnt mit "", dem »leeren« String. uucico sendet also direkt den Befehl ATZ an das Modem. ATZ ist der Hayes-Befehl zum Rücksetzen des Modems. Nun wird gewartet, bis das Modem OK zurückschickt, bevor der nächste Befehl übertragen wird, der das lokale Echo ausschaltet und ähnliches. Nachdem das Modem wieder mit OK antwortet, sendet uucico den Wählbefehl ATDT. Die Escape-Sequenz \T wird dabei durch die Telefonnummer ersetzt, die im Systemeintrag der sys-Datei gefunden wurde. uucico wartet dann darauf, daß das Modem die Zeichenkette CONNECT zurückschickt, was bedeutet, daß die Verbindung mit dem entfernten Modem erfolgreich aufgebaut werden konnte.

Natürlich passiert es auch, daß die Verbindung mit dem entfernten System nicht zustandekommt, beispielsweise, weil das andere System gerade mit jemand anderem redet und besetzt ist. In einem solchen Fall gibt das Modem eine entsprechende Fehlermeldung zurück. Modem-Chats sind nicht in der Lage, solche Meldungen zu handhaben; uucico wartet weiter auf den erwarteten String, bis ein Timeout erfolgt. In der UUCP-Log-Datei erscheint daher nur die nichtssagende Meldung »timed out in chat script« und nicht der wahre Grund für den Fehler.

Bei Taylor-UUCP können Sie aber uucico über diese Nachrichten informieren, indem Sie den Befehl chat-fail wie oben gezeigt verwenden. Erkennt uucico einen chat-fail-String während der Ausführung des Modem-Chats, bricht es den Anruf ab und speichert die Fehlermeldung in der UUCP-Log-Datei.

Der letzte Befehl im obigen Beispiel weist UUCP an, den Zustand der Steuerleitung DTR umzuschalten, bevor der Modem-Chat beginnt. Normalerweise aktiviert der serielle Treiber DTR (Data Terminal Ready), wenn der Prozeß das Gerät öffnet, um dem angeschlossenen Modem mitzuteilen, daß jemand mit ihm kommunizieren möchte. Mit dtr-toggle ziehen Sie DTR für kurze Zeit auf Low und dann wieder High. Viele Modems können so konfiguriert werden, daß sie beim Herunterziehen von DTR auflegen, in den Befehlsmodus gehen oder sich selbst zurücksetzen.(12)

UUCP über TCP

So absurd es auch klingen mag, so ist die Verwendung von UUCP zur Datenübertragung über TCP keine so schlechte Idee, besonders wenn große Datenmengen wie Usenet-News übertragen werden sollen. Bei TCP-basierten Links werden News im allgemeinen über das NNTP-Protokoll übertragen, bei dem Artikel individuell ohne Komprimierung und andere Optimierungen angefordert und übertragen werden. Wenn dies für große Sites mit mehreren Newsfeeds auch angemessen sein mag, so ist dies für kleinere Sites mit langsameren Verbindungen wie z. B. ISDN doch recht unvorteilhaft. Diese Sites können die Qualitäten von TCP mit dem Vorteil verknüpfen, News in großen Paketen zu verschicken, die komprimiert, und so mit geringem Overhead übertragen werden können. Eine Standardlösung, solche Batches zu übertragen, besteht in der Verwendung von UUCP über TCP.

In sys würden Sie ein System, das über TCP angerufen wird, wie folgt beschreiben:

system          gmu
address         news.groucho.edu
time            Any
port            tcp-conn
chat            ogin: vstout word: clouseau
Der Befehl address enthält die IP-Adresse des Host oder seinen voll qualifizierten Domainnamen. Der entsprechende port-Eintrag liest sich wie folgt:
port            tcp-conn
type            tcp
service         540

Der Eintrag bedeutet, daß eine TCP-Verbindung verwendet werden soll, wenn ein sys-Eintrag tcp-conn benutzt. Gleichzeitig soll uucico versuchen, die Verbindung mit dem entfernten Host über den TCP-Netzwerk-Port 540 herzustellen. Das ist die standardmäßige Port-Nummer des UUCP-Dienstes. Anstelle der Port-Nummer können Sie auch einen symbolischen Portnamen an den service-Befehl übergeben. Die zu diesem Namen passende Port-Nummer wird in der Datei /etc/services nachgesehen. Der für den UUCP-Dienst übliche Name lautet uucpd.

Verwendung einer direkten Verbindung

Stellen Sie sich vor, Sie verwenden eine Direktleitung von Ihrem System vstout zum System tiny. Genau wie bei einem Modem auch, müssen Sie einen entsprechenden Systemeintrag in Ihre sys-Datei aufnehmen. Der Befehl port gibt dabei den Port an, über den tiny angesprochen wird.

system          tiny
time            Any
port            direct1
speed           38400
chat            ogin: cathcart word: catch22

In der port-Datei müssen Sie den seriellen Port für diese direkte Verbindung beschreiben. Ein dialer-Eintrag ist nicht nötig, weil zum Wählen ja keine Veranlassung besteht.

port            direct1
type            direct
speed           38400
device          /dev/ttyS1

Wer darf was bei UUCP -- Zugriffsrechte bestimmen

Befehlsausführung

Die Aufgabe von UUCP besteht darin, Dateien von einem System auf ein anderes zu kopieren, sowie die Ausführung bestimmter Befehle auf dem entfernten Host anzufordern. Natürlich wollen Sie als Administrator kontrollieren, welche Rechte Sie anderen Systemen einräumen wollen -- die Ausführung jedes Befehls auf Ihrem System ist definitiv keine gute Idee.

Standardmäßig erlaubt Taylor-UUCP anderen Systemen nur die Ausführung von rmail und rnews auf Ihrem Rechner. Diese Programme werden häufig für den Austausch von E-Mail und Usenet-News über UUCP verwendet. Der per Voreinstellung von uuxqt verwendete Suchpfad kann während der Kompilierung über eine Option bestimmt werden, sollte aber /bin, /usr/bin und /usr/local/bin enthalten. Um den für ein bestimmtes System gültigen Satz von Befehlen zu ändern, können Sie das Schlüsselwort commands in der Datei sys benutzen. Auf ähnliche Weise kann der Suchpfad mit dem Befehl command-path angepaßt werden. Beispielsweise könnten Sie dem System pablo die Ausführung von rsmtp zusätzlich zu rmail und rnews erlauben wollen:(13)

system          pablo
...
commands        rmail rnews rsmtp

Dateitransfer

Taylor-UUCP erlaubt es Ihnen auch, den Dateitransfer bis ins kleinste Detail zu regeln. Im Extremfall können Sie den Transfer von und zu einem bestimmten System völlig unterbinden. Setzen Sie einfach request auf no, und das entfernte System wird nicht mehr in der Lage sein, Dateien von Ihrem System herunterzuladen oder auf Ihr System zu übertragen. Auf dieselbe Weise können Sie verhindern, daß die Benutzer Ihres Systems Dateien von Ihrem bzw. auf Ihr System übertragen, indem Sie transfer auf no setzen. Standardmäßig dürfen die Benutzer des lokalen und des entfernten Systems Dateien up- und downloaden.

Zusätzlich können Sie konfigurieren, aus welchen und in welche Verzeichnisse kopiert werden soll. Üblicherweise werden Sie den Zugriff für andere Systeme auf eine bestimmte Verzeichnis-Hierarchie beschränken wollen, aber gleichzeitig den lokalen Benutzern erlauben, Dateien aus ihrem Home-Verzeichnis zu übertragen. Häufig dürfen die Benutzer anderer Systeme nur Dateien übertragen, die sich im öffentlichen UUCP-Verzeichnis /var/spool/uucppublic befinden. Dies ist der traditionelle Ort, an dem Dateien öffentlich zugänglich gemacht werden, ähnlich wie bei FTP-Servern im Internet. Auf dieses Verzeichnis bezieht man sich im allgemeinen unter Verwendung des Tilde-Zeichens.

Taylor-UUCP bietet vier verschiedene Befehle zur Konfiguration der Verzeichnisse, aus denen und in die Dateien kopiert werden dürfen. Diese sind: local-send, das eine Liste mit Verzeichnissen enthält, aus denen ein Benutzer Dateien lesen darf; local-receive, das die Liste der Verzeichnisse enthält, in die ein Benutzer Dateien kopieren darf. Dazu kommen remote-send und remote-receive, die dieselbe Aufgabe für Anforderungen von einem entfernten System übernehmen. Sehen wir uns das folgende Beispiel an:

system          pablo
...
local-send      /home ~
local-receive   /home ~/receive
remote-send     ~ !~/incoming !~/receive
remote-receive  ~/incoming

Der Eintrag local-send erlaubt es den Benutzern ihres Host, Dateien unter /home und aus dem öffentlichen UUCP-Verzeichnis an pablo zu übertragen. Der Befehl local-receive erlaubt es den Benutzern, Dateien im allgemein schreibbaren Verzeichnis receive unter uucppublic oder in jedem allgemein schreibbaren Verzeichnis unter /home zu empfangen. Der Befehl remote-send erlaubt es pablo, Dateien aus /var/spool/uucppublic anzuforden, mit Ausnahme der Dateien aus den Verzeichnissen incoming und receive. Die Ausnahmen erkennt uucico an dem Ausrufezeichen vor dem Verzeichnisnamen. Die letzte Zeile erlaubt es pablo schließlich, alle Dateien in incoming abzulegen.

Das Hauptproblem beim Dateitransfer mit UUCP ist, daß es Dateien nur in Verzeichnissen ablegt, die allgemein gelesen werden können. Dies könnte Benutzer in Versuchung führen, anderen Benutzern Fallen zu stellen etc. Leider gibt es für dieses Problem keine Lösung, es sei denn, Sie verhindern den Dateitransfer unter UUCP ganz.

Weiterleitung (Forwarding)

UUCP bietet einen Mechanismus, mit dem andere Systeme Dateitransfers in Ihrem Namen erledigen. Das erlaubt Ihnen beispielsweise, daß seci eine Datei von uchile für Sie empfängt und an Ihr System sendet. Der folgende Befehl würde dies erreichen:

$ uucp -r seci!uchile!~/find-ls.gz ~/uchile.files.gz

Die Technik, einen Job über mehrere Systeme laufen zu lassen, wird Forwarding (Weiterleitung) genannt. Im obigen Beispiel könnte der Grund dafür, Forwarding zu benutzen, der sein, daß seci UUCP-Zugriff auf uchile besitzt, Ihr Host aber nicht. Wenn Sie ein UUCP-System betreiben, werden Sie diesen Forwarding-Service auf einige wenige Hosts beschränken wollen, bei denen Sie sicher sind, daß sie keine horrende Telefonrechnung auflaufen lassen, indem die neueste X11R6-Source-Release übertragen wurde.

Standardmäßig ist bei Taylor-UUCP das Forwarding komplett deaktiviert. Um Forwarding für ein bestimmtes System zu aktivieren, müssen sie den Befehl forward verwenden. Mit diesem Befehl geben Sie eine Liste von Sites an, von und zu denen das System Jobs weiterleiten kann. Der UUCP-Administrator von seci würde beispielsweise die folgenden Zeilen in seine sys-Datei aufnehmen, um pablo die Anforderung von Dateien von uchile zu ermöglichen:

####################
# pablo
system          pablo
...
forward         uchile
####################
# uchile
system          uchile
...
forward-to      pablo

Der Eintrag forward-to für uchile ist notwendig, damit die Dateien auch an pablo weitergeleitet werden. Anderenfalls würde UUCP sie einfach aussortieren. Dieser Eintrag ist eine Variante des forward-Befehls, der uchile nur das Senden von Dateien an pablo über seci erlaubt, aber nicht andersherum.

Um das Forwarding für jedes System zu erlauben, müssen Sie das spezielle Schlüsselwort ANY (in Großbuchstaben!) benutzen.

Das Einwählen in Ihr System einrichten

Wenn Sie Ihre Site so einrichten wollen, daß sich jemand einwählen kann, müssen Sie Logins auf Ihrem seriellen Port erlauben und einige Systemdateien so anpassen, daß sie UUCP-Accounts enthalten. Wie dies genau funktioniert, ist Thema dieses Abschnitts.

getty einrichten

Soll eine serielle Leitung als Einwählpunkt verwendet werden, müssen Sie einen getty-Prozeß für diesen Port aktivieren. Allerdings sind einige getty-Implementierungen für diese Aufgabe nicht richtig geeignet, weil der serielle Port häufig zum ein- und auswählen benutzt wird. Sie müssen daher sicherstellen, daß ein getty verwendet wird, das sich den seriellen Port mit anderen Programmen wie uucico oder minicom teilen kann. Ein solches Programm ist uugetty aus dem getty_ps-Paket. Bei den meisten Linux-Distributionen ist es dabei; suchen Sie nach uugetty in Ihrem /sbin-Verzeichnis. Ein anderes Programm, das ich kenne, ist Gert Doerings mgetty, das auch den Empfang von Faxen unterstützt. Die neuesten Versionen dieser Programme sind auf sunsite.unc.edu zu finden.

Dieser Abschnitt kann nicht beschreiben, wie unterschiedlich uugetty und mgetty Logins behandeln. Ausführlichere Informationen finden Sie im Serial-HOWTO von Greg Hankins und in der zu getty_ps und mgetty gehörenden Dokumentation.

UUCP-Accounts einrichten

Als nächstes müssen Sie Benutzer-Accounts einrichten, über die sich andere Sites in Ihr System einloggen und eine UUCP-Verbindung aufbauen können. Üblicherweise vergeben Sie für jedes System einen eigenen Loginnamen. Wenn Sie einen Account für das System pablo einrichten, könnten Sie ihm beispielsweise den Benutzernamen Upablo geben.

Bei Systemen, die sich über eine serielle Schnittstelle einwählen, müssen Sie diesen Account üblicherweise in die Paßwort-Datei des Systems (/etc/passwd) aufnehmen. Sie sind sicher nicht schlecht beraten, wenn Sie alle UUCP-Logins in einer speziellen Gruppe wie uuguest aufnehmen. Das Home-Verzeichnis des Accounts sollte dabei auf das öffentliche Spool-Verzeichnis /var/spool/uucppublic zeigen; als Login-Shell muß uucico verwendet werden.

Wenn Sie mit dem Shadow-Paßwort-System arbeiten, können Sie diese Arbeit mit useradd erledigen:

# useradd -d /var/spool/uucppublic -G uuguest -s /usr/lib/uucp/uucico Upablo
Wenn Sie die Suite nicht verwenden, müssen Sie /etc/passwd wohl von Hand editieren und eine Zeile wie die folgende einfügen. 5000 und 150 stehen dabei für die numerischen UIDs und GIDs, die dem Benutzer Upablo und der Gruppe uuguest zugewiesen wurden.
Upablo:x:5000:150:UUCP Account:/var/spool/uucppublic:/usr/lib/uucp/uucico
Nach der Installation des Accounts müssen Sie ihn noch aktivieren, indem Sie das Paßwort mit dem Befehl passwd einrichten.

Um UUCP-Systeme zu bedienen, die sich über TCP mit Ihrem Server verbinden, müssen Sie inetd so einrichten, daß es die auf dem uucp-Port eingehenden Verbindungen verwaltet. Dies geschieht durch Einfügen der folgenden Zeile in Ihre /etc /inetd.conf:(14)

uucp   stream  tcp   nowait  root  /usr/sbin/tcpd  /usr/lib/uucp/uucico -l
Durch die Option -l führt uucico seine eigene Login-Autorisierung durch. Genau wie beim normalen login-Programm wird auch hier nach dem Login und dem Paßwort gefragt, zur Verifizierung wird aber eine private Paßwort-Datei anstelle von /etc/passwd benutzt. Die private Paßwort-Datei heißt /usr/lib/uucp/passwd und enthält Paare von Loginnamen und Paßwörtern.
Upablo  IslaNegra
Ulorca  co'rdoba
Diese Datei muß natürlich uucp gehören und die Rechte 600 besitzen.

Wenn sich diese Datenbank für Sie so gut anhört, daß Sie sie auch für Ihre normalen seriellen Logins verwenden wollen, werden Sie wohl enttäuscht sein zu hören, daß dies ohne größere Umstände leider nicht möglich ist. Zuerst einmal benötigen Sie dazu Taylor-UUCP 1.05, weil es getty erlaubt, den Loginnamen des Anrufers über die Option -u an uucico weiterzugeben.(15) Dann müssen Sie getty dazu bringen, uucico anstelle der normalen /bin/login zu starten. Mit getty_ps geht dies, indem Sie die Option LOGIN in der Konfigurations-Datei einrichten. Allerdings deaktiviert dies automatisch alle interaktiven Logins. Andererseits besitzt mgetty ein schönes Feature, mit dem Sie abhängig vom Benutzer-Namen unterschiedliche Login-Befehle ausgeführt werden können. So können Sie mgetty etwa anweisen, uucico für all die Benutzer zu verwenden, deren Loginname mit einem großen U beginnt, während für alle anderen Benutzer der normale login-Befehl Anwendung findet.

Um Ihre UUCP-Benutzer vor Anrufern zu schützen, die einen falschen Systemnamen angeben und sich deren gesamte Mail ansehen, sollten Sie called-login-Befehle für jeden Systemeintrag in Ihrer sys-Datei aufnehmen. Dies wird im nächsten Abschnitt erläutert.

Wie Sie sich vor Schwindlern schützen

Ein Hauptproblem von UUCP besteht darin, daß das anrufende System bei der Angabe seines Namens lügen kann. Es gibt seinen Namen zwar nach dem Login bekannt, aber der Server hat keine Möglichkeit, diesen zu überprüfen. Der Eindringling könnte sich also unter seinem eigenen UUCP-Account einloggen und anschließend vorgaukeln, jemand anders zu sein, um sich die Mail der anderen Site anzueignen. Dies ist besonders schwerwiegend, wenn Sie Logins via Anonymous-UUCP anbieten, wo die Paßwörter öffentlich gemacht werden.

Solange Sie sich nicht ganz sicher sind, daß alle an Ihr System angeschlossenen Sites vertrauenswürdig sind, müssen Sie sich gegen diese Art von Eindringlingen schützen. Das Mittel gegen diese Krankheit besteht darin, von jedem System einen bestimmten Loginnamen zu erwarten. Dieser wird durch den Befehl called-login in sys spezifiziert. Ein solcher Systemeintrag könnte etwa wie folgt aussehen:

system          pablo
... normale Optionen ...
called-login    Upablo
Das Ergebnis ist, daß jedesmal, wenn ein System sich einloggt und vorgibt, pablo zu sein, uucico prüft, ob es sich unter Upablo eingeloggt hat. Wenn nicht, wird das anrufende System abgewiesen und die Leitung wird unterbrochen. Sie sollten es sich zur Gewohnheit machen, den Befehl called-login bei jedem System zu verwenden, das Sie in Ihre sys-Datei aufnehmen. Es ist wichtig, dies für alle Systeme zu tun, gleichgültig, ob sie Ihre Site jemals anwählen oder nicht. Bei Sites, die Sie niemals anrufen, sollten Sie called-login auf irgendeinen wirren Namen, wie etwa neverlogsin, setzen.

Seien Sie paranoid -- Rufsequenz-Prüfungen (Call Sequence Checks)

Eine andere Möglichkeit, Eindringlinge zu erkennen und abzuwehren, bieten sogenannte Rufsequenz-Prüfungen (Call Sequence Checks). Diese helfen beim Schutz vor Eindringlingen, denen es irgendwie gelungen ist, an ein Paßwort zu gelangen und sich in das UUCP-System einzuloggen.

Bei Rufsequenz-Prüfungen speichern beide Maschinen die Anzahl der bislang aufgebauten Verbindungen. Diese Zahl wird bei jeder neuen Verbindung erhöht. Nach dem Login sendet der Anrufer seine Rufsequenz-Nummer, die vom System mit der eigenen Zahl verglichen wird. Stimmen die Zahlen nicht überein, wird die Verbindung unterbrochen. Wird die Zahl zu Beginn zufällig gewählt, haben es Angreifer schwer, die richtige Nummer zu erraten.

Aber Rufsequenz-Prüfungen tun noch mehr für Sie als das: Selbst wenn eine besonders schlaue Person Ihre Rufsequenz-Nummer und Ihr Paßwort ermittelt haben sollte, finden Sie dies heraus. Dringt ein Angreifer in Ihren UUCP-Account ein und stiehlt Ihnen Ihre Mail, wird die Rufsequenz-Nummer um eins erhöht. Wenn Sie beim nächsten Mal versuchen, sich einzuloggen, wird das entfernte uucico Sie ablehnen, weil die Nummern nicht mehr übereinstimmen!

Haben Sie die Rufsequenz-Prüfungen aktiviert, sollten Sie Ihre Log-Dateien regelmäßig auf Fehlermeldungen überprüfen, die auf mögliche Angriffe hinweisen. Weist Ihr System die Rufsequenz-Nummer ab, die ihm von einem System angeboten wurde, schreibt uucico eine Nachricht wie »Out of sequence call rejected.« in die Log-Datei. Wurde Ihr System abgewiesen, weil die Sequenznummer nicht übereinstimmt, finden Sie eine Nachricht wie »Handshake failed (RBADSEQ)« in Ihrer Log-Datei vor.

Um die Rufsequenz-Prüfung zu aktivieren, müssen Sie den folgenden Befehl zu Ihrem Systemeintrag hinzufügen:

# Rufsequenz-Prüfung aktivieren
sequence        true
Außerdem müssen Sie eine Datei erzeugen, die die Sequenznummer selbst enthält. Taylor-UUCP bewahrt diese Zahl in einer Datei namens .Sequence im Spool-Verzeichnis des anderen Rechners auf. Sie muß uucp gehören und den Modus 600 besitzen (d. h. sie kann nur von uucp gelesen und geschrieben werden). Am besten initialisieren Sie diese Datei mit einer willkürlichen Zahl, auf die sich beide Seiten verständigt haben. Anderenfalls könnte ein Angreifer versuchen, die Nummer zu ermitteln, indem er beispielsweise alle Zahlen unter 60 ausprobiert.
# cd /var/spool/uucp/pablo
# echo 94316 > .Sequence
# chmod 600 .Sequence
# chown uucp.uucp .Sequence
Natürlich muß auch die Gegenseite die Rufsequenz-Prüfung aktiviert haben und mit genau derselben Nummer beginnen wie Sie.

Anonymous UUCP

Wenn Sie den Zugriff auf Ihr System über »anonymous UUCP« ermöglichen wollen, müssen Sie zuerst, wie oben beschrieben, einen speziellen Account dafür einrichten. In der Praxis wird für diesen anonymen Account häufig uucp als Loginname und Paßwort verwendet.

Zusätzlich müssen Sie einige Sicherheitsoptionen für unbekannte Systeme einrichten. So werden Sie üblicherweise verhindern wollen, daß diese Systeme irgendwelche Befehle auf Ihrem Rechner ausführen können. Nun können Sie diese Parameter aber nicht in der sys-Datei eintragen, weil der system-Eintrag einen Systemnamen erwartet, den Sie aber nicht haben. Taylor-UUCP löst dieses Problem mit dem Befehl unknown. unknown kann in der config-Datei verwendet werden, um Befehle anzugeben, die üblicherweise in einem Systemeintrag vorkommen können:

unknown         remote-receive ~/incoming
unknown         remote-send ~/pub
unknown         max-remote-debug none
unknown         command-path /usr/lib/uucp/anon-bin
unknown         commands rmail
Dies schränkt unbekannte Systeme darauf ein, Dateien unter dem Verzeichnis pub herunterzuladen und ins Verzeichnis incoming unter /var/spool/uucppublic zu kopieren. Die nächste Zeile stellt sicher, daß uucico alle Anforderungen ignoriert, das lokale Debugging zu aktivieren. Die letzten beiden Zeilen ermöglichen unbekannten Systemen die Ausführung von rmail, wobei der von uucico verwendete Suchpfad allerdings auf ein privates Verzeichnis namens anon-bin beschränkt ist. Auf diese Weise können Sie ein spezielles rmail anbieten, das beispielsweise alle Mail zur Prüfung an den Super-User weiterleitet. So können anonyme Benutzer den Verwalter des Systems erreichen, ohne irgendwelche Mails an andere Sites verschicken zu können.

Um »anonymous UUCP« zu aktivieren, müssen Sie mindestens eine unknown-Zeile in config aufnehmen. Anderenfalls lehnt uucico alle unbekannten Systeme ab.

Low-Level-Protokolle unter UUCP

Zur Abstimmung von Session-Kontrolle und Dateitransfer mit dem anderen Ende verwendet uucico einen Satz von standardisierten Nachrichten. Diese werden häufig als »High-Level-Protokoll« bezeichnet. Während der Initialisierungs- und Aufhängphase werden diese einfach als einfache Zeichenketten übertragen. Während der eigentlichen Transferphase wird aber ein zusätzliches Low-Level-Protokoll genutzt, das nahezu transparent für die höheren Level ist. Auf diese Weise werden Fehlerprüfungen z. B. auf Modem-Leitungen ermöglicht.

Protokoll-Übersicht

Da UUCP über verschiedene Arten von Verbindungen wie serielle Leitungen, TCP oder sogar X.25 verwendet werden kann, werden spezifische Low-Level-Protokolle benötigt. Zusätzlich haben verschiedene UUCP-Implementierungen unterschiedliche Protokolle hervorgebracht, die ungefähr dasselbe tun.

Protokolle können in zwei Kategorien eingeteilt werden: Paket- und Stream-orientierte Protokolle. Protokolle der letztgenannten Variante übertragen Dateien als ganzes und berechnen möglichst eine Prüfsumme. Dies geschieht nahezu frei von Overhead, setzt aber eine zuverlässige Leitung voraus, weil jeder Fehler die erneute Übertragung der gesamten Datei zur Folge hat. Diese Protokolle werden üblicherweise bei TCP-Verbindungen verwendet, sind aber bei Telefonleitungen nicht angemessen. Obwohl moderne Modems eine recht gute Fehlerkorrektur besitzen, sind sie doch nicht perfekt, und es gibt keine Fehlererkennung zwischen Ihrem Computer und dem Modem.

Auf der anderen Seite teilen Paket-orientierte Protokolle die Datei in viele kleine Stücke gleicher Größe auf. Jedes Paket wird separat verschickt und empfangen, eine Prüfsumme wird berechnet, und eine Bestätigung wird an den Sender zurückgeschickt. Um dies noch effektiver zu machen, wurden sogenannte »Sliding-Window-Protokolle« eingeführt, die eine beschränkte Anzahl (ein Window) noch ausstehender Bestätigungen zu einer bestimmten Zeit ermöglichen. Das reduziert die Zeit, die uucico während einer Übertragung warten muß, ganz erheblich. Der im Vergleich zu den Stream-basierten Protokollen jedoch relativ große Overhead macht Paketprotokolle über TCP allerdings ineffizient.

Auch die Datenbreite macht einen Unterschied. Manchmal ist die Übertragung von 8-Bit-Zeichen über eine serielle Leitung unmöglich, weil die Verbindung über einen dummen Terminal-Server läuft, der das achte Bit abschneidet. Sollen 8-Bit-Zeichen über eine 7-Bit-Verbindung übertragen werden, müssen sie für die Übertragung besonders markiert werden. Im schlimmsten Fall wird die zu übertragende Datenmenge verdoppelt, obwohl eine von der Hardware durchgeführte Komprimierung das wieder kompensieren kann. Leitungen, bei denen beliebige 8-Bit-Zeichen übertragen werden können, werden häufig als 8-Bit-sauber bezeichnet. Dies ist bei allen TCP-, aber auch bei den meisten Modem-Verbindungen der Fall.

Taylor-UUCP 1.04 unterstützt die folgenden Protokolle:

g
Dies ist das am weitesten verbreitete Protokoll und sollte von nahezu allen uucicos verstanden werden. Es führt eine sorgfältige Fehlerprüfung durch und ist daher für rauschende Telefonverbindungen besonders geeignet. g benötigt eine saubere 8-Bit-Verbindung. Es ist ein Paket-orientiertes Protokoll, das die Sliding-Window-Technik benutzt.
i
Ein bidirektionales Paket-Protokoll, das Dateien zur selben Zeit senden und empfangen kann. Es benötigt eine Vollduplex-Verbindung und einen sauberen 8-Bit-Datenpfad. Momentan wird es nur von Taylor-UUCP verstanden.
t
Dieses Protokoll ist für die Benutzung über eine TCP-Verbindung oder andere wirklich fehlerfreie Netzwerke gedacht. Es verwendet Pakete von 1024 Bytes und eine saubere 8-Bit-Verbindung.
e
Sollte grundsätzlich dasselbe tun wie t. Der Hauptunterschied liegt darin, daß e ein Stream-basiertes Protokoll ist.
f
Für die Verwendung über zuverlässige X.25-Verbindungen gedacht. Es ist ein Stream-basiertes Protokoll und erwartet einen 7 Bit breiten Datenpfad. 8-Bit-Zeichen müssen besonders gekennzeichnet werden, was es sehr ineffizient machen kann.
G
Die System V Release 4-Version des g-Protokolls. Wird auch von einigen anderen UUCP-Versionen verstanden.
a
Entspricht dem ZMODEM-Protokoll. Benötigt eine 8-Bit-Verbindung, markiert aber bestimmte Steuerzeichen wie XON und XOFF.

Einstellen des Übertragungs-Protokolls


Alle Protokolle erlauben einige Variationen bei den Paketgrößen, Timeouts und ähnlichem. Normalerweise arbeiten die voreingestellten Werte unter Standardbedingungen gut, sind aber nicht für jede Situation optimal geeignet. Zum Beispiel verwendet das g-Protokoll Window-Größen von 1 bis 7 und Paketgrößen in Zweierpotenzen von 64 bis 4096. (Die meisten in Linux-Distributionen enthaltenen Binaries verwenden eine Window-Größe von 7 und 128-Byte-Pakete.) Wenn Ihre Telefonleitung so verrauscht ist, daß immer mehr als 5 Prozent der Pakete verlorengehen, sollten Sie die Paketgröße verringern und das Window verkleinern. Andererseits kann der Protokoll-Overhead bei sehr guten Telefonverbindungen unnötig verschwendet werden, so daß Sie die Paketgröße auf 512 oder sogar auf 1024 Byte erhöhen können.

Taylor-UUCP stellt Ihnen mit dem protocol-parameter-Befehl in der sys-Datei einen Mechanismus zur Verfügung, mit dem Sie diese Parameter an Ihre Bedürfnisse anpassen können. Um etwa, wenn Sie mit pablo kommunizieren, die Paketgröße des g-Protokolls auf 512 zu setzen, müssen Sie folgendes hinzufügen:

system          pablo
...
protocol-parameter g  packet-size  512
Die einstellbaren Parameter und ihre Namen sind von Protokoll zu Protokoll verschieden. Eine komplette Liste können Sie der bei den Taylor-UUCP-Quellen beiliegenden Dokumentation entnehmen.

Bestimmte Protokolle wählen

Nicht jede Implementierung von uucico spricht und versteht jedes Protokoll. Daher müssen sich beide Prozesse während der Initialisierungs-Phase auf ein gemeinsames Protokoll verständigen. Der uucico-Master bietet dem Slave eine Liste unterstützter Protokolle durch Senden von Pprotlistan, aus denen sich der Slave eines aussuchen kann.

Basierend auf dem verwendeten Port-Typ (Modem, TCP oder Direkt), stellt uucico eine Standardliste mit Protokollen zusammen. Bei Modem- oder Direktverbindungen enthält diese Liste üblicherweise i, a, g, G und j. Bei TCP-Verbindungen sind t, e, i, a, g, G, j und f vorhanden. Diese Standardliste können Sie mit dem Befehl protocols überschreiben, der sowohl in einem System- als auch in einem Port-Eintrag stehen kann. Sie könnten etwa den Eintrag für Ihren Modem-Port in der port-Datei wie folgt erweitern:

port            serial1
...
protocols       igG
Jede über diesen Port ein- oder ausgehende Verbindung müßte dann i, g oder G verwenden. Wird keines von diesen vom anderen System unterstützt, schlägt die Kommunikation fehl.

Fehlersuche

Dieser Abschnitt beschreibt, was bei einer UUCP-Verbindung schiefgehen kann, und gibt einige Ratschläge, wo nach Fehlern zu suchen ist. Allerdings habe ich diese Probleme aus dem Kopf zusammengestellt. Es gibt wesentlich mehr, was noch schiefgehen kann.

In jedem Fall sollten Sie mit der Option -xall das Debugging aktivieren und sich die Ausgaben in Debug im Spool-Verzeichnis ansehen. Das sollte Ihnen helfen, das Problem schnell zu lokalisieren. Ich habe es auch immer als hilfreich empfunden, den Lautsprecher des Modems zu aktivieren, wenn keine Verbindung hergestellt werden kann. Bei Hayes-kompatiblen Modems erreichen Sie dies durch Einfügen von ATL1M1 OK im Modem-Chat der dial-Datei.

Zuallererst sollten Sie immer kontrollieren, ob die Dateizugriffsrechte korrekt gesetzt sind. uucico sollte Setuid uucp sein, und alle Dateien in /usr/lib/uucp, /var /spool/uucp und /var/spool/uucppublic sollten uucp gehören. Es gibt auch einige versteckte Dateien(16) im Spool-Verzeichnis, die auch uucp gehören müssen.

uucico behauptet andauernd »Wrong time to call«: Das bedeutet wahrscheinlich, daß Sie im Systemeintrag in sys keinen time-Eintrag spezifiziert haben, der bestimmt, wann ein System angerufen werden darf. Vielleicht haben Sie aber auch die Zeit so eingestellt, daß ein Anruf momentan einfach nicht erlaubt ist. Wird keine Zeitangabe gemacht, setzt uucico voraus, daß das System niemals angerufen werden kann.

uucico beschwert sich, »site is already locked«: Das bedeutet, daß uucico im Verzeichnis /var/spool/uucp eine Lock-Datei für das andere System entdeckt hat. Die Lock-Datei könnte von einem früheren Anruf zu diesem System stammen, der abgestürzt ist oder sonstwie abrupt beendet wurde. Es ist aber auch durchaus möglich, daß ein anderer uucico-Prozeß irgendwo im Speicher sitzt und versucht, das entfernte System anzurufen und dabei im Chat-Skript steckengeblieben ist etc. Wenn dieser Prozeß die Verbindung nicht erfolgreich herstellen kann, brechen Sie ihn mit einem Hangup-Signal ab, und entfernen Sie alle Lock-Dateien, die von ihm übriggeblieben sind.

Ich kann die Verbindung mit der anderen Site herstellen, aber das Chat-Skript schlägt fehl: Sehen Sie sich den Text an, den Sie von der anderen Site empfangen. Wenn er unverständlich ist, kann es sich um ein Geschwindigkeitsproblem handeln. Anderenfalls sollten Sie prüfen, ob er wirklich mit dem übereinstimmt, was Ihr Chat-Skript erwartet. Denken Sie daran, daß der Chat-Skript zu Beginn auf einen String wartet. Wenn Sie den Login-Prompt empfangen und Ihren Namen senden, aber niemals den Paßwort-Prompt erhalten, sollten Sie eine Verzögerung einbauen, bevor Sie ihn senden, möglicherweise sogar zwischen den einzelnen Buchstaben. Sie könnten zu schnell für Ihr Modem sein.

Mein Modem wählt nicht: Wenn Ihr Modem nicht anzeigt, daß die DTR-Leitung aktiviert wurde, während uucico eine externe Verbindung aufbaut, haben Sie uucico möglicherweise nicht das richtige Gerät angegeben. Wenn das Modem DTR erkennt, prüfen Sie mit einem Terminal-Programm, ob Sie zum Modem schreiben können. Wenn ja, aktivieren Sie das Echo mit \E zu Beginn des Modem-Chats. Erfolgt kein Echo Ihrer Befehle während des Modem-Chats, sollten Sie prüfen, ob die Geschwindigkeit für Ihr Modem zu hoch oder zu niedrig ist. Läuft das Echo, sollten Sie überprüfen, ob die Modem-Antworten deaktiviert oder auf numerische Werte eingestellt sind. Prüfen Sie, ob das Chat-Skript selbst in Ordnung ist. Denken Sie daran, daß Sie zwei Backslashes schreiben müssen, um einen an das Modem zu senden.

Mein Modem versucht zu wählen, kommt aber nicht raus: Fügen Sie eine Verzögerung in die Telefonnummer ein. Das ist besonders nützlich, wenn Sie aus einer Nebenstellenanlage herauswählen. Wenn Sie normalerweise das Impuls-Wahlverfahren benutzen, probieren Sie das Mehrfrequenz-Wahlverfahren aus. In manchen Ländern haben die Telekom-Gesellschaften ihr Netz schrittweise modernisiert. Manchmal hilft die Impulswahl.

Meine Log-Datei sagt, daß ich extrem viele Pakete verliere: Das sieht nach einem Geschwindigkeitsproblem aus. Möglicherweise ist die Verbindung zwischen Computer und Modem zu langsam (denken Sie daran, die schnellste effektive Übertragungsrate einzustellen). Vielleicht ist auch Ihre Hardware zu langsam, um auf Interrupts reagieren zu können. Mit dem NSC 16550A auf Ihrer seriellen Schnittstelle sind 38 Kbps vernünftig machbar. Ohne FIFOs dagegen (z. B. der 16450-Chip) sind 9600 Bps die Grenze. Stellen Sie auch sicher, daß der Hardware-Handshake auf der seriellen Leitung aktiviert ist.

Es ist auch häufig der Fall, daß der Hardware-Handshake für den Port nicht aktiviert ist. Taylor-UUCP 1.04 besitzt keine Möglichkeit, den RTS/CTS-Handshake einzuschalten. Sie müssen ihn explizit aus der rc.serial mit dem folgenden Befehl aktivieren:

$ stty crtscts < /dev/cua3
Ich kann mich einloggen, aber der Handshake schlägt fehl: Nun, da kann es eine Reihe von Problemen geben. Die Ausgabe in der Log-Datei sollten Ihnen viel dazu sagen können. Achten Sie darauf, welche Protokolle der andere Rechner anbietet (er sendet den String Pprotlist während des Handshakes). Vielleicht paßt ja keins (haben Sie irgendwelche Protokolle in sys oder port gewählt?).

Sendet das andere System RLCK, existiert eine alte Lock-Datei für Ihren Rechner auf dem anderen System. Wenn Sie nicht bereits über eine andere Leitung mit diesem System verbunden sind, muß die Datei von der Gegenseite entfernt werden.

Wird RBADSEQ gesendet, wurde mit Ihnen eine Rufsequenz-Prüfung durchgeführt, aber die Zahlen stimmten nicht überein. Erhalten Sie die Meldung RLOGIN, wurde Ihnen das Login unter dieser ID verweigert.

Log-Dateien

Wenn Sie das UUCP-Paket so kompilieren, daß das Taylor-eigene Logging verwendet wird, gibt es nur drei globale Log-Dateien, die alle im Spool-Verzeichnis untergebracht sind. Die Haupt-Logdatei heißt Log und enthält alle Informationen über aufgebaute Verbindungen und übertragene Dateien. Ein typischer Ausschnitt sieht wie folgt aus (die Formatierung wurde etwas geändert, damit er auf die Seite paßt):
uucico pablo -- (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3)
uucico pablo -- (1994-05-28 17:15:39.25 539) Login successful
uucico pablo -- (1994-05-28 17:15:39.90 539) Handshake successful
               (protocol 'g' packet size 1024 window 7)
uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj
uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai
uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at
uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as
uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2
uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1
uucico pablo -- (1994-05-28 17:15:59.05 539) Protocol 'g' packets: sent 15,
                resent 0, received 32
uucico pablo -- (1994-05-28 17:16:02.50 539) Call complete (26 seconds)
uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai
               (rmail okir)
uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as
               (rmail okir)
uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1
               (rmail okir)
Die nächste wichtige Log-Datei ist Stats, die die Datenübertragungs-Statistiken enthält. Der Ausschnitt aus Stats, der dem obigen Transfer entspricht, sieht wie folgt aus (auch hier wurden die Zeilen aufgeteilt, damit er auf die Seite paßt):
postmaster pablo (1994-05-28 17:15:44.78)
                  received 1714 bytes in 1.802 seconds (951 bytes/sec)
postmaster pablo (1994-05-28 17:15:46.66)
                  received 57 bytes in 0.634 seconds (89 bytes/sec)
postmaster pablo (1994-05-28 17:15:49.91)
                  received 1898 bytes in 1.599 seconds (1186 bytes/sec)
postmaster pablo (1994-05-28 17:15:51.67)
                  received 65 bytes in 0.555 seconds (117 bytes/sec)
postmaster pablo (1994-05-28 17:15:55.71)
                  received 3217 bytes in 2.254 seconds (1427 bytes/sec)
postmaster pablo (1994-05-28 17:15:57.31)
                  received 65 bytes in 0.590 seconds (110 bytes/sec)
Die dritte Datei ist Debug. An diesen Ort werden die gesamten Debugging-Informationen geschrieben. Wenn Sie das Debugging verwenden, sollten Sie sicherstellen, daß die Datei den Zugriffsmodus 600 verwendet. Abhängig vom gewählten Debug-Modus kann sie das Login und das Paßwort enthalten, die Sie verwenden, um sich in ein anderes System einzuloggen.

Die UUCP-Binaries mancher Linux-Distributionen sind so kompiliert worden, daß sie das HDB-eigene Logging verwenden. HDB-UUCP verwendet eine ganze Reihe von Log-Dateien, die alle unter /var/spool/uucp/.Log gespeichert sind. Dieses Verzeichnis enthält drei weitere Verzeichnisse namens uucico, uuxqt und uux. Sie enthalten die von den jeweiligen Programmen generierten Logging-Ausgaben, die für jede Site in einer separaten Datei abgespeichert werden. Die uucico-Ausgabe für pablo wird also in .Log/uucico/pablo gespeichert. Entsprechend schreibt uuxqt seine Ausgabe in .Log/uuxqt/pablo. Die Zeilen, die in die verschiedenen Log-Dateien geschrieben werden, sind aber dieselben wie beim Taylor-Logging.

Aktivieren Sie die Debugging-Ausgabe beim HDB-eigenen Logging, werden die Daten im .Admin-Verzeichnis unter /var/spool/uucp gespeichert. Bei ausgehenden Anrufen werden die Informationen in .Admin/audit.local festgehalten, während die Ausgabe von uucico bei eingehenden Anrufen in .Admin/audit gesichert wird.


Fußnoten

(1)
Geschrieben und Copyright von Ian Taylor, 1993.
(2)
Auch enthalten im System Manager's Manual von 4.4BSD.
(3)
Beachten Sie, daß, obwohl bei den meisten UUCP-Befehlen Setuid auf uucp gesetzt sein muß, dies beim uuchk-Programm nicht sein darf. Anderenfalls sind Benutzer in der Lage, die System-Paßwörter zu lesen, auch wenn die Dateien den Modus 600 verwenden.
(4)
Wenn Sie UUCP nur ausprobieren wollen, besorgen Sie sich die Nummer eines Archiv-Servers in Ihrer Nähe. Notieren Sie sich Login und Paßwort diese sind öffentlich bekannt, damit Downloads möglich sind. In den meisten Fällen lauten sie uucp/uucp oder nuucp/uucp.
(5)
Die einzige Einschränkung besteht darin, daß dieser Name nicht länger als 7 Zeichen lang sein sollte, um UUCP-Implementierungen nicht zu verwirren, die auf Betriebssystemen laufen, die nur eine beschränkte Zahl von Zeichen für Dateinamen erlauben. Namen, die länger als 7 Buchstaben sind, werden von UUCP häufig abgeschnitten. Einige Versionen beschränken die Länge sogar auf 6 Zeichen.
(6)
Das UUCP Mapping Project registriert alle UUCP-Hostnamen weltweit und stellt sicher, daß sie nicht doppelt benutzt werden. Um Ihren UUCP-Namen registrieren zu lassen, wenden Sie sich an die Administratoren der Site, die Ihre Mail verwalten. Die können Ihnen weiterhelfen.
(7)
Ältere Version-2-UUCPs übertragen ihren Namen nicht, wenn sie angerufen werden. Neuere Implementierungen, darunter auch Taylor-UUCP, tun dies aber.
(8)
Zum Beispiel ist es bei den meisten Nebenstellenanlagen notwendig, eine 0 oder eine 9 vorzuwählen, um ein Amt zu bekommen.
(9)
Die Baudrate des ttys muß zumindest genauso hoch sein wie die maximale Übertragungs-Geschwindigkeit.
(10)
Läuft auf dem anderen System Taylor-UUCP, hält es sich daran.
(11)
Einige Leute verwenden statt dessen die ttyS*-Geräte, die ursprünglich nur für das Einwählen gedacht sind.
(12)
Manche Modems scheinen das allerdings nicht zu mögen und hängen sich auf.
(13)
rsmtp wird verwendet, um Mail mit »batched SMTP« auszuliefern. Dies wird in den Kapiteln zu Mail behandelt.
(14)
Beachten Sie, daß tcpd üblicherweise den Modus 700 hat, d.h. Sie müssen es als root ausführen und nicht, wie Sie es normalerweise tun würden, als uucp.
(15)
Die Option u ist zwar auch in Version 1.04 vorhanden, besitzt aber keine Funktion.
(16)
Das sind alle Dateien, die mit einem Punkt beginnen. Solche Dateien werden vom ls-Befehl normalerweise nicht mit ausgegeben.

Inhaltsverzeichnis Kapitel 11 Kapitel 13