<adresse_électronique CHEZ fournisseur POINT code_pays>
Copyright © 2010 Ben Okopnik
Copyright © 2011 François Serman
Copyright © Année de relecture Prénom Nom du relecteur
Article paru dans le n°179 de la Gazette Linux d'octobre 2010.
Cet article est publié selon les termes de la Open Publication License. La Linux Gazette n'est ni produite, ni sponsorisée, ni avalisée par notre hébergeur principal, SSC, Inc.
Table des matières
Il y a quelques mois, j'ai mis en place un anti-spam sur mon ordinateur portable,
décrit précédement dans l'édition #176.
Étant installé sur ma machine locale, il produit quand même un traffic conséquent de paquets
SMTP
.
Et comme je voulais minimiser la charge, j'ai copié mon .procmailrc
,
ainsi que ma liste blanche et ma liste noire dans mon dossier personnel sur ce serveur mail.
Conséquence, mon trafic de mail a été réduit d'environ mille couriels par jour, plus les aller-retours vers GMail
pour les emails « douteux » à environ 25 messages valides par jour.
C'est particulièrement agréable, parceque je suis souvent connecté à internet par une connexion bas débit ou
de faible qualitée, dépendante de l'environnement à ce moment là.
However, there's still a slight catch: the two list files mentioned above
get updated on a regular basis. That is, if I get an email from someone and
I decide that I'm going to correspond with that person regularly, I
white-list them by hitting Ctrl+W
in Mutt (this, of course, requires
setting up a keystroke alias in ~/.muttrc
.) Conversely, black-listing
someone just takes hitting Ctrl+B.
Both of these actions, obviously,
update their relevant list file — but they do so locally, and
that's not where my (primary) spam filter is anymore. What to do? Logging
into the mailserver on a regular basis and copying the files would be a
hassle and an additional task that I'd have to remember — and that's
precisely the kind of load that I don't want to add to my routine.
Fortunately, automating it is easy.
Il va sans dire que les transactions qui s'éffectuent sur le réseau doivent être sécurisées. Heuresement, l'outil standard pour cela, ssh, est parfaitement fait pour cette tâche — et il permet même de sécuriser les connexions sans utiliser de mot de passe. Tout ce que vous avez à faire est configurer deux machines pour réaliser une authentification par échange de clé publique, ce qui consiste essentiellement à copier votre clé publique de l'une sur l'autre. La procédure est la suivante:
Assurez vous d'avoir un dossier .ssh
dans votre dossier personnel sur
votre machine locale. Créez le le cas échéant.
Considérant que vous ne l'avez pas encore fait, générez une clé SSH de 1024-bit; chaque système depuis
lequel vous allez vouloir vous connecter devra en posséder une.
Si cette clé existe déjà (c'est à dire, vous avez déjà un fichier id_dsa.pub
ou
id_rsa.pub
dans votre dossier ~/.ssh
), vous pouvez
passer cette étape.
ssh-keygen -tdsa
Ajoutez votre clé publique locale à votre hôte distant, dans le
fichier ~/.ssh/authorized_keys
:
ssh utilisateur@hote_distant 'cat>>~/.ssh/authorized_keys'<~/.ssh/id_dsa.pub
Entrez le mot de passe quand il vous sera demandé, et réjouissez vous de savoir que c'est la dernière fois que vous aurez à le faire .
Vous devriez-être capable de simplement taper la commande ssh utilisateur@hote_distant et
d'être logué— sans mot de passe. En fait, vous pouvez faire cet échange encore plus simplement en
donnant à l'hôte distant un alias; ajoutez simplement une entrée dans le fichier local
~/.ssh/config
(créez le s'il n'existe pas) comme suit:
Host dst
Hostname smithfamilyserver.com
Protocol 2
User joe
Compression yes
Une fois cette étape réalisée, vous devriez être capable de vous connecter à l'hôte en tapant simplement ssh dst. Clair, net et précis.
À ce stade, je pourrais simplement copier les fichiers que je veux sur le serveur en utilisant la commande
scp (la partie copie sécurisée, de l'outil
SSH); Cependant, par soucis d'utilisation de bonnes pratiques, j'aime ne copier que les
fichiers qui ont été modifiés — c'est à dire ne mettre à jour l'hôte distant que si les fichiers locaux
n'existent pas ou sont différents des fichiers distants.
La commande rsync est faite pour cela, et je peux même lui demander d'utiliser le protcole
SSH
comme mécanisme de transport. Tout ceci en quelques étapes simples:
Définissez le transport rsync en ajoutant la ligne appropriée à votre fichier de configuration:
echo 'export RSYNC_RSH=/usr/bin/ssh -l utilisateur_distant' >> ~/.bash_profile
En fonction de votre distribution, et de comment vous utilisez votre système, il se peut que vous deviez
également ajouter ceci à votre fichier ~/.xprofile
; en fait, vous devriez
peut-être le faire dans tous les cas, pour être sûr, cela n'abimera rien.
Si vous utilisez un shell autre que Bash
, alors je présume que vous saurez comment
faire ces réglages et exportez ces variables dans votre shell.
Demandez au shell de recharger son fichier (par exemple source ~/.bash_profile), ou déconnectez et reconnectez-vous.
Maintenant que les protocoles SSH
et rsync
sont configurés, mettre à jour les fichiers distants se résume à utiliser la commande:
rsync ~/.mail-* sfs:
Les deux points disent à rsync (comme c'estl e cas pour la commande ssh) que vous copyez les fichiers vers un hôte distant. L'emplacement distant par défaut est votre répertoire personnel sur la machine distante; biensûr, vous pouvez changer ce dossier— en considérant que vous avez les droits. Pour cela, ajoutez ce dossier immédiatement après les deux-points.
Automatiser cette procédure est tout aussi facile: il suffit de créer une ligne dans votre fichier
'crontab
' qui lancera la commande précédente quand vous l'aurez
planifiée. Par exemple, si l'on veut que ces deux fichiers soient mis à jour une fois par heure, il faudra
mettre en place la tâche cron
en tapant la commande
'crontab -e' et éditer la crontab
de sorte
qu'elle ressemble à ceci:
# m h dom mon dow command
05 * * * * /usr/bin/rsync /home/utilisateur/.mail-{accept,deny}-list sfs:
Cette ligne de commande signifie « à la 5ème minute de chaque heure de chaque jour de chaque mois et ce tous les jours de cette semaine, execute cette commande. » Cette tâche sera maintenant executée pour vous, régulière comme une horloge — et ce sans que vous n'ayez plus rien à faire.
Bien sûr, vous n'avez pas fait tout ceci uniquement pour copier quelques fichiers;
c'est assez facile sans configuration particulière. Cependant, maintenant que vous avez
mis cela en place, vous pouvez vous en reservir de plusieurs façons —
SSH
et rsync sont tous deux de bons outils
à avoir dans sa boîte à outils. Pour moi, ils ont utiles plusieurs fois par jour —
et puisqu'ils sont correctement configurés, manipuler mes fichiers en réseau est transparent,
c'est à dire aussi facile qu'en local.
Voici quelques exemples:
ssh lg # Se connecter sur la machine de Linux Gazette rsync file.html www:okopnik.com/misc # Copier ou mettre à jour 'file.html' dans le dossier 'misc/' de mon site ssh 203k 'tail /var/log/messages' # Voir les 10 dernières entrées dans le journal du serveur d'un client rsync -a ~/devel rb:backup/`date +%%FT%%T`/ # Sauvegarder mon dossier 'devel' dans un format daté sur mon serveur distant
Profitez, et parlez-nous des usages interessants que vous avez de votre réseau nouvellement transparent!
L'adaptation française de ce document a été réalisée dans le cadre du Projet de traduction de la Gazette Linux.
Vous pourrez lire d'autres articles traduits et en apprendre plus sur ce projet en visitant notre site : http://www.traduc.org/Gazette_Linux.
Si vous souhaitez apporter votre contribution, n'hésitez pas à nous rejoindre, nous serons heureux de vous accueillir.