Une PKI hors ligne renforce la sécurité en isolant physiquement l’autorité de certification des menaces réseau. Une YubiKey est une solution économique pour stocker un certificat racine. Vous avez également besoin d’un environnement isolé pour les opérations sur l’autorité de certification racine.

Ce billet décrit un système PKI hors ligne utilisant les composants suivants :

• 2 YubiKeys pour l’autorité de certification racine (avec une validité de 20 ans) ;
• 1 YubiKey pour l’autorité de certification intermédiaire (avec une validité de 5 ans) ;
• 1 carte Libre Computer Sweet Potato comme nano-ordinateur isolé.

Si nécessaire, il est possible d’ajouter plus de YubiKeys comme sauvegarde de l’autorité de certification racine. Ce n’est pas utile pour l’autorité de certification intermédiaire car vous pouvez en générer une nouvelle si l’actuelle est détruite.

La partie logicielle

offline-pki est une petite application Python pour gérer une PKI hors ligne. Elle s’appuie sur yubikey-manager pour gérer les YubiKeys et sur cryptography pour les opérations cryptographiques non exécutées par les YubiKeys. L’application a certains choix de conception opiniâtres. Notamment, la cryptographie est codée en dur pour utiliser la courbe elliptique NIST P-384.

La première étape consiste à réinitialiser toutes vos YubiKeys :

$ offline-pki yubikey reset
This will reset the connected YubiKey. Are you sure? [y/N]: y
New PIN code:
Repeat for confirmation:
New PUK code:
Repeat for confirmation:
New management key ('.' to generate a random one):
WARNING[pki-yubikey] Using random management key: e8ffdce07a4e3bd5c0d803aa3948a9c36cfb86ed5a2d5cf533e97b088ae9e629
INFO[pki-yubikey]  0: Yubico YubiKey OTP+FIDO+CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[yubikit.management] Device config written
INFO[yubikit.piv] PIV application data reset performed
INFO[yubikit.piv] Management key set
INFO[yubikit.piv] New PUK set
INFO[yubikit.piv] New PIN set
INFO[pki-yubikey] YubiKey reset successful!

Ensuite, générez l’autorité de certification racine et créez autant de copies que vous voulez :

$ offline-pki certificate root --permitted example.com
Management key for Root X:
Plug YubiKey "Root X"...
INFO[pki-yubikey]  0: Yubico YubiKey CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[yubikit.piv] Data written to object slot 0x5fc10a
INFO[yubikit.piv] Certificate written to slot 9C (SIGNATURE), compression=True
INFO[yubikit.piv] Private key imported in slot 9C (SIGNATURE) of type ECCP384
Copy root certificate to another YubiKey? [y/N]: y
Plug YubiKey "Root X"...
INFO[pki-yubikey]  0: Yubico YubiKey CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[yubikit.piv] Data written to object slot 0x5fc10a
INFO[yubikit.piv] Certificate written to slot 9C (SIGNATURE), compression=True
INFO[yubikit.piv] Private key imported in slot 9C (SIGNATURE) of type ECCP384
Copy root certificate to another YubiKey? [y/N]: n

Vous pouvez examiner le résultat :

$ offline-pki yubikey info
INFO[pki-yubikey]  0: Yubico YubiKey CCID 00 00
INFO[pki-yubikey] SN: 23854514
INFO[pki-yubikey] Slot 9C (SIGNATURE):
INFO[pki-yubikey]   Private key type: ECCP384
INFO[pki-yubikey]   Public key:
INFO[pki-yubikey]     Algorithm:  secp384r1
INFO[pki-yubikey]     Issuer:     CN=Root CA
INFO[pki-yubikey]     Subject:    CN=Root CA
INFO[pki-yubikey]     Serial:     1
INFO[pki-yubikey]     Not before: 2024-07-05T18:17:19+00:00
INFO[pki-yubikey]     Not after:  2044-06-30T18:17:19+00:00
INFO[pki-yubikey]     PEM:
-----BEGIN CERTIFICATE-----
MIIBcjCB+aADAgECAgEBMAoGCCqGSM49BAMDMBIxEDAOBgNVBAMMB1Jvb3QgQ0Ew
HhcNMjQwNzA1MTgxNzE5WhcNNDQwNjMwMTgxNzE5WjASMRAwDgYDVQQDDAdSb290
IENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAERg3Vir6cpEtB8Vgo5cAyBTkku/4w
kXvhWlYZysz7+YzTcxIInZV6mpw61o8W+XbxZV6H6+3YHsr/IeigkK04/HJPi6+i
zU5WJHeBJMqjj2No54Nsx6ep4OtNBMa/7T9foyMwITAPBgNVHRMBAf8EBTADAQH/
MA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAwNoADBlAjEAwYKy/L8leJyiZSnn
xrY8xv8wkB9HL2TEAI6fC7gNc2bsISKFwMkyAwg+mKFKN2w7AjBRCtZKg4DZ2iUo
6c0BTXC9a3/28V5aydZj6rvx0JqbF/Ln5+RQL6wFMLoPIvCIiCU=
-----END CERTIFICATE-----

Ensuite, vous pouvez créer un certificat intermédiaire avec offline-pki yubikey intermediate et l’utiliser pour signer des certificats en fournissant leur CSR à offline-pki certificate sign. Soyez prudent et inspectez la CSR avant de la signer, car seul le nom du sujet peut être remplacé. Consultez la documentation pour plus de détails. Obtenez les options disponibles en utilisant l’option --help.

La partie matérielle

Pour garantir que les opérations sur les autorités de certification racine et intermédiaire sont isolées du réseau, une solution économique consiste à utiliser une carte ARM64. Le Libre Computer Sweet Potato est une alternative plus ouverte au célèbre Raspberry Pi¹.

J’interagis avec lui via un convertisseur USB vers série :

$ tio /dev/ttyUSB0
[16:40:44.546] tio v3.7
[16:40:44.546] Press ctrl-t q to quit
[16:40:44.555] Connected to /dev/ttyUSB0
GXL:BL1:9ac50e:bb16dc;FEAT:ADFC318C:0;POC:1;RCY:0;SPI:0;0.0;CHK:0;
TE: 36574

BL2 Built : 15:21:18, Aug 28 2019. gxl g1bf2b53 - luan.yuan@droid15-sz

set vcck to 1120 mv
set vddee to 1000 mv
Board ID = 4
CPU clk: 1200MHz
[…]

L’assemblage Nix

Pour coller tout ensemble, j’utilise Nix avec un Flake fournissant :

• un paquet pour l’application offline-pki, avec la complétion pour le shell ;
• un shell de développement, incluant une version éditable de l’application offline-pki ;
• un module NixOS pour configurer la PKI, réinitialisant le système à chaque démarrage ;
• une image QEMU pour les tests ;
• une image de carte SD à utiliser sur le Sweet Potato ou une autre carte ARM64.

# Exécuter localement l'application
nix run github:vincentbernat/offline-pki -- --help
# Exécuter l'application dans une machine virtuelle QEMU
nix run github:vincentbernat/offline-pki\#qemu
# Construire l'image d'une carte SD pour Sweet Potato ou un Raspberry Pi
nix build --system aarch64-linux github:vincentbernat/offline-pki\#sdcard.potato
nix build --system aarch64-linux github:vincentbernat/offline-pki\#sdcard.generic
# Obtenir un shell de développement avec l'application
nix develop github:vincentbernat/offline-pki

Cisco pyATS est un outil pour l’automatisation et le test du réseau. Il comprend, entre autres, un ensemble d’analyseurs et de modèles multi-vendeurs open-source, Genie Parser. Il dispose de 2700 analyseurs pour diverses commandes sur de nombreux systèmes. Sur le papier, cela semble être un excellent outil !

>>> from genie.conf.base import Device
>>> device = Device("router", os="iosxr")
>>> # Hack pour analyser le résultat d'une commande sans se connecter à l'équipement
>>> device.custom.setdefault("abstraction", {})["order"] = ["os", "platform"]
>>> cmd = "show route ipv4 unicast"
>>> output = """
... Tue Oct 29 21:29:10.924 UTC
...
... O    10.13.110.0/24 [110/2] via 10.12.110.1, 5d23h, GigabitEthernet0/0/0/0.110
... """
>>> device.parse(cmd, output=output)
{'vrf': {'default': {'address_family': {'ipv4': {'routes': {'10.13.110.0/24': {'route': '10.13.110.0/24',
       'active': True,
       'route_preference': 110,
       'metric': 2,
       'source_protocol': 'ospf',
       'source_protocol_codes': 'O',
       'next_hop': {'next_hop_list': {1: {'index': 1,
          'next_hop': '10.12.110.1',
          'outgoing_interface': 'GigabitEthernet0/0/0/0.110',
          'updated': '5d23h'}}}}}}}}}}

Première déception : pyATS est sous licence propriétaire et les sources ne sont pas disponibles. C’est assez ennuyeux si vous rencontrez des problèmes en dehors de Genie Parser. Par exemple, bien que pyATS utilise la commande ssh, il ne peut pas exploiter mon fichier ssh_config : pyATS résout les noms d’hôtes avant de les fournir à ssh. Il n’est pas prévu de publier pyATS sous licence libre. 🤨

Ensuite, Genie Parser a deux problèmes :

1. Les modèles de données utilisés dépendent du vendeur et du système d’exploitation, alors que la documentation indique le contraire. Par exemple, le modèle de données utilisé pour les interfaces IPv4 est différent entre NX-OS et IOS XR.
2. Les analyseurs s’appuient sur des expressions régulières ligne par ligne pour extraire les données et sur une logique implémentée en Python. Tout cela est fragile et peut se briser silencieusement.

Pour illustrer le deuxième point, supposons que la sortie de la commande show ipv4 vrf all interface soit :

Loopback10 is Up, ipv4 protocol is Up
  Vrf is default (vrfid 0x60000000)
  Internet protocol processing disabled
