Hack on Zwindler's Reflection

Transformer Proxmox VE en node Kubernetes avec LXC et lxcri

Mon, 17 Nov 2025 18:00:00 +0200

Il ne savait pas que c’était complètement stupide, alors il l’a fait

Quel mensonge… Bien sûr, je sais très bien que c’est débile. Raison pour laquelle cette idée est donc irrésistible.

Si vous suivez le blog, vous savez que j’utilise beaucoup Proxmox VE (les articles qui attirent le plus sur le blog sont d’ailleurs des articles sur cette technologie de virtualisation).

Proxmox VE, c’est très cool ; on peut faire des VMs (QEMU) avec, mais aussi, si on n’a pas de VT-x ou qu’on veut des “lightweight VMs” (terme dont on a abusé à outrance), on peut installer des OS complets dans des containers avec LXC.

Mais au delà de ces deux solutions, les devs du projet Proxmox VE sont assez rigides (et pas que là dessus). C’est d’ailleurs pour ça que j’ai posté quelques “hacks” pour contourner les limitations de Proxmox, notamment cet article où j’explique comment lancer des containers Docker (via LXC) dans Proxmox VE (normalement pas possible).

Et si on allait encore plus loin dans le hack idiot ?

Et si, non seulement on exécutait des containers OCI dans Proxmox VE, mais qu’EN PLUS, on transformait nos hôtes Proxmox VE en ✨️ Nodes Kubernetes ✨️ ???

On s’y prend comment ?

Le but n’est évidemment pas d’installer Kubernetes à côté de Proxmox VE, mais réutiliser le plus de choses possibles. Typiquement, je vais réutiliser la techno de “virtu”.

Proxmox VE supportant 2 technos de virtualisation différentes (qemu et LXC), il faut choisir. Et comme j’aime bien LXC et que j’ai déjà expérimenté sur le hack Docker => LXC sur Proxmox VE, la question était vite répondue.

Toute la difficulté de l’exercice est de trouver comment rendre LXC “CRI-compatible”. Et on a de la chance, Linux Containers, la fondation qui chapeaute LXC et Incus (ex LXD, “refermé” par Canonical), a écrit il y a quelques années un CRI pour LXC appelé lxcri. Et bien sûr, comme c’est un projet à l’utilité discutable, le truc n’est plus maintenu depuis 2021.

J’avais d’ailleurs essayé de l’utiliser, passé pas mal de temps dessus en février 2024 (j’ai essuyé bug sur bug, suis passé par des forks, …) pour échouer lamentablement sur un problème de compatibilité avec ma version de LXC (5+ sous Proxmox 8, 6 en Proxmox 9), entre autres bugs.

lxcri is a wrapper around LXC which can be used as a drop-in container runtime replacement for use by CRI-O.

On va donc quand même avoir besoin de 3 trucs en plus sur notre serveur Proxmox pour que mon idée débile fonctionne :

lxcri comme container runtime de base niveau
cri-o comme container runtime de haut niveau
kubelet pour piloter le runtime et communiquer avec le control plane

C’est parti

OK. lxcri s’appuie donc sur cri-o, le container runtime de Red Hat. On commence donc par installer cri-o :

https://github.com/cri-o/cri-o/blob/main/install.md

Note : mon serveur Proxmox VE 8 de l’époque utilisait Debian 12 comme OS de base. On devrait donc se baser là-dessus pour la variable $OS (comme l’indique la doc). Cependant, à l’heure où j’ai testé la première fois, les dépôts de CRI-O étaient en cours de migration, avec une documentation pas à jour et des releases manquantes. Le répo download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o n’avait pas le PATH Debian_12, ni la version 1.29 de Kubernetes… J’avais BIEN ragé.

On ne devrait plus avoir de soucis maintenant :

export KUBERNETES_VERSION=v1.32
export CRIO_VERSION=v1.32

# créer un répertoire pour les keyrings (il n'existe pas toujours sur une install fraiche)
sudo mkdir -p /usr/share/keyrings

# répo de kubernetes
curl -fsSL https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/ /" |
 sudo tee /etc/apt/sources.list.d/kubernetes.list

# répo de crio
curl -fsSL https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/Release.key |
 sudo gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/ /" |
 sudo tee /etc/apt/sources.list.d/cri-o.list

sudo apt update
sudo apt install cri-o

A partir de là, on a cri-o. On pourrait le configurer mais si on fait ça, il utilisera runc et on n’utiliserait pas LXC en tant que runtime.

Ce n’est pas le but de ce hack !

C’est donc à ce moment là qu’on rebascule sur la documentation de lxcri :

github.com/lxc/lxcri

Ya pas de release

Et oui… il faut préalablement builder le binaire lxcri et le déposer dans le /usr/local de notre serveur Proxmox VE. Il n’y a pas de binaire précompilé dans le projet, c’est une issue ouverte juste avant qu’il ne soit abandonné 😬😬.

Et pour que ce soit encore plus fun, le processus de build passe par un Dockerfile, ce qui est rigolo puisqu’on n’a pas Docker sur notre node Proxmox…

J’ai donc essayé de builder lxcri depuis une machine avec Docker, en suivant la commande indiquée sur le GitHub. Patatra. (Déjà, il manque un “.” en fin de commande docker build dans la doc) ça fail misérablement à la compilation…

Note : je n’ai plus l’erreur en question, probablement un problème de dépendances. C’est relou parce qu’on va devoir faire plein de choses à la main… Mais ne vous embêtez pas à git clone, on va partir sur un fork (d’un fork).

En allant jeter un œil au Dockerfile, on se rend vite compte qu’on ne fait que lancer un script (install.sh)…

Quand on appelle Docker avec le buildarg installcmd=install_runtime, on lance la fonction install_runtime, qui appelle install_runtime_noclean, qui lance add_lxc puis add_lxcri.

Je veux juste compiler lxc (pour les bindings) et lxcri. Je vais donc le faire à la main. Pour ça, il faut golang 1.16 (ça date…).

Il y a pas mal de code pété un peu partout et plusieurs issues ouvertes dans lesquelles les mainteneurs conseillent de partir sur un fork :

https://github.com/drachenfels-de/lxcri

