[TUTO] Certificat SSL & reverse proxy via Docker

MilesTEG1 · le 11 juillet 2023

Hello

J'aurais besoin de vos lumières si vous le voulez bien 😉

J'utilise SWAG depuis pas mal de temps, et une des dernières MAJ fait que mon RP pour SRM ne fonctionne plus : j'ai une page blanche... Aucune erreur, mais page blanche.

La console me donne ceci que je ne sais pas interpréter pour élaborer une correction...

Voilà mon srm.local.conf :

## Version 2021/05/18
# make sure that your dns has a cname set for <container_name> and that your <container_name> container is not using a base url
# Note for DSM Applications (Package)
# As SWAG is installed in macvlan mode, you have to set the virtual IP for $upstream_app
#       set $upstream_app 192.168.2.230

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name rt2600ac.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;
    
    # GeoIP Blocking with Maxmind Docker-MOD
    include /config/nginx/maxmind-geoblock_and_LAN.conf;

    # Restrict access to some IPs only (LAN & VPNs)
    include /config/nginx/ACL.IP-LAN.conf;

    # Custom error pages
    include /config/nginx/error_pages.conf;
    
    # Custom error files
    access_log /config/log/nginx_not_crowdsec/access_syno_RT.log;
    error_log /config/log/nginx_not_crowdsec/error_syno_RT.log;
    
    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.2.1;
        set $upstream_port 9000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

J'ai tenté avec et sans le http2 pour les listen, via le port http ou le https pour le upstream_port et proto...
Mais rien n'y fait, c'est blanc.
Le ACL.IP-LAN.conf contient les restrictions d'accès suivantes qui ne semblent pas poser de souci puisque la page se charge :

## ACL.IP-LAN.conf
# For my Synology DSM, I created an Access Control Profiles to restrict access only to LAN and VPN IP adresses
# This Access Control Profile is a file in the /etc/nginx/conf.d folder
# But for SWAG-Nginx, it must be with another file.

# Allow all from LAN IPs
allow 192.168.2.0/24;
allow 192.168.1.0/24;

# Allow all from VPNs IPs
allow 192.168.10.0/24;
allow 192.168.11.0/24;
allow 192.168.12.0/24;
allow 10.7.0.0/24;

# Deny all
deny all;

J'arrive bien à accéder à SRM via l'IP du routeur.

Je ne sais pas comment corriger mon accès via SWAG.

Est-ce que l'un de vous saurait m'aider ?
Merci d'avance.

.Shad. · le 11 juillet 2023

@MilesTEG1 Ca a trait au fait que que le script js exécuté renvoie le mauvais MIME type, "text/plain" au lieu de "text/javascript" de ce que j'en comprends, ici par exemple : https://stackoverflow.com/questions/39228657/disable-chrome-strict-mime-type-checking

Après je ne m'y connais clairement assez pour te débugger plus avant personnellement.

Il existe visiblement un workaround dans Nginx, mais qui n'est pas conseillé. Est-ce que tu as testé avec d'autres navigateurs ?

MilesTEG1 · le 11 juillet 2023

@.Shad.
J'ai tenté tous les navigateurs à ma disposition : Ms Edge, Brave, Firefox, Safari. Et tous refusent de me charger la page...
J'ai tenté d'ajouter ça dans le .conf de SRM :

proxy_hide_header X-Content-Type-Options;

Mais sans effet...

Je viens de tenter autre chose.
J'ai fait une réécriture DNS différente pour mon domaine associé à SRM : je l'ai fait pointer sur le NAS, et donc son reverse proxy à lui.
Et là, ça fonctionne, même s'il y a quelques erreurs :

C'est étonnant...

Je vais laisser comme ça pour le moment, mais ça m'enquiquine que ça ne fonctionne pas alors que pour DSM , Photos, etc... ça marche impec.

.Shad. · le 14 juillet 2023

@MilesTEG1 Pour moi c'est lié au fichiers "mime.type" inclus par SWAG dans ses blocs server.
Il faut comparer avec ce que tu trouves dans les configs dans /etc/nginx sur ton NAS.

MilesTEG1 · le 15 juillet 2023

@.Shad.il faudra que je regarde ça , mais vu ce que tu dis , j’ai peur que ça ne soit pas vraiment possible de changer le mime type s’il est défini différemment dans le nginx.conf …

