Connecter sa machine Linux à l'Internet
Si vous avez un abonnement Internet de type dialup-RTC chez un
provider et désirez connecter votre PC Linux,
j'espère que ce qui suit pourra vous aider, un peu...
1 Introduction
Le but de cette page n'est pas de faire un cours ou une revue exhaustive
des moyens à mettre en oeuvre pour connecter une machine Linux
à l'Internet. De nombreuses possibilités sont offertes et
chacune d'entre elles convient à un besoin particulier.
Je ne prétends pas avoir la solution miracle, ce qui suit est le
résultat de mes difféents essais pour obtenir exactement ce
que je désirais en termes de connexion avec mon provider. Si cela
est insuffisant ou inadéquat il existe d'autres sites comme par
exemple, l'excellente page CONNEX du site
Linux-France ou
l'incontournable
Guide du Rootard.
En dernier ressort, il y a les FAQs, les NewsGroups, les HOWTOs et bien
sûr l'huile de coude...
Dans tout ce qui suit, il est supposé que vous avez une session
X11 sous root et que votre distribution est une RedHat (4.1 au moins).
Comme les manipulations qui suivent s'effectuent sous "root", je
vous recommande la plus grande prudence si vous n'êtes pas un
utilisateur expérimenté d'UNIX.
On y va ?
Dans le cadre d'une utilisation perso à la maison, tel est mon besoin:
- Gérer une liaison dial-up ppp via RTC avec adressage IP
dynamique; connexion à la demande et déconnexion
automatique au bout d'un certain temps d'inactivité. Ce
mécanisme doît être indépendant de tout
environnement utilisateur quel qu'il soit (que je sois sous X11 ou sur
une VT100 ca doit marcher sans l'aide de Kppp ou EzTruc !!!).
- Avoir une remise des mails locaux immédiate alors que les
mails sortants doivent être déposés dans une queue
pour envoi ultérieur. D'autre part, l'adresse e-mail de
l'émetteur du courrier sortant doit pouvoir être
transformée automatiquement afin de pouvoir utiliser un
forwarder comme dotcom.
- Récupérer automatiquement les messages reçus et hébergés par le
serveur POP3 de mon fournisseur d'accès.
2 Les softs nécessaires
- Linux, bien sûr... Personnellement j'utilise
une RedHat 4.1 (du moins ce qu'il en reste), les autres distributions
devraient faire l'affaire. Toutefois, ce qui suit est basé sur
l'utilisation de la RedHat. Pour les autres il faudra être
prêt à laisser de coté le cliquodrome et
éditer des fichiers du genre /etc/netconfig, /etc/machinrc, etc,
etc...
- Les sources du noyau et l'environnement de développement
installés sur le disque. Si ce n'est pas déjà
fait, utilisez Glint pour les installer.
- Le démon diald pour avoir une connexion
à la demande avec "monitoring" du trafic.
- Fetchmail, pour récupérer son courrier
électronique.
3 Configuration du noyau
Le système doit etre configuré pour supporter SLIP et PPP. Le
protocole PPP est employé entre le PC et le fournisseur
d'accès. SLIP est utilisé par diald pour détecter
quand il est nécessaire d'établir la liaison et quand il
devient inutile de la maintenir. Personnellement, j'use au maximum des
modules, sauf pour ce qui est vital ...
- Se connecter sous root puis aller dans le répertoire
où se trouve l'arborescence des sources du noyau (/usr/src/linux
en général). Puis taper make xconfig. Si tout
va bien, l'utilitaire graphique de personalisation du noyau affiche les
différentes rubriques disponibles. Voici ce que j'utilise:
|
Loadable module support
|
| Enable loadable module support | Y |
| Set version information on all symbols for modules |
N |
| Kernel daemon support | Y |
|
|
General setup
|
| Networking support | Y |
|
|
Networking options
|
| Network firewalls | N |
| Network aliasing | Y |
| TCP/IP networking | Y |
| IP: forwarding/gatewaying | N |
| IP: multicasting | N |
| IP: accouting | N |
| IP: optimize as router not host | N |
| IP: tunelling | N |
| IP: aliasing support | M |
| IP: PC/TCP compatibility mode | N |
| IP: reverse ARP | N |
| IP: disable Path MTU discovery | N |
| IP: drop source routed frames | Y |
| IP: Allow large windows | Y |
| The IPX protocol | M |
| Full internal IPX network | N |
| AppleTalk DDP | N |
| Amateur radio AX.25 Level 2 | N |
| Kernel/User network link driver | N |
|
|
Network device support
|
| Network device support | Y |
| Dummy net driver support | M |
| EQL support | N |
| PLIP support | N |
| PPP support | Y |
| SLIP support | M |
| CSLIP support | Y |
| KeepAlive and Linefill | N |
| Six bit SLIP encapsulation | N |
| Radio network interfaces | N |
| Ethernet driver support | N |
| Token Ring driver support | N |
| FDDI driver support | N |
| ARCnet driver support | N |
- Si il a été nécessaire de modifier la
configuration, il faut compiler et installer un nouveau noyau en tapant
la commande suivante:
make -s clean dep zlilo modules modules_install
Si tout s'est déroulé sans erreur, il est temps de
relancer la machine avec le nouveau noyau:
shutdown -r now puis attendre que ca redémarre.
4 Configuration pour PPP
4.1 Etablir les liens pour le fichier "/dev/modem"
Lancer le "control-panel" et choisir la rubrique
Modem configuration. Là il va falloir choisir quel
port série utiliser: cua0 pour COM1, cua1 pour COM2, etc... A vous
de choisir, dans mon cas c'est cua1 car j'utilise COM1 pour la souris.
Validez les modifications si il y a lieu de le faire, quittez la
fenêtre de configuration modem.
4.2 Configuration du réseau
Toujours depuis le "control-panel", choisir la rubrique
Network configuration. Renseignez les rubriques
proposées avec les valeurs suivantes:
4.2.1 Rubrique "Names"
| Hostname |
nom de votre machine (ex.: babasse) |
| Domain |
nom de domaine de votre FAI (ex.: Mon.FAI.dom) |
| Search for hostnames in additionnal domains |
A PRIORI, LAISSER VIDE POUR L'INSTANT |
| Nameservers |
adresses IP des serveurs DNS de votre FAI (une par ligne) |
4.2.2 Rubrique "Hosts"
Les adresses PPP sont là pour éviter des lookups DNS
(engendrant une connexion vers le fournisseur) au cas où
une commande du genre netstat -r serait tapée. Lors de
chaque établissement de la liaison, ces adresses seront
changées dynamiquement puisque j'utilise PPP avec affectation
d'adresses dynamiques.
| 127.0.0.1 |
localhost | # loopback |
| 0.0.0.0 |
paradise | # pseudo adresse de ma machine (affectation
dynamique) |
| 192.168.0.1 |
ppp-local | # mon adresse IP bidon (voir le
RFC 1918) |
| 192.168.0.2 |
ppp-remote | # l'adresse IP bidon du serveur d'accès
distant de mon FAI |
4.2.3 Rubrique "Interfaces"
Cliquer sour le bouton Add et choisir le type PPP. Validez
les paramètres saisis (N° d'appel modem, etc...) et gardez la
fenêtre principale des interfaces ouverte, elle va servir tout de
suite...
4.3 Tester la liaison
Ouvrir une fenêtre terminal (Xterm ou autre) et taper la commande
tail -f /var/log/messages afin de suivre la progression du test
et voir si il y a d'éventuels messages d'erreur.
Ouvrir une autre
fenêtre terminal et taper la commande netstat -r, on doit
voir apparaître les routes sur les interfaces lo et sl0, ok ?. Dans
la fenêtre de sélection des interfaces, choisissez
ppp0 puis cliquez sur le bouton Activate:
le modem doit numéroter et la liaison PPP doit s'établir.
Vous pouvez alors taper netstat -i pour
vérifier l'état des interfaces et pourquoi pas tenter un
ping sur une des machines de votre provider. Vous pouvez
couper la liaison en cliquant sur le bouton Desactivate de
la fenêtre de sélection des interfaces. Si le test n'a pas
fonctionné, aidez vous des éventuels messages d'erreur
contenus dans le fichier /var/log/messages et qui ont été
affichés dans la fenêtre où s'exécute le "tail".
Tapez ^C dans cette dernière pour arrêter le "tail".
5 Mesures élémentaires contre la CyberDélinquance...
Bien, arrivé à ce niveau il faut penser à
sécuriser quelque peu sa machine. On ne va pas en faire un bastion
pour firewall mais il faut quand même prendre quelques
précautions car même si une liaison PPP dynamique est un canal
relativement sécurisé; tandis que la défense
s'organise, les vraies attaques sont de plus en plus
sophistiquées et difficiles à détecter dans des
délais courts...
En matière de sécurité, il
vaut mieux adopter une attitude un peu paranoïaque plutôt
qu'être laxiste jusqu'au jour du cauchemard...
6 Configuration de DIALD
Diald est le démon qui va "écouter" ce qui se passe sur
l'interface réseau SLIP sl0 et décider si il est
nécessaire d'établir ou rompre la connexion modem. Pour ce
faire il procède de la manière suivante:
o utilisation de règles de filtrage pour agir
intelligement en fonction du trafic, du protocole, etc...
o manipulation des tables de routage
o surveillance de l'activité des interfaces
sl0 et ppp0.
- Installer diald.
Si diald n'est
pas inclus dans votre distribution, récupérez les sources
sur un des nombreux sites miroirs comme
ftp.lip6.fr par exemple. Si
il y a un package RPM prenez-le, sinon lisez la documentation fournie
avec les sources pour compiler et installer l'utilitaire. Vous pouvez
aussi aller directement sur le
site officiel de diald.
- Configuration de diald
- Le fichier /etc/diald.conf.
Ce fichier contient des infos comme type de protocole, le device
à utiliser, le débit jonction du modem, etc...,
nécessaires à diald pour fonctionner correctement.
Voici le contenu de mon fichier de config:
mode ppp
connect "/usr/sbin/chat -v -f /etc/sysconfig/network-scripts/chat-ppp0"
device /dev/modem
speed 115200
lock
crtscts
mru 1500
local 192.168.0.1
remote 192.168.0.2
redial-timeout 5
defaultroute
include /etc/diald.filter
fifo /etc/diald/diald.ctl
ip-up /usr/local/bin/diald_up
J'ai rajouté les lignes en gras:
- utilisation du chat-script généré par
les utilistaires RedHat (netcfg).
- utilisation de locks au style UUCP quand la ligne est
occupée (ca peut toujours servir dans le futur...).
- MRU (Maximum Receive Unit) à 1500 octets.
- Adresses IP locale et distante, inutiles dans notre cas mais
requises par diald pour fonctionner.
- 5 secondes de délai avant toute nouvelle tentative de
numérotation quand les choses vont mal.
- utilisation d'un FIFO pour pouvoir contrôler diald avec
l'utilitaire dctrl.
- lancement du script diald_up, à chaque connexion.
-
Création du FIFO pour pouvoir contrôler diald.
Ce fichier FIFO (ou pipe nommé) permet l'échange
d'informations et de commandes entre le démon et son
utilitaire de contrôle. Diald à la capacité de
le créer si il n'existe pas et dans ce cas il appartient
alors au propriétaire du démon, à savoir
root. Comme je veux pouvoir contrôler diald sans
être obligé de "passer" sous root, j'ai
créé le FIFO 'ad manu' avec les
commandesqui suivent.
# cd /etc
# mkdir diald
# mknod diald/diald.ctl p
# chmod 755 diald
# chmod 666 diald/diald.ctl
# ls -l diald*
-rw-r--r-- 1 root root 265 Nov 21 17:54 diald.conf
-rw-r--r-- 1 root root 5944 Nov 19 23:44 diald.filter
diald:
total 0
prw-rw-rw- 1 root root 0 Jan 7 21:33 diald.ctl
- Les règles de filtrage.
Les règles de filtrage qui sont fournies dans le fichier
/etc/diald.filter ne tiennent pas compte du fait que j'utilise le
serveur proxy de mon provider pour les protocoles HTTP et FTP. J'ai
donc ajouté dans ce fichier la ligne en gras qui suit:
[...]
# make sure http transfers hold the link for 2 minutes, even after they end.
# NOTE: Your /etc/services may not define the tcp service www, in which
# case you should comment out the following two lines or get a more
# up to date /etc/services file. See the FAQ for information on obtaining
# a new /etc/services file.
accept tcp 120 tcp.dest=tcp.www
accept tcp 120 tcp.source=tcp.www
accept tcp 120 tcp.source=tcp.proxy
[...]
Comme le service proxy n'existe pas dans la liste des noms
de services, j'ai aussi mis à jour le fichier /etc/services
en y ajoutant la ligne suivante:
proxy 8080/tcp proxy-port # proxy host port
- Lancement automatique de diald au boot.
On ne va pas lancer diald à la main à chaque fois qu'on
met en route sa bécane, il est plus pratique que cela soit fait
automatiquement. Pour ce faire, il faut créer un script de
démarrage dans le répertoire /etc/rc.d/init puis
créer les liens symboliques nécessaires pour qu'
init en tienne compte lors des changements de
run-level.
- Le script /etc/rc.d/init.d/diald
#!/bin/sh
#
# diald -- This shell script takes care of starting and stopping diald
#
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/sbin/diald ] || exit 0
# See how we were called.
case "$1" in
start)
# Start daemons.
echo -n "Starting diald: "
daemon /usr/sbin/diald
echo
touch /var/lock/subsys/diald
;;
stop)
# Stop daemons.
echo -n "Shutting down diald: "
#
# Killproc sends SIGKILL, I thing SIGTERM is better in the
# case of diald, but if TERM doesn't work ???
#
kill -TERM `pidofproc diald` # Killproc sends SIGKILL
echo
rm -f /var/lock/subsys/diald
;;
*)
echo "Usage: diald {start|stop}"
exit 1
esac
exit 0
- Les liens symboliques
J'ai créé 'S11diald', un lien symbolique dans rc3.d
et rc5.d qui pointe sur le script de démarrage de diald:
# cd /etc/rc.d/rc3.d
# ln -s ../init.d/diald S11diald
# ls -l S11diald
# rwxrwxrwx 1 root root 15 Nov 22 00:23 S11diald -> ../init.d/diald
# cd ../rc5.d
# ln -s ../init.d/diald S11diald
7 Sendmail
Pour envoyer votre courrier, il faut passer par le serveur SMTP de votre
fournisseur qui sert de relai entre votre machine et le reste du monde.
Sendmail est le MTA le plus répandu en ce qui concerne SMTP sous
Unix.
L'aspect hermétique de son fichier de configuration a sans doute
contribué à sa célébrité ;-))
Comme vu au début de cette page, je désirais avoir mon
courrier sortant géré au préalable par "mon" sendmail
avec connexion périodique vers le relai SMTP de mon FAI. Comme
j'utilise dotcom comme forwarder,
il fallait aussi convertir automatiquement les adresses e-mail de
l'émetteur avant que ca parte sur le Net: en "interne" mon adresse
est tout simplement mon nom de login mais quand "mon" sendmail traite un
message qui va à l'extérieur, mon adresse devient
automatiquement <pivert@mail.dotcom.fr>.
7.1 Le fichier m4
La syntaxe du fichier de configuration de sendmail a été
pensée dans un souci d'efficacité maximum durant son
interprétation par le programme, pour un humain c'est une autre
histoire... Heureusement, il y a m4 qui permet de
simplifier la tâche. J'ai créé un fichier babasse.mc
dans /usr/lib/sendmail-cf/cf dont le contenu est le suivant:
divert(-1)
#
# ma config sendmail 8.8.5/m4
#
# Liaison dial-up avec maquillage et translation d'adresse
#
divert(0)dnl
include(`../m4/cf.m4')
OSTYPE(`linux')
define(`confDEF_USER_ID',``8:12'')
dnl
dnl Par defaut, remise des mails sortants en mode differe
dnl pour eviter des connexions a chaque mail. (necessite de lancer
dnl sendmail avec l'option -q pour que la queue soit traitee).
dnl
define(`confCON_EXPENSIVE',`True')dnl
define(`SMTP_MAILER_FLAGS',`e')dnl
dnl
dnl Definition de la classe contenant les domaines pour lesquels
dnl l'utilisation de la table 'generics' est souhaitee.
dnl
GENERICS_DOMAIN(`Mon.FAI.dom')
dnl
dnl Definition du relai SMTP de mon FAI
dnl
define(`SMART_HOST', `esmtp:relai-smtp.Mon.FAI.dom')
dnl
dnl Il faut faire passer ma machine pour une machine du domaine
dnl de mon FAI le temps de passer les mails au relai.
dnl
MASQUERADE_AS(`Mon.FAI.dom')
FEATURE(`allmasquerade')
FEATURE(`masquerade_envelope')
dnl
dnl Utiliser la table 'generics' pour transformer les adresses e-mail
dnl a la volee:
dnl machin@babasse -> machin@Mon.FAI.dom -> dupont@forwarder.
dnl
FEATURE(`genericstable')
dnl
dnl Les mailers que j'utilise:
dnl - procmail pour le local
dnl - SMTP pour le reste
dnl
FEATURE(`local_procmail')
MAILER(`smtp')
Ensuite, j'ai généré un nouveau fichier de
configuration pour sendmail en tapant make babasse.cf puis
cp babasse.cf /etc/sendmail.cf.
7.2 Le fichier /etc/service.switch
Sendmail tente systématiquement d'obtenir le nom d'une machine (ou
son adresse IP) en ayant recours au DNS. Si cela n'est pas génant
pour le courrier sortant, en ce qui concerne le courrier local il n'est pas
souhaitable que sendmail génère des lookups DNS car cela a
pour conséquence fâcheuse de "monter" la ligne dialup. Pour
forcer sendmail à consulter d'abord le fichier /etc/hosts de la
machine, il faut créer le fichier /etc/service.switch dont le
contenu est le suivant:
hosts file
7.3 Le script sendmail.init
Le script de démarrage de sendmail fourni en standard lance le
démon de manière à ce que la queue soit traitée
à intervalles réguliers au moyen de l'option '-q'. Il est
préférable de ne pas laisser cette option puisque c'est
uniquement lors de l'établissement d'une liaison que la queue doit
être examinée par sendmail. Editez le fichier
/etc/rc.d/init.d/sendmail.init pour remplacer la ligne
sendmail -qXX -bd par sendmail -bd.
7.4 Relancer sendmail
Afin de prendre en compte la nouvelle configuration, il faut relancer
sendmail: allez dans le répertoire /etc/rc.d/init.d puis tapez les
deux commandes suivantes: ./sendmail.init stop puis
./sendmail.init start.
7.5 La table "generics"
Pour changer mon adresse dans les mails qui partent à
l'extérieur, sendmail utilise le contenu de la table generics. Pour
créer cette table il faut taper
makemap hash /etc/genericstable < /etc/generics.txt,
le fichier generics.txt contenant des paires du type "nom
<autre@quelque.part>".
Voici un extrait du mien:
cyril pivert@mail.dotcom.fr
7.6 Envoyer le courrier périodiquement
A chaque connexion réussie vers le fournisseur d'accès, diald
peut exécuter une commande spécifiée par le stanza
ip-up de son fichier de configuration. Pour moi, ce
fichier est un script et c'est par son intermédiare que sendmail
sera lancé de manière à ce que les mails en attente
soient envoyés au relai du fournisseur d'accès. Le contenu
du script est donné juste au dessous après ce qui concerne
fetchmail.
8 Fetchmail
En général, votre courrier qui arrive chez votre fournisseur d'accès est
géré par un serveur POP ou IMAP, chez moi c'est du POP3. Fetchmail permet
de le récupérer automatiquement et de le déposer dans vos boites aux
lettres en utilisant sendmail sur votre machine. Parmi
les 5 boites POP mises à ma disposition par mon provider je n'en n'utilise
qu'une mais je les traite toutes afin d'éviter de gaspiller inutilement de
l'espace disque sur les serveurs. Tous les mails qui arrivent dans les
trois autres boites POP sont donc directement "poubellisés".
8.1 Installer fetchmail
Si fetchmail n'est pas inclu dans votre distribution,
récupérez les sources sur un des nombreux sites miroirs comme
pour diald: ftp.lip6.fr par
exemple. Prenez le package RPM, si il n'existe pas lisez la documentation
qui est fournie pour l'installation. Comme pour diald, vous pouvez aussi
utiliser la page
officielle de fetchmail.
8.2 Configuration de fetchmail
J'ai créé le fichier /etc/fetchmail.conf de manière à récupérer le courrier
de 4 de mes 5 boîtes (une d'entre elles est utilisée par une autre
personne). Pour les trois que je n'utilise pas, les messages sont
délivrés à junk qui pour sendmail est un alias
sur /dev/null (la poubelle). Lorsque la connexion au serveur POP est
terminée, fetchmail lance sendmail avec
l'option -q pour traiter la queue. Le contenu du fichier est le suivant:
set syslog
set invisible
defaults proto pop3 norewrite flush
poll serveur_pop.mon.isp.com
user compte_pop1 with pass password1 is cyril here
user compte_pop3 with pass password3 is junk here
user compte_pop4 with pass password4 is junk here
user compte_pop5 with pass password5 is junk here
postconnect "/usr/lib/sendmail -q"
Une fois le fichier créé, il faut veiller à ce que le
mode de l'I-node soit 600 (c.à.d. -rw------), pensez donc à faire un
chmod sinon fetchmail refusera de faire quoi que ce
soit...
8.3 Le script diald_up
Le fichier diald_up (dans /usr/local/bin), est le script qui est
exécuté à chaque connexion réussie chez le
provider. C'est là que fetchmail est lancé (et donc
sendmail).
Comme diald peut lancer ce script autant de fois qu'il y a de connexions,
on peut potentiellement avoir de multiples (et inutiles) copies de ce
processus (et de ses descendants). Pour prévenir cette situation,
le script génère une sorte de fichier "lock" qui contient le
PID du processus. Enfin, comme j'aime avoir une trace de tout ce qui ce
passe dans les fichiers "log", j'ai utilisé l'utilitaire
logger:
#!/bin/sh
#
# Script lance a chaque etablissement de connexion avec FAI
#
[ -f /var/run/diald_up.pid ] && exit 1
trap "rm /var/run/diald_up.pid" EXIT HUP INT TERM
echo $$ > /var/run/diald_up.pid
logger -p mail.info -t diald_up[$$] 'STARTED'
/usr/bin/fetchmail -f /etc/fetchmail.conf
logger -p mail.info -t diald_up[$$] 'END RUN'
9 Configurer l'environnement graphique
Avoir diald bien configuré et opérationnel
c'est bien, le contrôler du bout du doigt avec la souris c'est encore
mieux ! Il suffit pour cela de configurer votre environnement graphique
préféré de manière à automatiser
l'exécution du programme dctrl. Quelques exemples:
- Fvwm: ajouter une ligne du type:
Exec "I" exec dctrl -geometry +1+1 -control-window -iconic
dans le corps de la fonction InitFunction.
- AfterStep:
*Wharf dctrl nil Swallow "dctrlIcon" dctrl -control-window
-iconic &.
- KDE: connait pas, à vous de voir... :))
10 Aller plus loin
Que faire de plus ? Il est possible d'élaborer une configuration encore
plus sophistiquée:
11 Conclusion
Le monde du logiciel libre est épatant. Si on prend la peine de
chercher un peu, il s'avère souvent que d'autres personnes ont eu le
même besoin que vous et ont rédigé un document ou
créé une solution logicielle au problème posé.
Il suffit d'aller faire son marché !. J'espère que
le monde Internet (libre) gardera cet état d'esprit car c'est
là une synergie formidable entre des milliers de développeurs
talentueux et les (millions ?) d'utilisateurs. C'est aussi la source d'une
riche collection de logiciels alternatifs en évolution constante que
certains éditeurs traditionnels ne font que suivre ou piller...
12 Devenir de ce document
Depuis son écriture au début de l'année 1998 bien
des choses ont évolué. Faute de temps, Eric Schenk a du
abandonner le développement de diald peu après
la sortie du patch 5 pour la version 0.16. Le noyau 2.2 est sorti et la
version 0.16 ne fonctionne pas très bien avec. Mike Jadgis a repris
le flambeau, la version courante est la 0.99, adaptée au noyau 2.2 mais
pas toujours bien supportée par le 2.0...
J'envisage de le réécrire en prenant pour base les versions
récentes des logiciels impliqués dans la chaîne de
liaison, et ce, en faisant abstraction de toute distribution. Cela
implique d'utiliser directement les sources de diald même si un paquetage
existe.
Pourquoi un tel choix ? Il s'avère que chaque distribution de
Linux a ses particularités. Ce document assume que l'environnement
est celui d'une RedHat. Tel quel, il ne peut servir que de base pour les
autres. En considérant les messages de la mailing list, il apparait
que les paquetages RPM de Diald n'ont pas toujours été
vraiment bien nets pendant une certaine période... Un moyen de
s'affranchir de ces différences et autres problèmes est de compiler
soi-même les applications et de les installer dans un
répertoire dédié comme /usr/local.
Quand sortira le nouveau document ?
Quand j'aurai eu le temps de passer ma machine en Glibc2 avec un noyau
2.2 à partir des sources, probablement pour septembre. Ma RH 4.1
n'en a plus que le nom et quelques vestiges RPM...
<MESSAGE STR="bouteille a la mer">
Malgré le fait d'en avoir toujours l'envie, je ne trouve pas le temps
nécessaire pour accomplir cette mise à jour tant souhaitable. La
dernière modification de ce document date de Novembre 99, et encore
c'était pour dire qu'il fallait être patient pour les updates
:-)
Récemment, deux "écueils" supplémentaires sont apparus:
* un nouveau membre de prévu dans la famille...
* j'ai zappé tout ce qui était du Linux au profit d'un BSD...
Il est donc maintenant clair pour moi que ce document n'évoluera plus et
c'est bien dommage.
Si par chance, il se trouvait quelqu'un qui désire reprendre le flambeau,
il suffit de me contacter par mail.
</MESSAGE>
Pour ceux qui n'ont pas le temps d'attendre:
- Le site de Mike Jadgis est la
page officielle de la version 0.99 .
- L' archive de la
mailing list linux-diald contient des infos intéressantes
sur la version 0.99. La liste étant passablement bruitée, prévoyez de
consacrer un peu de temps pour la recherche des "bons" messages...
- Ne pas oublier de compiler le noyau avec le support pour Ethertap et
Packet Socket (Networking Options).
- Souvenez-vous: RTFM est votre ami. ;-)
Mes remerciements à tous ceux qui par leur questions
posées dans feu fr.comp.os.linux et
fr.comp.mail m'ont permi d'avoir
des réponses avant même de demander quoi que ce soit !!!
Je tiens aussi à remercier les auteurs de diald
et fetchmail pour avoir créé et rendu
accessibles leurs programmes et tous ceux qui contribuent d'une
manière ou d'une autre, donc merci à moi-même ;-))
Enfin, un grand merci à Jean Charles: ses remarques
pertinentes m'ont aidé à mieux comprendre certains points
de la technique de configuration de sendmail avec
m4 et m'ont même donné l'envie de refaire
un p'tit tour dans le
BatBook !!!
A Nat Makarevitch, pour avoir spontanément
inséré un lien vers cette page depuis la page CONNEX du
site Linux France lors de l'annonce de l'existence de ce document.
Et Linus bien sûr...
Cyril Guibourg
Last modified: Sat Feb 10 21:59:56 CET 2001