— 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

— Permalink