L'autre jour, je voulais juste exposer un petit service tournant sur mon NAS pour y accéder à distance quand je suis en déplacement. Alors je me suis dit "Allez, je vais faire ça propre avec Traefik" mais bon, debugger du fichier YAML parce qu'on oublie des indentations à un moment ça casse la tête. J'ai +40 balais et pas que ça à foutre.

Si vous hébergez vos propres services à la maison (self-hosting powaaaah !) et que vous êtes un peu bordélique comme moi, vous installez un truc, puis un autre, et vous finissez avec une collection de ports impossible à mémoriser du genre monip:8080, monip:32400, monip:9000… Aarrgh, l'enfer !!!

Et ne me lancez pas sur la gestion des certificats SSL !! Si vous voulez faire ça bien, faut générer des certificats Let's Encrypt à la main pour chaque service, modifier les fichiers de conf Nginx en priant pour ne pas oublier un point-virgule… et j'en passe et des pas mûres… Alors je sais, oui ça nous occupe et pendant ce temps là, on n'est pas dehors en train de voler des voitures mais j'sais pas vous, moi j'ai mieux à faire.

Hé bien, figurez-vous les copains, qu'il existe un outil qui transforme ce cauchemar en promenade de santé. Ça s'appelle Nginx Proxy Manager, et une fois que vous aurez lu mon article et testé vous penserez : "Mais pourquoi je me suis emmerdé la vie pendant tout ce temps, mortecouille ?!".

Nginx Proxy Manager, c'est quoi ce truc ?

En gros, c'est une interface graphique super propre pour gérer Nginx. Au lieu de taper des lignes de commandes et d'éditer des fichiers de config obscurs, vous avez un beau tableau de bord pour :

1. Rediriger vos domaines (ex: plex.mondomaine.fr) vers vos conteneurs Docker.
2. Gérer vos certificats SSL (HTTPS) automatiquement.
3. Sécuriser l'accès à certains services avec un mot de passe.

