MACVLAN on Ink'Hey

🖧 Réseau moderne sous linux: 2. Routeur avec networkd

Sat, 23 May 2026 19:01:12 +0200

Dans cet article, je vais présenter rapidement comment vous pouvez faire un routeur minimaliste avec systemd‑networkd et remplacer totalement ou partiellement votre box internet.

Nous partirons du principe d’une box avec 2 liens :

wan branché sur l’ONT ou une box en mode bridge.
lan connecté à votre réseau local.

Nous allons partir sur un approché minimaliste :

En IPv6 , adresse globale (GUA: préfix 2000::/3) et Lien-local (LLA: préfix fe80::/10) pour les machines côté lan.
pas de pare-feu pour le moment (on verra ça ensuite dans un autre sujet).
En IPv4 : un NAT tout simple qui converti les addresse locale vers l’internet (massquerade). Uniquement les connections sortante sont concernés.

Note : configurer un routeur et vérifier son bon fonctionnement n’est pas simple, Des commandes comme ip address, ip route, traceroute, curl ou encore le logiciel wireshark sont très utile pour vous aider à corriger votre configuration.

Côté Wan

Cela dépend vraiment du FAI

La partie la plus complexe est celle consistant à brancher votre routeur et à récupérer les ip (v4 et V6) depuis le fournisseur d’accès, la méthode varie d’un fournisseur d’accès à l’autre.

La méthode varie selon les fournisseurs d’accès :

Certain fournissent (ou vous donne accès si vous les contactez) à un boitier externe ONT qui converti le signal fibre en ethernet.
D’autre fournissent uniquement des box dont l’ONT est intégré et dans ce cas précis, il n’est pas possible de se débarrasser de la box, vous pouvez néanmoins la placer en mode bridge, ce qui vous permet de router avec votre machine.

Il peut être aussi possible de faire fonctionner un ONT différent sur le réseau, mais cela est un point délicat que je n’aborderais pas.

La récupération des IPs diffère, elle aussi entre les fournisseurs d’accès avec diverses mécaniques :

certain permettent de récupérer les IPs via du DHCP/DHCPv6 d’autre oblige à créer un lien PPPoE, enfin d’autres ne fournissent pas de méthode standard, il vous faudra donc assigner manuellement toute ou partie des IPs…
Selon les fournisseurs, il est parfois nécessaire de configurer des interfaces utilisant des VLAN, chez orange le DHCP passe par le VLAN 832, et chez bouygue le traffic internet est sur le vlan 100 Si vous êtes établis en france, le mieux est de chercher sur le forum lafibre pour trouver la configuration spécifique à votre FAI .

Note : j’omets volontairement la question de la téléphonie/télévision de l’équation. Il est effectivement possible de récupérer ces services dans certain cas.

Base Générique

Dans tous les cas vous allez vous retrouver avec un fichier .network pour l’interface wan :

# /etc/systemd/network/wan.network
[Match]
Name=wan

[Link]
RequiredForOnline=yes

# Si vous utilisez le DHCP (en tant que client, valable qu'avec certain FAI)
[Network]
DHCP=yes

Dans le cas où vous voulez router en ipv6, vous pouvez ajouter ceci:

# /etc/systemd/wan.network.d/ipv6.conf
[Network]
IPv6Forwarding=yes

# Pour récupèrer les ipv6 en DHCPv6 (valable qu'avec certains FAI)
LinkLocalAddressing=ipv6
DHCPPrefixDelegation=yes
IPv6AcceptRA=yes

et en ipv4:

# /etc/systemd/wan.network.d/ipv4.conf
[Network]
IPv4Forwarding=yes

Pour ipv6, il est nécessaire d’activer le forwarding de façon globale en plus :

# /etc/systemd/networkd.conf.d/router.conf
[Network]
IPv6Forwarding=yes
# Il n'est pas nécessaire de faire pareil en ipv4:
# IPv4Forwarding=yes

La raison est un comportement différent entre ipv6 et ipv4 dans le kernel. Il n’est pas super clair pour moi si cela est un bug ou pas, mais cela rend les choses pas super simple à comprendre.

DHCP/DHCPv6

Si vous utilisez du DHCP/DHCPv6, il est probable que la configuration varie beaucoup d’un fournisseur à l’autre, par exemple en cherchant sur le forum lafibre, on voit qu’une configuration dhcp pour orange ressemblerait plutôt à ça :

Note : pour orange une configuration supplémentaire pour utiliser une interface sur le VLAN 832 est nécessaire

# /etc/systemd/network/orange.network
[Match]
# orange is wan vlan 832
Name=orange

[DHCPv4]
ClientIdentifier=mac
VendorClassIdentifier=sagem
UserClass=FSVDSL_livebox.Internet.softathome.Livebox3
# A modifier avec des identifiants de connection
SendOption=90:string:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1a\x09\x00\x00\x05\x58\x01\x03\x41\x01\x0D\x66\x74\x69\x2F\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**
UseHostname=no
UseDNS=no
UseDomains=no

[DHCPv6]
WithoutRA=solicit
UserClass=FSVDSL_livebox.Internet.softathome.livebox4
# A modifier avec des identifiants de connection
SendOption=11:string:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1a\x09\x00\x00\x05\x58\x01\x03\x41\x01\x0D\x66\x74\x69\x2F\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**\x**
# A modifier avec des identifiants de connection
SendOption=16:string:\x00\x00\x04\x0e\x00\x05\x73\x61\x67\x65\x6d
UseDNS=no
UseNTP=no

[IPv6AcceptRA]
DHCPv6Client=always
UseDNS=no
UseDomains=no

Et une configuration dhcp pour sfr plutôt à ça:

# /etc/systemd/wan.network.d/sfr.conf
[Link]
# set this to your router mac address
MACAddress=00:00:5E:00:53:00 

[DHCPv4]
ClientIdentifier=mac
UseDNS=yes
UseGateway=yes
UseHostname=no
VendorClassIdentifier=neufbox_bypass

[DHCPv6]
DUIDType=link-layer-time
PrefixDelegationHint=::/56
RapidCommit=No
SendOption=16:string:\x00\x00\xa0\x0c\x00\x0e\x6e\x65\x75\x66\x62\x6f\x78\x5f\x62\x79\x70\x61\x73\x73
UseDelegatedPrefix=Yes
WithoutRA=solicit
UseHostname=No

Bref, cette partie est un peu complexe et très variable d’un fournisseur à l’autre et l’on trouve des tonnes de discussion sur le sujet qu’il peut être fastidieux de lire. Je vous conseille selon votre fournisseur d’expérimenter et si possible de partager (sauf les secrets bien sûr) votre configuration fonctionnelle pour permettre à d’autre de s’éviter ces recherches fastidieuses.

Côté LAN

La partie Lan est beaucoup plus simple à configurer dans le sens ou elle ne dépend pas de fournisseur d’accès. Tout d’abord, nous allons activer mdns (relire la partie 1 pour la configuration systemd-resolved):

# /etc/systemd/network/lan.network
[Match]
Name=lan

[Network]
MulticastDNS=yes

IPv6

En IPv6, c’est relativement facile, il faut déléguer un prefix de sous réseau /64 pour l’interface lan:

# /etc/systemd/lan.network.d/ipv6.conf
[Network]
IPv6SendRA=yes
DHCPPrefixDelegation=yes
IPv6Forwarding=yes

[IPv6SendRA]
# Vous pouvez définir ici explicitement le dns à partager:
DNS=2a13:1001::86:54:11:100

[DHCPPrefixDelegation]
UplinkInterface=wan
SubnetId=0x1
Announce=yes

IPv4

En IPv4 c’est moins cool. Il faut passer du nat et faire du DHCP (en tant que serveur) :

# /etc/systemd/lan.network.d/ipv4.conf
[Network]
Address=192.168.1.1/24
DHCPServer=yes
# note: you may want to do masquerade by you firewall rule instead
IPMasquerade=yes
IPv4Forwarding=yes

[DHCPServer]
PoolOffset=0
PoolSize=100
EmitDNS=yes
# Vous pouvez définir ici explicitement le dns à partager:
DNS=86.54.11.100

Conclusion

Avec cette configuration, vous devriez avoir un accès internet fonctionnel dans tout votre réseau et la possibilité de communiquer en dualstack (ipv6 et ipv4).

Néanmoins cette configuration à des défauts :

Pas de pare-feu, les machine (en ipv6 au moins) peuvent donc être accessible depuis l’extérieur, ce qui n’est pas recommandé.
La configuration n’est pas conçu pour rendre un serveur accessible depuis l’extérieur en ipv4 (pas de port-forwarding).
Pas d’ipv6-mostly : la configuration actuelle est purement en mode double-stack. Il est possible de forcer les chose pour utiliser au maximum ipv6.

J’étudierai donc ces sujets ainsi que l’installation d’un vpn wireguard dans les prochains articles…

🖧 Réseau moderne sous linux: 1.Quelques astuces avec networkd

Sun, 17 May 2026 00:18:09 +0200

Dans cette nouvelle série d’articles, je vais parler de configuration réseau sous linux avec des outils modernes Gnu/Linux.

Dans ces premiers partis, je vais simplement présenter des astuces de configuration networkd, que j’ai découvert en passant beaucoup de temps dans la documentation, et parfois à l’aide de quelques articles de blog ou autre.

Personnellement, j’aime beaucoup networkd même si je trouve la documentation un peu difficile d’accès, l’internet ne contient pas assez d’exemple et d’article de blog à mon goût permettant de facilement trouver la solution à son problème, il faut donc parfois passer un temps non négligeable à creuser la documentation.

1.Activer Mdns

Pour accéder localement facilement aux machines via les adresse en nomdemachine.local, il est utile d’avoir mdns d’activé , pour cela si vous utilisez systemd-networkd, vous aurez besoin d’installer systemd-resolved et de vérifier qu’il est actif.

sudo apt install systemd-resolved
resolvectl

Si vous constater que mdns est désactivé sur votre interface (avec un résultat de commande contenant‑mDNS), il faut ajuster la configuration globale de resolved et/ou ajuster la configuration de l’interface:

Pour la configuration globale, vous devez créer un fichier :

# /etc/systemd/resolved.conf.d/99-enable-mdns.conf
[Resolve]
MulticastDNS=yes
# protocole similair à MDNS mais qui semble de moins en moins en usage
LLMNR=no

Pour la configuration spécifique de l’interface, il vous faudra dans le fichier .network :

# /etc/systemd/network/moninterface.network
...
[Network]
# Activer mdns (les addresse en .local)
MulticastDNS=yes

Note: ce dernier élément est un exemple, pas un vrai fichier .network fonctionnel, vous aurez besoin d’une directive [Match]

2.Renommer une interface

Dans un cas simple où vous avez une interface ethernet non usb, il est aisé de renommer son interface via un fichier .link :

# /etc/systemd/network/lan0.link
[Match]
MACAddress=00-00-5E-00-53-01

[Link]
# le nouveau nom
Name=lan0

comme vu précédemment le cas de périphérique USB est plus compliqué, certaines cartes change d’addresses mac à chaque connection tandis que certain conservent leur addresses mac.

La configuration des distributions peut changer les choses aussi. Ainsi, sous Debian Trixie, il peut être nécessaire de surcharger 73-usb-net-by-mac.link , pour éviter que le système renomme nos interfaces USB et ainsi nous permettre nous même de les modifier.

3. Switch Virtuel et virtualisation des interfaces

Il peut se trouver que les interface physiques ne correspondent pas exactement au réseau que vous voudriez obtenir :

Vous voulez utiliser plusieurs ports ethernet de votre système comme switch réseau.
Vous voulez des interfaces réseau virtuelles séparées, par exemple pour des conteneurs.

Ces ajustements sont possible via systemd-networkd.

Prénons un cas d’usage où l’on veut véritablement séparer les interfaces réseau utiliser des interfaces physiques réelles :

Nous avons 4 interface réelle de lan0 à lan3.
Nous voulons les regrouper dans un switch virtuel que nous nommeront vslan pour virtual switch lan.
Nous voulons 2 interfaces virtuelles pour, vslan1 pour l’hôte et vslan2 pour une machine virtuelle.

Le switch virtuel

Il suffit de créer une interface pont :

# /etc/systemd/network/vslan.netdev
[NetDev]
Name=vslan
Kind=bridge

On attache un par un les ports lan à ce pont, par exemple pour lan0 :

# /etc/systemd/network/lan0.network
[Match]
Name=lan0

[Network]
Bridge=vslan

Il faut répéter cette étape pour les autres ou utiliser un pattern par exemple : Name=lan*.

À partir de cette étape, si vous redémarrez networkd ou toute la machine, vous avez bel et bien un switch virtuel.

MacVlan : plusieurs interfaces virtuelles réseau de niveau 2

Pour avoir plusieurs addresses sur la machine, au niveau 2, c’est-à-dire que chaque machine aura une interface avec une adresse mac dédié et sera donc virtuellement totalement séparées, on utilise une fonctionnalité appelée MACVLAN.

Une limitation de ce mécanisme sous 🐧 Linux est que l’interface parente ne peut pas communiquer avec l’interface enfant, ainsi si j’avais une interface eth0 que je séparerais par MACVLAN en virt10@eth0 et virt2@eth0 et que j’attribuerais des addresses à ces 3 interfaces, eth0 ne pourrait communiquer avec virt10@eth0 et virt10@eth1 et inversement.

L’astuce pour contourner le problème dans notre cas, est simplement :

de ne pas attribuer d’adresse à notre pont, ainsi le pont ne sera pas utiliser directement pour la communication réseau.
ajouter un macvlan spécifique pour l’hôte (vslan1 dans le cas présent).

On configure ce pont pour fournir des macvlan pour nos adresses virtuelles :

# /etc/systemd/network/vslan.network
[Match]
Name=vslan

[Network]
MACVLAN=vslan1
MACVLAN=vslan2
ConfigureWithoutCarrier=yes

# désactiver la récupèration/génération d'addresse en ipv6 et ipv4
IPv6AcceptRA=no
LinkLocalAddressing=no
DHCP=no

Il nous manque plus que les interfaces virtuelles MACLAN, ça se fait à l’aide de 2 fichiers. Par exemple pour vslan1, on définit notre macvlan :

# /etc/systemd/network/vslan1.netdev
[NetDev]
Name=vslan1
Kind=macvlan

[MACVLAN]
Mode=bridge

On peut ensuite configurer l’interface vslan1:

# /etc/systemd/network/vslan1.network
[Match]
Name=vslan1

[Network]
# Activer mdns (les addresse en .local)
MulticastDNS=yes

# Activer la récupèration d'ip via le dhcp utile pour ipv4
DHCP=yes

# La récupèration d'addresse ipv6 est ici implicite (valeur par défaut), mais il est possible d'être explicite:
# IPv6AcceptRA=yes
# LinkLocalAddressing=yes

# il est possible d'assigner si besoin manuellement une addresse ULA (locale) en plus de l'addresse globale obtenu
# via le routeur.
# un des avantages et que l'addressage ne changera pas même en cas de coupure de l'internet/changement du prefixe globale
# assigné. Il faut néanmoins ajuster le réseau et les autres machine pour que la connectivité suivent. Par défault, sur
# mon réseau, mon routeur ne "route" pas ces addresse. il faut donc que les différence machine soit assigné avec des
# ipv6 ULA du même sous réseau /64 ou ajuster le routeur en conséquence.
# Address=fd70::b/64

[IPv6AcceptRA]
# Optionel: cela force le suffixe de l'ip globale généré. C'est pertinent amha pour des machine dont l'ipv6 devra
# être indiqué dans des enregistrement dns AAAA.
Token=::b

Il vous suffira ensuite de donner l’autre interface vslan2 à votre conteneur/machine virtuel avec les outils dédiés.

Interface avec systemd-nspawn

Note : Si vous utilisez systemd-nspawn, vous pouvez aussi utiliser la directive MACVLAN qui vous permet de déléguer la création de l’interface.

# /etc/systemd/nspawn/container.nspawn
[Network]
Private=yes

# Solution basique : délégation de l'interface créer exprès pour le conteneur
Interface=vslan2

# Solution alternative, laissez nspawn gérer la création d'une interface MACVLAN à partir de vslan 
# l'interface s'appelera "lan" à l'intérieur.
# MACVLAN=vslan:lan

Allez plus loin

L’article suivant de cette série est à propos de réaliser un Routeur avec networkd.

🌐 Des déclenchement selon l'état du réseau

Sun, 24 Aug 2025 00:00:00 +0000

Introduction

Dans un précédent article, j’ai présenté le fait qu’il est possible sans grande difficulté de démarrer des services systemd avec des règles udev, ce qui est très pratique pour détecter le branchement d’un disque dur ou d’une carte sd.

Mais qu’en est-il quand on veut faire des actions liées au réseau ?

Cas 1 : Événement sur l’existence de l’interface réseau

Le point le plus simple et le plus similaire au cas précédent est de réaliser une action sur le “branchement” d’une interface réseau. Cela peut avoir du sens dans certains cas particulier tel que le partage de connection usb depuis un téléphone : L’interface n’existe que si le téléphone active l’option et disparaît à l’instant où le partage se termine.

Dans ce cas présent, la méthode la plus fiable est de jouer là aussi avec les règles udev. Mais si vous pouvez garantir la stabilité du nom de l’interface, par exemple avec networkd, une méthode plus simple existe :

En effet, le système présente les interfaces réseau sous la forme de device systemd. Il est ainsi possible d’utiliser ces éléments pour exécuter un service

Pour voir les interfaces réseaux découvertes sur votre machine par systemd :

systemctl | grep sys-subsystem-net-devices

Voyons donc comment faire dans un cas concrêt

Forcer un nom d’interface stable avec networkd

Par défault sur ma machine, le nom des interfaces usb de tethering sont systématiquement modifié à la reconnection ce qui n’est pas pratique dans notre cas.

Pour ce faire, je vais utiliser networkd car la configuration de celui-ci est très simple. Il est possible de forcer un nom d’interface stable avec networkd sans passer par de la configuration udev.

