[Tuto] Installer SWAG en Docker ( Reverse Proxy )

[EVO]

Salut @Jeff777
Si tu souhaite installer SWAG sur DSM, alors pour moi cela ne vaut pas la peine. Car ce que va t'offir SWAG en plus, tu ne pourra pas l'exploiter, ou en tout cas, pas correctement, et pas sans te prendre la tete.

Je pense principalement à la protection via fail2ban et/ou crowdsec.

De base, le "reverse"/bridge de DSM prend le dessus, et donc les IP remontée dasn SWAG sont celle du bridge, et non les IP réelle public des visiteurs . Impossible donc de faire de la protection, du filtrage géographique, ...
La solution c'est du montage en Macvlan ( je suppose ), ou des modif dans les fichiers de DSM ( avec le risque de tout casser, ou de devoir recommencer a chaque MAJ ! )

Par contre, si tu parle de passer sur SWAG sur une autre machine qui sera alors par exemple dédiée a cette usage alors je dit OUI, clairement.
SWAG apporte une liberté supplémentaire, des reglages plus fin possible, mais aussi la limitation géographique pour certains domaines, fail2ban, crowdsec , ....

 

[kitchigo]

Pour moi, cette erreur est la cause de tes soucis.
Tu as bien vérifié que ton utilisateur ayant les ID 1000:1000 avait bien les permissions requises pour accéder au dossier de configuration ?

Car à mon avis, c'est là que se trouve ton problème.

Perso, aucun souci avec leur dernière image.

@Bambusa29 Il n'est jamais très conseillé de faire les déclarations de ports avec l'adresse IP devant...