J’ai passé pas mal de temps à le débugger, et au final j’ai fait mon propre fork (https://github.com/zwindler/lxcri), qui nécessite golang 1.22+ et qui ajoute un gros paquet de fixes.

Prérequis pour builder lxcri

On va installer un paquet de trucs :

sudo apt update
sudo apt install curl git meson pkg-config cmake libdbus-1-dev docbook2x

On installe Golang si on ne l’a pas (peu de chance que vous ayez Golang sur un node Proxmox VE) :

wget https://go.dev/dl/go1.25.4.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.25.4.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version
 go version go1.25.4 linux/amd64

Je vais aussi devoir récupérer et compiler lxc. Pendant un moment, j’étais bloqué sur la version 4.0.12 (très précisément) car la 4.0.6 qu’on trouve sur Debian 11 ne fonctionne pas avec le code de lxcri (j’ai mangé plein de bugs).

Mais la bonne nouvelle, c’est que comme je suis un try-harder de l’espace, à force de fixes sur mon fork, celui-ci fonctionne avec la dernière version de lxc (6.x), ce qui tombe bien parce que c’est la version sur mon Proxmox VE 9 à jour.

git clone https://github.com/lxc/lxc
cd lxc

meson setup -Dprefix=/usr -Dsystemd-unitdir=PATH build
 Build targets in project: 30

 lxc 6.0.0

 User defined options
 prefix : /usr
 systemd-unitdir: PATH

 Found ninja-1.12.1 at /usr/bin/ninja

meson compile -C build
 INFO: autodetecting backend as ninja
 INFO: calculating backend command to run: /usr/bin/ninja -C /root/lxc/build
 ninja: Entering directory `/root/lxc/build'
 [544/544] Linking target src/lxc/tools/lxc-monitor

Ça a buildé plein de trucs, c’est cool. Mais les fichiers qui m’intéressent sont ici :

find . -name "lxc.pc"
./build/meson-private/lxc.pc

ls build/*lxc*
build/liblxc.so build/liblxc.so.1 build/liblxc.so.1.8.0 build/lxc.spec

build/liblxc.so.1.8.0.p:
liblxc.so.1.8.0.symbols

Je mets ça aux bons endroits dans mon Proxmox VE avec un :

sudo make install
sudo ldconfig

Builder comme jamais

Ok, c’est parti pour jouer avec mon fork :

git clone https://github.com/zwindler/lxcri.git lxcri.zwindler
cd lxcri.zwindler

make build
 go build -ldflags '-X main.version=8805687-dirty -X github.com/lxc/lxcri.defaultLibexecDir=/usr/local/libexec/lxcri' -o lxcri ./cmd/lxcri
 cc -Werror -Wpedantic -o lxcri-start cmd/lxcri-start/lxcri-start.c $(pkg-config --libs --cflags lxc)
 CGO_ENABLED=0 go build -o lxcri-init ./cmd/lxcri-init
 # this is paranoia - but ensure it is statically compiled
 ! ldd lxcri-init 2>/dev/null
 go build -o lxcri-hook ./cmd/lxcri-hook
 go build -o lxcri-hook-builtin ./cmd/lxcri-hook-builtin

ls -alrt
 total 15288
 [...]
 -rwxr-xr-x 1 debian debian 7108288 Nov 16 20:06 lxcri
 -rwxr-xr-x 1 debian debian 17520 Nov 16 20:06 lxcri-start
 -rwxr-xr-x 1 debian debian 2942584 Nov 16 20:06 lxcri-init
 -rwxr-xr-x 1 debian debian 2834743 Nov 16 20:06 lxcri-hook
 -rwxr-xr-x 1 debian debian 2519097 Nov 16 20:06 lxcri-hook-builtin

Si on était sur une machine de dev, on pourrait envoyer les binaires sur le serveur Proxmox VE (lxcri dans /usr/local/bin, le reste dans /usr/local/libexec/lxcri).

Dans mon cas, je suis directement sur la machine qui build et qui run, je fais donc :

$ sudo make install
 mkdir -p /usr/local/bin
 cp -v lxcri /usr/local/bin
 'lxcri' -> '/usr/local/bin/lxcri'
 mkdir -p /usr/local/libexec/lxcri
 cp -v lxcri-start lxcri-init lxcri-hook lxcri-hook-builtin /usr/local/libexec/lxcri
 'lxcri-start' -> '/usr/local/libexec/lxcri/lxcri-start'
 'lxcri-init' -> '/usr/local/libexec/lxcri/lxcri-init'
 'lxcri-hook' -> '/usr/local/libexec/lxcri/lxcri-hook'
 'lxcri-hook-builtin' -> '/usr/local/libexec/lxcri/lxcri-hook-builtin'

et on peut continuer :

$ /usr/local/bin/lxcri help
NAME:
 lxcri - lxcri is a OCI compliant runtime wrapper for lxc

USAGE:
 lxcri [global options] command [command options] [arguments...]

VERSION:
 8805687
[...]

On reprend crio

Ok, on a buildé lxcri et on a toutes les dépendances pour l’utiliser. On peut donc repartir sur la doc officielle de lxcri “setup.md” dans l’idée de configurer CRI-O, pour qu’il n’utilise pas runc, uniquement lxcri.

sudo tee /etc/crio/crio.conf.d/10-crio.conf > /dev/null <<'EOF'
[crio.image]
signature_policy = "/etc/crio/policy.json"

[crio.runtime]
default_runtime = "lxcri"

[crio.runtime.runtimes.lxcri]
runtime_path = "/usr/local/bin/lxcri"
runtime_type = "oci"
runtime_root = "/var/lib/lxc" #proxmox lxc folder
inherit_default_runtime = false
runtime_config_path = ""
container_min_memory = ""
monitor_path = "/usr/libexec/crio/conmon"
monitor_cgroup = "system.slice"
monitor_exec_cgroup = ""
privileged_without_host_devices = false
EOF

A noter, la doc d’installation setup.md nous dit générer une conf propre avec le binaire crio et la commande config, mais ça ne marche pas vraiment et on se retrouve à lancer runc ou crun sans le vouloir. J’écrase tout, c’est plus simple.

Et maintenant, on peut lancer crio :

sudo systemctl enable crio && sudo systemctl start crio

A partir de là, on a un serveur disposant d’un CRI a priori fonctionnel.

systemctl status crio
● crio.service - Container Runtime Interface for OCI (CRI-O)
 Loaded: loaded (/lib/systemd/system/crio.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2025-11-17 12:02:37 UTC; 12s ago

journalctl -u crio
Nov 17 20:29:43 instance-2025-11-16-15-31-55 systemd[1]: Starting Container Runtime Interface for OCI (CRI-O)...
[...]
Nov 17 20:29:43 instance-2025-11-16-15-31-55 crio[11906]: time="2025-11-17T20:29:43.61758425Z" level=info msg="Using runtime handler lxcri version 8805687"

Yeeees :D

On peut donc installer kubelet, puis l’ajouter à un cluster Kubernetes existant

Fast forward

J’avais la flemme de monter un cluster propre avec kubeadm ou autre, et d’enrôler ensuite un node à la main avec le token+sha. J’aurais aussi pu rejouer avec mon PoC rigolo des workers “linux” de Clever Cloud pour créer un control plane chez Clever, puis enrôler à la main avec le node bootstrap token (j’ai fait les choses plutôt bien dans ce PoC).

J’ai donc rejoué à l’arrache avec mon projet demystifions-kubernetes, qui permet de monter un cluster mono node à la main en lançant juste des binaires.

Une fois le control plane bootstrapé (etcd, api-server, controller-manager, scheduler), on s’arrête AVANT la partie containerd (on a déjà configuré CRI-O) et on lance le kubelet à la main :

sudo bin/kubelet --kubeconfig admin.conf --container-runtime-endpoint --container-runtime-endpoint=unix:///var/run/crio/crio.sock --fail-swap-on=false --cgroup-driver="systemd"
[...]
I1117 13:41:58.741561 88434 kubelet_node_status.go:78] "Successfully registered node" node="instance-2025-11-16-15-31-55"

On progresse ! Essayons de voir l’état de santé du cluster et de déployer un pod :

$ export KUBECONFIG=admin.conf
$ kubectl get nodes
 NAME STATUS ROLES AGE VERSION
 instance-2025-11-16-15-31-55 Ready <none> 13m v1.34.2

$ kubectl create deployment web --image=zwindler/vhelloworld
 deployment.apps/web created


$ kubectl get pods
 NAME READY STATUS RESTARTS AGE
 web-6c8cc48c68-cdbtj 1/1 Running 0 4m17s

$ kubectl logs web-6c8cc48c68-cdbtj
 [Vweb] Running app on http://localhost:8081/
 [Vweb] We have 3 workers

Great success!

Conclusion

A partir de là, CRI-O partage le moteur LXC de Proxmox VE de manière fonctionnelle.

Pour s’en convaincre, on peut lancer la commande lxc-ls, qui nous affichera un mix de “vrais” containers LXC (créés avec Proxmox, les 151 et 200) et de containers de pods (les STOPPED sont les init containers de cilium) :

$ lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
151 STOPPED 0 - - - true
200 STOPPED 0 - - - true
3045d1f3abcc069b1009acc869a27b09cf9531d0701a3f9d5a760213d57c7b20 STOPPED 0 - - - false
78057100e5d0613944c2be859dfd09f790eeba88bceebea0e04970841c9bd950 RUNNING 0 - 10.0.0.90 - false
8e5506beea9a50214c46f31fa7fa6d04397963cb912aa397261359865d40a0cd RUNNING 0 - 10.0.0.167, 10.244.0.1, 203.0.113.42, 192.168.1.10 2001:db8::1 false
abdcd5be0a27417aa9e11cc2b27882bc86a63d94f547f909332ca7470a5e075a STOPPED 0 - - - false
aeaed9c2f56328bb6196ede4a78f06c4bb2d3edf5dca7912cf38407b9bf6610a STOPPED 0 - - - false
ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d RUNNING 0 - 10.0.0.167, 10.244.0.1, 203.0.113.42, 192.168.1.10 2001:db8::1 false
edb9d42e35a4029cfec5bed5597746bdf67fbe438f21446230252265ed1c849d STOPPED 0 - - - false
$ ps -ef |grep ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d
root 2674943 1 0 22:32 ? 00:00:00 /usr/libexec/crio/conmon -b /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata -c ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d --exit-dir /var/run/crio/exits -l /var/log/pods/kube-system_cilium-operator-56d6cd6767-dps78_6082ea2d-331e-4262-b8b3-d3f88eb4e446/cilium-operator/1.log --log-level info -n k8s_cilium-operator_cilium-operator-56d6cd6767-dps78_kube-system_6082ea2d-331e-4262-b8b3-d3f88eb4e446_1 -P /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata/conmon-pidfile -p /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata/pidfile --persist-dir /var/lib/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata -r /usr/local/bin/lxcri --runtime-arg --root=/var/lib/lxc --socket-dir-path /var/run/crio --syslog -u ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d -s
root 2674951 2674943 0 22:32 ? 00:00:00 /usr/local/libexec/lxcri/lxcri-start ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d /var/lib/lxc /var/lib/lxc/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/config

Rien ne nous empêcherait ensuite de pousser le vice, et de faire un petit script qui récupère toutes les informations des containers, et crée les fichiers /etc/pve/lxc/xxx.conf associés de manière à les afficher dans l’UI, comme je l’avais fait dans l’article :

Lancer des containers Docker avec Proxmox VE (et LXC)

En théorie, si cette étape avait du sens, je pourrais créer les releases moi-même sur mon fork pour faciliter l’installation.

Enfin, je pourrais essayer de contribuer mes modifications pour que tout soit mergé sur le projet principal, à ceci près que les mainteneurs refusent les PRs car le projet n’est plus maintenu.

Mais j’avoue qu’après probablement une quinzaine d’heures de debug, de Golang, de compilation C, réparties sur 2 ans, j’ai un peu été au bout de ma patience pour cette “blague”.

OK, c’était débile, maintenant que j’ai réussi, dodo X_X.

QNAP débranche LXC sur les NAS ARM : comment contourner ?

Mon, 13 Jun 2022 08:00:00 +0200

Si vous le suivez sur Twitter ou Masto, vous m’avez très probablement lu râler contre la sortie ~~de QTS 5~~ Container Station v2.4.0.2316, l’été dernier.

Ou plus particulièrement, contre une décision prise lors de ce passage : enlever LXC pour l’administration des containers, au profit de LXD. LXD étant juste une couche d’administration, LXC est toujours présent et fonctionnel, juste caché.

Pourquoi je râle ?

J’ai un NAS QNAP TS431P2 depuis 2018 dont je suis pleinement satisfait, et qui m’a permis de passer moins de temps à administrer et ajouter des fonctionnalités à mon NAS ZFS maison, monté initialement en 2011 (merci Dworak_of_sky pour les souvenirs).

Sauf que mon QNAP est un NAS milieu de gamme, fonctionnant avec un processeur ARM et pas x86 ! Et ces charmantes personnes (grrrr) de chez QNAP n’ont pas porté LXD sur les NAS ARM (segmentation artificielle de l’offre ? Flemme ?).

Nous, propriétaires de NAS QNAP ARM, nous retrouvons donc sans solution puisque LXC est désactivé et LXD pas disponible.

Une fonction hyper pratique pour héberger de petits services à bas coût (autant en performance qu’en prix) disparaît. C’était un réel différenciant pour ce modèle et je me sens vraiment trahi (ou alors c’est ma faute, car je n’aurais pas dû leur faire confiance ?).

Je ne suis pas près de recommander QNAP comme j’ai pu le faire par le passé. #PasContent

Nuance

HEUREUSEMENT, les containers LXC ne se sont pas mis à ne plus marcher du jour au lendemain.

Enfin, encore heureux ! Je n’ose imaginer les dégâts en prod !

C’est d’autant plus vicelard que le message d’information pour expliquer qu’il n’y a plus LXC indique que c’est pas grave puisque vous avez LXD à la place. Aucune mention du fait qu’en fait, sous ARM, non…

Il est toujours possible (pour l’instant) de démarrer, arrêter, utiliser et supprimer les containers existants. Mais il n’est plus possible d’en créer de nouveaux.

Ça veut donc dire que tout est encore présent pour faire fonctionner la fonctionnalité, ce n’est “juste” plus disponible en UI.

En avoir le coeur net

En farfouillant, je me suis aussi rendu compte qu’il était toujours possible d’exporter des containers existants et d’importer les exports.

On peut donc contourner la limitation arbitraire de QNAP via des export / import. J’ai l’habitude de ce genre de bidouilles, puisque je faisais déjà ça il y a plus de 10 ans avec les hyperviseurs VMware en licence gratuite…

A l’usage, ça fonctionne mais c’est pas satisfaisant. D’abord parce que si on a pas, ou plus, de containers sur le NAS, on ne peut pas le faire trivialement.

Ensuite, parce que le processus et long (l’export et l’import) et pénible (plusieurs étapes).

Enfin, parce que les images LXC mises à disposition par QNAP étaient antédiluviennes !

Ubuntu 14.04 !!! Sauf si vous avez pris le temps de faire le processus d’upgrade complet de 14.04 à 20.04 ou 22.04 (et vous devriez), il est probable que vous n’ayez pas envie de repartir de ces vieux machins.

“Faites mieux”

Si vous êtes admin, vous avez probablement déjà activé SSH pour vous connecter directement à l’OS de votre NAS. (Et sinon vous pouvez aller ici pour l’activer)

Une fois connecté, on peut sortir du menu TUI et bidouiller l’OS comme on en a envie.

[~] # id
uid=0(admin) gid=0(administrators)

Je n’ai pas fait beaucoup d’administration LXC/LXD directement, car j’avais toujours une interface à ma disposition pour me “cacher” la façon dont ça fonctionne vraiment, que ce soit dans le cas de QNAP ou de Proxmox VE (que j’utilise beaucoup pour ça).

En lisant rapidement la doc sur ubuntu-fr, j’ai compris qu’il existait en fait chez Canonical un genre de dépôt d’images officielles de pleins d’OS, notamment compatible armhf.

Avec LXC, on peut accéder directement à ces images en ligne de commande avec lxc-download. Pas de bol, la commande n’est pas dispo sur QTS :

[~] # lxc-download
-sh: lxc-download: command not found

(En fait elle n’est juste pas dans le PATH, mais je ne le savais pas à ce moment-là)

Sauf qu’on peut aussi appeler directement la commande pour créer des containers lxc-create avec un flag “download”. Et ça tombe bien parce que lxc-create est disponible. Mais la joie sera de courte durée…

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf

/usr/local/container-station/lxc/share/lxc/templates/lxc-download: line 237: getopt: command not found

Hack…

Note : si vous trouviez que ce qu’on était en train de faire n’était déjà pas très propre, je tiens à vous prévenir, la suite est vraiment immonde… Pas merci QNAP de me forcer à faire ça !

Le script /usr/local/container-station/lxc/share/lxc/templates/lxc-download est moisi. Il manque la moitié des binaires dans la busybox.

Pire encore, la procédure que je donne ici semble être écrasée à chaque mise à jour de l’application Container Station. Mais, ça fonctionne…

La première chose qu’on va faire, c’est faire une sauvegarde du script lxc-download par sécurité.

cp /usr/local/container-station/lxc/share/lxc/templates/lxc-download{,.old}

Le premier message d’erreur qu’on a getopt: command not found indique juste que de nombreux binaires “classiques” ne sont pas disponibles directement dans le shell de QTS.

Sauf qu’en fait, ils sont là, ces binaires. Pas besoin de les télécharger ou de les compiler. Ils ne sont juste “pas visibles”.

QTS tourne, comme beaucoup de serveurs Linux minimalistes, avec l’aide de Busybox.

On peut donc “magiquement activer” les binaires qui nous manquent simplement avec des liens symboliques.

for binary in getopt xz seq; do
 ln -s /share/CACHEDEV1_DATA/.qpkg/container-station/bin/busybox /share/CACHEDEV1_DATA/.qpkg/container-station/bin/${binary}
done

getopt
getopt: missing optstring argument

… and slash!

C’est bon, mais pas suffisant.

La version du binaire mktemp de busybox n’est malheureusement PAS compatible avec le script lxc-download. On va devoir le modifier à la main…

Usage: mktemp [-dq] TEMPLATE

Le passage problématique se situe autour des lignes 320-325

320 if ! command -V mktemp >/dev/null 2>&1; then
321 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmp/lxc-download.$$"
322 else
323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}$(mktemp -d)"
324 fi

En vrai, mktemp s’attend à avoir le path complet, accompagné d’un pattern à base de XXXXXX. mktemp remplace ensuite les caractères XXXXXX par un nombre aléatoire en s’assurant que le dossier n’existe pas déjà, puis le créé. Par exemple

mktemp /tmp/mydirXXXXX

Mode bourrin, j’ai remplacé la ligne par :

323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmpdir" && mkdir -p ${DOWNLOAD_TEMP}

De toute façon, il est supprimé à la fin de l’exécution du script, ce dossier (fonction cleanup dans le shell).

GPG

On progresse !

[~] # lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf
Setting up the GPG keyring
chmod: /var/lib/lxc/container_jammy/tmpdir/gpg: No such file or directory
Error creating container container_jammy

En creusant un peu, la vraie erreur est que je n’ai pas le binaire gpgkeys_curl à l’endroit attendu :

gpg: unable to execute program `/opt/cross-project/arm/linaro/arm-linux-gnueabihf/libc/libexec/gnupg/gpgkeys_curl': No such file or directory

Voilà un autre point que je n’ai pas réussi à corriger correctement.

Le plus simple est de simplement ignorer la validation avec --no-validate mais si vous avez une piste, je suis preneur.

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf --no-validate

Des dossiers qui disparaissent tout seul ???

Dernier mystère…

Downloading the image index
ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-system

L’erreur n’est pas du tout un problème d’accès à l’URL pour télécharger l’index des systèmes disponibles sur images.linuxcontainers.org (code 302, page redirigée sur uk.lxd.images.canonical.com).

En réalité, si active les messages d’erreurs lors du wget dans le script, l’erreur est que le dossier /var/lib/lxc/container_jammy/tmpdir/ n’existe pas !

Pourtant, ça devrait être corrigé, suite à la modif qu’on a faite ligne 323 (voir plus haut)… trop bizarre :/

J’en ai eu un peu marre de creuser et au bout d’un moment, j’ai juste fait :

export CONTAINER_NAME=jammy
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/tmpdir/
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/rootfs/
lxc-create -t download -n ${CONTAINER_NAME} -- -d ubuntu -r jammy -a armhf --no-validate

Et croyez-le ou non, mais ça marche ! Le container existe (il n’est juste pas visible dans la console pour l’instant)

[...]
You just created an Ubuntu jammy armhf (20220611_07:42) container.

On a plus qu’à redémarrer Container Station, il apparaît

Conclusion

Si jamais quelqu’un de chez QNAP lit ce blogpost… Arrêtez de vous fiche de nous et :

mettez nous LXD dans nos NAS ARM
OU si c’est trop de boulot (je peux l’entendre), remettre LXC en attendant.

Ce genre de hack est indigne et j’ai perdu plusieurs heures pour corriger votre m***e. J’ai payé pour un NAS compatible LXC, ce n’est pas pour que vous retiriez la fonctionnalité 1 an après.

Ce genre de pratiques est vraiment dégueulasse et je n’hésiterais pas à dire tout le mal que je pense de cette décision.

Sources

Retrouvez-moi à Devoxx France 2022

Mon, 18 Apr 2022 12:00:00 +0000

J’ai 10 ans 🎶

Devoxx France revient après deux ans de Covid (chaotique pour tout le monde) en présentiel total. Et ce n’est pas n’importe quelle édition de Devoxx, c’est l’année des 10 ans !

Pour ceux qui ne sont pas familiers de cette conférence, Devoxx c’est :

Conférence pour développeurs organisée par Quantixx au Palais des Congrès, à Paris. 60 exposants pendant 3 jours. 3000 visiteurs. 260 orateurs, 220 présentations, ateliers et plénières.

Et cette fois-ci, je serai présent sur les 3 jours, en particulier le jeudi puisque je donnerai mon talk “Ciel, mon Kubernetes mine des bitcoins” (slides ici, comme d’habitude). Je donnerai la conférence le jeudi à 14:30 en salle 243.

J’en parle dans mon billet sur le temps que je mets à préparer une conférence, être sélectionné à des conférences, c’est compliqué, mais à Devoxx encore plus. Il y a beaucoup de speakers expérimentés et de nombreux talks passionnants en simultanée.

Je suis donc particulièrement content de faire partie des heureux élus :). Une superbe occasion de revoir (ou rencontrer IRL) des copains des Internets et des anciens collègues (va même falloir faire une liste je crois 😅).

