UUCP :: Individual Network Berlin e.V.

Grundsätzliches

Die Einrichtung von UUCP ist naturgemäß nicht einfach. Genaugenommen muss man sich intensiv mit der Anleitung befassen und auch einiges an Erfahrung sammeln. Die originale Anleitung ist als .info-Datei-System vorhanden, zum Lesen empfehlen sich neben X-Tools das Konsolen-Tool pinfo (wer die mit info selbst liest, ist Masochist).

Da vermutlich die wenigsten vorhaben, eine komplette Hierarchie mit UUCP zu vernetzen, wie das früher noch üblich war, genügen aber für die Nutzung von UUCP für den durchschnittlichen IN-Berlin-Teilnehmer wenige Grundeinstellungen.

Der Rechner, der beim IN-Berlin den UUCP-Dienst erledigt, heißt hirsch. Da UUCP die Rechnernamen beim Aushandeln der Verbindung übermittelt, muss man das wissen.

Grundsätzlich bieten wir über UUCP zwei Dienste an: Mail und News. Die früher noch verbreitete Dateiübertragung ist von ftp und www abgelöst worden und dient nur noch dem Übertragen der Mail- und News-Jobs.

Prinzip

UUCP arbeitet erst einmal offline, d. h. ohne Verbindung zur Gegenstelle. Arbeitsaufträge - Jobs - werden von uux angenommen und in einem Spoolverzeichnis aufbewahrt. Erst der uucico transportiert die Jobs zum Partnersystem, das sie zunächst erst einmal wieder aufbewahrt, bis sie vom uuxqt abgearbeitet werden.

UUCP kennt 4 Dateien:

C-File – ist ein Auftrag für den uucico. Es enthält einen Befehl, z. B. eine Datei zu übertragen.
D-File – ist eine zu übertragene Datei.
D.X-File – ist eine zu übertragene Datei, die auf der Gegenseite zum X-File wird. Wird heute kaum benutzt, weil das C-File beim aktuellen Taylor-UUCP bereits ein Kommando zum Anlegen eines X-Files enthalten kann.
X-File – ist ein Auftrag für den uuxqt und enthält das dazu verwendete D-File.

Das Verfahren läuft wie folgt ab:

uux wird aufgerufen, um ein Kommando auf der Gegenseite auszuführen, z. B. “rmail rechner!user”. uux nimmt dabei den Standardinput als Daten an (also als die E-Mail).
uux legt nun ein D-File mit den erhaltenen Daten (also der E-Mail selbst) an und ein C-File, welches den Kopierauftrag für das D-File sowie das Kommando für die Gegenstelle (also “rmail rechner!user”) enthält. Nur bei Nicht-Standard-Kommandos wird ein D.X-File angelegt, das dann auf der Gegenseite zum X-File wird.
uucico stellt die Verbindung her und sucht nach C-Files. Er entnimmt ihnen die Namen der D-Files und überträgt sie (ein D-File, dem das C-File verlorengegangen ist, bleibt ewig liegen!). Wenn im C-File noch ein Kommando steht, wird dieses ebenfalls zur Gegenstelle geschickt und dort als X-File gespeichert. Steht im C-File ein D.X-File, wird dieses als X-File auf der Gegenseite abgelegt. Ist ein C-File abgearbeitet, also auch das D-File komplett übertragen, wird es entfernt. Auf der Gegenseite liegt nun also ein X-File mit “rmail rechner!user” und ein D-File mit der E-Mail selbst. Ist uucico damit fertig, kann die Gegenseite ihre Dateien senden (bei bidirektionalen Protokollen auch gleichzeitig). Das wechselt so lange, bis alle C-Files abgearbeitet sind (falls zwischendurch noch welche dazukommen). Unvollständige Dateien werden beim nächsten Anruf fortgesetzt. Die Verbindung wird schließlich beendet.
Entweder automatisch vom uucico oder per Cron oder per Hand wird der uuxqt gestartet. Dieser sucht nach X-Files, und führt die darin enthaltenen Kommandos aus. Dazu verwendet er die D-Files. Nach dem Abarbeiten werden die Files gelöscht. Sollten Kommandos fehlschlagen, werden D- und X-File in ein Verzeichnis .Failed/site verschoben (das sollte man also ab und an checken) und der Absender sowie der lokale UUCP-User werden benachrichtigt (E-Mail). Im Beispiel findet uuxqt nun also ein X-File mit dem Namen des D-Files und “rmail rechner!user”. uuxqt wird das D-File als Standardinput dem rmail übergeben, und wenn rmail ohne Fehler abgelaufen ist, die E-Mail also angenommen wurde, beide Files löschen. Im Prinzip können so beliebige Kommandos remote ausgeführt werden - das wurde früher auch durchaus benutzt. Die erlaubten Kommandos stehen im sys-File, damit kein Missbrauch möglich ist. Heute stehen dort meistens nur noch rmail und rnews.