À moins qu’il soit possible de faire une exclusion et de placer dans le .conf du routeur la elle chose que sur le RP de dsm…

.Shad. · le 15 juillet 2023

Il suffit d'enlever l'include qui pose problème dans ton srm.subdomain.conf, et d'ajouter dans ce fichier tout ce qui est habituellement inclus, modulo ce qui pose problème. Ca va être du try and retry pour trouver.

MilesTEG1 · le 15 juillet 2023

@.Shad.
En étudiants les différents fichiers de configuration du nginx du syno et ceux de Swag, j'ai trouvé ces différences :

Et c'est à peu près tout.

Je ne me vois pas trop refaire tout un bloc avec les mêmes choses...

.Shad. · le 16 juillet 2023

J'ai regardé un peu mais je ne trouve rien de probant, sachant que je ne peux pas non plus faire de tests en direct.
De mes recherches, je vois deux "solutions" (je mets entre guillemets car les gens n'expliquent pas pourquoi ça marche d'après eux) :

- ajouter include /etc/nginx/mime.types dans le bloc serveur de ton entrée de proxy inversé

Pour la deuxième ça me semble déjà plus compréhensible, le principe est d'ajouter un filtre regex sur un deuxième bloc location et de forcer le format pour les fichiers de type .js

location ~ .*(\.js) {

    default_type application/javascript;
    include /config/nginx/proxy.conf;
    include /config/nginx/resolver.conf;
    set $upstream_app IP_ROUTEUR;
    set $upstream_port 5000;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

}

MilesTEG1 · le 16 juillet 2023

Je verrais si l’une ou l’autre fonctionne 😇

merci pour les recherches 😊

dragonslore · le 23 septembre 2023

Bonjour à tous,

Tout d'abord un grand merci pour la richesse de cette communauté et les contributions des membres.

J'essaie de suivre ce tuto pour construiremon reverse proxy pour router le trafic de mon container domotique jeedom. Swag + Jeedom sont sur le même Macvlan docker.

Autant j'avais réussi auparavant avec un container Acme à générer le certificat de mon domaine perso hébergé chez OHV (délégué chez Cloudflare), autant en refaisant le tout sur mon container Swag je coince.

Les enregistrement DSN TXT " _acme-challenge" ne se crééent pas et la validation échoue donc.

Voici mon docker-compose

Avez-vous une idée ?

Un grand merci à tous pour votre aide 🙂

Manu

Modifié le 23 septembre 2023 par dragonslore

.Shad. · le 24 septembre 2023

@dragonslore Salut

Au vu du message, il y a un problème avec l'ajout de l'enregistrement _acme-challenge à ta zone DNS, es-tu certain de la validité des credentials API pour l'accès à OVH ?

Peut-être une date de validité expirée ?

dragonslore · le 24 septembre 2023

@.Shad. Salut, merci pour ta réponse, je pense ne pas m'être trompé sur la création de l'app OVH faite hier mais sait-on jamais, voici la chaine.

https://api.ovh.com/createToken/?GET=/domain/zone/&GET=/domain/zone/mondomaine.fr/&GET=/domain/zone/mondomaine.fr/status&GET=/domain/zone/mondomaine.fr/record&GET=/domain/zone/mondomaine.fr/record/*&POST=/domain/zone/mondomaine.fr/record&POST=/domain/zone/mondomaine.fr/refresh&DELETE=/domain/zone/mondomaine.fr/record/*

.Shad. · le 24 septembre 2023

il y a une heure, dragonslore a dit :
@.Shad. Salut, merci pour ta réponse, je pense ne pas m'être trompé sur la création de l'app OVH faite hier mais sait-on jamais, voici la chaine.
https://api.ovh.com/createToken/?GET=/domain/zone/&GET=/domain/zone/mondomaine.fr/&GET=/domain/zone/mondomaine.fr/status&GET=/domain/zone/mondomaine.fr/record&GET=/domain/zone/mondomaine.fr/record/*&POST=/domain/zone/mondomaine.fr/record&POST=/domain/zone/mondomaine.fr/refresh&DELETE=/domain/zone/mondomaine.fr/record/*

Je ne vois pas de requête PUT, je ne sais pas si ça peut avoir une influence.
Je sais qu'à une époque j'avais dû ajouter les autorisations sur l'ensemble des domaines (vu que je n'ai qu'un domaine sur mon compte OVH ça ne posait pas de problème de sécurité), mais je pense que j'avais dû mal m'y prendre.

