Devenir SysAdmin d’une PME – Les sauvegardes- Billet n°5 – Comment connaître la criticité d’un service ?

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.

Comment réinstaller Ubuntu sur un disque entièrement chiffré (avec un /home séparé)

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 :

$ sudo -i

Ouvrir la parition chiffrée via la commande suivante :

# cryptsetup luksOpen /dev/[nom partition chiffrée] hdcrypt
et taper la passphrase / phrase de passe.

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

Yunohost comme serveur de mails – Billet N°3

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.

Yunohost comme serveur de mails – Billet N°2

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

@ 3600 IN TXT "v=spf1 a mx ip4:12.345.678.123 -all"
mail._domainkey 3600 IN TXT "v=DKIM1; k=rsa; p= 50917a15d4930834a9dd3b43a43ee131190e12674eab791a354dea0afb4475b1"
_dmarc 3600 IN TXT "v=DMARC1; p=none"

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

Nom du champ, Type du champ, Valeur
@ TXT "v=spf1 a mx i … .159.188 -all"
mail._domainkey TXT "v=DKIM1; k=rsa; p= 50917a15d4930834"
_dmarc TXT "v=DMARC1; p=none"

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

Champ - valeur :
Domain name : mondomaine.tld
DKIM Selector : mail._domainkey

Et on a comme résultat :

SPF check

1 SPF record found for the domain mondomaine.tld :
"v=spf1 a mx ip4:12.345.678.123 -all"

DKIM check

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

On a donc bien la bonne configuration

Thunderbird : on peut ajouter une extension comme DKIM verifier

qui permet d'ajouter un champ dans l'entête d'un mail reçu et de vérifier le DKIM.

Envoi du mail sur un compte Gmail

Et on regarde alors dans le détail du mail (option Afficher l'original), on a alors

SPF : NEUTRAL avec IP 12.345.678.123 En savoir plus
DKIM : 'PASS' avec le domaine mondomaine.tld En savoir plus
DMARC : 'PASS' En savoir plus

Et quand on clique sur bouton le copier-coller, on a le détail :

Received-SPF: neutral (google.com: 12.345.678.123 is neither permitted nor denied by best guess record for domain of genma@mondomaine.tld) client-ip=12.345.678.123;
Authentication-Results: mx.google.com;
dkim=pass header.i=@mondomaine.tld header.s=mail header.b=mbt7mELs;
spf=neutral (google.com: 12.345.678.123 is neither permitted nor denied by best guess record for domain of genma@mondomaine.tld) smtp.mailfrom=genma@mondomaine.tld;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mondomaine.tld
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mondomaine.tld; s=mail; t=1535027249; h=from:from:sender:reply-to:subject:subject:date:date:

Soit une autre façon de valider que la configuration est correcte.
Les mails reçus ne doivent normalement pas être reconnus / tombés dans le SPAM par défaut.