V6 s’invite au déménagement

Un déménagement. Une idée simple quand on y pense: il suffit de déplacer des choses d’un point A vers un point B. Dans les faits, des objets à ranger dans des cartons en vu du transport, des meubles à vider, à déplacer, de l’aide à trouver (un meuble même vide, pèse son poids), le tout à planifier et à ordonnancer pour terminer à temps. Et bien sûr, au milieu de tout ça, des ordinateurs, switchs et router, bref, l’infrastructure qui héberge mon lot de service à arrêter, déplacer et à reconnecter ailleurs, possiblement dans un nouveau réseau. Au moment où j’écris ces lignes, pas loin de 24 mois se sont écoulés depuis que j’ai eu à déplacer mon homelab.

Occupé par l’organisation de mon déménagement, je n’avais pas pris le temps d’anticiper le déplacement de mon infra, en la migrant temporairement dans une machine virtuelle chez un hébergeur. Bien qu’ayant automatisé la majeure partie du déploiement, je savais que cela nécessiterait plusieurs vérifications, notamment que les processus de sauvegarde se soient bien remis en place. Même chose pour le renouvellement des certificats, sans parler des adaptations nécessaires sur les scripts ansible, si j’en avais profité pour passer sur une version plus récente de Debian. Bref, pas suffisamment de temps à dédier au sujet. J’ai donc attendu jusqu’au dernier moment, avant d’arrêter mon homelab et de déplacer ses composants, avec bien entendu, un temps d’indisponibilité dans l’intervalle, jusqu’à reconnecter le tout dans le nouveau réseau.

La bonne nouvelle, c’est que tout a redémarré correctement, pas de casse pendant le déplacement, pas de stockage corrompu, tout a fonctionné à merveille. La mauvaise, c’est que le réseau d’arrivée comportait des nouveautés ! Le réseau que je quittais était entièrement sous mon contrôle. En effet, j’avais réussi à utiliser mon propre router à la place de la livebox du FAI et je disposais alors d’une IPv4 dédiée. Dynamique, mais relativement fixe; avec un dynamique DNS bien configuré pour pouvoir contacter mes services, même en cas de changement d’IP. En changeant de réseau, je me retrouvais à devoir exposer mon homelab derrière une box de FAI et, oh surprise, j’ai vu arriver de l’IPv6, et découvert que le point d’entrée dans le réseau, la box du FAI, ne disposait pas d’une adresse IPv4 pour son seul usage, mais d’une IPv4 partagée entre plusieurs box. Cette technique portant le nom de CGNAT pour Carrier-Grade Network Address Translation.

Impossible donc de contacter mes services en v4, j’ai adapté mes plans pour faire fonctionner le tout en v6. Après quelques essais, la connectivité vers mon homelab était rétablie. Tout aurait pu s’arrêter là si je n’avais pas constaté, quelques jours plus tard, que mes services étaient inaccessibles depuis un réseau que j’utilisais régulièrement durant cette période. La raison la plus probable: pas d’IPv6 sur ce réseau et aucun mécanisme de compatibilité entre v6 et v4. Mes cours de réseaux sur IPv6 semblaient bien loin. Ni une, ni deux, j’ai donc enfourché mon renard de feu à la recherche de solutions à mon problème.

Après plusieurs lectures pour comprendre ce fameux CGNAT, je suis arrivé à la conclusion qu’il allait me falloir un point relais capable de recevoir du trafic en IPv4 et de le transférer vers mon réseau via IPv6. Je me suis alors souvenu que Google, dans sa plateforme cloud, propose des network load balancers intervenant au niveau de la couche TCP, soit bien plus bas que le proxy dont je me sers dans mon infrastructure pour faire de la terminaison SSL sur du trafic HTTPS. En continuant mes recherches autour de la notion de proxy passthrough, j’ai découvert que je pouvais configurer un serveur HAProxy, de telle sorte qu’il puisse recevoir du trafic HTTPS en IPv4 et IPv6 et le rediriger vers une adresse IPv6, sans que celui-ci ait besoin de toucher à la couche HTTPS, et donc sans avoir à reconfigurer les certificats de mes noms de domaines au niveau de ce proxy. Une fois connu, cela semble évident.