Je vais faire une instance test avec une nouvelle clé API pour vérifier si j'ai le même problème.

dragonslore · le 24 septembre 2023

En effet tu as raison je n'ai pas de PUT, je vais tester moi aussi et je te fais un retour.

EDIT

@.Shad. c'était bien celà, la requête PUT était manquante, je pense qu'il faut revister le tuto, le premier bloc suggéré dans le tuto ne fonctionnait pas, la seconde hypothèse non plus.

Il faut celà:

https://api.ovh.com/createToken/?GET=/domain/zone/&GET=/domain/zone/mondomaine.fr/&GET=/domain/zone/mondomaine.fr/status&GET=/domain/zone/mondomaine.fr/record&GET=/domain/zone/mondomaine.fr/record/*&POST=/domain/zone/mondomaine.fr/record&POST=/domain/zone/mondomaine.fr/refresh&DELETE=/domain/zone/mondomaine.fr/record/*&PUT=/domain/zone/mondomaine.fr/*

Par contre je suis coincé à l'étape suivante.

J'ai bien répliqué les deux enregistrements créés chez OVH sur cloudflare malgré tout après le redémarrage du container il n'en veut pas. Comme si au second démarrage, il avait renouvelé les clés...

Modifié le 24 septembre 2023 par dragonslore

.Shad. · le 25 septembre 2023

@dragonslore Histoire d'éviter d'être limité par le nombre d'essais successifs, passe la variable STAGING à true pour tes tests.
Je n'ai malheureusement pas le temps pour le moment de répliquer ta situation.

Concernant l'erreur, je sais que parfois let's encrypt ne crée pas deux enregistrements séparés mais concatène les deux chaînes en une seule.

Autre chose, qu'est-ce que Cloudflare vient faire dans l'histoire ? Si tu as délégué la gestion de ta zone DNS à Cloudflare, c'est l'api de ce dernier que tu dois configurer, je fais ça pour le domaine pro de ma femme, acheté sur un site qui ne propose pas d'API de gestion.

Ou alors je n'ai pas compris ce que tu voulais dire.

Modifié le 25 septembre 2023 par .Shad.

dragonslore · le 25 septembre 2023

Il y a 10 heures, .Shad. a dit :

@dragonslore Histoire d'éviter d'être limité par le nombre d'essais successifs, passe la variable STAGING à true pour tes tests.
Je n'ai malheureusement pas le temps pour le moment de répliquer ta situation.

Concernant l'erreur, je sais que parfois let's encrypt ne crée pas deux enregistrements séparés mais concatène les deux chaînes en une seule.

Autre chose, qu'est-ce que Cloudflare vient faire dans l'histoire ? Si tu as délégué la gestion de ta zone DNS à Cloudflare, c'est l'api de ce dernier que tu dois configurer, je fais ça pour le domaine pro de ma femme, acheté sur un site qui ne propose pas d'API de gestion.

Ou alors je n'ai pas compris ce que tu voulais dire.

Merci pour l'astuce "staging" je vais refaire un test après avoir repositionné la gestion des dns de mon domaine chez OVH et dégagé cloudflare (c'était prévu) ==> C'est tout bon pour le certificat maintenant.

Je pensais pouvoir générer le certificat par OVH (c'est là que j'ai acheté mon domaine) et l'utiliser ensuite sur mes services internes au NAS après import.

Bref je reviens à une architecture plus simple.

Mes services custo (Jeedom, adguard home, swag, mosquitto) sont sur mon macvlan et évidemment les services Syno natifs sont sur le host. En jouant avec Link + Route penses-tu que je puisse établir un possible échange bi-directionnel Host <-> Macvlan ?

Voici la configuration de mon macvlan (sur parent aggregated-link ovs_bond0)

networks:
  macvlan:
    name: macvlan
    driver: macvlan
    driver_opts:
      parent: ovs_bond0
    ipam:
      config:
        - subnet: "192.168.1.0/24"
          ip_range: "192.168.1.192/27"
          gateway: "192.168.1.1"

Et mon script pour le Link+Route qui ne semble pas faire l'affaire, malgré mes conversions CIDR.

