Vue lecture

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

CronMaster - Une interface graphique pour gérer vos cron jobs

Si vous avez déjà passé 20 minutes à déboguer un cron job qui ne se lance pas parce que vous aviez mis un espace au mauvais endroit dans la syntaxe * * * * *, vous allez adorer CronMaster .

Car le problème avec cron, c’est pas le concept en lui-même. L’idée de planifier des tâches automatiques reste géniale depuis les années 70. Non, le souci c’est cette syntaxe ésotérique qui fait que même les devs expérimentés doivent vérifier trois fois leur ligne avant de valider. Un petit 0 2 * * 1-5 et vous vous demandez si ça va se lancer tous les lundis ou tous les jours de la semaine à 2h du matin.

CronMaster arrive donc avec une proposition simple qui est de conserver la puissance de cron tout en rendant son utilisation intuitive. L’interface web affiche vos jobs sous forme de cartes visuelles, avec le nom de la tâche, sa fréquence d’exécution en langage humain et la possibilité de les activer/désactiver d’un clic. Plus besoin de commenter/décommenter des lignes dans le crontab.

CronMaster ne réinvente pas cron. Il se pose juste comme une couche visuelle par-dessus le système existant. Vos jobs continuent de tourner via le crontab système, mais vous les gérez depuis une interface moderne avec du dark mode, des stats système en temps réel (CPU, RAM, uptime) et même la possibilité de gérer des scripts bash directement depuis l’interface.

L’installation passe par Docker, ce qui simplifie énormément le déploiement. Un simple docker-compose.yml avec quelques variables d’environnement et vous avez votre interface accessible sur le port 40123. Le projet supporte aussi bien AMD64 qu’ARM64, donc ça tourne aussi bien sur votre serveur que sur un Raspberry Pi.

CronMaster n’est pas le seul dans sur créneau. Y’a Cronicle qui propose par exemple une solution multi-serveurs avec des graphiques de performance en temps réel et une gestion des dépendances entre tâches ou encore Crontab-UI qui mise plutôt sur la simplicité avec import/export de configurations et système de backup automatique.

Mais CronMaster a ses propres atouts. Son système d’informations système intégré permet de voir en un coup d’œil l’état de votre serveur pendant que vos jobs tournent. Et le support des variables d’environnement HOST_PROJECT_DIR facilite l’intégration dans des workflows existants. Sans oublier la possibilité de gérer plusieurs utilisateurs crontab depuis la même interface est pratique pour les équipes.

Un détail technique important… CronMaster nécessite les droits root dans le conteneur Docker pour accéder au crontab système. C’est un choix assumé du dev pour garantir une intégration transparente avec le système existant. Donc si vous préférez une approche plus isolée, Zeit propose une alternative desktop en C++ qui tournera sur votre ordi.

Le format cron reste toujours le même : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12) et jour de la semaine (0-7), mais avec CronMaster, vous avez des sélecteurs visuels qui génèrent automatiquement la bonne syntaxe comme ça, plus besoin de se rappeler que */5 signifie “toutes les 5 minutes” ou que 0,30 veut dire “à la minute 0 et 30”.

L’interface affiche aussi les logs d’exécution de chaque job, ce qui facilite grandement le debug. Au lieu de fouiller dans /var/log/syslog ou de configurer des redirections complexes avec >> /var/log/monjob.log 2>&1, tout est accessible depuis l’interface web.

Pour les développeurs qui bossent sur plusieurs projets, la fonctionnalité de commentaires sur chaque job est également super pratique. Vous pouvez documenter pourquoi tel script doit tourner à 3h du matin ou rappeler les dépendances d’un job particulier. Ces métadonnées restent attachées au job dans l’interface, contrairement aux commentaires dans le crontab qui peuvent facilement se perdre.

Voilà, donc si vous gérez régulièrement des cron jobs et que vous en avez marre de cette syntaxe cryptique, vous adorerez CronMaster !! C’est à découvrir ici !

Docker Desktop - Un accès API caché met Windows en danger

Il suffit parfois d’un simple scan nmap pour tomber sur une faille monumentale. Et c’est pile poil ce qui est arrivé à Félix Boulet, un chercheur en sécurité qui farfouillait dans le réseau privé de Docker et qui a découvert que l’API interne du Docker Engine traînait tranquillement à l’adresse http://192.168.65.7:2375/, sans aucune authentification. Oui, accessible depuis n’importe quel conteneur qui tourne sur votre machine.

