Pourquoi un runner CI pour un usage personnel ? J'ai quelques scripts et outils maison et je publie sur Gitea les images Docker de ces outils depuis ma machine de développement avec un simple Makefile. Avoir une petite CI permet de faire une publication plus officielle en se basant sur les tags de version Git.

Gitea s'exécute dans un container Docker d'une VM Debian de Proxmox. J'aurais pu installer le runner sur la même VM mais j'ai préféré ne pas pénaliser les autres services de la VM et installer le runner dans un container séparé... container et non pas machine virtuelle car je voulais du léger — les ressources du MiniPC ne sont pas inépuisables — donc j'ai opté pour le container LXC Docker via les Proxmox VE community scripts, le projet communautaire qui a pris la suite des fameux scripts de tteck.

Une seule commande à coller dans le shell Proxmox :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/docker.sh)"

Le script pose quelques questions en mode interactif, crée le container LXC, installe Docker et configure les services. C'est bluffant de rapidité. J'ai alloué 2 cœurs et 2 Go de RAM — je peux ajuster plus tard en fonction des besoins réels, Proxmox rend ça trivial.

Toutefois, faire tourner Docker dans un container LXC n'est pas la configuration recommandée par Proxmox, qui préconise une VM dédiée pour ça. Le script rend cela possible en créant un container privilégié. Pour un runner CI perso derrière le pare-feu Proxmox, le compromis me convient.

Une fois le container démarré, on récupère le binaire de l'act_runner depuis les releases officielles de Gitea et on l'enregistre auprès de son instance.

Côté Gitea, il faut d'abord générer un token. Ça se passe dans l'interface d'administration : Administration du site → Actions → Exécuteurs. On copie le token proposé et on retourne dans le container.

L'enregistrement est interactif :

cd /srv/gitea-runner
./act_runner register

Le programme demande l'URL de l'instance, le token, un nom pour le runner et des labels. J'ai gardé les labels par défaut (ubuntu-latest, ubuntu-22.04, ubuntu-20.04) qui couvrent la majorité des workflows qu'on croise dans la nature. À la fin, un fichier .runner est généré dans le répertoire courant — il contient les credentials du runner.

On génère ensuite le fichier de configuration :

./act_runner generate-config > config.yaml

j'ai gardé le fichier généré tel quel.

Il ne reste plus qu'à écrire un service systemd qui démarre notre runner avec la commande :

/srv/gitea-runner/act_runner daemon

Le runner apparaît alors dans l'interface Gitea avec le statut Inactif.

Un petit test de workflow m'a permis de valider que tout fonctionne : le job s'affiche en vert dans l'onglet Actions du dépôt. Le runner a bien chopé le job, Docker a tiré l'image ubuntu-latest et le job a tourné dans son container éphémère. Ca implique évidemment que le container LXC a un accès sortant à internet pour tirer les actions et les images. La première exécution du job est un peu lente car les images Docker ne sont pas encore mises en cache localement.

Ca s'installe assez rapidement sans tatônnements, la documentation de Gitea est suffisante. Dans mon cas, le plus long a été de décider la cible de déploiement du runner et d'appliquer mes règles de pare-feu. Le runner dort sagement en attendant un push, il consomme peu, c'est exactement ce que je cherchais.

Dans Tmux, nous manipulons plusieurs concepts :

• la session qu'on peut voir comme l'espace projet,
• la fenêtre qu'on peut assimiler à un onglet ; dans une session on ajoute de multiples fenêtres,
• le volet (ou "pane" en langue de Shakespeare) qui est la subdivision d'une fenêtre : verticalement ou horizontalement, redimensionnable à volonté.

Typiquement une session nommée "0" avec 3 fenêtres "vim", "zsh" et "cmus" ressemblera à ceci :

(Source: Wikipedia)

Est-il encore pertinent d'investir du temps dans l'apprentissage de Tmux ? Je le crois car le terminal reste une pierre angulaire du développement logiciel et de l'administration système. Même si les IDE sont pertinents, il y a des tâches ou la ligne de commande reste aussi performante et/ou plus rapide. Paradoxalement et ce n'est probablement pas une opinion populaire, les outils IA comme Claude Code sont plus puissants depuis la ligne de commande car ils travaillent à ce niveau : édition de fichier, installation de dépendances, compilation, lancement des tests, gestion de Git... les outils CLI sont aisés à manipuler pour un agent. Et si le Vibe Coding devait se généraliser, les IDE ont du souci à se faire.