Comment on fait pour venir ?

Evidemment, il est trop tard pour prendre un billet pour les conférences (ça part en quelques heures), mais cette année il est possible d’accéder au salon et aux stands d’exposants gratuitement, et même d’accéder à certaines conférences, le jeudi soir.

Seule condition, avoir un billet (gratuit du coup je le répète) pour avoir accès aux stands ou aux BOF (événement terminé).

Dans tous les cas, que vous ayez un billet conférence, speaker ou “salon”, n’hésitez pas à me pinger sur Bluesky, Mastodon (@zwindler@framapiaf.org) ou LinkedIn si vous voulez me faire un coucou 👋, ça sera avec grand plaisir !

Le pitch de mon talk

A tort ou à raison, Kubernetes s’est imposé, ces 4 dernières années, comme un des nouveaux standards dans la gestion des architectures microservices modernes.

Cependant cet outil, riche plus que complexe, amène son lot de pièges dans lesquels les débutants ne manqueront pas de tomber… Et ce n’est pas l’apparente facilité apportée par les offres Kubernetes as a Service qui va arranger les choses !

Après un rapide tour de l’actualité sécurité autour de Kubernetes, je vous donnerai les clés pour éviter de vous faire voler (trop facilement) vos cycles CPU.

Android Auto sur R-LINK 1 - Chérie, j'ai briqué la voiture...