Du coup, la CVE-2025-9074 qui en découle a reçu une note de 9.3 sur l’échelle CVSS, ce qui en fait une vulnérabilité critique. En fait, le problème, c’est que cette API exposée permet à un conteneur malveillant de communiquer directement avec le moteur Docker sans avoir besoin de monter le socket Docker. En gros, deux petites requêtes HTTP POST suffisent pour compromettre entièrement le système hôte. La première crée un conteneur privilégié avec le disque C: monté, et la seconde démarre ce conteneur malveillant…

Sous Windows, la situation est particulièrement préoccupante car le Docker Engine fonctionne via WSL2, ce qui signifie qu’un attaquant pourrait monter l’intégralité du système de fichiers en tant qu’administrateur. À partir de là, il pourrait lire n’importe quel fichier sensible et même remplacer une DLL système pour obtenir des privilèges administrateur complets sur l’hôte. Philippe Dugre, un autre chercheur, a confirmé qu’il pouvait créer des fichiers dans le répertoire home de l’utilisateur sous Windows, chose qu’il n’a pas réussi à faire sur macOS grâce aux protections supplémentaires du système d’Apple.

Ce qui rend cette vulnérabilité encore plus vicieuse, c’est que même la fonction Enhanced Container Isolation (ECI) de Docker ne la bloque pas. Cette protection censée isoler les conteneurs est complètement inefficace face à cette faille et les conteneurs peuvent toujours accéder à l’API et lancer d’autres conteneurs sans restriction. Ça la fout mal…

Sur macOS, l’impact est heureusement plus limité grâce aux mécanismes de sécurité intégrés. L’application Docker Desktop conserve une bonne couche d’isolation et demande la permission à l’utilisateur quand un conteneur tente de monter un répertoire utilisateur. Par défaut, l’application macOS n’a pas accès au reste du système de fichiers et ne s’exécute pas avec des privilèges administratifs, ce qui rend l’hôte beaucoup plus sûr que dans le cas de Windows.

Docker a rapidement réagi (youpi !) et publié la version 4.44.3 de Docker Desktop qui corrige cette vulnérabilité. Donc si vous utilisez Docker Desktop sur Windows ou macOS, installez cette mise à jour immédiatement. Aucune exploitation dans la nature n’a été signalée pour l’instant, mais avec une vulnérabilité aussi simple à exploiter et aux effets potentiellement dévastateur, mieux vaut ne pas traîner.

Pour info, Docker a également mentionné une autre vulnérabilité, la CVE-2025-23266, qui affectait le NVIDIA Container Toolkit en mode CDI jusqu’à la version 1.17.7 . Docker Desktop inclut maintenant la version 1.17.8 qui n’est pas touchée, mais les anciennes versions de Docker Desktop pourraient être affectées si le mode CDI était activement activé. C’est une raison de plus pour mettre à jour vers Docker Desktop 4.44 ou ultérieur.

Bravo Félix !

Source

Wrkflw - Testez vos GitHub Actions en local avant de casser la prod

Hier soir, j’ai découvert un outil qui m’aurait évité des dizaines de commits “fix CI”, “fix CI again”, “please work this time” sur GitHub. J’sais pas si vous aussi vous connaissez cette galère ? Vous modifiez votre workflow GitHub Actions, vous poussez, ça plante, vous corrigez, vous repoussez, ça replante… Bref, votre historique Git ressemble à un journal de débugging en temps réel.

Et heureusement, wrkflw vient mettre fin à ce cauchemar.

Ce petit outil codé en Rust vous permet en fait de valider et d’exécuter vos GitHub Actions directement sur votre machine, sans avoir besoin de pusher quoi que ce soit. L’outil vient d’être annoncé sur le forum Rust et ça va bien aider tout le monde je pense.

Grâce à lui, au lieu de tester vos workflows dans le cloud GitHub (et potentiellement faire planter votre CI/CD devant toute l’équipe… La te-hon…), vous les exécutez localement. Wrkflw parse alors votre fichier YAML, résout les dépendances entre jobs, et lance tout ça soit dans Docker/Podman pour matcher l’environnement GitHub, soit en mode émulation si vous n’avez pas de runtime container sous la main.

Ce qui rend wrkflw vraiment pratique, c’est son interface TUI (Terminal User Interface) qui vous permet de visualiser l’exécution en temps réel. Un simple wrkflw tui et vous avez un dashboard interactif où vous pouvez suivre vos jobs, voir les logs, et comprendre ce qui foire sans avoir à jongler entre 15 onglets GitHub.