# Creation de l interface macvlan sur l hote
ip link add mac0 link ovs_bond0 type macvlan mode bridge

# Configuration de l interface avec l adresse reservee
ip addr add 192.168.1.192/32 dev mac0
ip link set dev mac0 address AA:BB:CC:DD:11:45
ip link set mac0 up

# On fait une route entre les IPv4 du reseau mac0 et l'interface
ip route add 192.168.1.192/27 dev mac0

Modifié le 25 septembre 2023 par dragonslore

.Shad. · le 30 septembre 2023

Le 25/09/2023 à 18:12, dragonslore a dit :

Je pensais pouvoir générer le certificat par OVH (c'est là que j'ai acheté mon domaine) et l'utiliser ensuite sur mes services internes au NAS après import.

C'est faisable oui, mais ce n'est pas le plus simple je trouve.
Pour ma part j'utilise le ndd Synology et le renouvellement automatique via DSM pour tout ce qui est service de DSM ne passant par le proxy inversé => Synchro des données de Drive, ABB, etc...

Le 25/09/2023 à 18:12, dragonslore a dit :

Mes services custo (Jeedom, adguard home, swag, mosquitto) sont sur mon macvlan et évidemment les services Syno natifs sont sur le host. En jouant avec Link + Route penses-tu que je puisse établir un possible échange bi-directionnel Host <-> Macvlan ?

Avec le script de montage d'interface virtuelle oui tu n'auras pas de problème.
Pour ma part je réserve le réseau macvlan aux applis ayant absolument besoin de ports déjà utilisés par le NAS, ce n'est pas le cas de Mosquitto si je ne m'abuse. Un réseau bridge est quand même moins contraignant.

Concernant la suite :

Je te conseillerais de ne pas créer le réseau au sein d'une stack contenant des services pour tes applications. Ca n'apporte rien à mon sens, hormis le fait de risquer de faire sauter l'interface virtuelle si tu désactives la stack. Un réseau macvlan a plutôt une vocation pérenne, ce sont des IP qui ne doivent pas être utilisées par ailleurs. La version du script en CLI marche tout aussi bien.
Je ne sais pas quelle version de compose tu utilises, mais sache que les versions 3+ ne permettent pas l'utilisation de ipam.ip-range et ipam.gateway

Le 25/09/2023 à 18:12, dragonslore a dit :

Et mon script pour le Link+Route qui ne semble pas faire l'affaire, malgré mes conversions CIDR.

Essaie de réduire la plage, /27 c'est 30 IP réservées, c'est beaucoup je trouve, /28 c'est 14 c'est déjà plus raisonnable.
De même, essaie de supprimer la ligne où tu définis l'adresse MAC de l'interface, ce n'est pas nécessaire, et si l'adresse ne respecte pas certaines règles l'établissement de l'interface peut échouer.

dragonslore · le 30 septembre 2023

Je peux casser le macvlan pour le recréer après avoir détaché mes containers, puis les réaccrocher au nouveau macvlan sans risquer aucune régression ? Je n'aurai pas besoin de les recréer depuis mes projets docker-compose ?

J'ai par ailleurs laché une question "changement d'IP container sur macvlan" sur cet autre fil et un coup de pouce m'aiderait beaucoup:

Modifié le 30 septembre 2023 par dragonslore

.Shad. · le 30 septembre 2023

Il y a 2 heures, dragonslore a dit :

Je peux casser le macvlan pour le recréer après avoir détaché mes containers, puis les réaccrocher au nouveau macvlan sans risquer aucune régression ? Je n'aurai pas besoin de les recréer depuis mes projets docker-compose ?

Oui c'est le même fonctionnement que pour n'importe quel autre type de réseau.

Modifié le 30 septembre 2023 par .Shad.

rimase · le 8 octobre 2023

Consultez les fichiers journaux de SWAG pour voir s'il y a des erreurs ou des avertissements liés à votre problème. Les logs peuvent fournir des indices sur ce qui ne fonctionne pas correctement

192.168.100.1 192.168.1.1

Modifié le 9 octobre 2023 par rimase

Lelolo · le 8 octobre 2023

@rimaseC'est quoi le rapport avec le sujet ?

Dino Rayn · le 28 octobre 2023

@.Shad. Merci beaucoup pour ton tuto

Je suis actuellement à la mise en place du docker SWAG et je n'ai pas les résultats espérés.