Petit aparté sur la cohabitation systemd-networkd / NetworkManager: Contrairement à ce que peut faire croire certaines documentations, il est aujourd’hui tout à fait possible de faire tourner à la fois network-manager et network-manager sur la même machine dans le même temps. Il faut juste clarifier quelle interface vous gérer avec quel outil. Network-manager excelle pour les configurations dynamiques (connection wifi par exemple), là où systemd-networkd est idéal pour des interfaces statiques. Cet état de gestion partiel par un outil abouti à ce que l’outil obtienne une vision réduite sur l’interface, mais il reste néanmoins conscient de leur existence. De ma connaissance le seul conflit qu’il peut être nécessaire de résoudre est d’éviter d’avoir à la fois systemd-networkd-wait-online.service et NetworkManager-wait-online.service actif en même temps.

Dans le cas présent, on fixe vis à vis du port usb car c’est plus simple, mais il est probablement possible de fixer cela mieux, néanmoins je manque de meilleures idées.

Pour cela, il faut évidemment que networkd soit activé, comme dit précédemment, ce n’est pas un gros soucis (du moins sous debian) même si vous utilisez déjà NetworkNanager:

/etc/systemd/network/10-netusb.link:

[Match]
# À ajuster avec le path obtenu pour l'interface avec udevadm info
# udevadm info /sys/class/net/enx02e17d08a1ad
Path=pci-*** 

[Link]
Name=netusb

/etc/systemd/network/10-netusb.network:

[Match]
Name=netusb

[Network]
DHCP=yes

Relancez networkd:

sudo systemctl daemon-reload && sudo systemctl restart systemd-networkd

Maintenant testons notre service

$HOME/.config/systemd/user/test_network.service:

[Unit]
Description=test_network
After=sys-subsystem-net-devices-netusb.device
BindsTo=sys-subsystem-net-devices-netusb.device

[Service]
Type=simple
ExecStart=echo "running"
RemainAfterExit=true

[Install]
WantedBy=sys-subsystem-net-devices-netusb.device

Il vous faut l’activez:

systemctl --user enable test_network

Maintenant si vous activez le partage réseau sur le téléphone le service démarrera. Il vivra même le temps de l’interface réseau grâce à BindTo et RemainAfterExit.

Cas 2 : Événement sur l’état du réseau / de l’interface réseau

Pouvoir réagir sur l’existence d’une interface réseau, c’est bien, mais pouvoir réagir sur l’état d’une interface réseau ça semble néanmoins un cas plus pertinent : Démarrer son service quand le réseau est actif, redémarrer un service si le réseau “saute”, lancer un script de backup local quand le réseau se déconnecte, etc.

network-online.target

La première intuition serait d’utiliser ce qui existe dès à présent dans systemd, la target “network-online.target”. Malheureusement, elle n’est utile que pour le premier accès au réseau de la machine :

Note that this unit is only useful during the original system start-up logic. After the system has completed booting up, it will not track the online state of the system anymore. Due to this it cannot be used as a network connection monitor concept, it is purely a one-time system start-up concept.

Cela peut être utile dans de nombreux cas cependant, mais ne couvre pas tous les usages.

Script “Dispatcher”

Faute de solution systemd qui semble purement intégré et standard, il faut donc soit :

nous tourner vers des solutions dépendantes de nos outils réseaux : NetworkManager, systemd-networkd, …
créer nous même notre solution logicielle pour répondre à ce problème.

Il existe quelques logiciels existant pour gérer ce genre de cas :

NetworkManager possède mécanisme de script dit “dispatcher” qui semble plutôt éprouvé.
Systemd-networkd ne possède actuellement (août 2025) pas de solution, mais des logiciels tiers comparables au dispatcher de NetworkManager existe :
- networkd-dispatcher qui semble à priori un bon choix avec sa présence dans les dépôts, dans les fait le logiciel s’avère pour le moment décevant.
  - La gestion des interfaces qui change de nom est dysfonctionnelle.
  - Contrairement à NetworkManager, il semblerait qu’il soit obligatoire de placer les scripts dans des dossiers par état.
- network-broker : non testé, en rust, mais qui semble basé sur la même logique que networkd-dispatcher donc probablement les mêmes problèmes, pas beaucoup de développeurs.
- network-event-broker : Non testé , en go, créé par vmware.

Dans tous les cas, il s’agit là de script bash pour gérer le réseau. Ce n’est pas le plus élégant, mais il est évidemment envisageable de convertir ces scripts pour lancer/arrêter des target/service systemd correspondant à nos besoins.

Exemple: NetworkManagers Dispatcher

Un petit exemple pour forcer un logiciel à se redémarrer si une nouvelle connexion gérée par NetworkManager est “UP” :

/etc/NetworkManager/dispatcher.d/01-restart-myservice-on-new-network-up :

#!/bin/bash
case $2 in
  up)
    systemctl try-restart --no-block myservice.service
  ;;
  *)
    ;;
esac
exit 0

La solution idéale ?

La solution qui me paraîtrait idéal pour des cas simple, serait tout simplement d’avoir un service :

capable d’écouter en dbus sur les évènements networkd.
capable via ces données d’activer/désactiver des target systemd correspond au fait que l’interface réseau fonctionne.

Une implémentation assez simple de ma part se trouve ici En démarrant le script python listen_events.py via le service networkd_listener.service (il vous faut dbus-fast),

les targets suivantes sont gérés :

networkd_status.service correspond à l’état général de la connectivité de la machine (faire partie d’un réseau). le service est actif si l’ “OperationalState” général est “routable”.
networkd_link_status@[interface_name}.target correspond à l’état de la connectivité d’une des interfaces. le service est actif si l’ “OperationalState” de l’interface est “routable”.

Avec une telle solution, on ne peut pas forcément gérer des cas fin de réseaux, mais on peut gérer relativement simplement le cas qui seront probablement le plus commun :

Démarrer/arrêter des services selon si le réseau est actif ou nom, généralement ou pour une interface spécifique.

On peut imaginer par exemple une autre version du service test_network qui ne fonctionne que si l’interface usb est fonctionnelle (et non existante comme dans l’exemple précédént) :

[Unit]
Description=test_network
After=networkd_link_status@netusb.target
BindsTo=networkd_link_status@netusb.target

[Service]
Type=simple
ExecStart=echo "running"
RemainAfterExit=true

[Install]
WantedBy=networkd_link_status@netusb.target

Et Si l’interface réseau n’importe pas :

[Unit]
Description=test_network
After=networkd_status.target
BindsTo=networkd_status.target

[Service]
Type=simple
ExecStart=echo "running"
RemainAfterExit=true

[Install]
WantedBy=networkd_status.target

Cas 3 : Évènements sur la connectivité à l’internet

La version précédente, permet de faire fonctionner un service si le réseau existe (= possède une adresse) mais ne garantie pas de l’accès internet est bel et bien présent.

On peut imaginer une solution simple pour ce cas :

un script python utilisant ping testant de temps en temps la connectivité
un service systemd qui utilise ce script.

ping_test.py:

#!/usr/bin/env python3

import os
import random
import subprocess
import time
import datetime

def test_targets(targets, count) -> bool:
    """
    Tests connection to target, return true if one of the target is reachable
    """
    for target in targets:
        ping_process = subprocess.run(["ping", "-c", f"{str(count)}", target])
        if not ping_process.returncode:
            return True
    return False

ping_targets = os.environ.get("PING_TARGETS", "")
if not ping_targets:
    exit(1)
ping_targets = ping_targets.split(",")
heartbeat = int(os.environ.get("HEARTBEAT", "60"))
ping_count =  int(os.environ.get("PING_COUNT", "1"))

while True:
    random.shuffle(ping_targets)
    if not test_targets(ping_targets, ping_count):
        print(f"{datetime.datetime.now()} - HEARTBEAT FAILED")
        exit(0)
    print(f"{datetime.datetime.now()} - HEARTBEAT SUCCESS")
    time.sleep(heartbeat)

wan.service:

[Unit]
Description=Internet working ?
After=networkd_status.target
BindsTo=networkd_status.target

[Service]
Type=simple
# check with multiple url in case, one of them fail for internal reason
Environment=PING_TARGETS=inkey-art.net,perdu.com,perdus.com,linuxfr.org
# heartbeat in sec (verify connection each 2min)
Environment=HEARTBEAT=120
ExecStart=/opt/ping_test.py
Restart=always

[Install]
WantedBy=networkd_status.target

On peut d’ailleurs comme dans l’exemple ici profiter de l’existence de networkd_status.target pour éviter de ping quand le réseau est assurément non disponible.

Cas 4 : Évènement sur l’activation d’un socket.

Il reste un dernier cas, un peu différent, mais il me fallait l’aborder, d’autant qu’il est très bien intégré à systemd. C’est l’activation par socket.

L’idée n’est là pas tant d’agir sur le réseau au sens interface réseau, mais plutôt au sens connection, au sens socket.

Le principe de l’activation par socket est de pouvoir démarrer un service que si une connection au socket associé est ouverte.

J’y vois 2 grand intérêt :

réduire la latence du boot (pas de nécessité de démarrer un démon ssh si le port ssh n’est pas contacté)
réduire l’usage des services utilisé peu régulièrement. Je pense que la mémoire vive est probablement là où ça doit jouer le plus.

Ce cas est déjà bien présenté dans le blog d’ilManzo’s en anglais. Je vous conseille donc d’y jeter un œil.

Pour résumer rapidement la procédure :

Il vous faut un fichier .service et un fichier .socket.
Le fichier .socket doit être activé et démarré pour écouter sur le port voulu.
Il faut adapter le code du serveur pour qu’il puisse utiliser le socket déjà ouvert.
Il est possible via diverses astuces notamment systemd-socket-proxyd de gérer le service de sorte à qu’il s’arrête s’il n’y a plus d’activité sur le socket.

Conclusion

Creuser cette question m’a beaucoup amusé.

J’ai été un peu déçu du manque de complétion de systemd sur la partie événement lié au réseau, mais comme on le voit, il est possible assez facilement d’y remédier. On peut espérer néanmoins à l’avenir quelques mécanismes un peu plus solides et intégrer pour ce type d’évènement dans systemd. Le cas de vouloir démarrer un service à la connection/déconnexion d’une interface réseau ne me semble pas si extravagant que systemd ne mériterait une intégration de ce nom.

En attendant, il est possible de bricoler des targets et du service systemd pour un peu tout ce qu’on veut et ainsi avoir un système plus “réactif”.

🔗 Dans la jungle des IPCs

Fri, 27 Jun 2025 14:20:00 +0200

Introduction

Dans les programmes informatiques, les IPCs sont partout et de types très divers.

Pour rappel, il s’agit là de diverses technologies qui permettent à plusieurs processus de communiquer entre deux (comprendre : se partager des données).

Il y a, à mon sens 2 niveaux d’IPCs :

Les IPCs “bas niveau”, implémenté par le kernel :
- implémente des fonctionnalités simples.
- peu abstrait (besoin de définir la taille de l’espace alloué dans le cas d’un segment de mémoire partagé par exemple).
- Sous linux, on à notamment :
  - Tube(pipe)
  - Fichier
  - Socket (utilisé pour le réseau notamment)
  - Signaux (plutôt utilisé pour agir sur l’état du service, sens standardisé)
  - Segment de mémoire partagée
  - des mécanismes de synchronisations : ex : les semaphores.
Les IPCs “haut niveau” :
- Basé sur les IPC bas niveau (très souvent les sockets).
- Plus abstraits.
- Ajoute de diverses garanties selon les technologies, par exemple :
  - bonne récéption des données.
  - validation d’un format des données.
  - récéption synchrone (RPC) ou asynchrone (mq)
  - diverse paradigme de communication (Stream, PubSub), etc.
  - Logique unidirectionnelle, bidirectionnelle ou encore vers n récepteurs.

Si l’on comprend les IPC “haut-niveau”, les technologies de communications entre processus sont très nombreuses et il n’est pas toujours si simple de savoir quoi utiliser, ce qui abouti dans de nombreux cas à utiliser les technologies connu plutôt qu’une éventuelle meilleure technologie pour le cas d’usage.

Bref, j’avais du temps à perdre et j’ai donc réalisé un petit programme nommé Universal Ping, ou j’ai testé plus des dizaines d’IPC avec ces contraintes :

Langage Python
Communication simple type “RPC”:
- Appel “Ping” avec variable de nombre “n”
- Retour “n” fois “Pong…”

J’en ai profité pour essayer de clarifier dans ma tête tout cela. Voici donc ma façon, sous forme d’arbres de décisions de présenter la diversité des ces IPCs :

Quel IPC Choisir ?

J’ai organisé les IPCs autour d’un point qui me semble assez important : L’IPC fournit-elle une API ? Et si oui, est-elle prévu pour être utilisé publiquement (comprendre par des programmes totalement extérieurs sans difficultés).

J’ai donc séparé les IPC en trois catégories :

Les IPCs conçu pour fournir une API “publique” explicite.
Les IPCs conçu pour fournir une API “privée” explicite (plutôt conçu pour une application en plusieurs parties).
Les IPCs sans support intégré de mécanisme d’API.

Note : Il s’agit là d’une organisation subjective. Bien évidemment, il est toujours tout à fait possible d’utilisé une IPC sans mécanisme d’API et d’ajouter une documentation d’une API et/ou un sur-couche logicielle qui gèrerait l’API, mais cela sera moins “standard” qu’une technologie qui est conçue dans ce but.

API Publique

Si je veux concevoir un logiciel sur lequel d’autres logiciels peuvent se brancher, c’est vers ces solutions que je me tournerais :

API Privée

Si je devais faire un logiciel “en plusieurs parties”, ces solutions sont élégantes :

L’aspect API est particulièrement intéressant si vous voulez travailler à plusieurs sur différente partie sans vous marcher dessus.

Les autres IPCs

Ces technos requièrent une clarification d’API entre les différents processus utilisant la technologie pour être utilisé convenablement. Cependant, elles sont pour beaucoup simple d’accès et n’ont pas forcément les mêmes avantages que les technologies précédentes, je pense en particulier :

L’aspect stockage des BDD
L’aspect asynchrone des Messages Queue.

Certaines ont aussi des cas d’usage très défini et sont quasi-imbattable dans ce cadre précis, je pense en particulier à MQTT pour des capteurs. L’absence d’API clarifié n’est pas forcément un gros soucis notamment ll est très facile de regarder le flux avec un outil comme MqttExplorer et que les avantages du protocole surpassent cet inconvénient mineur pour ce cas d’usage.

Mon avis ?

En faisant ce petit test de divers IPC, il y a clairement des technologies que j’apprécie plus que d’autres :

IPC trop complexe à mon goût (besoin très particulier, gros projet, usage legacy) :
- IPC bas niveau : Amusant jusqu’au moment ou il faut réimplémenter les fonctionnalité d’un ZMQ.
- GRPC/Thrift: Je trouve l’intégration dans Python, en particulier de GRPC très lourde.
- RabbitMQ (et probablement Kafka) : Le code python pour mon petit RPC m’a paru inutilement compliqué.
Standard de fait :
- OpenAPI, Rest : Pour tout ce qui est Web.
- MQTT : Pour les capteurs.
- D-BUS : Pour la communication avec un démon quelconque dans un Linux Desktop.
Simple et efficace :
- varlink: Je pense que c’est l’idéal si vous avez besoin d’une API de communication qui “sort” d’un logiciel dans un conteneur.
- rpyc: Très facile à prendre en main, parfait pour prototyper un logiciel distribué rapidement.
- ZMQ : Super simple d’accès là aussi.
- Redis/Valkey : BDD très versatile, intéressant pour partager des données à faible durée de vie.

👋 Voilà, Voilà, plus qu’à trouver des cas d’usage concrêt pour jouer avec plus de ces technos 😅 !

⚙️ Sur les OS et les noyaux

Thu, 08 May 2025 17:50:59 +0100

Introduction

J’utilise Gnu/Linux tous les jours, j’ai eu autrefois cours sur les systèmes d’exploitation, fait un peu de VHDL et d’assembleur… Et pourtant le tutoriel Operating System in 1,000 Lines 🇬🇧 m’a appris, réappris et fait mieux comprendre ce qu’est réellement un système d’exploitation et quel est le rôle concrêt d’un noyau (aka kernel).

Cela a aussi abouti à pas mal de questionnement sur le fonctionnement de tout cela auquel j’ai recherché des réponses.

J’ai donc décidé de re-clarifier pour moi et pour d’éventuels lecteurs, quelques points en essayant de rester à la fois simple et clair.

L’espace de mémoire physique présenté au processeur est “virtuel”.

Un noyau doit décider comment il organise la mémoire. Le processus de boot lui donne accès à un espace mémoire dite “physique”. Pour être un plus concrêt, un noyau à d’une façon ou d’une autre une “carte” de l’organisation de la mémoire, par exemple via un linker script.

Mais qu’est-ce qui se cache derrière l’adresse 0x00000 ou 0x30000 ? la RAM ? un contrôleur de la carte mère quelconque ? le GPU ? Autre-chose ?

En réalité, l’allocation de tel ou tel parti de cet espace à tel ou tel mémoire est définie pas une spécification (lié à l’architecture du processeur et le processeur en lui-même). Il y a ainsi un bon nombre de “trou” dans cet adressage. L’adresse 0x02323 pointe peut-être vers rien du tout.

Donc l’espace de mémoire “physique” est, lui-même, une représentation « virtuelle » de différentes mémoires accessibles, non pas forcément dans le sens ou l’on pourrait le changer dynamiquement (il n’est pas très clair pour moi ce qui est physiquement fixé ou non là-dedans), mais plutôt dans le sens ou plusieurs mémoires bien différentes se retrouve accessibles depuis un même espace d’adressage de façon transparente pour le noyau (qui a intérêt à savoir réellement où se trouve chaque chose bien évidemment).

Il existe deux grandes méthodes pour organiser l’adressage l’espace mémoire classique (RAM) et l’espace IO :

