Vous voulez regarder une vidéo YouTube avec des potes qui habitent à l’autre bout du monde sans que ça rame ? Ou vous devez faire une démo produit à un client sans avoir à lui envoyer 50 captures d’écran ? Ou mieux vous avez besoin d’un navigateur jetable qui ne laisse aucune trace après utilisation ?

Et bien pour tout ça et plus encore, voici Neko , un navigateur virtuel auto-hébergé qui tourne dans Docker et utilise WebRTC pour streamer l’écran à plusieurs utilisateurs en même temps. C’est un outil développé par m1k1o et ça permet de créer très facilement des sessions de navigation partagées avec une latence inférieure à 300 millisecondes.

Vous lancez donc Neko sur votre serveur Docker, vous accédez à l’interface web, et vous avez un navigateur complet qui tourne dans le cloud. Plusieurs personnes peuvent se connecter à la même session et voir exactement le même écran en temps réel. L’hôte de la session peut également donner ou retirer le contrôle aux participants. Un peu comme quand on partage son écran sur Zoom, mais en mieux parce que tout le monde voit le même flux avec une qualité parfaite.

D’ailleurs, la technologie derrière est plutôt intéressante puisque ça utilise du WebRTC. Ainsi, le flux média ne transite pas par un serveur centralisé mais directement en peer-to-peer entre les navigateurs. Les médias circulent via SRTP et les données via SCTP, du coup, vous avez un streaming ultra-fluide avec synchronisation audio et vidéo impeccable.

Neko affiche sur son site plusieurs cas d’usage assez pratiques. Vous pouvez par exemple organiser des watch party pour regarder des films ou séries ensemble. Vous pouvez aussi pourquoi pas faire des présentations interactives où tout le monde voit la même chose en direct. Vous pouvez l’utiliser pour du support technique à distance en montrant exactement sur quoi cliquer. Ou tout pour du debugging collaboratif quand vous galérez sur un bug avec un collègue.

Le projet supporte aussi l’automatisation avec Playwright ou Puppeteer, donc vous pouvez scripter des actions dans le navigateur virtuel. Pratique si vous devez faire des tests automatisés ou des interactions complexes sur des sites web.

Niveau sécurité et vie privée, Neko propose deux modes. Le mode persistent browser garde les sessions entre les connexions, donc vous pouvez retrouver vos onglets et votre historique. Et le mode throwaway browser qui crée une session isolée qui est détruite après utilisation, sans historique, cookies ou cache. Zéro trace !

Vous pouvez aussi l’utiliser comme jump host (hôte relais quoi…) pour accéder à des ressources internes de votre réseau sans exposer directement ces ressources. Ou pour protéger la propriété intellectuelle en permettant à des gens de consulter des documents sensibles sans pouvoir les télécharger ou les copier.

L’installation se fait via Docker avec plusieurs images disponibles puisque vous avez le choix entre Firefox, Chrome, Brave et d’autres navigateurs. Le projet est d’ailleurs assez complet avec des projets satellites comme Neko Rooms pour gérer plusieurs salles, Neko Apps pour créer un environnement virtuel complet dans le navigateur, et Neko VPN pour des connexions sécurisées. Vous pouvez même broadcaster sur Twitch, YouTube ou n’importe quel service compatible RTMP directement depuis Neko.

Notez que Neko ne se limite pas qu’aux navigateurs puisque vous pouvez faire tourner n’importe quelle application Linux dedans, comme VLC par exemple. C’est en réalité plutôt une machine virtuelle streamée qu’un simple navigateur.

Le projet est sous licence Apache 2.0, donc c’est complètement open source et il y a aussi un serveur Discord actif pour échanger avec la communauté.

Bref, si vous cherchez une alternative aux solutions propriétaires pour le partage d’écran ou les watch party, Neko fera le job. Et comme c’est auto-hébergeable et hyper flexible, vous gardez le contrôle sur vos données tout en ayant une grande liberté sur l’usage que vous en ferez ! A tester donc !

Merci à Lorenper pour le partage.

— Permalien

— Permalien

— Permalink

— Permalink

— Permalien

— Permalien

— Permalink

— Permalink

— Permalien

— Permalien

— Permalink

— Permalink

Au tout début, dès que je devais sélectionner des redirections de ports je faisais ça proprement, ça se suivait. Puis… j’ai glissé.

Alors que ce soit dans une optique de faire du propre, dans celle de vérifier si tous les ports ouverts sont bien utiles, quelle application utilise quoi ou quels ports traiter via un firewall/port-forward, il peut être utile d’en avoir une liste.

Si c’est simple à faire en console, c’est pas sexy, encore moins pratique.

Merci à Mostafa Wahied qui a mis en ligne l’outil Portracker Et merci à demonangex pour la découverte.

Ça s’installe en 2-2 en Docker, on peut utiliser le Dashboard pour monitorer plusieurs machines, on peut lister les ports Docker et/ou de l’hôte, c’est beau. On peut chercher par numéro de port, nom d’applciation etc.

Exemple de lancement, sur UNRAiD dans mon cas :

services:
  portracker:
    image: mostafawahied/portracker:latest
    container_name: portracker
    restart: always
    network_mode: host
    volumes:
      - /mnt/user/appdata/portracker/data:/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      - /mnt/user/appdata/portracker/db=/data/portracker.db
      - PORT=4999
      - INCLUDE_UDP=true
    labels:
      - com.centurylinklabs.watchtower.enable=true