Voici mes deux fichiers .sh

maclvan_net.sh

docker network create -d macvlan \
--subnet=192.168.50.0/24 \
--ip-range=192.168.50.210/29 \
--gateway=192.168.50.1 \
-o parent=eth0 \
macvlan_net

mac0.sh :

#!/bin/sh

# Script permettant la communication entre
# un conteneur appartenant a un reseau macvlan et son hote
# A lancer au demarrage de l'hote

# Temporisation
#sleep 60

# Creation de l interface macvlan sur l hote
ip link add mac0 link eth0 type macvlan mode bridge

# Configuration de l interface avec l adresse reservee
ip addr add 192.168.50.200/32 dev mac0
ip link set dev mac0 address AA:BB:CC:DD:11:45
ip link set mac0 up

# On fait une route entre les IPv4 du reseau mac0 et l'interface
ip route add 192.168.50.208/29 dev mac0

Concernant l'ip "192.168.50.208/29" est la première IP de ma plage /29.

Jusqu'à là, tous les scripts s'exécutent correctement.

J'ai ensuite lancé mon docker swag :

version: "2.1"
services:
  swag:
    image: linuxserver/swag
    container_name: swag
    networks:
      macvlan_net:
        ipv4_address: 192.168.50.211
    cap_add:
      - NET_ADMIN
    dns:
      - 8.8.8.8
      - 8.8.4.4

    environment:
      - PUID=1026
      - PGID=100
      - TZ=Europe/Paris
      - URL=xxxxxxxx.com
      - SUBDOMAINS=wildcard
      - VALIDATION=dns
      - DNSPLUGIN=ovh
      - DHLEVEL=2048
      - EMAIL=xxxxxx@gmail.com
      - ONLY_SUBDOMAINS=false
      - STAGING=false
    volumes:
      - /volume1/docker/swag/config:/config:rw
    restart: unless-stopped

networks:
   macvlan_net:
      external: true

J'ai dû ajouter des DNS sans quoi swag n'arrivait pas à récupérer de la donnée de OVH.

Au premier démarrage du docker ou à chaque fois que je modifie une variable d'environnement, j'ai l'erreur :

Citation
 
Error adding TXT record: Expecting value: line 1 column 1 (char 0)

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

ERROR: Cert does not exist! Please see the validation error above. Make sure you entered correct credentials into the /config/dns-conf/ovh.ini file.

Cela semble être dû à un problème de MAJ de dépendance. Pour m'en sortir, je rentre dans l'instance swag et j'exécute la commande proposé dans ce commentaire : https://github.com/linuxserver/docker-swag/issues/422#issuecomment-1778615155 puis je redémarre.

J'ai fait une redirection de port 80 et 443 vers mon IP virtuelle de mon instance SWAG

CleanShot2023-10-28at20_07_46.png.7b2f2b6ee31fc0b8a0175a859b2f2ae6.png

J'ai ensuite modifié mon fichier "portainer.subdomain.conf.sample" :

## Version 2023/05/31
# make sure that your portainer container is named portainer
# make sure that your dns has a cname set for portainer

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name portainer.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.50.200;
        set $upstream_port 9000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_hide_header X-Frame-Options; # Possibly not needed after Portainer 1.20.0
    }

    location ~ (/portainer)?/api {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.50.200;
        set $upstream_port 9000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_hide_header X-Frame-Options; # Possibly not needed after Portainer 1.20.0
    }
}

J'ai redémarré mon docker swag et voici les logs :

───────────────────────────────────────
      ██╗     ███████╗██╗ ██████╗ 
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝ 
   Brought to you by linuxserver.io