Avoir deux espaces mémoire séparé entre IO et RAM et donc des instructions CPU spécifiques. C’est le mécanisme de port IO. C’est ce que faisaient les anciens systèmes informatiques.
Avoir un seul espace avec un branchement “physique” avec le/les contrôleurs IO de sorte que les IO puisse apparaître à des addresses mémoire “physique”. C’est ce qui est utilisé quasi-systématiquement de nos jours.

On pourrait penser que les addresses des IO sont fixés, mais cela ne semble pas si simple. Il existe des interactions possibles pour allouer la mémoire nécessaire.

Un exemple concrêt de l’interaction possible est la technologie rezisable BAR pour les GPU qui permet de négocier la taille allouer pour l’accès au GPU, autrement la taille sera limité et il faut donc un mécanisme pour passer à la donnée suivante et ainsi des cycles cpu perdus.

Dans le cas de périphériques tel qu’un disque dur ou autres, un principe qu’on retrouve beaucoup est :

L’accessibilité des bits de configuration ou d’instructions via un MMIO (memory mapped IO), c’est-à-dire un branchement direct entre l’appareil et le périphérique, ce qui implique un délai d’accès lecture/écriture relativement important.
La présence des espaces mémoire lecture/écriture plus important sous la forme d’un DMA (direct memory access). C’est-à-dire un tampon mémoire synchronisé entre l’appareil IO et l’ordinateur. Un exemple très parlant de ça, et le besoin d’éjecter la clé usb proprement mal gré que la copie (sur le tampon et non sur la clé usb) semble terminé.

Les processus sont déjà une première sorte de “conteneur”.

Si vous connaissez les conteneurs et leur logique d’isolation, pensez que les processus sont déjà un premier mécanisme d’isolation du système :

Par l’accès mémoire : Les processus n’ont accès qu’à une mémoire “virtuelle”, les addresses qu’il utilise ne sont valides qu’à l’intérieur de ceux-ci. Il y a tout un mécanisme dit de pagination, que je ne vais pas expliciter ici.

Par l’accès aux périphériques et autres : Les processus doivent demander l’accès au noyau pour de nombreuses tâches comme écrire sur le disque, via des fonctions appelés appels systèmes.

Ainsi les processus ne peuvent pas intéragir sur d’autre processus par défault et doivent demander l’accès pour bon nombre de tâches. Un certain nombre de mécanismes existent néanmoins (en passant obligatoirement par des syscall) pour au final permettre à ces processus de pouvoir communiquer entre eux, ce sont les IPC(Inter processus communication)… mais ce sera un sujet pour un autre article 😉.

Le noyau définis des concepts basiques de l’informatique

Les concepts tels que la pile, le tas, les processus sont tellement habituel pour un informaticien lambda qu’ils apparaissent comme naturel, il est donc un peu troublant, de se retrouver à devoir les implémenter, concrètement, simplement et de se demander à quoi pourrait ressembler un autre paradigme de fonctionnement de l’OS sans ces éléments ?

Ainsi dans le tutoriel, on implémente des choses telles que :

La structure d’un processus dans le tutoriel est très simple :

struct process {
    int pid; // 0 if it's an idle process
    int state; // PROC_UNUSED, PROC_RUNNABLE, PROC_EXITED
    vaddr_t sp; // kernel stack pointer
    uint32_t *page_table; // points to first level page table
    uint8_t stack[8192]; // kernel stack
};

Bien évidemment, dans le cas d’un noyau vraiment utilisé, les choses sont plus complexe. Mais il est amusant de voir à quel point tout cela est à la fois simple et réellement compliqué.

Un autre point intéressant a noté de voir qu’une partie de la mécanique tiens dans le code du kernel et une autre dans le rôle et l’implémentation même des instructions CPU. Ainsi, on a :

des instructions CPU pour gérer/mettre à jour l’adressage mémoire virtuel.
des instructions CPU pour changer de “mode” (Kernel ou utilisateur), permettant ainsi d’interdire aux instructions suivantes du programme de faire tel ou telles instructions.

Ces éléments sont un peu complexe à comprendre, notamment, car il nécessite de se plonger dans les méandres de la documentation d’architecture CPU, mais ce qu’il faut en déduire c’est que le CPU possède divers mécanismes pour simplifier la vie des concepteurs de système d’exploitation.

Programmer un pilote (driver) n’est (presque) qu’implémenter une spécification d’API

Dans la partie sur l’espace d’adresse physique, je parlais d’espace de configuration disponible via MMIO pour les IO. Mais il ne s’agit pas de remplis ces espaces de données au hasard.

Les appareils d’entrée/sortie une toute une spécification, je dirais même une API que le noyau doit respecter pour utiliser l’appareil, c’est (presque) aussi simple que ça un pilote.

Le tutoriel pour sa part nous donne pour mission d’implémenter un disque virtuel via Virtio et il est relativement amusant de voir qu’il s’agit pour une bonne grosse part de l’application stricte d’une spécification.

Les interruptions CPU sont essentielles au fonctionnement

Les interruptions ?

Les interruptions CPU sont un mécanisme, à l’image des Signaux POSIX (SIGINT, SIGKILL, etc.) qui permet au CPU d’exécuter un code spécifique (configurable) quand le CPU est confronté à des événements tels que :

un périphérique émet un signalement.
certaines instruction CPU.
une erreur CPU : division par 0, erreur de segmentation, etc.

Tout comme les Signaux POSIX, il est possible de se “brancher dessus”.

C’est ce que fait le noyau :

pour l’implémentation du kernel panic dans d’éventuel cas.
pour les syscall permettant aux processus en mode utilisateur d’exécuter par ce biais du code kernel en mode kernel notamment pour pouvoir intéragir avec les périphériques.

Un processus passe généralement souvent dans le mode noyau à intervalles réguliers, ne serait qu’à cause des appels systèmes.

Les interruptions sont la base d’un os préemptif

Dans le tutoriel, l’os se veut coopératif, le processus en cours indique de lui-même quand il redonne la main au noyau pour une nouvelle tâche.

Dans les systèmes d’exploitation récents, le mécanisme est préemptif, c’est-à-dire que le noyau peut arrêter un processus en cours de route.

Seulement voilà, comment faire cela ?

La solution ce sont les interruptions. Tout le mécanisme de préemption fonctionne dessus. En trouvant différente manière de profiter d’interruption qui interromprait le processus, on revient au mode noyau et on peut alors, décider de ne plus re-exécuter le code de ce processus.

Dans les faits, il y a toute une mécanique très complexe d’ordonnancement dans linux là-dessus pour organiser au mieux le temps alloué aux différents processus et leur ordre.

Quant aux interruptions, une astuce pour éviter qu’un processus reste éternellement en fonctionnement en mode utilisateur si aucune interruption n’est provoqué, est tout simplement l’existence d’interruption à intervalles réguliers, configurable via l’option de Compilation CONFIG_HZ.

Pour conclure

Le développement de Kernel/Noyau ne semble pas pour moi, j’ai l’impression qu’une partie notable du travail consiste à implémenter des spécifications complexes (jeux d’instruction CPU, spécification de pilote) dans le contexte d’un langage relativement bas niveaux, c’est une discipline très exigeante à mille lieues de la fluidité du développement python auquel j’ai l’habitude.

Néanmoins, mieux comprendre et démythifié les bases sur lequel son propre code fonctionne permet d’avoir une capacité supplémentaire d’action en cas de problèmes.

Je ne peux donc que vous conseiller de faire ce tutoriel. Le tutoriel s’avère plus ou moins rude selon vos connaissances ainsi je vous conseillerais de ne pas forcément chercher à comprendre le moindre détail, mais d’avancer tranquillement dessus (et ne pas hésiter le copier/coller… vous n’avez pas tous prévu de développer des OS, non ?).

Bonne création de noyau à tous 😀.

🫙 Systemd dans un conteneur avec Podman

Sun, 27 Apr 2025 20:50:59 +0100

Interaction entre Systemd et les conteneurs

Systemd est le programme d’initialisation ou init le plus courant dans les systèmes Gnu/Linux modernes, c’est-à-dire le premier processus (PID 1) démarré par le système qui éxecute tous les autres et permet de gérer l’ordre de démarrage, etc. C’est très utile pour pouvoir gérer un ensemble de processus qui tournent en parallèles sur le système.

Les phases d’initialisations d’un système sur une machine physique :

Dans le cas d’un conteneur, le kernel est déjà fonctionnel, le premier (et souvent le seul) processus lancé dans le conteneur (PID 1) n’a pas besoin d’être un logiciel spécialisé en init, on lance donc généralement directement le logiciel dont on a besoin.

De fait, un outil comme docker n’est pas conçu pour fonctionner avec un init tel que systemd. Ce n’est pas tant un souci technique (des méthodes existent) que philosophique qu’on pourrait résumer simplement par :

Un conteneur doit contenir le minimum de choses : taille minimale et un seul processus. Si on veut plusieurs processus, on utilise plusieurs conteneurs.

On est donc là dans une approche assez microservice avec docker ou autre en orchestrateur de conteneur démarrant chacun un unique processus.

On voit bien là que les 2 programmes que sont docker et systemd se recoupe un peu, chacun a sa manière gère des processus et leur ordonnancement, et l’usage de l’un ou l’autre dépendra de la couche ou l’ordonnancement se fait.

il est ainsi possible de :

gérer des conteneurs via systemd, pour ce faire la meilleure méthode aujourd’hui semble podman avec quadlet.
gérer avec systemd différents niveaux plus ou moins procĥe d’un conteneur avec uniquement systemd :
- Une isolation partielle du service avec différentes directives tel que ProtectSystem , ProtectHome, DynamicUser, …
- Un vrai mécanisme de conteneur avec systemd-nspawn
- Une “portabilité” des services avec les portables service.
démarrer systemd dans un conteneur : Ce qu’on va faire ici :

Pourquoi mettre systemd dans un conteneur ?

Les conteneurs sont très bien, mais la philosophie classique consistant à avoir des conteneurs minimale ne faisant tourner qu’un unique service se révèle de fait pas toujours la plus pertinente.

En effet :

Les outils d’orchestration de conteneurs ne sont pas forcément plus pratique dans certain contexte qu’un systemd. Un administrateur système préfèrera ne pas avoir deux mécanismes d’orchestration totalement disjoints.
Les conteneurs OCI (utilisé par docker et podman) sont très pratique et simple à partager, c’est une méthode pratique pour fournir du logiciel, pourquoi ne pas pouvoir fournir directement un logiciel complet plutôt qu’une pile de composants à orchestrer ?
Le fait de ne pas utiliser systemd avec les conteneurs, implique pour un logiciel qu’on envisage de packager pour une distribution comme debian de devoir dupliqué un même savoir (la gestion du service/processus) dans deux formats différents (service systemd vs paramètre docker/docker-compose/kubernetes).

Dans ces conditions, il me semble que pour un logiciel assez simple avec plusieurs composants qu’on envisage de packager maintenant ou à terme, il est plus simple de simplement générer un conteneur activant le/les mêmes services systemd que le paquet de distribution.

Bien évidemment, il faut choisir intelligemment les composant à intégrer ou pas dedans. Selon les besoins, dans l’exemple ci-dessous, il n’aurait pas exemple été peut être plus pertinent que le conteneur requiert un service valkey externe plutôt que de l’intégrer directement.

Exemple :

Explication

J’ai réalisé un exemple de conteneur avec systemd à l’intérieur. Il contient une application web minimale avec plusieurs éléments :

Une base de donnée clé/valeur (valkey).
Un serveur web python (uvicorn) contenant une api (avec fastapi) et utilisant la BDD.
Un frontal web nginx en proxy inverse.

J’utilise podman plutôt que docker dans ce cas de figure, car l’intégration systemd est plutôt poussé et ne requiert aucun effort, podman détecte par défault automatiquement le conteneur utilisant systemd et fait le nécessaire pour que le tout soit fonctionnel.

Ordonnancement prévu des services :

Implementation

C’est relativement facile à faire, voici le Containerfile :

# On installe la base du système
FROM debian:trixie as build
RUN apt-get update && apt-get install -y systemd nginx valkey-server \
    python3-fastapi python3-uvicorn python3-sdnotify python3-redis