Fri, 08 Apr 2022 16:00:00 +0000

Chérie, j’ai briqué la voiture

Qui n’a jamais eu envie de casser sa voiture en allant trifouiller dans les paramètres de l’ordinateur de bord ? Probablement personne, en fait…

Mais rassurez-vous, j’ai mis le titre pour la ref à “chérie, j’ai rétréci les gosses”, film de mon enfance. Aucun véhicule motorisé n’a été blessé lors de la réalisation de cet article.

Note de service : je vous conseille de NE PAS reproduire ça et je vous enverrai paitre si vous m’accusez d’avoir cassé votre RLINK suite à une mauvaise manipulation.

D’abord un peu de contexte. Mon véhicule principal (même si je ne l’utilise pratiquement plus), date de 2014. A l’époque, Renault équipait ses nouveaux véhicules d’une tablette Android depuis 2012, modifiée avec une interface maison qu’ils appellent le RLINK (version 1 à l’époque), en partenariat avec Tomtom.

Cette tablette est une vraie m***e. Buguée (l’autoradio se bloque même moteur coupé/voiture verrouillée, son à fond… sympa pour la batterie), compatible avec à peu près aucune application (encore moins qui seraient utiles), cartographie payante (très chère), en retard de près de plus de 6 mois au moment où vous l’achetez et plus compatible avec la carte SD initiale car trop grande…

