De part mon activité d’administrateur systèmes, je dois régulièrement me connecter en SSH à de nombreuses machines. 216 d’après mon fichier .ssh/config
, mais y a des alias et des machines virtuelles de développement dans le tas. Mais je dépasse largement les 150 machines.
J’ai longtemps — depuis que je l’ai découvert, il y a des années — utilisé concierge (écrit en Python) pour gérer ma configuration SSH. Un de ses grands avantages est le support de moteurs de templates, ce qui me permet de faire des boucles du genre :
{% for host in ('foo', 'bar') %}
Host {{ host }}
HostName {{ host }}.domain.tld
User luc
{% endfor %}
Le problème de concierge est qu’il n’est plus maintenu depuis plusieurs années, ce qui complique son installation sur des systèmes récents. Entre les dépendances pas bien fixées qui installent une version incompatibles de leurs dépendances à elles et certaines fonctionnalités de la bibliothèque standard qui ont migré dans des modules non listés en tant que dépendances… ça foirait à chaque installation.
Ma solution : forker concierge pour créer Bignole ! (une bignole est un terme d’argot pour… concierge 😁)
Le code est sur https://framagit.org/fiat-tux/bignole.
Au programme du fork :
- mise à jour des dépendances
- intégration directe des moteurs de templates sous forme de dépendances optionnelles au lieu de proposer des paquets distincts comme le fait concierge
- suppression du support de
libnotify
qui n’a jamais fonctionné chez moi : je voulais avoir rapidement un outil fonctionnel, pas passer des jours à débuguer - suite de tests automatisés via Gitlab CI (parce que la CI, c’est mon dada, j’adore ça)
- modernisation des outils de publication : exit les
setup.py
etsetup.cfg
, bonjourpyproject.toml
(bon, j’avoue, c’est parce que j’utilise ça dans Argos Panoptès et je sais pas faire autrement 😅)
Pour installer Bignole, avec jinja2
par exemple, c’est simple comme bonjour :
pip install 'bignole[jinja]'
Et si vous utilisez uv (et vous devriez car c’est fort pratique) :
uv tool install 'bignole[jinja]'
Après l’installation, vous aurez deux utilitaires : bignole
et bignole-check
(celui-ci ne servant qu’à vous indiquer si votre fichier contient une syntaxe correcte).
En faisant bignole --systemd
, vous aurez des instructions pour créer un service systemd qui surveillera votre fichier de configuration (~/.bignolerc
par défaut) et re-générera automatiquement votre .ssh/config
au moindre changement.
Pour le reste de l’utilisation, je vous laisse lire le README sur https://pypi.org/project/bignole/ 🙂
PS : oui, je connais le système des Tag
dans la config SSH (j’en utilise), mais une boucle reste pratique même en les utilisant. Par exemple :
{% for host in ('foo', 'bar') %}
Host {{ host }}
HostName {{ host }}.domain.tld
Tag perso
{% endfor %}
@luc@fiat-tux.fr Salut, en lisant ton article, j’ai tout de suite pensé à un outil qui te manque (peu être) : https://github.com/azlux/ssh-prompter . Il permet d’avoir une TUI rapide et sympa pour les personnes ayant pas mal de machines (1700 au boulot).
Réponse à distance
URL du commentaire initial
Votre profil
@azlux
C’est sympa, mais ça va encore pour moi, je connais mes machines par cœur, et zsh m’aide à compléter/corriger les noms 🙂
Mais oui, à 1700 machines, ça doit bien servir 😅
@luc
Merci pour la découverte de uv!
Réponse à distance
URL du commentaire initial
Votre profil
@e_jim
De rien !
C’est vraiment LE truc pratique pour installer des outils python sans pourrir sa machine, j’adore !
@luc Pourquoi le
.ssh/config
n’utilise-t-il pas un vrai langage de programmation, avec boucles, fonctions, et tests?Réponse à distance
URL du commentaire initial
Votre profil
@monnier
Sans doute parce que c’est compliqué ? Et que les dévs préfèrent se consacrer à la sécurité de SSH plutôt que d’introduire des fonctionnalités qui ne serviront pas à 90% des gens ?
Enfin, si j’étais dév de SSH, c’est ce que je dirais 🤔