Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

TuxRun et le noyau Linux

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Échirolles libérée ! La dégooglisation (5)

Voici aujourd’hui le 5e et dernier article que Nicolas Vivant consacre à la dégooglisation de la ville d’Échirolles (si vous avez raté les épisodes précédents). Maintenant que les outils sont en place, il est temps d’envisager comment la mutualisation et la décentralisation conjuguées pourraient ouvrir de nouvelles perspectives aux citoyens et citoyennes de l’agglomération.


Le grand absent de ce récit est le travail important entamé sur la réduction de l’impact environnemental du numérique. C’est un fil conducteur permanent pour notre action. De nombreuses choses sont faites, mais d’autres décrivent beaucoup mieux que nous les enjeux, les outils et ce qu’il convient de faire pour avancer. Leur travail nous sert de guide. J’y reviendrai dans un article (modeste et) dédié.

Voir plus loin pour viser juste

Une vision pour l’avenir, ce n’est pas une prédiction, ni même une prévision. C’est simplement un axe, une direction. C’est ce qui permet, quand deux chemins existent, de faire un choix. Ce n’est évidemment pas une garantie que ce choix soit le bon mais si, à chaque carrefour, une direction existe qui aide à se déterminer, alors nous gagnons en cohérence, en rapidité de décision et, finalement, en efficacité.

Dans un monde où la dégooglisation serait une réalité, où les logiciels libres seraient dominants et où transparence et partage des données s’imposeraient comme une évidence, quel pourrait être l’étape suivante ? Et quelles pierres poser, dès aujourd’hui, qui tendraient vers cet objectif et pourraient orienter notre action ?

La décentralisation comme facteur de résilience

Historiquement, l’internet public est une architecture décentralisée. C’est même l’une des raisons de sa création : l’interconnexion de réseaux divers, dans un but de coopération. Même si le récit d’un internet construit comme un réseau permettant de résister à une attaque nucléaire est une légende urbaine, les événements récents ont permis de vérifier que la décentralisation était bien l’une des clés de la résilience des systèmes d’information.

En France, la plupart des accès résidentiels reposent sur Orange, Free, Bouygues et SFR. Quatre infrastructures qui, si elles étaient attaquées, affecteraient durablement nos communications. Une étude du RIPE a montré comment l’internet ukrainien résistait au black-out général malgré les nombreuses dégradations de l »infrastructure. Le secret ? Une structure distribuée, décentralisée, et des fournisseurs d’accès locaux partout dans le pays.

L’exemple le plus connu (et l’un des plus anciens) d’un système fédéré est la messagerie électronique. Les fournisseurs d’adresses e-mail sont innombrables mais, parce qu’ils ont choisi d’utiliser des protocoles standard, interopérables, chaque utilisateur peut échanger des messages avec tous les autres. Si l’un des prestataires techniques disparaît (c’est arrivé plusieurs fois), il ne met pas en danger l’intégralité du système. La domination d’un acteur, en revanche, parce qu’elle repose sur la centralisation des ressources (pensons à Gmail), peut fragiliser cette construction.

Mais l’angle de la résilience n’est pas le seul qu’il est intéressant d’interroger.

Décentralisation et mutualisation

Dans l’esprit de la plupart de nos décideurs, mutualisation et centralisation vont de pair, l’un des objectifs d’un effort de mise en commun des moyens étant de réaliser des économies d’échelle. Pour un certain nombre d’applications centrales, cette promesse est tenue. Cependant, quelques inconvénients sont associés à ce type de projet :

  • éloignement des organes de décision
  • perte d’autonomie dans les choix techniques ou politiques
  • moindre connaissance de l’environnement des utilisateurs
  • moindre réactivité dans la mise en œuvre des projets

Comment articuler coopération (pour une plus grande efficacité dans les projets transversaux) et autonomie (pour conserver une certaine liberté de choix et d’action) ?

En coopérant, des structures indépendantes peuvent créer des réseaux au service de projets d’envergure, tout en conservant leur autonomie de gestion, d’évolution et d’action. Des moyens techniques existent, et elles sont très largement implantées dans les solutions libres. ActivityPub a été officiellement publié comme recommandation du W3C le 23 janvier 2018.

Ce standard, qui permet d’interfacer des solutions diverses, est présent dans plusieurs des logiciels utilisés par la ville d’Échirolles : Nextcloud (plateforme collaborative), Peertube (hébergement de vidéos), Mastodon (réseau social) et WordPress (création de sites web). Ces quatre outils sont de plus en plus utilisés par les collectivités territoriales, les ministères et les partenaires de la ville, mais les fonctionnalités de fédération sont rarement mises en œuvre, en interne comme en externe. Pourtant, les applications pourraient être nombreuses : partage d’annuaires/de dossiers entre collectivités (Nextcloud), meilleure visibilité de la communication des structures associées (Peertube), création de sites dans le cadre de projets intercommunaux (WordPress), mise en avant des actions d’un territoire (Mastodon), etc.

La fédération comme horizon

Au sein d’Alpes Numérique Libre, le collectif de DSI de la région grenobloise autour des logiciels libres, le sujet est en train de naître, sans concrétisation pour le moment. La mise en place d’une fédération des acteurs au sein d’un même territoire géographique pourrait être une première pierre posée, une expérience intéressante du point de vue de l’action publique dont nous pourrions, peut-être, tirer des enseignements plus larges.

Les EPCI (établissements publics de coopération intercommunale), comme le SITPI ou Grenoble Alpes Métropole dans notre région, pourraient jouer un rôle moteur dans ce type d’initiative : idéalement positionnés au centre des réseaux communaux, ils disposent d’une architecture parfaitement adaptée.

L’instance Mastodon colter.social, créée, hébergée et maintenue par le SITPI est, à ce titre, un précurseur intéressant de ce que pourraient être ces fonctionnements fédératifs. Mise à disposition de l’ensemble des collectivités territoriales, sa modération est assurée par les agents de collectivités qui ne sont pas forcément adhérentes du syndicat, mais qui ont choisi de coopérer. Des outils comme Zammad ou Signal (pour des instances plus importantes, pourquoi pas un serveur Matrix ?) permettent d’organiser efficacement ce travail.

Plusieurs autres systèmes de mutualisation innovants pourraient être imaginés, alliant la mise à disposition de ressources pour les petites collectivités (un serveur PeerTube partagé, par exemple) et une fédération avec les structures de taille plus importante, chacune maintenant sa propre solution.

Nous n’en sommes pas là pour le moment, et nombreuses sont les collectivités qui reposent sur des solutions hébergées (en mode SaaS), souvent chez des grands acteurs américains (Google, Microsoft, Amazon…), parce qu’elles n’ont pas les compétences ou les ressources financières permettant un autre fonctionnement.

Pas toujours très bien structurées, focalisées sur leur transformation numérique, choisie ou subie, ce type de projet peut paraître bien éloigné de leurs préoccupations quotidiennes. Mais il me semblait intéressant de faire ce travail de prospective, comme un horizon vers lequel nous pourrions, individuellement et collectivement, choisir de tendre.

L’épisode 1 (structuration)
L’épisode 2 (transformation)
L’épisode 3 (solutions)
L’épisode 4 (inclusion)
L’épisode 5 (vous êtes ici)

***

Retrouvez-moi sur Mastodon : https://colter.social/@nicolasvivant

❌