L’installation se fait en deux secondes si vous avez Rust :

cargo install wrkflw

Le package est aussi dispo sur crates.io et une fois installé, vous pouvez valider un workflow avec la commande :

wrkflw validate .github/workflows/rust.yml

ou le lancer directement avec

wrkflw run .github/workflows/ci.yml

L’outil détectera automatiquement tous vos workflows et les chargera dans l’interface.

Ce qui est fort avec wrkflow, c’est surtout le support quasi-complet des fonctionnalités de GitHub Actions. Les Matrix builds ? Ça passe ! Les Container actions ? Bah ouais, pas de problème ! Tout ce qui est JavaScript actions ? Check ! Même chose pour les Composite actions et les workflows réutilisables et même les fichiers d’environnement GitHub sont supportés. Bon, il y a quelques limitations évidemment. Vous ne pouvez pas par exemple mettre de secrets GitHub (ce qui est logique), et y’a pas de support Windows/macOS runners, ni pas d’upload/download d’artifacts. Mais pour 90% des cas d’usage, c’est largement suffisant.

Wrkflw s’inscrit dans une tendance plus large d’outils qui cherchent à remplacer Make et ses Makefiles cryptiques. Je pense par exemple à Task (Taskfile) qui est un autre exemple populaire, écrit en Go avec une syntaxe YAML plus moderne ou encore à Act, un autre outil open source qui fait à peu près pareil. Les développeurs cherchent clairement des alternatives plus lisibles et maintenables et wrkflw va encore plus loin en se spécialisant sur GitHub Actions.

Le mode Docker/Podman de wrkflw permet par exemple de créer des containers qui matchent au plus près l’environnement des runners GitHub. Et si jamais vous interrompez l’exécution avec Ctrl+C, pas de panique, puisque l’outil nettoie automatiquement tous les containers créés. Comme ça, y’aura plus de containers zombies qui traînent après vos tests.

Et pour tous ceux qui bossent en mode émulation sécurisée (sans Docker), wrkflw exécute les actions dans un environnement sandboxé. C’est moins fidèle à l’environnement GitHub mais au moins ça permet de tester rapidement sans avoir besoin d’installer Docker. Pratique sur des machines de dev légères ou des environnements restrictifs.

Le workflow de test devient donc le suivant : 1/ Vous modifiez votre YAML. 2/ Vous lancez wrkflw run . 3/ Vus voyez immédiatement si ça marche. 4/ Vous corrigez si besoin. 5/ Et c’est seulement ensuite que vous poussez sur GitHub. Plus de commits de debug, plus de CI cassée, plus de collègues qui râlent parce que la pipeline est tout rouge ^^.

L’outil est encore jeune bien sûr mais déjà très prometteur. Les prochaines versions devraient ajouter le support des secrets locaux, une meilleure intégration avec GitLab CI, et peut-être même le support des runners Windows/macOS.

Bref, si vous gérez des workflows GitHub Actions complexes, wrkflw va rapidement devenir indispensable à votre life.

A découvrir ici !

Spotizerr - Quand l'auto-hébergement rencontre votre conscience musicale

5 dollars, c’est tout ce qu’il faut pour écouter légalement 1000 fois votre artiste préféré sur S█████. Enfin, “légalement” au sens où S█████ l’entend, parce qu’avec 0,005$ par stream en moyenne, on peut difficilement parler d’un modèle équitable. C’est cette réflexion qui m’amène à vous parler aujourd’hui de Spotizerr.

L’idée derrière Spotizerr est assez maligne puisque ça consiste à utiliser l’excellente interface de recherche de S█████ pour trouver vos morceaux, puis à les télécharger depuis D████ en priorité pour obtenir du FLAC, avec un fallback sur S█████ si nécessaire. Le développeur Xoconoch ne cache pas son approche pragmatique dans le README où il écrit : “Supportez vos artistes directement (merch, concerts, dons), et considérez que 5$ leur permettent de compenser 1000 écoutes”. C’est le strict minimum éthique selon lui.

Techniquement, ce qui distingue Spotizerr des autres solutions comme Spotizer (notez la différence d’orthographe), c’est son approche vraiment orientée self-hosting avec une interface web progressive (PWA). Vous pouvez l’installer comme une app native sur mobile ou desktop, avec des thèmes clairs/sombres, et surtout un système de monitoring intelligent qui surveille automatiquement vos playlists et artistes favoris pour télécharger les nouveautés.

