On était passé à côté de la mise à niveau. Mais sachez que depuis le début du mois, le programme d'informations HWiNFO est disponible en version 8.40.
The post Le programme HWiNFO est dispo en version 8.40, quelles nouveautés ? first appeared on Bhmag."Merde, le port 8080 est squatté par quoi encore ???"
Si vous touchez un peu à l'auto-hébergement ou que vous gérez plus de trois services sur un serveur, vous avez forcément déjà hurlé cette phrase devant votre terminal. C'est le grand classique... on lance un nouveau conteneur, ça plante, et on finit par passer 20 minutes à faire des netstat ou des lsof pour comprendre qui fait la loi sur le réseau. Bref, c'est le bordel, et c'est exactement là que
Portracker
entre en scène pour nous sauver la mise.
Développé par Mostafa Wahied, Portracker n'est pas un énième scanner de ports réseau agressif façon Nmap, mais plutôt une vigie interne pour vos machines. C'est un outil auto-hébergé qui va scanner son propre hôte pour cartographier en temps réel (enfin, avec un rafraîchissement périodique réglable, généralement toutes les minutes) tous les services qui tournent et les ports qu'ils occupent. L'idée, c'est d'avoir une vue propre et centralisée pour dégager ce vieux tableur Excel que vous oubliez de mettre à jour une fois sur deux.
Le truc est super bien foutu, surtout pour les fans de Docker. Pour ceux qui se demandent comment ça se passe sous le capot, l'outil fait intelligemment la distinction entre les ports internes d'un conteneur et ceux qui sont réellement exposés sur l'hôte.
Alors oui, ça marche comment pour mapper tout ça ? En gros, ça utilise les API natives pour voir que votre instance Ghost est sur le 2368 en interne mais ressort sur le 8080 à l'extérieur. C'est le genre de truc qui évite bien des migraines quand on commence à empiler 50 conteneurs. Il y a même un support aux petits oignons pour TrueNAS pour les amateurs de NAS costauds.
Côté dashboard, c'est du propre puisqu'on est sur une interface moderne avec React, Tailwind et Shadcn UI, avec un mode sombre (évidemment) et des filtres en live qui répondent au quart de tour.
Mais la vraie force de Portracker, c'est sa capacité à bosser en meute. Vous pouvez connecter plusieurs instances entre elles via un système de "Peers" (en peer-to-peer donc) pour tout centraliser sur un seul tableau de bord. Pratique si vous avez un serveur chez vous, un VPS chez OVH et une vieille machine qui traîne dans un placard. Vous pouvez même organiser ça avec une hiérarchie parent-enfant pour mapper vos machines virtuelles sous leurs hôtes physiques respectifs.
Techniquement, c'est du solide mais ça reste léger : du Node.js avec Express et des WebSockets pour le backend, et une base SQLite (via better-sqlite3) embarquée pour ne pas avoir à se fader la conf d'une base externe. Pour le déploiement, ça se passe via Docker et pour les paranos de la sécurité (je vous vois ^^), sachez que l'outil supporte désormais l'utilisation d'un Docker Socket Proxy (genre celui de Tecnativa). Ça permet d'éviter de filer les droits root sur votre socket Docker à n'importe qui. Et depuis la version 1.2.0, vous pouvez même verrouiller l'accès avec une vraie authentification.
Notez que pour fonctionner correctement et aller fouiller dans les entrailles du système, l'outil a besoin de certaines permissions (les fameuses capabilities Linux). Il lui faudra généralement SYS_PTRACE, et éventuellement SYS_ADMIN si vous le faites tourner sur Docker Desktop ou macOS. C'est le prix à payer pour avoir une visibilité totale sur ce qui se passe dans les tuyaux.
Le projet cartonne pas mal sur GitHub et la communauté est super active donc si vous en avez marre de jouer à cache-cache avec vos ports, c'est clairement l'outil qu'il vous faut pour reprendre le contrôle de vos déploiements sans finir en PLS à chaque conflit de port 80. Et si jamais vous stressez sur la sécurité de vos ports Docker, n'oubliez pas qu'on peut aussi jouer avec les règles iptables pour blinder tout ça, mais ça, c'est une autre histoire !
Merci à AeroStream972 pour la découverte !
A very detailed & insightful explanation of Stack Overflow surprising architecture, from their lead architect in 2016.
Alors que les solutions de monitoring serveur deviennent toujours plus complexes et dépendantes de stacks lourdes, deux projets open source (NdM: absence de licence) récents prennent le contre-pied de cette tendance : MonitorBox et Monitux. Leur objectif commun : revenir à un monitoring lisible, fiable et maîtrisable, pensé avant tout pour les administrateurs Linux.
MonitorBox part d’un constat largement partagé dans les équipes techniques : la multiplication des alertes engendre une fatigue des notifications, au point que les incidents critiques risquent d’être ignorés.
Le projet introduit une logique volontairement simple mais efficace : réduction des faux positifs par vérifications successives, séparation claire entre alertes critiques et informationnelles, et retour d’un outil longtemps abandonné mais redoutablement efficace : le pager (bipper).
En complément des notifications classiques, MonitorBox propose :
Le projet assume une philosophie pragmatique : mieux vaut peu d’alertes fiables que beaucoup d’alertes ignorées.
Code source : https://github.com/simple-group/MonitorBox
Présentation : https://www.ihaveto.be/2026/01/pourquoi-jai-ressuscite-le-pager-des.html
Monitux s’inscrit dans une démarche encore plus radicale de sobriété technique. Le projet se définit comme un outil de monitoring serveur sans base de données, sans langage interprété (PHP, Python, Node.js), et sans dépendances externes.
Il repose exclusivement sur :
Ce choix permet de limiter fortement la surface d’attaque, de simplifier l’installation et de garantir une excellente lisibilité du code. Monitux se destine particulièrement aux environnements où la stabilité, la sécurité et la compréhension priment sur la sophistication fonctionnelle.
Code source : https://github.com/simple-group/Monitux/
Présentation : https://www.ihaveto.be/2025/12/monitux-le-monitoring-serveur-revient.html
Bien que différents dans leur approche, MonitorBox et Monitux partagent une vision commune :
le monitoring ne doit pas devenir une boîte noire, ni un empilement de dépendances difficile à auditer. Ces projets s’adressent aux administrateurs et équipes techniques qui souhaitent reprendre le contrôle, réduire la complexité et privilégier des outils compréhensibles, durables et open source.
Les deux projets sont publiés sous licence libre et ouverts aux contributions.
NdM: aucune licence n'est mentionnée sur les deux projets en question, qui ne sont donc pas libres en l'état.
Commentaires : voir le flux Atom ouvrir dans le navigateur
"Build end-user AI bots. Alyvix visually interacts with any Windows application like ERPs, CRMs or web browsers.
Run and measure your business-critical workflows like a human would, but continuously."
Merci Holaf pour la découverte.
Je n’ai plus de Proxmox depuis des années à la maison, je le teste avec Docker : Ubuntu, Synology et UNRAiD.
Ça fait penser à Beszel mais en plus puissant et complet bien entendu.
Pulse s’utilise en toute logique avec un serveur et des agents. Le tout s’installe en Docker ou en dur.
C’est très musclé et sécurisé, ça permet la découverte de réseaux pour ajouter des nodes Proxmox notamment. Je l’utilise de manière très simple pour ce test :
Connexion
services:
pulse:
image: rcourtman/pulse:latest
container_name: pulse_serveur
ports:
- 7655:7655
volumes:
- /mnt/user/appdata/pulse:/data
restart: alwaysOn peut ensuite définir un compte d’accès
Je souhaite ajouter des clients Docker
Il faudra pour ça générer un token par client
Et tout est ensuite expliqué pour l’installer ou le retirer. C’est très bien fait.
Mais pour ma machine sous UNRAiD je préfère passer par un container Docker
docker run -d \
--name pulse-docker-agent \
-e PULSE_URL="http://192.168.0.195:7655" \
-e PULSE_TOKEN="a297b11d70d16c15e4eb9241ace555a19bff4279c98ffaa92de5bd9d0bc9bab7" \
-e PULSE_TARGETS="http://192.168.0.195:7655|a297b11d70d16c15e4eb9241ace555a19bff4279c98ffaa92de5bd9d0bc9bab7" \
-v /var/run/docker.sock:/var/run/docker.sock \
--restart always \
ghcr.io/rcourtman/pulse-docker-agent:latestEt je l’ai tout de suite dans ma liste de clients
Pour un NAS Synology je passe aussi par Docker. En revanche je suis leur recommandation pour ajouter un client sur la machine Ubuntu.
curl -fsSL http://192.168.0.195:7655/install-docker-agent.sh | bash -s -- --url http://192.168.0.195:7655 --token bc6f2c3e562d5c030a1b2b925a6f145050e214359542b3670a79a4a94a971c18root@StreamBox:/home/aerya# curl -fsSL http://192.168.0.195:7655/install-docker-agent.sh | bash -s -- --url http://192.168.0.195:7655 --token bc6f2c3e562d5c030a1b2b925a6f145050e214359542b3670a79a4a94a971c18
== Pulse Docker Agent Installer ==
[INFO] Primary Pulse URL : http://192.168.0.195:7655
[INFO] Install path : /usr/local/bin/pulse-docker-agent
[INFO] Log directory : /var/log/pulse-docker-agent
[INFO] Reporting interval: 30s
[INFO] API token : provided
[INFO] Docker host ID : cf13d13b-a0e2-4bc6-b755-2535f80b4932
[INFO] Targets:
[INFO] • http://192.168.0.195:7655
[INFO] Downloading agent binary
/usr/local/bin/pulse-docker-agent 100%[=======================================================================================================================================================================================================================================>] 6.85M --.-KB/s in 0.03s
[ OK ] Agent binary installed
[ OK ] Cleared any previous stop block for host
== Configuring systemd service ==
[ OK ] Wrote unit file: /etc/systemd/system/pulse-docker-agent.service
[INFO] Starting service
Created symlink /etc/systemd/system/multi-user.target.wants/pulse-docker-agent.service → /etc/systemd/system/pulse-docker-agent.service.
== Installation complete ==
[INFO] Agent service enabled and started
[INFO] Check status : systemctl status pulse-docker-agent
[INFO] Follow logs : journalctl -u pulse-docker-agent -f
[INFO] Host visible in Pulse : ~30 secondsEt j’ai bien mes 3 clients
Pulse est un outil sécurisé, très simple, très beau, trés complet, très léger. J’adopte !