90€ pour une carte pas à jour, que je peux pas faire rentrer sur ma SD sur un système de navigation bugué : l’affaire du siècle !

Android Auto à la rescousse

A peu près au même moment, Google a annoncé en 2014-2015 la sortie du système Android Auto : vous connectez votre smartphone en USB à une tablette Android compatible, et hop, c’est les applications de votre smartphone que vous retrouvez à l’écran.

Waze, Deezer, etc. Tout ce dont j’ai besoin pour de longs trajets !

Sauf que la spec pour sélectionner les appareils compatibles avec le système Android Auto est sortie vraisemblablement un peu trop tard pour que Renault puisse rendre le système RLINK certifié compatible par Google…

Qu’à cela ne tienne

Alors, si encore c’était vraiment pas conçu pour et qu’on ne pouvait pas du tout l’avoir pour de bonnes raisons techniques, j’en aurais fait mon deuil et j’aurais payé des cartographies comme tous les autres automobilistes captifs de leur constructeur…

Sauf qu’assez vite, je suis tombé sur des posts de gens qui avaient réussi à “activer” Waze sur leur RLINK-1.

Et je dis bien “activer”. Car la fonctionnalité est intégrée à la tablette, il y a “juste” un booléen à passer à true pour que ça fonctionne… de quoi piquer ma curiosité.

Bon… en vrai, il a fallu que je m’y reprenne plusieurs fois avant de réussir à le faire marcher, car il y a pas mal d’étapes et d’embûches. Il existe depuis 2018 un tutoriel pour y parvenir, disponible sur le site gps-carminat.com.

Le but de cet article n’est pas de faire une redite des informations présentes sur ce site. Mais comme souvent, les tutos qu’on trouve sur le net ne sont pas toujours hypers clairs, pas toujours très jours, omettent des choses… Et je sais pas vous mais je trouve quand même marrant (et dangereux) de toucher au soft de sa voiture donc je vous propose de vous montrer ce que j’ai fait pour arriver à mes fins.

MyRenault ou les limbes d’un logiciel à l’abandon

Le premier prérequis avant de commencer à imaginer débloquer Android Auto sur un RLINK est d’abord de le mettre à jour (>11.343). Et c’est presque le plus difficile aujourd’hui, tant ce système est abandonné depuis des années par Renault…

Liens cassés, navigation pétée quelque-soit le navigateur, UI de l’enfer avec des liens cachés qui envoient vers des liens de liens… Ca a l’air réparé aujourd’hui, mais ça n’a pas marché pendant plusieurs mois, me renvoyant systématiquement des erreurs

https://www.renault.fr/?error=9

En théorie, il faut se rendre sur myr.renault.fr, puis ouvrir le r-link-store une fois qu’on a sélectionné son véhicule.

Là, on peut télécharger le RLINK Toolbox (un soft qui ne marche que sous Windows et MacOS) et suivre les instructions pour mettre à jour la tablette (via la carde SD que vous aurez probablement récupéré dans la voiture).

fr.rlinkstore.com/installation

Le processus de mise à jour est pénible de mémoire mais ça fonctionne la plupart du temps (c’est juste très long et il faut un lecteur de carte SD). Une fois à jour, votre RLINK devrait ressembler à ça (ici j’ai la 11.346)

Matériel

Pour hacker une voiture, il ne faut pas seulement du logiciel. Il va nous falloir du matériel et on va devoir mettre les mains dans le cambouis.

Normalement, pour accéder à l’ordinateur de bord de la voiture, il existe une interface universelle appelée OBD-II. Vous connaissez surement ça sans le savoir, c’est ni plus ni moins que le port que votre garagiste branche quand “il branche la valise”, qui est un PC+écran et une interface OBD-2.

Pendant longtemps, ce système était couteux et réservé aux pros car cher. Cependant, il existe maintenant depuis des années de boitiers USB, WIFI ou bluetooth qui permettent de faire l’interface avec la voiture. N’importe quel ordinateur devient donc une “valise de garagiste”, pour environ 20€.

J’ai pris comme conseillé dans le tuto une sonde ELM (celle en WIFI, car l’USB n’était plus dispo) et une rallonge OBD.

Note : pas de bol pour moi, la sonde WIFI n’a jamais marché et j’ai abandonné pendant plusieurs mois alors qu’il fallait juste en prendre une autre… J’ai insisté récemment, en en prenant une autre, en USB, pas spécialement conseillée mais qui a très bien fonctionné.

Comme chez Renault ce sont de petits blagueurs, on va aussi devoir modifier le cablâge de notre sonde (d’où la rallonge), car pour accéder au système OBD du RLINK, il faut changer de place certains fils !!!

C’est très bien expliqué sur le tuto de gps-carminat :

www.gps-carminat.com/v3/r-link/activer-android-auto-waze-sur-r-link-1

Grosso modo, ça donne ça :

Installer DDT4ALL

Le gros de modifs vont être réalisées à l’aide de l’outil DDT4ALL que Cédric PAILLE a gentiment opensourcé. Je lui ai fait un petit don et si ce soft vous ait utile je vous invite à faire de même.

Sous Linux, il suffit de cloner le projet et d’installer quelques packages pip3