───────────────────────────────────────
To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID:    1026
User GID:    100
───────────────────────────────────────
generating self-signed keys in /config/keys, you can replace these with your own keys if required
..+.......+..+.+...+..+..........+++++++++++++++++++++++++++++++++++++++*.....+......+.........+.+...+..+......+.......+...+..+.+.........+.....+......+.........+.+............+..+.......+.....+.+..+......+......+......+...+....+...+...+.....+......+...+...+...............+...+.+......+..+.+.....+......+++++++++++++++++++++++++++++++++++++++*..........+.............+.....+....+...+..+.........+....+......+..+...++++++
...+..+......+.......+...+...+..+...+.........+.+......+...+...........+.+...........+....+......+...+.....+.+.....+...+++++++++++++++++++++++++++++++++++++++*.+.........+....+++++++++++++++++++++++++++++++++++++++*..+.....+.+..+...+..........+............+...............+......+..+.......+...+............+...+..+...............+.+......+.....+.+..+......+......+.+...............+..+...............+.+..+...+..........+...........+................+..+.......+...+..+...+..........+...+...+.....+..........+..+.........+...+.......+...+.................+...+.+......+.....+.+...+......+...........+...+.+.....+.+...+..+...+....+...+....................+...+.+....................+.+...+.....+.+......+...+..........................+......+.........+...+.....................+....+.....+............+...+.......+.....+.+.........+...+...+..+...+...+.+...........+...+.......+.....+............+.............+...+.....+.........+............+....+..+....+...+............+.........+..+..........+............+..+...+......+.......+..+......+....+...+..............+....+.....+.........+................+............+..+.......+........+.......+...+......+..+..............................+...+......+...+......+....+......+...............+.........+......+.................++++++
-----
chown: cannot dereference '/config/keys/letsencrypt': No such file or directory
**** Permissions could not be set. This is probably because your volume mounts are remote or read-only. ****
**** The app may not work properly and we will not provide support for it. ****
Variables set:

6
PGID=100
TZ=Europe/Paris
URL="xxxxxxx.com"
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=xxxxxxxx@gmail.com
STAGING=false
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for xxxxxxx.com will be requested
E-mail address entered: xxxxxxxx@gmail.com
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for xxxxxxxx.com and *.xxxxxxx.com
Unexpected response from OVH APIs for POST /domain/zone/xxxxx.com/refresh (response dumped as plain text):
Unexpected response from OVH APIs for POST /domain/zone/xxxxxx.com/refresh (response dumped as plain text):
Waiting 120 seconds for DNS changes to propagate
Unexpected response from OVH APIs for POST /domain/zone/xxxxxx.com/refresh (response dumped as plain text):
Unexpected response from OVH APIs for POST /domain/zone/xxxxxx.com/refresh (response dumped as plain text):
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/xxxxxx.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/xxxxx.com/privkey.pem
This certificate expires on 2024-01-26.
These files will be updated when the certificate renews.
NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
New certificate generated; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
[custom-init] No custom files found, skipping...
[ls.io-init] done.

Server ready

Pour information j'utilisais jusqu'à présent ACME pour gérer tous mes sous-domaines automatiquement. J'ai temporairement désactivé le docker acme. L'idée est que je garde sur DSM uniquement mon ndd principal et les sous domaines soient gérés via swag.

J'ai également essayé de modifier les variables d'environnements dans le docker compose pour isoler mon test mais sans succès :

- SUBDOMAINS=portainer,
- ONLY_SUBDOMAINS=true

Je remarque cependant le message d'erreur ci-dessous qui me laisse fortement présager qu'il y a un problème au niveau de mes permissions. Effectivement le contenu de mon dossier keys est vide. Je n'ai cependant pas réussi à résoudre ce message. Mon PUID et PGID sont pourtant corrects et j'ai ajouté "rw" à la fin de mon volume dans mon docker compose. As-tu une idée pour résoudre ce problème ? J'ai regardé les issues du repo swag mais sans succès :

Citation

chown: cannot dereference '/config/keys/letsencrypt': No such file or directory
**** Permissions could not be set. This is probably because your volume mounts are remote or read-only. ****
**** The app may not work properly and we will not provide support for it. ****

et dans mon dossier letsencrypt le contenu ci-dessous. On dirait un certificat .pem consolidé. De ce fait, a chaque redémarrage de mon docker swag, il essaye de chercher les certificats "/etc/letsencrypt/live/xxxx.com/fullchain.pem" et "/etc/letsencrypt/live/xxxx.com/privkey.pem" mais il ne les trouve pas donc il considère qu'il y à peut-être un problème de permission ! Là je pige plus du tout sachant que dans les logs de mon docker swag j'ai le message ci-dessous. C'est sûrement dû à un lien symbolique ? :

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/xxxx.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/xxxxx.com/privkey.pem
This certificate expires on 2024-01-26.

Encore plus étrange, lorsque je liste les fichiers contenu dans "letsencrypt/live/xxxx.com j'ai bien les certificats visibles mais pas côté DSM. :

