Sélectionner une page
Fail2ban pour Nginx Proxy Manager (NPM)

Fail2ban pour Nginx Proxy Manager (NPM)

Article de la série « Mon ordinateur Ubuntu » 

Contexte

Environnement cible : un ordinateur Ubuntu sur lequel sont installés Nginx Reverse Proxy (NPM), Portainer, Home Assistant et Stirling PDF. Tout est déployé sous forme de containers Docker avec des chemins absolus (Bind Mounts), sans volumes nommés. Stirling PDF et Home Assistant sont accessibles via des URL externes, ce qui impose une sécurisation rigoureuse.

L’objectif est d’ajouter Fail2Ban pour passer d’une sécurité passive (certificats Let’s Encrypt) à une sécurité active.

Qu’est-ce que Fail2Ban ?

Les certificats Let’s Encrypt garantissent que la connexion est chiffrée (personne ne peut lire ce qui transite). Fail2Ban agit comme un videur à l’entrée.

Contre les attaques par brute force – sa mission principale. Si quelqu’un tente de deviner un mot de passe sur une page d’authentification, Fail2Ban détecte les échecs répétés dans les logs et bannit l’IP au niveau du pare-feu (iptables).

Contre les bots de scan (DoS léger) – il bloque les robots qui scannent le serveur trop rapidement à la recherche de vulnérabilités.

Contre la recherche de fichiers sensibles – il bannit les IPs qui tentent d’accéder à des dossiers inexistants mais critiques (.env, wp-config.php, /admin).

Résumé : HTTPS garantit que le tuyau est sécurisé, mais pas que la personne au bout du tuyau est autorisée à entrer. Le HTTPS empêche l’espionnage sur le Wi-Fi public. Fail2Ban empêche l’attaquant de frapper 10 000 fois à la porte.

Vérifier le format des logs NPM (étape préalable)

Avant toute configuration, il faut s’assurer que NPM enregistre les vraies IPs publiques des visiteurs dans ses logs, et non l’IP interne du réseau Docker.

Commande de vérification – ouvre un terminal sur Ubuntu et inspecte un fichier de log :

cat /home/USER/docker/nginx-proxy-manager/data/logs/proxy-host-1_access.log | head -20

Cherche le champ [Client X.X.X.X] dans chaque ligne de log.

✓  Si tu vois des IPs publiques (ex: 205.210.x.x, 45.84.x.x) dans [Client …] : NPM transmet déjà les bonnes IPs, aucune configuration supplémentaire n’est nécessaire.

⚠  Si tu vois des IPs internes Docker (ex: 172.18.x.x) dans [Client …] : Fail2Ban sera inefficace et risque de bannir ta passerelle Docker. Ajoute les proxy_set_header dans l’onglet Advanced de chaque Proxy Host dans NPM (voir ci-dessous).

Note importante sur les IPs dans les logs NPM – le champ [Sent-to X.X.X.X] contient l’IP interne de ta machine Linux (destination du trafic) : c’est normal. Le champ [Client X.X.X.X] est la seule IP qui compte pour Fail2Ban (source du trafic entrant).

Si les IPs internes sont présentes – configuration dans NPM – dans l’interface NPM, pour chaque Proxy Host (Stirling PDF, Home Assistant…), onglet Advanced, zone Custom Nginx Configuration, ajoute :

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Dans mon cas, les logs affichent déjà des IPs publiques. Cette configuration n’est pas nécessaire.

Installer Fail2Ban

Créer le dossier et le fichier docker-compose

mkdir ~/docker/fail2ban

cd ~/docker/fail2ban

nano docker-compose.yml

⚠  Pour que Fail2Ban puisse surveiller NPM, il doit avoir accès aux fichiers de logs générés dans le dossier /data/logs de NPM.

Contenu du docker-compose.yml :