Loopback30 is Up, ipv4 protocol is Down [VRF in FWD reference]
  Vrf is ran (vrfid 0x0)
  Internet address is 203.0.113.17/32
  MTU is 1500 (1500 is available to IP)
  Helper address is not set
  Directed broadcast forwarding is disabled
  Outgoing access list is not set
  Inbound  common access list is not set, access list is not set
  Proxy ARP is disabled
  ICMP redirects are never sent
  ICMP unreachables are always sent
  ICMP mask replies are never sent
  Table Id is 0x0

Parce que l’expression régulière pour analyser un nom d’interface ne s’attend pas aux données supplémentaires après l’état de l’interface, Genie Parser ignore la ligne qui commence la définition de Loopback30 et analyse ainsi la sortie¹ :

{
  "Loopback10": {
    "int_status": "up",
    "oper_status": "up",
    "vrf": "ran",
    "vrf_id": "0x0",
    "ipv4": {
      "203.0.113.17/32": {
        "ip": "203.0.113.17",
        "prefix_length": "32"
      },
      "mtu": 1500,
      "mtu_available": 1500,
      "broadcast_forwarding": "disabled",
      "proxy_arp": "disabled",
      "icmp_redirects": "never sent",
      "icmp_unreachables": "always sent",
      "icmp_replies": "never sent",
      "table_id": "0x0"
    }
  }
}

Bien que ce défaut soit simple à corriger, il s’agit d’une bataille difficile. Toute variation existante ou future dans la sortie d’une commande peut déclencher un bogue similaire non détecté, malgré la bonne couverture de tests. J’ai signalé et corrigé plusieurs autres erreurs d’analyse « silencieuses » : #516, #529 et #530. Une alternative plus robuste aurait été d’utiliser TextFSM et de produire un avertissement lorsque certaines sorties ne sont pas reconnues, comme le fait Batfish, un outil d’analyse de configurations.

À l’avenir, nous pourrons nous appuyer sur YANG pour l’extraction de données, mais il n’est actuellement pas largement pris en charge par le parc actuel. SNMP reste une possibilité valable, mais de nombreuses informations ne sont pas accessibles via ce protocole. En attendant, je vous conseille de n’utiliser Genie Parser qu’avec une grande prudence.

J’utilise awesome depuis 10 ans. Il s’agit d’un gestionnaire de fenêtres à tuiles, configurable et extensible avec le langage Lua. L’utilisation d’un langage de programmation polyvalent pour configurer chaque aspect est une arme à double tranchant. Par paresse et à cause de la difficulté apparente d’adapter ma configuration d’environ 3000 lignes aux nouvelles versions, je suis resté coincé avec la version 3.4, dont la dernière version date de 2013.

Le gestionnaire de fenêtres n’est qu’une partie d’un environnement de bureau. Il existe plusieurs options pour les autres composants. Je les présente également dans ce billet.

i3 : le gestionnaire de fenêtres

i3 est un gestionnaire de fenêtres à tuiles (« tiling window manager ») minimaliste. Sa documentation peut être lue du début à la fin en moins d’une heure. i3 organise les fenêtres dans un arbre. Chaque nœud intermédiaire contient une ou plusieurs fenêtres et possède une orientation et une disposition. Ces informations permettent d’arbitrer la position des fenêtres. i3 propose trois dispositions : fractionnée (split), empilée (stacking) et à onglets (tabbed). Elles sont présentées dans la capture d’écran ci-dessous :

La plupart des autres gestionnaires de fenêtres à tuiles, y compris awesome, utilisent des dispositions prédéfinies. Ils présentent généralement une zone importante pour la fenêtre principale et une seconde zone découpée entre les autres fenêtres. Ces dispositions peuvent être légèrement modifiées, mais vous vous en tenez généralement à une ou deux d’entre elles. Lorsqu’une nouvelle fenêtre est ajoutée, le comportement est assez prévisible. De plus, vous pouvez parcourir les différentes fenêtres sans trop réfléchir car elles sont ordonnées.

i3 est plus flexible grâce à sa capacité à construire n’importe quelle disposition à la volée, mais cela peut déconcerter car vous devez visualiser l’arbre dans votre tête. Au début, il n’est pas rare de se retrouver avec une arborescence complexe comportant de nombreux conteneurs imbriqués superflus. De plus, vous devez naviguer dans les fenêtres à l’aide de directions. Il faut un certain temps pour s’y habituer.

J’ai configuré une disposition en deux parties pour Emacs et quelques terminaux, mais la plupart des autres espaces de travail utilisent des onglets. Je n’utilise pas la disposition par empilement. Vous pouvez trouver de nombreux scripts essayant d’émuler d’autres gestionnaires de fenêtres à tuiles, mais j’ai essayé de ne pas me laisser tenter dès le début et de prendre le temps de m’habituer. i3 peut également sauvegarder et restaurer les dispositions, ce qui est une fonctionnalité assez puissante.

Ma configuration est proche de la configuration par défaut avec moins de 200 lignes.

le compagnon i3 : le chaînon manquant

La philosophie de i3 est de rester minimaliste et de laisser l’utilisateur implémenter les fonctionnalités manquantes en utilisant un protocole de communication (« IPC ») :

Ne pas ajouter de complexité supplémentaire lorsque cela peut être évité. Nous sommes généralement satisfaits de l’ensemble des fonctionnalités de i3 et nous nous concentrons plutôt sur la correction des bogues et la maintenance de la stabilité. De nouvelles fonctionnalités ne seront donc envisagées que si les avantages l’emportent sur la complexité supplémentaire, et nous encourageons les utilisateurs à mettre en œuvre des fonctionnalités en utilisant le protocole IPC chaque fois que cela est possible.

— Introduction au gestionnaire de fenêtres i3

Bien que cela ne soit pas aussi versatile qu’un langage intégré, c’est suffisant pour de nombreux cas. De plus, comme les fonctionnalités de haut niveau sont souvent subjectives, les déléguer à de petits morceaux de code faiblement couplés les rend plus faciles à maintenir. Des bibliothèques existent à cet effet dans plusieurs langages. Les utilisateurs ont publié de nombreux scripts pour étendre i3 : mise en page automatique et promotion de fenêtres pour imiter le comportement d’autres gestionnaires de fenêtres, remplacement de fenêtres pour placer une nouvelle application au-dessus du terminal qui la lance et passage d’une fenêtre à l’autre avec Alt+Tab.

Au lieu de maintenir un script pour chaque fonctionnalité, j’ai tout centralisé dans un seul processus Python, i3-companion, utilisant asyncio et la bibliothèque i3ipc-python. Chaque fonctionnalité est confinée dans une fonction. Il implémente les composants suivants :

Rendre un espace de travail exclusif à une application

Lorsqu’un espace de travail contient Emacs ou Firefox, j’aimerais que les autres applications se placent dans un autre espace de travail, à l’exception du terminal qui est autorisé à « envahir » n’importe quel espace de travail. La fonction workspace_exclusive() surveille les nouvelles fenêtres et les déplace si nécessaire vers un espace de travail vide ou contenant la même application déjà en cours d’exécution.

Implémenter une console Quake

