Dialogue avec le support Free

A mon avis, ce n’est plus une bonne idée de vouloir autohéberger son propre serveur de messagerie, tant il est difficile de garantir son bon fonctionnement selon les bonnes pratiques (qui évoluent très vite). Mais c’est possible. Et j’ai voulu m’y atteler pour une raison que j’expliquerai dans un autre billet.

L’une des nombreuses conditions pour disposer d’un serveur de messagerie pleinement accepté par ses petits camarades serveurs-de-messagerie, est de pouvoir mettre en place un reverse DNS. Et cela tombe bien, comme Rodolphe, je suis abonné Free, et ce FAI permet via son interface de mettre en place un reverse DNS.

Enfin, c’est ce que je croyais…

Après avoir paramétré le reverse DNS correspondant à mon besoin, dans l’interface Free de mon abonnement FreeBox, et après avoir attendu plusieurs jours pour être certains que les informations se soient bien propagées, le reverse DNS n’était toujours pas fonctionnel : les différents outils à ma disposition me donnent toujours comme reverse W-X-Y-Z.subs.proxad.net, où W.X.Y.Z est l’adresse IPv4 fournie par Free pour mon point d’accès.

Cherchant à en savoir plus, je me tourne vers internet et je constate que pas mal de personnes semblent avoir le même problème que moi…

Comme il n’est plus possible d’avoir une réponse par les canaux habituels des années 90, je m’adresse au support par Twitter en Direct Messages. Je vous livre le dialogue in extenso :

Bonjour, le reverse DNS n’est pas fonctionnel, alors qu’il est activé dans mon interface depuis 15 jours… Je lis dans de nombreux forums que ce service ne fonctionne pas correctement, est-ce exact ? Comment le faire fonctionner quand on autohéberge un serveur de messagerie ?

Ligne Fibre Optique
NRO : XXXXX
Adresse IP : W.X.Y.Z
Préfixe IPv6 : AAAA:BBBB:CCCC:DDDD::/64

Identifiant : fbxXXXXXX
N° de téléphone Freebox : XX XX XX XX XX
N° de fax : XX XX XX XX XX

Le reverse DNS effectif est WW-XX-YY-ZZ.subs.proxad.net

Ce qui n’est pas ce que j’ai paramétré dans l’interface Freebox

bonjour,
edirection DNS [ma conf] vers WW.XX.YY.ZZ (Actif)
Reverse DNS WW.XX.YY.ZZ vers [ma conf] (Actif)

Pour information, nous n’effectuons aucun support à ce sujet.

Bonne journée

Je pense que vous n’avez pas compris la question, car votre réponse ne fait qu’indiquer ce que j’ai moi-même configuré (je suis donc au courant de ce que j’ai configuré) ET me dire que c’est actif (ce que je sais puisque c’est ce que l’interface de la Freebox indique).

Ma question est donc : pourquoi est-ce que ce n’est pas fonctionnel ?

Nous n’effectuons aucun support à ce sujet.
Bonne journée

Vous m’indiquez que la edirection DNS est : [ma config]

Vous m’indiquez que le reverse DNS est : [ma config]

Je suis d’accord avec vous.

MAIS lorsque l’on teste le reverse DNS effectif depuis les ordinateurs du monde entier, la réponse effective est : WW-XX-YY-ZZ.subs.proxad.net

Ce qui n’est PAS le configuration demandée ET indiquée comme “Actif” sur votre interface Freebox

DONC il y a un bug CHEZ VOUS

Pouvez-vous le corriger et rendre ce service FONCTIONNEL ?

Merci

Je ne comprends pas que votre réponse puisse se limiter à “nous n’effectuons aucun support à ce sujet” : je vous signale un dysfonctionnement, et je demande une réparation d’un service dû qui ne fonctionne pas, je ne demande pas un support !

C’est actif, donc fonctionnel. Bonne journée

Je n’ai eu ensuite plus aucune réponse à mes sollicitations…

Une carte n’est pas le territoire qu’elle représente – Alfred Korzybski

[EDIT du 20/02/2020] Un lecteur m’informe sur Twitter qu’un ticket de bug a été ouvert chez Free cet été sur ce problème, puis fermé avec la réponse suivante :