services:

  fail2ban:

    image: crazymax/fail2ban:latest

    container_name: fail2ban

    network_mode: host

    cap_add:

      - NET_ADMIN

      - NET_RAW

    environment:

      - TZ=Europe/Paris

      - F2B_LOG_TARGET=/data/fail2ban.log

      - F2B_LOG_LEVEL=INFO

      - F2B_DB_PURGE_AGE=28d

    volumes:

      # Logs de Nginx a surveiller (lecture seule)

      - /home/USER/docker/nginx-proxy-manager/data/logs:/data/nginx/logs:ro

      # Dossier central Fail2Ban (config, db et log)

      - /home/USER/docker/fail2ban:/data

      # Logs systeme (lecture seule)

      - /var/log:/var/log:ro

    restart: always

    Pourquoi network_mode: host ? En mode host, Fail2Ban partage la pile réseau de la machine Ubuntu. C’est indispensable pour qu’il voie les vraies IPs sources et puisse agir sur iptables.

    Pourquoi monter les logs dans /data/nginx/logs ? L’image crazymax/fail2ban a un système de fichiers en lecture seule dans certains répertoires comme /var/log/nginx. Monter les logs dans /data/nginx/logs (qui est le volume /data accessible en écriture) évite cette erreur au démarrage.

    Structure des dossiers de configuration

    L’image crazymax/fail2ban attend ses fichiers de configuration dans /data/ (dans le conteneur), ce qui correspond à /home/USER/docker/fail2ban/ sur Ubuntu.

    Avant de déployer, crée la structure manuellement :

    mkdir -p /home/USER/docker/fail2ban/action.d
    
    mkdir -p /home/USER/docker/fail2ban/filter.d
    
    mkdir -p /home/USER/docker/fail2ban/jail.d
    

    Structure finale sur Ubuntu :

    /home/USER/docker/fail2ban/
    ├── action.d/
    │   └── docker-action.conf
    ├── filter.d/
    │   └── nginx-404.conf
    ├── jail.d/
    │   └── jail.local
    └── fail2ban.log    (cree automatiquement au demarrage)
    

    ⚠  Ne crée pas de sous-dossier ‘config/’ ou ‘data/’ supplémentaire. Les dossiers action.d, filter.d et jail.d doivent être directement dans /home/USER/docker/fail2ban/.

    Note sur les permissions – si les dossiers ont été créés par Docker (au premier démarrage du conteneur), ils appartiennent à root. Utilise sudo pour créer les fichiers, ou reprends la propriété du dossier :

    sudo chown -R USER:USER/home/USER/docker/fail2ban/
    

    Configuration de Fail2Ban

    Fichier action.d/docker-action.conf

    Ce fichier définit les règles iptables appliquées lors d’un bannissement. Il crée une chaîne dédiée f2b-npm-docker dans la table FORWARD.

    Crée le fichier /home/USER/docker/fail2ban/action.d/docker-action.conf :

    sudo nano /home/USER/docker/fail2ban/action.d/docker-action.conf
    

    Contenu :

    [Definition]
    
    actionstart = iptables -N f2b-npm-docker
    
                  iptables -A f2b-npm-docker -j RETURN
                  iptables -I FORWARD -p tcp -m multiport --dports 0:65535 -j f2b-npm-docker
    
    actionstop  = iptables -D FORWARD -p tcp -m multiport --dports 0:65535 -j f2b-npm-docker
    
                  iptables -F f2b-npm-docker
                  iptables -X f2b-npm-docker
    
    actioncheck = iptables -n -L FORWARD | grep -q 'f2b-npm-docker[ \t]'
    actionban   = iptables -I f2b-npm-docker -s <ip> -j DROP
    actionunban = iptables -D f2b-npm-docker -s <ip> -j DROP
    

    Fichier jail.d/jail.local

    Ce fichier définit les règles de bannissement et lie les filtres aux logs.

    Crée le fichier /home/USER/docker/fail2ban/jail.d/jail.local :

    sudo nano /home/USER/docker/fail2ban/jail.d/jail.local
    

    Contenu :

    [DEFAULT]
    
    # Temps de bannissement (1h)
    bantime  = 1h
    
    # Fenetre d'observation (10 min)
    findtime = 10m
    
    # Nombre d'erreurs avant bannissement
    maxretry = 5
    
    # Action : utilise le fichier docker-action.conf
    action = docker-action
    
    # --- JAIL POUR AUTHENTIFICATION NGINX ---
    
    [nginx-http-auth]
    enabled  = true
    filter   = nginx-http-auth
    
    # Surveille les logs d'erreur de NPM
    logpath  = /data/nginx/logs/proxy-host-*_error.log
    
    # --- JAIL ANTI-BOTS (erreurs 404/401/403) ---
    [nginx-404]
    enabled  = true
    port     = http,https
    filter   = nginx-404
    logpath  = /data/nginx/logs/proxy-host-*_access.log
    # Plus severe : 30 erreurs en 1 minute = banni 24h
    maxretry = 30
    findtime = 1m
    bantime  = 24h
    

    Fichier filter.d/nginx-404.conf

    Ce filtre indique à Fail2Ban quoi chercher dans les logs d’accès. Le format des logs NPM est différent du format Nginx standard – le regex doit en tenir compte.

    Format réel d’une ligne de log NPM :

    [11/May/2026:08:30:08 +0000] – 401 401 – GET https pdf.domaine.com « / » [Client 205.210.31.135] …

    Crée le fichier /home/USER/docker/fail2ban/filter.d/nginx-404.conf :

    sudo nano /home/USER/docker/fail2ban/filter.d/nginx-404.conf
    

    Contenu :

    [Definition]
    
    # Regex adapte au format de log NPM (champ [Client X.X.X.X])
    failregex = ^\[.*\] - \d+ \d+ - \w+ https? \S+ "\S+" \[Client <HOST>\] .*(404|401|403)
    ignoreregex =
    

    Le marqueur <HOST> est la variable Fail2Ban qui capture l’adresse IP – elle correspond au contenu du champ [Client …] dans les logs NPM.

    ignoreregex = avec rien après le signe égal signifie « aucune ligne à ignorer ». Cette ligne doit être présente même vide, sinon Fail2Ban peut générer une erreur au démarrage.

    Déploiement dans Portainer

    1. Dans Portainer, clique sur ton environnement « local », puis va dans l’onglet « Stacks » à gauche.
    2. Clique sur le bouton « + Add stack ».
    3. Donne-lui un nom : fail2ban.
    4. Dans la zone « Web editor », copie et colle le contenu du docker-compose.yml.
    5. Clique sur « Deploy the stack ». Docker télécharge l’image (1 à 2 minutes selon la connexion).

    Une fois la stack déployée, vérifie que le fichier fail2ban.log a bien été créé dans /home/USER/docker/fail2ban/. S’il n’apparaît pas, c’est souvent une question de permissions (le conteneur doit avoir le droit d’écrire dans ce dossier).

    Vérification

    Étape 1 – Vérifier que les logs sont accessibles

    Ouvre un terminal sur Ubuntu et tape :

    docker exec -it fail2ban ls /data/nginx/logs
    

    ✓  Si tu vois la liste de tes fichiers .log (en particulier proxy-host-*_access.log et proxy-host-*_error.log), le pont entre Fail2Ban et les logs NPM fonctionne.

    Étape 2 – Vérifier les jails actives

    Dans Portainer, ouvre la console (Exec) du conteneur fail2ban et tape :

    fail2ban-client status
    

    ✓  Tu dois voir apparaître deux jails : nginx-http-auth et nginx-404. C’est bien le cas pour moi :

    Résumé des sources de logs

    Type de logChemin dans logpathCe qu’il contient
    Erreurs d’authentification/data/nginx/logs/proxy-host-*_error.logTentatives de mots de passe ratés
    Visites (404/401/403)/data/nginx/logs/proxy-host-*_access.logBots cherchant des fichiers inexistants
    Log Fail2Ban/data/fail2ban.logCorrespond au volume /home/USER/docker/fail2ban:/data

    Commandes utiles

    Supervision

    Status général des jails :

    docker exec -t fail2ban fail2ban-client status

    Status détaillé d’une jail (ex: nginx-404) :

    docker exec -t fail2ban fail2ban-client status nginx-404

    Liste de toutes les IPs bannies :

    docker exec -t fail2ban fail2ban-client banned

    Recherche des requêtes d’une IP dans les logs :

    grep <IP-ADRESSE> /home/USER/docker/nginx-proxy-manager/data/logs/proxy-host-*_access.log

    Actions manuelles

    Bannir manuellement une IP :

    docker exec -t fail2ban fail2ban-client set nginx-404 banip <IP>

    Lever manuellement un bannissement :

    docker exec -t fail2ban fail2ban-client set nginx-404 unbanip <IP>

    Informations

    Version de Fail2Ban :

    docker exec -t fail2ban fail2ban-client version

    Aide complète :

    docker exec -t fail2ban fail2ban-client –help

    Rendons à César

    Pour concevoir ce processus d’installation et rédiger cet article, je me suis aidée de :

    • https://wiki.blablalinux.be/fr/docker-compose-fail2ban
    • l’IA Gemini (gemini.google.com)
    • l’IA Claude (claude.ai)

    100% testé et ajusté par moi.

    Installer Home Assistant sur Ubuntu avec Docker et Portainer

    Installer Home Assistant sur Ubuntu avec Docker et Portainer

    Article de la série « Mon ordinateur Ubuntu » 
    Actions et articles créés avec l’aide de Claude.ai et 100% testé et ajusté par moi.

    Home Assistant est une plateforme domotique open source puissante. Il en existe plusieurs variantes d’installation. Cet article explique comment installer la variante « Container » sur un ordinateur Ubuntu qui fait déjà tourner d’autres services Docker, avec un accès sécurisé depuis l’extérieur via Nginx Proxy Manager.

    Quelle variante de Home Assistant choisir ?

    Il existe trois grandes variantes :

    • HA OS – remplace complètement l’OS de la machine. À réserver à un appareil dédié (Raspberry Pi par exemple).
    • HA Supervised – donne accès au magasin d’add-ons officiel, mais officiellement supporté sur Debian uniquement. Risques de friction sur Ubuntu.
    • HA Container – s’installe comme n’importe quel container Docker. Pas d’accès au magasin d’add-ons natif, mais les add-ons les plus courants ont un équivalent en container Docker séparé. C’est la solution la plus cohérente si tu as déjà un PC Ubuntu avec Docker et Portainer.

    Ce dont tu as besoin avant de commencer

    Étape 1 – Créer les répertoires

    Sur le PC Linux, ouvre un terminal et crée les répertoires qui accueilleront les données de Home Assistant :

    sudo mkdir /home/USER/docker/home-assistant/
    sudo mkdir /home/USER/docker/home-assistant/config/
    

    C’est cohérent avec l’organisation décrite dans Docker et Portainer : regrouper les données. Toutes les données de HA seront dans ce dossier, et donc automatiquement couvertes par ta sauvegarde rclone.

    Étape 2 – Déployer la stack dans Portainer

    Connecte-toi à Portainer (https://TON-IP:9443), clique sur ton environnement « local », puis « Stacks » dans le menu gauche. Clique sur « + Add stack » et donne-lui le nom home-assistant.

    Dans la zone « Web editor », colle ce YAML :

    services:
      home-assistant:
        container_name: home-assistant
        image: "ghcr.io/home-assistant/home-assistant:stable"
        volumes:
          - /home/USER/docker/home-assistant/config:/config
          - /etc/localtime:/etc/localtime:ro
          - /run/dbus:/run/dbus:ro
        restart: unless-stopped
        privileged: true
        network_mode: host
        environment:
          TZ: Europe/Paris
    

    Quelques points importants sur ce YAML :

    • network_mode: host – HA utilise directement le réseau du PC, sans isolation. C’est recommandé par le projet HA pour la découverte automatique des appareils sur le réseau local.
    • privileged: true – nécessaire pour accéder au matériel (Bluetooth, USB, etc.).
    • /run/dbus:/run/dbus:ro – permet à HA de communiquer avec les services système, utile pour Bluetooth notamment.
    • Le volume letsencrypt n’est pas nécessaire ici – c’est Nginx Proxy Manager qui gère les certificats SSL.

    Clique sur « Deploy the stack ». Au bout de quelques secondes, HA est accessible sur ton réseau local via http://TON-IP:8123.

    Étape 3 – Accès externe via Nginx Proxy Manager

    Ouvrir le port 8123

    Dans l’interface de gestion de ton routeur, ajoute une règle de redirection de port :

    • Port externe : 8123
    • IP locale de destination : l’IP fixe de ton PC Linux
    • Port interne : 8123
    • Protocole : TCP
    Créer le proxy host dans NPM

    Connecte-toi à NPM (http://TON-IP:81), va dans « Proxy Hosts » et clique sur « Add Proxy Host ».

    Onglet « Details » :

    • Domain Names : ha.TON-DOMAINE.com
    • Scheme : http
    • Forward Name/IP : 127.0.0.1
    • Forward Port : 8123
    • Coche « Block Common Exploits » et « Websockets Support »

    Onglet « SSL » :

    • SSL Certificate : « Request a new SSL Certificate »
    • Coche « Force SSL », « HTTP/2 Support » et « HSTS Enabled »

    Clique sur « Save ».

    Le point spécifique à Home Assistant – configuration.yaml

    Contrairement aux autres containers, HA intègre une protection contre les accès via proxy non déclarés. Sans configuration supplémentaire, tu obtiendras une erreur 400 (Bad Request) en accédant via https://ha.TON-DOMAINE.com.

    Il faut déclarer NPM comme proxy de confiance. Ouvre le fichier de configuration :

    sudo nano /home/USER/docker/home-assistant/config/configuration.yaml
    

    Et ajoute ces lignes à la fin :

    http:
      use_x_forwarded_for: true
      trusted_proxies:
        - 127.0.0.1
        - 172.16.0.0/12
    

    Attention à l’indentation : 2 espaces par niveau, pas de tabulations. YAML est strict là-dessus.

    Redémarre le container HA dans Portainer. HA est maintenant accessible depuis l’extérieur via https://ha.TON-DOMAINE.com.

    Étape 4 – Premier démarrage et assistant de configuration

    Au premier accès, HA t’ouvre automatiquement l’assistant de démarrage. Tu y crées ton compte administrateur, choisis la langue, le fuseau horaire et la localisation.

    Bonne surprise : HA scanne ton réseau local et détecte automatiquement les appareils compatibles. Sur mon réseau il a trouvé Bluetooth, Google Cast, Frontier Silicon, Matter, Tado, Thread et UPnP – sans aucune configuration de ma part. La connexion effective de ces appareils est une étape ultérieure, mais la détection automatique donne un bon aperçu du potentiel.

    Étape 5 – Sauvegardes

    Si tu as déjà mis en place la sauvegarde automatique avec rclone décrite dans Sauvegarder ses containers Docker automatiquement avec Rclone, il n’y a rien à faire de plus. Le dossier /home/USER/docker/home-assistant/ est automatiquement inclus dans la sauvegarde quotidienne.

    Pour tester la restauration, la procédure est identique à celle décrite dans Restauration de containers Docker avec Rclone.

    Et ensuite ?

    Home Assistant est installé et opérationnel. Les prochaines étapes possibles :

    Ajouter des containers Docker complémentaires (MQTT, Zigbee2MQTT, etc.) selon les besoins

    Connecter les appareils détectés (Tado, Google Cast, etc.)

    Migrer des appareils depuis une box domotique existante

    ajouter un dongle Zigbee et ajouter des nouveaux appareils (j’ai trois ampoules et quelques capteurs d’ouverture de porte).

    Faille Linux Copy Fail (mai 2026)

    Faille Linux Copy Fail (mai 2026)

    Une vulnérabilité Copy Fail a été découverte fin avril 2026. Elle concerne beaucoup d’ordinateurs sous linux.

    Pour savoir si la vulnérabilité existe sur votre ordinateur : taper les commandes indiquées à la fin de cet article, dans le chapitre sur la vérification.

    mettre à jour mon ordinateur linux

    J’ai suivi les instructions de cet excellent site.

    Vérifier l’absence de cette vulnérabilité

    On peut aussi vérifier ensuite que tout a bien fonctionné :

    lsmod | grep algif_aead
    

    Rien ne devrait s’afficher en principe. Si rien ne s’affiche ça signifie que le module vulnérable ne se charge pas. C’est bien ce que l’on veut.

    Ultime vérification : Pour Ubuntu 24.04 (Noble Numbat), tu devrais avoir une version égale ou supérieure à la 6.8.0-31 (ou une version spécifique 6.14 si tu es sur un kernel HWE). C’est ce que me dit Gemini le 11 mai.

    uname -r
    

    La réponse est « 6.17.0-23-generic ». Tout va bien donc.

    Une image explicative de la faille

    Image créée par Gemini

    L’image est conçue comme une infographie technique simplifiée, divisée en deux parties distinctes pour expliquer le fonctionnement et les risques de la vulnérabilité CVE-2026-31431 :

    1. La zone « VULNERABILITY » (à gauche) : Un utilisateur avec des privilèges normaux lance une commande de copie de fichier. Cette action, normalement anodine, déclenche une erreur dans le noyau Linux. Cette erreur est symbolisée par des fragments de code brisés et une « fuite » d’informations qui contourne les sécurités habituelles.
    2. La zone « RISK » (à droite) : Un attaquant exploite cette corruption de mémoire pour contourner les protections. Un pictogramme montre un cadenas qui se brise, menant à une icône de l’utilisateur « Root » (super-utilisateur) symbolisé par une clé et une couronne, indiquant une prise de contrôle totale du système.
    3. L’interface Nginx : En haut de l’image, une interface graphique simplifiée de Nginx agit comme une barrière externe. Elle souligne le point que nous avons abordé : le danger survient lorsqu’une application exposée sur le web (via Nginx) est piratée et sert de point d’entrée pour lancer l’exploit « Copy Fail ».
    Obsidian synchronisé sur 3 appareils avec Dropbox

    Obsidian synchronisé sur 3 appareils avec Dropbox

    J’utilise Obsidian depuis peu pour stocker mes notes personnelles et professionnelles. L’objectif était simple : avoir mes notes accessibles sur mon PC Windows, mon téléphone Android et mon ordinateur Linux, sans payer d’abonnement. Voici comment j’ai mis ça en place, les obstacles rencontrés et les décisions prises.


    Pourquoi Obsidian et quel usage concret

    Obsidian est un outil de prise de notes basé sur des fichiers markdown (.md) stockés localement sur votre machine. Pas de cloud propriétaire, pas d’abonnement obligatoire pour les fonctions de base – mes notes m’appartiennent et restent dans un dossier normal de mon ordinateur.

    Mon usage principal : stocker des notes diverses au fil des jours, faire de la veille en conservant des liens commentés, et disposer d’une base de notes accessible depuis n’importe lequel de mes appareils.

    Ce que je ne cherchais pas : un système complexe avec des dizaines de plugins. La règle que je me suis fixée – n’ajouter de la structure que si un vrai besoin se manifeste.


    Ce qu’il faut avant de commencer

    • Un compte Dropbox (il peut être gratuit, 2 Go suffisent largement pour des notes texte)
    • Dropbox Desktop installé sur le PC Windows
    • Dropbox installé sur le PC linux (ce n’était pas mon cas, la synchronisation ne se fait pas)
    • Environ 30 minutes pour l’ensemble de l’installation

    Étape 1 – Installation Windows et création du vault dans Dropbox

    Télécharge Obsidian depuis obsidian.md//download et installe-le normalement.

    Au premier lancement, Obsidian propose de créer un vault (coffre). C’est le dossier qui contiendra toutes vos notes. Point crucial : place ce vault directement dans ton dossier Dropbox local.

    Sur mon installation, le vault se trouve dans D:\Dropbox\OBSIDIAN\obsidian-vault.

    Vérifie ensuite que Dropbox synchronise bien le dossier – l’icône Dropbox dans la barre des tâches doit indiquer une synchronisation en cours puis un statut « à jour ».


    Étape 2 – Plugin Remotely Save – configuration et authentification Dropbox

    Remotely Save est le plugin qui va gérer la synchronisation entre tes appareils via Dropbox. Il est gratuit pour Dropbox (attention : Google Drive est une fonctionnalité payante dans ce plugin).

    Pour l’installer :

    1. Paramètres > Modules complémentaires > activer les plugins communautaires
    2. Parcourir > rechercher « Remotely Save » > Installer > Activer
    3. Dans les réglages du plugin : choisir Dropbox comme service
    4. Cliquer sur Authentifier et autoriser l’accès à votre compte Dropbox
    5. Tester une première synchronisation manuelle avec l’icône de synchronisation en bas à gauche

    Le vault se retrouve alors dans un dossier OBSIDIAN dans ta Dropbox. On peut vérifier directement sur dropbox.com.


    Étape 3 – Installation Android et première synchronisation

    Installe Obsidian depuis le Play Store.

    Au premier lancement, crée un vault avec le même nom que sur Windows. Pour le stockage, choisis « Stockage de l’application ».

    Installe ensuite Remotely Save depuis les modules complémentaires (même procédure que sur Windows), configure Dropbox, authentifie-toi.

    Lance une première synchronisation manuelle – toutes les notes créées sur Windows apparaissent sur le téléphone, et inversement.


    Étape 4 – Installation Linux – cas particulier et limites

    Sur Ubuntu, Obsidian est disponible directement dans l’App Center. Installation en un clic, aucune ligne de commande nécessaire.

    La synchronisation est plus complexe sur Linux car Dropbox Desktop n’est pas installé sur ma machine. J’ai installé Remotely Save et configuré Dropbox, mais sans Dropbox Desktop local, le vault Linux reste isolé des autres appareils.

    Ma décision : ne pas installer Dropbox sur Linux pour l’instant, car mon usage Linux d’Obsidian est incertain. Si le besoin se confirme, j’installerai Dropbox Desktop Linux.

    Ce que j’ai appris en passant : les installations en container (Docker) n’ont pas de sens pour une application graphique comme Obsidian. Docker est fait pour des services auxquels on accède à distance, pas pour des interfaces utilisateur.


    Étape 5 – Synchronisation automatique – les réglages essentiels

    Par défaut, Remotely Save ne synchronise que manuellement. Pour automatiser, voici les réglages à faire sur chaque appareil séparément :

    Paramètres > Modules complémentaires > Remotely Save > icône engrenage :

    • Synchroniser au démarrage de l’application : activer
    • Synchroniser toutes les X minutes : activer, régler sur 5 (minutes)
    • Synchroniser à la fermeture de l’application : activer si disponible

    Ces réglages sont à répliquer sur chaque appareil. Une fois fait, la synchronisation se déclenche automatiquement sans aucune action manuelle.


    Premiers pas – notes quotidiennes et veille

    Pour apprendre à écrire en markdown, tu peut utiliser cette fiche, d’un dépôt GitHub.

    Pour démarrer simplement, la fonction Notes quotidiennes est idéale. Elle crée automatiquement une note par jour avec la date comme titre.

    Pour l’activer : Paramètres > Modules principaux > Notes quotidiennes > activer.

    L’icône calendrier dans la barre latérale gauche ouvre la note du jour en un clic. tu y notes ce que tu veux sans te poser de questions d’organisation.

    Pour la veille, deux approches simples :

    • Coller les URLs directement dans la note quotidienne avec un mot de contexte
    • Créer une note dédiée par thème (exemple : « Veille IA ») pour les liens que vous voulez retrouver facilement

    Mon conseil : résiste à la tentation dde structurer avant d’avoir des notes à organiser. Obsidian peut devenir très complexe très vite – commence simple.


    Ce que j’ai retenu de cette installation

    Remotely Save + Dropbox est la combinaison gratuite et fiable pour synchroniser Obsidian sur plusieurs appareils. Google Drive aurait été plus naturel pour moi mais c’est une fonctionnalité payante dans ce plugin.

    Le vault placé directement dans Dropbox sur Windows fonctionne sans friction. Sur Android, le plugin Remotely Save fait tout le travail. Sur Linux, la synchronisation nécessite Dropbox Desktop – à installer si l’usage se confirme.

    La synchronisation automatique toutes les 5 minutes est un bon équilibre entre réactivité et consommation batterie sur mobile.


    Cet article fait partie de ma démarche de capitalisation des compétences acquises. Si tu as des questions ou des retours sur cette installation, les commentaires sont ouverts.

    Restauration de containers Docker avec Rclone

    Restauration de containers Docker avec Rclone

    Article de la série « Mon ordinateur Ubuntu » À lire après : Sauvegarder ses containers Docker automatiquement avec Rclone vers Google Drive.
    Actions et articles créés avec l’aide de Claude.ai. 100% testé et ajusté par moi.


    La sauvegarde automatique mise en place dans l’article précédent ne vaut que si on sait s’en servir le jour où on en a besoin. Cet article décrit la procédure complète de restauration d’un container Docker depuis une sauvegarde Google Drive – testée sur Stirling PDF, Nginx Proxy Manager et Portainer.

    Avant de commencer : vérifie que tu as bien une sauvegarde récente dans Google Drive. La commande suivante liste les dates disponibles :

    sudo rclone --config /home/USER/.config/rclone/rclone.conf lsd "gdrive:/daily"
    

    Note la date de la sauvegarde que tu veux restaurer – tu en auras besoin à l’étape 4.


    Vue d’ensemble de la procédure

    1. Noter l’état actuel du container (point de comparaison)
    2. Arrêter et supprimer le container
    3. Renommer le dossier local (précaution de sécurité)
    4. Restaurer les fichiers depuis Google Drive
    5. Relancer le container
    6. Vérifier que tout fonctionne

    Nota : dans tout ce qui suit, tu remplaceras USER par ton nom d’utilisateur linux.


    Procédure standard (Stirling PDF et containers similaires)

    Étape 1 – Noter l’état actuel

    Avant de toucher quoi que ce soit, note les éléments qui te permettront de vérifier que la restauration a bien fonctionné :

    • les réglages personnalisés du logiciel (utilisateurs, mots de passe, configuration)
    • les favoris, l’historique, tout ce qui est propre à ton usage

    Vérifie l’empreinte des fichiers locaux actuels :

    ls -la /home/USER/docker/nom-du-logiciel/
    

    pour chaque sous-dossier :

    ls -la /home/USER/docker/nom-du-logiciel/sous-dossier/
    

    Vérifie aussi, pour chaque sous-dossier également, que la sauvegarde Drive contient bien les fichiers critiques et que leurs tailles correspondent :

    sudo rclone --config /home/USER/.config/rclone/rclone.conf ls "gdrive:/daily/YYYY-MM-DD/nom-du-logiciel/sous-dossier/"
    

    Les tailles en octets doivent correspondre à celles des fichiers locaux. Ce qui importe c’est que les fichiers principaux (base de données, configuration) soient de taille identique – pas besoin de vérifier les logs. Si c’est le cas, tu peux continuer en confiance.

    Étape 2 – Arrêter et supprimer le container dans Portainer

    Si tu restaure Portainer, va voir le cas particulier plus bas.

    Depuis ton navigateur, ouvre Portainer :

    1. Va dans Stacks dans le menu de gauche
    2. Clique sur la stack du logiciel à restaurer
    3. Clique sur Stop puis sur Delete this stack
    4. Confirme la suppression

    Le logiciel n’est plus accessible. C’est normal, on va le reconstruire depuis la sauvegarde.

    Étape 3 – Renommer le dossier local (précaution)

    Plutôt que de supprimer définitivement le dossier local, on le renomme. Si quelque chose se passe mal pendant la restauration, on peut revenir en arrière immédiatement.

    mv /home/USER/docker/nom-du-logiciel /home/USER/docker/nom-du-logiciel-BACKUP-TEST
    

    Vérifie que le dossier original n’existe plus :

    ls /home/USER/docker/
    

    Tu dois voir nom-du-logiciel-BACKUP-TEST mais plus nom-du-logiciel.

    Étape 4 – Restaurer les fichiers depuis Google Drive

    Crée un nouveau dossier vide :

    mkdir -p /home/USER/docker/nom-du-logiciel
    

    Puis copie les fichiers depuis la sauvegarde Drive. Note bien les guillemets autour du chemin Drive – ils évitent tout problème d’interprétation :

    Si tu restaures Nginx Proxy Manager, va voir le cas particulier plus bas.

    sudo rclone --config /home/USER/.config/rclone/rclone.conf copy "gdrive:/daily/YYYY-MM-DD/nom-du-logiciel" /home/USER/docker/nom-du-logiciel
    

    La commande ne retourne rien dans le terminal pendant qu’elle travaille – c’est normal. Pour surveiller la progression dans un second terminal :

    watch -n 5 ls -la /home/USER/docker/nom-du-logiciel/
    

    Les sous-dossiers apparaissent progressivement. Quitte avec Ctrl+C quand c’est terminé.

    Une fois la copie terminée, vérifie que les fichiers critiques sont bien là et ont la bonne taille :

    ls -la /home/USER/docker/nom-du-logiciel/configs/
    

    Étape 5 – Relancer le container dans Portainer

    Si tu restaure Portainer, va voir le cas particulier plus bas.

    Le fichier docker-compose.yml a été restauré avec les données. Affiche son contenu :

    cat /home/USER/docker/nom-du-logiciel/docker-compose.yml
    

    Puis dans Portainer :

    1. Va dans Stacks – clique sur + Add stack
    2. Donne le même nom qu’avant à la stack (le nom du répertoire)
    3. Dans l’éditeur Web editor, colle le contenu du docker-compose.yml
    4. Clique sur Deploy the stack

    Portainer va télécharger l’image Docker si nécessaire et démarrer le container.

    Étape 6 – Vérifier que tout fonctionne

    Ouvre le logiciel dans ton navigateur et vérifie :

    • que tu peux te connecter avec ton compte habituel
    • que tes réglages personnalisés sont bien présents (utilisateurs, configuration, favoris)
    • que les données sont intactes

    Si tout est conforme à ce que tu avais noté à l’étape 1, la restauration est réussie.

    Nettoyage après un test réussi

    Une fois que tu as confirmé que la restauration fonctionne parfaitement, supprime le dossier de sauvegarde temporaire :

    rm -rf /home/USER/docker/nom-du-logiciel-BACKUP-TEST
    

    Cas particulier – Nginx Proxy Manager

    NPM contient des données critiques : tes certificats Let’s Encrypt et ta configuration de proxy. La procédure standard s’applique, avec deux différences importantes.

    Différence 1 – commande de restauration

    Les certificats Let’s Encrypt dans letsencrypt/live/ sont des liens symboliques (symlinks) qui pointent vers les vrais fichiers dans letsencrypt/archive/. Sans l’option --copy-links, rclone refuse de les copier et la restauration échoue au démarrage avec l’erreur cannot load certificate.

    La commande de restauration doit donc inclure --copy-links :

    sudo rclone --config /home/USER/.config/rclone/rclone.conf copy --copy-links "gdrive:/daily/YYYY-MM-DD/nginx-proxy-manager" /home/USER/docker/nginx-proxy-manager
    

    Différence 2 – vérification après restauration

    En plus des vérifications habituelles, vérifie :

    • que tes proxy hosts sont bien présents dans l’interface NPM
    • que le cadenas vert s’affiche sur pdf.DOMAINE.com (certificat SSL actif)

    Si les certificats ont expiré pendant une longue interruption, NPM les renouvellera automatiquement au redémarrage.


    Cas particulier – Portainer

    Portainer est un cas spécial car il s’auto-gère. On ne peut pas le restaurer depuis son propre interface puisqu’il sera arrêté pendant la procédure. Toute la restauration se fait en ligne de commande.

    1 – Noter l’état actuel

    ls -la /home/USER/docker/portainer/
    ls -la /home/USER/docker/portainer/data/
    

    Vérifie que la sauvegarde contient bien les fichiers critiques :

    sudo rclone --config /home/USER/.config/rclone/rclone.conf ls "gdrive:/daily/YYYY-MM-DD/portainer/data/"
    

    Tu dois voir portainer.db, portainer.key et portainer.pub avec des tailles cohérentes.

    2 – Arrêter et supprimer Portainer en ligne de commande

    docker stop portainer
    docker rm portainer
    

    Vérifie que le container n’existe plus :

    docker ps -a | grep portainer
    

    La commande ne doit rien retourner.

    3 – Renommer le dossier local

    mv /home/USER/docker/portainer /home/USER/docker/portainer-BACKUP-TEST
    

    Vérifie :

    ls /home/USER/docker/
    

    Tu dois voir portainer-BACKUP-TEST mais plus portainer.

    4 – Restaurer les fichiers depuis Google Drive

    mkdir -p /home/USER/docker/portainer
    sudo rclone --config /home/USER/.config/rclone/rclone.conf copy "gdrive:/daily/YYYY-MM-DD/portainer" /home/USER/docker/portainer
    

    Surveille la progression :

    watch -n 5 ls -la /home/USER/docker/portainer/
    

    5 – Redonner les droits root et relancer Portainer

    Les fichiers dans portainer/data/ doivent appartenir à root – Portainer les gère en root et refuse de démarrer autrement. C’est une étape indispensable après restauration :

    sudo chown -R root:root /home/USER/docker/portainer/data
    

    Puis relance Portainer directement en ligne de commande :

    docker run -d \
      -p 9443:9443 \
      --name portainer \
      --restart=always \
      -v /var/run/docker.sock:/var/run/docker.sock \
      -v /home/USER/docker/portainer/data:/data \
      portainer/portainer-ce:latest
    

    6 – Vérifier que tout fonctionne

    Ouvre Portainer dans ton navigateur (https://[IP-DU-BEELINK]:9443).

    Si Portainer retrouve ton tableau de bord habituel sans te demander de créer un nouveau mot de passe, la restauration est réussie. Vérifie que tes stacks sont bien présentes dans l’onglet Stacks.

    Nettoyage

    rm -rf /home/USER/docker/portainer-BACKUP-TEST
    

    En cas de problème

    Le logiciel démarre mais ne retrouve pas les données Vérifie que les chemins dans le docker-compose.yml correspondent bien aux dossiers restaurés. Un chemin mal copié suffit à pointer vers un dossier vide.

    « Can’t follow symlink without -L/–copy-links » Ce message apparaît lors de la restauration de NPM. Ajoute --copy-links à la commande rclone de restauration – voir la section NPM ci-dessus.

    « Permission denied » au démarrage du container Les fichiers restaurés par Rclone appartiennent à USER, mais certains containers ont besoin que leurs dossiers appartiennent à root. C’est systématiquement le cas pour Portainer. Tape :

    sudo chown -R root:root /home/USER/docker/nom-du-logiciel/sous-dossier
    

    Puis redémarre la stack dans Portainer.

    Portainer affiche « New Portainer installation » Les fichiers de données n’ont pas les bons droits après restauration. Arrête le container, refais sudo chown -R root:root /home/USER/docker/portainer/data, puis relance avec docker run.

    Tu veux restaurer une version plus ancienne Remplace simplement YYYY-MM-DD par la date souhaitée dans la commande de l’étape 4. Les sauvegardes hebdomadaires sont dans gdrive:/weekly/YYYY-Wxx/ et les mensuelles dans gdrive:/monthly/YYYY-MM/.


    Dans le prochain article

    Maintenant que la sauvegarde et la restauration sont opérationnelles et testées, on verra comment installer un nouveau container en suivant dès le départ les bonnes pratiques – sans avoir à corriger la configuration après coup.

    Sauvegarder ses containers Docker automatiquement avec Rclone

    Sauvegarder ses containers Docker automatiquement avec Rclone

    Article de la série « Mon ordinateur Ubuntu ». À lire après : Docker (et Portainer) – regrouper les données

    Pour information, je me suis aidée de Claude.ai pour réaliser ces actions et rédiger l’article.


    Maintenant que tous les fichiers importants de mes containers Docker sont regroupés dans /home/USER/docker/, je peux mettre en place une sauvegarde automatique vers Google Drive. C’est l’objectif de cet article.

    J’utilise Rclone, un outil en ligne de commande qui synchronise des dossiers locaux vers des dizaines de services cloud. Couplé à un script bash et au planificateur cron, il permet d’automatiser complètement les sauvegardes, sans intervention manuelle.


    La stratégie de rétention Grand-Père / Père / Fils

    Plutôt qu’une simple copie quotidienne qui s’écrase, j’ai mis en place une stratégie de rétention appelée Grand-Père / Père / Fils (GFF) :

    • les sauvegardes quotidiennes sont conservées 7 jours
    • une sauvegarde hebdomadaire est créée chaque dimanche et conservée 4 semaines
    • une sauvegarde mensuelle est créée le 1er de chaque mois et conservée 12 mois
    • une sauvegarde annuelle est créée le 1er janvier et conservée indéfiniment

    Rclone ne gère pas cette logique nativement. C’est le script bash qui s’en charge.


    Ce que tu auras dans Google Drive au bout de quelques semaines

    sauvegardes-beelink/
    ├── daily/
    │   ├── 2026-05-01/
    │   │   ├── stirling-pdf/
    │   │   ├── nginx-proxy-manager/
    │   │   └── portainer/
    │   ├── 2026-05-02/
    │   └── ...  (7 jours maximum)
    ├── weekly/
    │   ├── 2026-W18/
    │   └── ...  (4 semaines maximum)
    ├── monthly/
    │   ├── 2026-05/
    │   └── ...  (12 mois maximum)
    └── yearly/
        └── 2026/  (conservé indéfiniment)
    

    Nota : dans tout ce qui suit, il faut remplacer USER par ton nom d’utilisateur Linux


    Étape 1 – Préparer un dossier dédié dans Google Drive

    Depuis ton navigateur, va dans Google Drive et crée un dossier appelé sauvegardes-beelink. Ouvre ce dossier et regarde l’URL :

    https://drive.google.com/drive/folders/1ABC123xyz456DEF789
    

    La partie après /folders/ est l’ID du dossier. Copie-la et garde-la de côté.

    En indiquant cet ID à Rclone, il ne verra que ce dossier et rien d’autre de ton Drive – c’est plus propre et plus sûr.


    Étape 2 – Installer Rclone

    Sur le Beelink, ouvre un terminal :

    sudo apt install rclone
    

    Vérifie l’installation :

    rclone version
    

    Tu dois voir quelque chose comme rclone v1.xx.x.


    Étape 3 – Connecter Rclone à Google Drive

    Lance la configuration interactive :

    rclone config
    

    Suis ces étapes dans le menu :

    n                        → nouveau remote
    Nom : gdrive
    Type : drive             → tape le numéro correspondant à "Google Drive"
    client_id :              → laisse vide, Entrée
    client_secret :          → laisse vide, Entrée
    scope : 1                → accès complet à Drive
    Edit advanced config : y → on répond oui pour pouvoir renseigner root_folder_id
                               laisser tout vide sauf :
       root_folder_id :      → colle ici l'ID copié à l'étape 1
                               laisser tout le reste vide, Entrée à chaque fois
    Edit advanced config : n → la question est reposée, on répond non cette fois
    Use auto config : y      → ou n si tu es en SSH depuis Windows
    

    Si tu travailles directement sur le Beelink (avec écran et clavier) :

    Use auto config : y
    

    Un navigateur s’ouvre – connecte-toi à Google et autorise Rclone.

    Si tu travailles depuis ton PC Windows en SSH :

    Use auto config : n
    

    Rclone te donne une URL. Ouvre-la dans ton navigateur Windows, autorise l’accès, et colle le code retourné dans le terminal.

    Puis dans les deux cas :

    Configure this as a Shared Drive : n
    OK → y
    

    Vérifier la connexion

    sudo rclone --config /home/USER/.config/rclone/rclone.conf lsd gdrive:
    

    Si la commande retourne le contenu de ton dossier Drive (ou rien si le dossier est vide), la connexion est établie. Rclone ne voit que ce dossier – rien d’autre de ton Drive.


    Étape 4 – Configurer sudo sans mot de passe pour Rclone

    Portainer et Nginx Proxy Manager écrivent leurs fichiers en root à l’intérieur du container. Pour que Rclone puisse les lire, il doit s’exécuter avec sudo – y compris quand cron lance le script automatiquement la nuit, sans session interactive.

    Note : selon ta configuration Ubuntu, cette étape peut ne pas être nécessaire. Si tu viens de taper ton mot de passe sudo, il est en cache pour quelques minutes. Pour être sûr que cron fonctionnera la nuit sans session ouverte, configure cette règle dans tous les cas.

    sudo visudo
    

    Ajoute cette ligne tout en bas :

    USER ALL=(ALL) NOPASSWD: /usr/bin/rclone
    

    Sauvegarde avec Ctrl+O puis quitte avec Ctrl+X.

    Attention avec visudo : ne ferme jamais le fichier directement avec Ctrl+X sans avoir d’abord sauvegardé avec Ctrl+O. visudo valide la syntaxe avant d’enregistrer – une faute de frappe dans ce fichier pourrait te bloquer hors de sudo.


    Étape 5 – Créer le token API Portainer

    Le script de sauvegarde interroge l’API Portainer avant chaque sauvegarde pour exporter automatiquement le docker-compose.yml de chaque stack dans son dossier. Ainsi la sauvegarde contient toujours le YAML exact et à jour.

    Pour cela il faut créer un token d’accès dans Portainer :

    1. Ouvre Portainer dans ton navigateur
    2. Clique sur ton nom d’utilisateur en haut à droite
    3. Clique sur My account
    4. Descends jusqu’à la section Access tokens
    5. Clique sur Add access token
    6. Donne-lui un nom : backup-script
    7. Copie immédiatement le token affiché – il ne sera plus visible ensuite

    Stocke ce token dans un fichier protégé :

    echo "ptr_TONTOKEN" > /home/USER/docker/scripts/.portainer-token
    chmod 600 /home/USER/docker/scripts/.portainer-token
    

    Le chmod 600 garantit que seul USER peut lire ce fichier.


    Étape 6 – Créer le script de sauvegarde

    On met le dossier script dans le répertoire qu’il sauvegardera, comme ça on ne le perdra pas.
    Crée d’abord les dossiers scripts s’ils n’existent pas :

    mkdir -p /home/USER/docker/scripts
    mkdir -p /home/USER/rclone-logs 
    

    Puis crée le script :

    nano /home/USER/docker/scripts/backup-docker.sh
    

    Colle ce contenu (remplace USER par ton nom d’utilisateur Linux) :

    #!/bin/bash
    
    # ═══════════════════════════════════════════════════════════════
    # backup-docker.sh — Sauvegarde Docker vers Google Drive
    # Stratégie Grand-Père / Père / Fils (quotidien / hebdo / mensuel / annuel)
    # v4 - export automatique des YAML depuis l'API Portainer
    #      --links pour les symlinks Let's Encrypt
    # ═══════════════════════════════════════════════════════════════
    
    # -- Configuration ────────────────────────────────────────────────
    SOURCE="/home/ald/docker"
    REMOTE="gdrive:"
    LOG="/home/ald/rclone-logs/backup-docker.log"   # hors /docker/ pour éviter de sauvegarder un fichier en cours d'écriture
    RCLONE_CONF="/home/ald/.config/rclone/rclone.conf"
    PORTAINER_URL="https://192.168.86.101:9443"
    PORTAINER_TOKEN=$(cat /home/ald/docker/scripts/.portainer-token)
    DATE=$(date +%Y-%m-%d)
    DAY=$(date +%u)     # 1=lundi ... 7=dimanche
    DOM=$(date +%d)     # jour du mois (01-31)
    MONTH=$(date +%m)   # mois (01-12)
    
    # -- Création du dossier de log si nécessaire ─────────────────────
    mkdir -p /home/ald/rclone-logs
    
    # -- Fonction de log ──────────────────────────────────────────────
    log() {
        echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG"
    }
    
    # -- Commande rclone de base ──────────────────────────────────────
    # --exclude "*.db-shm" : exclut les fichiers temporaires SQLite WAL
    # --exclude "*.db-wal" : idem - ces fichiers changent en permanence
    #                        et sont inutiles pour une restauration
    # --links : copie les liens symboliques comme de vrais fichiers
    #           indispensable pour les certificats Let's Encrypt de NPM
    # Important : ne pas ajouter --log-level, incompatible avec --log-file
    RCLONE="sudo rclone --config $RCLONE_CONF --log-file=$LOG --links --exclude *.db-shm --exclude *.db-wal"
    
    log "=== Début sauvegarde ==="
    
    # -- Export automatique des YAML depuis l'API Portainer ───────────
    log "Export des YAML depuis Portainer..."
    
    STACKS_JSON=$(curl -sk \
        -H "X-API-Key: $PORTAINER_TOKEN" \
        "$PORTAINER_URL/api/stacks")
    
    if [ -z "$STACKS_JSON" ] || [ "$STACKS_JSON" = "null" ]; then
        log "ERREUR : impossible de contacter l'API Portainer - les YAML ne seront pas mis à jour."
    else
        STACK_COUNT=$(echo "$STACKS_JSON" | python3 -c "
    import sys, json
    stacks = json.load(sys.stdin)
    print(len(stacks))
    " 2>/dev/null)
    
        log "$STACK_COUNT stack(s) trouvée(s) dans Portainer."
    
        echo "$STACKS_JSON" | python3 -c "
    import sys, json
    stacks = json.load(sys.stdin)
    for s in stacks:
        print(s['Id'], s['Name'])
    " 2>/dev/null | while read stack_id stack_name; do
    
            YAML_CONTENT=$(curl -sk \
                -H "X-API-Key: $PORTAINER_TOKEN" \
                "$PORTAINER_URL/api/stacks/$stack_id/file" \
                | python3 -c "
    import sys, json
    data = json.load(sys.stdin)
    print(data.get('StackFileContent', ''))
    " 2>/dev/null)
    
            if [ -n "$YAML_CONTENT" ]; then
                DEST="$SOURCE/$stack_name/docker-compose.yml"
                mkdir -p "$SOURCE/$stack_name"
                echo "$YAML_CONTENT" > "$DEST"
                log "YAML exporté : $stack_name/docker-compose.yml"
            else
                log "ATTENTION : YAML vide ou inaccessible pour la stack $stack_name"
            fi
        done
    fi
    
    # -- Vérification des docker-compose.yml manquants ────────────────
    # Le dossier "scripts" est exclu : ce n'est pas un container Docker
    # Portainer lui-même ne figure pas dans les stacks - son docker-compose.yml
    # doit être créé manuellement une fois (voir article sur le regroupement).
    log "Vérification des docker-compose.yml..."
    for dir in "$SOURCE"/*/; do
        logiciel=$(basename "$dir")
        compose="$dir/docker-compose.yml"
        if [ ! -f "$compose" ]; then
            log "ATTENTION : docker-compose.yml manquant dans $logiciel - à créer manuellement !"
        fi
    done
    
    # -- Sauvegarde quotidienne ───────────────────────────────────────
    log "Copie vers daily/$DATE..."
    $RCLONE copy "$SOURCE" "$REMOTE/daily/$DATE"
    
    # -- Sauvegarde hebdomadaire (chaque dimanche) ────────────────────
    if [ "$DAY" -eq 7 ]; then
        WEEK=$(date +%Y-W%V)
        log "Dimanche : création sauvegarde hebdomadaire $WEEK"
        $RCLONE copy "$REMOTE/daily/$DATE" "$REMOTE/weekly/$WEEK"
    fi
    
    # -- Sauvegarde mensuelle (le 1er de chaque mois) ─────────────────
    if [ "$DOM" -eq 01 ]; then
        YEARMONTH=$(date +%Y-%m)
        log "1er du mois : création sauvegarde mensuelle $YEARMONTH"
        $RCLONE copy "$REMOTE/daily/$DATE" "$REMOTE/monthly/$YEARMONTH"
    fi
    
    # -- Sauvegarde annuelle (le 1er janvier) ─────────────────────────
    if [ "$DOM" -eq 01 ] && [ "$MONTH" -eq 01 ]; then
        YEAR=$(date +%Y)
        log "1er janvier : création sauvegarde annuelle $YEAR"
        $RCLONE copy "$REMOTE/daily/$DATE" "$REMOTE/yearly/$YEAR"
    fi
    
    # -- Nettoyage des anciennes sauvegardes sur Drive ────────────────
    
    # Quotidiennes : on garde 7 jours
    log "Nettoyage daily > 7 jours..."
    RCLONE_CLEAN="sudo rclone --config $RCLONE_CONF --log-file=$LOG"
    $RCLONE_CLEAN delete "$REMOTE/daily" --min-age 7d 2>/dev/null
    $RCLONE_CLEAN rmdirs "$REMOTE/daily" 2>/dev/null
    
    # Hebdomadaires : on garde 4 semaines
    if sudo rclone --config "$RCLONE_CONF" lsd "$REMOTE/weekly" > /dev/null 2>&1; then
        log "Nettoyage weekly > 28 jours..."
        $RCLONE_CLEAN delete "$REMOTE/weekly" --min-age 28d
        $RCLONE_CLEAN rmdirs "$REMOTE/weekly"
    else
        log "Dossier weekly inexistant sur Drive, nettoyage ignoré."
    fi
    
    # Mensuelles : on garde 12 mois
    if sudo rclone --config "$RCLONE_CONF" lsd "$REMOTE/monthly" > /dev/null 2>&1; then
        log "Nettoyage monthly > 365 jours..."
        $RCLONE_CLEAN delete "$REMOTE/monthly" --min-age 365d
        $RCLONE_CLEAN rmdirs "$REMOTE/monthly"
    else
        log "Dossier monthly inexistant sur Drive, nettoyage ignoré."
    fi
    
    # Annuelles : conservées indéfiniment, pas de nettoyage automatique
    
    log "=== Sauvegarde terminée ==="
    

    Sauvegarde avec Ctrl+O puis quitte avec Ctrl+X.

    Rends le script exécutable :

    chmod +x /home/USER/docker/scripts/backup-docker.sh
    

    Étape 7 – Tester manuellement

    Avant d’automatiser, lance le script à la main :

    /home/USER/docker/scripts/backup-docker.sh
    

    La copie prend plusieurs minutes selon la taille de tes données. C’est normal et rassurant – si ça se termine en moins de 5 secondes, c’est qu’il y a un problème (voir encart erreurs fréquentes ci-dessous).

    Vérifie ensuite le log :

    tail -30 /home/USER/docker/scripts/backup-docker.log
    

    Tu dois voir dans l’ordre :

    • les YAML exportés pour chaque stack
    • === Sauvegarde terminée === sans aucune ligne ERROR ou ATTENTION

    Et dans Google Drive, le dossier daily/YYYY-MM-DD/ doit contenir les trois sous-dossiers stirling-pdf, nginx-proxy-manager et portainer.

    Pour vérifier l’absence d’erreurs d’un coup :

    grep -i error /home/USER/docker/scripts/backup-docker.log
    

    Si la commande ne retourne rien, tout est propre.


    Étape 8 – Automatiser avec cron

    cron est le planificateur de tâches de Linux. Ouvre-le :

    crontab -e
    

    Si c’est la première fois, choisis nano (option 1). Ajoute cette ligne tout en bas :

    0 3 * * * /home/USER/docker/scripts/backup-docker.sh
    

    Cela lance le script tous les jours à 3h du matin. Assure-toi que le Beelink est allumé à cette heure. Sauvegarde avec Ctrl+O puis quitte avec Ctrl+X.

    Vérifie que cron a bien enregistré :

    crontab -l
    

    Comment vérifier que la sauvegarde automatique a bien tourné

    Le lendemain matin, consulte la fin du log :

    tail -20 /home/USER/rclone-logs/backup-docker.log
    

    La dernière entrée doit être datée de cette nuit avec === Sauvegarde terminée ===.


    Déboguer une sauvegarde qui ne fonctionne pas

    Si le log montre une sauvegarde terminée en moins de 5 secondes sans aucune ligne de copie de fichiers, c’est le signe que rclone s’est lancé mais n’a rien fait – souvent à cause d’une erreur silencieuse au démarrage.

    La méthode pour diagnostiquer : lance rclone directement en ligne de commande et observe ce qui se passe :

    sudo rclone --config /home/USER/.config/rclone/rclone.conf lsd gdrive:
    

    Si cette commande fonctionne, la connexion Drive est bonne. Si elle échoue, le problème est dans la config rclone ou le token Google.

    Ensuite relance le script manuellement et surveille le log en temps réel dans un second terminal :

    tail -f /home/USER/rclone-logs/backup-docker.log
    

    Erreurs fréquentes

    La sauvegarde se termine en moins de 5 secondes Rclone a rencontré une erreur dès le départ et n’a rien copié, mais le script bash a continué jusqu’à la fin. Cause la plus fréquente : un conflit d’options ou un token Google Drive expiré. Diagnostique avec la commande lsd décrite ci-dessus.

    « Can’t set -v and –log-level » Ce message apparaît si tu utilises à la fois --verbose et --log-level dans la même commande rclone. Les deux options sont incompatibles. Solution : n’utilise que --log-file sans --log-level – c’est ce que fait le script ci-dessus.

    « Can’t follow symlink without -L/–copy-links » Ce message apparaît lors d’une restauration de Nginx Proxy Manager. Les certificats Let’s Encrypt dans letsencrypt/live/ sont des liens symboliques. Lors de la restauration, ajoute --copy-links à la commande rclone. La sauvegarde elle-même est correcte car le script utilise --links.

    « Permission denied » sur les fichiers de Portainer ou NPM Ces containers écrivent leurs fichiers en root. Rclone doit s’exécuter avec sudo pour les lire. Vérifie que la ligne NOPASSWD est bien présente dans sudoers (étape 4), et que le chemin /usr/bin/rclone est correct sur ton système (which rclone pour le vérifier).

    « Permission denied » lors de l’export du YAML Le fichier docker-compose.yml dans le dossier du logiciel appartient à root (créé avec sudo). Corrige les droits :

    sudo chown USER:USER /home/USER/docker/nom-du-logiciel/docker-compose.yml
    

    Le dossier weekly ou monthly n’apparaît pas C’est normal les premières semaines et les premiers mois. weekly se crée le premier dimanche après la mise en place, monthly le 1er du mois suivant. Le script vérifie leur existence avant de tenter un nettoyage – pas d’erreur à attendre.

    Cron ne lance pas le script Vérifie que le service cron tourne : systemctl status cron. S’il est inactif : sudo systemctl enable cron && sudo systemctl start cron. Vérifie aussi que le script est bien exécutable : ls -la /home/USER/docker/scripts/backup-docker.sh doit afficher -rwxr-xr-x.


    Dans le prochain article

    On verra comment restaurer un container depuis une sauvegarde Google Drive – c’est-à-dire utiliser concrètement tout ce qu’on vient de mettre en place.

    Docker (et Portainer) : regrouper les données

    Docker (et Portainer) : regrouper les données

    Article de la série « Mon ordinateur Ubuntu »


    J’ai expliqué dans des articles précédents comment j’ai installé des logiciels sous forme de containers Docker sur mon ordinateur Linux. Je veux maintenant pouvoir les sauvegarder automatiquement dans le cloud. Pour cela, il faut d’abord que je sache où sont stockés les fichiers essentiels — et surtout que je les regroupe tous au même endroit..

    Pourquoi regrouper les données ?

    Si on voit les containers comme des maisons, le fichier YAML (docker-compose.yml) est le plan de construction, mais il ne contient pas les habitants ni les meubles. Pour chaque container, il faut pouvoir localiser :

    • Le docker-compose.yml : c’est le plan de l’architecte. Si la maison brûle, le plan permet de reconstruire exactement la même structure.
    • Les volumes (les dossiers sur le Beelink) : ce sont tes meubles, tes photos et tes souvenirs. Si tu reconstruis la maison avec le plan mais que tu n’as plus tes meubles, la maison est vide.

    Pour Stirling PDF ce n’est pas très grave de perdre les volumes car rien n’y est stocké de façon critique. Mais pour Portainer, ce serait une catastrophe : le fichier YAML réinstallera le logiciel, mais tu perdras toutes tes stacks, l’historique de tes containers et tes réglages utilisateurs.

    L’objectif est donc de tout regrouper dans /home/USER/docker/nom-du-logiciel/ : le docker-compose.yml ET les dossiers de données, pour pouvoir tout sauvegarder d’un seul coup.

    Pour toute nouvelle installation, suis la checklist PDF qui résume les 4 étapes à suivre avant de cliquer sur Deploy. Cet article explique comment corriger des installations existantes qui n’ont pas suivi cette discipline dès le départ.

    Comment contraindre Docker à utiliser un répertoire spécifique ?

    Par défaut, quand on utilise des « named volumes » dans le YAML, Docker stocke les données dans un dossier système caché et protégé – invisible depuis Portainer et inaccessible facilement. Il faut remplacer ces named volumes par des chemins absolus pointant vers ton dossier personnel.

    La procédure est différente selon que le container est nouveau ou qu’il tourne déjà.

    Cas 1 – Nouveau container (pas encore installé)

    Étape 1 – Identifier les volumes dans la documentation

    Va sur la page Docker Hub du logiciel et cherche la section « Volumes » ou « Mounts ». Elle liste les chemins internes du container – ce sont eux que tu vas « brancher » sur ton Beelink. Note-les avant de créer la stack.

    Étape 2 – Créer les dossiers sur le Beelink

    mkdir -p /home/USER/docker/nom-du-logiciel/sous-dossier1
    mkdir -p /home/USER/docker/nom-du-logiciel/sous-dossier2
    

    Tu Tu crées autant de dossiers que de volumes nécessaires. Et tu choisis librement leurs noms. Ce qui compte c’est que le YAML pointe ensuite vers ces mêmes dossiers.

    Étape 3 – Écrire le YAML directement avec les chemins absolus

    Dans l’éditeur de Stack Portainer, écris les volumes avec les chemins complets dès le départ :

    volumes:
      - /home/USER/docker/nom-du-logiciel/sous-dossier1:/chemin/interne1
      - /home/USER/docker/nom-du-logiciel/sous-dossier2:/chemin/interne2
    

    Pas de named volumes, pas de section volumes: en bas du fichier. Clique sur Deploy the stack.


    Cas 2 – Container existant avec des named volumes

    C’est la situation dans laquelle je me trouvais avec Stirling PDF et Nginx Proxy Manager – installés avant que je connaisse cette bonne pratique.

    Étape 1 – Lire le YAML dans Portainer

    Va dans Portainer – Stacks – nom de la stack – Editor. Tu vois quelque chose comme :

    volumes:
      - stirling_trainingData:/usr/share/tesseract-ocr/5/tessdata
      - stirling_extraConfigs:/configs
      - stirling_customFiles:/customFiles
      - stirling_logs:/logs
    

    Chaque ligne te donne deux informations :

    • à gauche du : : le nom du named volume (ex: stirling_trainingData)
    • à droite du : : le chemin interne du container (ex: /usr/share/tesseract-ocr/5/tessdata)

    Étape 2 – Localiser les données sur le disque

    Les named volumes sont stockés dans /var/lib/docker/volumes/. Le chemin complet se construit selon cette règle :

    /var/lib/docker/volumes/ + [nom de la stack] + "_" + [nom du volume] + /_data/.
    

    Pour vérifier les noms exacts avant de copier :

    sudo ls /var/lib/docker/volumes/ | grep nom-de-la-stack
    

    Pour Stirling PDF (stack nommée stirling-pdf), la correspondance est la suivante :

    Nom dans le YAMLDossier dans /var/lib/docker/volumes/Dossier local à créer
    stirling_trainingDatastirling-pdf_stirling_trainingData/_data/trainingData/
    stirling_extraConfigsstirling-pdf_stirling_extraConfigs/_data/configs/
    stirling_customFilesstirling-pdf_stirling_customFiles/_data/customFiles/
    stirling_logsstirling-pdf_stirling_logs/_data/logs/

    Tu choisis librement les noms des dossiers locaux – ce qui compte c’est la cohérence avec ce que tu écriras dans le YAML à l’étape 4.

    Étape 3 – Créer les dossiers et migrer les données

    Crée les dossiers de destination :

    mkdir -p /home/USER/docker/stirling-pdf/{trainingData,configs,customFiles,logs}
    

    Arrête le container depuis Portainer (Stop), puis copie les données :

    # Le /. à la fin copie le contenu du dossier, pas le dossier lui-même
    sudo cp -r /var/lib/docker/volumes/stirling-pdf_stirling_trainingData/_data/. /home/USER/docker/stirling-pdf/trainingData/
    sudo cp -r /var/lib/docker/volumes/stirling-pdf_stirling_extraConfigs/_data/. /home/USER/docker/stirling-pdf/configs/
    sudo cp -r /var/lib/docker/volumes/stirling-pdf_stirling_customFiles/_data/. /home/USER/docker/stirling-pdf/customFiles/
    sudo cp -r /var/lib/docker/volumes/stirling-pdf_stirling_logs/_data/. /home/USER/docker/stirling-pdf/logs/
    
    # Redonne les droits à ton utilisateur
    sudo chown -R USER:USER /home/USER/docker/stirling-pdf
    

    Étape 4 – Modifier le YAML dans Portainer

    Dans l’éditeur de Stack, remplace les named volumes par les chemins absolus :

    volumes:
      - /home/USER/docker/stirling-pdf/trainingData:/usr/share/tesseract-ocr/5/tessdata
      - /home/USER/docker/stirling-pdf/configs:/configs
      - /home/USER/docker/stirling-pdf/customFiles:/customFiles
      - /home/USER/docker/stirling-pdf/logs:/logs
    

    Supprime la section volumes: en bas du fichier (celle qui listait les noms). Puis clique sur Update the stack.

    Pourquoi le chemin complet plutôt que ./ ? Portainer stocke ses fichiers de manière un peu invisible. En écrivant le chemin entier, tu es certain à 100 % de l’endroit où les données atterrissent sur le disque – indispensable pour tes futures sauvegardes.


    Cas particulier – Nginx Proxy Manager et les certificats Let’s Encrypt

    NPM est indispensable à relocaliser car c’est là que se trouvent tes certificats Let’s Encrypt et toute ta configuration de proxy.

    Sa structure de dossiers est la suivante :

    nginx-proxy-manager/
    ├── data/           - base de données, logs, configuration nginx
    └── letsencrypt/    - certificats SSL
        ├── archive/    - les vrais fichiers .pem
        ├── live/       - liens symboliques vers archive/
        └── renewal/    - configuration de renouvellement
    

    Point d’attention important : le dossier letsencrypt/live/ ne contient pas de vrais fichiers mais des liens symboliques (symlinks) qui pointent vers les fichiers dans letsencrypt/archive/. Les deux dossiers doivent être présents dans ta sauvegarde pour que la restauration fonctionne. L’outil de sauvegarde Rclone doit être configuré avec l’option --links pour les copier correctement – c’est détaillé dans l’article sur la sauvegarde automatique.

    La procédure de relocalisation est identique au Cas 2, avec ces volumes dans le YAML :

    volumes:
      - /home/USER/docker/nginx-proxy-manager/data:/data
      - /home/USER/docker/nginx-proxy-manager/letsencrypt:/etc/letsencrypt
    

    Créer le fichier docker-compose.yml

    Une fois le container configuré et fonctionnel, crée immédiatement un fichier docker-compose.yml dans son dossier. Ce fichier est indispensable pour pouvoir reconstruire le container depuis zéro en cas de problème – et pour que la sauvegarde automatique soit complète.

    nano /home/USER/docker/nom-du-logiciel/docker-compose.yml
    

    Colle le contenu exact du YAML visible dans Portainer (Stacks – nom de la stack – Editor). Puis donne les bons droits :

    sudo chown USER:USER /home/USER/docker/nom-du-logiciel/docker-compose.yml
    

    Le chown est important : il permet au script de sauvegarde de mettre à jour ce fichier automatiquement à chaque sauvegarde, si tu modifies la stack dans Portainer.

    Le script de sauvegarde vérifie à chaque lancement que ce fichier existe dans chaque dossier. Si ce n’est pas le cas, il écrit une ligne ATTENTION dans le log – un rappel quotidien jusqu’à ce que ce soit fait.

    Cas particulier – Portainer

    Portainer ne s’installe pas via une stack mais via une commande docker run directe – il n’apparaît donc pas dans la liste des stacks de Portainer et son YAML ne peut pas être exporté automatiquement. Crée son fichier manuellement :

    nano /home/USER/docker/portainer/docker-compose.yml
    

    Colle le contenu de ta stack Portainer tel qu’il apparaît dans Portainer – Stacks – Editor. Puis donne les bons droits :

    sudo chown USER:USER /home/USER/docker/portainer/docker-compose.yml
    

    Note sur les droits des données Portainer : contrairement aux autres containers, les fichiers dans portainer/data/ doivent appartenir à root (Portainer les crée et les gère en root). Ne fais pas de chown USER sur ce sous-dossier – uniquement sur le docker-compose.yml.


    Supprimer les volumes inutilisés

    Une fois que tu as vérifié que tout fonctionne avec les nouveaux chemins, supprime les anciens named volumes pour libérer de l’espace disque :

    sudo docker volume prune
    

    Cette commande supprime tous les volumes qui ne sont attachés à aucun container (allumé ou éteint). Elle ne touche pas à ce qui est dans ton dossier personnel ni aux volumes actifs.


    En résumé, ton nouveau réflexe

    « Un nouveau container ? Un nouveau dossier dans /home/USER/docker/ et un chemin complet dans le YAML – plus un docker-compose.yml créé immédiatement. »

    C’est cette discipline qui fera que, dans 6 mois, quand tu auras 10 logiciels différents, tu pourras tout sauvegarder sur ton Google Drive d’une seule traite, car tout sera sagement rangé au même endroit.

    Dans le prochain article de cette série, nous verrons comment configurer Rclone pour sauvegarder automatiquement tout le dossier /home/USER/docker/ vers Google Drive.

    Stirling PDF, un outil gratuit et très complet

    Stirling PDF, un outil gratuit et très complet

    J’ai décrit dans la série « Mon ordinateur Ubuntu » les étapes d’installation d’un logiciel libre de gestion des pdf. Je n’ai pas vraiment parlé du logiciel lui-même car le sujet c’était plutôt l’installation locale dans un container Docker, et accessible depuis l’extérieur. Mais je trouve utile de décrire rapidement ce que je peux faire avec ce nouveau logiciel à ma disposition.

    Stirling PDF a d’énormes qualités : il a une multitude de fonctionnalités (cf la copie d’écran de ses outils ci-dessous), il est gratuit, il peut être installé pour plusieurs utilisateurs (avec une limite de 5 cependant).

    Stirling PSF est disponible en version « desktop », pas seulement en version serveur hébergé. On peut le télécharger sur le site de Stirling : https://www.stirling.com/download

    mais quelques limites cependant

    J’utilise actuellement une version payante (wondershare pdf), dont le coût me paraît excessif, tout comme toutes les autres solutions un peu complètes que j’avais trouvé jusqu’à présent.

    Je pense que Stirling PDF est parfait pour toutes les manipulations sophistiquées de pdf (fusion, séparation, modifications, compression, conversion, etc). Mais malheureusement il laisse de côté deux fonctions bien utiles : l’impression « pdf » et la gestion du scanner pour générer un pdf.

    impression de PDF

    Tu as déjà dans ta liste d’imprimantes : « Microsoft Print to PDF ».

    Elle fonctionne exactement comme une vraie imprimante : tu fais « Imprimer » depuis n’importe quel logiciel (Word, une page web, un mail), tu choisis cette imprimante, et cela te crée un fichier PDF sur ton bureau.

    Pas besoin d’un logiciel pour ça !

    utiliser le scanner

    lire un pdf

    j’utiliserai Edge, qui est intégré à mon ordinateur déjà.

    Manipulations Complexes

    Là j’utiliserai Stirling PDF, pour l’OCR (reconnaissance de caractères), fusionner des fichiers, protéger par mot de passe, ou convertir un Word.

    Améliorations possibles de mes utilisations de logiciel PDF

    Il y a une option intéressante dans Stirling pour utiliser son téléphone pour générer des PDF : le téléphone peut également servir de scanner mobile. Voir les explications (en anglais) ici : https://docs.stirlingpdf.com/Functionality/Mobile-Scanner/. Je configurerai prochainement Stirling pour ça.

    accès sécurisé à mon PC de l’extérieur

    accès sécurisé à mon PC de l’extérieur

    Avant de suivre ce tutoriel, je te recommande vivement de lire l’article Docker (et Portainer) – regrouper les données qui explique pourquoi il est important de bien organiser les fichiers de tes containers dès le départ. Tu peux aussi télécharger la checklist PDF et la garder sous la main pendant l’installation.

    Note pour les lecteurs : le YAML de NPM crée des « named volumes » cachés, qui contiennent des éléments critiques : tes certificats Let’s Encrypt et toute ta configuration de proxy. Il est indispensable de les relocaliser dans /home/USER/docker/nginx-proxy-manager/. La procédure complète est expliquée dans l’article Docker (et Portainer) — regrouper les données, section « Pour Stirling PDF ».


    j’ai installé Stirling PDF sur un ordinateur à faible consommation qui restera allumé en permanence. Je veux pouvoir y accéder où que je sois. Je vais donc créer un système pour y accéder comme si c’était un site internet standard https://pdf.DOMAINE.com.
    Pour cela 6 étapes, plus ou moins difficiles :

    1. Attribuer une IP fixe à l’ordinateur Linux ;
    2. régler mon réseau interne pour que les ports 80 et 443 soient redirigés (autoriser le reverse proxy)
    3. Installer et connecter NGinx Proxy Manager (via Portainer)
    4. Créer le « Pont » dans Nginx Proxy Manager vers https://pdf.DOMAINE.com
    5. installer un certificat Let’s Encrypt
    6. vérifier tout

    Les étapes 1 et 2 sont complètement liées à ton installation interne. Ce que je décris est spécifique à moi. C’est l’étape 2 qui a été le plus difficile pour moi. Heureusement que Gemini m’a aidé.

    Pour le reste, tout est transférable je pense.

    Avant de démarrer

    Obtenir un nom de domaine

    Pour ma part j’ai acheté un domaine sur infomaniak. On peut le faire avec n’importe quel fournisseur, type OVH, Gandi ou autre. J’aurais aussi pu utiliser un nom de domaine que j’ai déjà puisque j’utiliserai des sous-domaines.
    Pour ce qui suit on utilisera le nom de domaine DOMAINE.com.

    Identifier l’IP de ma box

    Depuis ton PC Windows, va sur https://www.mon-ip.com/. mon IP est par exemple 12.123.45.678 Attention, si tu utilises un VPN le site te renverra l’IP de ton VPN et pas celle de ton point d’accès à internet, et rien ne fonctionnera.

    Pour vérifier qu’elle est fixe, utiliser https://www.mon-ip.com/ip-dynamique.php . Elle est fixe pour moi. Si elle ne l’était pas, il faudrait que je m’intéresse aux clients DDNS, souvent déjà présents dans les box internet, les Google Mesh, et qui peut aussi être placé dans un conteneur Docker sur mon ordinateur Linux). Le client DDNS informe alors le gestionnaire du nom de domaine de la nouvelle adresse IP à utiliser lorsque le fournisseur internet la change.

    Pointer le nom de domaine vers ma box

    Comme j’ai acheté le nom de domaine chez Infomaniak, je vais maintenant dans mon manager Infomaniak pour régler la zone DNS du domaine pdf.DOMAINE.com

    Chez Infomaniak :

    • Va dans Domaines > DOMAINE.com > Zone DNS.
    • Ajoute une entrée (un « Enregistrement A ») :
      • Nom (ou hôte) : pdf (pour créer pdf.DOMAINE.com).
      • Cible (ou IP) : Ton adresse IP publique notée plus haut, 12.123.45.678.
    • Enregistre.

    Attention, il faut au moins 1 heure pour que tous les systèmes de routage du monde soient informés.

    Pour vérifier si ça fonctionne : https://dnschecker.org/#A/pdf.DOMAINE.com pointe bien vers l’adresse IP fixe de ma box (12.123.45.678)

    étape 1 : Attribuer une IP fixe au PC linux

    Dans mon réseau, c’est un Google Mesh qui attribue les adresses IP, pas le routeur de mon opérateur. Je fais donc les réglages sur mon téléphone, dans l’application google Home.

    • Ouvre l’application Google Home.
    • Appuie sur l’icône Favoris ou Appareils et cherche ton réseau Wi-Fi.
    • Va dans Paramètres du réseau > Paramètres avancés > Réseau local (LAN).
    • Cherche une option nommée « Réservation d’adresse IP » ou « Baux statiques ».
    • Appuie sur le bouton « + », sélectionne ton Beelink dans la liste et enregistre l’adresse 192.168.86.101 (ou une autre de ton choix).
    • Redémarrer l’ordinateur

    étape 2 : Rediriger les ports 80 et 443

    j’ai mis du temps sur cette étape. Je ne comprenais pas tout. Et j’avais oublié que c’est le google Mesh qui gère les accès à mon réseau interne, pas la box du fournisseur d’accès. Il faut donc que je procède en deux temps :

    1. dire à la box du fournisseur d’accès d’autoriser l’accès direct du google mesh à internet (mode DMZ) ;
    2. dire au google mesh d’autoriser les entrées via les ports 80 et 443 (redirection de ports).

    régler la box du fournisseur d’accès

    Pour la plupart des gens, on ne fait pas ce réglage, on passe tout de suite à la redirection des ports 80 et 443 plus loin.

    Pour accéder à ma box internet, ilfaut que je me connecte directement à elle (pas via le boîtier google mesh), par exemple avec un cable ethernet.

    Puis de mon ordinateur connecté à cette box : 192.168.1.1 dans un navigateur.

    1. Aattribue une IP fixe au boîtier Google Mesh. Par exemple 192.168.1.100
    2. Ensuite, dans les paramètres de la Livebox, cherche l’option DMZ (Zone Démilitarisée). Active la DMZ pour l’adresse du Google Mesh. Cela signifie : « Livebox, n’essaie pas de filtrer ce qui arrive, envoie tout directement au Google Mesh, c’est lui qui gère la sécurité ».
    3. Ensuite, tu n’auras plus qu’à gérer les redirections de ports (80 et 443) uniquement dans l’application Google Home.

    N’oublie pas de reconnecter ton ordinateur Windows derrière le Google Mesh pour être sur le même réseau local que l’ordinateur Ubuntu !

    redirection des ports 80 et 443

    Pour moi c’est sur le Google Mesh, via l’application Google Home sur mon téléphone. Mais pour la plupart des gens, c’est directement sur la box.

    on doit impérativement rediriger le port 80 également, même si on prévoit de n’utiliser que des connexions sécurisées (httpS).

    1. Ouvre l’application Google Home sur ton téléphone.
    2. Va dans Favoris (ou Paramètres du réseau) > Paramètres avancés > Redirection de port.
    3. Crée deux règles pour l’ordinateur sous Linux (IP 192.168.86.101) :
      • Règle 1 : Port interne 80, Port externe 80, Protocole TCP.
      • Règle 2 : Port interne 443, Port externe 443, Protocole TCP.

    Pour vérifier, on peut utiliser https://www.yougetsignal.com/tools/open-ports/ pour le port 80 et pour le port 443.

    étape 3 : Installer NGinx Proxy Manager

    J’ai installé Docker et Portainer précédemment sur mon ordinateur Linux. Voir à ce sujet l’article Docker et Portainer sur ubuntu . Je réalise donc l’installation dans le navigateur de mon ordinateur Windows, par Portainer.

    Installation de NPM via Portainer

    1. Sur ton PC Windows, ouvre Portainer (https://192.168.86.101:9443).
    2. Ouvre l’environnement HOME
    3. Va dans Stacks (dans le menu de gauche) puis clique sur le bouton + Add stack.
    4. Nomme la stack : nginx-proxy-manager.
    5. Dans l’éditeur, colle le code YAML suivant :
    version: '3.8'
    services:
      npm:
        image: 'jc21/nginx-proxy-manager:latest'
        container_name: nginx-proxy-manager
        restart: unless-stopped
        ports:
          - '80:80'   # Port pour le trafic HTTP et Let's Encrypt
          - '81:81'   # Port de l'interface d'administration de NPM
          - '443:443' # Port pour le trafic HTTPS sécurisé
        volumes:
          - npm_data:/data
          - npm_letsencrypt:/etc/letsencrypt
    
    volumes:
      npm_data:
      npm_letsencrypt:
    

    Clique sur Deploy the stack. Attends une minute que Docker télécharge l’image et lance le service.

    Première connexion et configuration

    Une fois que la stack est « Green » (en cours d’exécution) :

    1. Ouvre un nouvel onglet sur ton Windows et tape : http://192.168.86.101:81.
    2. Connecte-toi avec les identifiants par défaut :
      • Email : admin@example.com
      • Mot de passe : changeme
    3. Important : NPM va immédiatement te demander de modifier ton nom, ton email d’administrateur et ton mot de passe. Fais-le soigneusement et note bien ces informations.

    étape 4 : Créer le « Pont » dans Nginx Proxy Manager

    Maintenant, on dit à ton ordinateur Linux quoi faire quand il reçoit une demande pour « pdf ».

    1. Connecte-toi à NPM sur ton navigateur Windows : http://192.168.86.101:81.
    2. Va dans l’onglet Proxy Hosts et clique sur Add Proxy Host.
    3. Onglet « Details » :
      • Domain Names : pdf.DOMAINE.com (appuie sur Entrée).
      • Scheme : http.
      • Forward Name/IP : 192.168.86.101.
      • Forward Port : 8080.
      • Coche Block Common Exploits et Websockets Support.

    Normalement à ce stade, si je tape https://pdf.DOMAINE.com dans un navigateur, il pointe vers mon ordinateur linux mais rien ne s’affiche car le navigateur bloque l’accès à un site non sécurisé. Il manque en effet un certificat Let’s Encrypt qui garantit que le site est correctement encrypté.

    étape 5 : installer un certificat Let’s Encrypt

    Tu as maintenant tous les ingrédients : un nom de domaine (DOMAINE.com), un serveur prêt (sous Linux) et un chef d’orchestre (Nginx Proxy Manager).

    Voici l’étape indispensable pour que https://pdf.DOMAINE.com affiche ton Stirling PDF avec le cadenas vert. En effet, le cadenas vert ne s’affiche que si mon site a un certificat qui dit que je possède bien le domaine DOMAINE.com et que le navigateur parvient à utiliser un protocole de cryptage moderne (TLS 1.2 ou 1.3) pour l’afficher.

    1. Connecte-toi à NPM sur ton navigateur Windows : http://192.168.86.101:81.

    2. Sur la ligne pdf.domaine.com clique sur les trois petits points verticaux tout à droite (sous la colonne « Status »). Clique sur Edit (Modifier). Une fenêtre surgissante (pop-up) va s’ouvrir. Tu y verras alors plusieurs onglets en haut : Details, Custom locations, SSL, et Advanced. Clique sur l’onglet SSL.

    • Coche HTTP/2 Support et HSTS Enabled (c’est mieux pour la sécurité et la rapidité).
    • Dans le menu déroulant « SSL Certificate », choisis Request a new SSL Certificate.
    • Coche Force SSL (pour que personne ne reste en non-sécurisé).

    3. Clique sur Save

    NPM va mouliner pendant 30 secondes. Il est en train de discuter avec Let’s Encrypt pour prouver que tu es bien le propriétaire de DOMAINE.com

    étape 6 : vérifier tout

    On a installé un un Proxy Host, quelque chose qui dit « Si quelqu’un demande pdf.DOMAINE.com, envoie-le vers 192.168.86.101 sur le port 8080 (Stirling PDF) »

    Maintenant, si je tape pdf.DOMAINE.com dans le navigateur de n’importe quel ordinateur, dans le monde entier, j’ouvrirai un accès à mon logiciel de gestion de pdf, Stirling PDF !

    Je peux même créer une application (PWA pour Progressive Web App) qui m’évitera d’utiliser mon navigateur. Il me suffit de cliquer sur « ouvrir dans l’appli » qui aparaît à droite de l’url pdf.DOMAINE.com en haut du navigateur.

    Et voilà !

    Installer et régler Stirling PDF via Docker

    Installer et régler Stirling PDF via Docker

    Avant de suivre ce tutoriel, je te recommande vivement de lire l’article Docker (et Portainer) – regrouper les données qui explique pourquoi il est important de bien organiser les fichiers de tes containers dès le départ. Tu peux aussi télécharger la checklist PDF et la garder sous la main pendant l’installation.

    Note pour les lecteurs : le YAML utilisé ici crée des « named volumes » gérés par Docker (et Portainer) dans un dossier système caché. Si tu veux pouvoir sauvegarder facilement tes données, il faut les relocaliser dans /home/USER/docker/stirling-pdf/. La procédure complète est expliquée dans l’article Docker (et Portainer) — regrouper les données, section « Pour Stirling PDF ».


    Cette action a été réalisée après avoir installé Docker et Portainer sur mon PC ubunto (cf l’article Docker et Portainer sur ubuntu). Les actions ont été réalisées à partir de Portainer, dans un navigateur web de mon ordinateur Windows. Mais stirling PDF est installé dans un container Docker sur l’ordinateur Linux.

    Maintenant que tu es dans Portainer, on va utiliser ce qu’on appelle un « Stack ». C’est une façon élégante de dire « un fichier de configuration qui installe tout d’un coup ».

    Installer Stirling PDF à partir de Portainer

    1. Dans Portainer, clique sur ton environnement « local », puis va dans l’onglet « Stacks » à gauche.
    2. Clique sur le bouton « + Add stack ».
    3. Donne-lui un nom : stirling-pdf.
    4. Dans la zone « Web editor », copie et colle ce bloc de code (c’est le fameux Docker Compose, en YAML) :
    version: '3.3'
    services:
      stirling-pdf:
        image: stirlingtools/stirling-pdf:latest
        container_name: stirling-pdf
        restart: always
        ports:
          - '8080:8080'
        volumes:
          - stirling_trainingData:/usr/share/tesseract-ocr/5/tessdata
          - stirling_extraConfigs:/configs
          - stirling_customFiles:/customFiles
          - stirling_logs:/logs
        environment:
          - DOCKER_ENABLE_SECURITY=true
          - OCR_LANGUAGES=fra,eng
          - INSTALL_BOOK_AND_ADVANCED_HTML_OPS=false
          - TZ=Europe/Paris
    
    volumes:
      stirling_trainingData:
      stirling_extraConfigs:
      stirling_customFiles:
      stirling_logs:
    

    Le code contient les instructions pour que Stirling PDF puisse faire de la reconnaissance de caractères (OCR) en anglais et en français. Il prévoit aussi qu’il redémarre tout seul si l’ordinateur Linux redémarre et règle le fuseau horaire sur Europe/Paris.

    Le code prévoit aussi que DOCKER_ENABLE_SECURITY=true. Cela obligera toute personne qui accèderai à l’application à entrer un nom d’utilisateur et un mot de passe. Je le prévois tout de suite car on verra plus tard comment je peux accéder à mon logiciel Stirling PDF de partout.

    Descends tout en bas et clique sur « Deploy the stack ». Docker va télécharger l’image (cela peut prendre 1 ou 2 minutes selon ta connexion car Stirling PDF est un outil complet).

    Utiliser Stirling PDF

    Une fois que le statut passe à « Running » (vert) dans Portainer :

    1. Retourne sur ton navigateur Windows.
    2. Ouvre un nouvel onglet et tape : http://[IP_DU_BEELINK]:8080 (ici c’est du http classique, sans le « s »).
    3. Victoire ! Tu devrais voir l’interface magnifique de Stirling PDF.

    Identifiants de connexion par défaut

    • Nom d’utilisateur: admin
    • Mot de passe: stirling

    La page http://192.168.86.152:8080/ me propose de télécharger pour windows. Ne pas le faire car ca crée un programme windows standalone.

    Par contre je peux installer une PWA (Progressive Web App) lorsque j’aurai un certificat permettant l’affichage https de stirling PDF.