Gandi c’est fini

Et dire que c’était l’hébergeur de ma première adresse email associée à mon nom de domaine.

Et oui, j’en ai désormais terminé avec Gandi depuis presque un mois maintenant. Propriétaire depuis plusieurs années d’un nom de domaine géré chez Gandi, j’avais fait le choix de cet hébergeur pour sa réputation, les bons retours que j’avais pu lire à plusieurs reprises en ligne, et surtout, pour les quelques adresses mails incluses dans leur offre nom de domaine.

L’histoire commence à la mi-2023, après réception et lecture d’un mail de Gandi informant ses clients des changements à venir et des évolutions de leurs tarifs. Trahison ! L’offre mail associée à un nom de domaine va être arrêtée et les clients forcés à souscrire à une offre mail facturée à l’adresse mail. Augmentation des coûts x8 dans mon cas, puisque deux adresses sont activement utilisées. Je me félicite de n’avoir finalement pas incité mes proches à migrer leur adresse email sur mon domaine.

A l’époque, de mémoire, il était possible de créer jusqu’à 5 adresses mails associées à un nom de domaine. Mon frère et moi-même avons donc pu troquer nos adresses gérées par le FAI du moment pour passer sur des adresses plus pérennes (du moins en théorie), et affichant notre nom de domaine: unicoda.fr. Ce qui faisait pour moi l’intérêt de cette offre en particulier, était la possibilité de définir des alias en mode regex *, permettant ainsi d’avoir facilement une adresse dynamique par contexte, par site ou par provenance. Avec par exemple l’alias suivant : moi-*@mondomaine.fr, je pouvais au besoin donner l’adresse moi-vendeur1@mondomaine.fr pour les communications en provenance de vendeur1 et moi-association-xy@mondomaine.fr pour les communications en provenance de association-xy. Et cela en toute simplicité.

Cette organisation a l’intérêt de ne pas exposer son adresse mail principale à des acteurs commerciaux parfois peu scrupuleux et dont les fichiers clients peuvent être réutilisés, malgré l’opposition explicite à l’envoi de mails commerciaux, mais aussi d’identifier immédiatement la source d’une fuite de données, en cas de faille de sécurité chez le contact x ou y. Heureusement chose exceptionnelle, il m’est arrivé de recevoir des spams sur l’une de mes adresses spécifiques, m’indiquant ainsi que l’adresse confiée au contact et à son système informatique avait fini par fuiter. Si les protections anti-spam ne font pas effet, il est alors possible de mettre l’adresse en liste noire, pour bloquer définitivement les mails entrants sur cette adresse et conserver ainsi une adresse saine. Mon erreur ici, a peut-être été de ne pas choisir d’utiliser le caractère `+` pour définir mon alias, car ce type d’alias est plus standard et donc souvent supporté chez les autres fournisseurs de mail.

Revenons à nos moutons. Alors que je commençais à envisager de faire migrer d’autres membres de la famille en utilisant les adresses restantes, Gandi annonça une baisse du nombre de mail associés à un domaine et limita leur nombre à 3 adresses. Statu quo. Nous restons donc à deux utilisateurs des adresses mails fournies. Avance rapide au 14 juin 2023 et à l’annonce de la fin des adresses mails fournies avec un nom de domaine au 30 novembre de la même année. Une solution simple consisterait à migrer les 2 comptes mails que nous utilisons vers l’offre de mail de Gandi, mais celle-ci, avec l’augmentation des tarifs, va passer de 0,42e/mois à 4,2e/mois. Rien de moi qu’un x10. Pour l’utilisation que nous faisons de nos comptes personnels, l’addition est salée.

Ayant bien d’autres choses à traiter, nous avons donc cherché à limiter les dégâts. Sur les deux adresses liées à mon domaine, je n’ai conservé que la mienne, l’autre ayant été décommissionnée, et j’ai donc commencé à me voir facturer le coût mensuel d’une adresse. Une migration durant cette période me semblait hasardeuse, car risquait de me faire perdre des emails, en réception, ou en envoi, du moins le temps de résoudre les éventuels problèmes de configuration.

Les mois passant, la routine s’installe. Le service fonctionne toujours correctement et je n’ai pas l’envie ni le temps de me concentrer sur la migration de mon adresse mail, bien qu’une courte interruption de service soit maintenant acceptable.