Close par Thibaut Freebox (Thibaut Freebox)
Thursday  1 August, 2019 15:01:46
Raison de clôture :  Ne sera pas implémenté
Commentaires supplémentaires de clôture :
Ne sera pas implémenté POUR L'INSTANT (période de transition adsl-fibre et ipv4-v6)
Ce sera ré-implémenté à l'avenir, mais non : je n'ai pas de date pour cela.

Remplacer un disque dans un soft RAID GNU/Linux

Hier, j’ai eu une petite frayeur en constatant qu’un test automatique SMART (long selftest) rencontrait une erreur de lecture sur l’un des disques durs de mon NAS de sauvegarde. Celui-ci apparaissait en SMART rouge sur l’interface OpenMediaVault…

Comme c’est un NAS DIY, je n’ai pas de procédure automatique en cas de panne de disque dur : il faut intervenir à la main. Je pose ici la procédure, pour la partager et m’en souvenir, car quand un disque tombe, les autres vont commencer à faire pareil…

Le disque en panne est /dev/sdb, et je suis dans le cas d’un RAID5 où je peux retirer un disque du RAID, sans perdre de données. Le NAS ne contient que des sauvegardes, donc je peux perdre toutes les données, mais j’aime mieux pas (10 To de sauvegardes à reconstituer pendant plusieurs semaines, mon cœur ne tiendrait pas).

Dans un terminal ouvert sur le NAS en ssh sous root (ssh root@X.X.X.X), utilisez les commande suivantes (il faut adapter les commandes selon votre configuration. VOUS DEVEZ COMPRENDRE CHAQUE COMMANDE AVANT DE LA LANCER. Une erreur a pu se glisser dans la suite de commandes que j’indique, je décline toute responsabilité, SGDZ, pas taper) :

Je déclare le disque en panne (SMART ne l’a pas fait), puis je le retire du RAID5 :

mdadm --manage /dev/md0 --fail /dev/sdb
mdadm --manage /dev/md0 --remove /dev/sdb

Je constate dans l’interface OpenMediaVault que le RAID est passé en mode dégradé (il ne l’était pas encore car le problème que j’ai détecté est un problème SMART).

J’arrête le NAS et je remplace hors tension le disque défectueux par un disque de même taille, judicieusement disponible à cette occasion (spare à froid).

Je redémarre le NAS et constate que l’interface OpenMediaVault ne me propose pas d’insérer dans le RAID le nouveau disque dur, sans doute parce que celui-ci n’est pas correctement préparé. Je vais le préparer avec les commandes suivantes :

Je me reconnecte root sur le NAS avec un terminal via ssh, pour lancer la commande gdisk :

gdisk /dev/sdb

Et là, horreur malheur, j’ai les informations suivantes :

GPT fdisk (gdisk) version 1.0.1

Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header.

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk verification and recovery are STRONGLY recommended.

Dans l’interface de la commande gdisk, je passe en mode “Expert command” en tapant “x”, puis je supprime les structures GPT et nettoie MBR avec la commande “z”:

Command (? for help): x
Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): Y

GPT data structures destroyed! You may now partition the disk using fdisk or other utilities.

Blank out MBR? (Y/N): Y

Je quitte gdisk avec la commande “w”, puis je relance gdisk pour vérifier que tout est bon :

# gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present

Creating new GPT entries.

Command (? for help): q

J’ajoute enfin le nouveau disque dans la grappe RAID :

mdadm --manage /dev/md0 --add /dev/sdb

Je vérifie qu’il n’y a pas d’erreur bizarre, avec :

fdisk -l  # <-- le signe avant le croisillon est un L minuscule

Je vérifie que le RAID se reconstruit correctement, dans l’interface OpenMediaVault ou avec la commande :

cat /proc/mdstat

Je prie pour qu’aucun autre disque ne lâche dans les heures suivantes…

Une fois tout rentré dans l’ordre, je n’oublie pas de reprogrammer un selftest SMART de type long sur le nouveau disque, dans l’interface OpenMediaVault.

J’espère que ce billet pourra faire gagner du temps à quelques uns.

Ceinture et bretelles