git clone https://github.com/cedricp/ddt4all.git && cd ddt4all
pip3 install PyQt5
pip3 install PyQtWebEngine

python ddt4all.py

Sous Windows, il y a un installer de l’outil, compatible depuis novembre 2020 avec Windows 10 et Python 3 (ce qui n’était pas le cas lors de mes premiers tests)

Dans les deux cas, on obtient une interface graphique pour modifier notre véhicule (hinhinhin).

Trouver une base DDT2000

Vu que le tuto de gps-carminat ne propose pas de téléchargement pour cette partie ni même de liens pour la trouver… je me demande si posséder ou partager cette base est totalement légal…

Enfin… en insistant un peu on finit par trouver un fichier DDT2000data.zip.

Cette partie n’est pas super claire dans le tuto. Il faut copier le dossier contenu dans l’archive, sans changer le nom “ddt2000data” dans C:\Program Files (x86)\ddt4all. On se retrouve donc avec un dossier C:\Program Files (x86)\ddt4all\ddt2000data avec plusieurs sous dossiers.

Brancher la sonde

Si vous ne savez pas où brancher la sonde OBD sur votre voiture, outilsobdfacile est un site qui permet, entre autres, de le trouver, quelque soit votre véhicule.

Lancer le logiciel DDT4ALL

Cette partie-là n’était pas non plus hyper claire dans le tuto. Une fois la sonde choisie dans le premier menu, le tuto nous dit d’abord de cliquer sur l’icône Einstein [5] puis choisir le mode “After sale” dans le menu déroulant.

En réalité, ce n’est pas (ou plus ?) du tout le bon ordre. Il faut d’abord choisir son véhicule [1] dans la première liste déroulante, tout en haut à gauche.

Ensuite, on cherche le menu Navigation, puis MFD 5.4 [2] (le tuto parle de MFD 4.6 mais il n’existe pas sur mon véhicule).

Et une fois qu’on l’a trouvé, on double clique dessus, ce qui le fait apparaitre dans le menu juste en dessous [3] et on clique là où il vient d’apparaitre.

Une fois toutes ces étapes passées, on peut cliquer sur “Ecrans”, “Configuration” et chercher le fameux menu 13 – ECU configuration ADAS dans lequel configurer Android Auto [4].

A partir de la seulement, on peut le sélectionner, puis sélectionner le mode “After sales” [6]. J’ai tatônné un moment avant de comprendre ça.

Après application des modifications, reboot de la tablette (5 fois Home) et branchement du smartphone, c’est une victoire :)

Sites utiles

Open Source Experience 2021 – Récap’ du premier jour

Wed, 10 Nov 2021 08:00:00 +0000

Première conférence en présentiel de 2021 !

Ca fait quelque chose…

Revenir… IRL… dans une conférence !

Et quelle conférence ! Pour la première fois, je participais à l’Open Source Experience (que vous connaissez peut être sous son ancien nom, le Paris Open Source Summit, voire Solution Linux pour les plus vieux 😉).

Ca se passait au palais des congrès de Paris, porte Maillot, et je vous avais déjà dit que j’étais (en plus !) speaker.

L’occasion de voir des conférences, mais aussi de rencontrer pas mal de gens, que je “connaissais d’Internet” ou pas du tout.

API != REST – procmail à la rescousse

Dans un talk vraiment détendu, Bruno CORNEC et Frédéric PASSERON nous ont présenté la façon dont était câblé l’API de la plateforme de Workshops on Demand sur le site hackshack.hpedev.io/workshops (lien mort)

L’idée était que, pour les besoins de leur outil de Workshops on demand, l’utilisation d’une API de type REST était totalement surdimensionnée et que le SMTP (certes protocole vénérable) dispose by design d’un traitement de message par file / asynchrone.

Une façon fun de montrer, selon eux, que ce n’est pas parce qu’une technologie n’est pas récente et/ou à la mode qu’elle n’est pas fonctionnelle.

Les environnements sont ensuite provisionnés avec un mélange de scripts bash mais surtout d’Ansible et je ne peux donc qu’approuver leur travail 😉.

Ciel mon Kubernetes mine des bitcoins

Bon, je ne vais pas vous refaire le match, c’était ma conférence et si vous souhaitez relire les slides, elles sont disponibles ici ;-)

Construction d’images de containers à l’aide de Kaniko

Yannig PERRE nous a présenté l’outil Kaniko, poussé par GoogleContainerTools, qui permet de construire des images de container Docker sans Docker.

Le talk commence sur un constat : si l’écosystème Kubernetes repose très majoritairement sur l’utilisation d’image de container Docker pour exécuter les runtime, Docker, lui, est de moins en moins disponible sur les serveurs Kubernetes eux même (débrayable depuis 2016 et le CRI, officiellement déprécié en 1.20).

Kaniko est donc un container qui va nous servir à construire des images docker, qu’on poussera ensuite sur notre registry, le tout sans démon/binaire Docker.

Grosso modo, le fonctionnement de base n’est que peu changé, avec le support de l’API v2 et des multistage build. Seuls petits bémols, de par sa conception Kaniko est un container qui nécessite d’être lancé avec root (mais sans privilèges particuliers) et Kaniko ne permet pas de builder une image sans la push.

Kaniko nécessite également de réfléchir un peu à la façon dont vous allez gérer vos caches pour la constructions des images. Au delà de ces points d’attention, l’outil semble assez mature.

github.com/GoogleContainerTools/kaniko

Construire un outil de CLI userfriendly

Nicolas LEPAGE a commencé ce talk par une anecdote qui m’a bien fait sourire : il a raconté qu’un jour, on lui a dit que pour rechercher des informations sur un processus, on lui avait dit de faire un ps aux et qu’il n’avait pas pendant des années, cherché à savoir à quoi correspondaient “aux”.

Le fait qu’on connaisse tous cette commande, sans pour autant tous être au courant du rôle de chaque “flag” est assez évocateur de l’UX parfois discutable de certaines commandes UNIX.

Nicolas a donc profité de ce talk pour faire un tour des bonnes pratiques et conventions pour que les utilisateurs de vos futures CLI ne mangent pas leur chapeau. Je vous en donne quelques unes pelle mêle :

Avoir des options longues (débutant par --, avec des mots séparés par un tiret)
- éventuellement des options courtes (1 tiret 1 lettre, éventuellement groupable avec d’autres lettres)
Des options usuelles qu’on s’attend à trouver (ex. –help, –version)
Une convention différente pour les commandes et les options
- éventuellement des groupes de commandes voire des hiérarchies de “groupes + sous groupes” de commandes

Nicolas nous a rappelé qu’il ne fallait pas oublier qu’une CLI a parfois vocation à être lancée dans un script ou par un processus (ajouter des options avec des valeurs par défaut qu’on peut surcharger si besoin, par exemple pour celles nécessitant un terminal), permettre d’ajouter de la configuration.

Les slides sont disponibles ici (lien mort, pas dispo sur Internet Archive)

Infrastructure As Code : quelles tendances ? De l’automatisation à l’orchestration multicloud !

Comme le titre du talk de Pierre VILLARD le laisse penser, c’était un état de l’art de l’automatisation et de l’orchestration.

Après un rapide tour d’horizon des différents types d’outils qui existent (Génération de template / Orchestration / Gestion de configuration), Pierre nous a donné quelques exemples des outils les plus connus, avec des alternatives.