Jusqu’à début septembre 2024, qui voit arriver le renouvellement du nom de domaine auquel sont liées les adresses. Alors que je démarre la procédure, le prix du renouvellement d’un .fr pour un an s’affiche: 30 euros et des brouettes. J’avais bien vu passer un document listant les augmentations de tarifs, mais celle-ci m’avait échappé… Une nouvelle fois, on sent que la politique tarifaire a changé après le rachat par un groupe d’investissement en 2019 : il faut que le fric rentre ! (Lire à ce sujet « Gandi, passe de « no bullshit » à « bait and switch » ? » chez linuxfr) A une semaine de la date d’expiration, j’hésite quelques instants. Rester encore un an et consentir à me faire racketter, le temps de trouver une autre solution, ou entamer une migration d’urgence.

Ce sera une migration d’urgence vers OVH, où les tarifs sont bien plus raisonnables et que j’utilise déjà pour unicoda.com: nom de domaine et serveur, sans avoir eu à m’en plaindre jusqu’à présent – excepté peut-être lorsqu’unicoda a littéralement migré dans le cloud avec l’incendie du datacenter de Strasbourg (Mais j’avais trouvé l’expérience plutôt enrichissante. Voir: Unicoda a brûlé !). Problème, les offres mail ne proposent pas de configuration d’alias * comme celle décrite plus haut. L’adresse mail comprise dans l’offre nom de domaine propose la création de 1000 alias, et l’offre pro, l’utilisation du + pour la création dynamique d’adresses. Il va falloir migrer toutes mes adresses existantes, vers un format +, en remplacement du caractère que j’utilisais jusqu’à présent.

J’ouvre une ligne de commande, et lance une analyse sur le contenu de mon password store: pass grep -E ‘monPrefix-.*@unicoda.fr’ > compte_a_migrer.txt. J’ouvre le fichier et me retrouve nez-à-nez avec 300 lignes de données, chaque compte occupant deux lignes, soit pas loin de 150 comptes à mettre à jour. Commence alors la tâche répétitive et gargantuesque de modification du mail: connexion au compte, changement du mail, validation de la nouvelle adresse, suppression de l’ancienne, mise à jour de l’entrée dans le gestionnaire de mot de passe, et on recommence.

Après trois soirées de désœuvrement intellectuel, ça y est, la majorité des adresses est migrée, et les adresses restantes ont fait l’objet d’une création d’alias manuelle. J’enclenche donc la procédure de transfert du nom de domaine, à 72h de son expiration, scotché à mon écran comme un papillon de nuit à sa lumière, inquiet de voir le processus automatisé se gripper. Tel ne fut heureusement pas le cas. La migration s’est déroulée sans accroc en ce qui m’a semblé moins de 3h et, après quelques heures de sommeil bien méritées, la partie mail a suivi, avec test d’envoi et de réception dans la foulée.

Rétrospectivement, j’aurais pu m’éviter énormément de travail en choisissant de ne migrer que les comptes importants et considérer de nombreux comptes de boutiques ou de services en ligne comme des comptes historiques. Ne pas les migrer signifiait une possibilité de perte d’accès en cas de reset forcé du mot de passe, le mail de contact n’existant plus mais, dans une telle situation, il aurait été seulement nécessaire de créer l’alias manquant pour débloquer la situation. Une autre solution, qui ne m’est venu malheureusement que bien après, aurait été d’utiliser les APIs OVH pour scripter la création des alias (POST /email/mxplan/{service}/account/{email}/alias et POST /email/pro/{service}/account/{email}/alias). Si l’idée d’automatiser ce processus rébarbatif de mise à jour des adresses mail m’a bien traversé l’esprit, l’urgence de la situation et le peu de temps restant pour migrer le domaine, via une procédure qui m’était jusqu’alors inconnue, m’ont empêchés de prendre le recul nécessaire pour envisager cette solution.

Finalement, le transfert d’un nom de domaine, opération que j’appréhendais quelque peu, est d’une simplicité enfantine et ce changement d’hébergeur me permet de limiter l’augmentation du coût des services que j’utilise et de simplifier un peu le suivi, la gestion et la facturation en les regroupant. La découverte des APIs OVH quant à elle, me donne quelques idées à explorer, un jour peut-être et vient me rappeler que, dans une situation d’urgence, il faut parfois savoir ralentir pour prendre un peu de recul. Et, qui sait, s’accorder d’explorer un autre chemin qui, s’il s’avère praticable, permettra de simplifier les choses et de gagner du temps.

Oh Gandi, c’est fini. Je ne crois pas que j’y retournerai un jour.

De retour chez OVH