# On ajoute les fichiers de notre application, notez le fichier webapp.service !
COPY nginx/conf.d /etc/nginx/conf.d
COPY www /var/www/html
COPY webapp.service /etc/systemd/system
COPY api/* /srv
RUN rm /etc/nginx/sites-available/* && rm /etc/nginx/sites-enabled/* 

# On à besoin de systemd fonctionnel pour lancer systemctl donc un nouveau stage est nécessaire
FROM build
# On active ici nos services spéciaux, dans le cas présent on préferera un unique service ou target
# contenant toutes les dépendances
RUN systemctl enable webapp
# la commande magique qui lance systemd en processus principal
CMD [ "/lib/systemd/systemd" ]
EXPOSE 80 6379

Et le service webapp.service qu’on lance :

[Unit]
Description=Webapp

# On lance toutes les dépendances de notre service ici
Requires=multi-user.target
Wants=valkey.service
Wants=nginx.service

After=multi-user.target
After=valkey.service
After=nginx.service

[Service]
# Le service python qu'on lance implémente sd-notify donc on
Type=notify
NotifyAccess=all
EnvironmentFile=/srv/api_config.env
Restart=always
RestartSec=3
WorkingDirectory=/srv
ExecStartPre=mkdir -p /run/uvicorn
ExecStart=python3 -m uvicorn --workers ${WORKERS_NB} --uds /run/uvicorn/appname.sock api:app
ExecStopPost=rm -rf /run/uvicorn

[Install]
WantedBy=multi-user.target

Vous pouvez voir le détail ici.

On pourrait bien évidemment profiter de la puissance de systemd ici et ajouter facilement des services :

Qui s’active en fonction d’évènements : socket, modification de fichier, …
Qui s’exécute à interval régulier avec les timers.
et probablement d’autres trucs amusants auquel je n’ai pas pensé.

Et les logs ?

Un point particulier à gérer dans ce cas est l’obtention des logs. Dans le cas standard, la méthode classique pour avoir les logs du conteneur (test dans ce cas), donne uniquement le contenu de la sortie standard, ce qui n’est pas très utile.

❯ podman logs test
systemd 257.5-2 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE)
Detected virtualization podman.
Detected architecture x86-64.

Welcome to Debian GNU/Linux trixie/sid!

bpf-restrict-fs: BPF LSM hook not enabled in the kernel, BPF LSM not supported.
Queued start job for default target graphical.target.
[  OK  ] Created slice system-getty.slice - Slice /system/getty.
.........
[  OK  ] Reached target getty.target - Login Prompts.
[  OK  ] Started dbus.service - D-Bus System Message Bus.
[  OK  ] Started systemd-logind.service - User Login Management.
[  OK  ] Started valkey-server.service - Advanced key-value store.
[  OK  ] Started nginx.service - A high performance web server and a reverse proxy server.
[  OK  ] Reached target multi-user.target - Multi-User System.
[  OK  ] Reached target graphical.target - Graphical Interface.
         Starting webapp.service - Webapp...

Debian GNU/Linux trixie/sid 96206de07c7c console

idem avec journalctl CONTAINER_NAME=test

Ce qu’il nous faut ce sont les logs des services suivants :

valkey-server.service
nginx.service
webapp.service

On peut donc lancer journalctl dans le conteneur avec exec :

podman exec test journalctl
# pour un service spécifique
podman exec test journalctl -u nginx.service

Il est probablement possible d’accéder au log journalctl du conteneur d’une façon plus élégante depuis le journalctl de l’hôte.

Une méthode semble être en partageant le dossier /var/log/journal (montage de volume du conteneur) avec le paramètre --directory de journalctl, mais mon test n’a pas été concluant, car la version de systemd n’étant pas compatible l’hôte n’étais pas en mesure de lire le journal du conteneur.

Une autre méthode probablement plus fiable, mais nécessitant des ajustements est d’utiliser systemd-journal-remote, qui permet de transmettre les logs par le réseau en http

Je pense qu’il doit exister d’autres solutions en creusant bien (compatibilité syslog ? partage de socket ?).

Pour conclure :

Systemd dans un conteneur, c’est possible et pas bien compliqué 😀.

💬 Envoyez des notifications XMPP avec Sendi

Mon, 04 Nov 2024 17:10:00 +0200

Introduction

J’utilise beaucoup XMPP pour communiquer, j’ai ainsi mon propre serveur XMPP.

Un des usages, en tant qu’administrateur système d’un serveur, est d’utiliser XMPP pour m’alerter d’évènements qui ont lieu sur le serveur. J’utilisais jusqu’à présent un petit logiciel qui s’appelle sendxmpp. Mon cas d’usage est de le placer dans des scripts systemd avant ou après des scripts pour me dire un peu plus sur l’état du système.

Un exemple par exemple est dans le cas du service backup.service présenté dans le dernier article :

[Unit]
After=btrbk.service btrbk_resume.service
Requires=btrbk.service btrbk_resume.service

[Service]
Environment=XMPP_NOTIFY_ACCOUNT=me@mysuperdomainname.ndd
User=me
Type=oneshot
ExecStart=/usr/bin/sendxmpp ${XMPP_NOTIFY_ACCOUNT} -t -m /path/of/the/message/after/success/backup

Ce logiciel sendxmpp à un gros défault qui me gêne dans son utilisation : il est basé sur le fait d’utiliser quasi nécessairement l’entrée standard, par exemple :

ls -la | sendxmpp me@mysuperdomainname.ndd

Et si on ne veut pas faire ça, la seule option qui reste est alors de données un chemin avec -m.

Ce choix technique, s’il est très pertinent dans des scripts bash, n’est vraiment pas pratique lorsque qu’on veut utiliser ce logiciel dans systemd.

L’idéal, pour moi, serait de pouvoir faire quelque chose comme ça :

ExecStart=/usr/bin/monprogramme ${XMPP_NOTIFY_ACCOUNT} -m "masupercommande ${UNE VARIABLE}"

Ensuite sendxmpp souffre un peu de son âge, créé en 2004, il ne supporte ainsi rien de très original. C’est le genre de logiciel ancien, mais efficace pour sa tâche. Il est malheureusement plus réellement maintenu avec une dernière version en 2014 !

Sendi

Pour pallier ce problème d’entrée, j’aurais pu éventuellement faire un bête script autour de sendxmpp, mais je me suis dit qu’il devait être possible de faire les choses mieux.

J’ai découvert un logiciel intéressant apprise qui a comme objectif de servir pour des notifications de tout type. Cela m’a intéressé. Malheureusement le support xmpp a été supprimé, en effet la librairie qu’il utilise est asynchrone et n’est du coup pas si simple a utilisé pour ce cas d’usage.

J’ai senti alors le défi et j’ai développé Sendi.

Sendi est un autre programme en ligne de commande pour envoyer des notifications XMPP. Il n’utilise pas la sortie standard et supporte l’envoi de fichier par http XEP-0363 et le chiffrement OMEMO XEP-0384 et XEP-0454.

Attention la peinture est toute fraîche, c’est probablement un peu bogué. N’hésitez pas à faire des retours, le but du projet étant d’avoir quelque-chose d’assez fiable.

Je remercie chaleureusement les développeurs xmpp de slixmpp et en particulier Syndace, développeur de slixmpp-omemo qui m’a bien aidé pour déboguer la partie omemo de mes tests automatisés.

Comment utiliser sendi avec systemd :

Dans mon cas particulier, bien qu’il soit possible d’installer sendi via paquet debian (experimental), j’ai testé dans un premier temps avec podman en générant l’image localement.

Je me suis fait un petit script pour que ça soit plus facile à utiliser :

 ❯ cat /usr/local/bin/sendi 
#!/bin/bash
set -euo pipefail
podman run --rm --net=host \
         -v $HOME/.config/sendi:/config \
         -v $HOME/.cache/sendi_container:/root/.cache/sendi \
         -v $HOME/.sendi_upload:/upload \
         localhost/sendi:1.0.0 --config-file=/config/config.toml "$@"

Je peux ainsi avoir cette configuration pour backup.service :

[Unit]
After=btrbk.service btrbk_resume.service
Requires=btrbk.service btrbk_resume.service

[Service]
Environment=SENDI_ACCOUNT_NAME=adminuser
Environment=XMPP_NOTIFY_ACCOUNT=me@mysuperdomainname.ndd
User=me
Type=oneshot
ExecStart=/usr/local/bin/sendi ${SENDI_ACCOUNT_NAME} ${XMPP_NOTIFY_ACCOUNT} --message "Backup process ended 😼"

Une bonne partie de la magie se situe dans le fichier $HOME/.config/sendi/config.toml:

[adminuser]
host="mysuperdomainname.ndd"
port=5222
password="A SUPER PASSWORD"
jid="bot@mysuperdomainname.ndd"
connection_type="standard"
security_level="encrypted"
lang="fr"

Avec cette configuration, les messages sont envoyé par bot@mysuperdomainname.ndd en chiffré bout en bout (via omemo).

La configuration sans podman via les paquets est un peu plus simple, vous n’avez besoin que de $HOME/.config/sendi/config.toml et d’une configuration comme cela :

[Unit]
After=btrbk.service btrbk_resume.service
Requires=btrbk.service btrbk_resume.service

[Service]
Environment=SENDI_ACCOUNT_NAME=adminuser
Environment=XMPP_NOTIFY_ACCOUNT=me@mysuperdomainname.ndd
User=me
Type=oneshot
ExecStart=/usr/bin/sendi ${SENDI_ACCOUNT_NAME} ${XMPP_NOTIFY_ACCOUNT} --message "Backup process ended 😼"

Noter que dans le cas présent le chemin vers sendi a changé, mais le reste est quasiment identique pour cet exemple.

Pour conclure

Sendi est dès à présent disponible en version 1.0 via Pypi, le code est lui disponible sur framagit.

💾 Sauvegarde au branchement avec Systemd: Instantanée BTRFS

Sun, 15 Sep 2024 00:00:00 +0000

Introduction

Dans l’article sur la sauvegarde automatique dès le branchement pour mes photos, j’indiquais comment j’avais réussi à gérer des sauvegardes automatiques au branchement pour mes photos. Cela est très bien, mais pourquoi pas ne pas étendre la mécanique pour la sauvegarde de fichiers ? La mécanique de base s’avère très proche, mais complété pas les fonctionnalités du système de fichier btrfs, cela donne un système de sauvegarde très flexible.

Contrairement aux sauvegardes de photos qui allait de la carte SD au NAS, l’idée là est inverse. On veut pouvoir connecter un disque et le système va écrire de lui-même sur ce disque la nouvelle sauvegarde.

Principe

Enregistrement automatique de sauvegarde d’un disque dur

Le principe est assez simple :

Je branche un disque dur à mon NAS, le disque dur contient une partition avec le label “backup”
Le disque dur est détecté et la partition “backup” est monté par le système.
Le système démarre la sauvegarde, ici avec l’aide de btrbk et de systemd.
Le système démonte la partition du disque automatiquement lorsque la sauvegarde est terminé.

Ajoutons un peu de BTRFS par-dessus

Le système de fichiers btrfs par ses fonctionnalités : gestion de sous-volume et instantané (snapshot), nous permet de figer l’image d’un sous-volume à un instant T directement sans copie. Cette image peut être en lecture seule. C’est un instantané.

L’intérêt ? Il est possible de stocker nos données à sauvegarder dans un sous-volume btrfs, qui sera alors sauvegardé sous la forme d’un instantané en lecture seule qu’on pourra ainsi transmettre sur un autre disque sans risque de corruption de données lié à des modifications durant la sauvegarde.

Les instantanés permettent aussi localement un mécanisme de sauvegarde simple permettant de “revenir dans le temps”. L’autre avantage des instantanés btrfs est qu’ils permettent d’utiliser le mécanisme send-receive qui permet de copier efficacement des sous-volumes (et donc des instantanés) d’un volume btrfs à un autre, potentiellement d’une façon incrémentale en utilisant les sous-volumes déjà transmis.

Donc le principe est le suivant :

On met en route une sauvegarde.
Le système crée un instantané sur le volume source.
Le système copie cet instantané sur le disque de sauvegarde grâce au mécanisme send-receive. il tire parti des instantanés déjà transmis pour ne pas tout retransmettre.

Les limitations de la mécanique sont les suivantes :

send-receive ne gère pas les coupures de réseau, donc pas très efficace par le réseau, car il devra renvoyer tout l’instantané en cas d’interruption.
il ne faut pas abuser des instantanés, l’impact de beaucoup d’instantanés sur l’espace disque et les performances peuvent être important, il faut donc faire le ménage.

La pratique

Prérequis : utiliser btrfs et les sous-volumes

Pour pouvoir utiliser la fonctionnalité, il faut que le disque à sauvegarder utilise btrfs, et il est conseillé de créer des sous-volumes pour définir les différents traitements.

Considérons que l’on veut sauvegarder la partition /home seulement, il faut donc un sous-volume sur home :

Imaginons qu’on a cette arborescence :

/
├── srv : point de montage direct du volume btrfs (voir fstab)
│   └── @home : emplacement du sous-volume `@home` dans le sous-volume par défault de btrfs.
└─ home : On va monter @home ici (voir fstab)

On aurait ainsi des paramètres de montage dans le fichier /etc/fstab similaire à ça :

UUID=6875f33c-4fed-4f43-bf34-4af0b2412ca4 /srv auto defaults 0 0
UUID=6875f33c-4fed-4f43-bf34-4af0b2412ca4 /home auto subvol=@home 0 0

Vous noterez que l’UUID est le même, car on pointe littéralement sur la même partition.

Quant au sous-volume @home, il a pu être créé tout simplement avec cette commande (volume /srv monté)

sudo btrfs subvolume create /srv/@home

Pour ce qui est des instantanés, nous les placerons dans le dossier snapshots à la raçine de /srv et les sauvegardes seront dans le dossier snapshots à la racine de /mnt/backup.

Je ne rentrerai pas plus dans le détail de la mécanique de btrfs, il existe une littérature importante à ce sujet.

Créer une règle Udev

Comme précédemment, il nous faut passer par udev pour gérer l’aspect montage automatique.

99-automount_backup_drive.rules

# Automount usb backup drive on insertion
ACTION!="remove", SUBSYSTEM=="block", ENV{ID_PART_ENTRY_NAME}=="backup", ENV{SYSTEMD_WANTS}+="backup.service"

Ce qui signifie :

Si une action provenant d’un périphérique de système block d’un périphérique donc le label de partition est backup active un évènement qui n’est pas “remove”, alors, on demande à activer l’unité systemd backup.service. On reviendra plus en détail ensuite sur pourquoi backup.service et pas mnt-backupt.mount

📝 Note : l’action est sur les périphériques de type block, ce qui signifie que c’est agnostique du moyen de communication utilisé : USB, SATA, NVME, Réseau. Du moment que le système voit une partition labellisée backup, il tentera de la monter.

Point de montage

Comme précédemment, il nous faut un fichier .mount.

/etc/systemd/system/mnt-backup.mount

[Unit]
Description=Mount Backup
BindsTo=btrbk_resume.service

[Mount]
What=/dev/disk/by-partlabel/backup
Where=/mnt/backup
ReadWriteOnly=true
Type=btrfs

Avec ce point de montage, systemd sait maintenant, qu’en cas d’activation de mnt-backup.mount:

qu’il doit monter la partition de label backup dans /mnt/backup.
qu’il doit la monter en lecture/écriture (sinon on va avoir des soucis) !
qu’il doit démarrer btrbk_resume.service. Je reviens dessus après.
qu’il doit la monter en btrfs. Il s’agit là d’une vérification supplémentaire, car on va utiliser des outils spécifiques à btrfs. si l’on branche un disque de sauvegarde en ext4, il faut mieux que le processus s’arrête au plus tôt.

Btrbk

Pour gérer efficacement la sauvegarde après quelques hésitations et un script perso, j’ai finalement décidé d’utiliser btrbk. btrbk est un outil en perl pour gérer les sauvegarde via btrfs, notamment avec la méthode “création d’instantanés puis envois sur disque via btrfs send/receive”.

Il a beaucoup d’avantages :

paquet debian.
gère correctement l’incrémental.
gére toute la mécanique de rotation des sauvegardes.

En bref, il nous simplifie la vie pour utiliser les fonctionnalités de btrfs dans notre cas.

Il faut néanmoins un peu de temps pour l’apprivoiser les règles de conservations sont ainsi assez compliqué à comprendre. Je vous laisse chercher dans la documentation.

Dans notre cas simple, on aura donc une configuration de ce style :

transaction_log            /var/log/btrbk.log
# les snapshot du volume src et targets seront placé dans le dossier snapshot à la racine
snapshot_dir               snapshots

# règle de conservation des snapshots
snapshot_preserve_min   2d
snapshot_preserve       14d

# règle de conservation des sauvegardes sur le disque de sauvegarde
target_preserve_min     no
target_preserve         20d 10w *m

# on définis ici qu'on fait des snapshot pour le sous volume @home de /srv
# et qu'on les copie en mode send-receive vers /mnt/backup
volume /srv
  target send-receive /mnt/backup
  subvolume @home

On pourrait s’arrêter là et modifier le système pour que backup.service lance le btrbk.service du paquet debian et ça fonctionnerait pour la sauvegarde à chaud. Mais mon souhait et d’avoir un snapshot journalier dans tous les cas et éventuellement une sauvegarde si le disque de sauvegarde est branché.

Snapshot régulier et sauvegarde si possible

Pour réaliser cette mécanique d’instantanés réguliers en plus de la sauvegarde à chaud, il faut jouer un peu avec systemd.

Btrbk, permet de séparer la transmission de sauvegarde de la réalisation de snapshot. Pour ce faire, au lieu de faire btrbk run on peut utiliser btrbk snapshot -pet btrbk resume. Avec quelques override systemd, on peut arriver au bon résultat :

On surcharge btrbk.service pour ne faire que des instantanés et ne rien supprimer(-p):

# /lib/systemd/system/btrbk.service
[Unit]
Description=btrbk backup
Documentation=man:btrbk(1)

[Service]
Type=oneshot
ExecStart=/usr/sbin/btrbk run

# /etc/systemd/system/btrbk.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/btrbk snapshot -p

On ajoute btrbk_resume.service pour faire la transmission des sauvegardes:

# /etc/systemd/system/btrbk_resume.service
[Unit]
After=btrbk.service
# 📝 note: on demande implicitement `mnt-backup.mount`.
RequiresMountsFor=/mnt/backup
RefuseManualStart=true

[Service]
Type=oneshot
# 📝 note: On n'a pas mis de `-p` ici, 
# la rotation des instanées et sauvegardes se fera à la fin de la transmission des sauvegardes.
ExecStart=/usr/sbin/btrbk resume

On crée backup.service notre point d’entrée pour tous processus de sauvegarde qui fera :
- la création des instantanés
- tentera d’exécuter la sauvegardes

# /etc/systemd/system/backup.service
[Unit]
After=btrbk.service btrbk_resume.service
Requires=btrbk.service btrbk_resume.service

[Service]
# 📝 Note: Ce service est un peu subtil, car on tire profit des spécificités des services oneshot. 
# Ce service lancera les 2 services btrbk et restera en activating, jusqu'à qu'ils s'arrêtent et donc sera enfin `inactivate`.
# il n'est à ma connaissance pas possible de faire la même chose avec des `.target` qui seront en `activate` à la fin du processus.
Type=oneshot
# Fausse commande car c'est obligatoire pour les service
ExecStart=/bin/true

On surcharge aussi btrbk.timer des paquets pour démarrer notre point d’entrée :

# /lib/systemd/system/btrbk.timer
[Unit]
Description=btrbk daily backup

[Timer]
OnCalendar=daily
AccuracySec=10min
Persistent=true

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/btrbk.timer.d/override.conf
[Timer]
Unit=backup.service

📝 Note : Il ne faut pas oublier d’activer ce service sinon vous n’aurez pas les sauvegardes régulières

Récapitulatif Scénario

On à donc les 3 scénarios suivants :

1. Branchement à chaud

On branche le disque de sauvegarde.
udev demande à démarrer backup.service
backup.service démarre d’abord btbrk.service car btrbk_resume.service demande à être exécuté après.
les snapshots sont créés, btrbk_resume.service est démarré.
btrbk_resume.service monte mnt-backup.service. Il fait la sauvegarde.
À la fin de btrbk_resume, mnt-backup.service est démonté

2. Sauvegarde régulière

btrbk.timer démarre backup.service
backup.service démarre d’abord btbrk.service car btrbk_resume.service demande à être exécuté après.
les snapshots sont créés, btrbk_resume.service est démarré.
btrbk_resume.service monte mnt-backup.service. Il fait la sauvegarde.
À la fin de btrbk_resume, mnt-backup.service est démonté.

3. Sauvegarde régulière sans disque branché

btrbk.timer démarre backup.service
backup.service démarre d’abord btbrk.service car btrbk_resume.service demande à être exécuté après.
les snapshots sont créés, btrbk_resume.service est démarré.
btrbk_resume.service monte mnt-backup.service mais mnt-backup.service ne peut être démarré. arrêt du service.
backup.service se stoppe, mais les instantanés ont bien été créés.

Conclusion

Btrfs n’est pas si facile à prendre en main, mais les concepts bien compris et à l’aide de systemd, on peut créer des mécanismes de sauvegardes puissants.

📦 Article sur Linux Embedded: Introduction au paquetage pour debian

Fri, 17 May 2024 17:40:32 +0100

J’ai publié un article technique sur la création de paquet Debian sur le blog Linux Embedded.

Pourquoi un article sur les paquets Debian ?

La création de paquet logiciel pour la distribution Gnu/Linux Debian peut se révéler vraie galère, car les outils sont nombreux, de différents niveaux¹, conçu pour répondre à différents d’usage.

Il existe de nombreuses documentations et tutoriels en ligne, mais peu de ressources permettant d’avoir une vision d’ensemble un peu claire du sujet, de sorte qu’il devient assez difficile de trouver la bonne information, on se retrouve facilement à lire des discussions stackoverflow qui propose chacune une façon différente de faire les choses ce qui au lieu de vous aider, vous embrouillent encore un peu plus.

Pour cette raison, j’ai beaucoup creusé et j’ai cherché à clarifier le sujet.

Les paquets Debian sont un sujet à la fois super vaste et difficile à maîtriser pour la plupart des développeurs, à moins d’être mainteneurs de paquet, car :

Quand un logiciel est configuré pour être packager, on revient à la marge sur la configuration et donc on peut très vite être perdu lors de la création d’un nouveau paquet des mois ou des années après.
Un logiciel pourra se mettre en paquet d’une manière très différente d’un autre.

Il me paraissait donc nécessaire d’avoir un article condensé permettant à la fois pour un novice d’avoir une 1ére approche, mais aussi des éléments sur le contexte logiciel très large de la création de paquet debian pour savoir un peu mieux où chercher et où trouver l’information.

Je veux lire l’article !

Cet article ne permettra donc pas de répondre dans le détail sur comment faire votre paquet, mais vous donnera, je l’espère, les éléments pour partir dans la bonne direction si vous envisagez d’en créer un.

Aller voir l’article

Bonne lecture 😄 !

J’espère beaucoup de Debputy pour pouvoir à terme générer des paquets à la norme Debian sans devoir subir toutes les couches successives d’outils Debian de génération de paquets. Mais cela reste pour l’instant qu’un outil expérimental incomplet. Le paquetage Debian mériterait d’avoir un outil de génération plus monolithique et moins permissif afin d’être plus accueillant. ↩︎

💾 Sauvegarde au branchement avec Systemd: Photos

Sat, 10 Feb 2024 00:00:00 +0000

Introduction

Dans l’article sur mon processus de gestion de photos, je notais que je n’avais pas poussé l’automatisation à fond sur la partie sauvegardes du contenu des cartes avec le NAS. C’est maintenant chose faite. Je vais donc dans cette logique, expliquer ici comment on peut facilement gérer ce type d’automatisation avec udev et systemd.

Enregistrement automatique de carte sd

Le principe est assez simple :

Je branche une carte SD à mon NAS.
La carte est détecté et est monté par le système.
Le système démarre la sauvegarde, ici avec le logiciel `phockup qui me trie en même temps le tout.
Le système démonte la carte automatiquement lorsque la sauvegarde est terminé.

Créer une règle Udev

Systemd n’est pas capable par lui-même d’écouter les évènements provenant des périphériques. Le logiciel permettant cela est udev. Il faut donc rajouter une nouvelle règle .rules dans le dossier /etc/udev/rules.d/.

la commande udevadm monitor permet d’écouter les évènements Udev, elle nous permet ainsi de pouvoir constater que l’évènement de branchement/débranchement de la carte est bien défini. Cela me permet ainsi de découvrir que le peripheral de carte SD, est, dans mon cas /dev/mmcblk0.
Il est possible d’en savoir plus tant que le périphérique est branché avec la commande : udevadm info --query=all --name=<devname>, elle retourne plein d’informations par périphérique qu’on pourra ensuite utilisé pour notre règle.

📝 Note : j’ai volontairement affiché ici que quelques résultats de la commande.

$ udevadm info --query=all --name=/dev/mmcblk0
…
N: mmcblk0
…
E: SUBSYSTEM=block
…
E: DEVNAME=/dev/mmcblk0
…

$ udevadm info --query=all --name=/dev/mmcblk0p1
…
N: mmcblk0p1
…
E: SUBSYSTEM=block
…
E: DEVNAME=/dev/mmcblk0p1

Il est assez facile dans le cas présent de bien filtré dans mon cas :

/etc/udev/rules.d/20-automount_sd_cards.rules

# Automount sd card on insertion
ACTION!="remove", SUBSYSTEM=="block", KERNEL=="mmcblk0p*", ENV{SYSTEMD_WANTS}+="mnt-sdcard.mount"

Ce qui signifie :

Si une action provenant d’un périphérique de système block d’un périphérique donc le nom kernel commence par mmcblk0p (une partition de mmcblk0) active un évènement qui n’est pas “remove”, alors, on demande à activer l’unité systemd mnt-sdcard.mount

📝 Note : Il est préférable pour des raisons de fiabilité d’utilisé ACTION!="remove" plutôt que ACTION=="add".

Point de montage

Les points de montages avec systemd peuvent être aussi bien créé avec des fichiers .mount qu’avec une syntaxe /etc/fstab. Aucune des deux méthodes n’est plus valable. La mécanique de .mount à l’avantage/le désavantage de produire des fichiers séparer pour chaque point de montage, ce qui est à la fois plus complexe, mais bien plus pratique, notamment si vous cherchez à empaqueter la configuration.

Attention le nommage doit “correspondre” au point de montage ainsi mnt-sdcard correspond à /mnt/sdcard

/etc/systemd/system/mnt-sdcard.mount

[Unit]
Description=Mount SD Card
# liaison forte à save_photos.service, 
# - Demande que save_photos.service soit activé
# - s'arrètera quand save.photos.service s'arrêtera.
BindsTo=save_photos.service

[Mount]
What=/dev/mmcblk0p1
Where=/mnt/sdcard
# On préfèrera ne pas monter la carte en écriture.
Options=ro

Avec ce point de montage, systemd sait maintenant, qu’en cas d’activation de mnt-sdcard.mount:

qu’il doit monter la 1ére partition de mmcblk0, mmcblk0p1 dans /mnt/sdcard.
qu’il doit la monter en lecture seule.
qu’il doit démarrer save_photos.service. Les cartes SD de photos ne contenant qu’une seule partition, cela rend les choses plus simples.

Service de sauvegarde

On peut maintenant faire la sauvegarde a proprement dit :

/etc/systemd/system/save_photos.service

[Unit]
# liaison forte à mnt-sdcard.mount
# - Demande que mnt-sdcard.mount soit activé.
# - s'arrètera quand  mnt-sdcard.mount s'arrêtera.
# - On met une relation d'ordre pour que le montage s'execute avant.
After=mnt-sdcard.mount
BindsTo=mnt-sdcard.mount
# On empêche le démarrage manuel, seul mnt-sdcard.service doit démarrer ce service
RefuseManualStart=true

[Service]
# on démarre le service avec les droits utilisateur
User=inkey
# le type oneshot permet facileent de cumuler les commandes
Type=oneshot
# Photos
ExecStart=/home/inkey/.local/bin/phockup /mnt/sdcard/ /home/inkey/Images/Photos/ -c 6 --progress --file-type image
# Video
ExecStart=/home/inkey/.local/bin/phockup /mnt/sdcard/ /home/inkey/Vidéos/Perso/ -c 6 --progress --file-type video

📝 Note : j’ai installé phockup dans $HOME/.local/bin pour le moment

Aller plus loin ?

Notification

Le système ici ne notifie ni quand la copie est démarré ni quand elle est finie. Pour ma part, j’ai complété ce mécanisme avec des commandes qui me notifie avec xmpp. C’est très facile avec ExecStartPre et ExecStartPost.

Sécurisation

Si vous voulez vous amuser un peu, vous pouvez sécuriser un peu plus le service à l’aide de: systemd-analyze security save_photos.service

Mécanisme de Sauvegarde de données hors-ligne (“backup”)

La mécanique pourrait être ajusté pour gérer un système de sauvegarde du contenu du NAS :

on branche un disque
le système détecte qu’il s’agit d’un disque de sauvegarde, probablement à l’aide d’un label de partition.
la sauvegarde commence.
la sauvegarde se termine et le disque est démonté automatiquement

C’est une méthode à la fois simple et efficace pour pouvoir faire des sauvegardes et s’assurer de cette façon que la sauvegarde est bel et bien offline.

Conclusion

Il est assez facile de gérer les points de montage avec systemd pour ce type d’usage. Bref Systemd, c’est sympa, c’est puissant, n’hésitez pas à jouer avec 😃.

🌐 Connexion directe en Ethernet via ipv6 et mDns

Sun, 29 Oct 2023 16:22:08 +0100

Comment facilement créer un réseau rapidement entre 2 appareils connectés en direct en Ethernet ?

Lien local IPV6

L’ipv6 à une fonctionnalité d’ip de lien local, qui commence par fe80. Sous Gnu/linux. Cette fonctionnalité fonctionne par défault sans la moindre modification. Cela permet à chaque appareil d’avoir une IP par défault sans configuration.

Sous Gnome, il peut être nécessaire de modifier la méthode ivp6, afin d’avoir la méthode de lien locale fonctionnelle.

La commande ip -br -c a devrait vous permettre rapidement de constater que l’adresse ip existe bel et bien sur chacune des machines.

Pour tester manuellement le lien local, on peut le faire comme ceci :

# ping de l'autre machine
ping6 -I enp0s31f6 fe80::bf48:d6d:de5a:5542
# exemple pour ssh
ssh user@fe80::bf48:d6d:de5a:5542%enp0s31f6

On remarque qu’il faut définir à chaque fois l’interface.

Accès facile via mDns

Le fonctionnement du lien local est intéressant, mais on remarque qu’il est nécessaire de définir chaque fois l’interface d’une part et d’autre part, il faut connaître les addresses IPs, ce qui n’est pas très pratique.

Une méthode pratique pour éviter de devoir apprendre l’adresse ip, on peut utiliser mDns (nommé aussi avahi/bonjour/zeroconf), qui fournit automatiquement des adresses en hostname.local pour les ordinateurs du réseau local.

Une modification est nécessaire sous Debian aujourd’hui (Debian 12) pour pouvoir faire fonctionner les addresses .local avec le lien-local ipv6 :

En replacement la ligne hosts, pour activer mdns en ipv6 en plus d’ipv4 :

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

par:

hosts:          files mdns_minimal [NOTFOUND=return] dns myhostname

Après ce changement et un redémarrage des machines, il suffit de faire :

# ping de l'autre machine
ping hostname.local
# exemple pour ssh
ssh hostname.local

🪄 Rendre un blog hugo plus dynamique avec HTMX

Sat, 09 Sep 2023 13:30:00 +0200

Je suis un développeur très orienté backend, logique interne et rarement amené à me poser des questions d’interface, néanmoins, j’ai suivi dans les grandes lignes les évolutions des technologies d’interface côté frontend d’application web. Nous sommes ainsi passé, dans le monde du web, d’applicatif fortement géré par le backend à un frontend quasi-autonome à base de beaucoup de javascript, les fameuses « Single Pages Apps » avec les frameworks tel que Vue, React, Angular ou encore Svelte.

Je ne suis pas un grand fan de configurer des interfaces et ces logiciels me font un peu peur de prime abord, il existe tout un écosystème très complexe et complet autours et je n’ai ni l’envie ni le temps d’y jeter un œil approfondi.

Une technologie va peut-être me réconcilier un peu avec les interfaces, c’est HTMX. L’idée est de convertir le plus possible de javascript en html et ainsi de compléter la logique d’hypermédia qui lui été prévu à l’origine. À propos d’hypermédia, le livre Hypermedia Systems est super intéressant.

En cherchant un peu dans HTMX, j’ai trouvé de quoi rendre ce site un peu plus interactif grâce à simplement 2 propriétés : hx-indicator et hx-boost, en rendant le changement de page un légèrement plus interactif tout en restant fonctionnel sans javascript.

Voici mes changements dans mon thème custom Hugo basé sur le thème etch :

diff --git a/themes/etch/layouts/_default/baseof.html b/themes/etch/layouts/_default/baseof.html
index 0a5d1f7..1196478 100644
--- a/themes/etch/layouts/_default/baseof.html
+++ b/themes/etch/layouts/_default/baseof.html
@@ -1,7 +1,7 @@
 <!DOCTYPE html>
 <html lang="{{ .Site.Language.Lang }}">
     {{- partial "head.html" . -}}
-    <body>
+    <body hx-boost="true"  hx-indicator="#spinner">
         {{- partial "header.html" . -}}
         <main id="content">
         {{- block "main" . }}{{- end }}
diff --git a/themes/etch/layouts/partials/head.html b/themes/etch/layouts/partials/head.html
index d6aed0c..e4e261f 100644
--- a/themes/etch/layouts/partials/head.html
+++ b/themes/etch/layouts/partials/head.html
@@ -27,6 +27,8 @@
     {{ $css := $resources | resources.Concat "css/style.css" | minify }}
     {{ printf `<link rel="stylesheet" href="%s">` $css.RelPermalink | safeHTML }}
 
+    {{ $js := (resources.Get "javascript/htmx-1.9.5.min.js") }}
+    {{ printf `<script src="%s"></script>` $js.RelPermalink | safeHTML }}
     <link rel="canonical" href="{{ .Permalink }}" />
     <title>{{ .Title }}</title>
 </head>
diff --git a/themes/etch/layouts/partials/header.html b/themes/etch/layouts/partials/header.html
index 9a66449..23a2642 100644
--- a/themes/etch/layouts/partials/header.html
+++ b/themes/etch/layouts/partials/header.html
@@ -1,4 +1,6 @@
 <header id="banner">
+    {{ $svg := resources.Get "svg/bars.svg" }}
+    <img  id="spinner" class="htmx-indicator" src="{{$svg.RelPermalink}}" alt="Updating page.."/>
     <h2><a href="{{ .Site.BaseURL }}">{{ .Site.Title }}</a></h2>
     <nav>
         <ul>

J’ai ainsi une jolie animation de chargement qui apparaît à chaque changement de page 😃.

📘 Déploiement Blog Hugo

Fri, 25 Aug 2023 18:09:50 +0200

Article original du 2023-05-06 :

Pour déployer facilement mon blog avec hugo en auto-hébergé tout en gardant le code sur gitlab, j’utilise la méthode suivante :

Un repository gitlab distant avec mon code.
Une intégration continue gitlab qui génère une archive du site : voir ici, mais qui n’est pas déployé
Un script local sur mon serveur me permettant de déployer mon site sans difficulté en modifiant le contenu d’un répertoire présenté par mon serveur web

Voici ainsi le type de script que j’ai ainsi utilisé, le principe est de récupérer le dernier artefact de gitlab et ensuite de le déployer dans le dossier /var/www/public :

#!/bin/bash

# CONFIG
ARCHIVE_PATH="/tmp/artifacts.zip"
PROJECT_NUMBER="YOURPROJECTNUMBER"
DEST_PATH="/var/www/"
GITLAB_ACCESS_TOKEN="YOURTOKEN"
GITLAB_INSTANCE="YOURINSTANCE"
BRANCH="YOUR BRANCHE"
JOB_NAME="pages"

# DEPLOY
set -e
curl --location --header "PRIVATE-TOKEN: $GITLAB_ACCESS_TOKEN" "https://$GITLAB_INSTANCE/api/v4/projects/$PROJECT_NUMBER/jobs/artifacts/$BRANCH/download?job=$JOB_NAME" --output "$ARCHIVE_PATH"
sudo rm -R "$DEST_PATH/public"
sudo unzip "$ARCHIVE_PATH" -d "$DEST_PATH"
sudo chown -R www-data:www-data "$DEST_PATH/public"
rm "$ARCHIVE_PATH"

Il suffit alors d’attendre que la CI passe et soit validé côté gitlab pour pouvoir appliquer le script. 😀

Mise à jour 2023-08-25 : J’ai amélioré le mécanisme pour le rendre automatique. Voici comment faire :

On peut aller plus loin et rendre le système automatique.

Optionel: Régénération du pipeline à intervalles réguliers, pour gérer les articles futurs ou expirés.
Ajout d’un webhook Pipeline events dans Gitlab.
Installation d’un serveur webhook pour répondre aux hooks Gitlab et lance le script bash ci-dessus.

Voici un exemple naif de configuration du serveur webhook :

[
  {
    "id": "blog_update",
    "execute-command": "/home/me/monscript.sh",
    "command-working-directory": "/home/me",
    "response-message": "redeploy blog",
    "trigger-rule": {
      "and": [
        {
          "match": {
            "type": "value",
            "value": "DONOTLEAKTHIS",
            "parameter": {
              "source": "header",
              "name": "X-Gitlab-Token"
            }
          }
        },
        {
          "match": {
            "type": "value",
            "value": "Pipeline Hook",
            "parameter": {
              "source": "header",
              "name": "X-Gitlab-Event"
            }
          }
        },
        {
          "match": {
            "type": "value",
            "value": "success",
            "parameter": {
              "source": "payload",
              "name": "builds.0.status"
            }
          }
        }
      ]
    }
  }
]

Des ajustements sont nécessaires pour gérer ça correctement et de façon sécurisée. En effet, l’utilisation d’un webhook est potentiellement dangereux, il pourrait rendre possible à un tier d’exécuter du code non voulu, il faut donc :

Empêcher au maximum la possibilité d’éditer le script.
Donner juste assez de droits pour que l’utilisateur du script soit en capacité de le lancer sans pouvoir modifier d’autres choses.
Gérer https pour ne pas faire transiter le token en clair.

Voilà si vous avez fait tout ça bien, vous pouvez pousser votre code sur Gitlab et tada, automatiquement, il sera mis à jour.

🐍 Avoir des type plus précis en Python

Sun, 13 Aug 2023 16:30:55 +0200

Introduction

En python, le typage est dynamique fort. De sorte que :

a = "super"
b = 12
c = a + b

#Traceback (most recent call last):
#  File "………………………….", line 3, in <module>
#    c = a + b
#        ~~^~~
#TypeError: can only concatenate str (not "int") to str

Python est capable à la fois de savoir que “a” est une chaine de caractères à l’exécution (typage dynamique) mais reste pour autant capable d’interdire à l’exécution certaines opérations pour des raisons d’incompatibilité de type (d’où le fort).

Il se trouve que depuis un certain nombre d’années, une nouvelle “mode” lié à des besoins de clarté et validation du code a poussé le monde python tout comme celui d’autre langage dynamique à proposer des solutions pour permettre d’être plus explicite.

En python, c’est la PEP 0484 ajoutant les « annotations de type » dans Python. Ces annotations ne changent rien à l’exécution du langage sauf que :

Elles permettent de documenter efficacement du code.
Elles peuvent être vérifiées statiquement par des outils externes tels que mypy, ou directement dans votre IDE préféré.
Elles peuvent être vérifiées dynamiquement via des librairies de validation, c’est le cas de Serpyco et de Pydantic au contraire de Marshmallow¹.

Bref, ces annotations peuvent nous rendre un fier service :

En détectant des erreurs, avant l’exécution du code.
En forçant à être plus explicite sur ce qu’on veut, si on s’oblige à les utiliser.

Avoir des types plus précis ?

Avec tout cas, vient une idée. Comment avoir des types les plus précis possible afin de limiter au maximum les bugs ? Les types en Python sont souvent avant tout une affaire de comportement, mais il arrive parfois qu’on aimerait être un peu plus strict sur ce qu’on en attend d’eux : Valider une propriété supplémentaire, clarifier une certaine sémantique.

Méthodes

1. Commentaire

La première solution consiste à utiliser les commentaires pour clarifier l’usage :

✅ Simple à utiliser et à comprendre.
✅ Utilisable pour tout : Sémantique/Contraintes à respecter
❌ aucune validation statique possible.
❌ aucune validation dynamique possible.
⚠ La coloration syntaxique ne met pas forcément très en avant la documentation.

import time

# variable:
one_minute: int = 60 # in seconds

# function:
def wait(duration: int) -> None:
    """
    :param duration: in seconds
    :return: nothing
    """
    time.sleep(duration)

2. Programmation par contrat(assert)

Une solution alternative pour définir des contraintes est la programmation par contrat, par exemple par l’usage d’assert. À noter que des solutions plus complètes existent notamment la librairie deal:

✅ Simple à utiliser et à comprendre.
✅ Utilisable pour définir des contraintes à respecter
✅ validation dynamique.
❌ pas utilisable pour ajouter de la sémantique
❌ aucune validation statique possible.
⚠ Un peu trop dissocié de la définition de la variable à mon goût.

import time

# function:
def wait(duration: int) -> None:
    assert duration > 0
    time.sleep(duration)

3. Annotated

Une solution, consiste à utiliser Annotated: Une certaine “normalisation” de cas simple existe avec, la librairie annotated_types

Il est donc possible de définir par exemple facilement si l’on veut :

✅ Utilisable pour tout : Sémantique/Contraintes à respecter, mais bien plus adapté pour des contraintes à mon avis.
❌ Très verbeux, et syntaxe redondante en cas de nombreuse utilisation.
⚠ validation statique et dynamique envisageable si usage d’une syntaxe génériquement admise².

import annotated_types
one_minute: Annotated[int, annotated_types.Gt(0)] = 60

def wait(duration: Annotated[int, annotated_types.Gt(0)]) -> None:
    time.sleep(duration)

4. Alias de type

Les alias de type sont une autre fonctionnalité envisageable :

✅ Permet facilement de simplifier un type complexe.
❌ Sémantiquement pas idéal pour définir une contrainte supplémentaire ni une distinction.
❌ L’existence de 3 syntaxes différentes rend les choses un peu confuses.
❌ validation statique et dynamique impossible :
- pas de distinction de type réelle PositiveInt = int et donc int = PositiveInt, la validation ne vérifiera rien de pertinent.
- isinstance ne fonctionne pas avec la syntaxe 3 utilisant type.

from typing import TypeAlias
# syntax 1: Implicit
PositiveInt = int
# syntax 2: Explicit
PositiveInt: TypeAlias = int
# syntax 3 (python 3.12)
# type PositiveInt = int

def wait(duration: PositiveInt) -> None:
    time.sleep(duration)

5. NewType

Pour distinguer des types, il existe NewType, une sorte de sous-classe fantôme.

✅ Pratique pour éviter de mélanger des données sémantiquement différentes, mais de même type.
✅ validation statique possible.
⚠ Nommage à faire avec précaution comme pour les sous-classes, selon le cas, il peut être pertinent de cacher ou de rendre clairement visible dans le nommage le type original. Attention à ne pas cacher le type original alors que l’utilisateur peut en avoir besoin.
⚠ Un peu complexe d’utilisation, car pas un vrai type.
❌ validation dynamique impossible (pas un vrai type, `isinstance non opérant).
❌ ne permet pas d’ajouter des contraintes.

import time
from typing import NewType

SecondsInt = NewType('SecondsInt', int)
one_minute: SecondsInt = SecondsInt(60)

def wait(duration: SecondsInt) -> None:
    time.sleep(duration)

6. Sous-classe

Une solution simple, mais efficace est tout simplement de créer des sous-classes spécifiques

✅ facile à utiliser
✅ utilisable pour à la fois de la sémantique et des contraintes de valeurs
✅ validation statique et dynamique possible
⚠ Potentiellement coûteux (vrai type)

import time

class SecondsInt(int):
    pass

one_minute: SecondsInt = SecondsInt(60)

def wait(duration: SecondsInt) -> None:
    time.sleep(duration)

Résumé

	facile à l’usage	distinction sémantique	ajout de contraintes	validation statique	validation dynamique	simple à l’oeil	usage	coût en performance nul
commentaire	✅	🆗	🆗	❌	❌	✅	clarification	✅
assertions	✅	❌	✅	❌	✅	❌	contraintes	❌
Annotated	✅	✅	✅	🆗	✅	❌	contraintes	✅
TypeAlias	❌	❌	❌	❌	❌	✅	simplification	✅
NewType	❌	✅	❌	✅	❌	✅	distinction sémantique	✅
Sous-Classe	✅	✅	✅	✅	✅	✅	Sémantique et contraintes	❌

Il n’y a pas de solution parfaite, la solution idéale peut notamment être une combinaison de solutions.

Voici quelque exemple concrêt et les solutions que j’utiliserais à ce jour:

Contrainte sur les entiers

Un cas simple est de vouloir un entier positif, une solution simple si vous utilisez pydantic pour d’autres raisons et de récupérer le type PositiveInt:

# in pydantic.types
import annotated_types
...
PositiveInt = Annotated[int, annotated_types.Gt(0)]

Notons que dans le cas de l’implémentation de pydantic ce n’est pas un NewType, donc comme il n’est pas garanti que l’analyser statique comprenne la contrainte supplémentaire, un code de la sorte peut être déclaré valide :

from pydantic.types import PositiveInt
a: PositiveInt = -12

Pydantic lui est capable de vérifier PositiveInt, mais seulement durant l’exécution du programme si on lui demande explicitement.

Un autre cas similaire que j’ai eu était de trouver une solution pour représenter la contrainte d’un type Rust dans du code python utilisant pyo3:

from annotated_types import Interval

# Unsigned Int 8
MAX_U8 = 2**8 - 1
MIN_U8 = 0
U8 = NewType("U8", Annotated[int, Interval(ge=MIN_U8, le=MAX_U8)])

Id de type existant ?

Les identifiants sont un exemple de distinction sémantique de type sans nécessairement ajout de contrainte.

L’exemple de NewType dans la documentation officielle contient cela :

UserId = NewType('UserId', int)
def get_user_name(user_id: UserId) -> str:
    ...

La fonction peut paraitre moyennement intéressante notamment par la redondance de “user_id”.

C’est intéressant si vous déplacez beaucoup une valeur sans vous soucier détail de l’implémentation du contenu. Ce qui arrive souvent avec les identifiants. En réduisant la surface de code utilisant les spécificités du type, ont s’évite l’incompréhension (“UserId est de type int ou str ?”).

Voici un exemple d’usage, que je pourrais avoir :

from dataclasses import dataclass
from pydantic.types import PositiveInt
UserId = NewType('UserId', PositiveInt)
RoomId = NewType('RoomId', PositiveInt)

@dataclass
class User:
  user_id: UserId
  name: str
  ...

@dataclass
class Room:
  room_id: RoomId
  name: str
  description: str
  ...

class HTTPRequestData:
  ...
  def get_current_user_id(self) -> UserId:
      return UserId(self['user_id'])

  def get_current_room_id(self)-> RoomId:
      return RoomId(self['room_id'])

class DB:
  ...
  def get_user(self, user_id: UserId) -> User:
      return db.query(User).sql("select * from user where id = {}", user_id)

  def get_room(self, room_id: RoomId) -> Room:
      return db.query(Room).sql("select * from room where id = {}", room_id)

Le cas des unités de mesure.

Un cas intéressant est celui des unités de mesure telle que la seconde ou encore le millimètre. Les unités de mesure ont un sens et il existe toute une logique de conversion entre elles. Ainsi des objets spécifiques, à l’aide de sous-classe semble la solution le plus adaptés. Il existe des librairies python à cet usage, tel que pint ou encore astropy, mais n’en ayant testé aucun, je ne pourrais pas vous conseiller.

Pour des cas plus simple. Les solutions que le privilégierait seraient NewType ou encore des commentaires :

import time
from typing import NewType

SecondsInt = NewType('SecondsInt', int)
one_minute: SecondsInt = SecondsInt(60)

def wait(duration: SecondsInt) -> None:
    time.sleep(duration)

wait(one_minute)

Notons que contrairement aux identifiants, dans ce cas présent, je préfère être précis sur le type pour plus de clarté.

Cela dit selon votre cas, dans le cas précis de la durée de temps, il peut être plus pertinent d’utiliser timedelta :

import time
from datetime import timedelta

one_minute: timedelta = timedelta(minutes=1)

def wait(duration: timedelta) -> None:
    time.sleep(duration.total_seconds())

wait(one_minute)

Pour Conclure

Difficile de conseiller un usage spécifique, bien que j’aime beaucoup Annotated, TypeAlias et NewType, ils ne conviennent malheureusement pas à tous les cas d’usage. Je trouve néanmoins le combo NewType/Annotated intéressant, en espérant que mypy et autre seront capable de gére les contraintes définies dans annotated_types dans un futur proche.

Quant À TypeAlias, je reste plus que mitigé sur les cas d’usage pertinent :

Si Le nom de type est trop court, l’intérêt est nul.
Si on commence à utiliser des types complexes tel que Dict[str, Union[int, float, str]], ne faudrait-il pas considérer sérieusement utiliser un type spécifique, un objet spécifique, ou peut-être un TypedDict ?

Allez plus loin :

Quelques ressources intéressantes sur le sujet que j’ai consulté :

https://justincaustin.com/blog/python-typing-newtype/ : Sur la différence NewType/TypeAlias.
https://www.agest.am/phantom-types-in-python : Parle notamment de la librairie phantom-types qui propose un mécanisme de contrainte avec des types “fantômes”.

Marshmallow est une librairie plus ancienne que l’instauration des annotations de type en Python, elle n’a pas pu utiliser cette syntaxe ↩︎
https://github.com/annotated-types/annotated-types/issues/33 ↩︎

📄 Comparaison visuelle de page web

Mon, 24 Jul 2023 13:05:10 +0200

Une petite astuce utilisée lors de certains développements où je devais « debugger » l’apparence d’un front un peu complexe :

Obtenir une image de la page dans son entièreté, firefox à la capacité de le faire naturellement au clic-droit.
Utiliser imagemagick pour faire un différentiel visuel des deux images.

Cette méthode peut paraître un peu « lourde », mais permet de tester ce qui importe vraiment : le rendu.

Aller plus loin

Un autre outil de comparaison intéressant à envisager pour des cas un peu différent (moins visuel et besoin d’exactitude sur les fichiers rendu) est diffoscope.

🗂 Tirer parti de la déduplication de BTRFS: cas concret du versionnage

Sun, 23 Jul 2023 11:47:32 +0200

Le problème

Il m’est arrivé à plusieurs reprises de travailler sur des projets utilisant la librairie python filedepot, cette librairie est bien pratique pour gérer le stockage de fichier notamment en combinaison avec Sqlalchemy.

Un point qui ne reste néanmoins pas forcément évident à gérer par-dessus ce type de librairie est la question du versionnage. Un cas que j’ai eu l’occasion de voir est le versionnage dans Tracim ou un contenu à diverse révision qui peuvent ou non avoir un contenu fichier associé différent.

Le fonctionnement du champ UploadedFileField proposé pour Sqlalchemy par filedepot, fonctionne de sorte à considérer que le fichier est liée uniquement à une ligne de base de donnée et il peut être compliqué de tenter de partage un identifiant d’un même fichier entre divers contenus, car par exemple, la suppression d’une ligne avec le contenu 1 supprimera le fichier associé, 2 pointant vers le même contenu ne pourra plus y accéder.

Comment alors éviter que pour une modification mineure non liée au fichier, que le fichier soit dupliqué inutilement consommant ainsi de l’espace inutilement ?

Je vois alors plusieurs approches :

Mettre cette intelligence de « versionnage » dans filedepot, mais cela demanderait un gros travail.
Mettre cette intelligence de « versionnage » dans l’application qui utilise filedepot notamment une table association entre l’identifiant du fichier pour l’application et le champ. Ce qui réduirait un peu l’intérêt simplificateur de filedepot à mon sens.
Créer une sorte de couche intermédiaire d’intelligence entre filedepot qui gère cela. Cela pourrait être aussi l’occasion de gérer d’autres features lié au traitement du fichier : indexation, génération de preview, …

Si la troisième solution me semble la plus intéressante a creusé, elle demande du temps à mettre en place.

Ayant envie de gagner un peu d’espace disponible sur mon serveur utilisant Tracim, j’ai trouvé une solution de contournement à partir du fait que btrfs supporte la fonctionnalité de déduplication.

La Déduplication Quézako ?

La déduplication est une fonctionnalité de système de fichier qui permet à un système de fichier de dire qu’un certain contenu utilisé par plusieurs fichiers est au même endroit. Ainsi, il est possible de copier via cp --reflink=always sans utiliser d’espace supplémentaire (sauf quelques meta-données). Seul certain système de fichier supporte cette fonctionnalité dont BTRFS.

À noter que cette fonctionnalité est activé par default dans cp quand c’est possible à partir de coreutils-9.0. Ainsi, si vous utilisez un simple cp dans un Gnu/Linux assez récent et utilisé un système de fichier comme btrfs, votre copie sera gérer automatiquement intelligemment sans réelle copie.

Revenons à nos moutons

Mais du coup, qu’est-ce que ça change pour nous ? Parce qu’on pourrait effectivement ajuster filedepot pour faire de la copie via reflink, mais il faudrait pour cela… Qu’il soit conscient qu’il réalise une copie. Et donc on retombe dans une problématique de développement plus ou moins complexe…

Oui … Sauf qu’il y a une astuce !

Il est possible de réaliser la déduplication a posteriori, quand on considère que c’est nécessaire grâce à un outil comme Duperemove. Ainsi, il m’est possible de récupérer de l’espace disque sans avoir à me soucier de l’optimalité ou non des solutions techniques de stockage utilisé par le logiciel utilisé.

L’autre grosse force est que cela fonctionne pour tous les fichiers sans la moindre distinction. Ainsi peu importe si la duplication est le fait d’un utilisateur qui aurait copié 2 fois le même fichier, d’un mécanisme de versionnage non intelligent, ou simplement le hasard de 2 utilisateurs qui ne se connaissent même pas qui téléverse l’exacte, même contenu, la déduplication s’effectuera.

Voici un exemple, Avec un tracim 4.5 tout neuf en conteneur et son contenu dans un système btrfs tout propre dans un fichier (grâce à ce commentaire) :

Ajout d’un 1 fichier un peu gros sur l’instance :

df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0        10G  219M  9,3G   3% /mnt/dsk

Création de 2 nouvelles révisions sans vraie modification du fichier :

Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0        10G  639M  8,9G   7% /mnt/dsk

Let’s go la déduplication (en utilisant l’exemple de https://wiki.tnonline.net/w/Btrfs/Deduplication/Duperemove):

root@gnu:/mnt/dsk# chrt -i 0 duperemove -A -h -d -r -v -b128k --dedupe-options=noblock,same --lookup-extents=yes --io-threads=1 var/data/depot 
Using 128K blocks
Using hash: murmur3
Gathering file list...
Skipping small file /mnt/dsk/var/data/depot/2031c9c0-076e-11ee-9c12-0242ac110002/file
Skipping small file /mnt/dsk/var/data/depot/2031c9c0-076e-11ee-9c12-0242ac110002/metadata.json
Skipping small file /mnt/dsk/var/data/depot/2032025a-076e-11ee-9c12-0242ac110002/file
Skipping small file /mnt/dsk/var/data/depot/2032025a-076e-11ee-9c12-0242ac110002/metadata.json
Skipping small file /mnt/dsk/var/data/depot/cb00f218-076e-11ee-a461-0242ac110002/file
Skipping small file /mnt/dsk/var/data/depot/cb00f218-076e-11ee-a461-0242ac110002/metadata.json
Skipping small file /mnt/dsk/var/data/depot/cb0142b8-076e-11ee-a461-0242ac110002/file
Skipping small file /mnt/dsk/var/data/depot/cb0142b8-076e-11ee-a461-0242ac110002/metadata.json
Skipping small file /mnt/dsk/var/data/depot/e89f0f58-076e-11ee-827e-0242ac110002/metadata.json
Skipping small file /mnt/dsk/var/data/depot/0f1a60a6-076f-11ee-a200-0242ac110002/metadata.json
Skipping small file /mnt/dsk/var/data/depot/55639ca8-076f-11ee-a315-0242ac110002/metadata.json
Using 1 threads for file hashing phase
[1/3] (33.33%) csum: /mnt/dsk/var/data/depot/e89f0f58-076e-11ee-827e-0242ac110002/file
[2/3] (66.67%) csum: /mnt/dsk/var/data/depot/0f1a60a6-076f-11ee-a200-0242ac110002/file
[3/3] (100.00%) csum: /mnt/dsk/var/data/depot/55639ca8-076f-11ee-a315-0242ac110002/file
Total files:  3
Total extent hashes: 3
Loading only duplicated hashes from hashfile.
Found 3 identical extents.
Simple read and compare of file data found 1 instances of extents that might benefit from deduplication.
Showing 3 identical extents of length 209.8M with id 54f11aa1
Start		Filename
0.0	"/mnt/dsk/var/data/depot/e89f0f58-076e-11ee-827e-0242ac110002/file"
0.0	"/mnt/dsk/var/data/depot/0f1a60a6-076f-11ee-a200-0242ac110002/file"
0.0	"/mnt/dsk/var/data/depot/55639ca8-076f-11ee-a315-0242ac110002/file"
Using 1 threads for dedupe phase
[0x56351b1f30c0] (1/1) Try to dedupe extents with id 54f11aa1
[0x56351b1f30c0] Add extent for file "/mnt/dsk/var/data/depot/e89f0f58-076e-11ee-827e-0242ac110002/file" at offset 0.0 (3)
[0x56351b1f30c0] Add extent for file "/mnt/dsk/var/data/depot/0f1a60a6-076f-11ee-a200-0242ac110002/file" at offset 0.0 (4)
[0x56351b1f30c0] Add extent for file "/mnt/dsk/var/data/depot/55639ca8-076f-11ee-a315-0242ac110002/file" at offset 0.0 (5)
[0x56351b1f30c0] Dedupe 2 extents (id: 54f11aa1) with target: (0.0, 209.8M), "/mnt/dsk/var/data/depot/e89f0f58-076e-11ee-827e-0242ac110002/file"
Kernel processed data (excludes target files): 419.5M
Comparison of extent info shows a net change in shared extents of: 629.3M

Après deduplication :

df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0        10G  219M  9,3G   3% /mnt/dsk

On a ainsi gagné pas moins de 419.5M !

Autres points intéressant de Duperemove:

Vous n’utilisez pas btrfs ou voulez avoir une idée de l’espace gagné, il est possible de lancer duperemove en mode détection seulement.
Changer la taille des blocs (-b) permet de prendre en compte les fichiers plus petit, par exemple les preview dans le cas de Tracim.
Duperemove permet d’utiliser un hashfile qui évite de devoir recalculer les fichiers déjà lus, attention néanmoins à la taille du hashfile.

Aller plus loin…

La solution Duperemove se conjugue bien avec le fonctionnement de Tracim, mais comment peut-on faire autrement ? Quelles solutions les autres logiciels utilisent pour conserver un historique sans surcharger les disques ?

Nextcloud : De ce que je comprends de l’approche de nextcloud sur ce genre de problématique, elle consiste à tenter de réduire le nombre de versions sauvegardées ainsi le versionnage de nextcloud n’est à ce sens pas très fiable dans une logique d’archivage, une approche hybride à base de version par etiquette pour une gestion semi-automatique associé ou non ne sorte d’IA ou d’algorithme un peu malin pourrait faire l’affaire afin de limiter les versions stockée tout en gardant l’essentiel de l’historique.

Gestion de version : L’approche des logiciels de gestion de versions comme git est intéressante et est clairement optimale en espace de stockage pour du fichier texte. Elle permet réellement de l’archivage, de plus le principe de pouvoir associer un texte à une modification commit, permet de s’y retrouvé facilement. Néanmoins l’approche ne se conjugue pas très bien avec du stockage de fichier binaire.

Voili Voilà ! 😀

🌈 Quelques Astuces de dessins

Sun, 23 Jul 2023 10:38:43 +0200

J’aime beaucoup dessiner au crayon de couleurs. Voici quelques petites de mes astuces.

timelapse d’un dessin de crabe

Osez mélanger les outils (médiums)

Mélanger les outils de dessin peut s’avérer très bénéfique pour réussir au mieux à réaliser ce que vous souhaitez. Ainsi pour ma part :

J’aime beaucoup le crayon de couleurs pour faire les détails.
J’aime beaucoup l’aquarelle ou les outils aquarellables pour faire des fonds ou gérer des aplats non-uniforme.
Pour redonner de la lumière en crayon de couleurs plusieurs options :
- Pour une lumière légère, le crayon de couleurs blanc est votre ami.
- Pour un « sauvetage » de dessin, il faut mettre les grands moyens : blanco ou feutre blanc bien opaque (par exemple: posca).
Pourquoi pas des paillettes ? Le crayon graphite peut donner un effet réfléchissant métallique à votre dessin.

Les soins intensifs, ça paye !

N’étant pas super soigneux, il m’arrive bien souvent de rater des choses dans mes dessins. Il faut toujours donner une seconde chance à son dessin (ou du moins tenter), faire preuve d’un peu d’inventivité pour contourner le problème obtenu.

J’ai ainsi sauvé nombre de créations.

Certains médiums pardonnent plus que d’autres, je vous conseille d’utiliser les outils les plus adaptés à votre capacité à être soigneux et précis.

Paradoxalement, il est souvent conseillé de s’entrainer sur des outils qui ne pardonnent pas pour apprendre à être juste, mais c’est un autre sujet.

dessin de désert avec cactus au crayon de couleur sur fond noir

Jouer avec les modèles, Utilisez les comme tuteur

Il est bien plus facile de dessiner quelque-chose d’après modèle que de tête, néanmoins on ne veut pas toujours reproduire, ainsi, une astuce intéressante est tout simplement de prendre un modèle comme tuteur, rien ne vous interdit de changer les couleurs, le fond, ainsi que certaines formes (changer un visage, un vêtement, etc.) de votre modèle lors de votre dessin.

Vous pouvez aussi faire une sorte de collage, en prenant des reference à droite et à gauche et en les insérant dans vos scènes.

Enfin dans ce même ordre d’idée, une astuce que j’ai découverte grâce à David Revoy, est le fait qu’il est aussi possible de s’appuyer sur un rendu 3D pour avoir les bonnes proportions et perspectives, alors certes, je suis encore moins bon en rendu 3D qu’en dessin mais :

Réaliser des objets simples sur Blender en quelques clics de souris peut être suffisant dans bien des cas pour me servir de modèle.
Les rendus 3D sont bien plus facilement accessible aujourd’hui, quelques pistes :
- Les jeux vidéos. Pourquoi pas des captures d’écran de Minecraft ?
- Les logiciels d’aménagement d’intérieur : Qui a dit Sweet Home 3D ?
- La photogrammétrie est aujourd’hui accessible à tout le monde ou presque, plus besoin de créer des modèles, s’il existe en réalité!¹.
- Les fichiers 3D existants, on en trouve pléthore sur le net. Côté paysage, il a des données topographiques qu’il est possible de convertir ou d’obtenir sous forme de modèle 3D².
Ce n’est qu’un principe général, ne vous limitez pas dans vos types de modèle ni dans leur usage.

Bref un modèle n’est pas forcément un rendu final à réaliser, ça peut être aussi bien un elements d’aide à la création, une sorte de tuteur.

Escargot

Jouer avec le hasard et le chaos pour l’inspiration

Une source intéressante peut être d’utiliser le hasard ou du moins des procédés un peu chaotiques à l’image de Jackson Pollock. C’est l’idée derrière le logiciel Alchemy.

Le plus facile d’accès en opensource semble Meshroom. L’IGN possède sa propre suite en opensource, mais cela reste moins simple d’accès. ↩︎
L’IGN passe la France au Lidar, c’est une nouvelle source de modèles 3D qui pourrait s’avérer très intéressante. ↩︎

📷 Mon process de gestion des photos

Sat, 22 Jul 2023 22:37:40 +0200

Introduction

J’aime beaucoup prendre des photos, néanmoins, il n’est pas toujours aisé de gérés ces données ensuite. En plus de 10 ans de photographie numérique, j’ai fait évoluer de nombreuses fois mon flux de travail afin de rendre celui-ci le plus fiable et efficace.

Mer Adriatique, 2011

L’épineux problème des sauvegardes en voyage

Perdre ses photos est une expérience qui peut être douloureuse. Elle m’est arrivé une fois en pleine mer adriatique, avec une carte SD m’ayant lâché à bord d’un ferry. J’ai donc par la suite évalué/testé plusieurs solutions :

Carte SD plus fiable ? Je ne connais pas l’évolution des procédés technique, mais je m’attache à prendre des modèles un minimum qualitatif, Samsung vendait pendant un temps des cartes SD se prétendant plus résistantes.
Multiplications des cartes SD : j’ai pendant un long moment utilisé un nombre important de cartes de petite taille afin de minimiser le nombre de données perdu en cas de problème. Le coût des cartes micro-SD de grande capacité étant devenue ridiculement bon marché depuis lors, je n’ai pas continué cette méthode.
Multiplication des appareils : involontairement depuis je suis passé à un fonctionnement à deux appareils photos, permettant facilement d’alterner des optiques sans risquer trop de problèmes de poussières sur le capteur. Deux appareils signifiant donc 2 cartes SD distinctes.
Une sauvegarde sur l’appareil photo-même ? Certain modèle d’appareil haut de gamme permettent effectivement la possibilité de mettre plusieurs cartes, néanmoins je n’ai pas le budget.
Une Copie intermédiaire ? La solution la plus prometteuse étant d’avoir un dispositif de copie intermédiaire, il y a différentes options ;
- un ordinateur portable : un peu volumineux, mais si vous en avez besoin, c’est le plus simple. On peut coupler ça facilement avec un logiciel pour synchro style phockup (voir plus bas).
- une carte type raspberry-pi avec un programme fait à cet effet, litte-backup-box propose une solution intéressante.
- via son smartphone ? Une dernière piste a creusé serait une copie sur smartphone. Il faut un adaptateur usb, reste à savoir quels outils sont possibles pour la copie/synchro ?

Myrdal, 2014

Sauvegarde long-terme.

Ayant pu quelque-peu mitigé les questions des sauvegardes en voyage, il reste la question du stockage à plus long-terme.

J’ai volontairement abandonné :

les solutions à base de copie sur le cloud pour des raisons de confiance
les solutions de sauvegarde en mode synchronisation bidirectionnelle comme syncthing. Légèrement complexe et avec une gestion des conflits souvent un peu auto-magique.¹
Les solutions à base d’instantané². Aussi un peu complexe.

J’ai ainsi préféré un modèle très linéaire et simple avec des copies pleine et entière.

Ma stratégie est devenue la suivante, une partie du processus n’est pas spécifique aux photos :

Stockage des photos via l’appareil sur de grandes cartes micro-sd (avec adaptateur) dont le contenu n’est formaté que quand c’est vraiment nécessaire (ça fait une copie de plus au cas où).
Stockage primaire sur un NAS avec RAID 1 logiciel sans chiffrement sur la partie photos, car je préfère m’éviter de m’arracher les cheveux si quelque-chose se passe mal là-dessus, cela dit selon la sensibilité du contenu, la réflexion pourrait être amenée à changer.
disque de sauvegarde primaire stockée à proximité du NAS
disques de sauvegardes secondaires avec dernière date de synchro noté et stocké à plusieurs endroits géographique (oui, je suis parano).

Quant aux étapes de synchronisations :

Synchronisation depuis les cartes SD vers le NAS via le logiciel phockup (voir plus loin).
Synchronisation entre le NAS et le disque de sauvegarde primaire via rsync.
Synchronisation entre la sauvegarde primaire et les sauvegardes secondaires via une baie de disque avec duplicateur de disques : l’intérêt principal étant de ne pas avoir besoin d’ordinateur, “on lance et on oublie”.

Champ de lin, Noir et blanc, 2015

Ajout des photos automatisé

Pour la synchro de photos sur mon nas, ayant décidé de ne plus vider systématiquement les cartes SD, j’avais du coup besoin d’une solution pour gérer plus facilement l’ajout des photos dans mon album sans copie, la solution s’appelle phockup.

Mon NAS ayant directement un port pour carte micro-sd, je peux synchroniser de cette façon :

sudo mount /dev/mmcblk1p1  /mnt/sdcard/
phockup /mnt/sdcard/DCIM/ /home/inkey/Images/Photos/ -y # passage sans changement ou «dry-run»
phockup /mnt/sdcard/DCIM/ /home/inkey/Images/Photos/
sudo umount /dev/mmcblk1p1

Je n’ai (à l’époque de cet article) pas poussé l’automatisation jusqu’à lancer automatiquement phockup à la connexion de la carte, mais cela est possible. Il faudrait creuser un peu les possibilités de systemd³.

Accéder et modifié les photos ?

Mon NAS étant ainsi la « source de vérité », il me faut un moyen de pouvoir aisément travailler dessus. Une solution simple est tout simplement sshfs, ce n’est pas le protocole le plus performant, mais combiné avec le mécanisme de copie-locale de darktable cela fonctionne plutôt bien.

Le type d’entrée fstab que j’utilise :

sshfs#me@mydomain.tld:/home/me/myphotofolder     /home/me/myphotofolder          fuse            port=22,user,noauto,noatime,_netdev     0 0

Renne du Père-Noël, 2022

Méthode de tri des photos

Trier mes plus de 36000 photos s’avère une tâche de prime abord, difficile. Je fais beaucoup de photos et il m’arrive parfois de revenir sur d’anciennes photos et d’y voir un potentiel jusqu’alors non-déceler. Ainsi dans mon processus, je ne supprime les photos que quand j’ai une vraie certitude qu’elles ont ratée, n’ayant pas de problème d’espace, je conserve ainsi un grand nombre de photos peu intéressant, mais elle reste trié par niveau de qualité. J’utilise Darktable pour réaliser ce traitement.

: Les différentes notations de Darktable : rejeté, sans étoile, 1 à 5 étoiles.

Ma stratégie de tri est une sorte d’algorithme. Il faut se donner un vague critère pour chaque passage à une étoile supérieure ensuite :

on trie tout et on marque les images comme rejetés.
on trie les images non rejetées et on marque la 1ére étoile.
on trie les images de la 1ére étoile et on marque la 2de étoile.
on trie les images de la seconde étoile et on marque la 3ᵉ étoile.
… idem jusqu’à la 5ᵉ étoile.

Un cas à décider un peu particulier est celui des images trop similaires, il faut décider à quel niveau on prend la décision de ne plus les classer et choisir la meilleure par comparaisons. Darktable permettant facilement de comparer 2 ou 3 images facilement.

Soirée à Thamel, 2016

Pour gérer des modifications bidirectionnelles, je préfère unison, qui oblige à être explicite. ↩︎
ou snapshot, voir ici ↩︎
Edit (Février 2024): L’automatisation est chose faite, lire cet article plus récent, ↩︎

💚 Pourquoi j'aime l'Ésperanto… | 💚 Kial mi ŝatas Esperanton…

Sat, 22 Jul 2023 12:09:43 +0200

J’apprends comme passe-temps la langue Éspéranto via Duolingo, c’est une langue étrange :

construite par Louis-Lazare Zamenhof en 1887.
mélange de plusieurs langues tout en ayant ses propres particularités
voulu comme une langue internationale dès le début.

Elle est très simple :

Une lettre = un son.
Des règles simples.
Un fonctionnement extrêmement logique.

Ce qui est amusant d’un point de vue d’ingénieur, c’est de voir les compromis fait par la langue, ainsi certains mots ont été pioché dans diverses langues avec des choix parfois difficile, entre simplicité et expressivité.

Une chose réellement étonnante est l’expressivité possible dans le langage son caractère très logique permet bien plus facilement que dans la plupart des langues de jouer avec les mots, de comprendre toute ou partie du sens d’un nouveau mot et bien d’autres choses tout étant peu expérimenté dans le langage. Pour ma part, cela fait, à l’heure de cet article, à peine trois mois que j’apprends l’Esperanto de façon non intensive et j’ai déjà l’impression d’une certaine maîtrise.

Les seuls points que je trouve légèrement compliqué en tant que Français au début sont :

La marque de l’accusatif que j’ai toujours un peu de mal
Les corrélatifs et tous les petits mots qu’il ne m’est pas possible de deviner.
Les cas ou l’Esperanto est plus précis que le français et donc ou il n’est pas facile de savoir quand/pourquoi utiliser les mots, tel quel les participes.

Le reste, étant vraiment simple, il faut pratiquer un peu et apprendre du vocabulaire. Comme dise les Anglais « practice makes perfect » ou plutôt dans notre cas « ekzercado lertigas ».

Si vous voulez apprendre l’Esperanto en ligne, je vous conseille Duolingo et Lernu.

Gîs la revido ! 👋

🎮 Créer un jeu de Morpion en ligne : partie 1. Mécanique de Jeu et Rust

Fri, 21 Jul 2023 13:05:10 +0200

Introduction

Dans le but d’apprendre le rust et d’autres technologies en m’amusant. J’ai décidé de commencer un projet de jeux de morpion en rust.

À l’instar des générateurs d’avatars, c’est un projet d’exploration qui ne va pas droit au but, mais sert de fil conducteurs à divers problèmes et technologie que j’ai envie de tester dans des cas un minimum réels.

Les règles du jeu :

Si les jeux de base du Gomoku se fait sur un pavage de 15x15 elements et le gagnant gagne lors d’un 5 à la suite, j’envisage que les briques de mon jeu puissent me permettre un peu de souplesse :

Nombre de joueurs possible entre 2 et 10.
Taille du plateau variable.
Nombre de coups pour gagner variable.

D’autres évolutions sont envisageables :

variante avec besoin de n fois la suite pour gagner, peut-être jusqu’à que la grille soit complête ?
variante sans gestion de tours.
etc…

Poc Rust:

Pour mon projet, mon idée est de pouvoir me baser sur des 🧱 briques assez génériques pour pouvoir implémenter plein de variantes facilement.

J’ai ainsi réalisé 2 classes de base :

MorpionBoard : le plateau de jeu qui:
- garde le plateau en mémoire.
- contrôle la validité des coups.
- calcule si le jeu est gagné.
Turn : Une surcouche d’un vecteur permettant d’itérer sur les identifiants de joueurs en boucle.

J’ai aussi pas mal joué avec les traits et la généricité de Rust, c’est super agréable d’avoir autant de liberté là-dessus, reste à savoir jusqu’où pousser le curseur, en particulier dans un projet perso. On a vite fait de vouloir rendre tout générique sans cas d’usage pertinent derrière.

Vérifier la victoire ?

Il existe divers moyens de vérifier la victoire pour un tel jeu, mais j’ai trouvé une optimisation particulièrement efficace, je cherche les segments de n éléments contenant la dernière position jouée, ainsi, je limite ainsi énormément l’espace parcouru :

Je les cherche donc pour chaque direction¹ :

    pub(super) fn check_win(&self, position: Dimension, winning_row_length: u8) -> bool {
        self.check_win_direction(position, HORIZONTAL, winning_row_length)
            || self.check_win_direction(position, VERTICAL, winning_row_length)
            || self.check_win_direction(position, DIAG_UP, winning_row_length)
            || self.check_win_direction(position, DIAG_DOWN, winning_row_length)
    }

Et je cherche pour chaque sens de ces directions le nombre d’éléments consécutifs, auquel j’ajoute l’élément d’origine.

fn count_consecutive_in_direction(&self, position: Dimension, direction: Direction) -> u8 {
    let res = self.count_consecutive_in_way(position, direction.0)
        + self.count_consecutive_in_way(position, direction.1)
        + 1;

Ainsi si j’obtiens pour une direction, une longueur égale ou supérieure à la valeur pour gagner, je sais donc que le dernier coup a été gagnant.

Ce mécanisme est très efficace.

Tentative de parallélisme

Par ailleurs, pour m’amuser², j’ai tenté d’aller encore plus loin à l’aide des scoped threads de Rust. L’idée est de séparer le travail en plusieurs tâches réalisé séparément, si possible en parallèle grâce à l’existence de plusieurs cœurs sur la machine :

    pub(super) fn check_win_multiple_core(&self, position: Dimension, winning_row_length: u8) -> bool {
        let (mut h,mut v,mut du,mut dd) = (false,false,false,false);
        thread::scope(|s| {
            s.spawn(|| {
                h = self.check_win_direction(position, HORIZONTAL, winning_row_length);
            });
            s.spawn(|| {
                v = self.check_win_direction(position, VERTICAL, winning_row_length);
            });
            s.spawn(|| {
                du = self.check_win_direction(position, DIAG_UP, winning_row_length);
            });
            s.spawn(|| {
                dd = self.check_win_direction(position, DIAG_DOWN, winning_row_length);
            });
        });
        h || v || du || dd
    }

Mais il s’avère que cette solution qui divise le travail en 4 calculs n’est pas optimal du tout. Après un test rapide avec criterion, le temps explose (ça reste très court cependant).

En effet, le coût de création des threads est beaucoup trop grand par rapport au coût du parcours de quelques éléments dans chaque direction. Pour que ça soit intéressant, il faudrait donc beaucoup plus d’éléments à parcourir d’une part, mais probablement aussi de quoi pouvoir arrêter les threads dès que l’un d’entre a fini le travail, une sorte de « ou optimisé en multicœur » en quelque-sorte.

La mécanique de scoped threads reste néanmoins super intéressante et facile à mettre en place, il me manque juste une bonne raison de l’utiliser.

Gestion des chaînes de caractères

La gestion des chaînes de caractères en rust s’avère un peu difficile provenant du python. Il est ainsi impossible d’avoir des constantes facilement pour le modèle du format des chaînes avec la macro println! car le 1er paramètre est nécessairement une valeur littérale :

const mon_text: &str = "🌷";
const pattern: &str = "--{}--";
fn main() {
    println!("--{}--", "🍓"); // --🍓--
    println!("--{}--", mon_text); // --🌷--
    println!(pattern, mon_text); // error: format argument must be a string literal
}

Je ne trouve pas cela super souple. Après un peu de recherche, j’ai finalement contourné pour partie le problème avec une solution, plus complexe, mais plus générique : l’internationalisation via fluent, avec les packages i18n-embed et i18n-embed-fl ainsi un peu de code, on peut arriver à faire des choses comme ça :

/i18n/fr/morpion.ftl:

game-title = Jeu de Morpion
user-turn = Tour du joueur {$name} utilisant le symbole '{$p_char}':

/i18n/eo/morpion.ftl:

game-title = Ludo de Morpion
user-turn = Vico de la ludanto {$name} kun la simbolo '{$p_char}':

/src/main.rs:

println!("{}", fl!("game-title"));
println!(
    "{}",
    fl!(
        "user-turn",
        name = players_data.names[&player_id],
        p_char = format!("{}", players_data.symbols[&player_id])
    )
);

Ce n’est pas encore parfait (je n’aime pas trop les « {} »), mais c’est déjà plus pratique, et j’ai obtenu, d’une pierre, deux coups :

un mécanisme assez souple pour gérer des chaînes de caractères permettant de séparer un peu le code des jeux, du texte utilisé dans le jeu.
la possibilité de gérer différentes langues. Dans mon cas, le français, l’espéranto et l’anglais.

Interface CLI

La première version du projet est toute simple en ligne de commande³ :

À suivre…

attention, je parle là bien de la direction, pas du sens. ↩︎
Si vous êtes sur des choses un peu sérieuses, éviter ce genre d’approche d’optimisation préventive, c’est la meilleure façon de perdre du temps sans gagner en performance. Les optimisations sont un sujet sérieux qui doit être réfléchis. ↩︎
C’est une logique de développement que j’ai déjà utilisé pour mon vieux jeu de serpent 🐍 où j’ai d’abord réalisé une version ligne de commande peu interactive puis une version ncurse et enfin une version pygame. Le but étant d’apprendre séparément la mécanique de jeu et la question du moteur. Si vous envisagez de faire des jeux un peu plus sérieux, je ne peux que vous conseiller d’utiliser un vrai moteur, tel que Godot. ↩︎

🐦 Mes Générateurs d'avatars

Fri, 21 Jul 2023 13:05:10 +0200

David Revoy, Génial illustrateur de Peeper and Carrot, a lancé avec cet article une flopée d’implémentations de générateurs d’avatars dans divers langages.

J’ai pour ma part réalisé deux implémentations :

Pioupiou, langage Python en 2021.
Roucoule, langage Rust en 2023.
…¹

Le principe de ce type de génération d’avatar en mode “sandwich”🥪 est très simple :

vous donnez une chaîne de caractère en entrée.
le programme va décider pour chaque couche de l’avatar quel “ingrédient” prendre à partir de la chaîne donnée.
- les couches correspondront à des éléments de l’image qui seront ensuite appliqué les un sur les autres afin de générer un avatar pseudo-aléatoire².

L’intérêt de ces projets pour moi est multiple :

Apprendre plus sur les spécificités du langage.
Apprendre à faire une librairie “propre” en mode “état de l’art” en matière d’outillage : packaging, CI, linting, etc.
Servir de point de repère “bonne pratique” pour les prochains projets notamment, car cela reste des projets assez petits.

N’hésitez pas à utiliser ces librairies/y jetez un coup d’œil ! 😀

Une implémentation en Elixir me plairait bien pour apprendre ce langage. ↩︎
le nombre de résultats possible étant restreint et l’algorithme volontairement déterministe pour une entrée donnée, ce n’est pas du vrai hasard. ↩︎

👨‍💻 Quelques utilitaires Gnu/Linux pratiques

Mon, 01 May 2023 16:25:45 +0200

Voici quelques utilitaires linux bien pratiques que je me permets de vous présenter brièvement.

SFTP

Compris avec ssh, je trouve sftp particulièrement pratique pour déplacer des fichiers rapidement, l’idée est la suivante :

Vous initiez une session sur la machine hôte depuis un répertoire A
Vous vous déplacez jusqu’à un répertoire B à l’aide de cd dans la session sftp interactive
Vous utilisez une des différentes commandes disponibles, les plus communes étant
- put pour envoyer depuis A vers B
- get pour récupérer depuis B vers A
il est aussi possible de modifier le répertoire local A à l’aide de lls et de lcd.

Bien évidemment l’autocomplétion fonctionne, ce qui permet de déplacer efficacement des fichiers à la fois sans devoir se prendre la tête sur la connaissance des chemins et sans interface graphique.

Htop

On ne le présente plus, un bon moniteur de processus, avec des fonctionnalités de filtrage bien pratique.

IP

Classique de chez classique, pour récupérer les addresses IP de la machine sans se faire déborder d’informations, j’utilise ces paramètres la plupart du temps pour ip (paquet debian iproute2):

root@867aa82abc92:/# ip -br -c a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
tap0             UNKNOWN        10.0.2.100/24 fe80::4c28:c3ff:fe98:5b16/64

Xkill

Pour X11 seulement, je ne sais trop ce qu’il en est sur Wayland. La commande xkill peut s’avérer utile pour tuer une fenêtre gelée via la souris en transformant le pointeur en une sorte de fusil pour processus.😀

🕸 Tracim sur mon NAS, partie 3: Frontal Nginx

Sun, 30 Apr 2023 18:30:23 +0200

Introduction

Le service tracim tourne, mais n’est pas accessible. En effet, lors de la dernière configuration, nous avons opté pour l’accessibilité que localement sur la machine sur le port 7070. De plus, pour une raison de sécurité, il nous faut un accès en https.

Exemple de configuration nginx frontal pour l’image docker de tracim :

Voici un exemple de ce à quoi peut ressembler un reverse-proxy pour Tracim dans nginx, à noter quelques points :

j’ai volontairement mis la configuration ssl utilisé dans un fichier common.conf à part.
Vous devez bien évidemment ajuster la configuration dns comme il faut pour que votre nom de domaine pointe sur le serveur.
j’ai activé http2 et l’ipv6 sur la partie nginx-internet, notez cependant que le canal tracim-nginx est en http 1.1 sans ssl et que le buffering du proxy est désactivé, car il produit des dysfonctionnements (utilisation des SSE par Tracim).

/etc/nginx/site-available/tracim :

upstream tracim_local{
    server 127.0.0.1:7070;
}
server {
  listen 443 http2 ssl;
  listen [::]:443 http2 ssl;
  server_name mysuperwebsite.net;
  include common.conf;
  location / {
    client_max_body_size 300M;
    include proxy_params;
    proxy_pass http://tracim_local;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
  }
}

/etc/nginx/proxy_params:

proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Exemple minimal de /etc/nginx/common.conf

Pour la configuration Nginx du ssl, je vous conseille de la tester.

ssl_certificate /path/vers/moncertif/mysuperwebsite.net/fullchain.pem;
ssl_certificate_key /path/vers/moncertif/mysuperwebsite.net/key.pem;

## Je vous conseille de vous intéresser aux autres paramètrages de ssl de nginx
## ainsi qu'au HTTP Strict Transport Security

Pour la génération des certificats, une solution simple si vous n’avez pas de contrainte complexe est d’utiliser Let’s Encrypt en mode DNS. Je le conseille avec ACME.sh.

Activation et utilisation de tracim

Si tout est ok, vous pouvez maintenant activer votre reverse-proxy:

sudo ln -s /etc/nginx/sites-available/tracim /etc/nginx/sites-enabled/tracim
nginx -t
sudo systemctl nginx reload

Et voilà ! un Tracim fonctionnel via Nginx et Podman !

🥳

🕸 Tracim sur mon NAS, partie 2: Service Systemd pour conteneur Podman

Sun, 30 Apr 2023 18:30:22 +0200

Introduction

Lors des précédents articles, je couvrais le fait de générer une image conteneur pour Tracim, les images sont prêts, il est temps de les utilisés !

Mise en route de l’image avec Podman et Systemd

Pour ce faire, je prépare la commande pour lancer le conteneur Tracim avec les bons paramètres, pour le cas d’une configuration très minimal, il est possible de faire comme dans le script donné ci-dessous.

A notez:

c’est un conteneur en mode utilisateur, il ne demande pas de droits super-utilisateur afin de limiter les risques de sécurité.
C’est une configuration Tracim très basique, qui ne tire par profit du plein potentiel du logiciel.
L’exemple ici demande l’existence d’un reverse-proxy capable de rediriger le port de sortie 7070 vers l’internet, autrement seul le NAS sera capable d’accéder au site.
J’ai limité les ressources utilisables par l’image via les paramètres cpu et memory.

podman run -d  -e "DATABASE_TYPE=sqlite" \
              -e "START_CALDAV=1" \
              -e "START_WEBDAV=1" \
              -e "TRACIM_WEBSITE__BASE_URL=https://tracim.ndd.tld" \
              -e "TRACIM_WEBDAV__BASE_URL=https://tracim.ndd.tld" \
              -e "TRACIM_WEBSITE__TITLE=Tracim" \
              -e "TRACIM_WEBSITE__DESCRIPTION=Mon espace partagé !" \
              -e "TRACIM_DEFAULT_LANG=fr" \
              -p "127.0.0.1:7070:80" \
              -v "$HOME//tracim/etc:/etc/tracim" \
              -v "$HOME/tracim/var:/var/tracim" \
              --cpus=2 \
              --memory=2g \
              --name tracim \
              inkhey/tracim:4.5-no-vtk

Pour une gestion un peu plus propre, il est possible de convertir cette configuration en service Systemd de la sorte :

podman stop tracim
podman generate systemd -n tracim > ~/.config/systemd/user/tracim.service
systemctl --user daemon-reload
systemctl --user enable tracim
systemctl --user start tracim

Vous avez ainsi un Tracim fonctionnel via Podman donc le cycle de vie est gérable via Systemd, pas mal non ?

Bonus : convertir en fichier de configuration pour kubernetes

Je n’utilise pas personnellement Kubernetes, mais Podman permet facilement de convertir un conteneur existant en configuration compatible

podman generate kube -f tracim.yml tracim

On peut aussi démarrer une configuration de type kubernetes :

podman play kube ./tracim.yml

🥳

La suite

🕸 Tracim sur mon NAS, partie 1b: Partage public d'une image multiplateforme avec Buildah

Sun, 30 Apr 2023 18:30:21 +0200

Une autre façon de faire, publiez publiquement une image !

Si vous avez lu mon précédent article , j’expliquais qu’il était facile avec Buildah de produire une image pour une plateforme différente.

Dans cet article-ci, je reviens sur cette procédure, en explorant la possibilité de tirer plutôt parti du serveur de stockage d’image public tout en proposant des images multi-architectures.

Le principe d’une image multi-architecture, est qu’avec un même nom, il est possible depuis des systèmes de différente architecture processeur d’utiliser le même nom d’image. Il ne s’agit pas à proprement parler d’image multi-plateforme, mais d’un alias unique permettant à chaque système de récupérer l’image compatible.

J’ai pour ce faire suivis attentivement ce tutoriel, merci à Dan Manners. Cet article n’est donc qu’une application un peu plus concrète de son article.

Mise en application

# dépendances nécessaire sous debian
sudo apt install podman buildah git qemu-user-static qemu git

On récupère le code nécessaire pour la génération de l’image :

cd /tmp
git clone --depth 1 --branch release_04.05.00 https://github.com/tracim/tracim.git tracim
cd tracim//tools_docker/Debian_Uwsgi_ARM64

Ce qui aboutit en changeant quelques points au script ci-dessous.

Avant de l’utiliser :

Changer le en fonction de votre cas, en particulier la variable USER.
Si vous utilisez le docker registry, créer un token d’authentification avec les bons droits pour pouvoir pousser sur le github registry.

#!/bin/bash

set -e
export TRACIM_VERSION="4.5"
# Set your manifest name
export MANIFEST_NAME="tracim-${TRACIM_VERSION}-no-vtk"

# Set the required variables
export BUILD_PATH="/tmp/tracim/tools_docker/Debian_Uwsgi_ARM64/"
export REGISTRY="ghcr.io"
export USER="inkhey"
export IMAGE_NAME="tracim"
export IMAGE_TAG="${TRACIM_VERSION}-no-vtk"

buildah logih $REGISTRY
# Create a multi-architecture manifest
buildah manifest create ${MANIFEST_NAME}

# Build your amd64 architecture container
#buildah bud \
    --tag "${REGISTRY}/${USER}/${IMAGE_NAME}:${IMAGE_TAG}" \
    --manifest ${MANIFEST_NAME} \
    --arch amd64 \
    ${BUILD_PATH}

# Build your arm64 architecture container
buildah bud \
    --tag "${REGISTRY}/${USER}/${IMAGE_NAME}:${IMAGE_TAG}" \
    --manifest ${MANIFEST_NAME} \
    --arch arm64 \
    ${BUILD_PATH}

# Push the full manifest, with both CPU Architectures
buildah manifest push --all ${MANIFEST_NAME} "docker://${REGISTRY}/${USER}/${IMAGE_NAME}:${IMAGE_TAG}"

Les images enfin générées si tout s’est bien passé, il est enfin possible d’aller les récupérer. Les miennes sont ainsi disponible ici

Vous pouvez ainsi les récupérer sous ce nom : ghcr.io/inkhey/tracim:4.5-no-vtkque ce soit depuis une machine amd64 ou arm64.

🥳

La Suite

🕸 Tracim sur mon NAS, partie 1a: Génération de l'image ARM64 avec Buildah

Sun, 30 Apr 2023 18:30:20 +0200

Introduction

Podman/Buildah est une suite logicielle afin de gérer des conteneurs logiciels. C’est une alternative à docker, qui a l’avantage de ne pas nécessiter de demon avec les droits root.

Tracim est un logiciel intéressant permettant de gérer des espaces de collaboration dans divers cadres. S’il est aisé d’imaginer des usages professionnels poussés avec ce logiciel, il est aussi facile du fait de sa modularité de le tester en mode simplifié¹ pour un usage personnel.

Pour mon usage personnel, j’utilise Tracim sur un NAS dont l’architecture logicielle est ARM64 et le système d’exploitation est Armbian, dérivée de debian.

La version actuelle de tracim à l’heure de ces lignes est la 4.5.0 sortie le 27 avril 2023.

Générer les images (Buildah)

Tracim ne fournit actuellement pas d’image ARM64 officiel, il faut donc les générer soit même. Dans cet exemple, je génère l’image ARM64 depuis une machine d’architecture amd64, j’ai ainsi besoin de qemu.

Sur le système pour générer les images :

sudo apt install podman buildah git qemu-user-static qemu

Récupérer sur la dernière version stable de tracim :

Récupération de la version 4.5.0 de Tracim :

git clone --depth 1 --branch release_04.05.00 https://github.com/tracim/tracim.git tracim_stable

Générer l’image pour ARM64 avec Qemu et Buildah

Une image fonctionnelle en ARM64 expérimentale est disponible dans le code source de tracim, la seule différence dans cette version (4.5.0) avec l’image officielle est l’absence de support des previews d’images 3D, la librairie vtk n’étant pas disponible en version compilée pour ARM64.

cd tracim_stable/tools_docker/Debian_Uwsgi_ARM64/
buildah bud \
    --tag "algoo/tracim:4.5.0" \
    --arch arm64 \
    --build-arg TAG="release_04.05.00"
    .

Note : la génération peut s’avérer longue du fait de l’utilisation d’une architecture non native.

Déplacer l’image entre 2 machines

Sur le système ou l’image a été généré :

podman save algoo/tracim:4.5.0 > tracim_4.5.0.tar

On peut ensuite déplacer l’archive entre les deux machines via un support tel qu’une clé usb ou tout simplement par le réseau, par exemple via des outils tel que sftp.

Pour importer l’image sur le système cible, ne pas oublier d’avoir Podman d’installé :

sudo apt install podman

podman load < tracim_4.5.0.tar

Il est ainsi possible d’utiliser sur mon nas l’image algoo/tracim:4.5.0.

🥳

La Suite

Sans fonctionnalités complexes tels que la recherche avancée avec elasticsearch/opensearch, les notifications mails, etc. la configuration de Tracim est très fournis ↩︎