Damit man mit UUCP E-Mails und News transportieren kann, müssen die verwendeten E-Mail- und News-Programme natürlich mit UUCP zusammenarbeiten, d. h. sie müssen die Übertragung mit uux ausführen und E-Mails/News mit den vom uuxqt ausgeführten Kommandos annehmen.

Was geht?

Wie könnt ihr anrufen?

UUCP über SSH: Hier erfolgt die Interneteinwahl über einen beliebigen Internetprovider. Damit dabei das Passwort nicht im Klartext über die Leitung geht, bieten wir dafür an, UUCP durch eine SSH-Verbindung zu führen. Hierbei ist kein Eintrag in dial/port nötig.

Austausch von News

Um News per UUCP auszutauschen, muss euer News-Server dafür eingerichtet werden.

News werden gebatcht und komprimiert. Dabei kann die Site die Größe der Batches (min/max) angeben und die Art der Kompression bestimmen, mit der wir packen. Wir bieten an:

compress (Header: cunbatch)
gzip (Header: gunbatch)
bzip2 (Header: bunbatch)

Dazu kann die Batchgröße (min/max) angegeben werden. Default sind 200 kB/20 MB. Eine E-Mail an den Support genügt, um das anpassen zu lassen.

Die Sites können die Batches nach eigenem Gutdünken packen (compress, gzip oder bzip2), ohne uns Bescheid zu sagen (sofern der Header stimmt). Damit bzip2 funktioniert, muss die Site folgendes tun (gültig für inn):

In <Pfad-zu-news-bin>/rnews.libexec/ ein `bunbatch? anlegen (ausführbar für news) mit:

#!/bin/sh
exec /bin/bzip2 -d

Um bzip2 zu verschicken, das Skript send-uucp kopieren (z. B. nach send-bzip) und ändern (cunbatch -\> bunbatch und den Default Compressor auf bzip2` setzen:

\*)
# The default is set in innshelvars
COMPRESS="bzip2"
;;

Analog natürlich für gzip, falls das bei älteren Systemen noch nicht vorhanden ist.

Austausch von Mail

Um E-Mails per UUCP auszutauschen, muss euer Mailer dafür eingerichtet werden. Auch hier kann die Site wahlweise einliefern, hirsch sollte alles verstehen. Wir verschicken die E-Mails via rmail.

Solltet ihr vorhaben, hinter einer UUCP-Site weitere Sites mit E-Mail zu versorgen, muss eure Site diese per Domain-Adressierung erreichen können. Es erfolgt keine komplette Bang-Adressierung von weiter hinten liegenden Sites mehr, sondern euer System bekommt ein rmail !user@site.do.main, und muss selbst wissen, wohin diese E-Mail zu schicken ist.

Konfiguration von UUCP

Generell

Die Konfiguration ist distributionsabhängig. Es gibt zwar nur eine aktuelle UUCP-Version (Taylor-UUCP 1.07), jedoch verschiedene Wege, diese zu konfigurieren:

im config-File (meist /etc/uucp/config) können die Namen der anderen Files festgelegt werden. Die üblichen Namen sind sys, port, dial, call, passwd, es gibt aber Distributionen, die diese ändern (z. B. in Dial oder gar sonstwas).
Kommandos können auch für die anderen Files angegeben werden, im falschen File sozusagen. So bedeutet z. B. port type tcp im sys-File, dass ein Port “namenlos” mit dem Typ tcp verwendet wird, der eigentlich im port-File hätte stehen müssen (dort jedoch mit Namen). Das ist praktisch, weil man nur eine Datei wirklich bearbeiten muss.
Für die Logfiles gibt es drei Verfahren: BSD-like, HDB-like und Taylor-like, und das noch an verschiedenen Stellen. Dies wird beim Compilieren festgelegt.
dto. Ort und Art der Spool-Verzeichnisse (getrennt nach D., C. und X. oder zusammen).

