Pourquoi donc me direz-vous ? simplement parce-que dans l’éventualité où faire bouger le prestataire en face de vous (celui qui héberge le serveur SSH) coûterait trop d’énergie, on va supposer qu’on ne peut pas facilement faire avaler notre clef publique à l’hébergeur du serveur SSH.

Bref, la commande traditionnelle est :

sftp utilisateur@serveur
Connecting to serveur...
utilisateur@serveur's password:
sftp>

J’ai trouvé une méthode simple : utiliser le client SFTP de “PuTTY”.
Je pensais au départ utiliser celui de “lftp” et sauvegarder ma connexion (avec mot de passe) en bookmark, mais comme mon login dans l’histoire est un utilisateur de domaine windows (ouais, le serveur SSH en face est sous windows O_o), y’a un \ dans le login et même en le doublant, lftp semble mal le digérer, ben j’étais aussi bloqué.

Bref, en installant les outils de PuTTY :

aptitude install putty-tools

On peut alors taper :

psftp -pw mon_pass utilisateur@serveur
Using username "utilisateur".
Remote working directory is /
psftp>

Attention : le mot de passe est en clair dans la ligne de commande, donc dans les processus etc etc. Donc c’est pas idéal comme condition.
Enfin, je n’ai pas mis le paramètre -b pour mon batch, car ce n’est pas le propos là.

• configurer postfix pour gérer des utilisateurs virtuels
• monter une architecture complète “postfix / postgrey / amavisd-new / clamav / spamassassin”

Il manque cependant un morceau : la possibilité de faire appel à des “procmail” personnalisés pour ces utilisateurs virtuels.

Lorsqu’on n’est pas avec des utilisateurs virtuels, chaque utilisateur réel (ayant un compte utilisateur, donc) utilise généralement son ~/.procmailrc pour trier un peu ou - cas qui m’intéresse particulièrement – activer son répondeur d’absence, “vacation“ pour ne pas le nommer.
Dans le cas d’utilisateurs virtuels, c’est sensiblement différent. C’est ce que je décrirai dans cet article. Ce n’est au final pas compliqué, mais il faut comprendre le rôle de chaque composant et les limites de fonctionnement de chaque outil.
En effet, je n’ai pas trouvé de doc ultra-claire sur le sujet sur le web, surtout les bricoles de chacun. Avec un peu de recul, et, voyant ma propre solution, j’ai l’impression qu’il y a tellement de configurations possibles (maildrop et pas procmail, mes utilisateurs virtuels comme ci, pas comme ça, il utilise postfixadmin et pas moi etc) qu’il est impossible d’écrire un truc qui n’est pas spécifique.
Le plus dur est donc de comprendre ce qu’on fait pour transposer à sa conf. Je tâcherai donc, comme d’hab, d’expliquer ce que je fais plutôt que de copier-coller les fichiers de conf.

Allez, let’s go pour la mise en place sur la base d’une archi postfix & co comme décrite dans les docs mentionnées en début de cet article.

Ah, dernier point : à la base, et tel que je le décris, l’utilisateur ne pourra pas mettre lui même son répondeur en place. Dans mon cas, ce n’est pas important. En effet, j’utilise des utilisateurs virtuels car il s’agit d’un serveur frontal de mails (qui trie le spam, en gros), livre les messages dans des arborescences virtuelles en attendant d’être POPées depuis un backend de mails quelconque (un vilain Exchange ). Donc, le répondeur d’absence des utilisateurs “physiques” est géré par eux-mêmes dans Outlook “normalement”, et je n’applique ce principe de répondeur qu’exceptionnellement, à quelques boîtes mails IMAP génériques, qui n’ont pas vraiment de notion de “vacances”. Des boîtes partagées entre plusieurs personnes, si vous voulez, mais stockées sur le frontal et pas dans le backend, pour diverses raisons dont on se moque ici. Après vous pourrez toujours bricoler un truc pour que tout un chacun accède à son procmail ou son message d’asbence pour le mettre, l’enlever etc.

Le principe

On veut activer le répondeur de toto@domaine.fr en utilisant l’outil “vacation” qui gère très bien les réponses. “vacation” ne joue qu’avec des comptes utilisateurs existants. Premier problème.

Pour y arriver, on va créer des alias pour ce compte virtuel “toto@domaine.fr” afin que postfix “forward” (du nom de la table “forwardings” gérant les alias des utilisateurs virtuels) tout mail à destination de toto@domaine.fr vers 2 endroits :

• le réel toto@domaine.fr, histoire de délivrer le mail quand même, au final
• et en plus vers un certain toto@vacation.domaine.fr qui n’existe pas

Ce dernier nom “vacation.domaine.fr” n’a pas besoin d’exister au sens DNS et ne correspond pas non plus à un MX réel. On va juste créer un “transport” (du nom de la table MySQL qu’on a créée avec les docs précédentes) particulier afin de router les messages à destination du domaine “vacation.domaine.fr” vers un “pipe” particulier de postfix qu’on va créer pour l’occasion.
Ce “pipe” UNIX, composant qu’on ajoute à la chaîne postfix, gèrera en fait l’appel à procmail configuré d’une manière globale (un gros procmailrc générique, si vous voulez).
Ce procmail fera ensuite un tri sur le nom du destinaire et appellera “vacation” lorsqu’on le veut avec un message personnalisé.

C’est ce procmail global qu’il conviendrait de découper (avec des INCLUDE), ainsi que les fichiers de messages d’absence qui vont avec, si on voulait donner la main d’une manière pas super pratique (FTP ? samba ?) à des utilisateurs réels sur leur répondeur de compte virtuel…

Je me suis basé sur pas mal de docs bizarroïdes, et surtout sur les quelques explications trouvées ici. Le cheminement y est, mais c’est pas détaillé sur le principe et le type propose son propre script de répondeur ; script qui peut générer une belle boucle infinie entre répondeurs, à mon humble avis. Ce risque n’existe pas avec “vacation“, car il garde une liste des gens “déjà répondus”, sauf si vous forcez à répondre à chaque fois.

Mise en place

Paquets, utilisateur etc

Au besoin, suivant l’état de votre installation :

aptitude install procmail vacation

Ensuite, j’ai expliqué que “vacation” ne travaillait que sur un compte réel. Je lui dédie donc un compte :

useradd -m vacation -s /bin/nologin -c "Utilisateur vacation"

Création du pipe UNIX

On crée le processus qui sera en charge de router (de manière interne à postfix) les messages arrivant dans un pipe qu’on nomme “repondeur” vers procmail (lui même appelant le cas échéant le programme de répondeur “vacation“).
Dans /etc/postfix/master.cf, à la fin (peu importe), on définit ce pipe comme suit :

#ajout d'un appel à procmail pour gérer certains 'vacation' sur les boites IMAP
#attention, l'appel à ce pipe est géré dans la table des transports virtuels + des forwardings qui vont bien
repondeur   unix    -       n       n       -       10      pipe
  flags=Rq user=vacation argv=/usr/bin/procmail -Y -m /etc/postfix/procmail-global-repondeur.rc ${sender} ${recipient}

Les espaces avant “flags” sont importants, c’est ce qui explique à postfix qu’il s’agit d’option du pipe nommé “repondeur”.
Je décrirai le fichier /etc/postfix/procmail-global-repondeur.rc plus tard. C’est lui qui contiendra les appels aux “vacation” de tels et tels utilisateurs.
J’avoue ne pas être super sûr des flags utilisés, voyez man pipe au besoin.

transport virtuel

Si votre base MySQL est exactement celle que je décris dans mes précédentes documentations, insérez une ligne dans la table “transport” afin d’avoir :

mysql> select * from transport;
+---------------------+-----------+
| domain              | transport |
+---------------------+-----------+
| vacation.domaine.fr | repondeur |
+---------------------+-----------+
1 row in set (0.00 sec)

Pour bien relier cette table à votre configuration “virtuelle”, la table “transport” dont je parle est celle décrite comme ça dans postfix :

[extraits de fichiers]
main.cf:transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
mysql-virtual_transports.cf:query = SELECT transport FROM transport WHERE domain='%s'

Création des alias pour router vers le “pipe” “repondeur”

Pour chaque utilisateur virtuel qui devra avoir un répondeur actif (ou potentiellement actif), il faudra ajouter 2 alias le concernant dans la table des alias (“forwardings” dans mon cas, là encore, ça dépend de votre conf de “postfix virtuel”). Ajoutez donc les lignes pour avoir :

mysql> select * from forwardings where source like 'j%doma%';
+--------------------+-----------------------------+
| source             | destination                 |
+--------------------+-----------------------------+
| jacques@domaine.fr | jacques@domaine.fr          |
| jacques@domaine.fr | jacques@vacation.domaine.fr |
+--------------------+-----------------------------+
2 rows in set (0.00 sec)

J’ai eu un souci pour insérer ces 2 lignes, car il y a une contrainte de clef primaire sur “source”, ce qui semble logique, mais qui est en fait bloquant pour nous et inutile dans un cas normal d’alias d’utilisateurs virtuels (on pourrait faire une liste de diffusion en créant plusieurs lignes pour une même source car postfix gère très bien le fait d’avoir plusieurs destination pour une même source).
Bref, j’ai fait sauté la contrainte PK que j’avais mise dans mes docs précédents :

ALTER TABLE forwardings
DROP PRIMARY KEY;

Rassurez-vous, ça ne fait pas sauter les entrées déjà stockées dans la table si vous en avez.

procmailrc et vacation

On y est presque.
Reste à définir le procmail global appelant vacation :
Dans mon “pipe“, j’appelle ce fichier :

servr:/etc/postfix# cat /etc/postfix/procmail-global-repondeur.rc
SHELL=/bin/sh

:0c
* ^(To|Cc).*jacques@domaine.fr
| vacation -f /home/vacation/jacques@domaine.fr.db -m /home/vacation/jacques@domaine.fr.msg -a jacques@domaine.fr vacation

:0c
* ^(To|Cc).*autre_type@domaine.fr
| vacation -f /home/vacation/autre_type@domaine.fr.db -m /home/vacation/autre_type@domaine.fr.msg -a autre_type@domaine.fr vacation

:0
/dev/null

Alors, c’est presque le plus compliqué car ce fichier est plein de petites ruses. Il vous montre comment procéder lorsque vous aurez plusieurs boîtes concernées par un vacation.
Je rappelle que de cette manière, c’est un peu pénible à maintenir car c’est l’admin qui gère. Là il s’agit de boîte IMAP partagées et peu nombreuses, donc c’est gérable.

Le détail est donc :

• Je stocke tous mes messages de “vacances” dans ~vacation/
• -f : pour indiquer dans quelle “base de données” on stocke les gens à qui on a déjà répondu
• -m : pour indiquer le mail de réponse d’un utilisateur donné, je le détaille plus bas
• -a : hyper important : en effet, vacation ne travaille que sur un utilisateur réel. Donc obligé de spécifier un utilisateur réel en fin de commande vacation, c’est l’utilisateur “vacation” himself qui figure en dernier argument de la ligne de commande. Donc, pour que vacation travaille, j’explique aussi que cet utilisateur réel peut être connu sous l’alias (-a) jacques@domaine.fr (ou autre_type@domaine.fr dans la 2è règle). Sinon aucune règle ne s’appliquera jamais.
• “:0c” : OUI : il faut activer le “carbon copy”. J’ai constaté ça à force de tests. En effet, un message arrivant dans postfix a un ID, il est dédoublé avec le même ID, l’un part vers l’utilisateur réel pour livraison, l’autre vers le “pipe“, puis procmail, puis vacation. “vacation” arrête les règles (si on ne met pas le “c” de carbon copy) dès que ça “match”. Si un expéditeur envoi un unique mail à en même temps jacques@domaine.fr et autre_type@domaine.fr, la première règle va marcher, donc procmail arrêtera de bosser. Résultat : pas de répondeur pour “autre_type”. On ne sait pas qu’il est en vacances.
• Et enfin, le piège des “carbon copy” : si on ne fait pas une dernière règle virant vers /dev/null tout message au final, un message légitime auquel on aura répondu par “vacation” sortira de procmail et continuera sa route : il sera donc livré. Mais c’est un utilisateur complètement bidon, untel@vacation.domaine.fr, domaine inexistant => erreur de livraison => log dans /var/log/mail.info et surtout, mail d’erreur bien crade informant l’expéditeur…

fichier .msg de vacation

Voici à quoi doit ressembler un fichier de réponse minimaliste :

servr:/etc/postfix# cat ~vacation/jacques\@domaine.fr.msg
From: jacques@domaine.fr (Jacques)
Subject: Re: $SUBJECT
Precedence: Bulk

Votre mail a bien été reçu, blablablabla
-- Jacques

reload postfix et tests

A la fin, /etc/init.d/postfix reload et zou, testez des envois de mails, de réenvois de mails (pour n’avoir qu’une fois la réponse etc).
Le plus risqué dans cette manip’ sur un serveur en production, c’est que tout les adresses normales commencent à merdouiller. Le plus rapide pour annuler tout ça le temps de réfléchir, est de commenter les 2 lignes définissant le pipe et de rechargez postfix.

Autres remarques

Réinit d’un répondeur

A une époque, il me semblait qu’en modifiant le fichier .msg, vacation détectait le changement et donc ne tenait plus compte des expéditeurs “déjà répondus”. Après quelques tests, je n’en suis plus si sûr. Le plus simple pour relancer un répondeur “pour tous” : supprimez le fichier .db correspondant.

Permissions

