❌

Vue lecture

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

Dirty Frag - L'exploit kernel Linux qui donne un accès root sur toutes les distros

✇Korben
Korben ✨

Le chercheur en sécu Hyunwoo Kim vient de lâcher dans la nature Dirty Frag, un nouvel exploit kernel Linux qui enchaîne 2 vulnérabilités pour obtenir un accès root sur n'importe quelle distro majeure, avec un taux de réussite proche de 100%.

L'embargo devait tenir encore quelques semaines. Il n'a pas tenu.

Et problème (et c'est pour ça que je vous en parle) c'est que ça marche du feu de dieu, et que personne n'a encore de patch disponible !! Alerte rouge donc !!

La lignée "Dirty" a donc maintenant quatre membres. Dirty COW en 2016, avec ses 9 ans de présence silencieuse dans le kernel avant d'être découvert, Dirty Pipe en 2022, Copy Fail dont je vous parlais il y a tout juste 8 jours, découvert par une IA. Et maintenant Dirty Frag, qui s'appuie sur le même principe que Copy Fail tout en contournant sa mitigation connue.

Alors comment ça marche ?

Le concept du truc c'est l'abus d'un mécanisme tout à fait légitime du kernel Linux : splice(). Cette fonction permet de faire circuler des données entre deux descripteurs de fichiers sans les copier en mémoire. C'est très utile, très performant, mais dans certaines configurations, c'est surtout très catastrophique.

Dirty Frag exploite les modules réseau d'IPsec (ESP) et du protocole RxRPC, ainsi quand un attaquant utilise splice() pour faire passer une page du cache mémoire (disons, /usr/bin/su) dans un buffer réseau, le kernel effectue son chiffrement directement sur cette page en RAM et sans faire de copie.

Résultat, les premiers octets de /usr/bin/su en mémoire sont remplacés par du code malveillant qui ouvre un shell root. Un simple appel à su ensuite, et l'attaquant est root.

Deux CVE sont impliqués dans la chaîne. CVE-2026-43284 qui concerne les modules esp4 et esp6 et qui a été patchée depuis hier et CVE-2026-43500 qui concerne rxrpc et pour celle-ci, y'a aucun patch actuellement à l'heure où j'écris ces lignes.

Le fait de chainer les 2 exploits permet à chacun de combler les angles morts de l'autre. C'est un peu technique mais en gros, la variante ESP requiert les droits de créer un namespace utilisateur, ce qu'Ubuntu peut bloquer via AppArmor. Alors que de son côté, la variante RxRPC ne nécessite pas ce privilège, mais le module rxrpc.ko n'est chargé par défaut que sur... Ubuntu. Du coup, une fois combinés, ils couvrent toutes les distros majeures sans exception.

Hyunwoo Kim a reporté la faille aux mainteneurs des distribs le 30 avril dernier, avec un accord de divulgation coordonnée via [email protected]. Mais un tiers extérieur (appelons le "connard" ^^) a brisé l'embargo hier, d'où la publication immédiate du PoC, avec l'accord des maintainers, pour éviter qu'un exploit silencieux circule sans que personne soit prévenu.

Les versions testées et confirmées vulnérables sont donc Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44.

En gros, si vous avez un kernel compilé depuis début 2017, vous êtes dans le scope.

Tester avec Lima sur macOS

Si vous voulez reproduire ça dans un environnement contrôlé, l'idée c'est de lancer une Ubuntu 24.04 avec le kernel non patché et de faire comme ceci :

# Cloner, compiler, et lancer
git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
sudo apt install gcc -y && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

Et si tout se passe bien, vous obtenez alors un shell root sans faire paniquer le kernel comme chez moi ici :

Après le test, le page cache est contaminé donc avant de faire quoi que ce soit d'autre, faut le nettoyer. :

echo 3 > /proc/sys/vm/drop_caches

Ou plus simple, redémarrez la machine car la modification est uniquement en RAM, donc un reboot permet de repartir de zéro.

Alors que faire ?

Hé bien, comme aucun patch n'est disponible pour la plupart des distros à l'heure où j'écris ces lignes, vous pouvez vous mettre en boule et pleurer. Sauf si vous êtes sous AlmaLinux car eux ont déjà poussé des kernels corrigés. Après vous pouvez aussi sécher vos larmes si vous êtes sur une autre distro, et suivre cette remédiation qui vous prendra trente secondes :

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Cette commande fait trois choses : elle blackliste les modules vulnérables pour qu'ils ne se rechargent pas au prochain boot, elle les décharge s'ils sont actifs, et elle nettoie le page cache au cas où il serait déjà corrompu.

Après c'est tranquille à faire car esp4, esp6 et rxrpc ne sont pas des modules que la plupart des machines desktop utilisent au quotidien. Les désactiver n'a donc aucun impact visible sur 99% des setups. Mais un serveur qui fait du VPN IPsec en mode transport ESP, lui, sera affecté...

En tout cas, surveillez ça de près car une fois que votre distro sortira le patch, faudra mettre à jour et rebooter.

Source : https://github.com/V4bel/dirtyfrag

Réparer Ubuntu sans perte de données : le guide complet

✇malekal.com
malekalmorte

Ubuntu ne démarre plus, reste bloqué au démarrage ou affiche une erreur GRUB ?
Avant de réinstaller complètement Linux, plusieurs méthodes permettent souvent de réparer Ubuntu sans formater et perdre ses fichiers.

Selon le problème rencontré, vous pouvez :

Dans la majorité des cas, les documents du dossier /home peuvent être conservés pendant la réparation du système Linux.

Dans ce guide complet, vous trouverez les différentes méthodes pour réparer Ubuntu et retrouver un système fonctionnel sans formater entièrement le PC.

Quand réparer Ubuntu sans perte de données

Dans de nombreux cas, il est possible de réparer Ubuntu sans formater Linux ni supprimer les fichiers personnels.

Cette solution est particulièrement utile lorsque :

  • Ubuntu ne démarre plus
  • Linux reste bloqué au boot
  • Une mise à jour Ubuntu s’est mal passée
  • GRUB est corrompu
  • Le système de fichiers Linux contient des erreurs
  • Des paquets Ubuntu sont cassés
  • L’environnement graphique ne se lance plus

L’objectif est alors de :

  • Restaurer le démarrage Ubuntu
  • Réparer les composants système Linux
  • Corriger les erreurs de configuration
  • Réinstaller certains paquets
  • Conserver les documents et données personnelles

Dans la majorité des cas, les fichiers du dossier /home restent intacts pendant les réparations.

👉 Si Ubuntu ne démarre plus, commencez par utiliser le mode recovery :

👉 Pour réparer GRUB et le démarrage Linux :

Quelles méthodes de réparation Ubuntu choisir

Plusieurs méthodes de réparation d’Ubuntu sont présentées dans ce guide.
Consultez le tableau ci-dessous pour utiliser la bonne méthode en fonction des problèmes rencontrés.

Problème UbuntuMéthode recommandée
Ubuntu démarre encore partiellementMode recovery Ubuntu
Ubuntu reste bloqué au démarrageVérifier le disque avec fsck
Erreur grub rescue>Réparer GRUB
Ubuntu ne démarre plus du toutLive USB Ubuntu
Mise à jour Ubuntu casséeRéparer les paquets avec dpkg
Mot de passe oubliéRéinitialiser le mot de passe Ubuntu
Système fortement corrompuRéinstaller Ubuntu sans perte de données
Fichiers importants à récupérerSauvegarder Linux avec un Live USB
Quelles méthodes de réparation Ubuntu choisir ?

Sauvegarder les données importantes avant réparation

Avant toute réparation importante d’Ubuntu, il est fortement conseillé de sauvegarder les fichiers importants afin d’éviter une perte de données en cas d’erreur ou de corruption du système Linux.

Quoi et comment sauvegarder ses données

Même si les méthodes de réparation présentées dans ce guide sont conçues pour conserver les données personnelles, un problème disque ou une mauvaise manipulation peut toujours survenir.

Les fichiers les plus importants se trouvent généralement dans le dossier :

/home

Pensez notamment à sauvegarder :

  • Les documents
  • Les photos et vidéos
  • Les projets professionnels
  • Les bases de données
  • Les fichiers de configuration Linux
  • Les profils Firefox ou Thunderbird
  • Les clés SSH et fichiers sensibles

Le plus simple consiste à utiliser un Live USB Ubuntu afin d’accéder aux partitions Linux et copier les fichiers vers :

  • Un disque dur externe
  • Une clé USB
  • Un NAS
  • Un autre PC

👉Pour créer une clé USB bootable :


👉Pour accéder au mode rescue avec un Live USB :

Depuis le mode Live Ubuntu

  • Ouvrez le gestionnaire de fichiers
  • Montez la partition Linux
  • Accédez au dossier /home
  • Copiez les fichiers importants vers un support externe

Vous pouvez aussi utiliser le terminal Linux pour sauvegarder les données.

Par exemple :

cp -r /home/utilisateur/Documents /media/ubuntu/DisqueUSB/

Si le disque Linux présente des erreurs ou des signes de défaillance :

👉 Vérifier l’état du disque sous Linux :

Vérifier le disque et le système de fichiers Ubuntu

Une corruption du système de fichiers Linux ou un problème disque peut empêcher Ubuntu de démarrer correctement.

Les symptômes les plus fréquents sont :

  • Ubuntu bloqué au démarrage
  • Écran noir Linux
  • Erreurs EXT4
  • Messages fsck
  • Kernel panic
  • Redémarrages en boucle
  • Partition Linux inaccessible

Avant de réinstaller Ubuntu, il est conseillé de vérifier :

  • L’état du disque dur ou SSD
  • Les partitions Linux
  • Le système de fichiers EXT4

Vérifier les partitions Linux

Depuis le mode recovery Ubuntu ou un Live USB, ouvrez un terminal puis affichez les partitions Linux :

lsblk -f

Ou :

sudo fdisk -l

Ces commandes permettent de :

  • Vérifier les partitions Linux
  • Identifier la partition racine Ubuntu
  • Contrôler les systèmes de fichiers EXT4
  • Vérifier les partitions EFI

👉Plus d’aide dans leur utilisation :

Vérifier les partitions Linux avec lsblk

Vérifier et réparer Ubuntu avec fsck

La commande fsck permet de détecter et corriger les erreurs du système de fichiers Linux.

Par exemple :

sudo fsck -f /dev/sda2

Remplacez /dev/sda2 par votre partition Ubuntu.

fsck peut corriger :

  • Les erreurs EXT4
  • Les inodes corrompus
  • Les erreurs du journal Linux
  • Les incohérences du système de fichiers

👉 Guide complet :

Vérifier l’état du disque dur ou SSD Linux

Si Ubuntu plante régulièrement ou refuse de démarrer, le disque peut être défaillant.

Vous pouvez vérifier l’état SMART du disque avec smartctl.

Par exemple :

sudo apt install -y smartmontools
sudo smartctl -a /dev/sda

Cette commande permet de :

  • Vérifier la santé du disque
  • Contrôler les secteurs défectueux
  • Détecter une usure SSD
  • Identifier des erreurs matérielles

👉 Voir aussi :

Vérifier l’espace disque Ubuntu

Un disque saturé peut aussi empêcher Ubuntu de fonctionner correctement.

Depuis le terminal Linux :

df -h

Cela permet de vérifier :

  • L’espace libre
  • Les partitions pleines
  • Le stockage disponible sur Ubuntu

Si la partition / est saturée :

  • Supprimez les anciens noyaux Linux
  • Nettoyez le cache APT
  • Supprimez les fichiers inutiles
  • Vérifiez le dossier /var/log

👉Aidez-vous de ce guide complet :

Réparer Ubuntu avec le mode recovery

Ubuntu intègre un mode recovery accessible depuis GRUB qui permet de réparer Linux lorsqu’il ne démarre plus correctement.

Le mode recovery Ubuntu permet notamment :

  • Réparer les paquets cassés
  • Vérifier le système de fichiers avec fsck
  • Réparer GRUB
  • Ouvrir un terminal root
  • Activer le réseau
  • Corriger des erreurs système Linux

C’est généralement la première méthode à utiliser lorsque :

  • Ubuntu reste bloqué au démarrage
  • Linux affiche un écran noir
  • Une mise à jour Ubuntu a échoué
  • Le système démarre partiellement
  • Des erreurs GRUB apparaissent

👉 Suivre le guide complet :

Réinitialiser Ubuntu sans supprimer les fichiers personnels

Lorsque Ubuntu est fortement corrompu ou instable, il est parfois possible de réinitialiser le système sans supprimer les fichiers personnels.

L’objectif est de :

  • Réinstaller les composants système Ubuntu
  • Restaurer les paquets Linux
  • Corriger les erreurs système
  • Conserver les documents et données du dossier /home

Cette méthode peut être utile lorsque :

  • Ubuntu ne démarre plus correctement
  • L’environnement graphique plante
  • Des paquets système sont cassés
  • Linux est devenu instable après plusieurs mises à jour
  • Les réparations classiques ne fonctionnent plus

Dans certains cas, une simple réparation des paquets Ubuntu suffit :

sudo apt --fix-broken install
sudo dpkg --configure -a

Si Ubuntu reste inutilisable, vous pouvez envisager :

  • Une réinstallation Ubuntu sans formatage
  • Une conservation de la partition /home
  • Une réparation via Live USB Ubuntu

Réinstaller Ubuntu sans formater la partition /home

Si Ubuntu ne démarre plus malgré les réparations, vous pouvez réinstaller le système Linux sans forcément supprimer les fichiers personnels.

Le principe consiste à :

  • Réinstaller Ubuntu sur la partition système
  • Conserver la partition /home
  • Garder les documents et données personnelles

Cette méthode permet souvent de :

  • Restaurer les composants système Ubuntu
  • Réparer les paquets Linux corrompus
  • Réinstaller GRUB
  • Retrouver un Ubuntu fonctionnel sans formatage complet

Créer le Live USB Ubuntu et démarrer dessus

  • Créez la clé USB d’installation d’Ubuntu en suivant ce tutoriel :
Démarrer sur clé USB Ubuntu

Utiliser l’option « Réinstaller Ubuntu »

  • Suivez les premières étapes de configuration
  • Dans le type d’installation, choisissez :
    • Réinstaller Ubuntu

Cette option permet généralement :

  • De réinstaller les fichiers système Ubuntu
  • Corriger les composants Linux corrompus
  • Restaurer le démarrage Ubuntu
  • Conserver les fichiers personnels du dossier utilisateur

C’est la méthode la plus simple et recommandée pour la majorité des utilisateurs.

L’option Réinstaller Ubuntu peut ne pas être disponible selon la version d’Ubuntu
Réinstaller Ubuntu sans perte de données

Utiliser « Partitionnement manuelle » pour gérer les partitions manuellement

Si vous utilisez :

  • Une partition /home séparée
  • Plusieurs disques Linux
  • Un dual-boot Windows 11/10 complexe
  • Une configuration personnalisée

Vous pouvez choisir : Partitionnement manuelle

Cette option permet :

  • Sélectionner précisément les partitions Linux
  • Réinstaller Ubuntu uniquement sur /
  • Conserver la partition /home sans formatage
Réparer Ubuntu sans perdre de fichiers

Dans ce cas :

  • Sélectionnez la partition système Ubuntu /
  • Activez le formatage uniquement sur cette partition
  • Vérifiez que la partition /home ne soit pas formatée

Attention :

  • Une mauvaise manipulation des partitions peut entraîner une perte de données
  • Vérifiez soigneusement les points de montage avant validation
Réparer Ubuntu sans perdre de fichiers

Que faire si Ubuntu ne démarre toujours pas

être fortement corrompu ou le problème être matériel.

Dans cette situation, il est important :

  • De ne pas formater immédiatement Ubuntu
  • Sauvegarder les fichiers importants
  • Vérifier l’état du disque Linux
  • Identifier si le problème vient :
    • du système Ubuntu
    • du démarrage GRUB
    • des partitions Linux
    • du matériel

Le tableau ci-dessous permet d’identifier rapidement la méthode à utiliser selon la situation rencontrée.

Problème UbuntuSolution recommandée
Ubuntu reste bloqué au démarrageUtiliser le mode recovery Ubuntu
Message grub rescue>Réparer GRUB
Écran noir après GRUBUtiliser systemd.unit=emergency.target
Erreurs EXT4 ou messages fsckVérifier le disque avec fsck
Ubuntu ne démarre plus du toutUtiliser un Live USB Ubuntu
Mise à jour Ubuntu casséeRéparer les paquets avec dpkg
Mot de passe Ubuntu oubliéRéinitialiser le mot de passe Ubuntu
Partition Linux inaccessibleMonter les partitions avec un Live USB
Données importantes à récupérerSauvegarder Linux avant réparation
Ubuntu fortement corrompuRéinstaller Ubuntu sans perte de données

👉Résolvez gratuitement le problème sur le forum du site :

FAQ

Peut-on réparer Ubuntu sans perdre ses données ?

Oui, dans la majorité des cas il est possible de réparer Ubuntu sans supprimer les fichiers personnels.
Les documents du dossier /home restent généralement conservés lors :
– D’une réparation GRUB
– D’un fsck
– D’une réparation des paquets Linux
– D’une réinstallation Ubuntu sans formatage complet
Il est toutefois recommandé de sauvegarder les données importantes avant toute manipulation.

Le mode recovery Ubuntu supprime-t-il les fichiers ?

Non, le mode recovery Ubuntu sert uniquement à dépanner Linux.
Il permet notamment :
– Réparer les paquets cassés
– Vérifier le disque avec fsck
– Réparer GRUB
– Ouvrir un terminal root
Les fichiers personnels ne sont normalement pas supprimés.
👉 Voir aussi :


Peut-on réparer Ubuntu avec un Live USB ?

Oui, un Live USB Ubuntu permet souvent de réparer un système Linux qui ne démarre plus.
Vous pouvez notamment :
– Monter les partitions Linux
– Sauvegarder les fichiers
– Utiliser chroot
– Réinstaller GRUB
Réparer Ubuntu sans démarrer le système installé
👉 Utiliser un Live USB Ubuntu :
https://www.malekal.com/utiliser-live-usb-linux-acceder-mode-rescue/

Comment réparer GRUB sur Ubuntu ?

GRUB peut être réparé :
– Depuis le mode recovery Ubuntu
– Depuis un Live USB Ubuntu
– Avec grub-install
– Avec update-grub
👉 Guide complet :

Peut-on réinstaller Ubuntu sans formater le disque ?

Oui, Ubuntu peut être réinstallé sans supprimer les données personnelles.
Selon les versions Ubuntu :
– L’option « Réinstaller Ubuntu » peut être proposée automatiquement
– Sinon il faut utiliser le partitionnement manuel afin de conserver /home
Attention à ne pas sélectionner :
– « Effacer le disque et installer Ubuntu »

Que faire si Ubuntu affiche grub rescue> ?

Le message grub rescue> indique généralement :
– Une corruption GRUB
– Une partition Linux introuvable
– Une erreur UEFI
– Un problème disque
Dans ce cas :
– Réparez GRUB
– Vérifiez les partitions Linux
– Lancez un fsck
Utilisez un Live USB Ubuntu si nécessaire
👉 Voir aussi :

Peut-on récupérer ses fichiers si Ubuntu ne démarre plus ?

Oui, même si Ubuntu ne démarre plus, les fichiers restent souvent accessibles depuis un Live USB Linux.
Vous pouvez alors :
– Monter les partitions Linux
– Copier les fichiers vers un disque externe
– Sauvegarder le dossier /home

L’article Réparer Ubuntu sans perte de données : le guide complet est apparu en premier sur malekal.com.

AlmaLinux 10.2 Beta réintroduit le support 32-bit, à contre-courant

✇Korben
Vincent Lautier

La distribution AlmaLinux a publié sa version 10.2 Beta nommée "Lavender Lion", et elle fait un truc que la plupart des distros récentes refusent de faire : remettre du support 32-bit dans le système. 

Pas un retour total, on s'entend, mais des packages userspace i686 pour faire tourner du logiciel ancien, des pipelines de CI un peu datées et des conteneurs qui dépendent encore de bibliothèques 32-bit. Pas d'ISO d'install i686, ça reste enterré pour de bon. Mais bon, vos vieux binaires repartent sur un x86_64 propre.

C'est intéressant parce que Red Hat a clairement tranché de l'autre côté avec RHEL. Plus de support 32-bit, plus de x86-64-v2 sur la version 10, c'est marche ou crève. AlmaLinux, qui se positionne comme rebuild compatible RHEL, prend un chemin un peu différent en disant : on garde la compat mais on rajoute des trucs qui rendent la vie plus simple aux entreprises avec du legacy à maintenir. Y'en a beaucoup.

Côté nouveautés plus classiques, vous récupérez Python 3.14, PostgreSQL 18, MariaDB 11.8, Ruby 4.0 et PHP 8.4 dans les packages, plus SDL3, libkrun et le tooling FIDO Device Onboard. La beta intègre aussi déjà le patch pour la vulnérabilité Copy Fail (CVE-2026-31431), ce qui veut dire que les équipes d'AlmaLinux suivent vraiment de près les correctifs amont, sans attendre la stable pour les pousser.

Le truc à retenir, c'est qu'AlmaLinux est en train de devenir le RHEL "raisonnable" pour les boîtes qui ont du parc informatique vieillissant. 

Pendant que Red Hat optimise pour ses futurs gros clients cloud, AlmaLinux ramasse tous les autres : ceux qui ont encore une appli métier en 32-bit, ceux dont les serveurs ne valident pas x86-64-v3, ceux qui veulent juste que ça marche sans réécrire la moitié de leur stack.

Bref, choisir AlmaLinux plutôt que RHEL ressemble de plus en plus à une décision pragmatique.

Source : Phoronix

Voyage dans les abysses : voilà l’incroyable vision des animaux de l’extrême

✇Numerama
The Conversation

Comment les créatures des abysses perçoivent-elles un monde sans soleil ? Dans un extrait de leur ouvrage Secrets de l'océan profond, les chercheurs Juliette Ravaux et Sébastien Duperron nous entraînent à plus de 2 000 mètres sous la surface. Des crevettes détectrices de chaleur aux poissons hypersensibles à la bioluminescence, découvrez les fascinantes adaptations visuelles d'une faune marine encore mystérieuse.

KULA - Le monitoring serveur Linux qui tient dans un seul binaire

✇Korben
Korben ✨

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

❌