Tmux est complexe si on tente d'appréhender sa configuration avancée d'entrée de jeu. Mais son apprentissage peut-être progressif et au fur et à mesure qu'on le maîtrise, on enrichit sa configuration pour être plus efficace dans les tâches fréquemment exécutées. Et l'apprentissage ne s'arrête jamais, le projet est mâture mais toujours actif et la communauté innove régulièrement en publiant de nouveaux plugins.

J'ai maîtrisé rapidement la gestion des fenêtres et des volets mais cela a été plus long pour les sessions. Pas que ce soit plus complexe mais je ne voyais pas le potentiel que je pouvais en tirer. Puis j'ai eu une période tmuxp qui permet de décrire des sessions prédéfinies dans un fichier de configuration et les charger au fil des besoins. Je décrivais donc les espaces projets du moment et j'utilisais la session par défaut pour le reste en ajoutant ou retirant des fenêtres. C'était pas mal mais j'effectuais finalement l'essentiel du travail dans la session par défaut avec beaucoup de fenêtres. Avec le recul, je pense que c'est par manque de dynamisme dans ma gestion des sessions et c'est en découvrant Sesh que j'ai véritablement exploité les sessions Tmux.

Bon alors Sesh c'est quoi ? Ironiquement si je m'étais arrêté à ma première impression j'aurais passé mon chemin car il présente des points négatifs :

• ce n'est pas un plugin Tmux mais un binaire externe écrit en Golang qui pilote Tmux,
• il a une dépendance à un autre binaire appelé Zoxide qui est un accélérateur de changedir car il mémorise les répertoires rencontrés,
• son créateur John Medeski a préféré des vidéos Youtube à une documentation.

Selon moi, l'idée génial de Sesh c'est d'apporter le dynamisme aux sessions : mixer des sessions prédéfinies et les derniers répertoires rencontrés et les présenter dans une interface unifiée :

• sélectionner une session prédéfinie instancie la session et ses fenêtres et des commandes peuvent être lancées automatiquement,
• sélectionner un répertoire crée une nouvelle session à la volée avec une fenêtre ouverte dans ce répertoire. Bien sûr on va rajouter des fenêtres nécessaires en lien avec ce projet

Le nombre de fenêtres lancé est globalement le même par rapport à mon précédent fonctionnement sans Sesh. Ce qui change c'est que je bascule essentiellement entre des sessions plutôt qu'entre des fenêtres et ces sessions sont nommées clairement, c'est facile de s'y retrouver.

Bref je n'ai pas fini d'améliorer ma configuration Tmux, accessible ici pour les intéressés.

Ce qui est passionnant avec l'auto-hébergement c'est qu'il n'y a pas qu'une façon de faire les choses. A chacun de bâtir la solution qui lui convient : containers ou machines virtuelles, GNU/Linux ou BSD, de la sécuriser et de sélectionner les services indispensables pour ses usages. Moi j'ai fait le choix de l'hyperviseur Proxmox qui fait tourner un mix de machines virtuelles (exécutant des docker compose) et de containers LXC. Le pare-feu de Proxmox me permet d'isoler la partie auto-hébergée du reste du réseau et de contrôler les communications pour protéger le réseau d'un serveur qui serait compromis et inversement la partie auto-hébergée d'un parasite qui aurait eu accès à mon WiFi. Je ne vais pas revenir sur les services hébergés j'en parle assez régulièrement :-)