L’intérêt d’un container Docker basé sur Alpine est de gagner de la place, beaucoup de place parfois, en partant d’une base très légère, dépourvue du superflu.
Sauf que de temps en temps, c’est pas pratique. J’ai migré mon AdGuardHome vers la version avec Redis et Unbound d’imTAIH.

Avantages d’Unbound avec la prélecture (prefetching) :

• Résolution DNS plus rapide : les enregistrements DNS fréquemment consultés sont résolus et mis en cache à l’avance.
• Latence réduite : moins de délais liés aux requêtes DNS, idéal pour les applications sensibles au temps de réponse.
• Meilleures performances réseau : les réponses étant déjà en cache, elles sont disponibles instantanément.

---

Avantages de l’utilisation de Redis :

Cache fiable : assure une réponse rapide même sous forte sollicitation.

Vitesse mémoire : Redis stocke les résultats DNS en mémoire pour un accès quasi instantané.

Débit optimisé : réduit la charge sur les serveurs DNS en évitant les requêtes répétitives.

Charge allégée : limite le nombre de requêtes vers l’extérieur.

Et donc c’est basé sur Alpine, qui n’embarque pas en standard tzdata

Ce qui ne m’arrange pas vu que je voudrais des logs d’AdGuardHome sur le bon fuseau horaire

Avec les Dockers de Linux Server, on peut ajouter des DOCKER_MODS. Là non. J’ai donc ajouté un script « AGH-tzdata » dans user-scripts qui installe tzdata et crée les dossiers nécessaires au boot de l’array et/ou à la MàJ du Docker que j’ai nommé AGH-Unbound-Redis.
Plus précisément, comme je tiens à passer par users-scripts et que du coup le script ne peut pas être relancé dès que le Docker est mis à jour, je fais en sorte que le script contrôle le Docker (tzdata installé etc) et si ce n’est pas le cas, il le fait. Le tout avec un log.

Le script : (mon fuseau est en dans le code directement : Europe/Paris)

#!/bin/bash

# Variables
CONTAINER="AGH-Unbound-Redis"
LOG_FILE="/var/log/agh-tz.log"
NOW=$(date "+%Y-%m-%d %H:%M:%S")

echo "[$NOW] Vérification du fuseau horaire dans $CONTAINER..." >> "$LOG_FILE"

# Vérifier si le Docker tourne
if ! docker ps --format '{{.Names}}' | grep -q "^${CONTAINER}$"; then
  echo "[$NOW] Le Docker $CONTAINER n'est pas lancé. Abandon." >> "$LOG_FILE"
  exit 0
fi

# Tester si tzdata installé
if docker exec "$CONTAINER" sh -c 'apk info tzdata >/dev/null 2>&1'; then
  echo "[$NOW]tzdata déjà installé." >> "$LOG_FILE"
else
  echo "[$NOW]Installation de tzdata..." >> "$LOG_FILE"
  docker exec "$CONTAINER" apk add --no-cache tzdata >> "$LOG_FILE" 2>&1
fi

# Configurer le fuseau horaire si incorrect
CURRENT_TZ=$(docker exec "$CONTAINER" date +"%Z")
if [ "$CURRENT_TZ" != "CEST" ] && [ "$CURRENT_TZ" != "CET" ]; then
  echo "[$NOW]Configuration du fuseau horaire Europe/Paris" >> "$LOG_FILE"
  docker exec "$CONTAINER" cp /usr/share/zoneinfo/Europe/Paris /etc/localtime
  docker exec "$CONTAINER" sh -c 'echo "Europe/Paris" > /etc/timezone'
else
  echo "[$NOW]Fuseau horaire déjà correct ($CURRENT_TZ)." >> "$LOG_FILE"
fi

# Reporter l'heure dans le log
CURRENT_DATE=$(docker exec "$CONTAINER" date)
echo "[$NOW]Heure actuelle dans le Docker : $CURRENT_DATE" >> "$LOG_FILE"
echo "----------------------------------------------------------" >> "$LOG_FILE"

Le rendu d’exécution dans le log :

[2025-07-25 19:44:01] Vérification du fuseau horaire dans AGH-Unbound-Redis...
[2025-07-25 19:44:01]tzdata déjà installé.
[2025-07-25 19:44:01]Fuseau horaire déjà correct (CEST).
[2025-07-25 19:44:01]Heure actuelle dans le Docker : Fri Jul 25 19:44:02 CEST 2025

Et contrôle de la date via la console :

root@HomeBox:/mnt/user/appdata# docker exec -it AGH-Unbound-Redis date
Fri Jul 25 19:46:45 CEST 2025

Je me remets sur l’article après le repas. Les logs affichent toujours 2h de retard.

Et… c’est là que je percute ! J’ai visiblement « digéré » avant de manger…

AdGuardHome utilise la timezone du navigateur dans les logs affichés. Timezone modifiée par mes paramètres stricts LibreWolf…

Sous un navigateur « propre », ça marche en effet impeccablement.

Bon, je laisse quand même mon script dont je suis content (avec sans doute trop de log d’ailleurs). Il me servira peut-être de base pour un autre souci avec un Docker basé sur Alpine ^^’

— Permalink

— Permalink

— Permalink