Next: Elektronische Post mit smail Up: Datenreisen und reisende Daten Previous: Seriell einloggen
Next: Elektronische Post mit smail
Up: Datenreisen und reisende Daten
Previous: Seriell einloggen
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.
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.
![[*]](./icons/foot_motif.gif){kind=icon}
$ 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.
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.
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.
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.
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.
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.
# /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).
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.
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
$ _
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.
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.
# /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.
# /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.
$ 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.
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
Das Linux Anwenderhandbuch