Je ne me suis pas relancé à héberger mes e-mails, c'est devenu trop compliqué de faire accepter ses messages aux GAFAM, de traverser les filtres anti spams... J'ai pris le parti d'héberger mes e-mails chez un fournisseur de confiance en l'occurrence Ecomail. Bien évidemment je ne suis pas à l'abri d'un piratage de mes boites e-mail donc j'ai essayé de mitiger le risque. Ecomail encourage à supprimer ses e-mails pour limiter l'impact environnemental et ça me convient car je fonctionne ainsi depuis longtemps, probablement traumatisé par le GTD : je traite, je supprime et je vide la corbeille régulièrement... bon parfois un peu agressivement ce qui m'a fait perdre des remboursements de mutuelle par exemple ;-) Pour parer à ma manie du nettoyage j'ai installé une instance de Bichon qui archive ma boite de réception et mes envois ; il me sert de tampon pour conserver mes e-mails un peu plus longtemps et les supprimer au plus vite du serveur public. Et j'ai repris en main l'hébergement de mes contacts et de mes calendriers sur une instance Radicale. Ce n'est pas parfait mais j'ai réduit les données exposées.

D'ailleurs j'ai arrêté d'exposer plusieurs services auto-hébergés au cours de l'année comme par exemple mon instance Gitea. Elle réplique mes projets publics hébergés chez Zaclys et pour les projets privés j'ai adopté des solutions parfois moins confortables privilégiant plus de sécurité. Je synchronise mes notes privées depuis mon réseau et j'ai un accès en lecture sur mon téléphone avec l'application GitNote : j'ai espoir d'améliorer cela dans quelque temps. De même, mon instance de Radicale n'est accessible que localement. Pour la synchronisation des contacts et du calendrier sur le téléphone, j'utilise DAVx5 qui a une option "synchroniser par WiFi" ; je n'ai aucune perte de confort, les modifications de la journée se synchronisent le soir en rentrant à la maison.

J'ai été tenté par des accès tunnels avec des solutions comme Tailscale (ou Headscale) mais vu la conjoncture, je préfère sacrifier un peu de confort en imposant l'administration depuis mon réseau local, la meilleure sécurité est de réduire la surface d'attaque. Pour les parties exposées publiquement comme mon instance Seafile ou Immich, je vais essayer d'améliorer encore la sécurité cette année.

Bonne année 2026

Techniquement, Seafile et Immich sont exécutés par Docker : Seafile expose 100Go de photos via un partage fuse sur l'hôte et ce répertoire est monté en volume dans le container Immich.

Immich propose une vue chronologique, une recherche par géolocalisation, une recherche par personne et un recherche par contexte. La géolocalisation se base sur les données EXIF de la photo et les deux autres sur des LLM d'analyse qui tournent localement sur le serveur. La recherche par personne est redoutable : je ne l'ai pas pris en défaut avec des photos étalées sur une cinquantaine d'années.

Mais il me manquait une fonction que j'ai eu du mal à trouver : les étiquettes (ou tags). je voulais étiqueter mon répertoire "travaux" d'année en année et avoir un point d'entrée pour le parcourir, les noms de mes dossiers d'origine étant bien sûr ignorés par Immich. Après avoir traîné sur la doc officielle et les forums j'ai trouvé la méthode : Immich crée les tags automatiquement avec ce qu'il trouve dans les données EXIF des photos analysées. A vrai dire je ne savais pas qu'EXIF pouvait stocker cette information mais une propriété "keywords" existe pour cela. Vous noterez le "s" à keyword, on peut même associer plusieurs tags à une photo.

Après avoir installé exiftool disponible dans toutes les bonnes distributions j'ai pu modifier mes photos :

# Afficher les étiquettes
exiftool -Keywords

# Supprimer les étiquettes
exiftool -Keywords=

# ajout d'une étiquette "Travaux"
exiftool -Keywords=Travaux *.jpg

Propriétés du fichier :

Et le lendemain après analyse par Immich mon étiquette est présente :

J’ai été satisfait du téléphone pendant trois ans, excepté quelques agacements récents suite au remplacement de l’assistant (désactivé de longue date) par Gemini qui a initié un jeu du chat et de la souris avec des réglages réinitialisés régulièrement par les mises à jour. Puis une conjonction de deux évènements ont déclenché le remplacement de la version Stock d’Android par GrapheneOS, une version durcie d’un point de vue sécurité et vie privée maintenue par une communauté très activée et financé par des sponsors individuels et des sociétés :