CleanShot2023-10-28at17_54_03.png.c23685db13176c7cd0f6d47e55613158.png

CleanShot2023-10-28at17_46_44.png.b0170bf2d8508f066248340502caa2e9.png

EDIT : pour le message avec le problème de permission, il intervient uniquement au premier démarrage ou lorsque je modifie une variable d'environnement. En gros je pense qu'il s'affiche automatiquement lorsque le contenu du dossier letsencrypt est vide. Je suppose donc que c'est un faux problème mais je préfère le laisser ici, si d'autres personnes se pose la question. et voici le résultat lorsque je redémarre swag après que celui ci est indiqué avoir généré les certificats :

───────────────────────────────────────
      ██╗     ███████╗██╗ ██████╗ 
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝ 
   Brought to you by linuxserver.io
───────────────────────────────────────
To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID:    1026
User GID:    100
───────────────────────────────────────
using keys found in /config/keys
Variables set:
�
6
PGID=100
TZ=Europe/Paris
URL=xxxxxxxx.com
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=xxxxxxx@gmail.com
STAGING=false
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for xxxxxxx.com will be requested
E-mail address entered: xxxxxxxxxx@gmail.com
dns validation via ovh plugin is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
[custom-init] No custom files found, skipping...
[ls.io-init] done.
�
Server ready

Le résultat des courses est que si j'accède à http://192.168.50.200:9000 je suis correctement redirigé vers mon instance portainer. Cependant, lorsque je tape https://portainer.xxxxx.com alors j'ai mon écran webstation de DSM qui s'affiche :

Ne faudrait-il pas que je supprime mon certificat généré par acme dans DSM ?

Est ce que je dois supprimer mon ouverture de port 80/443 vers l'IP de mon NAS ? Je me dis qu'il ne peut y avoir qu'une redirection possible côté routeur ?

Avec SWAG, est-ce que tous mes sous domaines sont actifs directement sans paramétrage au préalable ? Je m'explique : Si par exemple j'utilise homepage et que dans son fichier homepage.subdomain.conf.sample les entrées pour "set $upstream_app" et "set $upstream_port" sont corrects, alors je pourrais directement y accéder en tapant homepage.xxxxx.com ? Si oui, est il possible de désactiver l'activation automatique sans rentrer dans les fichiers de configuration ?