Le système de queue est particulièrement bien pensé : téléchargements concurrents configurables, mises à jour en temps réel via Server-Sent Events, prévention automatique des doublons, et persistance de la queue même après un redémarrage du navigateur. Vous pouvez télécharger des tracks individuels, des albums complets, des playlists entières (même celles avec plus de 1000 morceaux), ou carrément la discographie complète d’un artiste avec des options de filtrage.

Pour l’installation, c’est du Docker classique et il vous faudra créer un fichier .env (basé sur l’exemple fourni), configurer vos identifiants Redis, PUID/PGID, UMASK, et lancer le docker-compose. Pour S█████, le développeur recommande d’utiliser son outil spotizerr-auth sur un PC avec le client S█████ installé pour simplifier l’authentification. Pour D████, il suffit de récupérer le cookie “arl” depuis votre navigateur (F12 → Application/Storage → Cookies → copier la valeur “arl”).

Le support multi-utilisateurs est intégré avec authentification JWT, SSO via Google et GitHub, et un panneau d’administration pour gérer tout ce petit monde. L’historique des téléchargements est complet avec métadonnées, analytics de succès/échec, recherche et filtrage, et même l’export des données avec les IDs des services externes.

Au niveau configuration audio, vous pouvez définir la qualité par service (avec les limitations selon votre type de compte), convertir vers MP3, FLAC, AAC, OGG, OPUS, WAV ou ALAC dans différents bitrates, personnaliser les patterns de nommage des fichiers et dossiers, et même filtrer le contenu explicite si nécessaire.

Notez qu’au niveau des rémunération d’artistes, le champion c’est Qobuz qui paie jusqu’à 0,03€ par stream, soit près de dix fois plus que S█████. Apple Music fait un peu mieux avec 0,007 à 0,01€ par stream, tandis que YouTube Music reste le cancre avec 0,0008€ par stream. Pendant ce temps, Amazon, Tidal et D████ proposent du FLAC en standard, alors que S█████ résiste encore et toujours sur la qualité audio haute définition.

Le système de surveillance de Spotizerr est vraiment pratique puisqu’il vous permet de configurer des intervalles de vérification, d’ajouter des playlists ou des artistes à surveiller, et les nouveaux contenus sont automatiquement téléchargés. Pour une discographie complète, vous sélectionnez les types de releases (albums, singles, compilations) et tout est mis en queue automatiquement.

Le projet est basé sur la bibliothèque deezspot et reste dans une zone grise légale. Le développeur est transparent là-dessus : c’est pour un usage éducatif et personnel, respectez les conditions d’utilisation des services et les lois sur le copyright de votre pays. Les fichiers téléchargés conservent les métadonnées originales, et les limitations s’appliquent selon votre type de compte.

Bref, pour ceux qui cherchent une solution self-hosted complète pour gérer leur bibliothèque musicale, Spotizerr s’intègre bien dans un stack avec Lidarr pour la gestion de collection et Navidrome pour le streaming. C’est une approche qui permet de garder le contrôle sur sa musique tout en profitant des catalogues des services de streaming.

Et oui, j’ai caviardé un peu l’article parce que ça m’amusait de rajouter un peu de mystère ^^.

Managing container networks in Windows Server 2025

Windows Server 2025 can run Windows and Hyper-V containers. The former share resources like the kernel with the host OS and have process-level isolation, while the latter run in virtual machines. To enable communication between containers and with physical systems, you must configure the network accordingly.

Source

Install Apple Container CLI: Running containers natively on macOS 15 (Sequoia) and macOS 26 (Tahoe)

In my previous article, I introduced Apple's new Containerization solution for macOS and compared it with Docker Desktop. In today's post, I'll explain how to install Apple’s new Container CLI—a Swift‑based, open‑source tool—for running OCI‑compliant Linux containers on your Mac. Native container support will launch in macOS 26 (Tahoe), but you can install and utilize the Container CLI on macOS 15 with certain limitations. In the step‑by‑step guide, I will explain how to install, configure, and start running containers with Apple’s fresh alternative to Docker Desktop.

Source

Apple Container vs. Docker Desktop

At WWDC 2025, Apple announced the Containerization Framework and Container CLI, a solution for creating and running Linux containers as lightweight virtual machines on Mac. This article is geared toward developers, sysadmins, and DevOps engineers who want to understand how Apple Container works under the hood and how it compares to Docker Desktop.

Source

❌