Vous vous souvenez de l'époque où on s'écroulait comme des merdes dans notre canapé après une grosse journée de boulot et où on regardait juste ce que la télé nous balançait ? Pas de choix à faire sur Netflix, ni de recommandation sur l'Apple TV. On zappait juste en mode no-brain jusqu'à ce qu'on tombe sur une connerie qui réveille notre cerveau reptilien.

Eh bah le dev Chris Benincasa a créé Tunarr , un soft open source qui ressuscite ce truc-là en transformant votre Plex ou Jellyfin en chaîne de TV en continue.

Grâce à Tunarr, vous configurez vos chaînes dans une interface web (en glisser-déposer...), le soft émule un tuner HDHomeRun (le standard de la TV réseau aux US), que Plex, Jellyfin ou Emby reconnaissent ensuite comme une vraie source TV. Et voilà comment vous avez maintenant votre propre antenne maison.

Ou alors vous exportez en M3U pour des players IPTV comme Tivimate ou UHF, le tout avec un EPG intégré (c'est le guide des programmes), des bumpers (vous savez ces petites séquences Tchii Tchaaa ou M6 Mhmmmh des chaînes TV), des pubs vintage entre les programmes et même des clips musicaux pour faire authentique.

Bref, du déjà-vu, mais avec votre catalogue d'émissions à vous.

docker run -d -p 8000:8000 -v ./tunarr-data:/config/tunarr chrisbenincasa/tunarr:latest

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

On archive nos photos avec Immich , nos documents avec Readur , nos mots de passe avec Vaultwarden ... mais nos emails ? Ah bah non, ça on les laisse chez Google en croisant les doigts pour que tout se passe bien jusqu'à la fin de nos jours. C'est quand même un peu dinguo quand on y réfléchit sérieusement.

Et pourtant, y'a des années de conversations là-dedans ! Des factures en pièce jointe, des confirmations de commande, des échanges pro avec votre comptable, des mots de passe envoyés en clair (oui, hélas, ça arrive encore). Du coup, quand un hébergeur mail décide de changer ses conditions générales ou de fermer boutique, tout part à la poubelle si vous n'y faites pas attention.

Eonvelope , c'est un outil open source en Python qui permet de sauvegarder automatiquement tout ça sur votre propre serveur et qui se lance avec un simple docker compose up.

Le truc, c'est que des outils comme Gmvault font déjà le boulot via cron, mais uniquement pour Gmail et en ligne de commande alors qu'Eonvelope, lui, un peu à la manière de Bichon , tourne en arrière-plan avec une interface web et archive en continu tous vos comptes. Franchement, c'est pas le même délire. Vous branchez vos comptes IMAP, POP3, Exchange, et même JMAP (le protocole poussé par Fastmail qui commence tout juste à se démocratiser), vous réglez la fréquence, et hop, vos mails atterrissent dans votre instance sans que vous ayez à y penser.

Attention par contre, c'est de l'archivage, pas un client mail... vous ne répondrez pas à vos mails depuis l'interface.

Côté installation, c'est du Docker avec seulement 2 conteneurs, le serveur web et la base de données. En fait, comptez 5 minutes chrono si vous avez déjà un serveur dédié ou un VPS, le fichier docker-compose.yml est fourni et les variables d'environnement sont bien documentées sur ReadTheDocs . Y'a même un mode basse consommation pour ceux qui font tourner ça sur un Raspberry Pi 4 avec 2 Go de RAM ou un petit Synology ! SSL et HTTPS sont inclus par défaut, et l'authentification multifacteur aussi.

Mais le vrai point fort, c'est les intégrations avec le reste de l'écosystème self-hosted. Concrètement, vous pouvez envoyer vos pièces jointes PDF vers Paperless-ngx pour l'OCR, les photos vers Immich, et exporter vos contacts vers votre carnet d'adresses Nextcloud. Y'a aussi un endpoint Prometheus pour brancher Grafana et suivre vos stats d'archivage. En gros, si vous avez déjà un homelab qui tourne, ça vient se brancher dessus comme une pièce de Lego.

L'interface web est en PWA (donc utilisable sur votre téléphone), avec un moteur de recherche, du filtrage par date et par expéditeur, des fils de conversation reconstitués et de l'import/export en EML et MBOX. Franchement, c'est propre. Y'a aussi une API REST pour ceux qui préfèrent scripter par-dessus plutôt que de passer par l'interface.

Le projet est sous licence AGPLv3 et son dev déclare l'utiliser lui-même au quotidien, ce qui est souvent bon signe. Notez que la migration depuis un backup existant n'est pas forcément fluide mais qui ne tente rien n'a rien !

Bref, ça comble un vrai manque dans la stack de nos machins auto-hébergés mais je trouve que l'approche est clairement plus intégrée que ce qui existe (genre MailPiler ou un combo fetchmail+dovecot). À surveiller donc !

Source

Faut le reconnaitre, la doc et qui plus est, la doc réseau, c'est un peu le parent pauvre du homelab. Tout le monde sait qu'il faudrait la tenir à jour sur un petit wiki tout mignon mais personne le fait parce qu'on n'est pas cinglé et qu'on aime trop la vie pour ça. Heureusement, pour nous aider, y'a maintenant Scanopy qui est un outil open source qui scanne automatiquement votre réseau pour générer une topologie interactive incroyable qui se met à jour toute seule !

Pour l'installer, deux lignes suffisent :

curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
docker compose up -d

Développé par Madh93, cet outil en Go baptisé Prxy résout un problème que beaucoup d’entre nous subissent en silence à savoir comment accéder proprement à ses services auto-hébergés sans transformer sa connexion en passoire ou en goulot d’étranglement. L’idée, c’est du split-tunneling application par application, une approche chirurgicale qui évite les compromis habituels.