Côté Swag Dashboard, portainer est bien disponible (pour info j'avais oublié de supprimer le .sample à la fin du fichier...) mais il n'est pas accessible :

Merci beaucoup pour ton aide !

Modifié le 29 octobre 2023 par Dino Rayn

.Shad. · le 29 octobre 2023

Salut @Dino Rayn j'ai bien vu ton message, pas eu le temps de le lire je suis en déplacement je te réponds probablement ce soir ou demain. 😉

.Shad. · le 30 octobre 2023

@Dino Rayn Salut, j'ai bien parcouru ton post.
Concernant les permissions il faudrait que je remette en oeuvre mon tutoriel, il a été rédigé il y a maintenant un certain temps, il se peut (c'est même sûr) que des étapes aient changé.
Quoiqu'il en soit il est fort probable comme tu dis que les fichiers non visibles soient des liens symboliques. Il faut que je le confirme en reproduisant mon tutoriel.

Pour le réseau macvlan et l'interface virtuelle, je note que tu as mis 192.168.50.210/29 dans une des déclarations et 192.168.50.208/29 dans l'autre, même si c'est censé couvrir la même plage autant spécifier des valeurs identiques.

Concernant ton fichier conf pour Portainer il me semble ok.

En revanche, si ton URL portainer.ndd.tld pointe vers Webstation, c'est que :

- ta résolution DNS lui dit de le faire, donc vérifier si tu as un serveur DNS local et vérifier via un nslookup vers quoi pointe cette URL

- tu n'as pas de résolution locale, en ce cas il est possible que la résolution soit publique, ce qui implique vu de l'extérieur, la redirection des ports 80 et 443 ne se fait pas vers SWAG mais vers le NAS

- tu as potentiellement un cache persistant dans ton navigateur, supprimer donc les cookies liés à ton NDD ou faire un test en navigation privée.

Dans ton cas, portainer.ndd.tld doit pointer vers l'IP de SWAG (.211)

Le 28/10/2023 à 5:25 PM, Dino Rayn a dit :

Est ce que je dois supprimer mon ouverture de port 80/443 vers l'IP de mon NAS ? Je me dis qu'il ne peut y avoir qu'une redirection possible côté routeur ?

Je serais très étonné que tu puisses rediriger un même port vers plusieurs IP, sinon comment le routeur pourrait-il faire un choix ? le problème vient sûrement de là. Il faut effectivement que ces deux ports soient redirigés vers .211

Le 28/10/2023 à 5:25 PM, Dino Rayn a dit :

Avec SWAG, est-ce que tous mes sous domaines sont actifs directement sans paramétrage au préalable ? Je m'explique : Si par exemple j'utilise homepage et que dans son fichier homepage.subdomain.conf.sample les entrées pour "set $upstream_app" et "set $upstream_port" sont corrects, alors je pourrais directement y accéder en tapant homepage.xxxxx.com ? Si oui, est il possible de désactiver l'activation automatique sans rentrer dans les fichiers de configuration ?

Juste un peu de contexte, même si tu dois déjà le savoir.

Par défaut, la meilleure manière de fonctionner pour SWAG est d'être dans un réseau bridge personnalisé. Ce qui se fait facilement quand les ports 80 et 443 de l'hôte sont libres, ce qui n'est pas le cas avec DSM. Dans ce contexte, tous les conteneurs qui ne nécessitent pas d'autre accès que via une GUI par exemple, n'ont aucune port exposé sur le NAS, ils sont simplement adjoints au réseau bridge de SWAG. Les fichiers de SWAG sont préconfigurés pour utiliser la résolution DNS interne de Docker, qui permet de joindre une application par le nom de son conteneur.

Et dans ces conditions là uniquement, les fichiers conf sont utilisables sur le champ, si tu ajoutes le mod swag-auto-reload à ton instance, ça fait même en sorte que lorsqu'un fichier .conf.sample devient .conf, nginx est automatiquement rechargé pour en tenir compte.

Ca c'est quand tu utilises SWAG sur un hôte libre, ou dans une VM.
Dans notre cas, tu dois effectivement personnaliser l'upstream_app et l'upstream_port, mais rien de plus.

Dans tous les cas, un fichier avec une extension autre que .conf ne sera pas actif.

Dino Rayn · le 30 octobre 2023

@.Shad., le problème était tout simplement la redirection vers l'IP de mon NAS... Tu avais raison.

Étant donné que je gère d'autres domaines et notamment mon ndd avec acme.sh, j'ai pas mal de sous domaines directement dans DSM déjà configurés. En faisant pointer 80/443 directement sur l'ip de swag, tous mes anciens services ne sont plus accessibles.

Existe il un moyen de travailler avec acme.sh + swag afin de ne pas perdre mon ancienne config (et surtout pour que mon nom de domaine refonctionne de nouveau) ?

Citation

Pour le réseau macvlan et l'interface virtuelle, je note que tu as mis 192.168.50.210/29 dans une des déclarations et 192.168.50.208/29 dans l'autre, même si c'est censé couvrir la même plage autant spécifier des valeurs identiques.

Par rapport à ce que tu dis, le problème est que la commande en rouge ci-dessous me renvoyait l'erreur ci-dessous :

Citation

#!/bin/sh

# Script permettant la communication entre
# un conteneur appartenant a un reseau macvlan et son hote
# A lancer au demarrage de l'hote

# Temporisation
#sleep 60

# Creation de l interface macvlan sur l hote
ip link add mac0 link eth0 type macvlan mode bridge

# Configuration de l interface avec l adresse reservee
ip addr add 192.168.50.200/32 dev mac0
ip link set dev mac0 address AA:BB:CC:DD:11:45
ip link set mac0 up

# On fait une route entre les IPv4 du reseau mac0 et l'interface
ip route add 192.168.50.210/29 dev mac0

Citation

sudo ip route add 192.168.50.210/29 dev mac0
Password: 
RTNETLINK answers: Invalid argument

Malgré mes recherches, je n'ai pas trouvé de solution de contournement.

Modifié le 30 octobre 2023 par Dino Rayn

Connexion

[TUTO] Certificat SSL & reverse proxy via Docker

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.

.Shad.

ggdn18

Images postées

Rejoindre la conversation

Qui est en ligne 3 membres, 0 anonyme, 123 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante