Ce billet fait partie de la série Yunohost comme serveur de mails
Yunohost comme serveur de mails - Billet N°1
Yunohost comme serveur de mails - Billet N°2
Yunohost comme serveur de mails - Billet N°2

Les logs

Remarque : le présent billet ne parlera pas de l'analyse du contenu des logs en lui-même (gestion d'erreurs etc.) mais a pour objectif de faire (re)découvrir un outil précis.

Le serveur de mails d'envoi et de réception des mails est Posftix et les logs de ce serveur se trouvent dans le fichier /var/log/mail.log.

Pour analyser ce fichier, il y a

La version graphique depuis l'interface d'administration de Yunohost :
./admin/#/services/postfix/log : pour voir les logs
. /admin/#/services/postfix : pour voir l'état du service
que l'on utilisera pour regarder les dernières lignes et l'état du service.

La méthode à l'ancienne qui consiste à lire le contenu de de fichier (à base de cat, head, more, tail...), à y rechercher des séquences / chaînes de texte particulières (grep).

Et une méthode à base de script. Il existe en effet un script perl, packagée sous Debian, pflogsumm (Site internet de pflogsumm : http://jimsun.linxnet.com/postfix_contrib.html) qui permet de parser le fichier mail.log et en extraire un certains nombres d'informations classées de façon pertinentes, parmi lesquelles :
Nombre de mails envoyés par compte ;
Nombre de mails reçus ;
Taille des mails ;
Trafic mail par jour, par heure...
Tout un tas de cumul et de métriques qui peuvent être intéressantes et pertinentes.

Comme tout outil en ligne de commande, il y a une page man détaillant toutes les options qu'il est possible d'utiliser / appeler.

Et une FAQ en anglais assez riche et détaillée.

Pflogsumm est donc un outil fort utile pour avoir un rapport journalier de suivi de son serveur mail.

Pour finir, Astuce trouvée dans le forum de Yunohost, l'envoi par mail (!) d'un rapport quotidien d'analyse de l'envoi de mail via une tâche cron

Ce billet fait partie de la série :
Devenir SysAdmin d'une PME, retour d'expérience - Billet n°0
Devenir SysAdmin d'une PME - Gestion du legacy- Billet n°1
Devenir SysAdmin d'une PME - Mineur de bitcoin- Billet n°2
Devenir SysAdmin d'une PME - Accepter de ne pas avoir le contrôle sur tout- Billet n°3
Devenir SysAdmin d'une PME - Les sauvegardes- Billet n°4

Comment connaître la criticité d'un service ?

Pour répondre à cette question, la technique que je conseille est de couper - virtuellement - le service ou la machine (en vue d'esprit donc) et de juger, d'estimer l'impact que cela a. Il y a une autre façon de faire, plus brutal, est celle de débrancher le câble réseau si on a un accès physique à la machine.

L'objectif est d'éviter que l'on apprenne l'importance d'un service et les conséquences / impacts de son interruption au moment de la perte de celui-ci.

Relativité de la criticité

Nombre d'utilisateurs impactés, temps de remise en oeuvre, délai de coupure acceptable.... Cela reste très subjectif car le fait que le service d'impression ne marche pas pendant une matinée voir une journée ne me gênera pas et sera bloquant pour quelqu'un qui imprime toutes les fiches de paie en fin de mois... La criticité est aussi relative à la période du mois ou de l'année.

Quand on ne sait pas, une solution un peu extrême peut être alors de débrancher le câble réseau et de voir en ce qui ne marche plus (la supervision est pratique pour ça, encore faut il que la machine qui rende un service inconnu et qui tourne dans un coin soit supervisée...) en envisageant toutefois le "comment on remet en marche", avant.

Les services critiques évidents

Toutefois comme pour les O.I.V. (Organismes d'Importance Vital) il y a des choses vitales dans l entreprise. Sans connexion Internet, plus de possibilité d accéder aux serveurs dans le Cloud... Si la connexion fibre ne marche plus, il faut donc une ligne secondaire ADSL ou SDSL ou envisager une connexion en 4G, dans tous les cas ce sera une connexion secondaire qui doit rester temporaire, avoir été testé pour voir la viabilité... Comme tout plan B.

Si ça marche, on ne touche pas

Autre règle importante : une machine qui tourne surtout si elle est vieille on ne l'éteint pas. J ai eu l'expérience dans une autre vie d'un vieux serveur qui tournait depuis des années. Coupure de courant sur plusieurs jours suite à un coup de pelleteuse, groupe électrogène sous dimensionné et on éteint donc les serveurs les moins critiques pour alléger le groupe. Au retour à la normale, le serveur ne démarre pas. Soucis de pile du Bios HS, puis un ventilateur usé avec les années qui ne tourne plus... Le début des ennuis. Mais c'est une autre histoire.

A l'installation d'un PC, nous avons fait une Installation d'un disque entièrement chiffré (à l'exception de la parition uefi et /boot). Il y a donc un espace LUKS chiffré qui occupe la majorité du disque et dessus, différentes partitions reposant sur LVM ont été faîtes afin d'avoir une partition / (racine) et une partition /home séparée.

Que ce passe-t-il si on souhaite / doit réinstaller le système d'exploitation ?

Le but de cette procédure est donc de pouvoir réinstaller une partition racine au sein d'un disque dur chiffré tout en conservant la partition home.

Les étapes préalables à la réinstallation sont de booter le PC sur une clef contenant Ubuntu dans la version d'Ubuntu appropriée (un live-usb) et de choisir le mode "Try Ubuntu". Une fois le système démarré, on doit faire une ouverture de la parition chiffrée. Pour ce faire

Ouvrir un terminal et passer en root via la commande suivante :

Ouvrir la parition chiffrée via la commande suivante :

Et ensuite, on peut alors passer au lancement de la réinstallation en cliquant sur l'icone "Install Ubuntu" et on suit le processus de "résintallation" classique, en prenant soin de définir un partitionnement manuel
bien sélectionner les partitions et de bien les réaffecter aux bons points de montage (/, swap, /home et autres si besoin)
NE PAS FORMATER LA PARTITION /dev/mapper/vgcrypt-lvhome

Ce billet fait suite au billet Yunohost comme serveur de mails - Billet N°1 et Yunohost comme serveur de mails - Billet N°2

Le serveur MX secondaire

J'ai eu de nombreux retours via des messages sur les réseaux sociaux et je voudrais en faire une petite synthèse. J'aborde dans l'un des mes billets le cas (non encore réglé) d'avoir un serveur MX secondaire. Comprendre : si le serveur de Mail principal (définit via le champ MX de l'entrée DNS associée au nom de domaine) ne marche pas, alors le serveur de mail envoyant le mail tente l'envoi du mail sur le second serveur indiqué en champ MX, qui s'occupe alors de faire la réception (et éventuellement une redirection) du mail. Cette seconde doit être associé à un chiffre (le poids) plus faible pour indiquer que c'est un serveur de secours. ("Quand le serveur principal ets HS ça part sur le secondaire qui est réglé pour renvoyer sur le principal et il garde le mail en mailqueue (cas d'un serveur postfix) tant qu'il n'y arrive pas.") Une recommandation me dit que c'est inutile "Les mails restent en attente pendant quelques temps (par défaut 5 jours ; 4 à 5 jours recommandés sur https://tools.ietf.org/html/rfc5321#section-4.5.4" à celle d'au contraire "d'avoir un MX de secours sur un serveur de mails dans un datacenter différent". De même, on me dit que "l'hébergement d'un service de mails est un métier à part entière", sur ce point je suis assez bien placé pour le savoir de part l'une des mes nombreuses responsabilités professionnelles actuelles.

Je n'ai pas encore traité ce sujet, mais mon ressenti et mon avis est le suivant : si la panne se prolonge, que l'on a pas accès à la machine pendant un certain temps (cas des vacances) ou que l'on est la seule personne à savoir remettre le service en ligne, le mail finira par se perdre. Donc ce n'est pas un sujet anodin à prendre à la légère et il faut probablement avoir un MX secondaire. On peut "le prendre" chez une personne de confiance (un ami par exemple de qui on sera soi-même le MX secondaire ; FDN propose par exemple d'utiliser les serveurs FDN en MX secondaire, ou Rézine propose un serveur de mail secondaire (« MX secondaire ») à ses membres.), ce qui permet de s'afranchir de la maintenance de ce second serveur (sinon cela alourdit la charge en administration système que d'avoir un second serveur à maintenir à jour, et en coût).

Stéphane Bortzemeyer a écrit il y a un peu plus de 10 ans un billet de blog Un MX secondaire est-il vraiment utile ?, je vous laisse découvrir son avis fort bien argumenté (Spoiler : non). Autre avis à lire De l'intérêt d'un MX de secours dans le cadre de la gestion de mon service mail personnel par Quentin Demouliere.

Pour la configuration technique d'un serveur MX secondaire, voir wiki.auto-hebergement - Serveur de courrier secondaire.

La question n'est donc pas trancher, est à chacun de se faire son propre avis du coup, les arguments en faveur du pour et du contre ne me permettant à l'heure actuelle de pencher en faveur d'un seul ou de deux serveurs MX pour le mail.

Ce billet fait suite au billet Yunohost comme serveur de mails - Billet N°1 Dans la todo, il y avait l'envoi à un mail de GAFAM et l'ajout de DKIM, DMarc, SPF...

DKIM, DMarc, SPF

Pour ça, je citerai le billet Délivrabilité : SPF, DKIM, DMARC, … ce qu'il faut savoir sur l'authentification de vos emails !

DKIM = DomainKeys Identified Mail DKIM tente d'associer un nom de domaine à un message en y aposant une signature numérique. La vérification de la signature se fait via une clef cryptée située dans un enregistrement DNS. Ce faisant, DKIM permet de vérifier si un message a été altéré durant son transport entre les différents serveurs SMTP et de garantir que le contenu arrivera intact jusqu'au destinataire.

SPF = Sender Policy FrameworkEnregistrement SPF sur son serveur DNS. Permet de vérifier / valider que les IP associées des serveurs ont le droit d'envoyer des mails pour ce nom de domaine

DMARC = Domain-based Message Authentication, Reporting and ConformanceDMARC joue sur la synthèse entre SPF et DKIM, pas en les remplaçant, mais en les unissant et en les rendant plus intelligents.

Dans Yunohost

Yunohost dispose donc d'un serveur de mail (cf Yunohost comme serveur de mails - Billet N°1) et DKIM et SPF sont déjà préconfigurés, disponibles, il n'y a quasiment rien à faire. Il faut récupérer les informations de configuration. Pour ce faire, il faut :

aller dans la partie interface d'administration de Yunohost https://mondomaine.tld/yunohost/admin/
Dans le menu DOMAIN > mondomaine.tld > Voir la Configuration DNS

Là il y a les informations pour le DKIM, DMarc, SPF

Ces informations sont à saisir dans la configuration de l'entrée DNS chez son prestataire (Gandi par exemple) sous la forme :

Et on attend de nouveau la propagation du DNS.

Pour vérifier tout ça

Différentes façons de faire et de valider que la configuration est correcte.

Test en ligne

On va sur le site

DKIM check

DNS record for mail._domainkey.mondomaine.tld:
"v=DKIM1; k=rsa; p=50917a15d4930834a9dd3b43a43ee131190e12674eab791a354dea0afb4475b1"
Key length : 1024