Pour la partie templating, on peut citer Packer, buildpacks.io et Kaniko, chacun avec leurs usages et leurs faiblesses.

Si tous les grands providers de cloud disposent de leur propre manière de déployer des ressources, quand on fait du multi-cloud, Pulumi est une alternative intéressante.

Gestion de configuration pure, Ansible reste sans conteste l’outil le plus populaire.

Pierre nous a également parlé d’une dernière catégorie d’outils : le Policy as code. Ces outils nous permettent de vérifier que le code IaC qui est produit est conforme aux politiques de sécurité et de conformité de l’entreprise. Dans cette catégorie, on peut citer évidemment Open Policy Agent et Kyverno, deux outils de la CNCF.

Exposants, visiteurs et village associatif

Au delà des conférences, cet événement était l’occasion rêvée de rencontrer des gens qu’on avait pas pu voir “en vrai” depuis quasiment 2 ans.

J’ai eu une discussion passionnante avec les business model des entreprises éditant des logiciels open sources avec Ludovic DUBOST de XWiki et Cryptpad.

J’ai également pu parler avec l’équipe de développement de XCP-NG, une alternative libre à XenServer (lui même basé sur Xen) assez prometteuse. La communauté est assez active, a ajouté le support de terraform et travaille pour écrire une API pour piloter XCP-NG avec Kubernetes (de la même manière qu’on peut le faire avec kubevirt).

J’ai assisté à une présentation de la dernière beta de Rudder que je ne connaissais pas du tout (au delà du nom). Même si le produit ne s’adresse pas prioritairement à des admins systèmes

J’ai eu une discussion passionnante avec les gens de Centreon sur le monitoring et l’observabilité en général. On a aussi beaucoup parlé de haute disponibilité des brokers/pollers 😏.

J’ai également pas mal discuté Genma, AtaxyaNetwork (& une partie de la team Aquaray), Rémi VERCHERE, Nicolas LEPAGE, la team de LinuxFR.

De très belles rencontres :).

[OSXP 2021] Ciel ! Mon Kubernetes mine des bitcoins

Mon, 11 Oct 2021 06:20:00 +0000

Open Source Experience, le successeur du Paris Open Source Summit

GROSSE (mais excellente) surprise ! Je serai speaker à l’OSXP qui se déroulera au Palais des congrès à Paris les 9 et 10 novembre prochains (et c’est gratuit) ! J’avais cité le POSS dans un de mes tout premiers talks et je ne pensais pas un jour y être moi-même :).

A vrai dire, j’ai postulé sans grand espoir et c’est une version modifiée (20 minutes au lieu de 40) de mon talk « Ciel, mon Kubernetes mine des bitcoins » qui a été sélectionné. Je suis vraiment très flatté, car c’est ma plus grosse conf en tant que speaker jusqu’à présent.

Dans les speakers il y a de très beaux noms (certains que j’ai hâte de retrouver, d’autre que j’ai hâte de rencontrer), je vous laisse jeter un œil :

www.opensource-experience.com/programme/intervenants-2021/

Je serai également présent sur les 2 jours et aurait ainsi l’occasion de vous rencontrer. N’hésitez pas à me prévenir si vous venez, ou à m’écrire sur Twitter si vous voulez qu’on se cale un créneau pour discuter :)

Le pitch

A tort ou à raison, Kubernetes s’est imposé, ces 4 dernières années, comme un des nouveaux standards dans la gestion des architectures microservices modernes.

Cependant cet outil, riche plus que complexe, amène son lot de pièges dans lesquels les débutants ne manqueront pas de tomber… Et ce n’est pas l’apparente facilité apportée par les offres Kubernetes as a Service qui va arranger les choses !

Après un rapide tour de l’actualité sécurité autour de Kubernetes, je vous donnerai les clés pour éviter de vous faire voler (trop facilement) vos cycles CPU.

Slides

Comme à mon habitude, je met les slides à disposition ici pour que vous pouviez cliquer sur les liens en même temps que le talk :-)

Hacker un calendrier javascript (datepicker) avec un scraper python

Tue, 09 May 2017 12:00:26 +0000

Mais quel rapport entre un datepicker javascript et un scraper python ?

Si vous ne savez ni ce qu’est un datepicker en Javascript ou un scraper python, je vous ai probablement déjà perdu. Pourtant, dans cet article ultra fun (ok, je suis bizarre), je vous montrerai comme j’ai automatisé via un scraper développé en python la recherche de dates libres dans un calendrier Javascript sur une page web :

en scriptant la génération de cette page via une ligne de commande
en simulant un clic pour passer au mois suivant
et enfin en récupérant les bonnes valeurs (pour me les envoyer par email par exemple)

Commençons donc par un peu de storytelling

Depuis quelques mois, je vais régulièrement sur un site web un peu artisanal sur lequel je fais des réservations. Pour se faire, ce site web propose une page web simple dans lequel a été intégré un composant calendrier :

Rien de particulièrement extraordinaire jusque là.

Mais (car bien sûr il y a un mais), ce site à l’inconvénient d’être victime de son succès. Pour vous donner une idée, c’est le genre de site web qui tombe 30 secondes après l’ouverture des réservations à 19h00. Et que dès que l’administrateur système le relance entre 20 et 50 minutes plus tard, les réservations sont complètes en quelques minutes.

Méthode 1 : F5

La première méthode, probablement plébiscité par la plupart des utilisateurs, est à base de refresh frénétique du site web, jusqu’à ce qu’il devienne inopérant… Une fois que le site est down, on peut continuer à appuyer sur F5 en espérant être le premier quand il reviendra.

Le souci de cette méthode, c’est que je manque cruellement de patience et que je lâche l’affaire assez vite. Et donc tous les mois, les plus hargneux (ou les plus chanceux) me passent toujours devant car j’ai loupé le moment où le site redevient accessible.

Méthode 2 : cURL

En bon administrateur système que je suis, je ne pouvais pas me résoudre à en rester là. Mon problème principal étant d’être prévenu lorsque le site devenait à nouveau opérationnel, j’ai sorti ma boîte à outils habituelle : cURL !

cURL (abréviation de client URL request library), est un outil à tout faire quand on veut jouer avec des URL sur un serveur Linux. C’est simple et efficace.

Dans le cas où le site est tombé suite à la connexion massive des internautes avides de réservations, j’ai donc créé un petit script basé sur ce oneliner

curl http://@IP_ou_FQDN/le_chemin_de_la_page/ -I 2>/dev/null | head -n 1
HTTP/1.1 200 OK

Dès que le code retour passe de 503 à 200, c’est que le site web est de nouveau accessible et je peux me remettre à faire F5 en espérant que les réservations ouvrent.

Méthode 2bis : aller plus loin avec cURL

Bon… La méthode précédente fonctionne… mais ce n’est pas encore ça !

Typiquement, il arrive que l’ouverture des dates soit reportée au lendemain, quand le site est vraiment trop longtemps dans les choux. Du coup le site répond (et mon test me revoie que le site est opérationnel), mais les dates ne sont pas disponibles pour autant…

Un rapide coup d’œil aux sources me donne l’info que je cherche. Il n’y a plus qu’à automatiser ça.

Mais évidemment ça n’est pas si simple…

Firefox interprète le Javascript, mais pas cURL, qui ne sait pas interpréter le Javascript (cf ce post de Stack Overflow). Le retour de ma commande contient donc le code source HTML avec le Javascript brut, mais pas les données que je recherche…

Méthode 3 : Un scraper ?