Attention, j’ai interdit le login pour l’utilisateur vacation. Donc tout ce que vous créerez dans ~vacation/*msg sera sûrement au nom de “root”, par exemple. Pensez à changer les droits.
Si vous avez raté un truc, les logs sont très explicites dans /var/log/mail.info.
Je crois aussi me rappeler que si vacation ne voit pas le fichier .msg, il ne fera rien. A vérifier, mais c’est une méthode simple (et crade car ça va faire du log à coup sûr) pour activer/désactiver un répondeur

un log complet pour illustrer

Si tout se passe bien, vous avez ça :
Connexion du serveur expéditeur :

Jun 14 17:10:21 servr postfix/smtpd[20107]: connect from expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:21 servr postgrey[12166]: action=pass, reason=client AWL, client_name=expediteur.org, client_address=xx.yy.zz.tt, sender=exped@expediteur.org, recipient=jacques@domaine.fr
Jun 14 17:10:21 servr postfix/smtpd[20107]: C2B829C4081: client=expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:21 servr postfix/cleanup[20065]: C2B829C4081: message-id=<20100614151021.AF0F0EEC57C@mail.expediteur.org>
Jun 14 17:10:21 servr postfix/qmgr[19547]: C2B829C4081: from=, size=515, nrcpt=2 (queue active)
Jun 14 17:10:21 servr postfix/smtpd[20107]: disconnect from expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:23 servr postfix/smtpd[20208]: connect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/smtpd[20208]: 8A0E69C4085: client=localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/cleanup[20065]: 8A0E69C4085: message-id=<20100614151021.AF0F0EEC57C@mail.expediteur.org>
Jun 14 17:10:23 servr postfix/smtpd[20208]: disconnect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/qmgr[19547]: 8A0E69C4085: from=, size=1045, nrcpt=3 (queue active)

Pas de greylisting, car c’est un pote. Analyse par amavis OK, on dédouble le message vers jacques@domaine.fr et jacques@vacation.domaine.fr.
Chaque file suivra alors sa route :

Jun 14 17:10:23 servr amavis[18918]: (18918-18) Passed CLEAN, [xx.yy.zz.tt] [xx.yy.zz.tt]  -> ,, Message-ID: <20100614151021.AF0F0EEC57C@mail.expediteur.org>, mail_id: uuW4XqNAoH7S, Hits: 1.714, size: 515, queued_as: 8A0E69C4085, 1902 ms
Jun 14 17:10:23 servr postfix/smtp[20190]: C2B829C4081: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.03/0/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=18918-18, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A0E69C4085)
Jun 14 17:10:23 servr postfix/smtp[20190]: C2B829C4081: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.03/0/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=18918-18, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A0E69C4085)
Jun 14 17:10:23 servr postfix/qmgr[19547]: C2B829C4081: removed

La partie “utilisateur virtuel de postfix” traite le “mail normal” => “delivered to maildir”. Ca roule :

Jun 14 17:10:23 servr postfix/virtual[20212]: 8A0E69C4085: to=, relay=virtual, delay=0.3, delays=0.15/0.01/0/0.14, dsn=2.0.0, status=sent (delivered to maildir)

La partie “vacation” (pipe repondeur) route vers le “relay=repondeur”. Le job s’accomplit correctement “(delivered via repondeur service)”. Là on n’a pas d’autre erreur, sinon on pourrait voir vacation ou procmail pas content :

Jun 14 17:10:23 servr postfix/pickup[19550]: ECF179C408A: uid=5001 from=
Jun 14 17:10:23 servr postfix/pipe[20209]: 8A0E69C4085: to=, orig_to=, relay=repondeur, delay=0.41, delays=0.15/0/0/0.25, dsn=2.0.0, status=sent (delivered via repondeur service)
Jun 14 17:10:23 servr postfix/pipe[20209]: 8A0E69C4085: to=, relay=repondeur, delay=0.41, delays=0.15/0/0/0.25, dsn=2.0.0, status=sent (delivered via repondeur service)
Jun 14 17:10:23 servr postfix/cleanup[20065]: ECF179C408A: message-id=<20100614151023.ECF179C408A@domaine.fr>
Jun 14 17:10:23 servr postfix/qmgr[19547]: 8A0E69C4085: removed
Jun 14 17:10:24 servr postfix/qmgr[19547]: ECF179C408A: from=, size=343, nrcpt=1 (queue active)

Deux secondes plus tard, “vacation” a détecté qu’il fallait répondre à “exped@expediteur.org”, donc on envoit un mail :
(le champ From sera jacques@domaine.fr, seul Return-Path sera à vacation@domaine.fr)

Jun 14 17:10:26 servr postfix/smtpd[20208]: connect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:26 servr postfix/smtpd[20208]: 174A99C4081: client=localhost.localdomain[127.0.0.1]
Jun 14 17:10:26 servr postfix/cleanup[20065]: 174A99C4081: message-id=<20100614151023.ECF179C408A@domaine.fr>
Jun 14 17:10:26 servr postfix/qmgr[19547]: 174A99C4081: from=, size=770, nrcpt=1 (queue active)
Jun 14 17:10:26 servr amavis[20202]: (20202-01) Passed CLEAN,  -> , Message-ID: <20100614151023.ECF179C408A@domaine.fr>, mail_id: xw6dpgfdz+b5, Hits: -0.001, size: 343, queued_as: 174A99C4081, 2197 ms
Jun 14 17:10:26 servr postfix/smtp[20190]: ECF179C408A: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.3, delays=0.14/0/0/2.2, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20202-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 174A99C4081)
Jun 14 17:10:26 servr postfix/qmgr[19547]: ECF179C408A: removed
Jun 14 17:10:26 servr postfix/smtp[20219]: 174A99C4081: to=, relay=mail.expediteur.org[xx.yy.zz.tt]:25, delay=0.21, delays=0.14/0/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4337FEEC560)
Jun 14 17:10:26 servr postfix/qmgr[19547]: 174A99C4081: removed

Dézip, install etc

Pour monter le site, je passe en quelques mots.

• Vous dézippez le .tar.gz (pas de paquet Debian ; et puis c’est généralement en retard de versions pour ce genre d’outils). Par exemple dans /var/www
• Vous avez en amont un serveur MySQL et Apache en état. Et éventuellement créé un schéma de base dotproject, un admin DB dédié et tout le toutim. Exemple :

  create database dotproject;
  create user 'dpadmin'@'localhost' identified by 'mon_passwd_qui_tache';
  grant all on dotproject.* to 'dpadmin'@'localhost';

• Bien sûr, le paquet php5-ldap est installé et LDAP activé dans votre conf PHP :

  votre.serveur:/srv/www/dotproject# grep -r ldap /etc/php5/
  /etc/php5/conf.d/ldap.ini:extension=ldap.so
  /etc/php5/cli/conf.d/ldap.ini:extension=ldap.so
  /etc/php5/apache2/conf.d/ldap.ini:extension=ldap.so
  

• De même pour php5-mysql…
• Vous accédez à http://votre.serveur/dotproject/install/
• L’install se déroule paisiblement. Vérifiez que les modules qui vous intéressent sont bien détectés. Ajoutez les permissions sur /files et créez un fichier /includes/config.php vide, modifiable par www-data.
  Bref, du classique.
• Une fois installé, le mot de passe par défaut du compte admin est passwd. J’ai cherché quelques temps .

A la fin, supprimez le répertoire d’”install”.

Conf Active Directory

Dans le menu d’admin, vous configurerez la connexion à l’AD comme suit (dans Administration Système -> Configuration système) – si votre LDAP est en clair (port 389) :

Conf dotproject Active Directory

• Méthode d’authentif… : LDAP
• Avant d’oublier : BIEN COCHER LA CASE “LDAP autorise également les connexions standards”. Sinon, si vous ratez votre conf LDAP et déconnectez votre compte admin => Boum (probablement).
• Hôte LDAP : j’ai galéré longtemps en mettant le FQDN, comme préconisé un peu partout. C’est passé lorsque j’ai mis l’IP ! Arg !
• Base DN LDAP : le noeud racine des utilisateurs qui pourront se signer. Par exemple : ou=Users,cn=domaine,cn=fr
• Filtre Utilisateur LDAP. Pour un AD : (sAMAccountName=%USERNAME%). Ca veut dire : on comparera la variable %USERNAME% au champ LDAP sAMAccountName, qui est le login dans un AD.
• Recherche Utilisateur LDAP : le chemin complet pour atteindre l’utilisateur capable de faire la recherche dans l’AD. Exemple : CN=sonlogin,CN=Users,dc=domaine,dc=fr

Mais d’où toute cette syntaxe sort-elle ???? non non, pas DT… Je vous recommande “AD Explorer“. Ca permet de vous promener dans votre AD et de connaître le DN (Distinguished Name) de n’importe quel élément.
Le cas standard est que les utilisateurs sont dans Ou=Users,dc=votredomaine,dc=com. Mais bon, quelques fois, on ose le changement.

Traduction

Vous trouverez le paquet français sur le site officiel. Il faut dézipper dans /locales, ça crée un sous-répertoire “fr”. Reste à mettre le français par défaut aux utilisateurs dans un des menus d’admin.

Et voilà, c’était “j’ai pris aucune note d’installation ni de photo d’écran donc je torche un papier vite fait mais ça peut rendre service”.
A+

aptitude install isoqlog mailgraph

Il n’y a rien à dire sur le paramétrage de mailgraph. Dans le cas d’une installation standard de Debian, vous trouverez le rapport temps réel sur http://le.serveur/cgi-bin/mailgraph.cgi.

Si vous avez désactivé l’alias /cgi-bin/ de la conf standard Apache, débrouillez-vous pour accéder au script /usr/lib/cgi-bin/mailgraph.cgi.
Voici le genre de rapport que l’on obtient : http://www.stat.ee.ethz.ch/mailgraph.cgi.

Pour isoqlog, il ne vous demande que des choses faciles pendant l’installation : nom du domaine, type de logs (postfix, exim etc). Les rapports tournent en crontab journalière, résultats dans /var/www/isoqlog/. Par défaut, c’est donc http://le.serveur/isoqlog/ pour accéder.

Voilà, statistiquez bien.

D’abord, s’assurer que vous avez le paquet ntfs-3g (si besoin d’écriture sur le disque/partition NTFS) et le paquet smbfs (Samba FileSystem) pour les partages CIFS.

Vous pouvez tester facilement avec des commandes genre mount -t cifs ou mount -t ntfs-3g. Dans le cas du CIFS, il y a certaines options à passer, notamment l’utilisateur, le domaine etc. C’est presque plus simple dans /etc/fstab.

Bref, voici la chose illustrée par l’exemple :

srv:/etc# cat fstab
###
# blabla habituel
### puis :
//srvwin1/partage1      /mnt/srv1prt1      cifs    uid=root,credentials=/etc/cifs.credentials,domain=MONDOM 0 0
//srvwin1/partage2      /mnt/srv1prt2      cifs    uid=root,credentials=/etc/cifs.credentials,domain=MONDOM 0 0
//srvwin2/blabla1       /mnt/srv2prt1      cifs    uid=root,credentials=/etc/cifs.credentials,domain=MONDOM 0 0
/dev/sdb1               /mnt/usbsdb1       ntfs-3g defaults,locale=fr_FR.utf8 0 0

Dans cet exemple tout simple, on monte 3 partages CIFS, mappé sur l’utilisateur root de la machine linux, en se signant avec les informations contenues dans /etc/cifs.credentials (ci-dessous) sur le domaine NT “MONDOM”.
Et dans /mnt/usbsdb1, on monte un disque USB (ou SCSI ou SATA d’ailleurs), en NTFS lecture/écriture.

Ensuite, de simples “mount /mnt/celui_que_vous_voulez” pour monter.

Le contenu de /etc/cifs.credentials est de la forme :

username=mon_login_windows
password=mon_p4ss

Il peut évidemment être différent pour chaque montage. Pensez à le protéger (chmod 600 /etc/cifs.credentials)

Préparez le serveur

Le paquet qui va bien

Sur le serveur, installez le paquet “ntp”. Faisant office de serveur, il se met à jour (donc il fait office de client, si je ne dis pas connerie). Pas la peine donc d’installer “ntpdate” qui est un autre client possible.
Les options du serveur sont dans /etc/default/ntp.conf, j’en parle un peu plus bas. Lisez le man.
Les paramètres de /etc/ntp.conf sont :

serv:~# egrep -v "^#|^$" /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap

J’ai juste ajouté la plage 10.0.0.0 (c’est un exemple) pour autoriser mon LAN à joindre ce serveur.

Firewalling ?

Il faudra ouvrir en sortie le port “ntp” (123), en UDP, depuis le serveur vers les serveurs amonts. Si c’est la liste par défaut de /etc/ntp.conf, à savoir les “*.pool.ntp.org”, c’est une longue liste, amenée à évoluer dans le temps je suppose. A vous de voir comment faire. Le plus simple : ouvrir UDP/123 vers le web, point.
Pour que les clients joignent votre serveur, c’est pareil, il faudra ouvrir le LAN vers votre passerelle, port UDP/123.

Testez

Je recommande d’ajouter -l /var/log/ntp.log dans les options du fichier /etc/default/ntp, soit :

NTPD_OPTS='-g -l /var/log/ntp.log'

Puis de redémarrer le service via :

/etc/init.d/ntpd restart

Vous verrez dans /var/log/ntp.log si votre serveur se met à jour, de combien de temps etc. Pensez à enlever ce log ou sinon à mettre en place une rotation de logs qui va avec.
Ca ressemble à ça :

13 Nov 11:19:30 ntpd[18381]: synchronized to 91.121.121.160, stratum 2
13 Nov 11:19:30 ntpd[18381]: time reset -0.169417 s
13 Nov 11:19:30 ntpd[18381]: kernel time sync status change 0001
13 Nov 11:23:57 ntpd[18381]: synchronized to 91.121.121.160, stratum 2
13 Nov 11:31:29 ntpd[18381]: synchronized to 91.121.86.143, stratum 2
13 Nov 11:35:30 ntpd[18381]: time reset +0.189846 s
13 Nov 11:35:50 ntpd[18381]: synchronized to 91.121.121.160, stratum 2
13 Nov 11:40:06 ntpd[18381]: synchronized to 81.19.16.225, stratum 2
13 Nov 11:42:57 ntpd[18381]: synchronized to 91.121.121.160, stratum 2

On est maintenant prêt à dire à notre LAN d’aller taper sur ce serveur pour régler l’heure.

Les postes Windows

Le service W32Time (“Horloge Windows”) est en automatique par défaut depuis Windows XP. Il s’appuie sur le paramètre qu’on trouvera dans la clef de registre HKLM/SOFTWARE/Policies/Microsoft/W32Time/Parameters. La clef est “NtpServer”.
Il faut donc mettre à jour cette clef, d’une manière ou d’une autre.

…via des GPO

Si vous êtes en domaine Windows, le réglage est ici :

En gros, vous indiquez le nom de votre serveur.
Vous pouvez forcer la mise à jour des GPO sur un poste, pour tester, via gpupdate /force.

En pas GPO (domaine Samba-sans-GPO, Workgroup etc)

Il faut modifier la clef mentionnée plus haut, d’une manière ou d’une autre ; et probablement relancer le service “Horloge Windows”.

Sous Windows, comment tester

Le service Windows ne raconte rien et les “event logs” systèmes, c’est chiant.
Je suggère sur le serveur, un joli tcpdump qui vous montrera qui fait quoi :

serv:~# tcpdump -i eth0 dst port ntp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:14:49.071538 IP pc315.maboite.fr.ntp > imag.imag.fr.ntp: NTPv3, symmetric active, length 48
15:14:49.172627 IP imag.imag.fr.ntp > pc315.maboite.fr.ntp: NTPv3, symmetric active, length 48
15:15:29.305824 IP pc666.maboite.fr.ntp > serv.maboite.fr.ntp: NTPv3, symmetric active, length 48
15:15:29.306158 IP serv.maboite.fr.ntp > pc666.maboite.fr.ntp: NTPv3, symmetric active, length 48

Là, on voit un “pc315″ qui continue de demander à l’extérieur (le firewall l’autorise pour l’instant) et un pc666 qui a prit le pli.

Les postes Linux

Installez le paquet “ntpdate” et planifiez ntpdate-debian en crontab. Le manuel explique : ntpdate-debian utilise le fichier /etc/default/ntpdate pour la configuration (liste des serveurs de temps etc). Il contient, sans les commentaires :

NTPDATE_USE_NTP_CONF=yes
NTPSERVERS="0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org"
NTPOPTIONS=""

Mais, dans ce cas, à cause du “yes”, il utilise la conf de l’éventuel /etc/ntp.conf installé via le serveur NTP (paquet ntp). Comme on ne l’a pas mis sur les clients (ça sert à rien de faire tourner un serveur NTP), il faut donc soit passer NTPDATE_USE_NTP_CONF à “no”, soit ne pas planifier ntpdate-debian, mais ntpdate avec une tartine de paramètres.
Si vous mettez “no”, il faudra indiquer dans NTPSERVERS au moins / uniquement votre serveur du LAN. J’ai constaté qu’avec le nom de machine, ça ne passait pas. Mais avec l’IP, c’est OK. A creuser.

Pigé ? moi-même, je me perds régulièrement là-dedans.

Hop,
Dans une infra avec un proxy central et des sites distants reliés par des connexions assez lentes (et pas d’accès web direct), j’ai décidé de mettre en place des proxies “fils” sur les sites distants, pour soulager l’inter-site.
Manque de bol, à distance, uniquement des serveurs Windows sous la main…
Bon, squid existe sous Windows. Et “calamaris” n’est que du PERL. Ca doit pouvoir le faire.
Je fais cet article comme aide-mémoire, comme souvent, et surtout parce-que quand il faut automatiser des choses sous Windows, on voit vite que c’est vraiment la merde… Alors pour ne pas chercher 107 ans la prochaine fois, voici les quelques commandes à enchainer.

Et puis je n’avais pas envie/possibilité d’installer un superbe proxy-by-Microsoft, genre ISA ou je ne sais plus comment il s’appelle. Pas la peine non plus de chercher les ennuis quand on a un squid qui marche très bien

Je parle sur mon blog à différents moments de Squid, ou de proxy. Ca me fait penser que je n’ai rien écrit sur la mise en place d’un squid tout bête. On va considérer que c’est acquis. Sinon, avec le présent article et les autres, vous devriez avoir une certaine aide.

Installation et configuration des squid Windows

Je passe sur le aptitude install téléchargement à la main du gros zip contenant squid pour Windows, qu’on trouve à partir du site officiel (faut chercher un peu. Bon OK, c’est là). J’ai pris la même version que pour Debian Lenny, histoire d’interconnecter des squid de même génération… sait-on jamais. C’est donc la 2.7-STABLE7 (en fait ça doit être 2.7-STABLE5 en Debian, il me semble).
Ensuite, j’ai dézippé comme un cochon dans c:\squid\ et adapté la conf. Ce que je décris ci-dessous.

Configuration minimale

Il faut copier les fichiers c:\squid\etc\*conf.default en c:\squid\etc\*conf et adapter les contenus, notamment dans squid.conf :

• Adapter “acl localnet src” pour votre sous-réseau
• Déclarer le cache à utiliser : cache_dir ufs d:/squid/var/cache 4000 16 256
• Taille limite des objets mis en cache, à voir suivant votre cas : maximum_object_size 81920 KB
• Différents répertoires pour les fichiers de logs : cache_log d:/squid/var/logs/cache.log
• cache_store_log d:/squid/var/logs/store.log
• netdb_filename d:/squid/var/logs/netdb.state

J’ai voulu séparer les logs sur un disque à part. A noter les “/” (et non pas des “\”).

Service, initialisation du cache

Ensuite, il faut installer le service et créer le cache (j’ai laissé le format de cache par défaut, une arborescence de répertoires avec des fichiers aux noms codés) :

cd c:\squid\sbin
squid -k
squid -i
net start Squid

A noter que le nom du service n’est pas spécifié, ce sera donc par défaut “Squid”, c’est important pour la rotation de logs.
Le “net start Squid” ne devrait être fait qu’après configuration du lien avec le proxy “père” central, ce qu’on n’a pas encore fait. Mais bon, je le montre maintenant pour illustrer.

En images, ça donne :

Installation de Squid sous Windows

Déclaration du squid “père”

Dans la conf, il faut simplement caser un :

cache_peer proxycentral.maboite.fr parent 3128 3130 name=pxycentral
acl ftp proto FTP
always_direct allow ftp

J’explique : on déclare que ce proxy a un père (parent), sur le port 3128, machine “proxycentral.maboite.fr”. On attaquera l’interrogation du contenu de son cache via le protocole ICP (UDP/3130) et on le surnomme “pxycentral” dans les logs access.log histoire d’y voir clair.
Evidemment, le proxy central doit être ouvert sur le port TCP/3128 et UDP/3130 depuis les proxies “fils”.

Rotation de logs

Pour la rotation de logs, c’est en général un grand moment de bonheur pur sous Windows lorsqu’on amène un outil “du monde libre, tout ça” dans Windows. Heureusement ce coup-ci, Squid embarque ce qu’il faut :

c:
cd \squid\sbin
squid -k rotate -n Squid

Reste à mettre ça en “tâche planifiée” Windows.

Maintenant que ça tourne (testez), reste à synthétiser les logs, comme on le ferait naturellement sous Linux.

calamaris sous Windows, youpiiiii

Dans mon cas, ramener les logs sur un Linux qui aurait fait tourné calamaris était compliqué à mettre en oeuvre. Dans votre cas aussi, je suppose, car la rotation des logs fait que les fichiers sont renommés. Donc même avec un rsync (ou truc du genre), vous allez vous resynchroniser des Mo de logs (compressés éventuellement) à chaque fois.
Bref, j’ai opté pour un déploiement de PERL sur les serveurs distants et une “tâche planifiée” pour générer les pages statiques de statistiques des “fils” Squid.

Sous Windows, rien n’est fourni, je noterai donc ici la ligne de commande bien longue qu’on n’a pas besoin de chercher sous Linux, car les scripts “cron” sont fournis avec le paquet calamaris. Sous Debian en tout cas.

J’ai donc utilisé ActivePerl et récupéré calamaris en .tar.gz sur le site de l’éditeur. Manque de bol, j’ai retrouvé le même bug que décrit ici, donc j’ai fini par recopier le script perl /usr/bin/calamaris issu de ma Debian, patché pour corriger ledit bug.
Ensuite, plutôt que de ramer avec le fichier de conf, j’appelle calamaris en ligne de commande, via une “tâche planifiée”, et ça fait le boulot. C’est pas terrible mais bon, ça marche.
Pire que tout, pour générer les stats “weekly” et “monthly”, je recalcule tout en concaténant les différents “access.log.*” issus des rotations de logs, sur X jours.

En résumé, ça donne :

• Installation de ActivePERL
• Création dans C:\PERL\lib d’un répertoire calamaris avec les 3 fichiers .pm (modules PERL) pour la génération de graphiques dans les stats ; je n’ai pas trouvé comment lui spécifier d’utiliser ces modules, sans avoir à les copier dans PERL/lib. Je n’ai pas trop cherché non plus. Ca doit être avec “-I” ou quelque chose comme ça.
• Recopie du script “calamaris” issu de Debian, quelque part sur le Windows
• Mise en place de tâches planifiées appelant des “.bat” dans ce genre là :

  @echo off
  d:
  cd D:\calamaris-2.99.4.0
  type d:\squid\var\logs\access.log.0 | perl calamaris -a -F html,graph -H lookup --output-path d:\calamaris\output\daily

Notez que GD::Graph, nécessaire pour les graphiques, est installé par défaut avec ActivePERL.

Et voilà, mettez tout ça en oeuvre et ça devrait le faire.

Quelques remarques en vrac

Si tous les codes de retours de Squid ne vous parlent pas, lisez cette documentation là.

Comme je parle dans cet article d’un environnement mixte Windows & Linux, on peut parler de WSUS. Ces considérations pour Squid concernant les mises à jour Windows peuvent vous intéresser : http://wiki.squid-cache.org/SquidFaq/WindowsUpdate

Hop,
Après ma doc d’initiation Debian, où un rapide chapitre est consacré au montage d’un serveur postfix, spamassassin, greylisting etc, dans une configuration simple,
Après cet article sur le montage complet cette fois, en incluant amavisd-new, anti-virus etc,
=> Voici le complément idéal, par exemple en PME (et même plus gros) :

• Gestion d’utilisateurs virtuels, entendez par là “utilisateurs définis en base de données et non pas utilisateurs réels de l’OS”.
• Mise en place de tout ce qu’il faut pour lire les mails (POP3, POP3S, IMAP, IMAPS) via les outils “courier-*”
• Authentification via SASL
• Mise en place d’authentification sécurisée plus forte pour l’envoi (TLS).

Pour le webmail, j’en ai parlé déjà quelques fois sur mon blog et dernièrement, la version 0.3 de roundcubemail a fait de gros progrès par rapport à la 0.1. Ca s’installe en 3 clics. Si j’ai le temps je ferai un article, mais c’est mal barré.

Situation de départ

Avoir un serveur postfix correctement monté, avec (ou pas) amavis, spamassassin, un anti-virus, du greylisting, un nom correct etc. Bref, un serveur qui fonctionne et qui accepte les mails correspondant à des Maildir d’utilisateur de l’OS. En gros, ce qui est expliqué là .
Je ne parlerai pas d’ouverture de ports réseaux etc, mais ça tombe sous le sens. Ni du fait qu’il vous faudra une base MySQL en état de marche.

Je n’ai pas trouvé de doc officielle sur le sujet. En gros, on a postfix-mysql qui permet de faire le lien entre le serveur de mails et la base, mais rien dans un gros fichier README qu’on a habituellement avec ce genre de paquet. Ou alors je l’ai loupé.
Le “postfix mysql howto” est juste résumé à ça : http://www.postfix.org/MYSQL_README.html et ça : http://www.postfix.org/mysql_table.5.html. Et pour le coup, ce n’est pas très sexy.

J’ai donc compilé tout un tas de différents articles le sujet, parfois incomplet, parfois des articles décrivant des méthodes à grand coup de compilation-c-est-pénible-et-stupide-pour-suivre-les-mises-à -jour etc. Parfois sans gestion de quota, parfois avec. Et en général, en expliquant rien du tout. Donc dans mon cas, je tâche d’expliquer ce qu’on fait.

Alors, comme à mon habitude, je laisserai trainer 2/3 bugs que j’ai pu rencontrer (de ma faute), ça peut permettre d’aider si vous faites les mêmes erreurs. Et on y apprend l’existence de quelques outils pour tester en ligne de commande.

Remarque pour la partie quota qui ne fonctionne pas nativement dans postfix, je la passe sous silence volontairement au début et y consacre un chapitre à la fin. En effet, c’est relativement dissocié de tout le reste et ça implique de recompiler postfix (ou d’utiliser un .deb fourni par je ne sais qui, mais vous êtes dépendant de lui pour les mises à jour). Comme certains se moqueront des quotas, je le traite à la fin. Beaucoup de guides de mise en place mélangent tout et prévoient des fonctions qu’ils n’exploitent pas. J’essaye pour ma part de faire des briques dissociables.

J’ai aussi tout installé sur un unique serveur. Ce n’est pas une nécessité, sur une grosse installation par exemple.

Autres documentations

A ce propos, j’ai lu à peu près tout ce qui suit (et plein d’autres) pour monter le serveur, notamment les 2 premiers lien. J’ai même en gros simplement repompé, traduit et expliqué :

• http://library.linode.com/email-guides/postfix/postfix-courier-mysql-debian-5-lenny
• http://www.howtoforge.com/virtual-users-domains-postfix-courier-mysql-squirrelmail-debian-lenny
• Quelques survols de docs ici : http://www.postfix.org/docs.html
• Un psycho de la recompilation : http://www.phparchitecture.com/howto_show.php?id=2, mais y’a 2/3 trucs à prendre

Grandes étapes de la procédure

En gros, on va :

• 1) Installer les applicatifs,
• Créer la structure en base,
• Décrire cette structure à postfix pour qu’il sache l’interroger
• 2) Créer ce qu’il faut pour stocker les boites virtuelles
• Faire quelques tests de livraison de mails pour valider la partie “utilisateurs définis en base”
• 3) Paramétrer les outils pour récupérer les mails (courier-POP, IMAP et versions sécurisées par SSL)
• Tester ces protocoles pour la récupération des mails
• Voir l’analyse de quelques erreurs sur la partie “courier”
• 4) Paramétrer les mécanismes d’authentification pour l’envoi (SASL, TLS)
• Tester l’envoi, en TLS ou pas
• Voir l’analyse de quelques erreurs sur la partie authentification pour l’envoi
• 5) Optionnel : activer les quotas
• Et enfin, voir ce que je n’ai pas traité

Installation des paquets

Pour une fois, tout ne descend pas par dépendance, car les différents modules d’authentification (identification via une base MySQL) ne sont pas obligatoires, donc pas de dépendance. Donc pour une fois il faut absolument tout copier-coller. Pour illustrer, installer courier-authlib n’amène pas forcément courier-authlib-mysql.

On a donc :

aptitude install postfix-mysql courier-pop courier-pop-ssl courier-imap courier-imap-ssl postfix-tls  libsasl2-2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql openssl courier-authdaemon courier-authlib-mysql

Vous pouvez à la limite zapper certains, comme le POP, si vous ne comptez pas l’utiliser. Notez que les webmails tapent en IMAP, si vous ne le saviez pas.

Connexion postfix <-> MySQL

Création de la base de données

J’ai vu des définitions de base hyper complète, pour désactiver le POP (ou je ne sais quoi d’autre) par utilisateur. Sachez qu’il sera toujours temps d’ajouter une colonne à une table, de mettre des valeurs par défaut et d’ajouter une règle dans postfix pour prendre en compte une nouvelle fonctionnalité (c’est d’ailleurs ce qu’on fera pour les quotas de boîtes mails). Donc faisons simple au début.

On crée une base et un utilisateur dédié, avec des droits pas trop larges. Une fois connecté en root dans votre base (exemple : mysql -u root -p), on crée la base et donne des droits à cet utilisateur qu’on crée au passage :

mysql> create database postfix;
Query OK, 1 row affected (0.00 sec)

mysql> grant select,insert,update,delete on postfix.* TO 'mail_adm'@'localhost' identified by 'monpassadmin';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

ATTENTION : dans toute la suite, le nom de la base, le nom des tables, les identifiants etc sont à modifier pour refléter votre installation. Attention à ne pas copier-coller trop vite.

Ensuite, dans la base “postfix”, on crée quelques tables :

use postfix;

CREATE TABLE domains (
        domain varchar(50) NOT NULL,
        PRIMARY KEY (domain)
);
CREATE TABLE forwardings (
        source varchar(80) NOT NULL,
        destination TEXT NOT NULL,
        PRIMARY KEY (source)
);
CREATE TABLE users (
        email varchar(80) NOT NULL,
        password varchar(20) NOT NULL,
        PRIMARY KEY (email)
);
CREATE TABLE transport (
        domain varchar(128) NOT NULL default '',
        transport varchar(128) NOT NULL default '',
        UNIQUE KEY domain (domain)
);

Ces 4 tables permettront, dans l’ordre, de :

• définir la liste des domaines qu’on gère
• créer des alias (renvoyer toto@domaine.fr vers tata@blabla.com + titi@blibli.com)
• définir nos comptes et leurs propriétés
• définir une table de transport, au besoin

Création des requêtes pour savoir comment interroger ces tables

Le principe est le suivant : on a créé des tables avec des noms de colonnes et de tables libres (on aurait pu tout changer), on doit donc indiquer à postfix comment vérifier un mot de passe, voir s’il y a un forward etc. Pour chaque action, on a une directive dans /etc/postfix/main.cf et un fichier de conf décrivant la base et la requête.
Le truc énorme, c’est qu’on pourrait ajouter n’importe quelle colonne (attribut) pour ajouter un test. Exemple stupide : le password est OK entre 8h et 20h, sinon impossible de relever ses mails.
On ajouterait une colonne et une clause supplémentaire dans le WHERE, tenant compte de l’heure et d’horaires autorisés pour tel utilisateur.

Voici les 4 fichiers de conf pour les 4 tables précédement créées :
Fichier /etc/postfix/mysql-virtual_domains.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT domain AS virtual FROM domains WHERE domain='%s'
hosts = 127.0.0.1

Fichier /etc/postfix/mysql-virtual_forwardings.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT destination FROM forwardings WHERE source='%s'
hosts = 127.0.0.1

Fichier /etc/postfix/mysql-virtual_mailboxes.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/')
        FROM users WHERE email='%s'
hosts = 127.0.0.1

Fichier /etc/postfix/mysql-virtual_transports.cf :

user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT transport FROM transport WHERE domain='%s'
hosts = 127.0.0.1

Ensuite on sécurise ces fichiers qui contiennent des infos sensibles sur la base d’authentification de mails :

chown root:postfix /etc/postfix/mysql*cf
chmod 640 /etc/postfix/mysql*cf

Création de la structure de stockage des boîtes

Le principe est le suivant : on indique un répertoire racine, avec un utilisateur dédié sous lequel tout est stocké.
On aura une belle arborescence de ce type :

/ma/racine/des/maildirs/
        - /mon.domaine.fr/
                - user1
                        - cur
                        - new
                        - tmp
                        + .autre.sous.rep.de.maildir.genre.Sent
                + user2
        - /autre.domaine.a.moi.fr/
                + userX

Donc, disons que que le répertoire racine de stockage des boîtes mails sera /vmailboxes. On crée l’utilisateur avec un ID arbitraire :

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /vmailboxes -m

Attention, vous allez aussi recopier le contenu de /etc/skel dans /vmailboxes, le home de “vmail”. Ce n’est pas forcément utile. Adaptez au besoin.

On indique tout ça à postfix

Dans un premier temps, je n’ajoute pas toute la conf dans /etc/postfix/main.cf. On va y aller progressivement vu ce qu’on vient d’installer. On ajoute donc :

virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual,proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /vmailboxes
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_create_maildirsize = yes
virtual_maildir_extended = yes
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps \
             $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains \
             $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps \
             $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks

Les fichiers de conf MySQL en “mode proxy” (si on peut dire) permettent d’optimiser les accès en conservant en mémoire le contenu. Pratique pour éviter une tonne d’accès disque inutile.

N’oubliez pas de générer le fichier virtual.db, la “version base de données” associée au fichier “virtual”. Il vous sert à faire suivre par exemple certains comptes locaux vers d’autres adresses e-mails. Pour centraliser vos remontées de serveur autre part.

Rechargez postfix, ça devrait bien se passer. Allez voir dans /var/log/mail.info ou syslog sinon.
On va pouvoir tester.

Quelques tests de livraison de mails

Pour créer une boîte, il faudra au minimum :

• Avoir déclaré le domaine qu’on gère
• Avoir déclaré le compte
• Avoir envoyé un mail de bienvenue, localement, pour forcer la création de boîte (arborescence
• Eventuellement avoir ajouté des sous-répertoires pour que le webmail (si vous en mettez un) soit content : Sent, Trash, Drafts, Junk.
  

Ajout d’un domaine

Tout comme en postfix “normal”, on indique dans “mydestination” la liste des noms de domaines gérés, il faut ici les indiquer dans la base. Et les supprimer de “mydestination” si vous les gériez localement jusqu’alors. On crée simplement un enregistrement en base :

INSERT INTO domains (domain) VALUES ('mxtest.mondomaine.fr');

(Je suppose que mxtest.mondomaine.fr existe et que l’enregistrement MX existe aussi et pointe vers notre serveur.

Création d’un utilisateur

Simplissime, dans la base aussi :

INSERT INTO users (email, password) VALUES ('jacques@mxtest.mondomaine.fr', ENCRYPT('mon_pass_en_clair'));

Initialisation de sa boîte mail

Connecté localement, par exemple, sur la machine, envoyez un mail en ligne de commande, avec mailx, mutt. Ce que vous voulez.
Là , ô magie, vous devriez voir l’arborescence /vmailboxes se peupler, par exemple avec /vmailboxes/mxtest.mondomaine.fr/jacques/
C’est une arborescence “Maildir” classique, avec cur, new, tmp.
Si le mail est arrivé, on peut pour l’instant le lire en ligne de commande en allant dans le répertoire, tout bêtement.

Création des autres sous-répertoires

Dans cette procédure de création d’un compte, je suggère d’ajouter, pour le webmail, la création des répertoires habituels d’un compte en IMAP. Si vous ne comptez livrer que des boîtes récupérables en POP, ne vous cassez pas la tête, c’est inutile.
Sinon :

su - vmail
cd /vmailboxes/mxtest.mondomaine.fr/jacques
for i in Sent Trash Drafts Junk
do
        maildirmake .$i #le . est important
done

Vous devriez voir les sous-répertoires .Sent, .Junk etc avec à chaque fois le cur/tmp/new et des permissions restreintes à l’utilisateur vmail.

Voilà , la boîte sait recevoir et postfix sait gérer nos comptes virtuels, pour livrer le courier dans les boîtes virtuelles.

Abonnement aux répertoires IMAP ; pour le webmail ou la consultation IMAP

Si besoin, pensez à inclure la création du fichier suivant dans votre procédure de création de boîte mail :

mxtest:/vmailboxes/mxtest.mondomaine.fr/jacques# cat courierimapsubscribed
INBOX
INBOX.Sent
INBOX.Drafts
INBOX.Trash
INBOX.Junk

Annexe : création d’un alias

Dans la table forwardings, à base de :

INSERT INTO forwardings VALUES ('mon_alias@bla.fr', 'dest1@toto.fr', 'dest2@tata.fr');

Actif immédiatement. Pas plus compliqué que ça .

Partie lecture des mails, via “courier-*” utilisant MySQL pour l’authentification

Ici, on voit créer les services POP, IMAP et leurs versions sécurisées. Le tout sur fond d’authentification des utilisateurs définis en base MySQL.

Indiquer au “daemon” courier d’utiliser MySQL

Simplement, dans /etc/courier/authdaemonrc, changer la liste des modules utilisés pour l’authentification :

#authmodulelist="authpam"
authmodulelist="authmysql"

Dans /etc/courier/authmysqlrc, il faut positionner les variables suivantes :
MYSQL_SERVER localhost
MYSQL_USERNAME mail_adm
MYSQL_PASSWORD monpassadmin
MYSQL_PORT 0
MYSQL_DATABASE postfix
MYSQL_USER_TABLE users
MYSQL_CRYPT_PWFIELD password
MYSQL_UID_FIELD 5000
MYSQL_GID_FIELD 5000
MYSQL_LOGIN_FIELD email
MYSQL_HOME_FIELD “/vmailboxes”
MYSQL_MAILDIR_FIELD CONCAT(SUBSTRING_INDEX(email,'@',-1),’/',SUBSTRING_INDEX(email,'@',1),’/')
#MYSQL_NAME_FIELD name # NE PAS LAISSER CETTE VARIABLE, voir plus bas, cas d’erreur pour moi

Ici, bien évidemment, les valeurs indiquées reflètent les noms choisis en base.

Générer les certificats pour le POP3S et IMAPS

Cette partie est optionnelle, si vous ne voulez pas du POP3S et IMAPS. Dans ce cas vous pouvez aussi désinstaller courier-*-ssl.

On modifie les fichiers de conf de génération des certificats des daemon POP et IMAP sécurisés :

mxtest:/etc/courier# cat pop3d.cnf

RANDFILE = /usr/lib/courier/pop3d.rand

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no

[ req_dn ]
C=FR
ST=France
L=PARIS
O=Courier Mail Server
OU=Automatically-generated POP3 SSL key
CN=mondomaine.fr
emailAddress=certif@mondomaine.fr

[ cert_type ]
nsCertType = server

Et pour, l’IMAP :

mxtest:/etc/courier# cat imapd.cnf

RANDFILE = /usr/lib/courier/imapd.rand

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type
prompt = no

[ req_dn ]
C=FR
ST=France
L=PARIS
O=Courier Mail Server
OU=Automatically-generated IMAP SSL key
CN=mondomaine.fr
emailAddress=certif@mondomaine.fr

[ cert_type ]
nsCertType = server

Et on génère les certificats à partir de ces modèles. Ca ne fait que connaître à l’avance certains paramètres :

mxtest:/etc/courier# mkimapdcert
cp: not writing through dangling symlink `/usr/lib/courier/imapd.pem'
chmod: cannot operate on dangling symlink `/usr/lib/courier/imapd.pem'
chown: ne peut effectuer une déférence sur `/usr/lib/courier/imapd.pem': Aucun fichier ou répertoire de ce type
Generating a 1024 bit RSA private key
................++++++
....++++++
writing new private key to '/usr/lib/courier/imapd.pem'
-----
1024 semi-random bytes loaded
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
..............+.....................................................................................+..+.....................
.........+.............................+....+...+........+...................................................................
.............+..........+...........+..+...+..............................+....................+......................+......
........................+.....+.+......+..........................................................+..........................
.........................................................+...........+.........+.......................+.....................
..+..........++*++*++*++*++*++*
subject= /C=FR/ST=France/L=PARIS/O=Courier Mail Server/OU=Automatically-generated IMAP SSL 

key/CN=mondomaine.fr/emailAddress=certif@mondomaine.fr
notBefore=Oct  7 15:17:54 2009 GMT
notAfter=Oct  7 15:17:54 2010 GMT
SHA1 Fingerprint=9D:62:E6:CF:B7:39:80:C8:4E:F9:09:9C:61:36:14:8F:0B:EF:3C:6E

Et :

mxtest:/etc/courier# mkpop3dcert
cp: not writing through dangling symlink `/usr/lib/courier/pop3d.pem'
chmod: cannot operate on dangling symlink `/usr/lib/courier/pop3d.pem'
chown: ne peut effectuer une déférence sur `/usr/lib/courier/pop3d.pem': Aucun fichier ou répertoire de ce type
Generating a 1024 bit RSA private key
..++++++
..................++++++
writing new private key to '/usr/lib/courier/pop3d.pem'
-----
1024 semi-random bytes loaded
Generating DH parameters, 512 bit long safe prime, generator 2
This is going to take a long time
...............+..........................++*++*++*++*++*++*
subject= /C=FR/ST=France/L=PARIS/O=Courier Mail Server/OU=Automatically-generated POP3 SSL 

key/CN=mondomaine.fr/emailAddress=certif@mondomaine.fr
notBefore=Oct  7 15:18:10 2009 GMT
notAfter=Oct  7 15:18:10 2010 GMT
SHA1 Fingerprint=DD:8D:7C:0D:87:9D:19:9D:62:BE:5B:9A:B2:D8:43:80:CF:47:E2:14

Redémarrer tout ce bazar

Ayé, tout est prêt, les certificats sont générés, on redémarre tout ce monde :

/etc/init.d/courier-authdaemon restart
/etc/init.d/courier-imap restart
/etc/init.d/courier-imap-ssl restart
/etc/init.d/courier-pop restart
/etc/init.d/courier-pop-ssl restart

Tests pour l’envoi, quelques erreurs analysées

Déjà , faites un telnet sur chaque port, 143, 993, 110, 995 pour voir si ça répond bien.
Ensuite, testez chaque protocole. Par exemple avec Thunderbird. Sur un poste Windows, pensez à la version “portable” qui n’interfèrera pas avec votre actuel Thunderbird. Sous Linux, vous pouvez jouer avec vos ~/.mozilla-thunderbird (j’ai plus le nom précis en tête) pour ne pas abîmer votre conf actuelle.

Erreurs rencontrées

Ces erreurs m’ont permis de découvrir la commande authtest pour faire des tests d’aut

Oubli de package

J’ai commencé par tester l’authentification IMAP en local (depuis un webmail, roundcube, installé sur la même machine). Ca ne passait pas. J’ai testé depuis Thunderbird, pareil (pas étonnant), mais cette fois ça a généré un message dans les logs, genre syslog ou mail.info je ne sais plus :

Oct  8 16:10:32 ns305192 authdaemond: libauthmysql.so: cannot open shared object file: No such file or directory

Oops, il manquait le package courier-authlib-mysql.
Heureusement, ce ne sera pas votre cas, c’est bien écrit dans le aptitude install du début.

Erreur sur MYSQL_NAME_FIELD

Ensuite, j’ai eu le droit à une vraie erreur :

Oct  8 16:53:56 serveur imapd: authentication error: Input/output error

C’est l’occasion de mentionner la commande authtest (faites man authtest. Ca peut aider :

authtest ducon@lajoie.fr monpasswd
Authentication FAILED: Input/output error

Activez le debug dans /etc/courier/authdaemonrc avec DEBUG_LOGIN=1, redémarrez le service et allez voir les logs. Ca m’a permis de voir les erreurs SQL :

Oct  8 18:39:21 ns305192 authdaemond: mysql_query failed, reconnecting: Unknown column 'name' in 'field list'

En cherchant un peu, j’ai vu qu’il restait le champ MYSQL_NAME_FIELD dans /etc/courier/authdaemonrc. Une fois modifié, ça passe :

mxtest:/etc/courier# !auth
authtest bla@bla.fr monpassword
Authentication succeeded.

     Authenticated: bla@bla.fr (uid 5000, gid 5000)
    Home Directory: /vmailboxes
           Maildir: mondomaine.fr/jacques/
             Quota: (none)
Encrypted Password: OXXXXgfT0lXjI
Cleartext Password: monpassword
           Options: (none)

A ce moment là, tout marche pour la récupération, webmail aussi (puisque IMAP aussi).

Partie authentification des utilisateurs, pour l’envoi

Pour bien comprendre, on va activer 2 modes : SASL et TLS – encore que le mode TLS reste optionnel. Vous pourriez dans ce cas désinstaller les paquets concernés.
Le premier (SASL) pour avoir un mécanisme d’authentification pour le SMTP “normal”, port 25.
Le deuxième (TLS) pour avoir un mécanisme plus sécurisé, avec certificat etc, en TLS (anciennement SMTPS, ou SMTP avec SSL). C’est aussi sur le port 25 (pas 465), et, de ce que j’en ai compris, ça tend à remplacer le SMTPS, sur port 465. C’est expliqué là et j’ai peut-être un peu abrégé l’explication violemment.

Paramétrage de toute la chaîne postfix/sasl/pam/mysql

Pour ne pas se perdre, il faut comprendre que postfix va déléguer l’authentification à une couche d’abstraction, SASL. On va dire à SASL de se baser sur le mécanisme PAM (Pluggable Authentication Module) et on va dire à PAM de contrôler les logins/passwords dans une base MySQL, en lui décrivant cette base. Pigé ?

Dire à SASL d’utiliser PAM pour l’authentification

SASL est chrooté (je ne me souviens plus bien, mais c’est le boxon, j’ai dû en parler dans des posts précédents)
On crée son environnement de “chroot” :

mkdir --parents /var/spool/postfix/var/run/saslauthd

Ensuite, on paramètre le daemon SASL correctement :
Positionner START=yes dans /etc/default/saslauthd
et modifier la fin du fichier comme suite :

#OPTIONS="-c -m /var/run/saslauthd"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

Le reste du fichier par défaut doit être bon (DESC=”SASL Authentication Daemon”, NAME=”saslauthd”, MECHANISMS=”pam”, MECH_OPTIONS=”", THREADS=5).

Vous pourrez voir au passage qu’on indique (via le paramètre MECHANISMS) à SASL d’utiliser PAM.
Maintenant, on va dire à PAM d’utiliser MySQL.

Demander à PAM d’utiliser MySQL en décrivant notre structure

Dans /etc/pam.d/smtp (à créer je crois), on indique qu’on va utiliser le module MySQL pour PAM :

mxtest:/etc/pam.d# cat smtp
auth    required   pam_mysql.so user=mail_adm passwd=monpassadmin host=127.0.0.1 db=postfix table=users usercolumn=email passwdcolumn=password crypt=1
account sufficient pam_mysql.so user=mail_adm passwd=monpassadmin host=127.0.0.1 db=postfix table=users usercolumn=email passwdcolumn=password crypt=1

Ensuite, dire à postfix de faire confiance à SASL pour l’authentification

Maintenant que SASL sait faire le boulot en base de données, on configure postfix pour authentifier les utilisateurs via SASL/PAM/MYSQL.
Dans /etc/postfix/sasl/, s’assurer du contenu de smtpd.conf :

pwcheck_method: saslauthd
mech_list: plain login
allow_plaintext: true
auxprop_plugin: mysql
sql_hostnames: 127.0.0.1
sql_user: mail_adm
sql_passwd: monpassadmin
sql_database: postfix
sql_select: select password from users where email = '%u'

Ajoutez l’utilisateur postfix au groupe sasl :

adduser postfix sasl

Enfin, expliquer à postfix de bien vouloir relayer les envois d’utilisateurs authentifiés via SASL. Ce qui donne par exemple dans /etc/postfix/main.cf :

smtpd_sender_restrictions = permit_sasl_authenticated
        reject_unauth_pipelining
        permit_mynetworks
        reject_unauth_destination
        reject_unknown_sender_domain
        reject_non_fqdn_sender
        check_policy_service inet:127.0.0.1:60000

C’est surtout le “permit_sasl_authenticated” qui nous intéresse là.
Voilà, postfix sait maintenant contrôler les expéditeurs avec l’aide de SASL. Ils doivent se signer et exister dans la base.
Maintenant on met en place le TLS, si vous voulez utiliser du vrai cryptage SSL pour l’authentification.

TLS : certificat et configuration

Dans /etc/postfix/,on crée les clefs de cryptage :

mxtest:/etc/postfix# openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048 -nodes -keyout smtpd.key -keyform PEM -days 3650 -x509
Generating a 2048 bit RSA private key
................................................+++
................................................+++
writing new private key to 'smtpd.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:PARIS
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MASOCIETE
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:mondomaine.fr
Email Address []:certif@mondomaine.fr

IMPORTANT : le “Common Name” doit correspondonre à votre /etc/mailname
Protégez la clef privée : chmod 640 smtpd.key
J’ai mis 10 ans, on aurait pu mettre plus ou moins, c’est le paramètre 3650 dans la ligne de commande.

On ajoute pour finir la conf suivante pour activer le TLS et indiquer le certificat à utiliser. Dans /etc/postfix/main.cf toujours :

smtpd_tls_cert_file=/etc/postfix/smtpd.cert
smtpd_tls_key_file=/etc/postfix/smtpd.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes # à  voir, ça peut interdire certains outlook buggés, je crois, de tête.
smtpd_sasl_authenticated_header = yes

C’est fini, on relance tout ça

Redémarrez postfix et saslauthd via les /etc/init.d/saslauthd restart et /etc/init.d/postfix restart qui vont bien.

Tests pour l’envoi, quelques erreurs analysées

Après un rapide telnet sur le port 25 (quand même), testez avec un “ehlo mailhost” puor voir si le TLS est activé :

250-STARTTLS

Ensuite, comme pour la réception des mails, testez avec un client mail correct, en mode SMTP normal et avec TLS.

Erreurs rencontrées

Fausse manip dans /etc/pam.d/smtp

Tous les tests SMTP, avec et sans TLS étaient KO. Dans les logs, simplement ça :

Oct 14 13:52:39 ns305192 postfix/smtpd[6759]: connect from bla.fr[81.Y.67.X]
Oct 14 13:52:41 ns305192 postfix/smtpd[6759]: warning: SASL authentication failure: Password verification failed
Oct 14 13:52:41 ns305192 postfix/smtpd[6759]: warning: bla.fr[81.Y.67.X]: SASL PLAIN authentication failed: authentication failure
Oct 14 13:52:41 ns305192 postfix/smtpd[6759]: warning: bla.fr[81.Y.67.X]: SASL LOGIN authentication failed: authentication failure
Oct 14 13:52:43 ns305192 postfix/smtpd[6759]: disconnect from bla.fr[81.Y.67.X]

Je me souviens avoir utilisé saslfinger pour tester et debugger. Essayez-le.
Au final, je m’étais simplement trompé dans le mot de passe MySQL du fichier /etc/pam.d/smtp

Quotas

Sujet totalement optionnel. J’ai besoin dans mon cas de pouvoir affecter des quotas par utilisateur.
Postfix ne gère pas les quotas nativement, il faut appliquer un patch. Donc recompiler. Ou trouver une source, mais au niveau mise à jour de sécurité, vous dépendez alors du type qui maintient le dépôt.
J’ai préféré appliquer moi-même le patch.
Le patch est donné par ce projet : http://vda.sourceforge.net. Il est disponible pour toutes les versions postfix, notamment la 2.5.5, actuellement celle de Debian/Lenny. 32 ou 64 bits.

Ajout du dépôt de sources

D’abord, dans mon cas, j’ajoute un dépôt de sources, via la ligne suivante dans /etc/apt/sources.list :

deb-src ftp://ftp2.fr.debian.org/debian/ lenny main

Après un aptitude update, on va télécharger les sources et tout le bazar pour compiler.

Récupération des sources

serv:/etc/postfix# apt-get build-dep postfix
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les NOUVEAUX paquets suivants seront installés :
  build-essential comerr-dev debhelper dpkg-dev g++ g++-4.3 gettext hardening-wrapper html2text intltool-debian libcdb-dev libcdb1 libdb-dev libdb4.6-dev libfile-remove-perl
  libkadm55 libkrb5-dev libldap2-dev libmail-box-perl libmail-sendmail-perl libmime-types-perl libmysqlclient15-dev libobject-realize-later-perl libpcre3-dev libpcrecpp0
  libpq-dev libsasl2-dev libssl-dev libstdc++6-4.3-dev libuser-identity-perl lsb-release po-debconf tinycdb zlib1g-dev
0 mis à jour, 34 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 22,7Mo dans les archives.
Après cette opération, 69,1Mo d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ?

Ensuite, on récupère les sources de postfix :

serv:/etc/postfix# cd /usr/src
serv:/usr/src# apt-get source postfix

Ca download et décompresse (et gueule car je n’ai pas mis la clef GPG blablabla pour vérifier la signature du paquet, tout ça).

Récupération du patch, compilation

On récupère le patch qui va bien pour notre version postfix et on génère les .deb

cd /usr/src
wget http://vda.sourceforge.net/VDA/postfix-2.5.5-vda-ng.patch.gz
gunzip postfix-2.5.5-vda-ng.patch.gz
cd postfix-2.5.5
patch -p1 < ../postfix-2.5.5-vda-ng.patch
dpkg-buildpackage

Remplacement du postfix officiel

Une fois placé dans /usr/src, un simple dpkg -i postfix_2.5.5-1.1_i386.deb postfix-mysql_2.5.5-1.1_i386.deb suffit à remplacer postfix et son extension mysql. Ca ne flingue même pas la conf actuelle. Bref, nickel.

On ajoute le champ quota, on indique à postfix et courierauth

Dans la base de données, on ajoute la colonne. J'ai choisi 20 Mo par défaut.

mysql> alter table users add quota bigint (20) default '20971520' after password;
Query OK, 1 row affected (0.10 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> desc users;
+----------+-------------+------+-----+----------+-------+
| Field    | Type        | Null | Key | Default  | Extra |
+----------+-------------+------+-----+----------+-------+
| email    | varchar(80) | NO   | PRI | NULL     |       |
| password | varchar(20) | NO   |     | NULL     |       |
| quota    | bigint(20)  | YES  |     | 20971520 |       |
+----------+-------------+------+-----+----------+-------+
3 rows in set (0.00 sec)

Le alter s'est occupé de mettre la valeur par défaut sur les comptes existants

On crée alors la requête qui vérifie les quotas :

mxtest:~# cat /etc/postfix/mysql-virtual_mailbox_limit_maps.cf
user = mail_adm
password = monpassadmin
dbname = postfix
query = SELECT quota FROM users WHERE email='%s'
hosts = 127.0.0.1

Pensez à priver l'accès à ce fichier.

Et on ajoute cette notion de limite dans notre postfix-qui-sait-gérer-les-quotas, dans /etc/postfix/main.fr :

virtual_mailbox_limit_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailbox_limit_maps.cf
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = "The user you are trying to reach is over quota - L'utilisateur que vous cherchez a contacter a depasse son quota de mails"
virtual_overquota_bounce = yes

Sans oublier d'ajouter "$virtual_mailbox_limit_maps" dans la variable "proxy_read_maps".

Indication des quotas à "courier"

On précise à courier qu'il y a des quotas en créant ou décommentant la variable suivante :

mxtest:~# grep quota /etc/courier/authmysqlrc
MYSQL_QUOTA_FIELD       quota

On recharge le tout, on teste, on se congratule. Youpi, c'est fini.

Ce que je n'ai pas traité

j'ai pas joué avec les transports

Pas besoin dans mon cas.

Avoir un procmailrc par utilisateur ?

Aucune idée, je verrai plus tard.
En effet, où doit-on stocker le .procmailrc ??? ou alors faire un /etc/procmailrc général qui éventuellement trie par destinataire... lourd.

Désactivation de protocole par utilisateur

Exemple, besoin de désactiver le webmail ou le POP pour un utilisateur ? A priori, avec les "critères supplémentaires" que l'on peut passer dans les fichiers .cf de description de requêtes, ça doit être jouable. Je n'ai pas cherché car pas encore eu besoin.
Evidemment, il faudra ajouter une/des colonne dans la table, sûrement un booléen indiquant si le protocole est accepté pour l'utilisateur X.

Alerte sur les dépassements de quota

Pas eu encore le temps, mais il faudra y penser pour détecter les boulets qui ont des boîtes pleines et ne comprennent pas pourquoi ils ne reçoivent rien.
Je n'ai pas encore regardé : chapitre 11 dans cette page.
Voilà, j'espère que ça roulera pour votre installation et que vous aurez ainsi une belle plateforme de mails.

Vite, iptables doit pouvoir m’aider. Je suis une buse en QoS, mais bon, j’ai confiance en Google

Après quelques recherches, je suis tombé sur LARTC, Linux Advanced Routing & Traffic Control. En quelques mots, une bande de fous-furieux qui aiment les lignes de commandes compliquées (à côté de ça, iptables est un joujou) pour faire de la QoS.
Y’a un howto super complet : http://www.traduc.org/docs/howto/vf/lartc.html. Pas le temps, ça sent le sujet compliqué et vaste. On verra plus tard.

Là je veux juste limiter le trafic entre mon proxy et ce p~!?[n de serveur WSUS.

J’ai trouvé 3 lignes magiques ici (après avoir survolé le man tc histoire de suivre le loin ce que je fais) :

tc qdisc add dev eth0 root handle 1: cbq avpkt 1000 bandwidth 10mbit
tc class add dev eth0 parent 1: classid 1:1 cbq rate 400kbit allot 1500 prio 5 bounded isolated
tc filter add dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.2 flowid 1:1

Je voulais limiter le trafic vers 192.168.1.2 via eth0 à 50 kB/s, soit en gros 400 kbit/s.
Pour annuler, j’ai “annulé” les commandes, si je peux dire. Sans être trop sûr de moi, j’ai simplement tenté ça :

tc filter del dev eth0 parent 1: protocol ip prio 16 u32 match ip dst 192.168.1.2 flowid 1:1
tc class del dev eth0 parent 1: classid 1:1 cbq rate 400kbit allot 1500 prio 5 bounded isolated
tc qdisc del dev eth0 root handle 1: cbq avpkt 1000 bandwidth 10mbit

Je n’ai pas vu d’effet de bord (genre, tout bloqué ou rien qui ne se rétablit une fois le tc annulé). Donc on va dire que c’est probablement un peu crade, que je n’y comprends pas tout, mais que ça marche.

Voilà, si ça peut vous servir, j’en suis content.
noob-powered

Gros guide de mise en place de Nagios sur Debian, avec comme principal objectif de vous amener petit à petit à monitorer tout ce qu’on peut imaginer sur un parc de serveurs Linux, Windows, des équipements réseaux etc. Ca part d’un exemple bien détaillé (je l’espère) pour bien faire comprendre les principes et l’esprit Nagios pour espérer à la fin, vous avoir donné de quoi évoluer facilement pour ajouter n’importe quel test.
Au départ, je voulais faire un guide super complet, mais avec Nagios, on ajoute des tests tous les jours, pour ainsi dire. Bref, ça fait 3 mois que j’attendais pour faire ce guide. Finalement je l’écourte un peu et j’ajouterai (peut-être) des chapitres plus tard sur ce blog.
Après un premier exemple bien complet, je donne des exemples rapides de contrôles courants.

J’ai eu l’idée de rédiger cet article sachant que je ne connaissais rien à Nagios (rien de sa mise en place, rien des fichiers de conf, rien de sa syntaxe, rien des outils de base, rien des plug-ins supplémentaires et rien des contributions à gogo sur le web etc). L’intérêt, n’y connaissant rien justement, est que j’explique pas à pas, notamment les principes de l’outil pour comprendre comment le configurer, en détaillant parfois toutes les panneaux que j’ai pu me prendre, mais en donnant la solution rapidement

A la fin, je donne mes fichiers de conf, un peu anonymisés et allégés, ils peuvent vous servir pour de la mise en place de certains morceaux ou pour vous guider dans la syntaxe. Exemple, vous voulez surveiller vos serveurs DNS, cherchez le mot “dns” dans tous les fichiers, comprenez ce qui y est fait et copiez-collez-modifiez les bons blocs. Reste à changer les noms de hostname Hum, ça, ce sera plus tard lorsque j’aurai complété par d’autres articles (cf. ci-dessus), je n’ai pas trop le temps, et sinon, je ne publierai jamais cet article… il traîne depuis 3 mois…

Je ne compte pas faire de l’ombre à Nicolargo (passionné du sujet Nagios) mais mon approche est différente : je pars de ce que Debian a fait pour moi, pas des sources à compiler pour avoir l’absolue dernière version. Les répertoires de configuration et de chemins des binaires sont différents, tous les plug-ins classiques sont directement disponibles.
Après, une fois l’outil fonctionnel sur quelques cas, ça reste du Nagios pur. Allez voir son site, il y a de bonnes docs et le forum peut aider aussi. Sans compter d’autres sites d’outils de monitoring complémentaires, notamment http://www.monitoringexchange.org/, et évidemment la doc officielle qui est très bien foutue. J’y ferai référence autant de fois que j’y penserai.

La version actuellement packagée sous Debian “stable” (Lenny) est Nagios 3.0.6. Comme d’habitude avec Debian, un peu en retard sur la version officielle, mais il y a d’autres intérêts à utiliser tout de même la version packagée, à mon avis.

Installation

Sur un air d’aptitude install

Ca commence sur un air connu par un aptitude install nagios3. A noter que ça descend par dépendance 3 paquets nagios-plugins* qui contiendront tout un tas de plugins (contrôle de LDAP, de mail, de MySQL, de MRTG, de serveur FTP…).
Une remarque pendant l’installation (pour le chapitre suivant) :

[...]
Get:10 ftp://ftp.fr.debian.org lenny/main nagios3-doc 3.0.6-3 [2034kB]
[...]
serious bugs of nagios3-common (-> 3.0.6-3) 
 #519341 - nagios3-common: missing "then" in nagios3-common.prerm (Fixed: nagios3/3.0.6-4)
[...]

On voit aussi passer ces plugins :

[...]
Creating config file /etc/nagios-plugins/config/http.cfg with new version
Creating config file /etc/nagios-plugins/config/load.cfg with new version
Creating config file /etc/nagios-plugins/config/mail.cfg with new version
[...]

Lisez de préférence tous les fichiers README.Debian des répertoires /usr/share/doc/nagios3 et /usr/share/doc/nagios-plugins. Il y a 2/3 infos importantes, mais je les reprends au fil de l’eau dans la suite de l’article.

Droits d’accès à l’interface web de Nagios

Les README.Debian habituels qu’on trouve dans /usr/share/doc/nagios* parlent du truc et indiquent qu’on doit avoir une question posée pendant l’installation. Vu le bug mentionné plus haut par apt-listbugs (c’est quoi ?), je ne m’étonne qu’à moitié de n’avoir pas vu passer de “fenêtre” (ncurses) pendant l’installation. Doc pas à jour ou vrai bug. Bon bref, il faut rectifier le tir.

On voit dans /etc/apache2/conf.d/nagios3.conf que les droits sont gérés par htaccess (voir directive AuthUserFile)dans /etc/nagios3/htpasswd.users. Or, ce fichier n’existe pas, on doit donc le créer.

htpasswd -c /etc/nagios3/htpasswd.users nagiosadmin

Le nom nagiosadmin semble important pour éviter certains ennuis (de ce que j’en ai lu, mais je ne sais plus où, peut-être là).
Enfin, vérifiez les droits sur le fichier en question, idéalement, il faut :

chown root:www-data /etc/nagios3/htpasswd.users
chmod 640 /etc/nagios3/htpasswd.users

Et recharger apache via /etc/init.d/apache2 reload.
L’adresse d’accès doit être http://votre.serveur/nagios3/.

Principe de base et cheminement de ma doc

Une fois qu’on a pataugé un peu, il en ressort quelques grands principes pour gagner en autonomie et arriver à pondre du fichier de conf au kilomètre ou savoir où regarder pour trouver un plug-in tiers, le mettre en place, l’utiliser et même l’adapter.
Quelques grandes idées pour démarrer :

• Nagios appelle des scripts permettant de contrôler un élément particulier (ou plusieurs d’un coup) : contrôler un service, les espaces disques, la charge CPU, la réponse d’un site web, la charge d’un port de switch etc
• On a des modèles d’appels de scripts, nommés en général “check_quelquechose” permettant de comprendre les paramètres pour un contrôle donné (valeurs limites, nom du truc à regarder
• Il faudra déployer des agents pour certains contrôles, notamment pour contrôler du Windows. En gros, pour obtenir des informations qui sont récupérables par un traitement local uniquement, pas à distance. Normal me direz-vous. Ces agents sont des à côtés du projet Nagios. Mais il y a déjà tout ce qu’il faut.
• Il va falloir décrire nos machines une à une et ce qu’on contrôle pour chacune (forcément, c’est pas magique comme outil). On pourra faire des groupes de machines et y associer des contrôles appliqués à ces groupes. Exemples : toute machine hébergeant un serveur web aura de base un contrôle vérifiant le port 80 ; toute machine Windows aura de base un contrôle sur la nécessité d’applications de patchs, un contrôle sur l’espace disque etc…

Dans cette doc, je vais décrire chaque sujet dans l’ordre dans lequel j’ai mis en place les contrôles, souvent en partant de la doc officielle (parfois pas exactement à jour) puis en adaptant au contexte Debian qui a, comme d’habitude, pré-mâché certaines choses (mise à dispo de scripts, “modèles” pour tel type de machine, de switchs etc).
Je voulais avant tout contrôler un peu tous ces jolis serveurs Windows qui sont peu bavards en général (ou qui racontent uniquement des trucs dont on se fout)… Donc il y a une bonne partie sur l’interfaçage avec Windows ; cas somme toute courant je pense.
Du coup, je dissémine des informations malgré moi à mesure de ma compréhension (lorsque j’ai “appris” Nagios) ; et surtout en ayant rédigé la doc quelques mois après (hum).

Bon, en bref, Nagios est un outil tout sauf clef-en-main (sauf peut-être si vous optez pour un système comme FAN, mais vous aurez un système dédié “limité” à Nagios&co je suppose)
Le paramétrage est long et on en ajoute chaque jour.
Pour le planning pour le patron, prévoyez large. Mise en place et premiers résultats quelques heures tout au plus, paramétrage plus poussé : quelques semaines. Plus on en découvre, plus on monitore de choses. On corrige les problèmes et on en anticipe d’autres grâce à Nagios. Bref, le bonheur avec reporting pour le patron. A la fin, on commence à écrire ses propres scripts, en n’importe quel langage.

Ah au fait, attention aux alertes par mail. Nagios vous dit tout : “tel service est tombé”, “tel service est toujours KO”, “tel service est revenu”. Multiplié par le nombre de service et de machines, ça fait des mails à la pelle. Faudra prévoir des règles de tri dans un premier temps…

C’est parti

Surveillance des basiques de serveurs Windows (NT, 2000, XP, 2003 et +)

Oui les libristes vont encore perdre du temps à critiquer le fait que je parle de Windows-le-mal-incarné d’abord. Economisez-vous. Mon point de vue est que justement, Nagios aide très bien à monitorer “du windows” là où Windows est quand même à chier niveau remontées d’alertes, en standard. Autant, un Linux un tant soit peu configuré vous remonte déjà plein de choses par mail, par exemple, qu’il ne sera pas forcément la peine d’aller contrôler par Nagios.

Installation et 1er paramétrage de l’agent NSClient++

Si vous voulez la doc officielle, commencez par là (http://nagios.sourceforge.net/docs/3_0/quickstart.html) et enchainez sur http://nagios.sourceforge.net/docs/3_0/monitoring-windows.html.
Il faut donc télécharger et déployer un agent windows pour Nagios. Disponible en 32, 64 bits. Je pense qu’il y en a plusieurs, j’ai opté pour celui-ci, qui m’a l’air complet : http://sourceforge.net/projects/nscplus.
Lorsque ça marchera pour une machine, il n’y aura qu’à déployer l’agent à distance et injecter le fichier de conf NSC.ini qui va bien sur chaque machine. Pensez aux outils sysinternals.com microsoft, notamment les PSTools et psexec. C’est pratique pour automatiser.

L’agent apporte une interface entre l’appelant Nagios et un serveur Windows. Il apporte aussi de base quelques outils pour effectuer une certaine batterie de tests. Le paramétrage des tests que l’on veut se fait sur le serveur Nagios, pas du côté de l’agent Windows.
Si on veut ajouter un test qui n’est pas prévu par cet agent, il faudra écrire un script, sous windows cette fois, et le définir dans l’agent, qui sert de relai, en gros. On le verra plus bas avec le contrôle des patchs Windows en attente d’installation.

Bref, une fois NSClient++ installé, la doc dit d’aller trafiquer les options du service Windows qu’on vient d’installer. Dans les propriétés du service, allez dans l’onglet “Connexion / Log on” et cocher la case pour autoriser à “interagir avec le bureau”.

Maintenant il faut ajuster un peu le fichier de paramétrage de l’agent, C:\Program Files[ (x86)]\NSClient++\NSC.ini. Sachant que je vais y revenir plus tard pour NRPE (voir plus bas), si c’est la galère pour déployer le fichier sur vos machines, attendez un peu pour le faire une seule fois (cherchez plus bas dans l’article NRPE). Enfin bon, commencez par un serveur avant de généraliser un truc qui ne fonctionne pas.

Dans la section [modules], décommenter comme suit (tout sauf CheckWMI.dll et RemoteConfiguration.dll) :

[modules]
;# NSCLIENT++ MODULES
;# A list with DLLs to load at startup.
;  You will need to enable some of these for NSClient++ to work.
; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
; *                                                               *
; * N O T I C E ! ! ! - Y O U   H A V E   T O   E D I T   T H I S *
; *                                                               *
; ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
FileLogger.dll
CheckSystem.dll
CheckDisk.dll
NSClientListener.dll
NRPEListener.dll
SysTray.dll
CheckEventLog.dll
CheckHelpers.dll
;CheckWMI.dll
;
; RemoteConfiguration IS AN EXTREM EARLY IDEA SO DONT USE FOR PRODUCTION ENVIROMNEMTS!
;RemoteConfiguration.dll

Dans la partie [NSClient], attribuer un port d’écoute (celui par défaut à priori) et dans la section [Settings], à voir si vous voulez un mot de passe. Je n’en ai pas mis, j’ai limité l’écoute à l’adresse IP de mon serveur Nagios ; pratique dans ce cas simple avec un seul serveur de monitoring.

[...]
[NSClient]
[...]
port=12489
[...]
[Settings]
[...]
;password=secret-password
allowed_hosts=192.168.y.x
[...]

Notez la section [log] qui peut être pratique quand rien ne fonctionne et qu’il faut comprendre ce que NSClient reçoit de Nagios.

Redémarrez le service, le client est prêt.

Premier morceau de config Nagios, la théorie

Maintenant on va indiquer à Nagios d’aller voir ce qu’il se passe là-bas et quels tests de base effectuer pour une “machine windows”.
On va partir d’un modèle de configuration de poste Windows fourni par Debian et définir notre machine, appelée “mamachine”.
Là ça fait un peu mal au crâne la première fois, mais une fois le concept compris, vous pondrez des fichiers de conf Nagios au kilomètre. En effet, c’est le chapitre où on fait le baptême du feu dans la syntaxe Nagios. J’espère être clair dans ces prochains chapitres.

L’organisation en terme de fichiers dans /etc/nagios3/conf.d/ est complètement libre. Vous pouvez tout mettre dans un seul fichier ou couper par site (par exemple), ou encore séparer la déclaration des machines de celle des groupes de machines, mettre la définition de vos propres services à part ou proche des groupes de machines auxquelles ces services se rapportent etc.
C’est votre choix, à la fin, Nagios intègrera l’ensemble des directives de configuration de “conf.d” (ainsi que des plugins, tout ceci est configuré en amont par Debian dans /etc/nagios3/*conf) et hurlera au “reload” si vous vous êtes trompés.
C’est d’autant plus libre qu’en géréral, il y a plusieurs manières d’organiser les choses pour arriver à un même résultat. Premier exemple ci-dessous : est-ce que je dis que “mamachine” appartient au groupe (hostgroup) “windows-servers” ou est-ce que je dis que le groupe “windows-servers” contient comme membre (members) “mamachine”. A vous de voir.
Je mets les mots-clefs Nagios entre parenthèse et en italique pour faire l’association “bon français”-”mot-clef Nagios”.

Donc, pour une conf de base pour tester une machine via NSClient++, je prends le “groupe” Windows (qu’on complètera plus tard) et je crée une machine “mamachine” appartenant à ce groupe. Ce qu’on appelle ici un “groupe” est un “ensemble des machines auxquelles un certains nombre de tests communs seront appliqués”. C’est un “hostgroup”. Debian a déjà affecté plusieurs tests à ce groupe. C’est pratique.
L’idée sera d’ajouter par la suite au groupe (hostgroup) “windows-servers” d’autres les tests qui sont communs à tous les Windows : présence de patchs WSUS par exemple. Par exemple, on n’ajoutera pas le contrôle du disque F: qui n’existe peut-être pas sur tous les serveurs. Là il faudra faire par machine, ou alors un groupe “des machines ayant un disque F:”. C’est votre choix.

Attention, la notion de “template” dans Nagios est différente, c’est réellement un modèle qui définit d’autres informations sous-jascentes. On n’y touchera pas (il me semble). Il y a des templates “windows” (nommés windows-server, et pas windows-servers qui est le groupe de machine windows, vu ? ), mais aussi par exemple un “template” de service nommé generic-service sur lequel on se base pour déclarer un service.

Premier morceau de config Nagios, la pratique

Alors, je localise le groupe (hostgroup) “windows-servers” pré-mâché par Debian. On va l’utiliser car il amène en standard les contrôles de base : espace disque, charge CPU…

srvnag:/etc/nagios3/conf.d# dpkg -S windows.cfg
nagios3-common: /usr/share/doc/nagios3-common/examples/template-object/windows.cfg
srvnag:/etc/nagios3/conf.d# cp /usr/share/doc/nagios3-common/examples/template-object/windows.cfg template-windows.cfg

Ce fichier contient, sans les commentaires standards mais avec les miens et une fois un peu remodelé, ceci :

define host{ ; définition d'une machine basée sur le template "windows-server", nommé ci-dessous
        use             windows-server  ; Inherit default values from a template
        host_name       mamachine       ; The name we're giving to this host
        alias           C est mamachine       ; A longer name associated with the host
        address         192.168.x.y     ; IP address of the host
        ; #hostgroups windows-servers ; voir ci-dessous
}

Cette dernière ligne (hostgroups) aurait permis de dire “mamachine” appartient au groupe (hostgroup) “windows-servers” (donc elle hérite de tous ses tests). Dans mon cas, j’ai plutôt décidé de définir la liste des membres (=machines = “host”) d’un groupe (hostgroup) dans la définition de ce groupe. Voir ci-dessous.
J’ai adapté les tests fournis par Debian pour le groupe “windows-servers” (qui ne contient qu’une machine pour l’instant). Voici le fichier résultant :

### Déclaration du groupes windows-servers auquel on affectera les tests communs à tous les windows
define hostgroup{
        hostgroup_name  windows-servers ; Mes serveurs windows
        alias           Windows Servers ; Long name of the group
}

### Définition des SERVICE que l'on va associer au groupe windows-servers
# Create a service for monitoring the version of NSCLient++ that is installed
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     NSClient++ Version
        check_command           check_nt!CLIENTVERSION
}
# Create a service for monitoring the uptime of the server
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     Uptime
        check_command           check_nt!UPTIME
}
# Create a service for monitoring CPU load
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     CPU Load
        check_command           check_nt!CPULOAD!-l 5,80,90
}
# Create a service for monitoring memory usage
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     Memory Usage
        check_command           check_nt!MEMUSE!-w 80 -c 90
}
# Create a service for monitoring C:\ disk usage
define service{
        use                     generic-service
;        host_name               mamachine ; non je ne raisonne pas par machine, mais par groupe
        hostgroup_name         windows-servers; voilà où est l'association service/groupe windows
        service_description     C:\ Drive Space
        check_command           check_nt!USEDDISKSPACE!-l c -w 80 -c 90
}
# Create a service for monitoring the W3SVC service
# c'est un exemple gardé en commentaire pour la syntaxe check_nt de contrôle d'un service, voir plus bas
;define service{
;        use                     generic-service
;        host_name               mamachine
;        service_description     W3SVC
;        check_command           check_nt!SERVICESTATE!-d SHOWALL -l W3SVC
;}
# Create a service for monitoring the Explorer.exe process
# c'est un exemple gardé en commentaire pour la syntaxe check_nt de contrôle d'un processus, voir plus bas
;define service{
;        use                     generic-service
;        host_name               mamachine
;        service_description     Explorer
;        check_command           check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe
;}

Voilà. Si vous rechargez Nagios via /etc/init.d/nagios3 reload, ben ça plante !!!
Je décris ça juste après avoir décrit “check_command” histoire de finir l’initiation à la conf de base et aux problèmes pénibles du début :/.

Autres principes à comprendre de cet exemple

Qu’y a-t-il d’autre d’important dans cette configuration pour comprendre le principe de Nagios ? le mot-clef “check_command” bien sûr. Lors de la définition d’un service, la directive check_command est celle qui explique à Nagios comment effectuer le test et quels paramètres on lui passe. Les paramètres sont séparés par le “!”. Le premier argument est le nom de la commande (command) Nagios (et pas du script appelé, pas encore, qui lui s’appelle command_line).

Exemple :

        check_command           check_nt!MEMUSE!-w 80 -c 90

On voit les valeurs d’alertes warning et critical pour la charge mémoire utilisée, en pourcentage. On retrouvera souvent les mêmes noms d’arguments alors que les scripts n’ont rien à voir entre eux (-w pour seuil de warning etc). Il doit y avoir une sorte de norme dans le développement de ces scripts, je suppose.

Pour comprendre le lien entre la command et le script effectivement appelé sur l’OS, voici :

srvnag:/etc/nagios-plugins# grep -r command_name * | grep check_nt
config/nt.cfg:  command_name    check_nt
[...]

On y voit l’association entre cette commande Nagios et la commande OS appelée :

srvnag:/etc/nagios-plugins/config/cat nt.cfg
define command {
        command_name    check_nt
        command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'
# cette ligne est erroné d'ailleurs, on le verra plus tard.
}

La commande (command) check_nt appelle donc le script /usr/lib/nagios/plugins/check_nt.
C’est avec lui qu’il faudra jouer pour “tester certains tests” en ligne de commande, avant de comprendre pourquoi ils plantent depuis Nagios mais pas depuis la ligne de commande. C’est un cas courant..
Bon revenons au bug qui m’occupait et qui devrait aussi vous occuper, à priori un problème lors du reload (je n’ai plus le message précis), mais on comprend que :

Il manque le template windows-server

J’ai dit le template “windows-server”, pas “windows-servers” qui est un hostgroup, j’insiste.
En effet, ce template est fourni dans les packages Debian, mais pas chargé par défaut. En cherchant un peu, on le trouve ici : /usr/share/doc/nagios3-common/examples/template-object/templates.cfg.gz.
Mais si on le gunzip et qu’on le place dans /etc/nagios3/conf.d, il y a doublon de définition de generic-service comme le montre encore un reload qui plante. Ca se confirme avec cette commande :

srvnag:/etc/nagios3/conf.d# egrep "name[[:space:]]+generic-service" *
generic-service_nagios2.cfg:        name                            generic-service ; The 'name' of this service template
templates.cfg:        name                            generic-service   ; The 'name' of this service template

Deux fichiers définissent “generic-service”. Les emmerdes continuent.

Donc, je reprends le minimum du template générique, dans mon cas, “windows-server”, on verra plus tard si j’ai besoin de quelque chose d’autre de ce super-template. Je crée donc ce fichier, tout au moins j’ajoute ce bout de code quelque part dans ma conf Nagios :

srvnag:/etc/nagios3/conf.d# cat windows-server_from_templates-gz.cfg
define host{ ; oui ça passe par un "host" pour définir ce modèle de machine "windows-server"
        name                    windows-server  ; The name of this host template
        use                     generic-host    ; Inherit default values from the generic-host template
        check_period            24x7            ; By default, Windows servers are monitored round the clock
        check_interval          5               ; Actively check the server every 5 minutes
        retry_interval          1               ; Schedule host check retries at 1 minute intervals
        max_check_attempts      10              ; Check each server 10 times (max)
        check_command           check-host-alive        ; Default command to check if servers are "alive"
        notification_period     24x7            ; Send notification out at any time - day or night
        notification_interval   30              ; Resend notifications every 30 minutes
        notification_options    d,r             ; Only send notifications for specific host states
        contact_groups          admins          ; Notifications get sent to the admins by default
        hostgroups              windows-servers ; Host groups that Windows servers should be a member of
        register                0               ; DONT REGISTER THIS - ITS JUST A TEMPLATE
}

Bien sûr, on comprend que ce template dépend lui-même du template “generic-host”, mais, ce “generic-host” est dans les templates de base de /etc/nagios3/conf.d/. Pas de problème cette fois.
Là, le restart de Nagios devrait bien se passer hop, connexion à l’interface. Moi perso, j’y ai vu une tartine de trucs avec des warnings, des “critical”, des machins à hurler partout. Surtout des trucs à débugger en fait. Ce qu’on va faire en expliquant.

Attention les remontées par mail vont commencer (par défaut root@localhost). Faites ce qu’il faut pour récupérer ces mails.

Bug “missing -l parameters”

Le premier bug relevé fût donc un résultat de commande “missing -l parameters” dans ̉l’interface web̉ de Nagios.
Pour débugger, il faut en revenir à la ligne de commande comme montré brièvement plus haut. Si on exécute le vrai binaire /usr/lib/nagios/plugins/check_nt, ça marche. Depuis Nagios, ça ne marche pas. Tiens tiens.
Demandez l’aide pour apprendre à utiliser ce plug-in en ligne de commande :

srvnag:/etc/nagios-plugins# /usr/lib/nagios/plugins/check_nt
check_nt: Could not parse arguments
Usage:check_nt -H host -v variable [-p port] [-w warning] [-c critical][-l params] [-d SHOWALL] [-t timeout]

Vous pouvez faire un /usr/lib/nagios/plugins/check_nt --help pour une doc plus complète.
Si vous jouez avec l’outil en ligne de commande, ça marche pourtant, exemple :

srvnag:/etc/nagios-plugins# /usr/lib/nagios/plugins/check_nt -H mamachine_ou_son_IP -v MEMUSE -p 12489 -w 80 -c 90
Memory usage: total:3945.26 Mb - used: 1287.70 Mb (33%) - free: 2657.56 Mb (67%) | 'Memory usage'=1287.70Mb;3156.21;3550.73;0.00;3945.26

Il y a deux problèmes. D’abord Nagios n’est pas configuré pour tolérer l’appel à des scripts “extérieurs” (raison sécuritaire). Ensuite, la command check_nt est mal définie (gasp !). J’en parlais plus haut.

Le README.Debian le disait, et dans notre cas on en a besoin, il faut autoriser Nagios a appeler des scripts extérieur. Il faut positionner set check_external_commands=1 dans /etc/nagios3/nagios.cfg. Ensuite, il faut modifier quelque chose dans dpkg pour qu’une manip soit retenue après mise à jour/upgrade de nagios par aptitude :

srvnag:/etc/nagios3# /etc/init.d/nagios3 stop
Stopping nagios3 monitoring daemon: nagios3
.
srvnag:/etc/nagios3# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
srvnag:/etc/nagios3# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
srvnag:/etc/nagios3# /etc/init.d/nagios3 start
Starting nagios3 monitoring daemon: nagios3/etc/init.d/nagios3: line 64: kill: (19130) - No such process.

A noter, j’ai vu plusieurs fois un problème de PID non trouvé, on dirait que le fichier /var/run/nagios3/nagios3.pid n’est pas purgé à l’arrêt de Nagios ; pas grave.

Enfin, on modifie la command check_nt. Le “missing -l parameters” signifie bien qu’on n’a pas passé le paramètre “-l” au binaire check_nt, paramètre obligatoire pour certains tests. En fait, dans /etc/nagios-plugins/config/nt.cfg, l’appel à check_nt est défini comme suit :

        #command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'

Mais souvent, dans les services associés à notre hostgroup windows-servers, on voit qu’un deuxième paramètre est passé. Le fameux “-l”. C’est simplement que la définition de la commande (command_line) ne s’occupe de récupérer qu’un seul paramètre…
Je suggère donc de modifier /etc/nagios-plugins/config/nt.cfg comme suit :

gw:/etc/nagios-plugins/config# cat nt.cfg
# 'check_nt' command definition
define command {
        command_name    check_nt
        #command_line    /usr/lib/nagios/plugins/check_nt -H '$HOSTADDRESS$' -v '$ARG1$'
        command_line    /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -p 12489 -v $ARG1$ $ARG2$
}

Reload de Nagios. Enfin les premiers testent passent !
Pour dire vrai, je suis passé par un stade intermédiaire de “wrong -l argument”. J’ai forcé l’appel du port (-p 12489) dans la command_line pour régler le problème. Si vous voulez rendre ce port variable, à vous de modifier la définition des services (dans les define service) appelant check_nt pour passer un n-ième argument.
J’ai aussi fait sauter les apostrophes, ça me faisait des trucs bizarres.
FIXME : si quelqu’un sait comment activer une trace qui permet de savoir comment a été appelée telle ou telle commande par Nagios, ce serait cool ça permettrait de débugger plus facilement. J’ai tenté plusieurs niveaux de débuggage, sans succès.

Ouf, premiers tests fonctionnels. Vite, d’autres !

Ca marche, c’est pas trop tôt. Quelques suggestions tirées de ce qui précède :

• Dans /etc/nagios-plugins/conf.d/, il y a plein de noms de commandes à lire, pour voir ce qu’on va pouvoir rapidement contrôler. Exemple : contrôler un port https, avec ou sans authentification (plusieurs commandes dispo).
• Dans /usr/lib/nagios/plugins/, il y a le pendant en terme de binaires. C’est bien de se familiariser avec ceux qu’on compte utiliser pour être sûr de savoir les utiliser en ligne de commande avant de s’ajouter des bugs en les définissant mal dans la conf Nagios.

Je considère par la suite que vous avez bien assimilé ce qu’on vient de voir et que vous êtes maintenant parés pour créer de la configuration Nagios à grand coup de grep et de copier-coller d’exemples. Je vais pouvoir donner des bouts de codes en vrac, par thème.

C’est reparti.
C’est là où j’aurais voulu faire une doc méga-complète, mais c’est impossible. J’ajouterai donc plus tard des chapitres lorsque j’estimerai que tel ou tel sujet n’était pas trivial à mettre en place ou qu’il y a un concept fort que je n’ai pas abordé.

Contrôle DHCP

Plus exactement, “tester si le serveur DHCP est en mesure d’attribuer des IP” (plage pleine ? service KO ?).
Je considère ici mon serveur Nagios comme un simple ordinateur client DHCP sur le réseau (ou une partie du réseau). En exécutant un script, l’outil check_dhcp simulera une demande de bail et vérifiera que tout se passe bien.
En lisant /etc/nagios-plugins/config/dhcp.cfg, vous voyez vite que la command_line attend un paramètre, l’adresse du serveur DHCP. Donc, en ajoutant quelque part dans votre /etc/nagios3/conf.d/quelquechose.cfg les lignes suivantes, on met en place le contrôle DHCP :

define service {
        use     generic-service
        host_name mon_serveur_dhcp ; ou alors vous raisonnez par hostgroups, au choix
        service_description     Reponse du DHCP
        check_command           check_dhcp
}

En ayant bien sûr défini “mon_serveur_dhcp” dans un bloc define host quelque part.
Notez qu’il y a aussi un check_dhcp_interface, qui d’après /usr/lib/nagios/plugins/check_dhcp --help permet de spécifier une interface particulière.

Ce contrôle est un bon exemple car il faut qu’il soit lancé avec les droits root – ou en sudo – car le principe, je suppose, doit être de forger des paquets pour déclencher une attribution de bail du serveur DHCP ; et forger des paquets => droit root, un peu comme l’outil de scan de port “nmap” dans certains types de scans. Lire /usr/share/doc/nagios-plugins/README.Debian à ce propos. Ca raconte de faire :

dpkg-statoverride --update --add root nagios 4750 /usr/lib/nagios/plugins/check_dhcp

Sinon, vous aurez un joli Warning: This plugin must be either run as root or setuid root. dans l’interface Nagios.
Dans mon cas, le serveur DHCP est un Windows (ah, j’te parle plus). J’ai donc aussi installé le client NSC++ sur cette machine afin de pouvoir remonter de base tous les autres indicateurs. En effet, j’ai déclaré “mon_serveur_dhcp” dans la catégorie windows-servers, donc il récupère de base tous les tests concernant le groupe “windows-servers”, contrôle des disques, RAM, blablabla.
Hop, un test de plus.

Zoom sur les groupes de machines

J’en parle tout de suite car il y a déjà des groupes (hostgroups) définis dans /etc/nagios3/hostgroups_nagios2.cfg. Notamment les machines “pingables”. Je trouve que c’est une bonne idée d’ajouter des groupes type “les serveurs web” ou “les serveurs de mail”. Même si pour l’instant vous n’avez pas encore défini de service (define service) pour ces groupes, ça permet de s’organiser et de prévoir la distribution automatique de plein de tests à mesure qu’on déclare nos host et qu’on les affecte à ces groupes (hostgroup), et non pas aux machines.

Au passage, avec un bon dpkg -S base/debian.png et un grep qui va bien, vous allez vite localiser le bout de configuration qui permet d’affecter des icones aux types de serveurs, pour faire joli dans l’interface.

Droits d’utilisateurs, contacts

Pour créer un utilisateur en lecture (votre patron par exemple, il faut le limiter, pour pas qu’il fasse n’importe quoi depuis l’interface), le mieux est de lire http://nagios.sourceforge.net/docs/3_0/cgiauth.html. Attention, c’est fourbe car le menu de replanification – par exemple – de test de service est disponible pour tous les utilisateurs, mais c’est après validation de l’action qu’on voit que la personne n’a bien pas le droit de lancer une planification de tests.

Dans le cas d’une installation énorme de serveurs, il est possible d’affecter des contacts à tel ou tel serveur. Vous pouvez aussi donner les droits de supervision à une personne sur un certain ensemble de contrôles uniquement, ce genre de trucs.
Car la liste peut être longue une fois déclarés une 20aine de serveurs triés en X catégories…

Vue par service

Dans l’interface web de Nagios, vous avez sûrement trouvé le menu qui permet d’avoir un aperçu par hostgroup. On peut aussi créer une vue par service. Exemple, j’ai mis plein de contrôles de “services publics”, à savoir la réponse d’un FTP distant, la présence d’un serveur web distant, la réponse spécifique (recherche d’un mot dans un page web reçue) etc. J’estime que tout ça représente un ensemble, mes “services publics dont j’aimerais être sûr qu’ils sont bien online à tout moment sinon on perd nos clients”.
Je vais donc définir un “groupe de service” (servicegroup) rassemblant des couples (machine , service).

Plus précisemment, il s’agit de lister des couples (host_name d’un host , service_description d’un service).
Petit exemple :

define servicegroup {
        servicegroup_name       public-services
        alias                   Services Internet
        members                 srvweb,Check URL non signee,ftpext,Check FTP ; les fameux couples host/service
}

Je suppose ici que les define host “srvweb” et “ftpext” sont définis, ainsi que les define service “Check FTP” et “Check URL non signee” ; ces exemples seront donnés plus bas dans cette doc.
Pour les services, il s’agit bien de leur description longue, pas de leur nom.
Ainsi, dans le menu “servicegroup overview”, vous verrez un groupe “Services Internet” vous donnant d’un coup d’oeil l’état de tous vos services publics/web.

Contrôle de services Windows

Exemple pour un serveur Exchange ou pour une base Oracle, je veux être sûr que tous les services associés sont en cours d’exécution.
Bon cette fois, je passe sur les groupes de machines Oracle qu’on pourrait créer. Là le but est d’appréhender le contrôle de services Windows via NSClient++.

Exemple avec Exchange

Si je vous suggère de tester la commande suivante, vous allez vite comprendre :

srvnagw:/usr/lib/nagios/plugins# ./check_nt -H mon_serveur_exchange -p 12489 -v SERVICESTATE -d SHOWALL -l MSExchangeIS,MSExchangeMTA,SMTPSVC,RESvc,W3SVC

La liste des noms technique des services s’obtient en double-cliquant sur le nom d’un service Windows, dans ses propriétés.
Reste à définir le service et la commande qui va bien et à l’affecter à votre serveur ou votre groupe de serveurs Exchange.
Voir plus bas mes exemples si vous êtes paumés.

Ce qui est bien avec cet agent NSClient++, c’est que ça marche pour n’importe quel service. Ci-dessous, on découvre que ça marche aussi pour perfmon .

Exemple avec l’anti-virus Sophos, remarque sur la syntaxe

Attention, certains services ont des espaces dans leur nom.

• Pour les nommer/utiliser en ligne de commande, il faut un backslash \
• Pour les nommer/utiliser depuis Nagios, il faut 2 backslash \

Exemple :

define service {
        use generic-service
        hostgroup_name          sophos-servers
        service_description     Svc SOPHOS server
        check_command           check_nt!SERVICESTATE!-d SHOWALL -l Sophos\\ Agent,Sophos\\ Certification\\ Manager,Sophos\\ EMLibUpdate\\ Agent,Sophos\\ Enterprise\\ Manager\\ Scheduler,Sophos\\ Management\\ Service,Sophos\\ Message\\ Router
}

Pour tester ce check_nt en ligne de commande, un seul \ suffirait.

Exemple de surveillance des services Oracle

Ben c’est la même chose, un gros check_nt!SERVICESTATE!-d SHOWALL -l blabla où “blabla” est la liste de noms de noms instances Oracle, du listener etc.

Contrôle de perfmon

Dans la lignée de ce qui précède, si vous voulez surveiller des indicateurs perfmon de serveurs Windows, c’est jouable.
Notez que perfmon permettant de surveiller à peu près n’importe quoi sur Windows (charge réseau par exemple), ce test peut être une variante d’un test de charge via SNMP ; en ce qui concerne la charge réseau. Pour d’autres indicateurs de perfmon, il n’y a que NSClient++ je suppose, ou un script dédié.
Notamment, vous pouvez contrôler la taille des files d’attente du serveur Exchange monitoré précédemment.
Je ne m’étends pas, mais il faut appeler check_nt avec “-v COUNTER” et le nom des indicateurs que l’on veut suivre.

Contrôle de switchs

Les informations sont décrites là : http://nagios.sourceforge.net/docs/3_0/monitoring-routers.html.
Il faut être un peu habitué à SNMP, ou alors c’est l’occasion de s’y mettre. Il faut savoir activer le SNMP sur un switch et connaître quelques OIDs.
Ceci dit attention, vous pourrez tester l’état de certains ports, l’uptime d’un switch. Mais pour contrôler la bande passante du trafic d’un port, il n’y a pas d’OID. Il faudra écrire votre script vous-même ou alors, interfacer avec Cacti qui lui stocke l’historique des informations de compteurs de trafic, permettant ainsi de calculer des vitesses moyennes. Je suis dessus là, donc j’en parlerai sûrement de ce ces 4.
Le principe est le suivant :

• Il faut activer le “requêtage” SNMP sur le routeur en question, définir une “communauté” (si autre que “public”), un éventuel mot de passe (si SNMP v3)
• S’inspirer ensuite du modèle de conf générique des switchs dispo ici : /usr/share/doc/nagios3-common/examples/template-object/switch.cfg
• Reprendre le template generic-switch (et uniquement lui) de /usr/share/doc/nagios3-common/examples/template-object/templates.cfg.gz
• Lire http://fr.wikipedia.org/wiki/Snmp
• Lire http://doc.ubuntu-fr.org/snmp pour comprendre rapidement les MIB
• Tester en ligne de commande pure d’abord, avec check_snmp

Pour activer le SNMP sur un 3com type 4400, l’attaquer en telnet (menu system management snmp community) car ce n’est pas accessible en interface web. Pour un netgear, c’est gérable par l’interface web du switch (ou alors ça dépend de la version du firmware, j’ai déjà vu ça aussi). On peut limiter à une interface IP, par exemple le serveur Nagios exécutant la requête.

Appel à un script tiers, sous Windows : contrôle des patchs en attente

Truc très pratique, au lieu d’aller voir dans WSUS-qui-rame-et-qui-est-à-moitié-pratique.
On va utiliser NRPE, un agent qui tournera localement sur la machine distante et qui permettra d’exécuter des scripts. Ca tombe bien NSClient++ peut assurer ce rôle, du moment qu’on a décommenter NRPEListener.dll, voir plus haut dans la doc.
Nagios appellera donc NRPE qui appellera un script (ici un .wsf). Au niveau des alertes NAgios, on obtiendra des “warnings” et “critical” suivant la nature des patchs.
J’utilise le script suivant (ou celui là, je ne sais plus, essayez les deux).
Placez les par exemple sur C:\ du serveur à monitorer.

Conf NRPE pour patchs Windows

Dans la section [NRPE] du fichier NSC.ini d’un serveur à monitorer, j’ai dû paramétrer les choses suivantes :

;# COMMAND ARGUMENT PROCESSING
;  This option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed.
allow_arguments=1

;  This option determines whether or not the NRPE daemon will allow clients to specify nasty (as in |`&><'"\[]{}) characters in arguments.
allow_nasty_meta_chars=1

allowed_hosts=192.mon.nag.ios

Et dans la section [NRPE Handlers], comprenez "les commandes autorisées via NRPE", j'ai simplement créé une commande appelée (au niveau de NSClient/NRPE) "windows_updates" :

command[windows_updates]=c:\\windows\\system32\\cscript.exe //NoLogo //T:120 c:\\check_windows_updates.wsf /w:0 /c:1
;# RESTE du blabla pour que vous situiez l'endroit
;# COMMAND DEFINITIONS
;# Command definitions that this daemon will run.
;# Can be either NRPE syntax:
;command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10

Attention aux doubles backslashs/slashs etc.
Rechargez le service NSClient++.
Je suppose que le port par défaut (5666) est accessible depuis NAgios vers votre serveur.

Conf Nagios pour patchs Windows

Si tous vos serveurs Windows sont équipés du script et que la conf NRPE dans NSClient++ est bonne pour chacun, vous pouvez ajouter quelque part dans /etc/nagios3/conf.d/ ce bout de code :

define service{
        hostgroup_name          windows-servers
        use                     generic-service
        service_description     Windows Update
        check_command           check_nrpe_1arg!windows_updates
}

Si vous n'avez qu'une machine (pour tester), pensez à utiliser host_name toto au lieu de hostgroup_name.

Ensuite, on va définir un test Nagios qui appelle la commande "windows_updates" via NRPE. Le nom windows_updates est bien celui reprit dans la conf NSC.ini, section [NRPE Handlers].
Après quelques tests, j'ai dû recréer mon propre passage d'argument à check_nrpe, script qui d'ailleurs vient normalement avec les plugins de Nagios. Voyez :

monnagios:/etc/nagios-plugins/config# cat check_nrpe.cfg
# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
#JACQUES
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -t 60
        #command_line   /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Notamment en ajoutant un timeout (-t) plus long et en supprimant le 2è argument.
Comme d'habitude, pour inventer cela, il faut jouer avec la commande /usr/lib/nagios/plugins/check_nrpe directement. Et commencer par jouer localement avec le script .wsf (sur la machine Windows, donc), histoire de vérifier que tout va bien et de débugger pas à pas votre bazar (script mal placé, NRPE mal configuré, Nagios mal paramétré pour ce test etc).

Voilà, normalement ce test fonctionne aussi.

Trucs en vrac

Par manque de temps et impossibilité de faire un guide "complet", je note 2/3 idées en vrac :

Attention après un /etc/init.d/nagios3 reload : temps de latence (tests en pending) et lorsqu'un test échoue, il est replanifié pour X minutes plus tard. On peut forcer sa réexécution, mais il faut y aller mollo et ne pas être trop impatient.

Il reste tant à dire : la dépendance entre services, la carte des machines, les prévisions de downtime de machines (pour éviter les mails et alertes inutiles), la fréquence des tests.
Mais là, maintenant que vous avez la base, vous allez pouvoir facilement lire n'importe quelle doc (je veux dire, même celles où très peu de choses sont expliquées) pour peaufiner votre installation. J'espère.

A+

(enfin c'est publié, youhou.... ; j'espère que le tout reste cohérent et utile vu que ça a été écrit en plein de fois et à différents moments de mon apprentissage Nagios)

MAIS : rien pour valider les inscriptions. Soit on les ferme, soit on demande confirmation de l’expéditeur (il reçoit un mail avec son pass et confirme). Pas d’intermédiaire.

Résultat : des robots un peu partout qui s’inscrivent. Aucun message derrière, ptet juste pour garder un compte pour le jour où telle faille est publiée. Je ne sais pas.
Bon bref, en suivant ce qui est expliqué là, vous ajouterez sans mal une question lors de l’inscription. Question si possible assez balaise pour qu’un robot ne sache pas y répondre.

EDIT : il y avait des balises php, interprétées… :
Modifiez donc le fichier “register.php” comme indiqué dans ce fichier (ou sur le site).

Pense-bête : j’ai un gros .tar sur un serveur, je dois l’extraire sur un autre serveur. MAIS, sur cet autre serveur, je n’ai pas la place pour récupérer le .tar puis le décompresser, c’est-à-dire stocker deux fois en terme d’espace.
Donc j’utilise netcat pour faire un “pipe” entre commande d’une machine à l’autre.

Une fois le programme netcat installé, peu importe par quel biais, et en considérant que vous n’avez pas de restriction réseau entre les 2 machines (sinon ouvrez le port ci-dessous en UDP), vous faites ceci :

Sur la machine cible, on prépare une socket en écoute, ici sur le port 12345 :

moi@destination:/ou/je/veux/ecrire$ netcat -l -p 12345 | tar xvf -

Sur la machine émettrice, on balance la purée dans le tuyau :

moi2@source:~$ cat monfichier.tar | netcat aladdin 12345

A adapter dans le cas d’un fichier .bz2 ou .gz, par exemple.

Recopie d’arborescence d’un serveur à l’autre

Une autre utilisation très courante est la suivante : recopier une arborescence d’un serveur à l’autre, sans utiliser rsync, scp etc. Pourquoi se passer de ces outils ? il y a des cas où on ne les a pas. Et puis là on évite le cryptage, tout ça, charge CPU, blablabla.
Ca donne :

dest$ nc -l p 12345 | tar x

src$ tar cvf - mon_arborescence | nc dest 12345

EDIT : truc bien crade : ça marche aussi pour injecter du SQL…

dest$ nc -l p 12345 | mysql -u monlogin -p

src$ cat test.sql | nc dest 12345

Attention à ce que vous faites là quand même.
Notez qu’au lancement de la commande sur la machine de destination, le mot de passe mysql est demandé tout de suite.

Voilà
A+

Toujours à mon habitude, j’essaye d’utiliser ce qu’a fait Debian pour moi. Point de compilation, de création de machin-bidule à la main lorsque ce n’est pas une absolue nécessité.

Pour le contexte, on va dire que le VPN va être installé sur une machine de type passerelle Internet-LAN. Pourquoi pas une Debian avec shorewall et 2 pattes : loc, net (et $FW of course). Je parlerai rapidement des modifications de firewall à la fin. Vous pouvez trouver une introduction à shorewall sur ma doc d’initiation à Debian.

Je vais développer en 3 parties : thèse, anti-thèse, foutaises, comme disait mon prof de philo au siècle dernier installation, paramétrage du serveur, paramétrage du client, firewalling. Ca fait 4 ? bien, au moins y’en a qui suivent.

Let’s go.

Installation de l’outil

Ca devient presque rasoir, on commence direct dans le feu de l’action :

aptitude install openvpn

Par dépendances, SSL descend. Enfin bon, si sur cette machine vous n’avez pas SSH, donc openssl, je serais étonné.
Je n’ai pas pris de notes, mais je pense qu’à ce niveau là déjà, une interface réseau “tun0″ est créée. Le futur sous-réseau du VPN est 10.0.8.x. Le serveur n’est pas lancé car il n’a aucune conf. Ca veut dire /etc/openvpn/ vide ou pas loin. Et c’est tant mieux.

Paramétrage serveur

Rappel : permissions

On va jouer avec les clefs cryptées et les clefs publiques d’un outil donnant accès à l’intérieur de votre réseau. Faites un peu attention aux permissions des fichiers.

Clef privée = permission limitée au niveau de l’OS, root:root + chmod 600
Clef publique = root:root + chmod 644
Ce qui ne concerne que le service et son lancement = root:root + chmod 640

Notez que le service openvpn sera lancé par root même s’il tournera au nom d’un utilisateur “openvpn”.

Traditionnellement, les clefs privées ont un nom en .key, les certificats publics en .crt.
Notez bien les permissions de votre conf OpenVPN lorsqu’on l’aura monté et gardez ça à l’esprit tout le long :

serveur:/etc/openvpn# ls -l
total 40
-rw-r--r-- 1 root root  1176 2009-09-14 14:46 ca.crt
-rw------- 1 root root   245 2009-09-14 14:47 dh1024.pem
-rw------- 1 root root    16 2009-09-23 08:23 ipp.txt
-rw------- 1 root root   232 2009-09-23 08:32 openvpn-status.log
-rw-r----- 1 root root 10560 2009-09-22 17:02 server.conf
-rwxr-xr-x 1 root root  1352 2008-09-18 00:33 update-resolv-conf
-rw-r--r-- 1 root root  3813 2009-09-14 14:46 vpnserveur.crt
-rw------- 1 root root   887 2009-09-14 14:46 vpnserveur.key

En résumé, seules la clef publique de l’autorité de certification et la clef publique du serveur doivent être publiques.

Présentation rapide de easy-rsa

“easy-rsa” est un ensemble de scripts simplifiant votre vie pour gérer les certificats. Que ce soient ceux du serveur pour créer sa configuration ou ceux de vos postes clients.
Vous savez aussi sans doute qu’il vous faudra gérer votre base de certificats autorisés (et surtout révoqués). Lorsque le portable de votre collègue est oublié dans le train, il est intéressant d’être mis au courant dans la seconde pour révoquer le certificat en question. Sinon c’est la porte d’entrée dans l’entreprise, suivant le profil du voleur type qui a trouvé le portable.
Cet outil descend avec OpenVPN et l’ensemble des scripts se situe dans /usr/share/doc/openvpn/examples/easy-rsa/2.0/. Il y a une version 1.0. J’ai opté pour la 2.0. Je ne me suis pas trop documenté sur le sujet.

Il y a un tout petit peu de paramétrage à faire sur easy-rsa.
Je recommande de dupliquer le fichier /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars en /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars.maconf et de travailler dedans.
Je vous montre un “diff” entre le fichier d’origine et le mien. C’est le minimum syndical à renseigner :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# diff -h vars vars.maconf
64,68c64,68
< export KEY_COUNTRY="US"
< export KEY_PROVINCE="CA"
< export KEY_CITY="SanFrancisco"
< export KEY_ORG="Fort-Funston"
< export KEY_EMAIL="me@myhost.mydomain"
---
> export KEY_COUNTRY="FR"
> export KEY_PROVINCE="France"
> export KEY_CITY="Petaouana"
> export KEY_ORG="MaBoite"
> export KEY_EMAIL="adminvpn@maboite.fr"

Notez : pour utiliser les scripts Easy-RSA, il faut à chaque fois positionner les variables d’environnement du fichier vars.maconf. Donc, à chaque nouvelle session dans laquelle vous jouez avec les scripts easy-rsa, il faudra commencer par la commande suivante :

. /usr/share/doc/openvpn/examples/easy-rsa/2.0/vars.maconf #sans oublier le point au début !!!

.

Le répertoire où sont stockées les clefs générées (et d’autres choses, liste de certificats, certificats révoqués etc) est le sous-répertoire keys/. Inutile de préciser (?) que ce répertoire doit être archi-protégé :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ls -ld keys
drwx------ 2 root root 4096 2009-09-14 18:22 keys

Enfin, la première fois uniquement (ou tant que vous testez), vous pouvez nettoyer ce répertoire via la commande ./clean-all.

Création de l’autorité de certification

Maintenant que vos “variables” sont prêtes et chargées dans votre session, on attaque.
Bien évidemment, cette manip n’est à faire qu’une fois. Seule la manip de création de certificats pour vos clients (postes clients) sont à faire X fois.
L’autorité de certification est “un nom et des clefs” signant vos certificats. Un exemple connu est Verisign. Ici, on va signer nous-même. Sur un serveur web, ça ferait des warnings de certificats bidouilleux, ici on s’en fout.

./build-ca

Vous obtenez le baratin standard de génération de clefs, lisez ce qui y est dit et renseignez le “Common Name”. Le reste doit descendre du fait du fichier “vars” chargé au préalable. Pour “Common Name”, mettez le nom de votre serveur.

Création de la clef Diffie-Hellman

La clef Diffie-Hellman est une clef permettant au client et au serveur de s’entendre sur une clef secrète pour crypter la conversation.
Si je me souviens bien, les clefs publiques/privées servent à l’initialisation de la communication, mais, étant lourdes en calculs, on opte pour un cryptage plus simple pour le reste de la communication. C’est la clef DH. En gros hein. Et pardon aux puristes. Ou dites moi si je me trompe complètement.

On la génère comme suit, grâce aux script Easy-RSA :

./build-dh

Rien à saisir, ça prend juste un peu de temps.

Génération du certificat serveur

On continue, pour le dernier élément du serveur : sa propre clef.

./build-key-server

(trop cool les scripts Easy-RSA non ?)
Ca sort aussi le baratin standard de génération de clefs. Vous devrez préciser le “Common Name”, éventuellement un mot de passe (je ne l’ai pas fait, je suppose qu’il demanderait du coup un mot de passe au lancement du service openvpn ; ça peut être contraignant lors de reboot).
Par défaut, votre certificat sera valable 10 ans.
Ca termine par l’inscription du certificat dans la “base” :

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Création des certificats d’un client

Rappel : lorsque plus tard, vous créerez un autre certificat pour un autre PC, pensez à “sourcer” le fichier vars.maconf.
Le script de génération se lance comme suit :

./build-key pc123

Je suggère un nom éloquent rappelant ou bien le PC, ou bien la personne.
Là non plus, rien de sorcier : le “Common Name” sera le nom du PC et vous “committez” le certificat.

Création des certificats d’un client avec mot de passe

Tout pareil que le paragraphe du dessus, mais le script est ./build-key-pass pc123
Il faudra alors renseigner le mot de passe là :

Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

Rien à voir avec le “Challenge password” demandé plus tard.

La révocation de certificats

Si à ce niveau là de la configuration on n’a pas besoin de révoquer des certificats, ça deviendra obligatoire à mesure que les utilisateurs arriveront, partiront et perdront leur PC portables. Evidemment que c’est du vécu
La commande Easy-RSA est :

./revoke-full pc123

Il faut copier le fichier résultant, après chaque révocation :

cp keys/crl.pem /etc/openvpn/

Ce fichier est lu dès l’instant que vous avez mis en place l’option “crl-verify” dans votre fichier de conf serveur (voir plus haut).
Notez aussi qu’il est relu à chaque tentative de connexion. Pas besoin de recharger OpenVPN après une révocation. Juste de recopier le fichier à jour. Si vous pensez faire un lien symbolique, attention aux permissions (c’est l’utilisateur openvpn qui fait tourner openvpn). Je n’ai pas testé la solution par lien symbolique.

Vous pourrez consulter la liste des certificats révoqués grâce à la commande :

openssl crl -in /chemin/vers/keys/crl.pem -text

CRL = Certificate Revocation List

Lancement du service

A ce niveau là, on a généré tout ce qu’il faut, mais le service ne tourne pas.
Le contenu de votre sous-répertoire keys ressemble à ça :

serveur:/usr/share/doc/openvpn/examples/easy-rsa/2.0# ls -l keys/
total 80
-rw-r--r-- 1 root root  3813 2009-09-14 14:06 01.pem
-rw-r--r-- 1 root root  3698 2009-09-14 14:29 02.pem
-rw-r--r-- 1 root root  1176 2009-09-14 14:03 ca.crt
-rw------- 1 root root   887 2009-09-14 14:03 ca.key
-rw-r--r-- 1 root root  3698 2009-09-14 14:29 client_test.crt
-rw-r--r-- 1 root root   668 2009-09-14 14:29 client_test.csr
-rw------- 1 root root   887 2009-09-14 14:29 client_test.key
-rw-r--r-- 1 root root   245 2009-09-14 14:32 dh1024.pem
-rw-r--r-- 1 root root   205 2009-09-14 14:29 index.txt
-rw-r--r-- 1 root root    20 2009-09-14 14:29 index.txt.attr
-rw-r--r-- 1 root root    21 2009-09-14 14:06 index.txt.attr.old
-rw-r--r-- 1 root root   101 2009-09-14 14:06 index.txt.old
-rw-r--r-- 1 root root     3 2009-09-14 14:29 serial
-rw-r--r-- 1 root root     3 2009-09-14 14:06 serial.old
-rw-r--r-- 1 root root  3813 2009-09-14 14:06 vpnserveur.crt
-rw-r--r-- 1 root root   664 2009-09-14 14:05 vpnserveur.csr
-rw------- 1 root root   887 2009-09-14 14:05 vpnserveur.key

On y retrouve les clefs de l’autorité de certification (ca*), le certificat serveur (vpnserveur.crt et vpnserveur.key) et un futur poste client (client*.[crt|key]). Les fichiers .csr sont les demandes de signatures, étape intermédiaire de la création des certificats, masquée par l’enrobage de commandes d’Easy-RSA. Inutile par la suite
Il faut recopier (avec les bonnes permissions !!!) les fichiers suivants :

cp -p dh1024.pem vpnser*crt vpnser*key ca* /etc/openvpn

Ensuite, on va faire tourner le service sous un utilisateur/groupe sans droit, c’est mieux côté sécurité.

groupadd openvpn
useradd -d /dev/null -g openvpn -s /bin/false openvpn

Enfin, il faut créer le fichier de conf du serveur. Un exemple est donné dans le fichier /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz. Une fois dézippé et mis dans /etc/openvpn, on l’adapte.
Voici son contenu, sans les commentaires :

serveur:/etc/openvpn# egrep -v "^$|^#|^;" server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert vpnserveur.crt
key vpnserveur.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.X.0 255.255.255.0"
push "dhcp-option DNS 192.168.X.Y"
push "dhcp-option DOMAIN maboite.net"
push "dhcp-option WINS 192.168.X.Y"
keepalive 10 120
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status openvpn-status.log
verb 3
;crl-verify crl.pem # j'ai triché, j'ai ajouté le ";" il n'aurait pas dû sortir vu la commande egrep passée. Voir ci-dessous.

Les 4 paramètres push route et push dhcp-option sont à adapter. Ce sont eux qui feront ajouter à votre PC client les règles de routages et DNS, domaine (et optionnellement WINS) à utiliser. Sinon, point de résolution de nom, point de routage depuis votre PC, tantôt vers sa connexion web, tantôt vers le VPN.
Suivant la configuration de votre passerelle, le simple ajout de ces push ne sera pas suffisant pour permettre à vos postes client VPN de rebondir de votre passerelle vers le LAN. Voir plus bas le chapitre dédié.
Enfin, le paramètre “crl-verify” prendra son importance avec les révocations de certificats (voir plus bas).Pour l’instant, il est en commentaire car j’ai noté que OpenVPN plantait (volontairement ?) lorsqu’on lui dit de tenir compte d’une liste de révocation et que cette liste n’existe pas, ou est un fichier vide. Ce sera donc à activer plus tard, après votre première révocation.

Ah, j’oubliais :

/etc/init.d/openvpn start

Vérifiez dans les logs que tout va bien. Et ifconfig qui doit avoir affecté une IP à tun0, probablement 10.8.0.1.

Paramétrage client (poste Windows dans mon cas)

On a généré un premier ensembles de clefs d’un poste client.
Dans le cas d’un PC sous Windows (cas à mon avis le plus courant lorsqu’il s’agit de fourni des portables d’appoint à des utilisateurs distants), installez OpenVPN avec le GUI.
Injectez (par un moyen sûr, éviter d’envoyer la clef cryptée par mail à votre destinataire) les fichiers suivants dans le répertoire C:\Program Files\OpenVPN\config :

ca.crt # et pas le .key !!!
client_test.key
client_test.crt

Puis créez un fichier de configuration client nommé nimportequoi.ovpn dans le même sous-répertoire config. Il contiendra la conf suivante, si on oublie les commentaires :

client
dev tun
proto udp
remote votre.serveur.vpn.votresociete.fr 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client_test.crt
key client_test.key
comp-lzo
verb 3

Enfin, lancez le GUI d’OpenVPN situé dans le sous-répertoire bin/ d’OpenVPN, bouton droit dans le “system tray” sur l’icône qui vient d’apparaitre, menu “Connect” et lisez ce qui passe pour commencer à débugger s’il y a un hic niveau réseau entre le PC portable et le serveur VPN. Attention à vos règles de firewalling en vigueur, que vous testiez de l’extérieur ou de l’intérieur (ce qui semble un peu stupide), vous pourriez ne pas être en mesure d’atteindre le service, d’où le chapitre ci-dessous.

Considérations de firewalling

Bon là, c’est bien beau, vous atteignez votre serveur VPN depuis l’extérieur, et encore, si vous avez bien ouvert la porte d’entrée vers le port UDP 1194 de votre serveur.
Mais pour l’instant, point de rebond vers le LAN. Et heureusement que ça ne marche pas par défaut.

Méthode gore pour tester vite fait

En activant l’IP Forwarding à la main et en définissant quelques routes entre votre réseau VPN et votre LAN, vous obtiendrez vite fait un résultat. Mais c’est pas terrible je trouve.
Activation de l’IP Forwarding comme un cochon :

echo 1 > /proc/sys/net/ipv4/ip_forward

Puis définition de routes. Plutôt que de donner un exemple qui ne sera pas le votre, tâchez plutôt de raisonner sur la liste des routes que vous avez et ajoutez celles qu’il faut, avec les commandes route, route add et route delete.

Méthode réfléchie pour shorewall

Si vous utilisez iptables, je ne peux rien pour vous. Enfin si, un conseil : songez à utiliser shorewall.
Si vous ne connaissez rien à shorewall, c’est le moment de vous y mettre. Mais dans ce cas, faites vous la main *avant* d’installer le VPN, quand même. Voyez ma doc Debian au besoin, il y a un chapitre consacré à shorewall.
Sinon, dans une conf shorewall à 2 pattes (net, loc), on la modifie pour qu’elle passe à 3 pattes. Dans un cas idéal (mais néanmoins courant), ça se passera comme ça :

• Ajout de la ligne vpn ipv4 dans /etc/shorewall/zones.
• Ajout de la ligne vpn tun0 detect dans /etc/shorewall/interfaces
• Ajout de la ligne eth0 tun0 dans /etc/shorewall/masq pour activer le Masquerading entre votre VPN et votre LAN, ici situé sur l’interface eth0
• Ajout de toutes les règles par défaut dans /etc/shorewall/policy, concernant la probable interdiction par défaut d’aller de n’importe quelle zone vers le VPN et réciproquement. Le VPN doit en effet, à mon avis, être un moyen de secours pour donner accès à quelques services internes, pas à tout le LAN. A base de vpn loc REJECT info + réciproque.
• Enfin, le vrai travail, l’ouverture du minimum d’autorisation entre toutes vos zones et le VPN. J’y consacre le paragraphe suivant.

Ouvertures minimum sur le firewall

En considérant net=eth1 ; loc=eth0 et vpn=tun0, voici ce qu’il faudra ajouter au minimum, à mon avis :
Déjà l’accessibilité du service VPN depuis le NET :

ACCEPT          net     $FW         udp     openvpn

Ensuite des règles du VPN vers le LAN :

ACCEPT          vpn     loc:$dns1      tcp     domain # sinon on ne touche pas le serveur DNS => pas de résol de nom => problème...
ACCEPT          vpn     loc:$dns1      udp     domain # je ne sais pas s'il faut le TCP ou l'UDP. Oops.
Ping/ACCEPT     vpn     loc # pratique pour du dépannage
ACCEPT          vpn     loc:$leserveurapplicatif1 # c'est un exemple
ACCEPT          vpn     loc:$leserveurapplicatif2 tcp 80 # un exemple plus restreint, limité au port http

Les variables “$dns1″ (par exemple), sont à définir dans /etc/shorewall/params, ou alors vous tapez l’IP en dur.

Et enfin quelques accès minimums vers la passerelle elle-même :

Ping/ACCEPT     $FW     vpn # pratique pour les tests
SSH/ACCEPT      vpn     $FW # pour les admins tout au moins ?
ACCEPT          vpn     $FW     tcp     80 # s'il y a des intranets à consulter (outil de supervision, par exemple)

A noter aussi, pour le Masquerading, de forcer l’activer (valeur “On”) ou de laisser tel quel (valeur “Keep”) l’IP forwarding. Ca se passe dans /etc/shorewall/shorewall.conf, paramètre IP_FORWARDING.
Il me semble que c’est ce paramètre qui force ou pas la modification du paramètre noyau /proc/sys/net/ipv4/ip_forward. Il me semble.

Voilà. Ca devrait marcher.
Evidemment, comme c’est fortement lié à toute votre infrastructure réseau, tout ce qui précède est plutôt un guide des trucs-à-pas-oublier-pour-que-ça-marche.

Divers

Ce que je n’ai pas abordé

• Testez avant de déployez !!!! notamment les certificats révoqués, et avec eux la CRL et l’option crl-verify.
• Il y a une notion de règles de routages paramétrables par certificat client. Ca peut être utile.
• Vous utilisez Orange Business Everywhere pour votre clef 3G ? attention, ça semble intercaler un proxy sur votre Internet Explorer. Résultat, l’accès à des Intranets via le VPN ne marchait pas. Firefox passait bien. Je n’ai pas creusé plus pour l’instant.

Comportement lors d’une connexion avec un certificat révoqué

Côté serveur, on voit cette discrète ligne dans /var/log/syslog :

Sep 23 11:57:49 gw ovpn-server[24224]: 192.X.Y.Z:1120 CRL CHECK FAILED: /C=FR/ST=France/L=Petaouana/O=SOCIETE/CN=pctest/emailAddress=adminvpn@chezmoi.fr is REVOKED

Côté client, c’est moins flagrant, on tourne en rond et tente de se reconnecter.
Peut-être qu’en montant le niveau de verbosité (paramètre verb), on en saurait plus. Mais à la limite, ça intéresse qui ? (à part l’utilisateur qui s’est fait révoquer son certificat par erreur).

Ce type d’installation peut tout à fait convenir pour des petites et moyennes entreprises (quelques centaines de personnes), sur un serveur moyennement puissant. Pour faire simple.

Encore une doc sur ce sujet ?

Oui on s’excuse, mais comme d’habitude avec Debian, tout est déjà prêt à fonctionner et pourtant, on trouve généralement des docs de personnes mettant en place l’outil en recompilant les sources, en prenant des fichiers de conf à droite à gauche, en démolissant le beau travail déjà accompli par les packageurs Debian.
Mon approche reste la même : Debian a fait le boulot pour moi, j’en profite.
Au final, cet article est simplement brodée autour du README.Debian de chaque paquet qu’on va installer (surtout amavisd-new) et de quelques autres docs glanées sur le web expliquant tel ou tel paramètre, un peu plus que la doc officielle.
Mais comme rares sont les gens qui lisent les README, mon article devrait quand même intéresser quelques lecteurs, je l’espère.

Ce dont je ne parle pas

Je ne parle pas de l’aspect lecture des mails (en POP, en IMAP, renvoi vers un autre backend (Exchange ?)), mais juste au nettoyage et au blocage amont des spams et virus.
Je pars d’ailleurs d’une machine avec un postfix minimaliste sachant envoyer et recevoir des mails.
Vous pouvez vous reporter à ma doc Debian pour ce cas là, elle décrit en plus de postfix :
- la mise en place de postgrey (voyez l’intérêt ici)
- la mise en place de quelques blocages par blacklists (RBL & co)
- procmail
Je ne parle pas non plus du montage d’un backup MX. Probablement lors d’un prochain article.

Enfin, je colle tous les éléments de ce serveur sur une unique machine physique. Vous pourriez séparer les éléments. A ce moment-là, un peu de raisonnement et une lecture des documentations officielles que je cite me paraît judicieux. Cet article se limiterait alors,pour vous, à comprendre le rôle de chaque morceau, à appréhender la configuration de base et à partir du coup dans la bonne direction.

Comme à mon habitude, je décris aussi quelques bêtises et oublis que j’ai pû rencontrer, ça aidera à débugger et ça explique des choses.

Pré-requis

Etre sur une Debian stable (Lenny) avec le dépôt Debian “volatile” opérationnel (pour les mises à jour de clamav).
Le dépôt “volatile”, c’est ça :

moi@srv:~$ cat /etc/apt/sources.list | grep vola
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free

C’est un dépôt créé pour palier aux problèmes des applications mises à jour constamment (les bases anti-virus par exemple, tout autant que des outils de mssageries instantanées qui voient les protocoles sous-jascents évoluer régulièrement). Si on restait sur le rythme Debian (tous les 2 ans ; bientôt 6 mois), on aurait des applications inutiles.

Rôle de chaque élément

D’abord le schéma qui va bien :

Cheminement du mail

1. Postfix reçoit donc la connexion d’un serveur voulant envoyer un mail.
2. Grâce à postgrey, il va filtrer déjà un bon paquet de spams qui n’atteindra pas la suite des composants (et donc pas de charge réseau/cpu inutile).
3. Donc au besoin, le mail revient plus tard, suite à greylisting.
4. Postfix passe le relai à amavisd-new qui orchestre les appels à :
5. ClamAV qui fait ce qu’il a à faire
6. et à spamassassin, lui-même gérant pyzor/razor
7. Retour du mail nettoyé (disons, avec les en-têtes qui vont bien) vesr postfix
8. Postfix livre le mail (dans la boîte de l’utilisateur, au backend, à je ne sais quel autre élément en aval.

Doc officielle, doc complémentaire

Lire /usr/share/doc/amavisd-new/README.postfix.gz est un passage obligé, je trouve. Je me base dessus et je fais certains choix qui pourraient ne pas être les votres. Je n’invente pas grand chose, tout est quasiment dedans.
Si vous êtes sur une installation déjà en production, vous pourriez être intéressés par le paramètre soft_bounce, voyez ici via un :
postfix -e "soft_bounce = yes"

Autre doc intéressante : http://www200.pair.com/mecham/spam/spamfilter20090215.html. A noter : l’auteur n’utilise pas trop le boulot de Debian, donc beaucoup de choses à reparamétrer dans son cas, sans compter les manips à la main : récupérer le fichier de conf X, prendre tel binaire postfix plutôt que celui de la distrib. Bref, pas très Debian-style à mon goût.
Mais au moins il donne une bonne explication de certains paramètres, à vous de voir.
Enfin, cette doc décrit le montage complet d’une Debian, installation, serveur DNS etc. On s’en fout pas mal dans le cas présent. Commencez donc à lire cette doc à partir du mot “postfix anti-spam settings:”. A peu près au milieu.
Vous verrez passer dans les chapitres qui suivent cet endroit quelques paramètres importants sur le comportement des différents outils, les destinataires des notifications de mails vérolés etc, quelques optimisations sur les niveaux de spam acceptables etc. Mon article reprend certaines de ces suggestions et de ma propre expérience.
Cette doc va aussi plus loin : installation de DCC (Distributed Checksum Clearinghouses) et des outils de statistiques. Je n’en parle pas (pour l’instant), on verra avec des articles ultérieurs.

Bon, allez, on installe tout ça.

Installation des logiciels

aptitude install clamav clamav-daemon clamav-freshclam
aptitude install amavisd-new
aptitude install lha arj rar unrar nomarch lzop cabextract razor pyzor p7zip-full pax zip unzip lha zoo

Certains des paquets ici sont discutables, pour les pros du ça-pue-c-est-pas-libre-(tm). Moi je veux simplement analyser un maximum de contenu de mails, pièces jointes en format moins courants y compris.
Les outils type “décompression” serviront à ClamAV pour analyser les contenus de pièces jointes.

Les parties postfix, postgrey, spamassassin et les Maildir sont déjà expliqués dans mes docs/blog à différents endroits.
Deux nuances tout de même :
Je suppose enfin que votre spamassassin est en mode daemon (donc “spamd” tourne) car vous avez mis à 1 le paramètre ENABLED dans /etc/default/spamassassin.
Par rapport à ce que j’explique sur procmail, j’ai opté pour une conf standard pour tous dans /etc/procmailrc plutôt que dans chaque ~/.procmailrc.

Paramétrage de base

Configuration postfix <=> amavis

D’abord, on configure un canal de communication postfix => amavis en mode SMTP et pas LMTP (voir le /usr/share/doc/amavisd-new/README.postfix.gz). J’ajoute à la fin de /etc/postfix/master.cf des lignes suivantes :

amavisfeed unix    -       -       n       -       2     smtp
     -o smtp_data_done_timeout=1200
     -o smtp_send_xforward_command=yes
     -o smtp_tls_note_starttls_offer=no

Le nom “amavisfeed” est libre. Mais c’est le nom du tuyau que vous venez de créer. Il faudra utiliser ce nom plus bas (dans main.cf)

Puis le canal retour (message reinjection), toujours à la fin de /etc/postfix/master.cf :

127.0.0.1:10025 inet n    -       n       -       -     smtpd
     -o content_filter=
     -o smtpd_delay_reject=no
     -o smtpd_client_restrictions=permit_mynetworks,reject
     -o smtpd_helo_restrictions=
     -o smtpd_sender_restrictions=
     -o smtpd_recipient_restrictions=permit_mynetworks,reject
     -o smtpd_data_restrictions=reject_unauth_pipelining
     -o smtpd_end_of_data_restrictions=
     -o smtpd_restriction_classes=
     -o mynetworks=127.0.0.0/8
     -o smtpd_error_sleep_time=0
     -o smtpd_soft_error_limit=1001
     -o smtpd_hard_error_limit=1000
     -o smtpd_client_connection_count_limit=0
     -o smtpd_client_connection_rate_limit=0
     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
     -o local_header_rewrite_clients=
     -o smtpd_milters=
     -o local_recipient_maps=
     -o relay_recipient_maps=

Enfin, on active le tuyau postfix => amavisd-new pour permettre l’analyse : (pas de tri, on balance tout ; on pourrait restreindre par domaine, adresse émettrice etc). C’est dans /etc/postfix/main.cf :

content_filter=amavisfeed:[127.0.0.1]:10024

Dans cette configuration par défaut, il faut que les ports 10024 et 10025 (localement) soient libres. Les paramètres sont décrits dans la doc en .gz mentionnée ci-dessus. L’idée, en gros, est de créer un autre serveur SMTP, local uniquement sur le port 10024, avec une conf postfix indépendante et vierge – en gros – car on sait que les messages arrivant là seront passés par amavis, donc ils seront propres/nettoyés. Cette seconde instance postfix sera la porte d’entrée pour les retours d’amavisd-new.

Tests des briques de la communication postfix <=> amavisd-new

Là, on peut tenter un /etc/init.d/postfix reload.

Ecoute de amavis

Le 10024 répondait déjà (car c’est le port d’écoute de amavis, lancé depuis qu’on l’a installé) :

# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready

Ecoute du 2è postfix (la voie de retour d’amavis)

Le port 10025 ne fonctionne qu’après la conf dans master.cf et un postfix reload :

# telnet localhost 10025
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 srv.net ESMTP Postfix (Debian/GNU)

Tests des décodeurs de pièces jointes

On peut voir les “décodeurs” qu’il manque dans /var/log/mail.log.

/var/log/mail.log:Aug 25 17:18:21 srv amavis[28164]: No decoder for       .lha

Dans le cas ci-dessus, on peut conclure que le paquet lha n’est pas installé.
Attention, la doc dit quelque part de se méfier des décodeurs pour analyse des TNEF. Vous risquez de perdre les mails écrits en RTF par Outlook-le-casse-couipied.

Test du retour de mails

On teste un envoi de mail à amavis, et donc le retour :

# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready
helo localhost
250 [127.0.0.1]
mail from: <>
250 2.1.0 Sender <> OK
rcpt to:

250 2.1.5 Recipient
 OK
data
354 End data with .
From: virus-tester
To: undisclosed-recipients:;
Subject: amavisd test - simple - no spam test pattern

 This is a simple test message from the amavisd-new test-messages.
.
250 2.0.0 Ok, id=28165-03, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 5FD7D9C4057
quit
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel
Connection closed by foreign host.

Résultats dans /var/log/mail.log (le retour à postfix prend quelques secondes) :

# tail /var/log/mail.log
Aug 27 11:37:43 srv postfix/smtpd[681]: connect from localhost.localdomain[127.0.0.1]
Aug 27 11:37:43 srv postfix/smtpd[681]: 5FD7D9C4057: client=localhost.localdomain[127.0.0.1]
Aug 27 11:37:43 srv postfix/cleanup[683]: 5FD7D9C4057: message-id=<20090827093743.5FD7D9C4057@srv.net>
Aug 27 11:37:43 srv postfix/qmgr[30259]: 5FD7D9C4057: from=<>, size=724, nrcpt=1 (queue active)
Aug 27 11:37:43 srv amavis[28165]: (28165-03) Passed BAD-HEADER, <> ->
, quarantine: 5/badh-5kHJ7I-xUr2T, mail_id: 5kHJ7I-xUr2T, Hits: -, size: 175, queued_as: 5FD7D9C4057, 81992 ms
Aug 27 11:38:39 srv postfix/local[684]: 5FD7D9C4057: to=, orig_to=
, relay=local, delay=56, delays=0.14/0/0/56, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION")
Aug 27 11:38:39 srv postfix/qmgr[30259]: 5FD7D9C4057: removed

Activation de l’appel amavisd-new <=> ClamAV+Spamassassin

Enlevez les commentaires, c’est tout

C’est expliqué ici : /usr/share/doc/amavisd-new/README.Debian.
Comme d’hab, les fichiers de conf pré-machés par Debian sont très bien et attention à ne pas tenir trop compte de documentation de bidouilleurs qui paramètrent tout ça à la sauce pas-très-Debian.
D’après le README cité ci-dessus, la conf s’active dans /etc/amavis/conf.d/15-content_filter_mode. Il suffit de décommenter les 4 lignes suivantes dans /etc/amavis/conf.d/15-content_filter_mode : (2 pour ClamAV, 2 pour spamassassin)

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

En faisant celà, on active la conf définie dans les autres fichiers de /etc/amavis/conf.d/, exemple 15-av_scanners pour les anti-virus. Il s’agit là aussi de modèle de configuration standard de tout un tas d’outils connus (une bonne 15aine d’anti-virus dont NOD32, F-Prot, Grisoft, KAV, du symantec etc). Amavisd-new va donc charger les AV qu’il trouve. De même pour spamassassin.

Petit oubli pour ClamAV

On se paye une erreur :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

L’utilisateur clamav doit être dans le groupe amavis, on fait ce qui est dit dans le README.Debian de amavisd-new :

# adduser clamav amavis
Ajout de l'utilisateur « clamav » au groupe « amavis »...
Ajout de l'utilisateur clamav au groupe amavis
Terminé.

Et on contrôle le paramètre suivant dans la conf ClamAV : AllowSupplementaryGroups true. C’est déjà positionné dans le /etc/clamav/clamd.conf fraîchement dépaqueté. Vérifiez tout de même.
Et on redémarre ClamAV évidemment.

On peaufine certains paramètres

Destinataires des alertes

Pensez à bien ajuster les destinataires de “abuse”, “postmaster” et “root” de votre serveur. Soit en modifiant les variables comme :

$virus_admin
$banned_admin
$mailfrom_notify_admin OU recip OU spamadmin
$hdrfrom_notify_sender

Soit en étant sûr que ces comptes par défaut (et obligatoires, surtout postmaster) font bien suivre les mails vers une adresse que vous lisez/survolez.

Voyez la doc mentionnée plus haut pour des suggestions à propos des variables $virus_admin & co.

Resctrictions de base de postfix

Je n’en parle pas trop, mais pensez à la conf de base de postfix, notamment votre paramètre smtpd_sender_restrictions dans /etc/postfix/main.cf.
Utilisez un service web quelconque sur Google pour valider que votre serveur n’est pas un open-relay.

Pièces jointes

Dans /etc/amavis/conf.d/20-debian_defaults, je suggère d’élargir la liste des pièces jointes interdites (par extension). Plus besoin de sanitizer, c’est intégré dans amavisd-new. Exemple :

### JACQUES
#  qr'.\.(exe|vbs|pif|scr|bat|cmd|com|cpl)$'i, # banned extension - basic
 qr'.\.(ade|adp|app|bas|bat|chm|cmd|com|cpl|crt|emf|exe|fxp|grp|hlp|hta|
        inf|ins|isp|js|jse|lnk|mda|mdb|mde|mdw|mdt|mdz|msc|msi|msp|mst|
        ops|pcd|pif|prg|reg|scr|sct|shb|shs|vb|vbe|vbs|
        wmf|wsc|wsf|wsh)$'ix,  # banned ext - long
###

# qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i,  # banned extension - WinZip vulnerab.

  qr'^\.(exe-ms)$',                       # banned file(1) types
# qr'^\.(exe|lha|tnef|cab|dll)$',         # banned file(1) types
### JACQUES
  qr'^\.(exe|lha|cab|dll)$', # OK pour TNEF, merci outlook
###

Comportement lors de détection de spam

EDIT 08/10/2009. Quelques variables importantes à positionner (écraser par rapport à la conf par défaut) :

[...]
serveur:/etc/amavis/conf.d# cat 50-user
$final_spam_destiny = D_DISCARD; # pour eviter de renvoyer des notifications inutiles a des zombies
$sa_tag_level_deflt  = undef; # pour toujours avoir le tag dans les headers, même si c'est pas du spam
$sa_tag2_level_deflt = 5.0; # d'habitude je mets 5, na !
$sa_kill_level_deflt = 12.0; # d'experience, a 10 on est deja bien bien sur que c'est du spam
[...]

Enfin, j’avais oublié un point important, la variable “@local_domains_acl”. Elle défini la liste des domaines sur lesquels spamassassin va intervenir. Les domaines non listés ici ne sont tout simplement pas pris en compte, donc pas analysés, donc pas “flaggés”…
Je ne l’avais pas vu au début car avec un seul domaine qui est le nom de la machine etc, tout va bien avec le choix par défaut de Debian dans 05-domain_id:@local_domains_acl = ( ".$mydomain" );.
Là où ça se complique, c’est quand vous gérez plusieurs domaines, suivant comment votre bousin est défini. Par exemple avec des domaines virtuels, gérés en base de données, c’est mort (prochain article à venir sur la gestion de domaines et d’utilisateurs virtuels).
J’ai donc forcé cette variable dans le fichier /etc/amavis/conf.d/50-user :

@local_domains_acl = ( ".maboite.fr", "un.autre.alias.net" );

A noter que là, je prends en charge les éventuels sous-domaines “toto.maboite.fr” (c’est voulu, grâce au point devant “maboite”) et uniquement “un.autre.alias.net”, mais pas un domaine de mails qui s’appellerait “encore.un.autre.alias.net”. Pigé ?

Quarantaine

Où doivent aller les mails vérolés ? Par défaut, je suggère de ne rien toucher au paramètre $virus_quarantine_to, ainsi les mails vérolés vont dans une arborescence de /var/lib/amavis/virusmails. Jetez-y un oeil une fois des tests de détection effectués (voir ci-dessous, dernier chapitre).
Et documentez vous sur amavisd-release.

Décodeurs, suite et fin

Dans /etc/amavis/conf.d/01-debian, jouez avec les variables $unrar et autres qui vous intéressent (oui oui, unrar c’est pas libre, tout ça, installez le paquet vrms). Il vous faut les applications correspondantes. Voyez le log /var/log/mail.log pour savoir ce qu’il manque par rapport à votre conf.

spamassassin

If you use spamassassin with the Bayes database system, you should make sure
that the spamassassin configuration option “bayes_auto_expire 0″ is set in
spamassassin configure files. This disables the automatic expiration of tokens
which causes problems for amavisd-new when activated. The amavisd-new package
includes cron jobs that take care of syncing and expiring the token database
frequently.

Je ne mesure pas trop l’impact, à vrai dire, mais je suppose qu’il vaut mieux le faire, donc ajoutez bayes_auto_expire 0 dans la conf /etc/spamassassin/local.cf.

Mise à jour de l’anti-virus

Le programme freshclam est planifié automatiquement lors de l’installation de ClamAV. Vous pouvez contrôler sa bonne exécution (il tourne une fois par heure) dans :

srv:/etc# tail /var/log/clamav/freshclam.log
Received signal: wake up
ClamAV update process started at Thu Sep 10 15:25:18 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
daily.cld is up to date (version: 9791, sigs: 77548, f-level: 43, builder: guitar)
--------------------------------------
Received signal: wake up
ClamAV update process started at Thu Sep 10 16:25:18 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
daily.cld is up to date (version: 9791, sigs: 77548, f-level: 43, builder: guitar)
--------------------------------------

Testez avec EICAR

EICAR est un virus inoffensif. Essayez de vous envoyer des mails avec différentes pièces jointes fournies ici : http://securite-informatique.info/virus/eicar/. Vous validerez ainsi la réaction de votre serveur.
J’ai eu une erreur dans le mail.info lors de la détection du virus. Le serveur tente d’informer l’admin des virus, mais avec une légère erreur de syntaxe sur l’expéditeur :

Sep 21 15:33:37 ns305192 postfix/smtpd[20381]: warning: Illegal address syntax from localhost.localdomain[127.0.0.1] in MAIL command:

J’ai alors modifié la liste des expéditeurs de mails d’alertes. Dans le fichier /etc/amavis/conf.d/50-user :

$mailfrom_notify_admin='postmaster@chezmoi.fr';
$mailfrom_notify_recip='postmaster@chezmoi.fr';
$mailfrom_notify_spamadmin='postmaster@chezmoi.fr';
$mailfrom_to_quarantine='postmaster@chezmoi.fr';

J’ai trouvé la liste de toutes les adresses émettrices d’alertes sur ce site : http://www.radical-spam.org/documentations/amavisd-new.html. Il y a de belles explications sur les modèles de mails et d’autres trucs. Bref, à survoler.
Je n’ai pas trouvé comme pour postfix une commande permettant de voir les variables en mémoire d’amavisd-new. Si ça existe, je suis preneur.

Pour ceux qui n’utiliseraient pas encore de greylisting pour limiter le nombre de spams en entrée de ses serveurs de mails, j’explique comment mettre en place dans ma doc Debian et dans plusieurs articles sur ce blog.

Voici donc une capture d’un échange dans /var/log/mail.[info|log] d’un serveur envoyant un mail à cette architecture postfix/postgrey. Vous pouvez l’imprimer et l’afficher au-dessus de votre lit, c’est joli.

Rappel de la théorie

Le greylisting demande à l’émetteur de renvoyer le mail plus tard, disons 5 minutes. C’est un comportement normal et possible d’un serveur SMTP. Si l’expéditeur est complètement bidon (un zombie par exemple), cette réponse n’arrive jamais. Le mail – qui est un spam ou venant d’un serveur configuré avec les pieds – ne reviendra jamais et n’ira donc pas plus loin que la porte d’entrée du serveur. Pas de traitement anti-spam, rien. Economie de charge CPU etc.
Au bout de quelques mails effectivement reçus de la part de tel serveur, alors on le whiteliste car il semble au moins digne de confiance (je n’ai pas dit qu’il n’envoyait pas du spam). Attention au délai de réception pendant une journée ou 2.

Let’s go

Prise de contact

Aug 27 15:51:05 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:51:06 mon_srv postgrey[12790]: action=greylist, reason=new, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:51:06 mon_srv postgrey[12790]: cleaning up old logs...
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On voit l’action de postgrey (action=greylist) au motif que ce serveur n’a pas encore été whitelisté (reason=new)
Avant dernière ligne : on informe le serveur expéditeur qu’il est greylisté, on en profite pour expliquer à l’admin d’en face qui (peut-être) lit les logs ce qu’est le greylisting.
Sous-entendu, on lui dit via le code retour 450 que la boite a un problème temporaire, sous-entendu, retente plus tard. Attention, on ne dit pas code 550 qui signifierait “la boite est morte définitivement”.

Maintenant on attend de voir s’il nous recontacte

Il revient, mais trop tôt

Une minute plus tard, on a :

Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:52:06 mon_srv postgrey[12790]: action=greylist, reason=early-retry (239s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

L’action est de le greylister à nouveau au motif qu’il est trop tôt (reason=early-retry (239s missing)). Le temps doit être donné dans la réponse d’indisponibilité temporaire mais ça ne se voit pas au niveau des logs).
Et on le renvoit dans ses pénates.
Le revoilà, mais encore trop tôt.< méchanceté gratuite>C’est un serveur Exchange, il ne doit rien comprendre à ce qu’on dit< /méchanceté gratuite>.

Aug 27 15:53:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:53:08 mon_srv postgrey[12790]: action=greylist, reason=early-retry (177s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

̉Trop c’est trop : anvil

Maintenant, c’est simplement le processus “anvil” de postfix, le “contrôleur de nombre de sessions et taux de bourrinage” qui détecte que le serveur en face est un peu trop insistant (il vient trop souvent) :

Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection rate 1/60s for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection count 1 for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max cache size 1 at Aug 27 15:51:05

On ferme carrément la connexion. Reviens plus tard on te dit.

Là il est calmé

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postgrey[12790]: action=pass, reason=triplet found, delay=724, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr

J’accepte son mail comme on voit ci-dessous (action=pass) au motif qu’on l’a déjà bien embêté (reason=triplet found). Au final, il y a aura eu pour ce mail 724 secondes de délai. Rappelez-vous que ça peut être gênant lors d’une mise en place sur un serveur déjà en prod.

La suite est l’enchaînement logique postfix :

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: 1E6B29C4057: client=le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postfix/cleanup[17164]: 1E6B29C4057: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:09 mon_srv postfix/qmgr[15006]: 1E6B29C4057: from=, size=6905, nrcpt=1 (queue active)
Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On arrive dans amavisd-new :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

Aaaaah, ça foire (normal j’ai juste installé clamav, il est détecté par amavis, mais je n’ai rien configuré. Je dois avoir un problème de droits/groupes, ce genre-là. On verra dans mon prochain article qui décrira toute la mise en place.

Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: connect from localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: C2A8D9C405B: client=localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/cleanup[17164]: C2A8D9C405B: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: C2A8D9C405B: from=, size=7349, nrcpt=1 (queue active)
Aug 27 16:03:10 mon_srv amavis[17143]: (17143-01) Passed CLEAN, [10.20.30.40] [10.20.30.40]  -> , Message-ID: <8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>, mail_id: xmX0C24kDlYt, Hits: -, size: 6905, queued_as: C2A8D9C405B, 1764 ms
Aug 27 16:03:10 mon_srv postfix/smtp[17165]: 1E6B29C4057: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.11/0/0/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=17143-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as C2A8D9C405B)
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: 1E6B29C4057: removed

Ci-dessus on a le baratin standard d’un amavis sans clamav (avec son anti-virus interne) qui finit par accepter le mail et le délivrer.

Voilà, c’est beau, on dirait du Rimbaud.

quel.qu.un@tele2.fr le 26/08/2009 16:06
            Le système de messagerie n'a pas pu remettre ce message mais n'a pas signalé de raison particulière. Vérifiez l'adresse du destinataire et réessayez d'envoyer le message. Dans le cas d'un nouvel échec, contactez votre administrateur système.
            < mailfe09.swip.net #4.0.0>

J’ai d’abord pensé à un problème passager lié sûrement au rachat par SFR/NEUF/CEGETEL. Mais le problème dure dans le temps…
Puis j’ai pensé à une sorte de blacklist où le serveur en face ne se donnerait même pas la peine de m’expliquer pourquoi il me jette.
Donc j’ai contacté postmaster@tele2.fr pour demander ; en anglais, car il y a un renvoi vers des bal @swip.net qui ne sont pas des français.

Réponse claire : suite au rachat, migration en cours, les clients sont informés, les boîtes n’existent plus.

Hello Jacques,
Tele2 Europe has divested its french operations.
We are in the middle of a migrationprocess with the buyer(www.sfr.se) of our french operations right now.

This involves that the customers chooses a new emailadress in SFR mailsystem.
The mailadress you are trying to reach has been moved to their system.

Best Regards
Jonas Johnsson
Postmaster
Tele2 Europe

(Et démerdez-vous pour contacter les gens qui se cachaient derrière cette adresse ; et si ce sont des clients tant pis)

Je ne connais personne “chez” tele2.fr, donc je n’ai pas d’information du client lambda.
Si vous en avez, n’hésitez pas à faire un commentaire.

Je doute qu’il suffise de remplacer tele2 par SFR dans l’adresse. Les clients vont sûrement en choisir une nouvelle. Risque de téléscopage trop gros avec les abonnés déjà existants chez SFR.

Le fix est décrit ici, il faut remplacer votre libpurple.dll par celle-ci. En attendant un repackaging officiel (de Pidgin je suppose, pas d’OpenFire).

Partitionnement par défaut

Le serveur arrive avec en gros un swap et une partition “/” de quasimment 1 To (la capacité de mon disque) et un /var (dans mes souvenirs) de quelques dizaines de Mo. C’est assez cool pour héberger une base de données, genre des gros fichiers dans /var/lib/mysql…
Aucune restriction type nosuid, noexec, nodev.
Donc je suggère d’abord une réinstallation en mode “je personnalise mes partitions”. L’interface web est curieuse, il faut d’abord affecter un peu de place à /boot, puis de la place (mais pas tout) à /. (pas slashdot, c’est un point pour finir ma phrase )
A ce moment là, l’interface vous permet de nommer et modifier n’importe que point de montage: /home, /var, /tmp, le swap. A votre convenance.
Pour ce qui est des options noexec, nodev, nosuid, que vous voulez peut-être positionner, il faudra modifier /etc/fstab à la main et rebooter ou faire des mount -o remount qui vont bien.

A la fin j’ai ça, dans le cas d’un serveur en RAID 1 logiciel (celui à 69 €, l’autre est en RAID 1 hard, je préfère). Remplacez mentalement /dev/md par /dev/sda si ça vous pose un problème existentiel.

/dev/md2        /       ext3    errors=remount-ro       0       1
/dev/md1        /boot   ext3    errors=remount-ro,nodev,nosuid,noexec   0       1
/dev/md3        /home   ext3    nodev,nosuid    1       2
/dev/md6        /tmp    ext3    nodev,nosuid    1       2
/dev/md7        /var    ext3    nodev   1       2
/dev/sda5       swap    swap    defaults        0       0
/dev/sdb5       swap    swap    defaults        0       0
proc            /proc   proc    defaults        0       0
sysfs           /sys    sysfs   defaults        0       0

Sources logicielles (apt)

Il y a un miroir OVH. Je n’aime jamais trop ce concept, ne sachant pas si c’est à jour ou pas.
De toute manière, il manque le repository “volatile”. Quitte à l’ajouter, je suis revenu aux standards Debian, voici mon /etc/apt/sources.list :

deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

Un petit aptitude update et aptitude safe-upgrade plus tard, vous voilà à jour.

Kernel

Le kernel par défaut est le 2.6.27.10-grsec-xxxx-grs-ipv4-32 pour un serveur 32 bits. Le patch grsec apporte des modifications de sécurité (mouais) au kernel standard.
Le truc louche est que je ne vois aucun linux-image installé via dpkg -l. J’ai tenté l’installation du dernier 2.6 packagé par Debian (le 2.6.26, via le paquet linux-image-2.6-686), ça a un peu foiré, j’ai lâché l’affaire.
J’ai un peu peur de l’upgrade de sécurité du kernel, qui viendra bien un jour ou l’autre. Pas de paquet qui a amené le noyau (!) et je suis sur les repos autres que les miroirs OVH. Bref à mon avis, le kernel est figé pour longtemps. EDIT: A priori, vu des commentaires, c’est comme chez dedibox : un serveur FTP mettant à jour les noyaux. Supeeeer. Il doit y avoir une mailing-list ou un newsgroup pour suivre les upgrades recommandés, j’espère. C’est le cas chez dedibox.

LILO vs. GRUB

Ils ont choisi LILO. Soit. Je n’ai pas osé mettre GRUB, de peur de foutre la zone avec le reboot en mode rescue. ou de faire sauter (peut-être) le KVM sur IP (ça m’étonnerait quand même). ‘Pas eu envie de tester.
Inconvénient de LILO : penser à taper lilo après un upgrade de noyau. Mais bon, vu la situation décrite ci-dessus…

Accès SSH

Evidemment, accès root autorisé, de toutes les IP.
J’ai changé tout ça : PermitRootLogin no et AllowUsers après avoir créé des utilisateurs locaux. Pour ce qui du classique changement de port, j’ai plutôt opté pour du bridage par IP source sur ce port. Faites comme vous voulez.
OVH peut se connecter en root via clef publique autorisée (installée avec la machine). Si le concept vous plait (et que vous ne virez pas la clef de authorized_keys), il serait judicieux de laisser passer le SSH pour l’IP source qu’ils utilisent (décrite dans le chapitre du firewall ci-après).
Le PermitRootLogin doit être largement incompatible avec ce principe, au passage. Mais bon, on le sait, le RootLogin, c’est mal.

Shorewall (ou iptables)

Là, c’est l’épisode “La mise en place du firewall ou si tu bloques le ping, j’te reboote”. Arg. La cocasse anecdote. Je vous raconte ça comme je l’ai vécu. Les conclusions pour éviter une galère potentielle seront donc à la fin. C’est plus marrant comme ça.
Donc, voici le truc.

(vous pouvez lire mon guide complet sur debian, notamment shorewall, à cette adresse : http://michauko.org/docs/debian_testing/

Après un aptitude install shorewall, il faut configurer Shorewall, avec le postulat de base “je bloque tout sauf ce qui m’intéresse”. Normal. J’ouvrirai le reste à mesure que j’installerai les services (MySQL, apache, mail…)

Les “templates” shorewall pour un serveur à une interface (c’est notre cas) sont amenés par le paquet shorewall-common, dans /usr/share/doc/shorewall-common/examples/one-interface/
Copiez donc tout le contenu dans /etc/shorewall/ et passez en revue tous les fichiers pour que ça corresponde à vos besoins : bridage du SSH sur quelques IP par exemple.
Attention à cette règle (policy) :

$FW             net             ACCEPT

Elle rend possible l’attaque réseau depuis votre machine si elle est compromise. Détailler chaque flux sortant peut permettre d’éviter ça, si votre machine a été compromise juste assez pour faire chier, mais pas assez pour être root, auquel cas l’intervenant fera mumuse avec votre shorewall de toute manière.
Si vous avez besoin d’un fichier “params” vide, il est donné là : /usr/share/doc/shorewall-common/default-config/params.
Une fois votre conf adaptée, modifiez /etc/default/shorewall => startup=1 et relancez shorewall. Testez votre connexion SSH sans perdre l’ancienne session, au cas où la conf n’accepte plus rien, suite à fausse manip…

Cocasse anecdote : une sonde de leur côté (OVH) a immédiatement détecté que mon serveur ne répondait plus au ping=> REBOOT quasi-instantané pour cause de défaillance. O_o woooow. Que ça détecte une “panne”, admettons, que ça force un reboot, PUTAIN NON !!!!!
J’ai eu un ticket quelques instants après m’indiquant qu’il y avait un kernel panic et qu’ils l’avaient donc passé en mode rescue. Moi je veux bien, mais sur la console, y’avait bien écrit “reboot”, et pas le bon gros figeage d’un “kernel panic”. Le type au téléphone m’avait confirmé quelques minutes avant qu’ils avaient forcé le reboot. Bref passons. Ca commence bien la relation client…
Je pense surtout que quelqu’un a eu un excès de zèle et sous couvert d’un ping qui ne répondait pas, m’a rebooté comme un porc la machine, “pour m’aider”, en me la mettant en mode rescue. Ah ouais, super, ça m’aide à mort…
Quelques cris plus tard, un type du service des serveurs dédiés m’indique le “Guide OVH pour le firewall” (http://guides.ovh.net/fireWall). A priori, il me confirme que les machines de monitoring évoquées dans ce guide ne changent pas et qu’il n’y en a pas d’autres en terme de monitoring qui feraient que ma machine serait vu comme défaillante et qui ferait que le mec qui s’emmerde au mois de juillet dans la salle serveur prendrait un coup de chaud et me rebooterait le serveur. Pour m’aider.

Bref, il faut laisser passer le ping pour les machines suivantes : proxy.ovh.net, proxy.p19.ovh.net, proxy.rbx.ovh.net, ping.ovh.net et les 3 premiers octets de votre IP+250/251/249 (3 machines en plus donc).
Plus une machine pour le SSH si vous pouvez avoir besoin d’eux un jour.

Changez enfin les permissions 755 à 750 sur /etc/shorewall

Question : le “PermitRootLogin no” => peut-on quand même passer en mode rescue ? Je le pense, mais bon… car le pass du root est différent. C’est un autre OS qui boote, véritablement, avec uniquement un compte root. Si quelqu’un peut me confirmer ça en commentaire, merci.

Le guide OVH donne la syntaxe iptables pour tolérer le ping de tout ça. Si vous adorez ces longues lignes iptables inbuvables, c’est pour vous. Pour le reste, il y a mast shorewall.
Côté shorewall, avec les fichiers par défaut, il faut comprendre que tout traffic net -> $FW est bloqué par défaut, en “DROP info”, sauf une règle spéciale pour le ping en “DROP simple” – pour éviter de pourrir les logs. J’ai donc ajouté avant cette règle l’autorisation pour les machines de supervision OVH. Ca donne donc :

/etc/shorewall/policy

Inchangé dans cet exemple :

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
$FW             net             ACCEPT
net             $FW             DROP            info
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/rules

#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE         ORIGINAL RATE            USER/   MARK
#                                                       PORT    PORT(S)        DEST             LIMIT           GROUP

### PING
# ouverture pour monitoring OVH
ACCEPT          net:213.186.50.98       $FW     icmp    # proxy.ovh.net
ACCEPT          net:213.186.45.4        $FW     icmp    # proxy.p19.ovh.net
ACCEPT          net:213.251.184.9       $FW     icmp    # proxy.rbx.ovh.net
ACCEPT          net:213.186.33.13       $FW     icmp    # ping.ovh.net
ACCEPT          net:x.y.z.250       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.249       $FW     icmp    # specifique à mon IP : x.y.z.53
ACCEPT          net:x.y.z.251       $FW     icmp    # specifique à mon IP : x.y.z.53
# des machines à moi :
ACCEPT          net:$une_machine     $FW     icmp
ACCEPT          net:$une_autre            $FW     icmp
#défaut :
Ping/DROP       net             $FW # le reste est en "DROP info". Là on va éviter des logs inutiles

### SSH
# moi, moi et moi :
ACCEPT          net:$une_machine     $FW     tcp     22
ACCEPT          net:$une_autre            $FW     tcp     22
# à la limite, eux :
ACCEPT          net:213.186.50.100      $FW     tcp 22  # cache.ovh.net, probablement inutile, pas de compte dans mon cas

### WEB, utiliser AllowWeb serait plus dans le coup non ?
ACCEPT          net                     $FW     tcp     80,443

### MAIL si besoin
ACCEPT          net                     $FW     tcp     25

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

/etc/shorewall/params : exemple

# blabla...
#               net     eth0            130.252.100.255 routefilter,norfc1918
#
###############################################################################
une_machine=a.b.c.d
une_autre=e.f.g.h
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE

autres

Dans cet exemple, les fichiers “interfaces”, “zones” etc sont bien tels quels.
Pensez au restart de shorewall et au test afin d’être sûr de toujours pouvoir venir en SSH sur votre serveur.

Autres trucs à faire avant d’aller plus loin

Je passe sur les softs que vous utiliserez ou non : postfix ou exim, snort, rkhunter…
Pensez à cron-apt, apt-listbugs, ntp…

Autre spécificité OVH

Le script /usr/local/rtm/bin/rtm qu’on trouve dans /etc/crontab. Un outil maison de monitoring. Admettons. C’est expliqué là : http://guides.ovh.net/RealTimeMonitoring

A plus tard pour compléter ce retour d’expérience. En bien je l’espère

Contexte

Je suppose que vous avez un SVN qui tourne. Vous voulez qu’à chaque “commit”, un mail soit envoyé à une personne (ou une liste de personnes), contenant tout ce qu’on peut en attendre : message, fichiers impactés etc.
Sur Internet, tout le monde y va de son script en perl, ruby, bash etc. Debian propose un truc tout fait. J’aime bien

Le principe est le suivant : l’outil SVN a déjà tout prévu. Il y a des “hooks” (grappin = bout de code appelable à un instant donné d’une commande SVN) qu’il suffit d’activer. Un tout petit peu de paramétrage et ça roule.

Installez le script-qui-va-bien

Le paquet subversion-tools vous apporte tout un tas de scripts pré-machés (voir /usr/share/subversion/hook-scripts), notamment un pour envoyer un mail bien propre.

Activez le “hook”

Il y a un modèle dans /votre/repo/svn/hooks/, nommé post-commit.tmpl. Copiez-le en post-commit, avec les bonnes permissions (idéalement via cp post-commit.tmpl post-commit).
Editez-le, lisez le baratin et enfin adaptez la dernière ligne indiquant quelle adresse mail est destinatrice (je considère que le serveur hébergeant SVN est capable d’envoyer des mails).
Exemple :

svnsrv:/svn/monrepo/hooks# tail post-commit
# the Subversion repository at
# http://svn.collab.net/repos/svn/trunk/tools/hook-scripts/ and
# http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/

REPOS="$1"
REV="$2"

/usr/share/subversion/hook-scripts/commit-email.pl \
  "$REPOS" "$REV" mon.adresse@mail.com

Si votre serveur est capable d’envoyer des mails, vous n’avez rien à faire de plus, sinon, il faudra jouer avec la définition des variables $sendmail et $smtp_server (l’une ou l’autre, lisez les commentaires) dans le script /usr/share/subversion/hook-scripts/commit-email.pl.

Enfin, si vous voulez, la ligne de commande accepte plusieurs destinataires (au moins 2, je n’ai pas testé plus ni lu le code pour savoir).

Testez

Normalement, c’est tout. Faire un commit quelconque et voyez le résultat.
J’utilise TortoiseSVN comme client, sous Windows ; ça marche nickel. Si vous vous plantez dans la configuration, Tortoise vous remonte l’erreur indiquant par exemple que le script /usr/share/subversion/hook-scripts/commit-email.pl est KO.

Port knocking :
- tant que votre poste client n’a pas fait une bonne séquence au guichetier (knock-daemon , tel ou tel service est bloqué pour votre IP, via iptables.
- à la fin, vous jouez une séquence pour fermer, ou pas.

Bon j’avoue, je n’ai pas testé. M’enfin, ça doit marcher tout ça. A voir, comme avec le genre fail2ban, si ça ne peut pas être utilisé pour provoquer des dénis de service – le genre je fais bannir/fermer telle IP que je ne suis pas, évidemment.

Ca + du changement de port sur certains services (SSH notamment), et votre machine devrait être une tombe, normalement. Reste les services publics (http…) pour chercher une faille.

(et puis si vous adorez mon site, ce dont je ne doute pas, voici mon flux – façon de parler ; mais je doute que vous aviez besoin de mon aide pour le trouver)

Bonnes vacances