La fonction quake_console() implémente une console déroulante disponible depuis n’importe quel espace de travail. Elle peut être activée avec Mod+`. Elle utilise le mécanisme de scratchpad.

Alterner entre les deux derniers espaces de travail sur un écran

Avec la commande workspace back_and_forth, on peut demander à i3 de passer à l’espace de travail précédent. Cependant, cette fonctionnalité n’est pas limitée à l’écran actuel. Je préfère avoir un raccourci clavier pour passer à l’espace de travail sur l’écran d’à côté et un autre pour passer à l’espace de travail précédent sur le même écran. Ce comportement est mis en place dans la fonction previous_workspace() en conservant un historique par écran.

Créer un nouvel espace de travail vide ou déplacer une fenêtre vers un espace de travail vide

Pour créer un nouvel espace de travail vide ou y déplacer une fenêtre, vous devez trouver un emplacement non utilisé et invoquer le raccourci pour workspace number 4 ou move container to workspace number 4. La fonction new_workspace() trouve un emplacement libre et l’utilise comme espace de travail cible.

Redémarrer certains services lors d’un changement de configuration des écrans

Lors de l’ajout ou de la suppression d’un écran, certaines actions doivent être exécutées : rafraîchir le fond d’écran, redémarrer certains composants incapables d’adapter leur configuration par eux-mêmes, etc. i3 déclenche un événement à cet effet. La fonction output_update() fusionne plusieurs événements consécutifs et vérifie s’il y a un réel changement avec la bibliothèque de bas niveau xcffib.

Je détaillerai les autres fonctionnalités au fur et à mesure de ce billet. Concernant la partie technique, chaque fonction est décorée avec les événements auxquels elle doit réagir :

@on(CommandEvent("previous-workspace"), I3Event.WORKSPACE_FOCUS)
async def previous_workspace(i3, event):
    """Go to previous workspace on the same output."""

La classe d’évènements CommandEvent() correspond à ma façon d’envoyer une commande au compagnon, en utilisant soit i3-msg -t send_tick ou en liant un raccourci à une commande nop. Cette dernière est utilisée pour éviter d’invoquer un shell et un processus i3-msg juste pour envoyer un message. Le compagnon écoute les événements liés aux raccourcis clavier et vérifie si c’est une commande nop.

bindsym $mod+Tab nop "previous-workspace"

Il existe d’autres décorateurs pour éviter la duplication du code : @debounce() pour fusionner plusieurs appels consécutifs, @static() pour définir une variable statique, et @retry() pour relancer une fonction en cas d’échec. Le script entier fait un peu plus de 1000 lignes. Je pense que cela vaut la peine de le lire car je suis assez satisfait du résultat. 🦚

dunst : le démon de notification

Contrairement à awesome, i3 ne dispose pas d’un système de notification intégré. Dunst est un démon de notification léger. J’utilise une version modifiée avec le support HiDPI pour X11 et la recherche récursive des icônes. Le compagnon i3 a une fonction auxiliaire, notify(), pour envoyer des notifications en utilisant DBus. container_info() et workspace_info() l’utilisent pour afficher des informations sur le conteneur ou l’arbre d’un espace de travail.

polybar : la barre de statut

i3 inclut i3bar, une barre de statut polyvalente, mais j’ai opté pour Polybar. Un script exécute une instance pour chaque écran.

Le premier module est le support intégré pour les espaces de travail i3. Pour ne pas avoir à se rappeler quelle application est en cours d’exécution dans un espace de travail, le compagnon i3 renomme les espaces de travail pour inclure une icône pour chaque application. Cette opération est effectuée par la fonction workspace_rename(). Les icônes proviennent du projet Font Awesome. Je maintiens manuellement la correspondance entre les applications et les icônes. C’est un peu lourd, mais c’est très joli.

Pour le CPU, la mémoire, la luminosité, la batterie, le disque et le volume sonore, je m’appuie sur les modules intégrés. Le script lançant Polybar génère la liste des systèmes de fichiers à surveiller et ils ne sont affichés que lorsque l’espace disponible est faible. L’icône de la batterie devient rouge et clignote lentement lorsqu’elle est à court d’énergie. Consultez ma configuration de Polybar pour plus de détails.

Pour les statuts du Bluetooth, du réseau et des notifications, j’utilise le module ipc de Polybar : la prochaine version permet de recevoir un texte arbitraire via le canal IPC. Le module est défini avec une seule commande à exécuter au démarrage pour restaurer le dernier statut.

[module/network]
type = custom/ipc
hook-0 = cat $XDG_RUNTIME_DIR/i3/network.txt 2> /dev/null
initial = 1

Il peut être mis à jour avec la commande polybar-msg action "#network.send.XXXX". Dans le compagnon i3, le décorateur @polybar() prend la chaîne retournée par une fonction et pousse la mise à jour à travers la chaussette IPC.

Le compagnon i3 réagit aux signaux DBus pour mettre à jour les icônes Bluetooth et réseau. Le décorateur @on() accepte un objet DBusSignal():

@on(
    StartEvent,
    DBusSignal(
        path="/org/bluez",
        interface="org.freedesktop.DBus.Properties",
        member="PropertiesChanged",
        signature="sa{sv}as",
        onlyif=lambda args: (
            args[0] == "org.bluez.Device1"
            and "Connected" in args[1]
            or args[0] == "org.bluez.Adapter1"
            and "Powered" in args[1]
        ),
    ),
)
@retry(2)
@debounce(0.2)
@polybar("bluetooth")
async def bluetooth_status(i3, event, *args):
    """Update bluetooth status for Polybar."""

Le milieu de la barre est occupé par la date et la météo. Cette dernière utilise également le mécanisme IPC, mais la source est un script Python déclenché régulièrement.

Je n’utilise pas la zone de notification intégrée à Polybar. Les icônes sont généralement hideuses et se comportent toutes différemment. Il y a quelques années, GNOME a supprimé la zone de notification. La plupart des problèmes sont résolus par le protocole Status Notifier Item basé sur DBus. Toutefois, Polybar ne prend pas en charge celui-ci. L’implémentation des icônes Bluetooth et réseau, y compris l’affichage des notifications en cas de changement, prend environ 200 lignes dans le compagnon i3. J’ai pu apprendre un peu comment fonctionne DBus et j’obtiens exactement les informations que je veux.

picom : le compositeur

J’aime avoir des terminaux légèrement transparents et réduire l’opacité des fenêtres inactives. Ces tâches nécessitent un compositeur¹. picom est un compositeur léger. Il fonctionne bien dans mon cas, mais il peut nécessiter quelques ajustements en fonction de votre carte graphique². Contrairement à awesome, i3 ne gère pas la transparence, donc le compositeur doit décider l’opacité de chaque fenêtre. Consultez ma configuration pour plus de détails.

systemd : le gestionnaire de services

J’utilise systemd pour démarrer i3 et les différents services qui l’entourent. Mon script xsession ne définit que quelques variables d’environnement et laisse systemd s’occuper de tout le reste. Jetez un coup d’œil à cet article de Michał Góral pour en connaître les raisons. Notamment, chaque composant peut être facilement redémarré et leurs sorties ne sont pas mélangées dans le fichier ~/.xsession-errors³.

J’utilise un démarrage en deux étapes : i3.service dépend de xsession.target pour démarrer les services avant i3 :

[Unit]
Description=X session
BindsTo=graphical-session.target
Wants=autorandr.service
Wants=dunst.socket
Wants=inputplug.service
Wants=picom.service
Wants=pulseaudio.socket
Wants=policykit-agent.service
Wants=redshift.service
Wants=spotify-clean.timer
Wants=ssh-agent.service
Wants=weather.service
Wants=weather.timer
Wants=xiccd.service
Wants=xsettingsd.service
Wants=xss-lock.service

Ensuite, i3 active la seconde étape via i3-session.target:

[Unit]
Description=i3 session
BindsTo=graphical-session.target
Wants=wallpaper.service
Wants=wallpaper.timer
Wants=polybar.service
Wants=i3-companion.service
Wants=misc-x.service

Jetez un œil à mes fichiers de configuration pour plus de détails.

rofi : le lanceur d’applications

Rofi est un lanceur d’applications. Son apparence peut être modifiée en utilisant un langage semblable à CSS et il est livré avec plusieurs thèmes. Regardez ma configuration pour le mien.

Il peut également faire office de menu. J’ai écrit un script pour contrôler un lecteur multimédia et un autre pour sélectionner le réseau sans fil. C’est une application plutôt flexible.

xss-lock et i3lock : le verrouillage de la session

i3lock permet de verrouiller la session. xss-lock l’invoque de manière fiable en cas d’inactivité ou avant une mise en veille. Pour l’inactivité, il utilise les événements XScreenSaver. Le délai est configuré via la commande xset s. Le verrouillage peut être instantané avec xset s activate. Les applications X11 savent comment le désactiver. J’ai également développé une petite application de fondu au noir qui est exécutée 20 secondes avant le verrouillage pour me donner une chance de bouger la souris si je ne suis pas absent⁴. Jetez un coup d’oeil à mon script de configuration.

Les autres composants

• autorandr est un outil qui détecte les écrans connectés, les compare à un ensemble de profils et les configure avec xrandr.

• inputplug exécute un script pour chaque nouvelle souris et clavier branchés. Regardez ma configuration pour avoir une idée des possibilités.

• xsettingsd fournit des paramètres aux applications X11, un peu comme xrdb mais il notifie les applications des changements. L’utilisation principale est de configurer les paramètres Gtk et DPI. Lisez mon article sur le support HiDPI sur Linux avec X11 pour les détails.

• Redshift ajuste la température des couleurs de l’écran en fonction de l’heure de la journée.

• maim est un utilitaire pour faire des captures d’écran. J’utilise Prt Scn pour déclencher une capture d’écran d’une fenêtre ou d’une zone spécifique et Mod+Prt Scn pour capturer le bureau entier dans un fichier. Consultez le script associé pour plus de détails.

• J’ai une collection de fonds d’écran que je fais tourner toutes les heures. Un script les sélectionne avec un algorithme neuronal particulièrement élaboré et les assemble sur les configurations multi-écrans. Le fond d’écran sélectionné est réutilisé par i3lock.

Il existe de nombreuses ressources pour l’automatisation du réseau avec Ansible. La plupart d’entre elles n’exposent que les premières étapes ou se limitent à un champ d’application réduit. Elles donnent peu d’indications sur la manière d’aller plus loin. Les environnements réseau réels peuvent être vastes, polyvalents, hétérogènes et remplis d’exceptions. L’absence d’exemples concrets de déploiements Ansible, contrairement à Puppet et SaltStack, conduit de nombreuses équipes à élaborer des solutions fragiles et incomplètes.

Nous avons publié sous une licence libre notre tentative pour pallier ce manque :

• Jerikan, un outil pour construire des fichiers de configuration à partir d’une source de vérité unique et de modèles Jinja2, ainsi que son intégration dans GitLab ;
• un playbook Ansible pour déployer ces fichiers de configuration sur les équipements réseau ;
• les données de configuration et les modèles pour nos centres de données, aujourd’hui fermés, à San Francisco et en Corée du Sud, couvrant de nombreux fournisseurs (Facebook Wedge 100, Dell S4048 et S6010, Juniper QFX 5110, Juniper QFX 10002, Cisco ASR 9001, Cisco Catalyst 2960, serveurs de console Opengear et serveurs Linux) et de nombreuses fonctionnalités (approvisionnement, routage BGP vers l’hôte, routage Internet, réseau d’administration séparé, configuration DNS, intégration avec NetBox et les IRR).

Voici une démo pour l’ajout d’un nouveau peering:

Ce travail est l’œuvre collective de Cédric Hascoët, Jean-Christophe Legatte, Loïc Pailhas, Sébastien Hurtel, Tchadel Icard et Vincent Bernat. Nous sommes l’équipe réseau de Blade, une société française exploitant Shadow, un produit de PC dans les nuages. En mai 2021, notre société a été rachetée par Octave Klaba et l’infrastructure est en cours de transfert vers OVHcloud, sauvant ainsi Shadow en tant que produit, mais rendant notre équipe superflue.

Notre réseau comptait environ 800 équipements, répartis sur 10 centres de données avec plus de 2,5 Tbps de bande passante disponible en sortie. Le matériel publié est donc un exemple substantiel de gestion d’un réseau de taille moyenne à l’aide d’Ansible. Nous avons laissé de côté la configuration de nos centres de données plus anciens pour rendre le résultat final plus lisible, tout en conservant suffisamment de substance pour ne pas en faire un exemple trivial.

Jerikan

Le premier composant est Jerikan. En entrée, il prend une liste d’équipements, des données de configuration, des modèles et des scripts de validation. Il génère un ensemble de fichiers de configuration pour chaque appareil. Ansible pourrait effectuer cette tâche, mais il présente les limitations suivantes concernant la compilation des modèles :

• il est lent ;
• les erreurs sont difficiles à corriger¹ ;
• la hiérarchie de recherche d’une variable est rigide.

Si vous voulez suivre les exemples, il vous suffit d’avoir installé Docker et Docker Compose. Clonez le dépôt et vous êtes prêt !

Source de vérité

Nous utilisons des fichiers YAML, versionnés avec Git, comme source de vérité unique au lieu d’utiliser une base de données, comme NetBox, ou un mélange de base de données et de fichiers texte. Cela offre de nombreux avantages :

• chacun peut utiliser son éditeur de texte préféré ;
• l’équipe prépare les changements dans des branches ;
• l’équipe évalue les changements en utilisant des demandes de fusion ;
• les demandes de fusion présentent l’impact sur les fichiers de configuration générés ;
• le retour à un état antérieur est facile ;
• c’est rapide.

Le premier fichier est devices.yaml. Il contient la liste des équipements. Le deuxième fichier est classifier.yaml. Il définit un ensemble de clés-valeurs pour chaque équipement. Il est utilisé dans les modèles et pour rechercher les données associées à un appareil.

$ ./run-jerikan scope to1-p1.sk1.blade-group.net
continent: apac
environment: prod
groups:
- tor
- tor-bgp
- tor-bgp-compute
host: to1-p1.sk1
location: sk1
member: '1'
model: dell-s4048
os: cumulus
pod: '1'
shorthost: to1-p1

Le nom de l’équipement est comparé à une liste d’expressions régulières et chaque correspondance contribue au résultat. Pour to1-p1.sk1.blade-group.net, le sous-ensemble suivant de classifier.yaml définit ses variables :

matchers:
  - '^(([^.]*)\..*)\.blade-group\.net':
      environment: prod
      host: '\1'
      shorthost: '\2'
  - '\.(sk1)\.':
      location: '\1'
      continent: apac
  - '^to([12])-[as]?p(\d+)\.':
      member: '\1'
      pod: '\2'
  - '^to[12]-p\d+\.':
      groups:
        - tor
        - tor-bgp
        - tor-bgp-compute
  - '^to[12]-(p|ap)\d+\.sk1\.':
      os: cumulus
      model: dell-s4048

Le troisième fichier est searchpaths.py. Il décrit les répertoires à examiner pour trouver une variable. Une fonction Python fournit une liste de chemins dans data/ selon les variables associées à l’équipement. Voici une version simplifiée² :

def searchpaths(scope):
    paths = [
        "host/{scope[location]}/{scope[shorthost]}",
        "location/{scope[location]}",
        "os/{scope[os]}-{scope[model]}",
        "os/{scope[os]}",
        'common'
    ]
    for idx in range(len(paths)):
        try:
            paths[idx] = paths[idx].format(scope=scope)
        except KeyError:
            paths[idx] = None
    return [path for path in paths if path]

Avec cette définition, les données pour to1-p1.sk1.blade-group.net sont recherchées dans les chemins suivants :

$ ./run-jerikan scope to1-p1.sk1.blade-group.net
[…]
Search paths:
  host/sk1/to1-p1
  location/sk1
  os/cumulus-dell-s4048
  os/cumulus
  common

Les variables sont limitées à un espace de noms à spécifier lors d’une recherche. Nous utilisons les suivants :

• system pour les comptes, DNS, serveurs syslog ;
• topology pour les ports, interfaces, adresses IP, sous-réseaux ;
• bgp pour la configuration de BGP ;
• build pour les modèles et les scripts de validation ;
• apps pour les variables d’application.

Lors de la recherche d’une variable dans un espace de noms donné, Jerikan recherche un fichier YAML nommé d’après l’espace de noms dans chaque répertoire retourné par la fonction de recherche. Par exemple, si nous recherchons une variable pour to1-p1.sk1.blade-group.net dans l’espace de noms bgp, les fichiers YAML suivants sont traités : host/sk1/to1-p1/bgp.yaml, location/sk1/bgp.yaml, os/cumulus-dell-s4048/bgp.yaml, os/cumulus/bgp.yaml et common/bgp.yaml. La recherche s’arrête à la première correspondance.

Le fichier schema.yaml nous permet d’outrepasser ce dernier comportement en fusionnant dans certains cas les dictionnaires et les tableaux correspondants³. Voici un extrait de ce fichier pour l’espace de noms topology :

system:
  users:
    merge: hash
  sampling:
    merge: hash
  ansible-vars:
    merge: hash
  netbox:
    merge: hash

La dernière fonctionnalité de la source de vérité est la possibilité d’utiliser des modèles Jinja2 pour les clefs et les valeurs en les préfixant par « ~ » :

# Dans data/os/junos/system.yaml
netbox:
  manufacturer: Juniper
  model: "~{{ model|upper }}"

# Dans data/groups/tor-bgp-compute/system.yaml
netbox:
  role: net_tor_gpu_switch

Chercher netbox dans l’espace de noms system pour to1-p2.ussfo03.blade-group.net produit le résultat suivant :

$ ./run-jerikan scope to1-p2.ussfo03.blade-group.net
continent: us
environment: prod
groups:
- tor
- tor-bgp
- tor-bgp-compute
host: to1-p2.ussfo03
location: ussfo03
member: '1'
model: qfx5110-48s
os: junos
pod: '2'
shorthost: to1-p2
[…]
Search paths:
[…]
  groups/tor-bgp-compute
[…]
  os/junos
  common
$ ./run-jerikan lookup to1-p2.ussfo03.blade-group.net system netbox
manufacturer: Juniper
model: QFX5110-48S
role: net_tor_gpu_switch

Cela fonctionne aussi pour des données structurées :

# Dans groups/adm-gateway/topology.yaml
interface-rescue:
  address: "~{{ lookup('topology', 'addresses').rescue }}"
  up:
    - "~ip route add default via {{ lookup('topology', 'addresses').rescue|ipaddr('first_usable') }} table rescue"
    - "~ip rule add from {{ lookup('topology', 'addresses').rescue|ipaddr('address') }} table rescue priority 10"

# Dans groups/adm-gateway-sk1/topology.yaml
interfaces:
  ens1f0: "~{{ lookup('topology', 'interface-rescue') }}"

Cela retourne le résultat suivant :

$ ./run-jerikan lookup gateway1.sk1.blade-group.net topology interfaces
[…]
ens1f0:
  address: 121.78.242.10/29
  up:
  - ip route add default via 121.78.242.9 table rescue
  - ip rule add from 121.78.242.10 table rescue priority 10

Pour placer des données dans la source de vérité, nous utilisons les règles suivantes :

1. Ne pas se répéter.
2. Préférer l’emplacement le plus spécifique sans enfreindre la première règle.
3. Utiliser avec parcimonie les modèles, principalement pour respecter les règles précédentes.
4. Limiter le modèle de données à ce qui est nécessaire pour votre cas d’utilisation.

La première règle est assez importante. Par exemple, lorsque vous spécifiez des adresses IP pour une liaison point à point, ne spécifiez qu’un côté et déduisez l’autre valeur via les modèles. La dernière règle signifie qu’il est inutile de reproduire un modèle BGP YANG pour spécifier les pairs et les politiques BGP :

peers:
  transit:
    cogent:
      asn: 174
      remote:
        - 38.140.30.233
        - 2001:550:2:B::1F9:1
      specific-import:
        - name: ATT-US
          as-path: ".*7018$"
          lp-delta: 50
  ix-sfmix:
    rs-sfmix:
      monitored: true
      asn: 63055
      remote:
        - 206.197.187.253
        - 206.197.187.254
        - 2001:504:30::ba06:3055:1
        - 2001:504:30::ba06:3055:2
    blizzard:
      asn: 57976
      remote:
        - 206.197.187.42
        - 2001:504:30::ba05:7976:1
      irr: AS-BLIZZARD

Modèles

La liste des modèles à compiler pour chaque équipement est stockée dans la source de vérité, sous l’espace de noms build :

$ ./run-jerikan lookup edge1.ussfo03.blade-group.net build templates
data.yaml: data.j2
config.txt: junos/main.j2
config-base.txt: junos/base.j2
config-irr.txt: junos/irr.j2
$ ./run-jerikan lookup to1-p1.ussfo03.blade-group.net build templates
data.yaml: data.j2
config.txt: cumulus/main.j2
frr.conf: cumulus/frr.j2
interfaces.conf: cumulus/interfaces.j2
ports.conf: cumulus/ports.j2
dhcpd.conf: cumulus/dhcp.j2
default-isc-dhcp: cumulus/default-isc-dhcp.j2
authorized_keys: cumulus/authorized-keys.j2
motd: linux/motd.j2
acl.rules: cumulus/acl.j2
rsyslog.conf: cumulus/rsyslog.conf.j2

Les modèles utilisent Jinja2. C’est le même moteur que pour Ansible. Jerikan fournit quelques filtres personnalisés mais réutilise également certains des filtres d’Ansible⁴, notamment ipaddr. Voici un extrait de templates/junos/base.j2 pour configurer les serveurs DNS et NTP sur les équipements Juniper :

system {
  ntp {
{% for ntp in lookup("system", "ntp") %}
    server {{ ntp }};
{% endfor %}
  }
  name-server {
{% for dns in lookup("system", "dns") %}
    {{ dns }};
{% endfor %}
  }
}

Voici le modèle équivalent pour Cisco IOS XR :

{% for dns in lookup('system', 'dns') %}
domain vrf VRF-MANAGEMENT name-server {{ dns }}
{% endfor %}
!
{% for syslog in lookup('system', 'syslog') %}
logging {{ syslog }} vrf VRF-MANAGEMENT
{% endfor %}
!

Trois fonctions utiles sont fournies :

• devices() renvoie la liste des équipements correspondant à un ensemble de conditions. Par exemple, devices("location==ussfo03", "groups==tor-bgp") renvoie la liste des routeurs de San Francisco appartenant au groupe tor-bgp. Vous pouvez également omettre l’opérateur si vous souhaitez que la valeur spécifiée soit égale à celle de l’équipement en cours. Par exemple, devices("location") renvoie les équipements situés dans le lieu actuel.
• lookup() effectue une recherche par clé. Elle prend l’espace de noms, la clé, et optionnellement, un nom d’équipement. S’il n’est pas fourni, la recherche s’effectue sur l’équipement actuel.
• scope() renvoie les variables associées à l’équipement indiqué.

Voici comment définir des sessions iBGP entre des routeurs situés dans le même centre de données :

{% for neighbor in devices("location", "groups==edge") if neighbor != device %}
  {% for address in lookup("topology", "addresses", neighbor).loopback|tolist %}
protocols bgp group IPV{{ address|ipv }}-EDGES-IBGP {
  neighbor {{ address }} {
    description "IPv{{ address|ipv }}: iBGP to {{ neighbor }}";
  }
}
  {% endfor %}
{% endfor %}

Nous disposons également d’une base de données clé-valeur pour enregistrer les informations à réutiliser dans un autre modèle ou équipement. Ceci est très utile pour construire automatiquement des enregistrement DNS. Tout d’abord, on « capture » l’adresse IP insérée dans un modèle avec le filtre store() :

interface Loopback0
 description 'Loopback:'
 {% for address in lookup('topology', 'addresses').loopback|tolist %}
 ipv{{ address|ipv }} address {{ address|store('addresses', 'Loopback0')|ipaddr('cidr') }}
 {% endfor %}
!

Puis, nous réutilisons les valeurs stockées pour construire les enregistrements DNS en itérant sur les résultats de la fonction store()⁵ :

{% for device, ip, interface in store('addresses') %}
  {% set interface = interface|replace('/', '-')|replace('.', '-')|replace(':', '-') %}
  {% set name = '{}.{}'.format(interface|lower, device) %}
{{ name }}. IN {{ 'A' if ip|ipv4 else 'AAAA' }} {{ ip|ipaddr('address') }}
{% endfor %}

Les modèles sont compilés localement avec ./run-jerikan build. L’argument --limit restreint les équipements pour lesquels générer des configurations. La construction ne se fait pas en parallèle car un modèle peut dépendre des données collectées par un autre modèle. Actuellement, il faut 1 minute pour construire environ 3000 fichiers couvrant plus de 800 appareils.

Lorsqu’une erreur se produit, une trace détaillée est affichée. Elle inclut le nom du modèle, le numéro de ligne et la valeur de toutes les variables visibles. C’est un gain de temps considérable par rapport à Ansible !

templates/opengear/config.j2:15: in top-level template code
    config.interfaces.{{ interface }}.netmask {{ infos.adddress | ipaddr("netmask") }}
        continent  = 'us'
        device     = 'con1-ag2.ussfo03.blade-group.net'
        environment = 'prod'
        host       = 'con1-ag2.ussfo03'
        infos      = {'address': '172.30.24.19/21'}
        interface  = 'wan'
        location   = 'ussfo03'
        loop       = <LoopContext 1/2>
        member     = '2'
        model      = 'cm7132-2-dac'
        os         = 'opengear'
        shorthost  = 'con1-ag2'
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

value = JerkianUndefined, query = 'netmask', version = False, alias = 'ipaddr'

[…]
        # Check if value is a list and parse each element
        if isinstance(value, (list, tuple, types.GeneratorType)):
            _ret = [ipaddr(element, str(query), version) for element in value]
            return [item for item in _ret if item]

>       elif not value or value is True:
E       jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'adddress'

Nous ne disposons pas de règles générales pour l’écriture des modèles. Comme pour la source de vérité, il n’est pas nécessaire de créer des modèles génériques capables de produire n’importe quelle configuration BGP. Il y a un équilibre à trouver entre la lisibilité et le fait d’éviter la duplication. Les modèles peuvent devenir effrayants et complexes : parfois, il est préférable d’écrire un filtre ou une fonction dans jerikan/jinja.py. Maîtriser Jinja2 est un très bon investissement. Prenez le temps de parcourir nos modèles, car certains d’entre eux présentent des fonctionnalités intéressantes.

Validation

Optionellement, chaque fichier de configuration peut être validé par un script dans le répertoire checks/. Jerikan utilise la variable checks dans l’espace de noms build pour connaître les tests à appliquer :

$ ./run-jerikan lookup edge1.ussfo03.blade-group.net build checks
- description: Juniper configuration file syntax check
  script: checks/junoser
  cache:
    input: config.txt
    output: config-set.txt
- description: check YAML data
  script: checks/data.yaml
  cache: data.yaml

Dans l’exemple ci-dessus, checks/junoser est exécuté s’il y a une modification du fichier généré config.txt. Il produit également une version transformée du fichier de configuration qui est plus facile à interfacer avec l’utilitaire diff. Junoser vérifie un fichier de configuration Junos en utilisant la définition du schéma XML pour Netconf⁶. En cas d’erreur, Jerikan affiche :

jerikan/build.py:127: RuntimeError
-------------- Captured syntax check with Junoser call --------------
P: checks/junoser edge2.ussfo03.blade-group.net
C: /app/jerikan
O:
E: Invalid syntax:  set system syslog archive size 10m files 10 word-readable
S: 1

Intégration continue avec GitLab

L’étape suivante consiste à compiler les modèles en utilisant un système d’intégration continue. Comme nous utilisons GitLab, Jerikan contient un fichier .gitlab-ci.yml. Lorsque nous devons effectuer un changement, nous créons une branche dédiée et une demande de fusion. GitLab compile les modèles en utilisant le même environnement que celui que nous utilisons sur nos ordinateurs portables et les stocke dans un artefact.

Avant d’approuver une fusion, un autre membre de l’équipe étudie les changements au niveau du code mais aussi les différences au niveau des fichiers générés :

Ansible

Une fois que Jerikan a construit les fichiers de configuration, Ansible prend le relais. Il est également livré sous la forme d’une image Docker pour éviter la maintenance d’un environnement virtuel Python et s’assurer que nous utilisons tous les mêmes versions.

Inventaire

Jerikan a généré un fichier d’inventaire. Il contient tous les équipements gérés, des variables définies pour chacun d’eux et les groupes convertis en groupes Ansible :

ob1-n1.sk1.blade-group.net ansible_host=172.29.15.12 ansible_user=blade ansible_connection=network_cli ansible_network_os=ios
ob2-n1.sk1.blade-group.net ansible_host=172.29.15.13 ansible_user=blade ansible_connection=network_cli ansible_network_os=ios
ob1-n1.ussfo03.blade-group.net ansible_host=172.29.15.12 ansible_user=blade ansible_connection=network_cli ansible_network_os=ios
none ansible_connection=local

[oob]
ob1-n1.sk1.blade-group.net
ob2-n1.sk1.blade-group.net
ob1-n1.ussfo03.blade-group.net

[os-ios]
ob1-n1.sk1.blade-group.net
ob2-n1.sk1.blade-group.net
ob1-n1.ussfo03.blade-group.net

[model-c2960s]
ob1-n1.sk1.blade-group.net
ob2-n1.sk1.blade-group.net
ob1-n1.ussfo03.blade-group.net

[location-sk1]
ob1-n1.sk1.blade-group.net
ob2-n1.sk1.blade-group.net

[location-ussfo03]
ob1-n1.ussfo03.blade-group.net

[in-sync]
ob1-n1.sk1.blade-group.net
ob2-n1.sk1.blade-group.net
ob1-n1.ussfo03.blade-group.net
none

in-sync est un groupe spécial pour les équipements dont la configuration doit correspondre à la configuration générée. Quotidiennement et sans surveillance, Ansible devrait être capable de pousser les configurations vers ce groupe. L’objectif à moyen terme est de couvrir tous les équipements.

none est un équipement spécial pour les tâches non liées à un hôte spécifique. Cela inclut la synchronisation de NetBox, des objets IRR et du DNS, la mise à jour de la RPKI et la construction des fichiers de géolocalisation.

Playbook

Nous utilisons un unique playbook pour tous les équipements. Il est décrit dans le fichier ansible/playbooks/site.yaml. En voici une version raccourcie :

- hosts: adm-gateway:!done
  strategy: mitogen_linear
  roles:
    - blade.linux
    - blade.adm-gateway
    - done

- hosts: os-linux:!done
  strategy: mitogen_linear
  roles:
    - blade.linux
    - done

- hosts: os-junos:!done
  gather_facts: false
  roles:
    - blade.junos
    - done

- hosts: os-opengear:!done
  gather_facts: false
  roles:
    - blade.opengear
    - done

- hosts: none:!done
  gather_facts: false
  roles:
    - blade.none
    - done

Un hôte n’exécute qu’un seul des rôles. Par exemple, un équipement Junos exécute le rôle blade.junos. Une fois qu’un rôle a été exécuté, l’équipement est ajouté au groupe done et les autres rôles sont ignorés.

Le playbook peut être exécuté avec les fichiers de configuration générés par GitLab en utilisant la commande ./run-ansible-gitlab. Elle utilise Docker pour exposer la commande ansible-playbook et elle accepte les mêmes arguments. Pour simuler un déploiement de la configuration sur les équipements du centre de données SK1, nous utilisons :

$ ./run-ansible-gitlab playbooks/site.yaml --limit='edge:&location-sk1' --diff --check
[…]
PLAY RECAP *************************************************************
edge1.sk1.blade-group.net  : ok=6    changed=0    unreachable=0    failed=0    skipped=3    rescued=0    ignored=0
edge2.sk1.blade-group.net  : ok=5    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

Nous avons quelques règles pour écrire les rôles :

• --check doit détecter si un changement est nécessaire,
• --diff doit fournir une visualisation des changements prévus,
• --check et --diff ne doivent rien afficher s’il n’y a rien à changer,
• écrire un module sur mesure pour nos besoins est une solution valable,
• toute la configuration de l’équipement est gérée⁷,
• les secrets doivent être stockés dans Vault,
• les modèles doivent être évités car nous avons Jerikan pour cela,
• les tâches doivent être réutilisées et non dupliquées⁸.

Nous évitons d’utiliser des collections d’Ansible Galaxy, à l’exception de celles permettant de se connecter et d’interagir avec les équipements constructeur, comme la collection cisco.iosxr. La qualité des collections d’Ansible Galaxy est assez aléatoire et cela représente un effort de maintenance supplémentaire. Nous préférons écrire des rôles adaptés à nos besoins. Les collections que nous utilisons sont dans ci/ansible/ansible-galaxy.yaml. Nous utilisons Mitogen pour accélérer considérablement les exécutions d’Ansible sur les hôtes Linux.

Nous disposons également de quelques playbooks à des fins opérationnelles : mise à niveau d’une version, isolation d’un routeur Internet, etc. Nous avions également en tête d’ajouter une étape de validation dans les rôles : est-ce que toutes les sessions BGP sont opérationnelles ? Cela aurait permis de valider un déploiement et de revenir rapidement en arrière en cas de problèmes.

Actuellement, nos playbooks sont exécutés à partir de nos ordinateurs portables. Pour assurer le suivi des exécutions, nous utilisons ARA. Un essai hebdomadaire sur les équipements du groupe in-sync fournit également un tableau de bord sur les hôtes sur lesquels nous devons faire converger la configuration.

Données de configuration et modèles

Nous livrons Jerikan avec des données et des modèles correspondant à la configuration de nos centres de données USSFO03 et SK1. Ils n’existent plus mais, nous vous le promettons, tout ceci était utilisé en production à une époque ! 😢

Vous trouverez la configuration pour :

Nos routeurs Internet

Certains fonctionnent sur Junos, comme edge2.ussfo03, les autres sur IOS XR, comme edge1.sk1. Les fonctionnalités implémentées sont similaires dans les deux cas et nous pouvons échanger l’un contre l’autre. Il y a la configuration BGP pour les transits, les peerings et les IX ainsi que les politiques BGP associées. PeeringDB est interrogé pour obtenir le nombre maximum de préfixes à accepter. bgpq3 et un IRRd conteneurisé aident à filtrer les routes reçues. Un pare-feu est également présent. IPv4 et IPv6 sont tous deux configurés.

Notre fabrique BGP

BGP est utilisé à l’intérieur du centre de données⁹ et s’étend jusqu’aux hôtes physiques. La configuration est automatiquement dérivée de l’emplacement du dispositif et du numéro de port¹⁰. Les switchs en haut de chaque rack utilisent des sessions BGP passives pour les ports vers les serveurs. Ils exposent également un réseau spécifique pour permettre de démarrer en utilisant DHCP et PXE. Ils font également office de serveur DHCP. La conception est multivendeur : certains équipements fonctionnent sous Cumulus Linux, comme to1-p1.ussfo03, tandis que d’autres fonctionnent sous Junos, comme to1-p2.ussfo03.

Notre réseau hors bande

Nous utilisons des commutateurs Cisco Catalyst 2960 pour construire un réseau hors bande L2. Pour assurer la redondance et économiser quelques sous sur le câblage, nous construisons des petites boucles et exploitons le protocole STP. Regardez ob1-p1.ussfo03. Le réseau est connecté de manière redondante à des serveurs d’accès. Nous utilisons également des équipements OpenGear pour les accès console. Regardez con1-n1.ussfo03.

Nos passerelles d’accès

Ces serveurs Linux ont plusieurs objectifs : passerelles SSH, connexion de secours, accès direct au réseau hors bande, installation automatisée des équipements réseau¹¹, accès Internet pour les flux administratifs, centralisation des serveurs de console à l’aide de Conserver et mise à disposition d’une API pour l’autoconfiguration des sessions BGP pour les serveurs physiques. Ce sont les premiers serveurs installés dans un nouveau centre de données et ils sont utilisés pour mettre en place tout le reste. Regardez à la fois les fichiers générés et les tâches Ansible associées.

L’Internet est divisé en cinq registres Internet régionaux : AFRINIC, ARIN, APNIC, LACNIC et RIPE. Chacun de ces RIR gère un registre de routage Internet. Un tel IRR permet de publier des informations sur le routage des ressources Internet¹. Les opérateurs l’utilisent pour déterminer le propriétaire d’une adresse IP et pour construire et maintenir des filtres de routage. Pour que vos routes soient largement acceptées, il est important de tenir à jour les préfixes que vous annoncez dans un IRR.

Il existe deux outils courants pour interroger cette base de données : whois et bgpq4. Le premier vous permet d’effectuer une requête avec le protocole WHOIS :

$ whois -h whois.ripe.net -- '-BrG 2a0a:e805:400::/40'
[…]
inet6num:       2a0a:e805:400::/40
netname:        FR-BLADE-CUSTOMERS-DE
country:        DE
geoloc:         50.1109 8.6821
admin-c:        BN2763-RIPE
tech-c:         BN2763-RIPE
status:         ASSIGNED
mnt-by:         fr-blade-1-mnt
remarks:        synced with cmdb
created:        2020-05-19T08:04:58Z
last-modified:  2020-05-19T08:04:58Z
source:         RIPE

route6:         2a0a:e805:400::/40
descr:          Blade IPv6 - AMS1
origin:         AS64476
mnt-by:         fr-blade-1-mnt
remarks:        synced with cmdb
created:        2019-10-01T08:19:34Z
last-modified:  2020-05-19T08:05:00Z
source:         RIPE

Le second permet de construire des filtres de routage en utilisant les informations contenues dans la base de données IRR :

$ bgpq4 -6 -S RIPE -b AS64476
NN = [
    2a0a:e805::/40,
    2a0a:e805:100::/40,
    2a0a:e805:300::/40,
    2a0a:e805:400::/40,
    2a0a:e805:500::/40
];

Il n’y a pas de module disponible sur Ansible Galaxy pour gérer ces objets. Chaque IRR a différentes façons d’être mis à jour. Certains RIR proposent une API, mais d’autres non. Si l’on se limite au RIPE, à l’ARIN et à l’APNIC, la seule méthode commune de mise à jour des objets est la mise à jour par courrier électronique, authentifiée par un mot de passe ou une signature PGP². Écrivons un module Ansible à cet effet !

Code

Le module prend une liste d’objets RPSL à synchroniser et renvoie le contenu d’un courrier électronique pour mise à jour si un changement est nécessaire :

- name: prepare RIPE objects
  irr_sync:
    irr: RIPE
    mntner: fr-blade-1-mnt
    source: whois-ripe.txt
  register: irr

Prérequis

Le fichier source doit être un ensemble d’objets à synchroniser en utilisant le langage RPSL. Il s’agirait du même contenu que celui que vous enverriez manuellement par courrier électronique. Tous les objets doivent être gérés par le même mainteneur, également fourni en paramètre.

La signature³ et l’envoi du résultat ne relèvent pas de la responsabilité de ce module. Vous avez besoin de deux tâches supplémentaires à cette fin :

- name: sign RIPE objects
  shell:
    cmd: gpg --batch --local-user noc@example.com --clearsign
    stdin: "{{ irr.objects }}"
  register: signed
  check_mode: false
  changed_when: false

- name: update RIPE objects by email
  mail:
    subject: "NEW: update for RIPE"
    from: noc@example.com
    to: "auto-dbm@ripe.net"
    cc: noc@example.com
    host: smtp.example.com
    port: 25
    charset: us-ascii
    body: "{{ signed.stdout }}"

Vous devez aussi autoriser la clé PGP utilisée pour signer les mises à jour en créant un objet key-cert et en l’ajoutant comme méthode d’authentification pour l’objet mntner correspondant :

key-cert:  PGPKEY-A791AAAB
certif:    -----BEGIN PGP PUBLIC KEY BLOCK-----
certif:
certif:    mQGNBF8TLY8BDADEwP3a6/vRhEERBIaPUAFnr23zKCNt5YhWRZyt50mKq1RmQBBY
[…]
certif:    -----END PGP PUBLIC KEY BLOCK-----
mnt-by:    fr-blade-1-mnt
source:    RIPE

mntner:    fr-blade-1-mnt
[…]
auth:      PGPKEY-A791AAAB
mnt-by:    fr-blade-1-mnt
source:    RIPE

Définition du module

En se basant sur le squelette présenté dans l’article précédent, nous définissons le module :

module_args = dict(
    irr=dict(type='str', required=True),
    mntner=dict(type='str', required=True),
    source=dict(type='path', required=True),
)

result = dict(
    changed=False,
)

module = AnsibleModule(
    argument_spec=module_args,
    supports_check_mode=True
)

Obtenir les objets existants

Pour récupérer les objets existants, la commande whois recherche tous les objets attachés au mainteneur fourni en paramètre du module.

# Per-IRR variations:
# - whois server
whois = {
    'ARIN': 'rr.arin.net',
    'RIPE': 'whois.ripe.net',
    'APNIC': 'whois.apnic.net'
}
# - whois options
options = {
    'ARIN': ['-r'],
    'RIPE': ['-BrG'],
    'APNIC': ['-BrG']
}
# - objects excluded from synchronization
excluded = ["domain"]
if irr == "ARIN":
    # ARIN does not return these objects
    excluded.extend([
        "key-cert",
        "mntner",
    ])

# Grab existing objects
args = ["-h", whois[irr],
        "-s", irr,
        *options[irr],
        "-i", "mnt-by",
        module.params['mntner']]
proc = subprocess.run(["whois", *args], capture_output=True)
if proc.returncode != 0:
    raise AnsibleError(
        f"unable to query whois: {args}")
output = proc.stdout.decode('ascii')
got = extract(output, excluded)

La première partie du code introduit des constantes spécifiques à chaque IRR : le serveur à interroger, les options à fournir à la commande whois et les objets à exclure de la synchronisation. La seconde partie invoque la commande whois qui récupère tous les objets dont le champ mnt-by correspond au mainteneur fourni. Voici un exemple de sortie :

$ whois -h whois.ripe.net -- '-s RIPE -BrG -i mnt-by fr-blade-1-mnt'
[…]

inet6num:       2a0a:e805:300::/40
netname:        FR-BLADE-CUSTOMERS-FR
country:        FR
geoloc:         48.8566 2.3522
admin-c:        BN2763-RIPE
tech-c:         BN2763-RIPE
status:         ASSIGNED
mnt-by:         fr-blade-1-mnt
remarks:        synced with cmdb
created:        2020-05-19T08:04:59Z
last-modified:  2020-05-19T08:04:59Z
source:         RIPE

[…]

route6:         2a0a:e805:300::/40
descr:          Blade IPv6 - PA1
origin:         AS64476
mnt-by:         fr-blade-1-mnt
remarks:        synced with cmdb
created:        2019-10-01T08:19:34Z
last-modified:  2020-05-19T08:05:00Z
source:         RIPE

[…]

Le résultat est transmis à la fonction extract(). Elle analyse et normalise les résultats dans un dictionnaire qui met en correspondance les noms d’objets et les objets. Nous stockons le résultat dans la variable got.

def extract(raw, excluded):
    """Extract objects."""
    # First step, remove comments and unwanted lines
    objects = "\n".join([obj
                         for obj in raw.split("\n")
                         if not obj.startswith((
                                 "#",
                                 "%",
                         ))])
    # Second step, split objects
    objects = [RPSLObject(obj.strip())
               for obj in re.split(r"\n\n+", objects)
               if obj.strip()
               and not obj.startswith(
                   tuple(f"{x}:" for x in excluded))]
    # Last step, put objects in a dict
    objects = {repr(obj): obj
               for obj in objects}
    return objects

RPSLObject() est la classe qui permet de normaliser et comparer les objets. Regardez le code du module pour plus de détails.

>>> output="""
... inet6num:       2a0a:e805:300::/40
... […]
... """
>>> pprint({k: str(v) for k,v in extract(output, excluded=[])})
{'<Object:inet6num:2a0a:e805:300::/40>':
   'inet6num:       2a0a:e805:300::/40\n'
   'netname:        FR-BLADE-CUSTOMERS-FR\n'
   'country:        FR\n'
   'geoloc:         48.8566 2.3522\n'
   'admin-c:        BN2763-RIPE\n'
   'tech-c:         BN2763-RIPE\n'
   'status:         ASSIGNED\n'
   'mnt-by:         fr-blade-1-mnt\n'
   'remarks:        synced with cmdb\n'
   'source:         RIPE',
 '<Object:route6:2a0a:e805:300::/40>':
   'route6:         2a0a:e805:300::/40\n'
   'descr:          Blade IPv6 - PA1\n'
   'origin:         AS64476\n'
   'mnt-by:         fr-blade-1-mnt\n'
   'remarks:        synced with cmdb\n'
   'source:         RIPE'}

Comparer avec les objets souhaités

Construisons maintenant le dictionnaire wanted en réutilisant la fonction extract() :

with open(module.params['source']) as f:
    source = f.read()
wanted = extract(source, excluded)

L’étape suivante est de comparer got et wanted pour construire les différences :

if got != wanted:
    result['changed'] = True
    if module._diff:
        result['diff'] = [
            dict(before_header=k,
                 after_header=k,
                 before=str(got.get(k, "")),
                 after=str(wanted.get(k, "")))
            for k in set((*wanted.keys(), *got.keys()))
            if k not in wanted or k not in got or wanted[k] != got[k]]

Retourner les mises à jour

Le module n’a pas d’effet de bord. S’il y a une différence, nous retournons les mises à jour à envoyer par courrier électronique. Nous choisissons d’inclure tous les objets souhaités dans les mises à jour (contenus dans la variable source) et de laisser l’IRR ignorer les objets non modifiés. Nous ajoutons également les objets à supprimer en ajoutant un attribut delete: à chacun d’entre eux.

# We send all source objects and deleted objects.
deleted_mark = f"{'delete:':16}deleted by CMDB"
deleted = "\n\n".join([f"{got[k].raw}\n{deleted_mark}"
                       for k in got
                       if k not in wanted])
result['objects'] = f"{source}\n\n{deleted}"

module.exit_json(**result)

Le code complet est disponible sur GitHub. Le module prend en charge les options --diff et --check. Il ne renvoie rien si aucun changement n’est détecté. Il peut fonctionner avec l’APNIC, le RIPE et l’ARIN. Il n’est pas parfait : il peut ne pas détecter certains changements⁴, il n’est pas capable de modifier des objets n’appartenant pas au mainteneur fourni⁵ et certains attributs refusent les mises à jour, ce qui nécessite de supprimer et de recréer manuellement l’objet⁶. Cependant, ce module devrait automatiser 95% de vos besoins.

La collection netbox.netbox d’Ansible Galaxy fournit divers modules pour mettre à jour des objets dans NetBox:

- name: create a device in NetBox
  netbox_device:
    netbox_url: http://netbox.local
    netbox_token: s3cret
    data:
      name: to3-p14.sfo1.example.com
      device_type: QFX5110-48S
      device_role: Compute Switch
      site: SFO1

Cependant, si NetBox n’est pas votre source de vérité, vous voudrez vous assurer qu’il reste synchronisé avec votre base de gestion de configuration¹ en supprimant les équipements ou les adresses IP obsolètes. Alors qu’il devrait être possible de bricoler un playbook avec une requête, une boucle et des filtres pour supprimer les éléments indésirables, cela semble fastidieux, inefficace et constitue un détournement de YAML comme langage de programmation. Un module Ansible ad hoc résout ce problème et est probablement plus flexible.

Code

Le module expose la signature suivante et synchronise NetBox avec le contenu du fichier YAML fourni :

netbox_sync:
  source: netbox.yaml
  api: https://netbox.example.com
  token: s3cret

Les objets synchronisés sont :

• les sites ;
• les constructeurs ;
• les types d’équipements ;
• les rôles des équipements ;
• les équipements ;
• les adresses IP.

Dans notre environnement, le fichier YAML est généré à partir de notre source de vérité et contient un ensemble d’équipements et une liste d’adresses IP :

devices:
  ad2-p6.sfo1.example.com:
     datacenter: sfo1
     manufacturer: Cisco
     model: Catalyst 2960G-48TC-L
     role: net_tor_oob_switch
  to1-p6.sfo1.example.com:
     datacenter: sfo1
     manufacturer: Juniper
     model: QFX5110-48S
     role: net_tor_gpu_switch
# […]
ips:
  - device: ad2-p6.example.com
    ip: 172.31.115.18/21
    interface: oob
  - device: to1-p6.example.com
    ip: 172.31.115.33/21
    interface: oob
  - device: to1-p6.example.com
    ip: 172.31.254.33/32
    interface: lo0.0
# […]

L’équipe réseau n’est pas le seul utilisateur de NetBox. Si l’ajout de nouveaux objets ou la modification d’objets existants est peu risqué, la suppression d’objets indésirables peut être hasardeuse. Le module ne supprime que les objets qu’il a créés ou modifiés. Pour les identifier, il les marque avec une étiquette spécifique, cmdb. La plupart des objets de NetBox acceptent les étiquettes.

Définition du module

En se basant sur le squelette présenté dans l’article précédent, nous définissons le module :

module_args = dict(
    source=dict(type='path', required=True),
    api=dict(type='str', required=True),
    token=dict(type='str', required=True, no_log=True),
    max_workers=dict(type='int', required=False, default=10)
)

result = dict(
    changed=False
)

module = AnsibleModule(
    argument_spec=module_args,
    supports_check_mode=True
)

Il contient un argument supplémentaire optionnel définissant le nombre de requêtes à envoyer en parallèle à NetBox pour la récupération des objets existants afin d’accélérer l’exécution.

Abstraction du processus de synchronisation

Nous devons synchroniser différents types d’objets, mais une fois que nous avons une liste des objets que nous voulons dans NetBox, le travail est toujours le même :

• vérifier si les objets existent déjà ;
• les récupérer et les mettre sous une forme permettant de les comparer ;
• récupérer les objets dont nous ne voulons plus ;
• comparer les deux ensembles ;
• ajouter les objets manquants, mettre à jour les objets existants, supprimer les objets en trop.

Ces comportements sont codés dans une classe abstraite Synchronizer. Pour chaque type d’objet, une classe concrète est construite avec les attributs appropriés pour adapter son comportement et une méthode wanted() pour fournir les objets désirés.

Je ne détaille pas ici le code de la classe abstraite. Jetez un coup d’œil aux sources si nécessaire.

Synchroniser les étiquettes et les tenants

Pour commencer, voici comment nous définissons la classe synchronisant les étiquettes :

class SyncTags(Synchronizer):
    app = "extras"
    table = "tags"
    key = "name"

    def wanted(self):
        return {"cmdb": dict(
            slug="cmdb",
            color="8bc34a",
            description="synced by network CMDB")}

Les attributs app et table définissent les objets NetBox que nous voulons manipuler. L’attribut key est utilisé pour déterminer comment rechercher des objets existants. Dans cet exemple, nous voulons rechercher des étiquettes en utilisant leurs noms.

La méthode wanted() doit renvoyer un dictionnaire qui associe les clés des objets à la liste des attributs désirés. Ici, les clés sont le nom des étiquettes et nous ne créons qu’une seule étiquette, cmdb, avec la couleur et la description fournies. C’est cette étiquette que nous utiliserons pour marquer les objets que nous créerons ou modifierons.

Si l’étiquette n’existe pas, elle est créée. Si elle existe, les attributs fournis sont mis à jour. Les autres attributs ne sont pas modifiés.

Nous voulons également créer un tenant spécifique pour les objets acceptant un tel attribut (équipements et adresses IP) :

class SyncTenants(Synchronizer):
    app = "tenancy"
    table = "tenants"
    key = "name"

    def wanted(self):
        return {"Network": dict(slug="network",
                                description="Network team")}

Synchroniser les sites

Nous devons également synchroniser la liste des sites. Cette fois, la méthode wanted() utilise les informations fournies dans le fichier YAML : elle parcourt les équipements et construit la liste des centres de données.

class SyncSites(Synchronizer):

    app = "dcim"
    table = "sites"
    key = "name"
    only_on_create = ("status", "slug")

    def wanted(self):
        result = set(details["datacenter"]
                     for details in self.source['devices'].values()
                     if "datacenter" in details)
        return {k: dict(slug=k,
                        status="planned")
                for k in result}

Grâce à l’utilisation de l’attribut only_on_create, les attributs spécifiés ne sont pas mis à jour s’ils sont différents. Le but de ce synchroniseur est surtout de collecter les références aux différents sites pour les utiliser dans d’autres objets.

>>> pprint(SyncSites(**sync_args).wanted())
{'sfo1': {'slug': 'sfo1', 'status': 'planned'},
 'chi1': {'slug': 'chi1', 'status': 'planned'},
 'nyc1': {'slug': 'nyc1', 'status': 'planned'}}

Synchroniser les constructeurs, les types d’équipements et les rôles des équipements

La synchronisation des constructeurs est très similaire, sauf que nous n’avons pas besoin de l’attribut only_on_create :

class SyncManufacturers(Synchronizer):

    app = "dcim"
    table = "manufacturers"
    key = "name"

    def wanted(self):
        result = set(details["manufacturer"]
                     for details in self.source['devices'].values()
                     if "manufacturer" in details)
        return {k: {"slug": slugify(k)}
                for k in result}

Concernant les types d’équipements, nous utilisons l’attribut foreign indiquant le lien entre un attribut NetBox et le synchroniseur qui le gère.

class SyncDeviceTypes(Synchronizer):

    app = "dcim"
    table = "device_types"
    key = "model"
    foreign = {"manufacturer": SyncManufacturers}

    def wanted(self):
        result = set((details["manufacturer"], details["model"])
                     for details in self.source['devices'].values()
                     if "model" in details)
        return {k[1]: dict(manufacturer=k[0],
                           slug=slugify(k[1]))
                for k in result}

La méthode wanted() renvoie des références aux constructeurs en utilisant les valeurs contenues dans l’attribut key. Dans ce cas, il s’agit du nom du constructeur.

>>> pprint(SyncManufacturers(**sync_args).wanted())
{'Cisco': {'slug': 'cisco'},
 'Dell': {'slug': 'dell'},
 'Juniper': {'slug': 'juniper'}}
>>> pprint(SyncDeviceTypes(**sync_args).wanted())
{'ASR 9001': {'manufacturer': 'Cisco', 'slug': 'asr-9001'},
 'Catalyst 2960G-48TC-L': {'manufacturer': 'Cisco',
                           'slug': 'catalyst-2960g-48tc-l'},
 'MX10003': {'manufacturer': 'Juniper', 'slug': 'mx10003'},
 'QFX10002-36Q': {'manufacturer': 'Juniper', 'slug': 'qfx10002-36q'},
 'QFX10002-72Q': {'manufacturer': 'Juniper', 'slug': 'qfx10002-72q'},
 'QFX5110-32Q': {'manufacturer': 'Juniper', 'slug': 'qfx5110-32q'},
 'QFX5110-48S': {'manufacturer': 'Juniper', 'slug': 'qfx5110-48s'},
 'QFX5200-32C': {'manufacturer': 'Juniper', 'slug': 'qfx5200-32c'},
 'S4048-ON': {'manufacturer': 'Dell', 'slug': 's4048-on'},
 'S6010-ON': {'manufacturer': 'Dell', 'slug': 's6010-on'}}

Les rôles des équipements sont, quant à eux, définis ainsi :

class SyncDeviceRoles(Synchronizer):

    app = "dcim"
    table = "device_roles"
    key = "name"

    def wanted(self):
        result = set(details["role"]
                     for details in self.source['devices'].values()
                     if "role" in details)
        return {k: dict(slug=slugify(k),
                        color="8bc34a")
                for k in result}

Synchroniser les équipements

Un équipement est essentiellement un nom avec des références à un rôle, un modèle, un site et un tenant. Ces références sont déclarées comme des clés étrangères en référence aux synchroniseurs définis précédemment.

class SyncDevices(Synchronizer):
    app = "dcim"
    table = "devices"
    key = "name"
    foreign = {"device_role": SyncDeviceRoles,
               "device_type": SyncDeviceTypes,
               "site": SyncSites,
               "tenant": SyncTenants}
    remove_unused = 10

    def wanted(self):
        return {name: dict(device_role=details["role"],
                           device_type=details["model"],
                           site=details["datacenter"],
                           tenant="Network")
                for name, details in self.source['devices'].items()
                if {"datacenter", "model", "role"} <= set(details.keys())}

L’attribut remove_unused est un garde-fou provoquant un échec si nous devons supprimer plus de 10 équipements : cela peut être l’indication qu’il y a un problème quelque part ou un important départ de feu dans l’un des sites.

>>> pprint(SyncDevices(**sync_args).wanted())
{'ad2-p6.sfo1.example.com': {'device_role': 'net_tor_oob_switch',
                             'device_type': 'Catalyst 2960G-48TC-L',
                             'site': 'sfo1',
                             'tenant': 'Network'},
 'to1-p6.sfo1.example.com': {'device_role': 'net_tor_gpu_switch',
                             'device_type': 'QFX5110-48S',
                             'site': 'sfo1',
                             'tenant': 'Network'},
[…]

Synchroniser les adresses IP

La dernière étape consiste à synchroniser les adresses IP. Nous ne les attachons pas à un équipement². Nous spécifions plutôt leurs noms dans la description :

class SyncIPs(Synchronizer):
    app = "ipam"
    table = "ip-addresses"
    key = "address"
    foreign = {"tenant": SyncTenants}
    remove_unused = 1000

    def wanted(self):
        wanted = {}
        for details in self.source['ips']:
            if details['ip'] in wanted:
                wanted[details['ip']]['description'] = \
                    f"{details['device']} (and others)"
            else:
                wanted[details['ip']] = dict(
                    tenant="Network",
                    status="active",
                    dns_name="",        # information is present in DNS
                    description=f"{details['device']}: {details['interface']}",
                    role=None,
                    vrf=None)
        return wanted

Il y a une petite difficulté : NetBox autorise les adresses IP en double. Une simple recherche ne suffit donc pas. En cas de multiples résultats, nous choisissons le meilleur en préférant ceux marqués par l’étiquette cmdb, puis ceux déjà attachés à une interface :

def get(self, key):
    """Grab IP address from NetBox."""
    # There may be duplicate. We need to grab the "best."
    results = super(Synchronizer, self).get(key)
    if len(results) == 0:
        return None
    if len(results) == 1:
        return results[0]
    scores = [0]*len(results)
    for idx, result in enumerate(results):
        if "cmdb" in result.tags:
            scores[idx] += 10
        if result.interface is not None:
            scores[idx] += 5
    return sorted(zip(scores, results),
                  reverse=True, key=lambda k: k[0])[0][1]

Calculer les états actuels et attendus

Chaque synchroniseur est initialisé avec une référence au module Ansible, une référence à pynetbox, les données contenues dans le fichier YAML fourni et deux dictionnaires vides pour les états actuels et attendus :

source = yaml.safe_load(open(module.params['source']))
netbox = pynetbox.api(module.params['api'],
                      token=module.params['token'])

sync_args = dict(
    module=module,
    netbox=netbox,
    source=source,
    before={},
    after={}
)
synchronizers = [synchronizer(**sync_args) for synchronizer in [
    SyncTags,
    SyncTenants,
    SyncSites,
    SyncManufacturers,
    SyncDeviceTypes,
    SyncDeviceRoles,
    SyncDevices,
    SyncIPs
]]

Chaque synchroniseur a une méthode prepare() dont le but est de calculer l’état source et l’état cible. Elle renvoie True en cas de différence.

# Check what needs to be synchronized
try:
    for synchronizer in synchronizers:
        result['changed'] |= synchronizer.prepare()
except AnsibleError as e:
    result['msg'] = e.message
    module.fail_json(**result)

Appliquer les changements

Pour revenir au squelette décrit dans l’article précédent, la dernière étape est d’appliquer les changements quand une différence est détectée. Chaque synchroniseur consigne les états actuels et attendus dans, respectivement, sync_args["before"][table] et sync_args["after"][table] où table est le nom de la table correspondant au type d’objet NetBox. L’objet diff est un peu plus élaboré car il est construit table par table. Ansible affiche alors le nom de chaque table avant la représentation de la différence :

# Compute the diff
if module._diff and result['changed']:
    result['diff'] = [
        dict(
            before_header=table,
            after_header=table,
            before=yaml.safe_dump(sync_args["before"][table]),
            after=yaml.safe_dump(sync_args["after"][table]))
        for table in sync_args["after"]
        if sync_args["before"][table] != sync_args["after"][table]
    ]

# Stop here if check mode is enabled or if no change
if module.check_mode or not result['changed']:
    module.exit_json(**result)

Chaque synchroniseur expose également une méthode synchronize() pour appliquer les changements et une méthode cleanup() pour supprimer les objets indésirables. L’ordre est important en raison de la relation entre les objets.

# Synchronize
for synchronizer in synchronizers:
    synchronizer.synchronize()
for synchronizer in synchronizers[::-1]:
    synchronizer.cleanup()
module.exit_json(**result)

Le code complet est disponible sur GitHub. Par rapport à l’utilisation de la collection netbox.netbox, la logique est écrite en Python au lieu d’essayer d’assembler des tâches Ansible. Je pense que cela est à la fois plus flexible et plus facile à lire, notamment lorsque l’on essaie de supprimer des objets obsolètes. Bien que je n’aie pas testé, cela devrait également être plus rapide.

Une alternative aurait été de réutiliser le code de la collection netbox.netbox, car il contient des primitives similaires. Malheureusement, je n’y ai pas pensé jusqu’à présent. 😶