Article du samedi soir qui devrait rester court, simplement pour informer qu’Unicoda est de retour chez OVH depuis quelques heures. Cette fois, le serveur s’éloigne de moi de plusieurs centaines de kilomètres, alors qu’il était longtemps à moins de 15 kilomètres de mon domicile. Bref, retour en France, après un court passage chez Hetzner à Falkenstein en Allemagne. Tout a l’air de bien fonctionner. Vérification demain matin que le processus de sauvegarde quotidien s’est exécuté comme prévu et avec succès.

Au passage, j’en ai profité pour ajouter une sauvegarde distante supplémentaire. Le site est donc à présent sauvegardé vers deux services de stockage différents: Backblaze B2 (déjà évoqué ici) et désormais également dans le Cloud IBM. Je suivrai les sauvegardes vers ce nouveau dépôt dans les prochains jours afin de valider définitivement son bon fonctionnement.

J’ai profité de cette nouvelle migration pour jeter un œil du côté des logs Apache, pour la journée du 19 mars, en utilisant GoAccess, découvert pour l’occasion, et qui permet d’avoir quelques données agrégées directement accessible dans le terminal. Je note au passage l’option --ignore-crawlers permettant de filtrer les robots et autres bots. Difficile par contre de se faire une idée précise du nombre de lecteurs quotidiens, mais le flux RSS semble être appelé régulièrement: tant mieux !

C’est vraiment un point que je souhaite améliorer, à savoir la surveillance du serveur, en termes d’utilisation de ressources et d’analyse du trafic. Loin de moi l’idée de mettre en place du Google Analytics, mais quelque chose basé sur l’analyse des logs Apache devrait suffire et permettre, par exemple sur une durée d’un mois, de distinguer le trafic « réel », du trafic des bots, crawlers et autres spammers automatisés, et de savoir comment se comporte le serveur.

Pour finir, quelques données en vrac concernant les proportions de chaque système d’exploitation et les navigateurs pour cette journée du 19 mars. Pour les systèmes d’exploitation, je note environ (arrondi à la valeur inférieure):

  • 36% Windows
  • 25% GNU/Linux
  • 18% Android
  • 11% Macintosh
  • 1% iOS

Pour les navigateurs:

  • 37% Chrome
  • 26% Firefox
  • 19% Safari
  • 2% MSIE

Sur ces quelques chiffres, amis lecteurs, bonne nuit !

SPA112 et ligne VoIP OVH

En début d’année 2018, je m’attelais à l’amélioration de mon réseau LAN, en cherchant à en maîtriser le plus de composants possibles. À l’époque, j’étais chez OVH pour ma connexion au réseau internet, et je disposais à ce titre, d’une ligne téléphonique. Afin de pouvoir me passer du modem OVH, j’avais donc commandé un petit boîtier Cisco SPA112, afin de pouvoir brancher mon téléphone et d’être en mesure de passer et de recevoir des appels. Voici quelques notes prises au moment de la mise en place et que je publie ici pour référence.

Sur le SPA112, le couple login/mot de passe par défaut est admin/admin. Avant même de m’attaquer à la configuration de la ligne, j’avais commencé par mettre à jour le firmware. Celui-ci est à récupérer directement sur le site de Cisco, je note d’ailleurs qu’une nouvelle version du firmware a été publié en avril de cette année. Dans mes souvenirs, le processus de mise à jour ne présente aucune difficulté, dans l’onglet dédié, il suffit de sélectionner le zip sur son disque, puis de valider pour démarrer la mise à jour. Évidemment, dans l’idéal, on prendra quelques minutes pour vérifier la somme de contrôle du fichier récupéré.

Pour ce qui est de la configuration de la ligne, je me suis inspiré de la page Cisco SPA112 du wiki VoIP.ms qui fournit une documentation très complète sur le boîtier. Toujours en fouillant dans ma mémoire, je crois me souvenir d’avoir effectué la configuration via la page « Quick Setup », et n’avoir eu qu’à remplir les champs proxy, display name, user id et password avec les informations de ma ligne OVH. Il ne me semble pas avoir eu besoin de mettre en place une configuration particulière pour le dial plan. Voici donc un extrait de ma configuration:

  • Proxy: sip3.ovh.fr
  • Display Name: 0033900000000
  • User ID: 0033900000000
  • Password: <mot de passe>
  • Dial Plan: (*xx|[3469]11|0|00|[2-9]xxxxxx|1xxx[2-9]xxxxxxS0|xxxxxxxxxxxx.)