1. mon appareil est concerné par un problème de batterie défectueuse : Google m’a indemnisé de 100$ pour ce défaut
2. un proche m’a posé des questions sur la dégooglisation des téléphones et nous avons discuté de la difficulté technique et des prérequis, idéalement peu d’adhérence aux services Google. Du coup j’ai continué cette réflexion pour mon propre cas en me demandant quelle était mon adhérence et si je pouvais aller plus loin.

J’ai identifié les applications GPS : même si j’utilise CoMaps essentiellement en vacances pour ses capacités hors ligne, j’utilise aussi beaucoup Maps et Waze pour l’info trafic sur la région marseillaise. On m’a conseillé Magic Earth en complément de CoMaps et si l’info trafic est forcément moins précise j’adore la clarté de sa navigation ; ça ressemble plus aux GPS dédiés de l’époque genre TomTom et moins à un jeu vidéo (on prend quoi ce mois-ci : un avatar de combi Volkswagen et les voix rigolotes de South Park ?). Je crois que je peux vivre sans une info trafic collaborative un peu trop temps réel qui pousse parfois à des décisions sur le vif qu’on regrette d’ailleurs en changeant d’itinéraire sans raison, ça me fera le plus grand bien. L’autre application nécessitant un compte est Youtube Music, un abonnement familial que je souhaite conserver encore quelques temps.

Les alternatives à la version Stock Android sur Pixel sont multiples : de la mama Lineage avec ou sans Gapps dont dérivent beaucoup de ROM custom et GrapheneOS qui sort du lot car :

• sa priorité est la sécurité et la confidentialité,
• elle ne supporte que la gamme Pixel aujourd’hui, à priori, car ils ont une connaissance experte de ces modèles
• son support optionnel des Play Services n’est pas une couche de compatibilité mais une version officielle en mode "bac à sable" : l’application Play Store n’est pas partie intégrante du système mais une application comme les autres
• l’accès au PlayStore permet d’installer le module photo pour les Pixel et donc de conserver la qualité des photos produites par l’appareil

Selon la page Wikipedia, la fonction de sécurité introduit un accès réseau révocable et des paramètres d’autorisation des capteurs pour chaque application installée. Il introduit également une option de brouillage du code PIN pour l’écran de verrouillage. Une randomisation des adresses MAC Wi-Fi par connexion (à un réseau Wi-Fi) est introduite par défaut. Anecdote amusante je recevais une notification "nouvel appareil connecté au réseau" à chaque fois que je revenais à la maison à cause de cette randomisation des adresses MAC.

Étonnamment la méthode d’installation recommandée par GrapheneOS passe par un navigateur Web (privilégiez Chrome exceptionnellement) au lieu de manipulation en lignes de commandes avec ADB. Au préalable il faut déverrouiller le bootloader (et le verrouiller après l’installation) ; c’est une manipulation aisée et documentée par Google. Avec Xiaomi c’est mon second constructeur préféré pour cette partie qui peut-être risquée avec certains constructeurs qui ne supportent pas les utilisateurs changeant de système.

Je suis très satisfait de GrapheneOS. Les mises à jour du système sont poussées automatiquement et il suffit de redémarrer le téléphone pour les appliquer. J’ai reçu déjà trois mises à jour en quatre semaines. F-Droid reste mon magasin d’application privilégié ; j’aurais pu éviter le PlayStore et passer par Aurora, mais je ne suis pas très serein avec cette méthode. Et évidemment aucun assistant Google n’est installé et probablement installable sur ce système.

Et puis depuis quelques mois j’ai commencé un chantier qui s’apparente à un mix entre minimalisme et réduction des coûts : j’ai rapatrié le cloud de kDrive et tous mes petits services d’un VPS vers un mini-pc hébergé à la maison. Cela fait 6 mois et avec le recul (Trumpisme, augmentation des coûts des hébergeurs, incertitude de la régulation suisse) j’ai bien fait d’enlever mes billes d’Infomaniak et de reprendre la main sur mes données. J’ai aussi fermé quantité de comptes sur des sites (la plupart US) dont je pouvais me passer et migré mes projets GitHub (coucou Zaclys).