Je dois écrire un scraper qui va aller simuler l’action de l’humain qui va ouvrir la page dans un navigateur. Le post de Stack Overflow cite PhantomJS qui est probablement une bonne solution.

PhantomJS is a headless WebKit scriptable with a JavaScript API. It has fast and native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.

Cependant je ne connais pas bien JS (ça fait longtemps on va dire) et je préfère capitaliser sur Python. J’ai donc cherché un module Python pour régler mon problème, et j’en ai trouvé 2 : un module python selenium et un plus simple appelé dryscrape.

J’ai installé dryscrape sur un de mes serveurs (un CentOS 7 minimal, sans environnement graphique). La documentation de dryscrape est disponible ici et ici (stable, documentation plus fournie).

yum install -y qt5-qtwebkit-devel gcc-c++
sed -i 's/PATH=$PATH:$HOME\/bin/PATH=$PATH:$HOME\/bin:\/usr\/lib64\/qt5\/bin/' .bash_profile
source .bash_profile
pip install dryscrape

Et j’ai tout de suite voulu tester un bout de code sans trop chercher à comprendre.

cat << EOF > test.py
import dryscrape
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
response = session.body()
print response
EOF

… je me suis donc pris un bon gros Traceback :

Traceback (most recent call last):
File "test.py", line 3, in <module>;
session = dryscrape.Session()
[...]raise NoX11Error("Could not connect to X server. "
webkit_server.NoX11Error: Could not connect to X server. Try calling dryscrape.start_xvfb() before creating a session.

Ahhhhh oui… ça !

xvfb_ (necessary only if no other X server is available)

En fait il suffit d’ajouter un test pour exécuter dans xvfb si nécessaire.

Un premier exemple

Le bout de code suivant ne fait que récupérer le code source de la page et l’afficher à l’écran.

cat << EOF > simple_scraper.py
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
import dryscrape
if 'linux' in sys.platform:
# start xvfb in case no X is running. Make sure xvfb
# is installed, otherwise this won't work!
dryscrape.start_xvfb()
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
response = session.body()
print response
EOF

Mais la grosse différence avec le cURL précédent, c’est que dans le cas présent, ici le Javascript est interprété. Cette fois ci dans le code source retourné, je retrouve bien mon calendrier

A partir de là, il ne me reste donc en théorie qu’à terminer d’écrire un petit bout de script pour extraire les informations qui m’intéressent et à me notifier quand des places sont libres ! On progresse !

Méthode 3 : Scraper comme jamais

Ce montage pourri d’un clip de Maître Gimms avec des logos dans la main vous est offert par Zwindler

Mais je n’étais pas encore satisfait. Mon but est d’être prévenu lorsque des places sont disponibles. Or, les places s’ouvrent le 1er du mois, pour le mois suivant. En revanche, le composant Javascript datepicker a la mauvaise idée de donner les disponibilités pour le mois en cours. Mon script simple_scraper.py ne récupère donc pas les bonnes dates…

Pour contourner le problème, il faut aller encore un peu plus loin dans l’automatisation des actions. Il faut simuler le clic de l’utilisateur sur la flèche vers la droite, qui passe au mois suivant.

C’est possible avec dryscrape, qui propose notamment une fonction pour sélectionner des nodes XPATH et interagir avec. Pour ceux qui ne connaissent pas XPATH, vous pouvez aller sur la doc de dryscrape qui donne quelques exemples, et aussi sur le tutoriel de la W3School.

Comme j’ai examiné le code HTML retourné par le datepicker, je sais quoi chercher :

Pour changer de mois en cours, dans un premier temps j’ai essayé d’utiliser le label « » » mais le module dryscrape ne supporte pas les caractères non ASCII ! Une solution qui fonctionne est de cliquer sur le lien qui contient javascript:void(0) contenu dans le div de classe datepick-next :

cat << EOF > datepick_scraper.py
#!/usr/bin/python
# -*- coding: iso-8859-15 -*-
import sys
import dryscrape
if 'linux' in sys.platform:
# start xvfb in case no X is running. Make sure xvfb
# is installed, otherwise this won't work!
dryscrape.start_xvfb()
session = dryscrape.Session()
session.visit('http://@IP_ou_FQDN/le_chemin_de_la_page/')
datepicknext = session.at_xpath('//*[@class="datepick-next"]/a')
datepicknext.click()
response = session.body()
print response
EOF

Après vérification, cette version du script renvoie bien le tableau avec les date de Juin (quand on est en Mai) !

Le mot de la fin

A partir du moment où vous en êtes là, il n’y a plus vraiment de limites à ce que vous êtes capable de faire. Dans mon exemple, j’aurai pu aller encore plus loin, extraire les dates disponibles, et même pourquoi pas aller jusqu’à remplir automatiquement le formulaire pour réserver automatiquement une date prédéfinie (voire même toutes les dates disponibles).

Ce n’est pas mon but : je vais me contenter de m’envoyer un email dès qu’une date se libère. Mais c’est possible !

Si vous voulez explorer les possibilité de dryscrape, la documentation officielle donne quelques exemples, et notamment celui de l’envoi d’un email depuis Gmail, entièrement automatisé comme si c’était un humain (!)

De quoi donner des idées, pour scraper comme jamais !

Hack on Zwindler's Reflection

Transformer Proxmox VE en node Kubernetes avec LXC et lxcri

Il ne savait pas que c’était complètement stupide, alors il l’a fait

On s’y prend comment ?

C’est parti

Ya pas de release

Prérequis pour builder lxcri

Builder comme jamais

On reprend crio

Fast forward

Conclusion

QNAP débranche LXC sur les NAS ARM : comment contourner ?

Nuance

En avoir le coeur net

“Faites mieux”

Hack…

… and slash!

GPG

Des dossiers qui disparaissent tout seul ???

Conclusion

Sources

Retrouvez-moi à Devoxx France 2022

J’ai 10 ans 🎶

Comment on fait pour venir ?

Le pitch de mon talk

Android Auto sur R-LINK 1 - Chérie, j'ai briqué la voiture...

Chérie, j’ai briqué la voiture

Android Auto à la rescousse

Qu’à cela ne tienne

MyRenault ou les limbes d’un logiciel à l’abandon

Matériel

Installer DDT4ALL

Trouver une base DDT2000

Brancher la sonde

Lancer le logiciel DDT4ALL

Sites utiles

Open Source Experience 2021 – Récap’ du premier jour

Première conférence en présentiel de 2021 !

API != REST – procmail à la rescousse

Ciel mon Kubernetes mine des bitcoins

Construction d’images de containers à l’aide de Kaniko

Construire un outil de CLI userfriendly

Infrastructure As Code : quelles tendances ? De l’automatisation à l’orchestration multicloud !

Exposants, visiteurs et village associatif

[OSXP 2021] Ciel ! Mon Kubernetes mine des bitcoins

Open Source Experience, le successeur du Paris Open Source Summit

Le pitch

Slides

Hacker un calendrier javascript (datepicker) avec un scraper python

Mais quel rapport entre un datepicker javascript et un scraper python ?

Commençons donc par un peu de storytelling

Méthode 1 : F5

Méthode 2 : cURL

Méthode 2bis : aller plus loin avec cURL

Méthode 3 : Un scraper ?

Un premier exemple

Méthode 3 : Scraper comme jamais

Le mot de la fin

Infrastructure As Code : quelles tendances ? De l’automatisation à l’orchestration multicloud !