Présentation du protocole UUCP
Cet article présente l'utilisation et la configuration du protocole UUCP (Unix to Unix CoPy) sur Linux.
UUCP permet, de manière très efficace, de transférer des fichiers, du courrier électronique ou bien des news.
Introduction et historique
Le protocole UUCP fut introduit dans les premières versions d'Unix développées par AT&T à la fin des années 1970. La première version
d'UUCP fut développée par Mike Lesk en 1976 et fut intégrée à la version V.7 de l'Unix AT&T diffusée en 1977 (sous le nom d'UUCP version 2).
Une nouvelle version fut distribuée avec Unix System V R3 en 1983. Le nom officiel de cette nouvelle version fut BNU pour Basic
Network Utilities. Elle fut cependant célèbre dans la communauté Unix sous le nom de Honey DanBer dérivé des noms
des 3 auteurs : Peter Honeyman, David A. Nowitz et Brian E. Redman.
Malgré son grand âge, UUCP surpasse largement dans certains cas bon nombre de systèmes de transfert de données plus récents.
Lorsque l'on ne dispose pas d'une connexion IP permanente, UUCP peut être un système à la fois performant et très économique
en particulier pour gérer le service de courrier électronique, même dans le cas d'un site relativement important (comme une petite
entreprise comprenant plusieurs dizaines d'utilisateurs).
UUCP fut conçu à une époque où les réseaux n'existaient pas (ou peu). Il s'est basé sur un principe de connexion temporaire (dial)
qui s'effectue la plupart du temps à l'aide d'un modem (appelé aussi dialer). Le temps d'utilisation de la ligne et donc le coût
de communication est très optimisé car les transferts UUCP sont rassemblés dans une zone de spool (file d'attente) qui permet
de stocker plusieurs transferts (transfert de fichier, de courrier, etc.) avant d'effectuer l'appel effectif. Le protocole UUCP
est également réversible, ce qui permet de transférer des données dans les 2 sens lors d'un même appel. Le système peut cependant
fonctionner sur d'autres supports comme une connexion série directe ou un réseau.
UUCP est largement configurable à travers des fichiers décrits plus loin, il est également automatisable au maximum, ce qui permet
de limiter l'administration du système une fois que celui-ci est correctement configuré. La configuration d'UUCP est cependant
un peu délicate pour un profane ... UUCP est disponible en standard sous Linux avec la version Taylor UUCP (du nom de l'auteur),
appelée aussi GNU UUCP. Cette distribution a la particularité de pouvoir émuler les versions AT&T antérieures mais elle apporte aussi
un format de fichier de configuration propre (TAYLOR_CONFIG). Le type de configuration est sélectionné par les options de compilation
de Taylor UUCP dans le fichier policy.h de la distribution. Les différentes versions Unix d'UUCP diffèrent par la structure
des fichiers de configuration, bien que le protocole utilisé reste compatible. Dans la suite de l'article, nous parlerons de configuration
BNU (compatible avec la distribution d'AT&T).
Configuration basique d'UUCP
Introduction
La configuration de UUCP est relativement complexe du fait du grand nombre de fichiers utilisés pour le paramétrage. Ces fichiers
sont rassemblés sur un répertoire qui pourra être /etc/uucp ou bien /var/lib/uucp. Les fichiers décrits sont ceux de la version BNU.
Le fichier Systems décrit les calculateurs accessibles via la protocole UUCP. Ces sites sont accédés à travers
des pseudo-devices associés à des devices physiques (/dev/cuax ou bien /dev/ttySx) dans le fichier Devices.
Le fichier Devices associe un device physique à un pseudo-device. Les pseudo-devices utilisent également
des canaux de communication (ligne, série, modem, etc.), ces derniers étants décrits dans le fichier Dialers.
Le fichier Dialers décrit le comportement des différents types de modems utilisables sur le système : procédure
d'initialisation, de libération de ligne, de composition, etc.
Le fichier Permissions permet de définir les droits d'accès des sites distants sur le site local et réciproquement.
Un exemple de configuration
Supposons que ma machine personnelle appelée mmxpf veuille dialoguer par UUCP avec une machine distante appelée bureau.
On doit tout d'abord déclarer la machine bureau dans le fichier Systems de la machine locale par une ligne :
bureau Any ACU 57600 numéro_bureau "" \d\r login-gin uupf ord: uupf0
bureau est le nom UUCP de la machine distance (pas forcément identique au nom retourné par uname -n)
Any indique que la machine peut être appelée à n'importe quelle heure de la journée. Un administrateur pointilleux
pourra définir des tranches horaires avantageuses dans le cas d'appels coûteux (par exemple, Any2201-0759).
ACU indique le pseudo-device utilisé pour l'appel. Il sera défini dans le fichier Devices.
57600 indique la vitesse de connexion.
La dernière partie (après le numéro de téléphone) est le chat-script permettant d'établir le login UUCP sur la machine
distante. On notera que le mot de passe est inscrit en clair dans le fichier, ce qui explique pourquoi le fichier Systems est protégé
en lecture.
Dans le fichier Devices, on ajoutera la ligne :
ACU modem - 57600 deskline56
qui indique que le pseudo-device ACU (Automatic Call Unit) est associé au device physique /dev/modem, qui est en général un lien
symbolique sur un device réel. La chaîne deskline56 spécifie la macro d'appel correspondant au modem utilisé (ici un Deskline 56K
COM One) et devra être définie dans le fichier Dialers.
Dans le fichier Dialers, on ajoutera la ligne :
deskline56 =,-, "" \dAT&FE0M1V1X1&K3%TCB\r\c OK\r ATDT\T\r\c CONNECT
qui représente la séquence Hayes utilisée pour initialiser le modem puis composer le numéro de téléphone. On peut d'ores et déjà
tester la connexion en utilisant la commande UUCP cu (Call Unix) livrée dans le package UUCP :
cu bureau
...
Connected
~[mmxpf].
Disconnected.
On quitte cu en tapant ~ puis . (il fallait l'inventer :-))
Le fichier Permissions permet de définir les droits d'accès des machines distantes utilisant le protocole UUCP.
Il permet également de modifier le nom UUCP sous lequel apparaîtra la machine locale appelante lors de l'appel au site distant.
Voici un exemple de fichier Permissions :
MACHINE=bureau LOGNAME=uupf MYNAME=pcpf \
READ=/var/spool/uucppublic:/tmp \
WRITE=/var/spool/uucppublic:/tmp \
SENDFILES=yes REQUEST=yes \
COMMANDS=/bin/rmail:/bin/rnews
Cette configuration indique que lors du dialogue avec la machine bureau en utilisant le login uupf, on sera identifié
comme pcpf (alors que le nom local est mmxpf). Les répertoires accessibles par la machine distante sont /var/spool/uucppublic
(le défaut) et /tmp, et ceci en lecture et écriture. La machine distante a le droit de télécharger des fichiers sur ces répertoires
ainsi que d'exécuter les commandes rmail et rnews.
Transfert de fichiers
Le transfert se fait en utilisant la commande uucp. Par exemple, le transfert du fichier binaire fichier1.tar.gz
depuis le site éloigné bureau vers /var/spool/uucppublic se fera ainsi :
uucp -r bureau!~/fichier1.tar.gz /var/spool/uucppublic
la chaîne ~/ symbolise le répertoire distant /var/spool/uucppublic normalement réservé aux transferts UUCP. L'option -r indique
de placer l'ordre de transfert dans la zone de spool et non d'effectuer un appel immédiat. On peut de même commander un transfert
dans l'autre sens par :
uucp -r fichier2.tar.gz bureau!/tmp
N.B. : Dans le cas de l'utilisation du shell bash sous Linux, il est nécessaire de placer un backslash devant le ! qui est un
caractère spécial.
On peut lire l'état de la file d'attente UUCP avec la commande uustat -s :
root@mmxpf # uustat -s bureau
bureauN007e bureau root 11-24 23:06 Sending /home/pierre/tar_gz/fichier2.tar.gz (35999 bytes) to /tmp
bureauN0081 bureau root 11-24 23:11 Requesting ~/fichier1.tar.gz to /var/spool/uucppublic
On peut annuler le transfert (supprimer la requête de la file) par la commande uustat -k à laquelle on donne l'identificateur
de la requête :
uustat -k bureauN0081
Courrier électronique
Une utilisation très efficace du protocole UUCP est la gestion de courrier électronique, par exemple :
pour dupliquer / rediriger temporairement le courrier d'un poste de travail classique (utilisant SMTP pour l'envoi de courrier
et POP3 pour la lecture) vers un poste personnel ne disposant que d'un modem et d'un budget limité;
pour gérer totalement le courrier électronique d'une petite structure professionnelle (PME, association, site isolé).
Configuration pour accès personnel
Configuration pour accès professionnel
Dans les deux cas, une configuration UUCP correctement installée sur un simple PC Linux permettra une utilisation très confortable
du courrier électronique et ce, de manière transparente pour l'utilisateur. De plus, les temps d'interrogation du serveur de messagerie
distant seront beaucoup plus faibles, comparés à des solutions SMTP/POP3.
Dans le cas numéro 1 (PC personnel), on devra tout d'abord indiquer au programme Sendmail local que le routage par défaut des courriers
se fait par une passerelle UUCP. Cette configuration se fait facilement par exemple en utilisant le programme
Linuxconf. Une fois cette configuration effectuée, on peut tester ce routage
en utilisant le mode test de Sendmail
(option -bt) :
root@mmxpf # /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 0,3 somebody@some.where
rewrite: ruleset 0 input: somebody @ some . where
rewrite: ruleset 98 input: somebody @ some . where
...
rewrite: ruleset 3 returnes: $# uucp-dom $@ bureau
$: somebody < @ some . where >
> ^D
ce qui indique bien qu'un courrier extérieur sera correctement routé par la passerelle UUCP bureau. Si on utilise un outil de courrier
pour envoyer un message à truc@com1.fr, la requête sera stockée dans la file UUCP, lisible par la commande uustat :
root@mmxpf # uustat -s bureau
bureauC0083 bureau pierre 11-25 00:20 Executing rmail truc@com1.fr (sending 764 bytes)
Du côté de la machine distante bureau, il suffira de créer un fichier de redirection .forward sur le home-directory de l'utilisateur
concerné, par exemple :
pierre,pcpf!pierre
Ce fichier indique que le courrier sera toujours délivré sur la machine bureau mais qu'une copie sera systématiquement envoyée
via UUCP à la machine pcpf correspondant à la machine personnelle de l'utilisateur. Pour améliorer encore les choses,
on peut ajouter au crontab de l'utilisateur sur la machine bureau une ligne validant automatiquement
la copie UUCP le vendredi soir à partir de 19h00 (début du week end) :
0 19 * * 5 cp $HOME/forward.weekend $HOME/.forward
et supprimant la redirection dans la nuit du dimanche au lundi :
0 2 * * 1 rm -f $HOME/.forward
Côté machine distante bureau, on doit s'assurer que la machine pcpf est déclarée dans le fichier Systems
par une ligne :
pcpf Never
qui indique que l'on n'appelle jamais ce système mais que c'est toujours lui qui appelle. Dans le cas d'un serveur de messagerie
professionnel, la config sera similaire à quelques points près :
le serveur de messagerie local sera relié aux postes clients via un réseau local de type TCP/IP. Ces postes utiliseront
les protocoles SMTP/POP3 pour la récupération du courrier sur le serveur de courrier UUCP. Le serveur SMTP et POP3 sera le serveur
de messagerie Linux supportant également le protocole UUCP. Notez que les postes clients ne sont pas forcément sous Linux ...
les noms de tous les utilisateurs susceptibles de recevoir du courrier devront être déclarés sur le serveur de messagerie.
Côté fournisseur d'accès, tous les courriers à destination du domaine associé à l'entreprise devront être routés par UUCP
sur le serveur de messagerie. Pour cela, il sera nécessaire de configurer Sendmail en ajoutant une règle comme :
R$*<@truc.fr> $#uucp-dom$@truc$:$1
dans le sendmail.cf. Il faut noter qu'un seul compte est nécessaire sur le serveur du fournisseur d'accès Internet (le compte accès UUCP)
pour gérer tout le courrier de l'entreprise.
Côté serveur, on devra bien sûr installer un accès modem entrant par exemple en utilisant mgetty. Pour cela, on pourra se reporter
à l'article Installer un serveur PPP de Linux Magazine numéro 2. L'entrée dans le fichier /etc/passwd
pourra être :
uutruc:IJSrjU4zXl2Ys:14:14:login UUCP truc:/var/spool/uucp:/var/lib/uucp/uucico
Appel du site distant
L'appel au site distant est effectué par la commande uucico. Cette commande effectue les actions suivantes :
Appel du site spécifié par l'option -S
Traitement des requêtes en émission
Traitement des requêtes en réception
Coupure de la connexion
La ligne suivante donne un exemple d'utilisation de la commande uucico :
/var/lib/uucp/uucico -r1 -x1 -S bureau
L'option -r1 indique que uucico est l'initiateur du protocole, l'option -x1 indique le niveau de trace. Dans le cas d'une config
BNU sur Taylor UUCP, les traces seront sauvées sur le fichier /var/log/uucp/.Admin/audit.local. On pourra donc tracer l'appel
en effectuant la commande :
tail -f /var/log/uucp/.Admin/audit.local
Une première solution simple est d'effectuer des appels réguliers au serveur distant en programmant des exécutions d'uucico
dans une crontab. Le petit script ci-dessous permet d'appeler le serveur tout en suivant l'évolution du protocole :
#!bin/sh
DEBUG=1
DEFAULTSITE=bureau
LOGFILE=/var/log/uucp/.Admin/audit.local
if [ «$1» = «» ]; then
SITE=$DEFAULTSITE
else
SITE=$1
fi
/var/lib/uucp/uucico -r1 -x$DEBUG -S $SITE & tail -f $LOGFILE
Ce qui permet d'obtenir une sortie du genre :
uucp bureau (11/14-11:53:33,145,0) Calling system bureau (port modem)
uucp bureau (11/14-11:54:04,145,0) Login successful
uucp bureau (11/14-11:54:04,145,0) Handshake successful (protocol `i' sending packet/window 1024/16 receiving 1024/16)
bin bureau (11/14-11:54:04,145,0) Receiving rmail pierre (2213 bytes)
bin bureau (11/14-11:54:05,145,0) Receiving rmail pierre (1993 bytes)
bin bureau (11/14-11:54:05,145,0) Receiving rmail pierre (1670 bytes)
bin bureau (11/14-11:54:06,145,0) Receiving rmail pierre (1670 bytes)
bin bureau (11/14-11:54:06,145,0) Receiving rmail pierre (3200 bytes)
bin bureau (11/14-11:54:06,145,0) Receiving rmail pierre (170668 bytes)
bin bureau (11/14-11:54:50,145,0) Receiving rmail pierre (2389 bytes)
bin bureau (11/14-11:54:50,145,0) Receiving rmail pierre (1789 bytes)
uucp bureau (11/14-11:54:51,145,0) Protocol `i' packets: sent 19, resent 0, received 205
uucp bureau (11/14-11:54:51,145,0) Call complete (48 seconds 185592 bytes 3866 bps)
Cette méthode est utilisable mais peut être améliorée en adoptant les principes suivants :
On teste le contenu de la file avec une fréquence donnée (par exemple une fois par heure). S'il y a des éléments à envoyer,
on appelle le site distant, ce qui aura aussi pour effet de rapatrier les éléments à destination de la machine locale.
On force l'appel au site distant avec une fréquence donnée (par exemple 3 fois par jour), ce qui permet de forcer le rapatriement
des éléments à destination de la machine locale.
On utilisera pour cela 3 fichiers :
Un fichier Poll contenant la liste des sites UUCP à appeler ainsi que les heures d'appel. Le fichier ressemble à ce qui suit :
site1 0 12 17
bureau 12 18
Un shell-script uudemon.poll qui lira régulièrement le fichier Poll afin de générer une entrée dans la file UUCP
si l'heure courante correspond à celle spécifiée dans le fichier Poll.
Un shell-script uudemon.hour destiné à exécuter les appels UUCP et contenant simplement les lignes :
/usr/lib/uucp/uusched &
/usr/lib/uucp/uuxqt &
Pour faire fonctionner l'ensemble, on pourra ajouter à la crontab de root les lignes :
1 * * * * /var/lib/uucp/uudemon.poll > /dev/null
35 * * * * /var/lib/uucp/uudemon.hour > /dev/null
Conclusion
UUCP est un système à la fois très puissant et économique. Il est malheureusement assez peu utilisé par la majorité des fournisseurs
d'accès classiques alors qu'il pourrait avantageusement remplacer certaines configs SMTP/POP3 "tordues".
Bibliographie
Managing UUCP and Usenet de Tim O'Reilly et Grace Todino chez O'Reilly & Associates
Mini How-to français sur Sendmail + UUCP
Sources et documentation du package Taylor / GNU UUCP sur http://www.gnu.org
ou ftp://ftp.gnu.org/gnu/uucp