À mon taff, nous utilisons le logiciel RANCID et j'en ai jamais parlé ici. Rattrapons cela. :D
RANCID est un logiciel qui permet d'exécuter des commandes sur des équipements de réseaux informatiques (commutateurs, routeurs, etc.) en automatisant le retrait de toutes les fioritures de ces derniers (bannière de présentation, pagination, etc.).
Il permet donc un premier niveau d'automatisation : exécuter des commandes, sauvegarder la configuration dans un dépôt git, etc.
Au final, RANCID est une surcouche à expect : lancer une commande, attendre / chercher tel motif dans la sortie, lancer une commande, chercher un motif, etc.
L'utilisation de git se configure dans la conf' principale, /etc/rancid/rancid.conf
, variable « RCSSYS ». Ensuite, il faut définir un (ou plusieurs) contenants : « LIST_OF_GROUPS="<NOM_GROUPE>"
» dans rancid.conf + /usr/lib/rancid/bin/rancid-cvs
depuis le compte utilisateur rancid pour créer l'arborescence. Le ou les dépôts seront stockés dans le homedir de l'utilisateur rancid (/var/lib/rancid
sur Debian).
La base de données des équipements réseaux est le fichier router.db
de chaque groupe / contenant. Format : <HOSTNAME>;<MODÈLE>;<ÉTAT>
. Mettre l'état à « down » permet d'ignorer un équipement temporairement hors service afin que RANCID ne timeout pas et n'envoie pas un email d'erreur.
En parlant d'emails : RANCID en envoie à deux adresses : rancid-admin-<NOM_GROUPE>
pour les erreurs et rancid-<NOM_GROUPE>
pour montrer son travail. Il faut donc configurer /etc/aliases
en conséquence. Nous n'avons pas trouvé le bout de configuration permettant de recevoir uniquement les emails d'erreurs donc nous avons configuré Exim (serveur d'emails sur la machine où est installé RANCID) pour jeter les emails de journalisation.
Pour prendre en charge de nouvelles marques et modèles d'équipements (Allied Telesis, H3C, Aruba, etc.), il suffit de récupérer des scripts nommés *login (authentification, désactivation de la pagination et des autres contraintes) et *rancid (enchaînement de plusieurs commandes d'affichage afin de récupérer toute la configuration et des états), de les ranger dans le dossier « bin » du homedir de l'utilisateur rancid puis de définir une correspondance entre un nom de modèle et les scripts dans /etc/rancid/rancid.types.conf
. Exemple pour Alied Telesys (dans router.db, on utilisera donc le modèle « at » ;) ) :
at;script;ATrancid
at;script;ATlogin
Parfois, c'est un peu plus compliqué (mais, les concepteurs de scripts donnent les instructions d'intégration). Pour un contrôleur Wi-Fi Aruba, il s'agit d'un module Perl. Il faut le stocker dans /usr/share/perl5/rancid
et remplir ainsi rancid.types.conf
(on charge le modèle et le script de sauvegarde, c'est simplement RANCID armé d'un modèle) :
aruba;module;aruba
aruba;login;clogin
aruba;script;rancid -t aruba
Le fichier .cloginrc
à la racine du homedir de l'utilisateur rancid permet de préciser l'identifiant et le mot de passe d'un équipement réseau (même si le mieux est d'utiliser une auth par clé SSH). Des regex minimalistes (glob) permettent d'affecter un identifiant à plusieurs équipements (exemple : add user lt* {<NOM_UTILISATEUR>}
concernera tous les équipements dont le nom commence par « lt »). On peut également définir des options et des actions (pour un équipement ou plusieurs) : add method * {ssh}
= se connecter en SSH à tous les équipements ; add noenable * {1}
: ne pas tenter de choper des droits supplémentaires ; etc.
Si l'on ne veut pas attendre CRON pour sauvegarder les configurations, on peut lancer leur récupération à la main :
su - rancid
rancid-run
Si l'on a plusieurs groupes, on peut préciser à rancid-run
le nom de celui que l'on veut sauvegarder.
Si l'on veut sauvegarder un seul équipement :
su - rancid
rancid-run -r <NOM_EQUIPEMENT>
En parlant de CRON, nous avons inhibé l'entrée proposée par défaut par le paquet Debian pour la remplacer par plusieurs qui lancent nos sauvegardes quand nous le voulons (chaque groupe a une fréquence / date de passage différente).
De même, je préconise d'effectuer un git pull avant rancid-run
au cas où quelqu'un modifierait le dépôt git (pour ajouter des équipements dans router.db, par exemple ou un autre script qui sauvegarde, dans le même dépôt git, des équipements résolument inattaquables avec RANCID).
Pour exécuter un enchaînement de commandes sur un équipement (ici, un modèle HP, sinon il faut adapter le nom du script *login ;) ) :
su - rancid
cd /usr/lib/rancid/bin
./h3clogin -c '<COMMANDES_SÉPARÉES_PAR_UNE_VIRGULE>' <NOM_ÉQUIPEMENT>
Exemple : ./h3clogin -c 'sys;undo info-center loghost 192.0.2.42;quit;save fo' lt01
(désactivation de l'envoi des journaux à un serveur de journalisation configuré dans une vie antérieure).
RANCID rajoute un « quit » automatiquement à la fin de la liste des commandes. ;) Donc, dans la liste des commandes, il faut juste prévoir les « quit » pour revenir au mode non privilégié. Si tu rajoutes un « quit » excédentaire, t'auras l'erreur « Error: EOF received » et un code retour différent de 0 (pas cool dans un script).
J'ignore comment lancer une commande sur tous les équipements d'un même modèle ou sur un ensemble d'équipements (pas de regex/glob possible). J'utilise une boucle shell pour encapsuler le script *login. :D
J'ai souvent entendu parler de rancid-killers, de remplaçants à RANCID, comme oxidized, mais, au final, boarf… RANCID fait le boulot, reste simple et, vu sa base conséquente d'utilisateurs, on trouve toujours les scripts *login et *rancid qui prennent en charge un matos improbable.
Si l'on souhaite une abstraction supplémentaire comme un langage plus descriptif genre sur telle interface configure le VLAN XXXX en mode access, ajoute telle ACL ici, etc., on peut utiliser Ansible (qui dispose de modules pour Arista, Cisco, Juniper, Mellanox, FRR, etc.) ou le char d'assaut Jerikan+Ansible.