A ce stade, les propriétaires d’un accès internet OVH s’étonneront peut-être du fait que je disposais des informations de connexions à la ligne téléphonique incluse dans mon abonnement. En effet, il faut savoir qu’OVH ne fournit pas ces informations dans le cadre de l’offre d’abonnement internet. Le seul moyen d’avoir ces informations via OVH, consiste à demander l’envoi contre caution d’un SPA112 déjà configuré, ou de s’abonner spécifiquement à une offre de ligne téléphonique sur IP.

Une autre solution, celle que j’ai choisi, consiste à ruser pour obtenir le mot de passe de la ligne. D’après ce que j’avais pu lire sur les forums OVH, il faut savoir que cette manière de faire vient avec quelques limitations d’usage comparée à une véritable solution VoIP. En effet, OVH vérifie que cette ligne n’est utilisée qu’à partir de votre réseau domestique. Il n’est à priori pas possible d’utiliser sa ligne depuis une application Android en étant connecté au réseau 4G. Les utilisateurs ayant tentés l’opération, ont vu les informations de connexion de leur ligne VoIP être réinitialisées, les obligeant ainsi à refaire la procédure de récupération des identifiants de connexion. En revanche, il est tout à fait possible d’utiliser la ligne depuis une application Android, avec son téléphone connecté à son réseau local. Du point de vue d’OVH, l’appel est passé depuis l’IP associée à la connexion internet et cela ne pose donc aucun problème. Si vous disposez donc d’un VPN vous permettant de vous connecter à votre réseau local, il devient alors possible d’utiliser la ligne téléphonique depuis l’extérieur, comme par exemple, depuis un pays étranger dans lequel vous n’auriez pas de réseau, mais simplement un accès à internet non restreint.

Passons maintenant à l’exposition succincte et non détaillée du processus de récupération des identifiants de connexion. À partir d’un modem OVH configuré et disposant de la ligne téléphonique activée et fonctionnelle, on commence par configurer un service dyndns pointant vers un nom de domaine en notre possession et sur lequel on fait tourner un petit bout de code ayant pour seul rôle de logger les informations provenant des requêtes entrantes. Une fois le service configuré, on sauvegarde la configuration du modem dans un fichier via la page prévue dans l’interface. Dans le fichier de configuration, on cherche la ligne correspondant aux identifiants de la ligne VoIP et on récupère le hash du mot de passe associé. On remplace ensuite le hash du mot de passe associé à la configuration de notre service dyndns par le hash du mot de passe de la ligne VoIP récupéré à l’étape précédente. Une fois le fichier modifié de cette manière, on procède à la restauration de la configuration du modem à partir du fichier que l’on vient de modifier. Une fois la nouvelle configuration en place, le modem va faire un appel vers notre service dydns pour l’informer de la configuration IP actuelle et utilisera dans la requête les informations d’authentification, à savoir, le mot de passe de la ligne VoIP. Il ne reste plus qu’à aller consulter les logs du service dyndns que nous avons mis en place pour y découvrir le mot de passe VoIP en clair. Une fois en possession de cette information, on peut alors configurer une application Android ou un SPA112 pour se connecter à la ligne téléphonique.

Sur ce point, je trouve dommage qu’OVH ne fournisse pas directement les informations de connexion, même en précisant par exemple, que la ligne téléphonique n’est utilisable que depuis l’adresse IP associée à la connexion internet fournie. Au passage, je remercie toutes les personnes qui ont échangé autour du processus à suivre et dont les discussions, posts après posts m’ont permis de reconstituer une solution fonctionnelle, et de profiter de la ligne téléphonique au sein de mon LAN comme je l’entendais.

Création d’un accès à l’API OVH

Afin de pouvoir générer un certificat wildcard via Let’s Encrypt pour un domaine géré par OVH, il est nécessaire de créer un accès à l’API OVH sur la page de création de token.

Les autorisations à accorder sont les suivantes:

GET /domain/zone/*
PUT /domain/zone/*
POST /domain/zone/*
DELETE /domain/zone/*

Une fois l’ensemble des informations renseignées et validées, la page nous génère les clés d’API que l’on prendra soin d’enregistrer dans son gestionnaire de mot de passe favori.

S’il doit être possible de lister les accès accordés et de les gérer quelque part dans les interfaces d’administration OVH, je n’ai pour l’instant pas trouvé une telle page (mais je n’ai pas non plus pris le temps d’aller à sa recherche).