Le dernier clou fut les e-mails migrés d’Infomaniak vers Ecomail en toute transparence car rattachés à mon nom de domaine. Là on n’est pas sur une réduction de coût, car la boite e-mail était offerte avec le nom de domaine mais sur une volonté d’en faire un peu plus pour la planète puisque Ecomail finance des actions avec une partie de son chiffre d’affaires. Ma volonté s’est bornée à effectuer un petit paiement ! Ce sont Clio et Nathan qui font le boulot et je pense qu’ils méritent d’être plus connus.

Tout ça pour en revenir à mon laptop et ma volonté de prolonger ce mouvement et d’agrandir ma surface de cohérence (et j’ai une grosse marge de progression). J’ai installé une Debian testing très vite renommée Trixie, quand j’ai validé qu’elle avait tout ce qu’il me fallait, afin de rester sur une version stable les deux ou trois prochaines années. Je n’ai jamais perdu Debian de vue et j’en installe souvent sur mes serveurs mais cela faisait très longtemps que je n’avais pas revu la version bureau. J’ai choisi Mate Desktop (nostalgie quand tu nous tiens) et un thème d’inspiration MacOs bien léché.

Que dire ? je l’adore et je me suis fixé des règles :

• je limite les dépôts tiers ; là j’ai Sublime et Signal.
• les Flatpak / AppImage sont proscrits.

Je commence même à apprécier Synaptic et son côté rétro… Sûrement l’indigestion de ces boutiques d’applications bourrées de publicité et de notation.

Je me suis demandé s'il y avait une alternative à Nginx Proxy Manager et je suis tombé sur Zoraxy : un outil tout-en-un qui fait office de reverse-proxy dynamique avec un tableau de bord d'analyse du trafic. Tout-en-un techniquement aussi car c'est une application écrite en Golang donc un binaire unique. En plus de la fonction de proxy HTTP et de la gestion des certificat, des fonctions additionnelles très sympathiques sont proposées via l'interface Web :

• le support des proxy TCP / UDP (nommés Stream Proxy)
• une surveillance de la disponibilité des services backends (uptime monitor)
• une configuration des pages 404 et un hébergement de pages statiques. je n'ai pas expérimenté mais on doit pouvoir créer une page d'erreur personnalisée quand un service backend est par terre.
• un tableau de bord assez complet qui permet de réagir et de contrôler les accès en bloquant des IP ou des pays

Devant l'engouement pour son projet le créateur de Zoraxy a recadré les utilisateurs en insistant sur le fait que Zoraxy ne pouvait pas avoir la robustesse et les performances d'un NginX et qu'il fallait le réserver à des usages plus limités. En cela il se positionne comme "The ultimate homelab networking toolbox for self-hosted services" et non pas comme un remplacement du reverse-proxy NginX pour des sites à gros volumes. Cela colle parfaitement à mon usage.

Après migration, il me reste quatre projets actifs (hé oui il ne reste que ça) à savoir mes configurations (dotfiles), le déploiement par docker compose (selfhosting), le gestionnaire de commentaires (stacosys) et le blog. Vous avez noté la subtilité pour être retrouvé sur la forge de Zaclys sans donner explicitement le lien de mon espace dans l'article ;-)