Die nachfolgende Konfiguration ist also nur eine Möglichkeit und geht davon aus, dass das config-File keine anderen Namen festlegt. Der obere Teil des sys-Files sowie das Auslösen des uucico ist dabei für alle Poll-Arten gleich:

    # --- sys oberer Teil ---
    #
    # wo man z. B. rgsmtp, rnews usw. stehen hat
    command-path /usr/bin /usr/lib/news/bin /usr/lib/uucp
    commands uucp rmail rnews rsmtp rgsmtp rbsmtp
    #
    # für guten Durchsatz:
    protocol-parameter i packet-size 1024
    protocol-parameter g packet-size 1024
    # wichtig, weil man sonst von hirsch nur
    # 64-Byte-Pakete kriegt, was den Durchsatz stark drückt:
    protocol-parameter g remote-packet-size 1024
    #
    # damit nimmt er die Daten aus dem call-File, welches
    # dann uucp 600 sein sollte:
    call-login     \*
    call-password  \*
    #
    # Beginn der Site:
    system hirsch
    # falls der Rechner lokal anders heißt:
    myname <site>
    time any
    # --- Ende sys oberer Teil ---

Dazu muss hirsch ins call-File, und zwar so (mit U davor!):

    hirsch U<site> password

Starten kann man dann per Cron mit uucico -S hirsch, oder die vom Cron gestarteten Skripte benutzen, die z. B. Einträge in einer Datei “Poll” auswerten (je nach Distribution sehr verschieden).

Je nach Pollverfahren

Bei Verbindung über PPP

Es ist kein Eintrag in dial nötig.

Debian hat einen Port TCP im port-File vordefiniert, den man benutzen kann, aber nicht muss. Ob es den bei anderen auch gibt, ist uns nicht bekannt. Es geht auch alles im sys-File, das dann so aussieht:

    # sys unterer Teil ---
    # wer den port TCP aus dem port-File nicht benutzen will:
    port type tcp
    # wer den port TCP aus dem port-File benutzen will:
    port TCP
    # statt t geht auch g oder i oder andere,
    # g bietet den Vorteil, dass man nebenher noch
    # surfen kann, weil es die Leitung nicht so zudrückt,
    # i ist bidirektional
    protocol t
    # --- Ende sys unterer Teil ---

Verbindung per SSH

UUCP vorbereiten

Anlegen eines Eintrags SSH im port-File ist zwar möglich, aber unzweckmäßig, da die IP-Adresse darin auftaucht. Daher mache man es ohne port- oder dial-Eintrag ausschließlich im sys-File so:

    # --- sys unterer Teil ---
    port type pipe
    port reliable true
    port command <pfad\_zu\_ssh> -C -a -x -q -l uus \\
     -e none hirsch.in-berlin.de
    # bei mir geht nur y-Protokoll, das kann am asymmetrischen T-DSL
    # liegen, bei anderen geht auch i-Protokoll. Vorsicht, y-Protokoll
    # bei gcc 3.3 ist buggy, muss man selbst compilieren und den ASM-
    # Teil ausmachen.
    protocol y
    # --- Ende sys unterer Teil ---

SSH-Verbindung einrichten

Der uucico ist SUID uucp. Daher müssen alle SSH-Sachen als User uucp gemacht werden (su - uucp oder sudo -u uucp):

Erzeugen eines SSH-Keys (ssh-keygen), dem Key keine Passphrase geben!
Mailen des Inhalts von id_rsa.pub des Benutzers uucp an den Support.
Auf hirschs Seite kann man sich natürlich nicht als User uucp einloggen. Daher gibt es dort den User uus (UUCP SSH), der den uucico startet. Dem SSH muss also immer ein -l uus mitgegeben werden!
Nach dem Eintragen des Keys durch den Support dann entweder den SSH-Public-Key von hirsch manuell in die known_hosts-Datei hinzufügen oder - als User uucp - einmal mit ssh uus@hirsch.in-berlin.de eine SSH-Verbindung zu hirsch aufbauen. Dabei bestätige man mit “yes”, dass man den Key speichern möchte. Dann erscheint “login:”. Das ist der uucico der Gegenseite, das kann man direkt wieder beenden.

Der SSH-Public-Key des Benutzers uus ist:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIE A4lEyhZotlEhe8CM4L4ymiNAflhlwFkWr57Ycw+GNBmralR/UsckDmvNxBZYykmjh254MjPHkkvboGnCT4rsFEvB74A3nILhQdvH4rmVE0ZItPO+5nJXD3FEfgoDj+KQZqefcmew 0b14/MujOhPvy6YDr2D3dCLhYadJJN6TrMRs=
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKpMFw3X1cw9KnwqIWGbpcZbtjCJh2NUFxrshtQHKl/l7iKQ811VFUJC2avyMGIL+/FNcBydFA4VB6JDfkXWQWM=