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.

[Ansible] Liste des valeurs disponibles pour ansible_os_family

Petit pense-bête, pour éviter de perdre plusieurs dizaines de minutes à retrouver la liste des valeurs possibles pour la variable ansible_os_family dans ansible, après plusieurs semaines ou mois sans pratiquer.

La liste est par là:
ansible/ansible/module_utils/facts/system/distribution.py#L511

cmd#11 – GitHub – Clone de dépôt via HTTPS et token

De temps en temps, j’ai besoin de cloner l’un de mes dépôts GitHub, vers un poste de travail sur lequel je ne souhaite pas ou ne peut pas utiliser ma clef SSH pour réaliser l’opération. Dans ces cas là, je passe par la génération d’un token via Settings > Developer settings > Personal access tokens > Fined-grained tokens, auquel je ne n’assigne que l’autorisation « Content » avec « Read and Write », sur le dépôt concerné.

Avec une validité maximum d’un an, la sélection des dépôts concernés et une sélection minimale des permissions, je réduit ainsi grandement la surface d’exposition de mes dépôts. Une fois en possession du token généré, vient ensuite le moment de cloner le dépôt via git. Pour mémoire, voici la syntaxe à utiliser, par exemple, pour cloner mon dépôt yt-auto-dark:

git clone https://oauth2:<token>@github.com/vvision/yt-auto-dark.git

Voilà pour l’aide-mémoire.

Seul bémol de la solution, n’importe qui ayant accès au dépôt cloné pourra effectuer des modifications pendant toute la durée de validité du token, ou jusqu’à ce que ce dernier soit révoqué. A ne pas utiliser n’importe comment, n’importe où donc. En sacrifiant un peu de simplicité (et encore) et en fonction de l’environnement, on pourra préférer la génération d’une clef SSH spécifique à la machine, auquel on veillera bien à associer une pass phrase de qualité. On aura alors accès à tous nos dépôts, mais il faudra penser nous-même à retirer la clef des clefs autorisées lors de la décommission de la machine utilisée.

Bref, plusieurs solutions possibles en fonction des besoins et des environnements, à choisir en connaissance de cause.

Créer votre première céramique (en 3D et sans se salir)

Après une longue absence c’est l’heure du grand retour avec ce tutoriel d’une dizaine de minutes qui vous apprendra à prendre en main Blender pour réaliser une céramique japonaise.


Vous pouvez très bien adapter la texture et la forme de l’assiette à vos propres goûts et envies.

Bon visionnage !