Sur mon infrastructure domestique (le mini-pc Beelink propulsé par l'hyperviseur Proxmox) j'ai déjà une instance Gitea qui réplique mes projets à l'extérieur, ça me garantit d'avoir une copie à jour en cas de gros pépin. Bref après avoir migré mes projets je me suis trouvé devant la problématique de construire et publier les images Docker de stacosys et du blog puisque cette tâche était dévolue aux actions GitHub. Je ne sais pas si la forge Zaclys propose un équivalent mais je trouve inefficace de publier ailleurs des images prêtes à l'emploi qui ne servent qu'à moi, pour ensuite les rapatrier en local. En plus dans la foulée de GitHub j'avais bien apprécié de supprimer mon compte Docker Hub enfin désactiver car la suppression ne semble pas possible :-(

En cherchant une alternative pour construire mes images localement et les transférer vers mon infra, j'ai pensé à Gitea qui a aussi la fonction de "docker registry" appelée packages. Je suis donc parti là dessus, une publication à la demande, pas de CI ; vu le peu d'activité des projets ça fait parfaitement l'affaire.

C'est quand on paye de sa poche qu'on prend conscience de la valeur des choses

Après avoir mis ça en place... un changement d'URL dans 2 projets j'ai trouvé assez long la publication de l'image du blog dans Gitea alors que tout est sur le LAN. Et pour cause, elle faisait 1,2 Go alors que celle de stacosys tient dans 74 Mo. Évidemment, en tout automatisé dans une CI ça ne m'avait pas alerté auparavant. Me voilà donc à m'intéresser à un génial outil d'analyse d'images Dive qu'on peut même exécuter en container,

alias dive="docker run -ti --rm  -v /var/run/docker.sock:/var/run/docker.sock docker.io/wagoodman/dive"

à lire un peu de littérature sur les build multi-stages et à analyser où ça pêche... Bon, ça pêche à plusieurs endroits : trop de couches, installation d'outils de développement pour construire les locales MUSL de la distribution Alpine alors que sur les versions récentes elles sont proposés dans les dépôts. Après une phase d'optimisation j'ai pu ramener l'image à 128 Mo, honnête à mon sens pour un container avec Nginx, Python et des traitements Bash qui font du "git clone".

Depuis tant d'années nous baignons dans ce monde du partage communautaire et multiculturel autour de Linux, des projets libres et opensource. Alors est-ce qu'on fait de la politique ? Pas forcément consciemment mais nous essayons de vivre en accord avec nos valeur et nos goûts reflètent une vision du monde (pas tel qu'il est malheureusement mais plutôt comme nous le rêvons). Le durcissement des gouvernements au détriment de l'humain (en piétinant d'abord les minorités) et de la nature, le repli en mode écureuil (tiens si je prends le Groenland je pourrais assurer le même train de vie pendant encore quelques dizaines d'année et faire croire que tout va bien ?) nous expose peu à peu. Si on n'est pas d'accord avec cela car nous avons d'autres valeurs plus humanistes alors je crains que nous ayons une posture politique à l'insu de nous-mêmes même :-) Le fait qu'on ait jamais voté ou qu'on soit fidèle aux urnes ne change rien à l'affaire : il y a une majorité silencieuse qui n'approuve pas, ne défile pas, du moins j'aime à le croire. Quelle est la limite qui fait basculer de l'indignation à l'action, je me pose la question... à moi-même en premier lieu.

L'année va être intéressante mais pas forcément joyeuse. Prenez soin de vous, mentalement aussi, car la période est malsaine.

A ma grande satisfaction j'ai mis en place GoAccess en moins de deux heures avec deux étapes :

1. l'installation sur le container LXC Alpine. GoAccess est écrit en langage C et a peu de dépendances pour la compilation. Avec deux ou trois dépendances de librairies ajoutées, la compilation sur le container a été simple.
2. le travail principal consiste à décrire le format du log à analyser dans le formalisme de GoAccess

Nginx Proxy Manager utilise un format de log commun pour tous les proxy ce qui m'a simplifié la tâche. La documentation de GoAccess est exemplaire, notamment le formalisme des logs (https://goaccess.io/man#custom-log).

Pour ce format de log Nginx :

log_format proxy '[$time_local] $upstream_cache_status $upstream_status $status - $request_method $scheme $host "$request_uri" [Client $remote_addr] [Length $body_bytes_sent] [Gzip $gzip_ratio] [Sent-to $server] "$http_user_agent" "$http_referer"';

j'ai défini ces paramètres de lancement :

--datetime-format='%d/%b/%Y:%H:%M:%S %z' 
--log-format='[%x] - %^ %s - %m %^ %v "%U" [Client %h] [Length %b] [Gzip %^] [Sent-to %^] "%u" "%R"'

GoAccess peut générer son rapport HTML à partir d'une liste de fichiers de logs à la demande ou en temps-réel avec un lancement en tâche de fond (option --real-time-html --daemonize). L'option temps-réel est sympa avec une web socket qui rafraîchit la page du navigateur automatiquement mais c'est consommateur en CPU sur ce type d'installation en mini-pc où l'un des objectifs est la sobriété énergétique. J'ai préféré opter pour une génération horaire par une tâche planifiée avec CRON.

GoAccess répond à mon besoin et j'ai commencé à analyser les données pour préparer une phase de renforcement de la sécurité.