Un petit rôle Ansible pour ddclient et les dynhosts OVH

Cet article a été publié il y a 3 ans 3 mois 19 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

J’en avais parlé lors de mon passage à la fibre, sans adresse IP fixe, il faut bricoler pour pouvoir garder un point d’entrée identifiable même quand la base de cette identifiant change. C’est le rôle du DNS dynamique, OVH propose évidemment ce service, et il est exploitable de différentes façons.

Un petit rappel du DNS dynamique, et du dynhost OVH

Eh oui, au final les « vrais » opérateurs qui proposent de l’adresse IPv4 fixe sont rares, et donc, aussi bien France qu’à l’étranger, quand on veut faire de l’Internet, et pas seulement le consommer, on a pas trop le choix, il faut bidouiller. Comme pour à peu près tous les services sur Internet, en particulier le web, on utilise des noms de domaine pour joindre ces services, le rôle du DNS étant, principalement, de traduire le nom en question par une adresse IP (le DNS –Domain Name System, si vous avez besoin de réviser— fait plein d’autres choses mais pas utiles pour cet article 😉 ).

Historiquement, quand on voulait faire du DNS dynamique, c’est à dire pouvoir changer automatiquement et régulièrement l’adresse IP associée à un nom (parfois toutes les 24h, à la grande époque de l’ADSL), on passait par des services dédiés à ça : No-IP, DynDNS, pour ne citer que ces deux mastodontes qui sont même souvent embarqués dans plusieurs routeurs du marché, y compris la Livebox de l’enfer pour DynDNS. Mais depuis quelques années, les fournisseurs de domaines plus classiques ont commencé à se doter d’outils permettant de faire le même travail. Quand on a déjà un domaine chez un fournisseur en France, pourquoi se disperser chez un autre fournisseur la plupart du temps américain ?

Et donc parmi eux, OVH. Sur votre zone DNS classique, vous pouvez paramétrer une ou plusieurs entrées dynamiques, c’est à dire modifiables rapidement et simplement par différents biais. C’est simple, via le manager, on on crée un utilisateur qui aura les permissions  sur le sous-domaine créé, ensuite on déclare l’entrée/sous-domaine avec une valeur existante. Et voilà, pour faire la mise à jour, un simple appel HTTPS sur une URL embarquant la nouvelle adresse IP à définir, et roulez jeunesse. Ça c’est la méthode de la documentation d’OVH, mais un confrère blogueur a fourni une méthode d’installation manuelle de ddclient pour arriver aux mêmes fins (et pour la blague, des recherches complémentaires m’ont fait tomber sur celui d’Arowan qui datait de 2016 😀 ).

Le faire plus d’une fois ? Ansible !!!

Cette dernière méthode m’a bien plu, parce qu’elle est beaucoup moins manuelle et artisanale que mon script bash avec sa tâche cron que j’avais installé historiquement chez ma maman. Mais elle reste quand même manuelle : installation du soft, modification de la configuration, redémarrage du service. Hors, il se trouve qu’en plus du setup chez ma mère, j’ai aussi la même chose à faire chez moi puisque mon passage à la fibre est une grosse régression aussi sur ce point. Et Orange est beaucoup plus agressif que NordNet, au final ma mère n’a jamais changé d’IP, alors qu’en deux mois j’en ai déjà « consommé » 4 avec l’agrume, qui en gros me change dès que la box redémarre/coupe. Très pénible donc, surtout lors des mises à jour non maîtrisables de la box.

Deux dynhost OVH sur deux domaines, deux installations pratiquement identiques de ddclient, l’une sur un Raspbian, l’autre sur un Debian. Eh oui, c’est une tâche pour Ansible ! En partant de la méthode ddclient manuelle, on a besoin d’avoir les identifiants du compte pour la modification, et la zone DNS. Le fichier de configuration sera donc un template contenant trois variables, qu’on peut appliquer soit dans un fichier de variables dédié, soit dans un groupe de variables dans l’inventaire, soit dans l’appel au rôle dans un playbook.