Mais en vrai, c'est plus riche que ça. Dans la barre du haut, vous avez tout ce qu'il faut pour piloter votre reverse proxy comme un adulte responsable : des hosts (proxy, redirections, streams, 404), des certificats (Let's Encrypt ou certifs locaux), des utilisateurs, des règles d'accès (Access Lists), et même des logs d'audit pour savoir qui a fait quoi (au cas où un de vos potes "teste un truc vite fait" et casse tout).

C'est le reverse proxy pour ceux qui veulent que ça marche, tout de suite, sans devenir ingénieur réseau bac+12 ou devoir se taper 2h d'explications IRL d'un barbu qui pue de la gueule ^^.

Installation en 3 minutes chrono (avec Docker)

Bon, on ne va pas y passer la nuit. La méthode la plus propre, c'est évidemment Docker Compose. Si vous ne l'avez pas, installez-le (allez, un petit apt install docker-compose et on n'en parle plus).

Créez un dossier nginx-proxy-manager et collez-y ce fichier docker-compose.yml :

version: '3.8'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 restart: unless-stopped
 ports:
 - '8080:80' # Port HTTP public
 - '8181:81' # Port d'administration (à garder pour vous)
 - '8443:443' # Port HTTPS public
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt
 db:
 image: 'jc21/mariadb-aria:latest'
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: 'npm'
 MYSQL_DATABASE: 'npm'
 MYSQL_USER: 'npm'
 MYSQL_PASSWORD: 'npm'
 volumes:
 - ./mysql:/var/lib/mysql

Petit piège à éviter : Faites gaffe si vous avez déjà un serveur web (Apache ou Nginx) qui tourne sur la machine hôte. Il va falloir couper le service ou changer les ports, sinon Docker va vous jeter une erreur parce que le port 80 est déjà pris. Du coup, vérifiez bien avec un petit netstat -tulpn | grep 80 avant de lancer la sauce.

Ah oui, et si vous utilisez un pare-feu comme UFW (ce que je vous recommande chaudement), n'oubliez pas d'ouvrir le port 81 : ufw allow 81. Sinon, vous allez pleurer devant une page blanche et vous demander pourquoi ça marche pas.

Ensuite, lancez la bête :

docker-compose up -d

Et voilà ! C'est tout. Votre serveur tourne. Si vous avez des erreurs, c'est probablement parce que vos ports sont déjà utilisés. Ou que les dossiers data, Let's Encrypt et MySQL n'existent pas encore. Moi j'ai ça sur mon NAS :

La configuration que même ma grand-mère pourrait le faire

Ouvrez votre navigateur et allez sur http://votre-ip:8181 et créez vous un compte.

Une fois dedans, pour exposer un service, c'est ridicule tellement c'est easyyyy

1. Cliquez sur "Add Proxy Host".
2. Entrez votre nom de domaine (ex: nextcloud.mondomaine.fr).
3. Indiquez l'IP de la machine et le port du service (ex: 8080).
4. Allez dans l'onglet "SSL", cochez "Request a new SSL Certificate" et "Force SSL".
5. Sauvegardez.

En fait, le seul truc qui peut coincer, c'est la propagation DNS. Si vous venez d'acheter votre nom de domaine il y a 5 minutes, pas de panique si Let's Encrypt refuse de générer le certificat. Attendez une petite heure et réessayez. C'est classique.

Et hop, fini. Votre service est accessible en HTTPS, avec le petit cadenas vert qui va bien. Nginx Proxy Manager s'occupe de discuter avec Let's Encrypt et de renouveler le certificat tout seul. C'est carrément magique.

Tour d'horizon des fonctionnalités qui sauvent des week-ends

Parce que oui, Nginx Proxy Manager ne fait pas "juste" proxy + "cadenas". Dans le menu Hosts, vous avez plusieurs types de trucs à créer, et chacun sert à un usage bien précis. Et côté Certificats et sécurité, il y a de quoi faire sans sortir le marteau-piqueur.

Certificats Let's Encrypt (HTTP et DNS) + certifs locaux

On va commencer par le sujet qui donne des boutons : les certificats. Dans l'onglet Certificates, vous pouvez gérer tout ça au même endroit :

• Let's Encrypt en HTTP-01 : le classique. NPM ouvre la voie, répond au challenge, et basta. Pratique pour un service.mondomaine.fr exposé "normalement".
• Let's Encrypt en DNS-01 : là, c'est le mode "j'ai compris la vie". Vous pouvez valider le certificat via votre DNS (donc sans dépendre d'un port 80 accessible), et surtout ça permet les wildcards du style *.mondomaine.fr. Donc un seul certif et roule ma poule, même si vous ajoutez 12 sous-domaines demain à 3h du mat.
• Certificats locaux : vous pouvez aussi importer un certificat existant (genre un certif de votre boîte, un truc interne, un CA maison, ou même un self-signed si vous aimez vivre dangereusement). Ça évite de dépendre de Let's Encrypt si vous êtes en mode "tout en local, rien sur Internet".

Et le meilleur c'est que NPM gère le renouvellement automatique. Donc plus de rappel calendrier "renouveler les certifs" tous les 2 mois, sinon c'est le drame et tout le monde vous écrit "ça marche plus ton truc".

Plusieurs comptes, parce que tout le monde n'est pas "admin"

Dans Users, vous pouvez créer plusieurs comptes pour accéder à l'interface. Typiquement :

• un compte admin pour vous, le chef, le patron, le seigneur des reverse proxies.
• un compte "moins dangereux" pour quelqu'un qui doit juste consulter ou bidouiller un truc sans toucher à toute l'infra.

Et ça, couplé aux Audit Logs (j'y reviens juste après), c'est très pratique quand plusieurs personnes mettent les mains dedans. Parce que "c'est pas moi, j'ai rien touché" est une phrase universelle, on la retrouve dans toutes les cultures.

Access Lists, le videur à l'entrée

Alors ça, c'est une des fonctions les plus sous-cotées. Les Access Lists permettent de mettre en place des règles d'accès et de les réutiliser partout :

• Basic Auth (login/mot de passe) : parfait pour protéger une appli pas prévue pour être publique, ou un petit outil d'admin que vous ne voulez pas exposer "en clair".
• Allow/Deny par IP : le top pour dire "seulement depuis mon IP / mon VPN / mon réseau". Et là, même si quelqu'un devine votre URL, il se prend un mur.

Vous créez une Access List une fois, et ensuite vous l'appliquez à vos Proxy Hosts. Du coup, pas besoin de refaire 50 fois la même conf. C'est propre, c'est net, c'est carré.

Les redirections propres (HTTP -> HTTPS, domaine A -> domaine B, etc.)

Besoin de rediriger un vieux domaine vers un nouveau ? Ou de faire un joli http:// qui part systématiquement en https:// ? Les Redirection Hosts servent exactement à ça. C'est bête mais ça évite d'aller trifouiller des règles Nginx à la main.

Exemples typiques :

• mondomaine.fr -> www.mondomaine.fr
• ancientruc.mondomaine.fr -> nouveautruc.mondomaine.fr
• http -> https (pour les retardataires)

Streams - Quand ce n'est pas du HTTP mais que vous voulez quand même un reverse proxy

Le web, c'est bien, mais tout n'est pas en HTTP. Certaines applis parlent en TCP/UDP (bases de données, services réseau, protocoles chelous, etc.). C'est là que Streams entrent en jeu. Cette fonctionnalité vous permet de proxyfier des flux réseau, genre "ce port externe pointe vers ce port interne".

Alors oui, c'est plus "brut" que les Proxy Hosts, mais ça dépanne vraiment quand vous avez un service qui n'a rien à faire derrière un vhost HTTP. Et ça se configure aussi en 2 clics, sans incantations démoniaques.

404 Hosts - La sortie de secours

Les 404 Hosts, c'est la petite finition qui fait plaisir (non, rien à voir avec votre salon de massage préféré). Vous pouvez définir un "host poubelle" qui répond proprement quand quelqu'un tape un domaine qui n'existe pas chez vous, ou quand un bot scanne votre serveur en espérant trouver /phpmyadmin par magie.

Au lieu de laisser traîner une réponse moche ou ambiguë, vous renvoyez une 404 nette, propre, assumée. C'est pas de la sécurité absolue, mais c'est une bonne hygiène, et ça évite de donner trop d'infos aux curieux.

Audit Logs

Dans Audit Logs, vous avez l'historique des actions effectuées dans l'interface : création/modif de hosts, changements de certifs, etc. C'est le genre de truc dont on se fout… jusqu'au jour où on en a besoin. Et là, vous êtes content de pouvoir remonter le film de l'horreur.

Et enfin, mon bonus : Le mode "je sais ce que je fais" (les options avancées Nginx)

Et si un jour vous voulez aller un cran plus loin, NPM permet aussi d'ajouter des réglages plus "Nginx pur jus" par host (headers, règles, conf custom). Donc vous commencez en mode clic-clic, et si vous devenez un peu psycho sur l'optimisation, vous pouvez aussi affiner. Sans tout casser, normalement.

2/3 conseils de daron pour éviter les boulettes

• Ne laissez pas l'admin ouvert au monde : le port 8181 (ou votre port d'admin) c'est "pour vous". Si possible, limitez-le via pare-feu / VPN / IP autorisées. C'est le panneau de commande de votre château, pas un distributeur de bonbons.
• Utilisez les Access Lists pour tout ce qui est sensible : dashboards, outils d'admin, services pas prévus pour Internet, etc.
• Pensez au DNS-01 si vous voulez des wildcards ou si vous n'avez pas envie d'exposer le port 80.

Et par rapport aux autres ?

Je vous vois venir les puristes : "Oui mais Traefik c'est mieux car c'est dynamique". C'est vrai. J'ai testé Traefik, et c'est une tuerie pour les environnements qui bougent tout le temps. Mais sa config en YAML peut vite devenir une usine à gaz si vous débutez. Caddy est top aussi (un seul fichier de conf), mais il faut quand même mettre les mains dans le cambouis.

Perso, je pense que Nginx Proxy Manager est un excellent choix pour un homelab par exemple. C'est un peu le choix du confort, celui des grosses feignasses comme moi parce que c'est visuel, c'est du clic-bouton clic clic, et pour un petit serveur perso, c'est franchement imbattable.

Bref, si vous galérez encore avec vos vhosts Nginx, arrêtez de vous faire du mal. Installez ça, et profitez de la vie (et de vos week-ends).

Nginx Proxy Manager c'est par ici !

Ce matin, je discutais avec Emmanuel (un lecteur fidèle) sur mon Linkedin Korben et il m'a partagé une ressource vraiment chouette. Si comme moi vous jouez un peu parfois avec un serveur Proxmox qui tourne à la maison pour vos expérimentations ou votre domotique, vous savez que configurer chaque VM ou conteneur LXC peut vite devenir chronophage. On copie-colle des commandes, on installe des dépendances, on se plante, on recommence... La routine quoi sauf que cette routine peut vite devenir reloue.

Hé bien, fini la galère !!!! Le projet dont je veux vous parler aujourd'hui s'appelle Proxmox VE Helper-Scripts et c'est une collection communautaire de scripts (plusieurs centaines !) qui permet d'installer et de configurer tout un tas de services en une seule ligne de commande.

En gros, c'est une immense boîte à outils pour votre hyperviseur. Vous avez besoin d'une instance Home Assistant pour gérer des ampoules connectées ? Hop, vous lancez le script et ça vous crée le conteneur LXC tout propre. Vous voulez monter un serveur média avec Plex ou Jellyfin ? Pareil, c'est généralement plié en quelques minutes (selon votre connexion évidemment).

Vous allez sur le site, vous cherchez l'outil qui vous intéresse, vous copiez la commande bash fournie (du style bash -c "...") et vous la collez dans le shell de votre nœud Proxmox. Et hop, l'assistant se lance. Il vous pose quelques questions (IP statique ou DHCP, espace disque, RAM... ce genre de trucs classiques) et puis tente de s'occuper de tout le reste (si les planètes sont bien alignées et que votre karma est au top !).

Je trouve ça génial parce que non seulement ça gère l'installation, mais ça s'occupe aussi des mises à jour. Mais bon, attention quand même parce qu'une mise à jour upstream peut parfois casser le script, donc prudence. C'est d'ailleurs super utile si vous utilisez Proxmox sur un Raspberry Pi (via Pimox), même si l'architecture ARM peut poser souci avec certains scripts. D'ailleurs, bonne nouvelle pour les utilisateurs de Pimox : il existe Pimox-Scripts , un portage de ces mêmes Helper Scripts mais adaptés spécifiquement pour ARM/Raspberry Pi. Tous les scripts ne sont pas encore dispos (moins de contributeurs), mais y'a déjà de quoi faire !

Parmi les scripts disponibles, on retrouve les classiques Docker, AdGuard Home, Pi-hole, mais aussi des trucs plus pointus pour le monitoring ou la sécurité. C'est vraiment très complet, y compris si vous êtes dans une optique de création de lab de cybersécurité .

Après, je dois quand même vous faire une petite mise en garde de circonstance. Car comme d'habitude, exécuter des scripts bash trouvés sur le net direct en root... comment dire... c'est jamais sans risque. Le code est open source et maintenu par une communauté active, ça facilite l'audit, mais ce n'est pas une garantie de sécurité absolue. Sauf si vous aimez vivre dangereusement, jetez toujours un œil au code avant de valider. La confiance n'exclut pas le contrôle !!

Un grand merci à Emmanuel pour le tuyau initial et à Karl pour l'info sur Pimox-Scripts !

Tim Berners-Lee, le papa du Web, tape du poing sur la table . Dans cette interview accordée au Guardian aujourd'hui, il explique en gros qu'il est grand temps de "reprendre Internet" aux géants qui l'ont transformé en machine à fric.

Il était temps que ça sorte !

Parce lui parle carrément d'une "bataille pour l'âme du web". Rien que ça ! Selon lui, le web actuel est devenu un truc "optimisé pour la méchanceté" et la surveillance de masse. Je ne peux pas le contredire sur la méchanceté et en effet, la centralisation excessive et le modèle actuel ont largement perverti sa vision d'origine.

Sa solution, vous en avez peut-être déjà entendu parler, c'est le projet Solid (porté notamment par sa startup Inrupt ) qui propose de stocker ses données dans des "pods" personnels. L'idée c'est de découpler les données des applications. Vous gardez vos infos dans votre pod (hébergé chez vous ou chez un fournisseur de confiance) et vous donnez accès aux apps au cas par cas. Comme ça on peut reprendre (un peu) le contrôle de notre vie en ligne.

Il s'inquiète aussi pour l'IA et réclame un "CERN de l'IA" pour éviter que la technologie ne nous échappe totalement. C'est mal barré ça je pense, même si je suis d'accord avec lui.

Perso en ce qui me concerne, j'ai jamais changé mon fusil d'épaule et vous le savez, puisque depuis toujours j'invite tout le monde dès que j'en ai l'occasion à créer son site, à créer son forum, à créer sa plateforme et à en finir avec ces conneries de plateformes centralisée.

Alors peut-être que ça ne marchera pas, ou peut-être que son appel sera entendu et que ça marchera. Mais en tout cas, si à un moment, vous voulez publier des trucs sur le web, essayez un tout petit peu d'héberger vos propres trucs vous-même. Attentio, je ne vous dis pas de monter un cluster Kubernetes dans votre salon (sauf si vous kiffez ça) ou de switcher en mode auto-hébergement pur et dur sur un Raspberry Pi (bien que ce soit très cool avec Yunohost )... Non, vous pouvez simplement prendre un hébergeur comme O2Switch par exemple. C'est pas très cher.

Je crois que quand on a une passion, on peut mettre un petit peu d'argent dedans pour se faire plaisir. Puis ça peut marcher dans l'autre sens aussi... À l'époque, moi je me souviens, il y avait un pote qui ouvrait son serveur pour qu'on puisse y mettre des pages web et ce genre de truc via un petit FTP. Donc ceux qui savent gérer des serveurs web, vous pouvez peut-être aussi envisager de créer un espace non pas accessible à la Terre entière, mais au moins accessible à vos amis, à des connaissances, gratuitement. Un truc un peu facile à utiliser, à l'ancienne...

Voilà, je trouverai ça vraiment cool que ça revienne un petit peu à la mode et que le web se repeuple. Qu'on sorte un peu des GAFAM et des algos toxiques...

Quelques pages statiques et c'est suffisant pour s'exprimer sans se prendre le chou avec la technique. J'en suis la preuve vivante ! Le site sur lequel vous êtes est 100% statique. On n'a pas besoin de monter une startup à chaque fois qu'on veut faire un site.

Je ne sais pas si les fournisseurs d'accès internet offrent toujours un petit bout d'espace web, mais si vous avez ça qui traîne, profitez-en aussi.

Bref, écoutez Papi Tim et Tonton Korben et ensemble, reprenons le contrôle, un serveur à la fois.

Source

Si vous en avez marre de confier vos notes perso à Notion ou Evernote et que vous voulez reprendre le contrôle de vos données, Alexandrie va vous plaire ! C'est une app open source française qui permet de prendre des notes en Markdown au travers d'une interface plutôt moderne, tout en gardant vos données là où vous voulez qu'elles soient : Chez vous.

Alexandrie, c'est avant tout un éditeur Markdown amélioré qui vous permet d'organiser vos notes par workspaces, catégories et tags. L'interface est clean, la recherche instantanée, et vous pouvez exporter vos notes en PDF ou Markdown !

Ce qui est cool, c'est que l'app fonctionne aussi hors ligne grâce à la technologie PWA. Vous pouvez donc bosser sur vos notes dans le train ou l'avion, et tout se synchronise dès que vous avez du réseau. Et si vous voulez partager des notes avec d'autres personnes, y'a un système de permissions pour gérer qui peut voir et modifier quoi.

Côté technique, Alexandrie tourne sur Vue/Nuxt pour le frontend et Go pour le backend, avec une base MySQL et un stockage compatible S3 et comme d'hab, tout ça se déploie avec un simple "docker compose up".

La grosse différence avec Notion ou Obsidian, c'est que vous contrôlez tout. Vos données restent sur votre serveur ou votre machine, rien ne transite par des serveurs américains. C'est donc de l'auto-hébergé, 100% hors ligne si vous voulez, et c'est compatible avec plein d'autres apps Markdown si vous souhaitez migrer plus tard.

C'est bien de voir une app française qui mise sur la souveraineté des données plutôt que sur le cloud américain ! C'est en train de devenir quelque chose de très recherché en ce moment. Bon après, faut être prêt à gérer soi-même l'hébergement, mais avec Docker c'est pas la mer à boire non plus.

Et si vous appréciez ce genre de découvertes, vous pouvez me soutenir sur le Patreon de Korben .

Voilà, si vous cherchez une alternative open source à Notion qui respecte votre vie privée, c'est par ici .

"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 !

Vous avez 15 ans d'emails répartis sur 4 comptes différents et vous aimeriez bien pouvoir chercher dedans sans devenir complétement fou ? Bichon est fait pour vous . C'est un archiveur d'emails open source écrit en Rust qui synchronise vos boîtes mail et vous permet de tout fouiller via une interface web ultra léchée.

Le truc c'est que Bichon n'est pas un client mail. Vous ne pouvez pas envoyer ou recevoir de messages avec. C'est vraiment un outil d'archivage pur qui se connecte à vos serveurs IMAP, aspire tous vos emails, les compresse, les déduplique et les indexe pour que vous puissiez faire des recherches full-text dessus pour par exemple retrouver ce mail de 2012 où votre ex vous expliquait sa recette secrète du tiramisu.

L'interface web est plutôt propre, codée en React avec ShadCN UI. Vous pouvez filtrer par compte, par dossier, par expéditeur, par nom de pièce jointe, par taille, par date... Y'a même un dashboard avec des stats sur vos emails si vous aimez les graphiques. Et bonne nouvelle, le WebUI est disponible en 18 langues, donc le français est de la partie !

Vous savez comment ça se passe, on traîne sur le web, on tombe sur un article passionnant de 4 000 mots sur Korben.info, mais on n'a absolument pas le temps de le lire là, tout de suite. Alors on ouvre un onglet. Puis deux. Puis cinquante. Et à la fin de la semaine, votre navigateur ressemble à une forêt vierge de Favicons et votre RAM pleure du sang.

Pourtant, il existe des solutions comme Wallabag (ou feu-Pocket), mais si vous êtes un peu maniaque du contrôle comme moi, vous cherchez peut-être un truc plus moderne, plus léger et surtout que vous pouvez également héberger vous-même sur votre propre serveur. C'est là que Readeck entre en scène.

C'est un outil de "read-it-later", c'est-à-dire une application qui vous permet de sauvegarder du contenu web pour le consulter plus tard, une fois que vous avez la tête reposée. L'idée de Readeck, c'est donc de garder l'histoire mais de virer tout le reste : les pubs, les popups de cookies qui vous sautent au visage et les mises en page qui font mal aux yeux. On se retrouve avec un texte pur, propre, et une interface qui ne vous agresse pas.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/readeck-read-it-later-self-hosted/readeck-read-it-later-self-hosted-1.webm">lien vers la vidéo</a>.

Si vous développez un logiciel open source auto-hébergé, vous connaissez sûrement ce dilemme qui est de comment savoir si votre projet est réellement utilisé sans devenir l'affreux Big Brother que vous combattez ? Soit vous ne mesurez rien et vous codez dans le vide, soit vous collez du Google Analytics ou assimilé et vous trahissez l'esprit même du self-hosting.

Benjamin Touchard (que certains d'entre vous connaissent peut-être via son projet Ackify ) a décidé de résoudre ce problème avec SHM, pour Self-Hosted Metrics . Son idée c'est de proposer une télémétrie respectueuse de la vie privée, où chaque instance génère sa propre identité cryptographique dès le premier démarrage.

Concrètement, quand vous intégrez le SDK dans votre application (dispo en Go et Node.js 22+), chaque installation génère une paire de clés Ed25519, un peu comme quand vous générez vos clés SSH pour la première fois. Tous les échanges avec votre serveur SHM sont ensuite signés cryptographiquement, ce qui garantit l'intégrité des requêtes et leur origine. L'instance a une identité persistante (pseudonyme), mais ça n'identifie pas l'utilisateur final.

Côté données collectées, ensuite c'est vous qui décidez. Votre app envoie périodiquement un JSON avec les métriques que vous avez définies, et le dashboard s'adapte dynamiquement. Y'a pas de schéma imposé, pas de PII (données personnellement identifiables) et par défaut, le SDK collecte aussi des infos système (OS, CPU, RAM), mais c'est désactivable.

Pour ceux qui veulent héberger le bouzin, c'est du Docker classique... Vous créez un fichier compose.yml, vous configurez le DSN PostgreSQL, vous récupérez les migrations SQL, et hop un docker compose up -d. Le dashboard est alors accessible par défaut sur le port 8080 et affiche automatiquement vos métriques métier, la distribution des versions, le nombre d'instances actives, etc.

Et pour les utilisateurs finaux qui ne veulent vraiment pas participer, un simple DO_NOT_TRACK=true dans les variables d'environnement désactive complètement la télémétrie.

Le code du serveur est sous licence AGPL (les SDKs ont leur propre licence, vérifiez sur le dépôt) et y'a aussi des badges SVG à coller dans vos pages README pour afficher fièrement le nombre d'instances de votre app qui tournent.

Bref, si vous distribuez un logiciel auto-hébergé et que vous voulez savoir combien d'instances sont actives sans compromettre la vie privée des utilisateurs, c'est le top !

Merci à Benjamin pour le partage !

Si comme moi vous avez une enceinte Bose SoundTouch qui traîne chez vous, vous avez peut-être appris que la bestiole allait bientôt perdre son cerveau "cloud". Bose a en effet annoncé la fin du support pour le 6 mai 2026, et de ce que j'ai compris, ça veut dire que votre enceinte va se transformer en brique connectée qui ne se connecte plus à grand chose.

Sauf que non !

Bose a fait un truc plutôt cool puisqu'ils ont publié la documentation complète de l'API locale de leurs enceintes . Du coup, même quand les serveurs Bose fermeront boutique, vous pourrez continuer à bidouiller votre enceinte en local.

Perso, j'ai une petite SoundTouch 10 qui fait bien le boulot depuis des années, donc cette nouvelle me fait plutôt plaisir ! L'API tourne sur deux ports : le 8090 pour les commandes REST classiques (volume, presets, now_playing...) et le 8080 en WebSocket pour les notifications en temps réel. Le protocole s'appelle "gabbo", et avec ça, y'a de quoi faire le ménage dans vos automatisations.

Un petit curl http://votre-enceinte:8090/volume et vous récupérez le niveau sonore. Un autre sur /presets et vous avez vos stations favorites. Et comme la découverte se fait en SSDP ou MDNS, ça s'intègrera nickel avec n'importe quel système domotique.

Et visiblement la communauté n'a pas attendu pour s'y mettre puisqu'il y a déjà plus d'une centaine de projets sur GitHub qui exploitent cette API. Le plus abouti c'est probablement SoundTouchPlus pour Home Assistant, qui permet de contrôler toute la famille d'enceintes depuis votre dashboard.

Après ce qui va disparaître avec le cloud, c'est surtout les presets synchronisés et le streaming direct depuis l'app Bose. Mais le Bluetooth, l'AirPlay, Spotify Connect et le multiroom resteront fonctionnels et avec l'API locale, vous pouvez recréer vos presets en dur. Ouf !

C'est un peu le même délire que ce qui s'est passé avec les thermostats Nest ... quand le fabricant lâche l'affaire, c'est la communauté qui prend le relais sauf qu'ici, Bose joue le jeu en documentant proprement leur API avant de couper les serveurs. Et ça, c'est suffisamment rare pour être souligné !

Voilà... Si vous avez des SoundTouch, allez jeter un œil à l'API avant mai, histoire de préparer votre migration vers du 100% local.

Source

Voilà un outil qui va faire plaisir aux possesseurs de homelabs qui surveillent leur consommation de ressources comme le lait sur le feu !

Car si vous êtes comme moi, vous avez probablement une ribambelle de conteneurs qui tournent H24 sur votre bécane. Et je vous raconte pas tous ceux qui tournent alors que je m'en sers qu'une fois par an... breeeef...

Car même si un processus en "idle" ne consomme pas forcément grand-chose, c'est quand même un peu moisi de laisser tourner des services pour rien, non ? (oui, j'ai une âme d'écologiste de la ressource système). D'ailleurs si vous cherchez une solution d' authentification légère pour vos conteneurs Docker , y'a des solutions qui vont dans le même sens.

C'est là qu'intervient ContainerNursery , un petit utilitaire écrit en Node.js qui se comporte comme un reverse proxy intelligent qui va tout simplement stopper vos instances Docker quand aucune requête HTTP ou connexion WebSocket n'est détectée pendant un certain temps, et les redémarrer d'un coup de baguette magique dès qu'une nouvelle requête pointe le bout de son nez.

Pour ceux qui se demandent s'il est possible de mettre en pause un conteneur proprement, sachez que ContainerNursery va plus loin que le simple docker pause. Il arrête carrément le conteneur pour libérer la RAM et éviter les réveils CPU inutiles. Et il ne fait pas ça à la sauvage puisqu'il vérifie par exemple s'il n'y a pas de connexions WebSocket actives proxifiées avant de tout couper.

Hé oui, quand on n'est pas un connard, on évite de déconnecter un utilisateur en plein milieu de sa session.

docker run \
 --name='ContainerNursery' \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /mnt/ContainerNursery/config:/usr/src/app/config \
 ghcr.io/itsecholot/containernursery:latest

Aujourd’hui, je vous propose de découvrir Pimmich, un cadre photo connecté open source basé sur Raspberry Pi, pensé pour afficher vos souvenirs sans cloud ni abonnement, en restant 100% local. Avec les récents changements côté Google Photos, beaucoup d’entre vous ont dû revoir leurs habitudes… et Aurélien a eu le bon réflexe : s’appuyer sur […]

Cet article Pimmich – Un cadre photo connecté open source basé sur Raspberry Pi a été publié en premier sur Framboise 314, le Raspberry Pi à la sauce française.....

Auto-hébergement complet de votre infrastructure derrière Cloudflare avec accès de gestion via Warp et Zero Trust.

L’article Auto-hébergement derrière Cloudflare est apparu en premier sur The Abyss Project.