Au final, la solution aura été relativement simple et rapide à mettre en place. Commander un petit VPS disposant d’une IPv4, modifier les DNS pour faire pointer les noms de domaines vers ce serveur pour le trafic en v4, installer HAProxy et le configurer en mode proxy passthrough. Pour le trafic en v6, on peut au choix utiliser le même proxy, ou déclarer directement l’IPv6 du serveur cible dans les DNS. Cette solution m’aura donc permis de rétablir rapidement l’accès à mes services quel que soit le réseau (v4 ou v6), et surtout, avec pratiquement pas de modification du côté de mon infrastructure auto-hébergé.

Pour terminer, voici la configuration utilisée au niveau de HAProxy (/etc/haproxy/haproxy.cfg) pour mettre en œuvre la solution trouvée:

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
	ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
	ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
	ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
	timeout connect 5000
	timeout client  50000
	timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

frontend www_https
	bind *:443 v4v6
	mode tcp
	option tcplog
	default_backend backend_servers

backend backend_servers
	mode tcp
	# balance roundrobin
	option ssl-hello-chk
	# TODO: replace ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff with the target IPv6
	server server1 [ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:443 verify none

frontend http_in
	bind :::80 v4v6
	option forwardfor
	default_backend http_back

backend http_back
	# TODO: replace ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff with the target IPv6
	server server2 [ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:80

Sources:

Certifié

Depuis ce week-end, j’ai une nouvelle certification à mon actif, à savoir, la Google Professional Cloud DevOps Engineer. Le format de l’examen est classique, 50-60 questions sur le sujet, pas toujours des plus simples, 2 heures de temps, surveillance en ligne. Une jolie réussite pour ce début d’année 2025 et qui porte désormais mon nombre de certifications à 4.

Mon entrée dans le monde des certificats s’est fait en 2022, avec la Google Professional Cloud Developer. Après 3 ans de pratique pour mettre en place la nouvelle plateforme cloud d’un client, c’était la candidate idéale pour démarrer. Puis, avance rapide début 2024 où, après plusieurs semaines d’auto-formation pour améliorer ma compréhension de la technologie et pour atteindre mes objectifs annuels, je passe la Certified Kubernetes Application Developer (CKAD pour les intimes) de la Linux Foundation.

Plus tard à la fin août 2024, ce sera le renouvellement de ma certification Google Professional Cloud Developer. Avec seulement 2 ans de validité, le moment de repasser l’examen arrive plus rapidement qu’il n’y paraît. Pour ne pas refaire la même erreur qu’en 2022, je décide de capitaliser sur le travail déjà effectué pour rafraîchir ma mémoire et je passe à la fin novembre la certification Google Professional Cloud Architect.

Motivé par ces réussites, je découvre qu’en me formant pour ces deux certifications Google, j’ai déjà effectué presque 80% du parcours de formation recommandé pour la certification DevOps. Qu’à cela ne tienne, quelques heures d’études supplémentaires, me permettent d’empocher une nouvelle certification: la Google Professional Cloud DevOps Engineer.

Alors que j’écris ces quelques lignes, je me prends à sourire. Il y a quelques années, je ne voyais que peu d’intérêt à l’obtention de certifications et considérais, et considère toujours, l’expérience pratique comme bien supérieure. Qu’est-ce qui a changé me demanderez-vous ?

Continuer la lecture de « Certifié »

Contourner le filtrage web en entreprise

Je suis fatigué et irrité par les politiques de filtrage web des grandes entreprises qui, pour des raisons de sécurité ou par manque de confiance envers leurs employés, appliquent un filtrage bien trop agressif sur leur trafic web de sortie.

J’avais rencontré ce problème sur mon premier poste en sortant d’école. Tous les employés étaient d’ailleurs pris pour des étudiants, puisque l’entreprise utilisait des listes de filtrages en usage dans les universités françaises. Impossible donc de consulter la carte de l’enseigne de restauration du coin (Jamais compris le gain de sécurité). Plus embêtant était le blocage pur et simple de gist, ou d’outils similaires – ce qui est quand même fort dommage quand, au détour d’une discussion web sur un problème technique, tout le monde pointe vers une solution à laquelle vous n’avez pas accès.

Comme d’habitude dans ces cas-là, certains employés ont trouvé une solution pour simplement pouvoir faire leur travail sans qu’on leur mette constamment des bâtons dans les roues. A l’époque, l’intégralité de mon équipe avait configuré son poste de travail pour que le trafic passe par le même proxy que celui utilisé par les machines qui hébergeaient nos environnements de développement et de test. Proxy qui était pas ou peu filtré.

Je pensais naïvement qu’en presque 10 ans, les choses s’étaient améliorées, et pourtant, je suis à nouveau confronté aux mêmes problèmes idiots. Un exemple parmi d’autres: récemment, le système de surveillance du trafic réseau du client chez lequel j’interviens a décidé de bloquer le site web de npm, à savoir https://www.npmjs.com. Plus d’accès à la documentation (sauf à trouver le dépôt des sources). Terminé la récupération des dépendances en local… Le blocage fut heureusement de courte durée, mais bon, c’est rapidement une journée de travail perdue pour les personnes concernées. 

Autre exemple, impossible de faire des recherches sur les technologies WebGL, et tout ce qui tourne autour des modèles 3D dans le navigateur. Pourquoi donc, me direz-vous ? Où est le danger ? Ce coup là, le blocage est effectué car ces sujets sont assimilés au domaine du jeu vidéo et donc bloqués de peur que les employées passent leur journée à jouer. Bravo, vous venez par la même occasion de vous assurer que l’entreprise n’innovera pas dans ce domaine, ou avec difficulté.

En fait, le problème est en général tellement courant, qu’on finit par apprendre que pour pouvoir travailler, une équipe entière s’est fait installer une connexion internet domestique pour son propre usage.

Revenons à nos moutons, filtrage excessif du trafic web: ras-le-bol. Pas de droits d’admin sur ma machine, et installations limitées au catalogue de logiciels autorisés… Je dispose par contre d’une machine virtuelle chez l’un des grands fournisseurs mondiaux de cloud (il faut bien trouver une manière de travailler quand tout est bloqué). La solution: utiliser cette machine comme nœud de sortie pour mon trafic web.

Pour ce faire, je dispose bien entendu d’une entrée dans mon fichier .ssh/config, de la forme:

Host proxy
  HostName <ip_machine_distante>
  User <username>
  IdentityFile <chemin_vers_le_fichier_pem>

A partir de là, je vais donc lancer un proxy SOCKS via ssh avec la commande: ssh proxy -N -D 9090.
-N précise qu’aucune commande ne sera exécutée sur l’hôte distant et -D pour utiliser, ici le port 9090, comme port sur la machine local exposant le proxy SOCKS.

Deuxième étape: télécharger Firefox en version portable pour disposer d’un navigateur sur lequel j’ai la main sur la configuration des paramètres de proxy: https://portableapps.com/apps/internet/firefox_portable .

Enfin, configurer notre Firefox en version portable pour utiliser notre proxy SOCKS. Dans la partie préférence, rechercher le terme proxy. Choisir ensuite “Manual proxy configuration”, et renseigner “127.0.0.1” dans “SOCKS Host” et “9090” dans “Port”. Conserver la case “SOCKS v5” cochée et valider.

Enfin, vérifier que l’url précédemment bloquée est accessible.

Dernière étape, aller chercher un café et le siroter en parcourant un web non filtré. Hourra !

Pour essayer de simplifier le lancement du proxy, j’ai créé 2 scripts: proxy.bat et start_proxy.sh. proxy.bat me sert de point d’entrée pour lancer le script principal start_proxy.sh via git bash, simplement en cliquant sur le fichier dans l’explorateur Windows.

"C:\Program Files\Git\bin\bash.exe" --login -i -c "C:/Users/<username>/APPS/start_proxy.sh"
# pause

Le script start_proxy.sh est quant à lui une copie inspirée d’un script partagé au détour d’un gist.

#! /bin/bash
# Inspired by: https://gist.github.com/scy/6781836?permalink_comment_id=2777535#gistcomment-2777535

set -eu
SOCKS_PROXY_PORT=9090
HOST=proxy

socket=$(mktemp -t deploy-ssh-socket.XXXXXX)
rm ${socket} # delete socket file so path can be used by ssh

exit_code=0

cleanup () {
    # Stop SSH port forwarding process, this function may be
    # called twice, so only terminate port forwarding if the
    # socket still exists
    if [ -S ${socket} ]; then
        echo
        echo "Sending exit signal to SSH process"
        ssh -S ${socket} -O exit ${HOST}
    fi
    exit $exit_code
}

trap cleanup EXIT ERR INT TERM

echo "Starting SOCKS proxy on port ${SOCKS_PROXY_PORT}"
# https://mpharrigan.com/2016/05/17/background-ssh.html
# Start SSH port forwarding process
ssh -M -S ${socket} -fNT -o ExitOnForwardFailure=yes -D ${SOCKS_PROXY_PORT} ${HOST}

# -f : Run in the background before command execution.
# -N : Do not execute a remote command; this is useful for just forwarding ports.
# -T : Disable pseudo-tty allocation.
# -S <socketname>: Use a control socket.
# -M : Put control socket in master mode.
# ExitOnForwardFailure : if set to "yes", the connection shall be terminated 
#   if ssh cannot set up all requested dynamic, tunnel, local, and remote port forwardings,
#   (e.g. if either end is unable to bind and listen on a specified port).
# -D <port>: Port on which to expose on the local machine.

ssh -S ${socket} -O check ${HOST}
# -O check,exit : Control command

# launching a shell here causes the script to not exit and allows you
#   to keep the forwarding running for as long as you want.
#   I also like to customise the prompt to indicate that this isn't a normal shell.

bash --rcfile <(echo 'PS1="\nwith-ports> "')

Le tout fonctionne plutôt, avec parfois une perte de connexion en revenant de la pause déjeuner, après une interruption trop longue de la connexion internet, ou une période d’inactivité. Dans cette situation, je ferme simplement la fenêtre “cmd” où tournait le script, et je relance le tout par un double clic sur mon premier fichier.

Simple, efficace et surtout fonctionnel.

Déploiement d’un routeur R7000 supplémentaire sous FreshTomato

Ca y est, le domicile parentale est enfin équipé en fibre optique, en remplacement d’une connexion Adsl vieillissante. Si la qualité et la stabilité du signal s’est donc grandement améliorée, l’organisation physique du réseau a quelque peu changée. La box fibre du fournisseur d’accès se retrouve à la cave, avec l’impact que vous devinez sur la couverture du signal WiFi.

Pour palier au problème, et plutôt que de souscrire à une option de répétiteur WiFi facturée mensuellement, je me suis procuré un routeur R7000 d’occasion. Comme d’habitude, plutôt que de rester sur le firmware Netgear, j’ai immédiatement procédé à l’installation de FreshTomato, pour disposer d’un système bien plus à jour et de nombreuses fonctionnalités supplémentaires, en particulier: des règles de filtrage DNS directement au niveau du routeur.

Sans rentrer dans les détails, la procédure d’installation tient en quelques étapes:

Principales difficultés dans l’opération: ne pas oublier qu’il faut commencer par installer l’image initial et ensuite, trouver ou retrouver les couples utilisateur/mot de passe à utiliser pour chaque image. Ce qui nous donne:

  • initial: admin/@newdig ou root/admin
  • AIO: root/admin

Et pour de plus amples détails, direction la documentation en anglais: Installing FreshTomato.

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.