J’ai appelé mon rôle ddclient_ovh, rien de très original là-dedans, il fallait quand même que ça soit parlant parce que je l’ai rangé dans ma collection de rôles persos (que je ne partage pas forcément parce qu’il n’y a rien d’original et que vous trouverez certainement plus complets ailleurs — je ne teste pas grand chose en dehors des quelques serveurs sur lesquels je les exécute). Ce rôle a donc très peu d’étapes dans son arborescence. Commençons par le tasks/main.yml :

J’avais prévenu, c’est dramatiquement simple : installation de ddclient, application de la configuration avec un rechargement du service en cas de besoin. Je n’utilise pas de serveurs autres que Debian voire Ubuntu personnellement, je n’ai donc même pas pensé à inclure les autres possibilités dans les tâches, une piste d’amélioration peut-être, si j’ai la motivation.

Le template jinja templates/ddclient.conf.j2, là encore inspiré de l’article de Lucas, est d’une simplicité bien agréable :

Oui c’est tout. Ces variables, je les définis dans le fichier vars/main.yml :

À me relire, c’est peut-être superflu, on pourrait utiliser directement domain_*, mais bon, que voulez-vous, je vous ai pas déjà dit que j’étais mauvais ? Pour finir dans le strictement nécessaire, voici le handler, qu’on retrouve logiquement dans handlers/main.yml :

Idem, j’ai rajouté le passage d’enabled à yes uniquement dans le handler, sous Debian/Ubuntu le service est activé par défaut, sur d’autres systèmes ça ne sera pas forcément le cas, il aurait donc peut-être fallu s’en charger dans les tâches de base par principe.

Comme je l’ai précisé plus tôt, l’appel à ce rôle nécessite donc de paramétrer les trois variables domain_name, domain_login, domain_password, pour ça, je suis passé par l’inventaire :

Reste à faire un petit playbook des familles :

Et voilà 🙂 En analysant les logs de ddclient, avec le temps, voilà ce qu’on peut voir apparaitre :

Une petite explication ?

Oui, parce que j’aime bien comprendre ce que ça fait. ddclient va donc vérifier à intervalles plus ou moins régulier l’adresse IP publique, à partir d’un service qu’on lui indiquera, avec le protocole approprié. dans mon template on voit que j’utilise la méthode « web » et le service ifconfig.co/ip qui ne va renvoyer que le strict minimum comme résultat, à savoir l’adresse en question. Le protocole dyndns2, pour ce que j’ai pu en juger, correspond peu ou prou à la méthode qu’on utilise en passant par curl comme indiqué dans la doc OVH, d’où le fait de pouvoir l’utiliser ailleurs que pour DynDNS, ensuite, on indique que le serveur qui est www.ovh.com (le domaine utilisé dans la doc), et les identifiants. Voilà, rien de bien sorcier.

WARNING : en écrivant l’article et en vérifiant les infos, je percute que j’ai bien la mise à jour IPv4, mais pas IPv6, alors même que la machine virtuelle qui fait tourner le service en dispose et qu’un test curl retourne bien une IPv6. C’est parce que ddclient fonctionne en IPv4 par défaut. Il faut apparemment installer un paquet supplémentaire d’après le README, mais je ne sais pas si derrière, OVH va comprendre la réponse. Apparemment il est compliqué également de faire à la fois IPv4 et IPv6, et de manière générale le support d’IPv6 semble avoir encore besoin d’amour, il n’y a qu’à voir les issues pour s’en convaincre. De toute manière, vu comment fonctionne le pare-feu de la Livebox, autant que je me prépare à la remplacer d’abord avant de pouvoir exposer des services en IPv6 chez moi…

Une petite publication ?

Il faut encore pas mal de boulot pour en faire un vrai rôle communautaire publiable sur ansible-galaxy et/ou Github/Gitlab. Vous le savez, j’ai une flemme monumentale, et je suis à peu près certain qu’il existe déjà ce genre de choses ailleurs. Quoique peut-être pas, faudrait que je regarde avec Google parce qu’avec les termes « ansible ddclient ovh », Qwant me ressort mon dernier article en date sur Ansible 😀 Bon, disons qu’on va trouver un moment pour au moins le publier sur Github, même en l’état, et voir si les contributions pleuvent autant que pendant la tempête Bella ? 😀