Juste pour confirmer, il faut mettre l'ID de l'user crée dans le conteneur (j'ai crée un User "dockervm") ou bien il faut créer un avec un ID de Proxmox ?
Concernant la redirection sur le routeur pour le port 433 et 80, il faut la rediriger vers l'adresse IP du conteneur contenant Swag ou vers Proxmox ?

 

[Jeff777]

Merci de ta réponse @EVOTk
Je crois que je vais rester avec ma configuration actuelle.

 

[MilesTEG]

Bonjour @MilesTEG1 pourquoi tu dis cela ?

L’intérêt est de n'exposer le conteneur qu'a l'adresse IP de la machine qui l'héberge, sinon par défaut le conteneur est exposé à toutes les adresses par défaut (0:0:0:0) via une règle IPTable qu'il vas créer. De plus sur Portainer, tu peux comme cela accéder directement à ton conteneur en cliquant sur le lien.

C'est bien dit dans la doc officiel :

Important

Publishing container ports is insecure by default. Meaning, when you publish a container's ports it becomes available not only to the Docker host, but to the outside world as well.

If you include the localhost IP address (127.0.0.1) with the publish flag, only the Docker host can access the published container port.

Ho ! Je ne savais pas tout ça...
Cela dit, si je publie un port, c'est pour qu'il soit accessible depuis les ordinateurs du LAN, et notamment depuis SWAG mon reverse proxy.
Donc je ne suis pas convaincu que mettre l'adresse IP de l'hôte soit nécessaire.
Ou alors je n'ai pas tout compris...

Bonjour,
Cela fait un bout de temps que je vois des messages passer à propos de Swag et je me demande si cela vaut la peine que je l'installe.
J'utilise (énormément)le reverse proxy de DSM sur mes deux nas. J'ai une wildcard, utilise HSTS, pihole en docker sur chaque nas. Tout fonctionne très bien.
J'ai du mal a estimer si les options supplémentaires fournis par Swag valent la peine que je tente l'aventure. Merci de vos commentaires

Bah tout dépend de ce que tu veux faire...
Si le reverse proxy de DSM te satisfait, et que tu n'as pas besoin de plus, reste avec lui, il fonctionne très bien.
Mais si tu as besoin d'ajuster plus finement la configuration (ce qui n'est pas vraiment permis par DSM au-delà de l'ajout de quelques en-têtes), ou que tu veux sécuriser avec Fail2ban et/ou crowdsec et/ou Authellia... ou encore utiliser plus finement la géolocalisation des IP, là oui ça devient intéressant.

(voir la suite après la réponse de @EVOTk )​

Salut @Jeff777
Si tu souhaite installer SWAG sur DSM, alors pour moi cela ne vaut pas la peine. Car ce que va t'offir SWAG en plus, tu ne pourra pas l'exploiter, ou en tout cas, pas correctement, et pas sans te prendre la tete.

Je pense principalement à la protection via fail2ban et/ou crowdsec.

De base, le "reverse"/bridge de DSM prend le dessus, et donc les IP remontée dasn SWAG sont celle du bridge, et non les IP réelle public des visiteurs . Impossible donc de faire de la protection, du filtrage géographique, ...
La solution c'est du montage en Macvlan ( je suppose ), ou des modif dans les fichiers de DSM ( avec le risque de tout casser, ou de devoir recommencer a chaque MAJ ! )

Par contre, si tu parle de passer sur SWAG sur une autre machine qui sera alors par exemple dédiée a cette usage alors je dit OUI, clairement.
SWAG apporte une liberté supplémentaire, des reglages plus fin possible, mais aussi la limitation géographique pour certains domaines, fail2ban, crowdsec , ....

Comme le dit @EVOTk , sur Syno, si tu installes SWAG en mode Bridge, (tu peux oublier le host, les ports sont déjà pris), tu ne verras que l'adresse IP de la passerelle du réseau bridge, donc exit fail2ban et crowdsec... et tu perds aussi l'intérêt de la géolocalisation des IP.
Il te faudra obligatoirement passer par un réseau macvlan, mais il me semble que tu maitrises déjà le sujet ^^ donc ça ne devrait pas trop te poser de problème.

Sinon, comme le dit @EVOTk , tu peux aussi installer SWAG sur une autre machine, en host.

Juste pour confirmer, il faut mettre l'ID de l'user crée dans le conteneur (j'ai crée un User "dockervm") ou bien il faut créer un avec un ID de Proxmox ?
Concernant la redirection sur le routeur pour le port 433 et 80, il faut la rediriger vers l'adresse IP du conteneur contenant Swag ou vers Proxmox ?

Heuu, je n'avais pas saisi que tu étais sur du proxmox...
Quoiqu'il en soit, c'est l'utilisateur de l'hôte dont tu passes les IDs qui doit avoir les droits d'accès sur le dossier monté en volume.
Donc est-ce bien ton utilisateur dockervm qui possède les ID 1000/1000 ?

id dockervm

 

[kitchigo]

Heuu, je n'avais pas saisi que tu étais sur du proxmox...
Quoiqu'il en soit, c'est l'utilisateur de l'hôte dont tu passes les IDs qui doit avoir les droits d'accès sur le dossier monté en volume.
Donc est-ce bien ton utilisateur dockervm qui possède les ID 1000/1000 ?

id dockervm

Utilisateur crée dans le conteneur :
id dockervm : uid=1000(dockervm) gid=1000(dockervm) groups=1000(dockervm)

 

[MilesTEG]

Utilisateur crée dans le conteneur :
id dockervm : uid=1000(dockervm) gid=1000(dockervm) groups=1000(dockervm)

Ok, donc maintenant fait un ls -la sur les dossiers pour être sûr que tes dossiers soient bien lisibiles :
- /mnt/docker/
- /share/

Il faut que ton user dockervm y soit le propriétaire, et que tu aies à minima drwxrwx--- en permissions.

 

[kitchigo]

Ok, donc maintenant fait un ls -la sur les dossiers pour être sûr que tes dossiers soient bien lisibiles :
- /mnt/docker/
- /share/

Il faut que ton user dockervm y soit le propriétaire, et que tu aies à minima drwxrwx--- en permissions.

dockervm@docker:/$ ls -la
total 72
drwxr-xr-x  19 root   root     4096 Oct 24 09:57 .
drwxr-xr-x  19 root   root     4096 Oct 24 09:57 ..
lrwxrwxrwx   1 root   root        7 Jun 15 13:58 bin -> usr/bin
drwxr-xr-x   2 root   root     4096 Mar  2  2023 boot
drwxr-xr-x   6 root   root      480 Oct 24 09:57 dev
drwxr-xr-x   3 root   root     4096 Oct 24 10:16 docker
drwxr-xr-x  69 root   root     4096 Oct 24 09:57 etc
drwxr-xr-x   4 root   root     4096 Oct 24 10:27 home
lrwxrwxrwx   1 root   root        7 Jun 15 13:58 lib -> usr/lib
lrwxrwxrwx   1 root   root        9 Jun 15 13:58 lib32 -> usr/lib32
lrwxrwxrwx   1 root   root        9 Jun 15 13:58 lib64 -> usr/lib64
lrwxrwxrwx   1 root   root       10 Jun 15 13:58 libx32 -> usr/libx32
drwx------   2 nobody nogroup 16384 Oct 24 01:45 lost+found
drwxr-xr-x   2 root   root     4096 Jun 15 13:58 media
drwxr-xr-x   2 root   root     4096 Jun 15 13:58 mnt
drwxr-xr-x   3 root   root     4096 Oct 24 01:52 opt
dr-xr-xr-x 296 nobody nogroup     0 Oct 24 09:57 proc
drwx------   3 root   root     4096 Oct 24 01:50 root
drwxr-xr-x  15 root   root      520 Oct 24 10:25 run
lrwxrwxrwx   1 root   root        8 Jun 15 13:58 sbin -> usr/sbin
drwxr-xr-x   2 root   root     4096 Jun 15 13:58 srv
dr-xr-xr-x  13 nobody nogroup     0 Oct 24 09:57 sys
drwxrwxrwt   7 root   root     4096 Oct 24 09:57 tmp
drwxr-xr-x  14 root   root     4096 Jun 15 13:58 usr
drwxr-xr-x  11 root   root     4096 Jun 15 13:58 var

dockervm@docker:/home/docker/appdata/swag/config$ ls -la
total 52
drwxr-xr-x 11 dockervm dockervm 4096 Oct 24 10:28 .
drwxr-xr-x  3 root     root     4096 Oct 24 10:27 ..
-rw-r--r--  1 root     root      233 Oct 24 10:32 .donoteditthisfile.conf
-rw-r--r--  1 root     root       28 Oct 24 10:27 .migrations
drwxr-xr-x  2 root     root     4096 Oct 24 10:27 crontabs
drwxr-xr-x  2 dockervm dockervm 4096 Oct 24 10:32 dns-conf
drwxr-xr-x  3 root     root     4096 Oct 24 10:27 etc
drwxr-xr-x  4 root     root     4096 Oct 24 10:27 fail2ban
drwxr-xr-x  2 dockervm dockervm 4096 Oct 24 10:32 keys
drwxr-xr-x  6 dockervm dockervm 4096 Oct 24 10:27 log
drwxrwxr-x  4 dockervm dockervm 4096 Oct 24 10:32 nginx
drwxr-xr-x  2 dockervm dockervm 4096 Oct 24 10:27 php
drwxr-xr-x  2 dockervm dockervm 4096 Oct 24 10:27 www

Je pense qu'il est la le problème :

dockervm@docker:/home/docker/appdata/swag/config/keys$ ls -la
total 16
drwxr-xr-x  2 dockervm dockervm 4096 Oct 24 10:56 .
drwxr-xr-x 11 dockervm dockervm 4096 Oct 24 10:50 ..
-rw-r--r--  1 dockervm dockervm 1342 Oct 24 10:50 cert.crt
-rw-------  1 dockervm dockervm 1704 Oct 24 10:50 cert.key
lrwxrwxrwx  1 root     root       39 Oct 24 10:56 letsencrypt -> ../etc/letsencrypt/live/mondomaine.ovh

 

[MilesTEG]

Que donne ces commandes :

ls -la /home/docker/appdata/
ls -la /share/

C'est pour voir globalement les permissions des dossiers swag et logs.

En fonction de ce que tu montreras, il faudra faire :

chmod -R 770 /home/docker/appdata/swag
chown -R 1000:1000 /home/docker/appdata/swag

 

[kitchigo]

Que donne ces commandes :

ls -la /home/docker/appdata/
ls -la /share/

C'est pour voir globalement les permissions des dossiers swag et logs.

En fonction de ce que tu montreras, il faudra faire :

chmod -R 770 /home/docker/appdata/swag
chown -R 1000:1000 /home/docker/appdata/swag

J'ai pas de répertoire share je crois.

dockervm@docker:/docker$ ls -la /home/docker/appdata/
total 12
drwxr-xr-x 3 root root 4096 Oct 24 10:27 .
drwxr-xr-x 3 root root 4096 Oct 24 10:27 ..
drwxr-xr-x 3 root root 4096 Oct 24 10:27 swag
dockervm@docker:/docker$ ls -la /share/
ls: cannot access '/share/': No such file or directory

Après de long nuit blanche et de recherche, j'ai enfin réussi a le faire fonctionner

Pour ceux qui ont le même erreur avec OVH voilà ce que j'ai trouvé :
- J'ai supprimé le fichier "letsencrypt" afin qu'il soit régénérée.
- J'ai trouvé sur le github quelqu'un qui à le même problème, ça serait a cause de "dns-lexicon", du coup j'ai fait pip install dns-lexicon==3.15.1 à ça fonctionne...

C'est une solution provisoire le temps que les dépôts se met à jour.

 

[MilesTEG]

J'ai pas de répertoire share je crois.

My bad! Le post dans lequel j'avais vu un volume avec /share/... n'était pas de toi.
Donc oublions le /share

dockervm@docker:/docker$ ls -la /home/docker/appdata/
total 12
drwxr-xr-x 3 root root 4096 Oct 24 10:27 .
drwxr-xr-x 3 root root 4096 Oct 24 10:27 ..
drwxr-xr-x 3 root root 4096 Oct 24 10:27 swag
dockervm@docker:/docker$ ls -la /share/
ls: cannot access '/share/': No such file or directory

Pour ça par contre, les permissions ne sont pas correctes...
Tente les deux commandes chmod et chown.

Pour ta solution palliative, je reste dubitatif... Je n'ai pas besoin de faire celà, et SWAG fonctionne très bien.

 

[kitchigo]

J'ai fait les deux commandes :

root@docker:/docker# ls -la /home/docker/appdata/
total 12
drwxr-xr-x 3 root     root     4096 Oct 24 15:09 .
drwxr-xr-x 3 root     root     4096 Oct 24 15:09 ..
drwxrwx--- 3 dockervm dockervm 4096 Oct 24 15:09 swag

Avec la dernière version de Swag et OVH aucun problème ?

 

[MilesTEG]

J'ai fait les deux commandes :

root@docker:/docker# ls -la /home/docker/appdata/
total 12
drwxr-xr-x 3 root     root     4096 Oct 24 15:09 .
drwxr-xr-x 3 root     root     4096 Oct 24 15:09 ..
drwxrwx--- 3 dockervm dockervm 4096 Oct 24 15:09 swag

Avec la dernière version de Swag et OVH aucun problème ?

Non pas de soucis constaté avec mon ndd ovh et la dernière version de swag.

 

[EVO]

- J'ai trouvé sur le github quelqu'un qui à le même problème, ça serait a cause de "dns-lexicon", du coup j'ai fait pip install dns-lexicon==3.15.1 à ça fonctionne...

Pour ta solution palliative, je reste dubitatif... Je n'ai pas besoin de faire celà, et SWAG fonctionne très bien.

J'en parle ici : https://www.forum-nas.fr/threads/tu...ocker-reverse-proxy.15057/page-11#post-141293

il semblerai que le changement soit coté OVH, et donc le downgrade ne fonctionne pas ! Il faut attendre que Linuxserver upgrade la dépendance, ou faire comme @kitchigo et upgrader la dépendance manuellement dans le conteneur

[BUG] certbot-dns-ovh failed. Breaking change in OVH API propagated to dns-lexicon · Issue #422 · linuxserver/docker-swag

Is there an existing issue for this? I have searched the existing issues Current Behavior DNS authenticator with ovh provider fails with error : swag | Requesting a certificate for redacted.com swa...

github.com

 

[bensonG]

Bonjour,

J'aimerai mettre en place Swag sur mon NAS en docker, en suivant le tuto pour OVH, j'ai un domaine.OVH.
Par contre certaines images du tuto spécifique OVH, donnant des instructions semble avoir lien cassé.
Est il possible de remédier a ca? oui d'avoir une autre méthode?

Merci pour le temps passer a écrire ce tuto.

 

[Tolk]

Bonjour j'arrive pas à faire tourner swag qqun pourrais me guider ?
voila le log que j'ai

using keys found in /config/keys
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:
PUID=1002
PGID=992
TZ=Europe/Paris
URL=omvtolk.fr
SUBDOMAINS=www,jellyfin
EXTRA_DOMAINS=<extradomains>
ONLY_SUBDOMAINS=false
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=QQQQQQQQ@hotmail.com
STAGING=false

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Sub-domains processed are: www.omvtolk.fr,jellyfin.omvtolk.fr
EXTRA_DOMAINS entered, processing
Extra domains processed are: <extradomains>
E-mail address entered: qqqqqqqq@hotmail.com
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for omvtolk.fr and 3 more domains
An unexpected error occurred:
Error creating new order :: Cannot issue for "<extradomains>": Domain name contains an invalid character
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.

 

[MilesTEG]

Hello @Tolk
Pour moi, il faut regarde cette partie de message :

Make sure you entered correct credentials into the /config/dns-conf/ovh.ini file.

À mon avis tes clés API ne sont pas bonnes...

 

[Tolk]

J'ai repris bien vérifier c'est bien ce qui est ressorti de la génération.
J'arrive pas a trouver le log de letsencrypt
maintenant j'ai ca:

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:    1002
User GID:    992
───────────────────────────────────────

using keys found in /config/keys
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:
PUID=1002
PGID=992
TZ=Europe/Paris
URL=omvtolk.fr
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=xxxxxx@hotmail.com
STAGING=

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for omvtolk.fr will be requested
E-mail address entered: xxxxxx@hotmail.com
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for omvtolk.fr and *.omvtolk.fr
Unsafe permissions on credentials configuration file: /config/dns-conf/ovh.ini
Error determining zone identifier for omvtolk.fr: 403 Client Error: Forbidden for url: https://eu.api.ovh.com/1.0/domain/zone/. (Are your Application Key and Consumer Key values correct?)
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.

 

[Nincha]

.......

using keys found in /config/keys
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:
PUID=1002
PGID=992
..........

Hello, les lignes qui commencent par des étoiles semblent dire que les répertoires sous /config/keys ont quelques soucis, soit de permission, soit il manque des trucs.
Premièrement, ces répertoires ont bien pour propriétaire le user qui a l'id 1002 ?
Ensuite, est ce que le fichier (ou dossier je sais pas trop) letsencrypt existe sous /config/keys ?

 

[Tolk]

@Nincha , effectivement un soucis de propriétaire.
Maintenant comme d'autre j'ai un soucis

Unsafe permissions on credentials configuration file: /config/dns-conf/ovh.ini
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.

J'ai cru comprendre à une mise a jour à faire de certbot selon le lien mais je vois pas comment faire
https://github.com/linuxserver/docker-swag/issues/422

 

[Nincha]

Ça me fait penser à une permission trop "permissive" … avec des droits trop ouverts si tu préfères. Un peu le même genre de solution que mon message précédent, mais sur le fichier ovh.ini