Swagme

Bonjour, si ça peut donner des indices, je confirme que chez moi (DS918+ sous DSM7 avec un HDHomeRun Duo et Plex dans un container Docker), ça fonctionne parfaitement quand je relis le fichier dans Plex (client web, appli android, appli ios, etc.). Je ne peux par contre pas tester avec VideoStation car je n'ai pas installé ce paquet (et ne souhaite pas le faire). J'espère que vous trouverez une solution, sinon Plex est vraiment pratique avec le HDHomeRun pour planifier les enregistrements, gérés les séries, etc.) Bonne investigation.

Ah, enfin un progrès !!! Je pense que j'ai un souci avec accueil.mondomaine.fr (qui est un Dashboard tournant dans un container sur le NAS, Dashmachine). Le reverse proxy de swag pour ce sous-domaine accueil (qui fonctionnait avant que je paramètre authelia) doit avoir un souci maintenant (j'arrive pourtant à y accéder via l'ip du nas, mais pas via le domaine, étrange...). Et comme c'était l'url de redirection d'authelia après une authentification réussie, ça coinçait. Cette fois, j'ai mis mon www.mondomaine.fr comme cible de la redirection, et quand je rentre mes id et mdp dans Authelia (que ce soit dans http://192.168.1.10:9091 ou dans authelia.mondomaine.fr, je suis bien redirigé vers mon site www. Mais je continue à avoir les mêmes erreurs dans les logs de nginx swag si j'essaye d'accéder à rss.mondomaine.fr : 2021/10/06 21:48:20 [error] 506#506: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 21:48:20 [error] 506#506: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 21:48:20 [error] 503#503: *9 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" 2021/10/06 21:48:20 [error] 503#503: *9 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" (PS : est-ce normal que l'ip du "client" dans ces logs soit celle de mon routeur DHCP, et pas de l'ordi d'où je fais mes tests en 192.168.1.51 ?)

ok, j'ai donc mis ça dans configuration.yml d'Authelia : access_control: default_policy: deny networks: - name: internal networks: - 192.168.1.0/24 - 172.16.0.0/12 - 127.0.0.0/8 - 10.0.0.0/8 rules: - domain: '*.mondomaine.fr' policy: bypass networks: - internal (sauf erreur de ma part, il faut mettre des ' simple autour du *.mondomaine.fr 😉 Et ça dans le reverse proxy d'Authelia : ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. server { listen 443 ssl; listen [::]:443 ssl; server_name authelia.mondomaine.fr; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.1.10; set $upstream_port 9091; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Je suis par contre sceptique sur le fait que ça puisse marcher en l'état : en effet la doc d'authelia explique que par défaut le service va utiliser un subfolder (soit service.mondomaine.fr/authelia . Je comprends dans leur entête ci-dessus que si je veux utiliser au contraire authelia.mondomaine.fr, il faut paramétrer autre chose dans authelia-location.conf et authelia-server.conf, or là je n'y ai rien changé. Résultat : l'interface de login d'Authelia est bien visible sur authelia.mondomaine.fr mais j'ai tourjours l'erreur 500 si j'essaye de charger rss.mondomaine.fr (avec les lignes authelia actives) et si je désactive les lignes Authelia, j'accède bien à rss.mondomaine.fr Bizarerie (qui peut être te donnera une idée), si je mets dans ce reverse proxy subdomain "authelia" au lieu du l'ip du raspberry hôte "192.168.1.10", j'obtiens l'erreur 500. set $upstream_app authelia; #ne fonctionne pas -> erreur 500 set $upstream_app 192.168.1.10; #fonctionne (bizarre car pourtant swag et authelia sont dans le même network, et c'est bien le nom des containers

J'ai été voir les fichier de log d'erreur de Nginx dans le container Swag (soit dans swag/config/log/nginx/error.log) et si je garde les 2à dernières lignes environ, j'ai ça : 2021/10/06 18:45:13 [crit] 504#504: connect() to [2a02:26f0:2b00:13::5f64:55a4]:80 failed (99: Address not available) while requesting certificate status, responder: r3.o.lencr.org, peer: [2a02:26f0:2b00:13::5f64:55a4]:80, certificate: "/config/keys/letsencrypt/fullchain.pem" 2021/10/06 18:45:13 [crit] 504#504: connect() to [2a02:26f0:2b00:13::5f64:5595]:80 failed (99: Address not available) while requesting certificate status, responder: r3.o.lencr.org, peer: [2a02:26f0:2b00:13::5f64:5595]:80, certificate: "/config/keys/letsencrypt/fullchain.pem" Ensuite j'ai : 2021/10/06 18:45:21 [error] 505#505: *3 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 18:45:21 [error] 505#505: *3 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 18:45:21 [error] 505#505: *14 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" 2021/10/06 18:45:21 [error] 505#505: *14 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "rss.mondomaine.fr", referrer: "https://rss.mondomaine.fr/" 2021/10/06 18:45:24 [error] 505#505: *3 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET / HTTP/2.0", host: "accueil.mondomaine.fr" 2021/10/06 18:45:24 [error] 505#505: *14 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "accueil.mondomaine.fr", referrer: "https://accueil.mondomaine.fr/" 2021/10/06 18:48:33 [error] 506#506: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 18:48:33 [error] 506#506: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 18:48:36 [error] 506#506: *2 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET / HTTP/2.0", host: "accueil.mondomaine.fr" 2021/10/06 18:50:08 [error] 504#504: *4 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "adguard.mondomaine.fr" 2021/10/06 18:50:08 [error] 504#504: *4 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET / HTTP/2.0", host: "adguard.mondomaine.fr" 2021/10/06 18:50:08 [error] 504#504: *7 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", subrequest: "/authelia/api/verify", host: "adguard.mondomaine.fr", referrer: "https://adguard.mondomaine.fr/" 2021/10/06 18:50:08 [error] 504#504: *7 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: adguard.mondomaine.fr, request: "GET /favicon.ico HTTP/2.0", host: "adguard.mondomaine.fr", referrer: "https://adguard.mondomaine.fr/" 2021/10/06 18:50:11 [error] 504#504: *9 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 18:50:11 [error] 504#504: *9 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" 2021/10/06 18:50:14 [error] 504#504: *9 no host in upstream ":10080", client: 192.168.1.1, server: accueil.mondomaine.fr, request: "GET / HTTP/2.0", host: "accueil.mondomaine.fr" 2021/10/06 19:36:11 [error] 504#504: *27 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 45.146.164.110, server: _, request: "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "MON-IP-PUBLIQUE", referrer: "http://MON-IP-PUBLIQUE:80/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php" 2021/10/06 19:36:12 [error] 504#504: *34 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 45.146.164.110, server: _, request: "GET /index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "MON-IP-PUBLIQUE", referrer: "http://MON-IP-PUBLIQUE:80/index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21" 2021/10/06 19:36:14 [error] 504#504: *42 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 45.146.164.110, server: _, request: "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "MON-IP-PUBLIQUE", referrer: "http://MON-IP-PUBLIQUE:80/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php" 2021/10/06 20:38:40 [error] 506#506: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/06 20:38:40 [error] 506#506: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" hum, des idées ? ok, je teste ça et reviens éditer ici dans 5 min. Merci de ton aide 🙂

J'ai donc mis ça (et uniquement ça, aucune autre règle) : networks: - name: internal networks: # réseau LAN local - 192.168.1.0/24 # réseau Docker - 172.16.0.0/12 # localhost - 127.0.0.0/8 # a priori les vpn - openvpn serait sur 10.0.8.0/24 - et wireguard ? - 10.0.0.0/8 rules: ## Rules applied to everyone - domain: - nas.mondomaine.fr - www.mondomaine.fr - mondomaine.fr - adguard.mondomaine.fr - rss.mondomaine.fr - accueil.mondomaine.fr policy: bypass networks: - internal ...et nope, ça me renvoie toujours cette erreur 500. Et dès que je décommente les lignes d'Authelia ci-dessous, la redirection refonctionne... Argghhh ! server { # enable for Authelia # include /config/nginx/authelia-server.conf; location / { # enable for Authelia # include /config/nginx/authelia-location.conf;

Hello @.Shad. J'ai changé le nom du daemon.json pour qu'il ne soit plus pris en compte. J'ai rebooté et Portainer et les containers fonctionnent normalement. J'ai mis à jour tous les containers. Voici ce que donne "docker ps" : CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 023122bc6a23 authelia/authelia "/app/entrypoint.sh …" 48 minutes ago Up 24 minutes (healthy) 0.0.0.0:9091->9091/tcp, :::9091->9091/tcp authelia 9cf2a7c07ac8 linuxserver/swag:latest "/init" 49 minutes ago Up 25 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp swag 373724ea8175 linuxserver/phpmyadmin:version-5.1.1 "/init" 50 minutes ago Up 25 minutes 443/tcp, 0.0.0.0:8080->80/tcp, :::8080->80/tcp phpmyadmin 9c44f231e5d4 linuxserver/mariadb "/init" 50 minutes ago Up 25 minutes 3306/tcp authelia_mariadb 1aa11213a81a redis:latest "docker-entrypoint.s…" 51 minutes ago Up 25 minutes 6379/tcp redis 105398912b8f portainer/agent "./agent" 51 minutes ago Restarting (1) 35 seconds ago portainer_agent 8f28dadaf608 adguard/adguardhome:latest "/opt/adguardhome/Ad…" 51 minutes ago Up 25 minutes 0.0.0.0:53->53/udp, :::53->53/udp, 80/tcp, 68/udp, 0.0.0.0:53->53/tcp, :::53->53/tcp, 0.0.0.0:853->853/tcp, :::853->853/tcp, 443/tcp, 3001/tcp, 443/udp, 5443/tcp, 5443/udp, 0.0.0.0:3000->3000/tcp, 0.0.0.0:67->67/udp, :::3000->3000/tcp, :::67->67/udp, 8853/udp, 6060/tcp adguardhome 0cd7a71ba8f4 containrrr/watchtower "/watchtower" 52 minutes ago Up 25 minutes 8080/tcp watchtower 4acfa320672d portainer/portainer-ce "/portainer" 4 days ago Up 25 minutes 0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 0.0.0.0:9000->9000/tcp, :::9000->9000/tcp, 9443/tcp portainer Je t'envoi en MP le fichier configuration.yml. En revanche je n'ai pas créé de reverse proxy pour Authelia (de la forme https://auth.mondomaine.fr) car selon la doc, il faudrait que je modifie en conséquence les fichiers authelia-server.conf et authelia-location.conf mais je ne sais pas de quelle manière (cf. texte ci-dessous en entête du fichier authelia.subdomain.conf.sample) ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. Or je comprends que par défaut, ça devrait fonctionner avec ma requête renvoyée vers mondomaine.fr/authelia, donc le problème doit être ailleurs. Merci pour ton aide, je commence à désespérer de trouver la solution...

il faut donc que je remette le fichier /etc/docker/daemon.json dans son état d'origine. En l'état j'ai juste 1 ligne : { "dns": ["80.67.169.12", "80.67.169.40"] } Faut-il l'effacer, mettre autre chose, ou tout simplement effacer ce fichier daemon.json ? Concernant cette remarque : Mon container Adguard a les paramètres de translation suivant : donc sauf erreur de ma part, c'est bon ?

@.Shad. je me doute bien que pour toi c'est compliqué de m'aider, et je te remercie déjà pour toute cette aide. Tes commentaires et remarques m'aident néanmoins à avancer je pense. Concernant les réseaux, je comprends tes recommandations. En revanche, ma situation est un peu différente puisque toute la partie reverse-proxy est déportée sur le raspberry pi, et que les autres services (freshrss, dashmachine, etc.) sont sur le NAS. Sur le Pi, j'ai : sur le réseau host "system" : rien sur le réseau bridge "system" : Adguard Hom + Watchtower + Portainer (+ Portainer agent pour accèder aussi depuis le Portainer du NAS) sur un bridge "perso" (nommé "swag_default") : Swag + Authelia + MariaDB + Redis + phpMyAdmin Concernant mon problème, je pense que je commence à circonscrire son origine. J'ai les indices suivants : le reverse proxy de SWAG fonctionne sans Authelia j'arrive à atteindre la page d'Authelia sur 192.168.1.10:9091 (IP du Pi), et quand je teste un utilisateur, les logs d'Authelia montre que les id et mdp sont ok par contre, je ne suis pas redirigé sur la page que j'ai précisé dans authelia/config/configuration.yml : default_redirection_url: https://accueil.mondomaine.fr/ si j'active les lignes d'Authelia dans les .conf de SWAG, j'ai l'erreur 500. Mais si je désactive ces lignes (sans rien changer d'autre), la redirection refonctionne J'en déduis donc que le problème survient quand je demande à accéder à (par exemple) rss.modomaine.fr, que SWAG voit qu'il doit rediriger vers telle adresse ET qu'il doit me faire passer par Authelia. Et là ça coince avec l'erreur 500 nginx. Donc je suppose que ça coince pour afficher rss.modomaine.fr/authelia Donc on progresse 🤔 J'ai regardé les logs de swag/config/log/nginx juste après cette tentative d'accès à rss.mondomaine.fr : 2021/10/02 18:05:56 [error] 502#502: *2 authelia could not be resolved (3: Host not found), client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", subrequest: "/authelia/api/verify", host: "rss.mondomaine.fr" 2021/10/02 18:05:56 [error] 502#502: *2 auth request unexpected status: 502 while sending to client, client: 192.168.1.1, server: rss.mondomaine.fr, request: "GET / HTTP/2.0", host: "rss.mondomaine.fr" Ces messages t'évoquent quelque chose ? Dans le fichier authelia.subdomain.conf.sample (que je n'ai pas activé), je lis ça : ## Version 2021/05/18 # make sure that your dns has a cname set for authelia # the default authelia-server and authelia-location confs included with letsencrypt rely on # subfolder proxy at "/authelia" and enabling of this proxy conf is not necessary. # But if you'd like to use authelia via subdomain, you can enable this proxy and set up your own # authelia-server and authelia-location confs as described in authelia docs. Donc je pense que c'est là que ça coince : Je n'ai pas de DNS server sur mon réseau local (j'y songe mais rien en l'état, ni sur le NAS ni ailleurs). Chez OVH (mon domaine), j'ai mis en place une redirection globale vers mon ip fixe (*.mondomaine.fr -> 86.123.43.23) J'ai AdGuard Home (sans DNS rewrite) J'ai le reverse proxy SWAG, mais je n'ai créé aucune règle pour authelia (puisque ces lignes au dessus disent que c'est inutile puisque par défault c'est un subfolder /authelia qui est utilisé). Donc je crois que le problème est peut être là : # make sure that your dns has a cname set for authelia Je pensais que les containers pouvant se parler (puisque dans le même réseau docker) et que ça suffisait. Mais peut être faut-il "mieux déclarer" Authelia ? Est-ce que justement de configurer le DNS server sur le NAS pourrait aider ? PS : je vais lire (en étant concentré) ton message dans l'autre fil sur le DNS server ; je me dis que j'ai peut être mis le bazar dans les réglages DNS du Pi en allant modifier etc/dhcpcd.conf et /etc/docker/daemon.json. Je te pose l'éventuelle question dans cet autre fil. Désolé de m'éparpiller à ces 2 endroits 😞

@Jeff777 heu bah non, pourquoi tu dis ça, ça m'avait l'air très clair (et là tu jettes le doute...). Avec l'ordre d' @oracle7 je pense qu'on obtiendrait ta config "bof" avec dans AdGuard toutes les requêtes qui seraient vues comme provenant du NAS (pas terrible pour créer des filtrage différencié). Alors qu'avec ton ordre "recommandé" j'aurai dans Adguard chaque client bien séparé. Donc je préfère ta config "recommandée" (qui finalement a fonctionné, exact ?) et ça donnerait : dans le routeur DHCP : je mets comme DNS principal (et uniquement lui) l'ip du raspberry avec AdGuard Home (192.168.1.10) NB : tous les clients du réseau utiliseront donc cette ip comme DNS : est-ce problématique pour le NAS (sorte de boucle ?) dans le raspberry pi, il faut mettre l'ip du NAS (192.168.1.20) en DNS à 3 endroits (est-ce bien ça ?) : dans etc/dhcpcd.conf (paramètre global du pi) dans /etc/docker/daemon.json (paramètre de docker, donc des containers) et dans les réglages de AdGuard Home lui même (via l'interface graphique) dans le DNS serveur du NAS : je mets en DNS principal et secondaire par exemple Cloudfare (1.1.1.1 et 1.0.0.1) ou ceux de la FDN (80.67.169.12 et 80.67.169.40). Vous confirmez ?

@.Shad.,je réponds point par point : 1- en effet je mettais mon IP publique pensant que parfois mes requêtes depuis chez moi auraient cette ip (c'est ma méconnaissance des DNS). Donc je devine que cette IP n'a pas besoin d'apparaître où que ce soit dans cette partie Access control, exact ? (je pense que ça vient du fait que je vois souvent dans les tutos en ligne le parefeu du Synology avec une règle allow pour l'adresse IP public, mais c'est peut être aussi une erreur, ou la logique n'est pas la même ?) 2- ok pour l'ordre, je procèderai par network. D'ailleurs je vois souvent les plages d'IP 172.16.0.0/12 et/ou 127.0.0.0/8 (et même 10.0.0.0/8) dans "internal", est-ce nécessaire par exemple pour que les échanges entre les container soient bien traités ? 3- oui j'avais mis une règle d'accès 2FA en interne et externe dans le but de tester. J'enlèverai sans doute le two_factor et mettrai one_factor ou bypass pour l'interne quand tout marchera. Là j'ai suivi les recommandations ici : il s'agit d'un fichier à générer (il n'est pas existant par défaut. Non, il est sur le réseau Bridge d'origine (pas un que j'ai créé) avec l'IP 172.17.0.5. Et il n'est que sur ce réseau (par sur le réseau "swag_default" du stack Swag+Authelia. Voilà le code de adguard.subdomain.conf : ## Version 2021/05/18 # make sure that your dns has a cname set for adguard and that your adguard container is named adguard server { listen 443 ssl; listen [::]:443 ssl; server_name adguard.mondomaine.fr; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for Authelia -> décommenté pour l'authentification via Authelia include /config/nginx/authelia-server.conf; location / { # enable for Authelia -> décommenté pour l'authentification via Authelia include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; #include /config/nginx/internal.conf; # ajouté - exclu l'accès depuis l'extérieur - autorise depuis local set $upstream_app 192.168.1.10; set $upstream_port 3000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location /control { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; #include /config/nginx/internal.conf; # ajouté - exclu l'accès depuis l'extérieur - autorise depuis local set $upstream_app 192.168.1.10; set $upstream_port 3000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Pour le container Adguard, j'ai créé le container via le GUI de Portainer, en précisant des volumes (depuis j'ai appris et je passe par une syntax docker-compose toujours dans le GUI). Donc je te mets paramètres ci-dessous : IMAGE adguard/adguardhome:latest@sha256:50682ca547fb1e5fb5c587bfd67dd053174c8375c40b0c917207aa2ca9cfbef2 PORT CONFIGURATION 0.0.0.0:3000 3000/tcp :::3000 3000/tcp 0.0.0.0:53 53/tcp :::53 53/tcp 0.0.0.0:53 53/udp :::53 53/udp 0.0.0.0:67 67/udp :::67 67/udp 0.0.0.0:853 853/tcp :::853 853/tcp CMD --no-check-update -c /opt/adguardhome/conf/AdGuardHome.yaml -h 0.0.0.0 -w /opt/adguardhome/work ENTRYPOINT /opt/adguardhome/AdGuardHome ENV PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TZ Europe/Paris LABELS maintainer AdGuard Team <devteam@adguard.com> org.opencontainers.image.created 2021-05-19T13:30:19Z org.opencontainers.image.description Network-wide ads & trackers blocking DNS server org.opencontainers.image.licenses GPL-3.0 org.opencontainers.image.revision $( git rev-parse --short HEAD ) org.opencontainers.image.source https://github.com/AdguardTeam/AdGuardHome org.opencontainers.image.title AdGuard Home org.opencontainers.image.url https://adguard.com/adguard-home.html org.opencontainers.image.vendor AdGuard org.opencontainers.image.version v0.106.3 RESTART POLICY unless stopped VOLUMES Host/volume Path in container adguardhome_config /opt/adguardhome/conf adguardhome_data /opt/adguardhome/work Network IP Address Gateway MAC Address Actions bridge 172.17.0.5 172.17.0.1 02:42:ac:11:XX:XX Après concernant les DNS : C'est aussi mon impression, mais je maîtrise peu cette partie. Le fichier /etc/resolv.conf est selon moi celui global du raspberry (c'est le /etc à la racine ; mes autres applis comme swag sont dans /home/pi/nom_du_container/) Je constate d'ailleurs qu'après un "sudo apt update -y && sudo apt full-upgrade -y && sudo reboot", le fichier a été régénéré et qu'il contient maintenant ça : # Generated by resolvconf nameserver 192.168.1.10 nameserver fd0f:ee:b0::1 J'ai aussi regardé /etc/dhcpcd.conf je me souviens y avoir configurer (tout en bas) un fallback vers mon ip static au cas où le serveur DHCP aurait un souci) : # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. # Allow users of this group to interact with dhcpcd via the control socket. #controlgroup wheel # Inform the DHCP server of our hostname for DDNS. hostname # Use the hardware address of the interface for the Client ID. clientid # or # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361. # Some non-RFC compliant DHCP servers do not reply with this set. # In this case, comment out duid and enable clientid above. #duid # Persist interface configuration when dhcpcd exits. persistent # Rapid commit support. # Safe to enable by default because it requires the equivalent option set # on the server to actually work. option rapid_commit # A list of options to request from the DHCP server. option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes # Respect the network MTU. This is applied to DHCP routes. option interface_mtu # Most distributions have NTP support. #option ntp_servers # A ServerID is required by RFC2131. require dhcp_server_identifier # Generate SLAAC address using the Hardware Address of the interface #slaac hwaddr # OR generate Stable Private IPv6 Addresses based from the DUID slaac private # Example static IP configuration: #interface eth0 #static ip_address=192.168.0.10/24 #static ip6_address=fd51:42f8:caae:d92e::ff/64 #static routers=192.168.0.1 #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1 # It is possible to fall back to a static IP if DHCP fails: # define static profile profile static_eth0 static ip_address=192.168.1.10/24 static routers=192.168.1.1 static domain_name_servers=1.1.1.1 1.0.0.1 80.67.169.12 80.67.169.40 # fallback to static profile on eth0 interface eth0 fallback static_eth0 Merci encore pour ton aide, là j'avoue que ça dépasse mes compétences. 😞

Merci @Jeff777 et @oracle7, Je crois que j'ai compris. Je vais tester ça ce week end si je trouve un peu de temps. Merci pour votre aide 😉 PS : @Jeff777 avec ta configuration "recommandée", tu arrives à récupérer les noms de tes clients dans ton Pi-Hole (et en imaginant que la logique soit la même dans mon AdGUard) ? Moi je n'obtiens que des adresses IP, et j'avais cru comprendre que ça ne pouvait pas en être autrement sauf à ce que AdGuard soit aussi le serveur DHCP ? Si ce n'est pas automatique, tu as associé manuellement les IP local à des noms dans Pi-Hole ? (genre tv->192.168.1.53) ... ce qui impliquerait de passer tous les clients en ip fixe (via des baux DHCP fixes sur la freebox, laborieux mais faisable au moins pour tous les appareils permanents, pas contre impossible pour les appareils de passage de la famille et des amis...)

Merci @oracle7, et selon toi, c'est donc l'IP du NAS que je mets dans ma Freebox comme DNS principal ? Et l'IP du raspberry peut aller en DNS secondaire ? (ou ça risque de créer une boucle et la création d'un trou noir ?) Donc le circuit d'une requête serait : client -> DCHP -> DNS (principal) sur le NAS -> AdGuard sur le raspberry Pi (aussi DNS secondaire) -> DNS externes de FDN J'imagine que dans ce cas, il ne faut pas préciser les DNS de la FDN en secondaire dans le DNS serveur du NAS, au risque de court-circuiter AdGuard parfois, exact ?

Hello @.Shad., suite à ta remarque sur un autre fil (Authelia) au sujet des possibles problèmes de DNS que j'ai, j'ai jeté un oeil à ce tuto pour mieux comprendre les DNS. Avant d'éventuellement tenter de déployer DNS server, il y a un truc qui m'échappe. Comment intégrer dans cette "configuration DNS" un bloqueur comme Pi-Hole ou AdGuard Home qui tourne sur un raspberry pi différent du NAS ? J'essaye de comprendre, mais sans y parvenir... Voici ma configuration : mon routeur, une freebox pop avec : IP extérieure fixe, et un domaine perso chez OVH qui pointe dessus IP locale : 192.168.1.1 ports 80 et 443 ouverts et redirigés vers le reverse proxy serveur DHCP, avec comme DNS l'ip locale du Raspberry Pi hébergeant AdGuard un Raspberry Pi : IP locale : 192.168.1.10 SWAG comme reverse proxy AdGuard comme serveur de DNS bloquand les pub les DNS d'AdGuard sont ceux de la FDN un NAS : IP locale : 192.168.1.20 des services comme Drive de Synology accessible sur drive.mondomaine.fr ...et pas encore de serveur DNS (mais si je suis ici, j'y pense 😉 Donc si je suis le tuto et mets en place le cache et la zone locale via DNS server sur le NAS, où et comment intégrer le raspberry pi avec Adguard dans la chaîne ? Merci d'avance pour vos conseils et explications qui me permettront d'y voir clair.

Une autre idée qui me traverse l'esprit (parce que j'ai souvenir qu'on dit souvent "c'est toujours un problème de DNS"), j'ai jeter un oeil au fichier resolver.conf de Nginx Swag : # This file is auto-generated only on first start, based on the container's /etc/resolv.conf file. Feel free to modify it as you wish. resolver 192.168.1.10 valid=30s; Comme je fais tourner Adguard Home sur le même host (le raspberry), et que c'est lui qui sert de DNS à tout mon réseau local, j'avais donc cette valeur avec l'IP locale du raspberry comme DNS. J'ai testé en mettant : resolver 1.1.1.1 valid=30s; mais pas de changement (à part qu'il faut juste 1sec pour afficher l'erreur 500 là où avec l'IP du raspberry il fallait 6sec). J'ai donc aussi regardé le fichier /etc/resolv.conf (si je comprends bien c'est le réglages DNS plus global au raspberry et pas juste au container Nginx Swag), et j'ai ça : # Generated by resolvconf nameserver 1.1.1.1 nameserver 80.67.169.12 nameserver 80.67.169.40 nameserver fd0f:ee:b0::1 ... en effet, j'ai souvenir d'avoir eu des souci par le passé pour mettre en place Nginx Proxy Manager puis SWAG, et que je les avais résolus en mettant des DNS "sérieux" et pas ma propre IP d'Adguard. Un avis ? Merci.

Arghhh, ça me rend fou ! Impossible de faire fonctionner normalement Authelia. Si je configure comme actives les 2 lignes d'Authelia dans mes fichiers .conf de Nginx Swag (par exemple "adguard.subdomain.conf") : server { ... # enable for Authelia include /config/nginx/authelia-server.conf; ... location / { # enable for Authelia include /config/nginx/authelia-location.conf; ... alors j'obtiens une erreur 500 si je tente d'accéder à la page adguard.mondomaine.fr En revanche si je les désactive, ma redirection fonctionne à nouveau et j'accède bien à mon service. Si je tape 192.168.1.10:9091, j'affiche bien la page de login d'Authelia. J'ai même testé avec un utilisateur valide sur le LDAP, et je vois dans les log du container que l'utilisateur est bien reconnu. Je ne vois aucun autre message d'erreur (je suis en mode debug). time="2021-09-30T22:56:48+02:00" level=info msg="Authelia v4.31.0 is starting", time="2021-09-30T22:56:48+02:00" level=info msg="Log severity set to debug", time="2021-09-30T22:56:48+02:00" level=debug msg="Storage schema is being checked to verify it is up to date", time="2021-09-30T22:56:48+02:00" level=debug msg="Storage schema is up to date", time="2021-09-30T22:56:48+02:00" level=debug msg="Notifier SMTP client attempting connection to smtp.XXXX.XXXX.com:587", time="2021-09-30T22:56:48+02:00" level=debug msg="Notifier SMTP client connected successfully", time="2021-09-30T22:56:48+02:00" level=debug msg="Notifier SMTP server supports STARTTLS (disableVerifyCert: false, ServerName: smtp.XXXX.XXXX.com), attempting", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP STARTTLS completed without error", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP server supports authentication with the following mechanisms: LOGIN PLAIN ATOKEN", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP client authenticated successfully with the server", time="2021-09-30T22:56:50+02:00" level=info msg="Listening for non-TLS connections on '0.0.0.0:9091' paths '/' and '/authelia'", time="2021-09-30T22:56:49+02:00" level=debug msg="Notifier SMTP client attempting AUTH PLAIN with server" Je pense que je dois merder dans la partie "access control" du "configuration.yml" d'Authelia. J'ai pourtant passé du temps pour le comprendre, et simplifier les paramètres pour mes essais. Mais rien n'y fait. Si vous avez un avis, je suis preneur... access_control: default_policy: deny networks: - name: internal networks: - 192.168.1.0/24 - X.X.X.X # mon ip publique ici cachée évidement ;-) rules: - domain: - nas.mondomaine.fr - www.mondomaine.fr - mondomaine.fr policy: bypass - domain: - snapdrop.mondomaine.fr - imprimante.mondomaine.fr policy: bypass networks: - internal - domain: - accueil.mondomaine.fr - rss.mondomaine.fr - media.mondomaine.fr - drive.mondomaine.fr policy: one_factor networks: - internal - domain: - adguard.mondomaine.fr policy: two_factor Au passage, avant de me lancer dans l'installation d'Authelia, j'avais configurer le fichier internal.conf de Nginx Swag. J'ai repassé ce fichier en internal.conf.sample et j'ai décommenté les lignes y faisant références dans mes fichiers de configs. Est-ce qu'on peut imaginer qu'il intérfère quand même encore quelque part ? (je ne pense pas car j'ai testé depuis mon réseau local et depuis mon smartphone en 4G et j'ai les mêmes erreurs 500). Merci d'avance pour vos réflexions 😞

Bonjour @oracle7, et de rien, j'ai profité de tellement de forum pour commencer à comprendre un peu Docker, alors si ça peut aider en retour (et surtout ne pas induire en erreur avec de mauvais conseils 😉 Concernant la version de MariaDB, je pense que c'est en effet une v10, car le container m'affiche ça : build_version Linuxserver.io version:- 10.5.12-r0-ls37 Build-date:- 2021-09-25T07:47:56+02:00 Maintenant concernant sa configuration, j'ai suivi simplement les indications de Linux Server io, et ils mentionnent bien le port 3306. Mais je suis preneur d'info pour corriger ça si besoin. Car c'est possible que la connexion se fasse via le port 3307 même si je ne l'expose pas "officiellement" dans mes variables docker-compose, car si j'ai bien compris, en appartenant tous au même "user_network", tous les ports sont ouverts entre ces containers, exact ? D'où ta remarque @.Shad.de dire que je pourrai uniquement spécifier les ports dans le service SWAG et supprimer cette indication pour les autres services. Concernant ce point (merci pour l'explication !), qu'entends-tu exactement par "réseau défini de façon externe" ? Cest par exemple le cas de mon "user_network" appelé "swag_default" que j'avais créé avant le stack via l'interface de Portainer ? Je pourrai donc mettre ça dans mon cas : service: exemple: name: ... [...] networks: - swag_default [...] networks: swag_default: external: true Merci de ta confirmation 😉 Sinon pour finir sur Redis, j'ai compris de mon côté (mais sans avoir creusé très longtemps) que c'est un outil de mise en cache de certaines infos. Là encore, il est recommandé sur la doc d'Authelia, et il fait aussi parti des template de Portainer, donc facile à déployer dans un stack ou dans un container unique.

Bonsoir .Shad. et merci pour tes réflexions. Je commence par tenir ma parole, et poster la syntaxe que j'ai utilisée pour déployer ce stack via Portainer sur le Raspberry Pi. Si ça peut aider quelqu'un... version: "2.1" services: swag: image: linuxserver/swag:latest container_name: swag cap_add: - NET_ADMIN environment: - PUID=1000 - PGID=1000 - TZ=Europe/Paris - URL=swagme.fr #ce n'est evidement pas le vrai domaine :-) - SUBDOMAINS=wildcard - VALIDATION=dns - DNSPLUGIN=ovh - CERTPROVIDER=letsencrypt - EMAIL=swagme@me.com - EXTRA_DOMAINS=dev.swagme2.fr,prod.swagme2.fr - MAXMINDDB_LICENSE_KEY=MJ************* volumes: - /home/pi/swag/config:/config ports: - 443:443 - 80:80 #optional restart: unless-stopped depends_on: - authelia - authelia_mariadb - redis authelia: image: authelia/authelia container_name: authelia environment: - PUID=1000 - PGID=1000 - TZ=Europe/Paris volumes: - /home/pi/authelia/config:/config ports: - 9091:9091 restart: unless-stopped #healthcheck: #ne semble pas supporté par portainer et sa version 2.X de docker-compose # disable: true depends_on: - authelia_mariadb - redis redis: image: redis:latest #un autre exemple s'appuye sur redis:alpine container_name: redis environment: - PUID=1000 - PGID=1000 - TZ=Europe/Paris command: redis-server /usr/local/etc/redis/redis.conf volumes: - /home/pi/redis/data/redis.conf:/usr/local/etc/redis/redis.conf - /home/pi/redis/data:/data #ports: # - 6379:6379 expose: - 6379 restart: unless-stopped authelia_mariadb: image: linuxserver/mariadb container_name: authelia_mariadb environment: - PUID=1000 - PGID=1000 - MYSQL_ROOT_PASSWORD=f2b********* - TZ=Europe/Paris - MYSQL_DATABASE=authelia - MYSQL_USER=authelia-******* - MYSQL_PASSWORD=vB7Xa************ volumes: - /home/pi/authelia_mariadb/config:/config ports: - 3306:3306 restart: unless-stopped De mon côté, je suis preneur de la manière de préciser le réseau (soit d'en créer un, soit de connecter les nouveaux containers créés à un réseau pré-existant). Concernant tes réflexions, je vais m'y pencher après ce week end (là je manque de temps). Merci en tout cas.

Bonjour @Novice34, Si le reverse proxy ne fonctionne pas, tu pointes donc ton IP public (par exemple 86.22.3.12) et tu as mis une redirection du port 636 TCP de ta box vers le NAS en local (ex. 192.168.1.20), c'est bien ça ? J'ai fait la même chose, mais comme c'est en TLS, le client (en l’occurrence chez moi un container Authelia) qui veut se connecter au serveur LDAP dit que le certificat n'est pas valable (celui de *.mondomaine.fr ne correspondant évidement pas à l'IP local du NAS qui me sert à pointer le serveur LDAP). Comment as-tu contourner ce problème ? EDIT : j'ai pu contourner ça en utilisant le certificat mondomaine.synology.me. Je l'ai associé au service LDAP, et ensuite je pointe mon LDAP avec ldaps://mondomaine.synology.me Par contre, je ne sais pas si ça peut poser un problème de sécurité, par exemple en exposant le LDAP à l'extérieur de mon réseau local ? Sinon je confirme que je ne trouve pas non plus de moyen d'importer les utilisateurs locaux en les convertissant en utilisateur LDAP ; c'est dommage, ce serait très utile !

Merci .Shad pour ce tuto. Je suis étonné aussi du peu de commentaire 😉 Je me suis lancé dans cette démarche, mais je rencontre des difficultés avec le serveur LDAP sur le NAS (LDAP Server sous DMS7). (je me suis permis de le mettre ici, mais ça pourrait sans doute aussi aller sous le tuto sur le LDAP). Ma configuration est un peu différente : j'ai un NAS (192.168.1.20) et un Raspberry pi (192.168.1.10), et c'est sur le Pi que je redirige toutes les requêtes des ports 80 et 443 du routeur. Ce Raspberry héberge le container SWAG (et aussi AdGuard Home pour info) pour gérer toute la partie reverse proxy. Celle-ci fonctionne (j'ai un certificat wildcard pour tout mon domaine chez OVH *.mondomaine.fr), et les redirections fonctionnent pour les autres services dans des containers sur le Pi (adguard.mondomaine.fr) ou sur le NAS (par ex. freshrss.mondomaine.fr) et aussi pour les appli natives du NAS (comme drive.mondomaine.fr). Donc jusque là, tout semble ok. Voulant installer Authelia, j'ai décidé de le déployer plutôt sur le Raspberry. J'ai donc déployé 3 autres containers MariaDB, Redis et Authelia (via Portainer, car je maitrise mal les commandes SSH) et les ai tous attaché à un "user_network" bridge appelé "swag_default". (PS : au passage, j'ai fait ce déploiement via un docker-compose mais rédigé dans l'interface de Portainer, et pas moyen de faire se créer ce network, ou si je le crée avant, d'y attacher les containers à leur création. J'ai regardé sur la doc officiel de Docker compose, mais la syntaxe semble être pour les version 3 et suivantes, quand portainer-ce ne gère que la syntaxe v2. Si quelqu'un sait comment le rédiger, je veux bien apprendre). Les 4 containers (SWAG, MariaDB, Redis et Authelia) communiquent entre eux (via le nom des container plutôt que les ip, puisqu'ils sont dans le même user_network). Ensuite j'ai installé le serveur LDAP sur le NAS via le package officiel LDAP Server. J'ai donné en nom FQDN "ldap.mondomaine.fr" (est-ce un problème ? je vois dans l'autre tuto sur LDAP un nom du genre ldap.local) J'ai finalement créé sur SWAG un fichier de config redirigeant "ldap.mondomaine.fr" vers l'IP du NAS et le port 636 supportant le TLS (supposant que j'allais obtenir ainsi un certificat valide). EDIT : après lecture de différent article, il semble préférable de nommer son serveur truc.home En effet cela fonctionne sous cette forme dans mon cas. J'ai ouvert sur le parefeu du NAS le port 636. (je n'ai pas testé le port 389 non sécurisé). J'ai finalement configuré les infos du serveur LDAP du NAS dans le fichier de configuration d'Authelia. Et là ça coince. Dans les logs d'Authelia, la connexion au LDAP semble refusée car mon serveur LDAP n'a pas de certificat valable (le message indique que le serveur a un certificat pour truc.synology.me mais pas pour ldap.mondomaine.fr). QUESTION : Faut-il que je copie/colle le certificat wildcard de SWAG du Pi vers le NAS pour que le NAS sache qu'il existe ? (par exemple avec cette méthode, est-ce que je pourrai avoir mes certificats sur le Pi via SWAG, et en même temps sur le NAS ?) Faut-il plutôt utiliser l'IP du NAS comme cible (mais là encore, j'aurai le message d'erreur car je n'aurai pas de certificat valide pour 192.168.1.20) ? EDIT : puisque mes certificats pour mondomaine.fr sont gérés au niveau du Raspberry Pi via SWAG, j'ai configuré dans DSM un certificat moi.synology.me, et tous les services de Synology (dont le LDAP) utilise ce certificat. Dans le fichier de configuration d'Authelia, j'ai donc indiqué ldaps://moi.synology.me comme serveur LDAP, et ça fonctionne (pas de message d'erreur dans les logs). EDIT : Question qui reste valide ? Est-ce que mon serveur LDAP n'est pas ouvert vers l'extérieur via ce réglage ? Je n'ai ni ouvert ni redirigé vers le NAS les ports LDAP 389 et 636, mais j'imagine que de passer par une adresse moi.synology.me rend quand même cela "visible" de l'extérieur ; est-ce un problème de sécurité ? Merci d'avance pour votre aide. PS : 2 questions subsidiaires au passage : 1- est-ce que quelqu'un a testé d'autres système d'authentification sur Synology, comme leur SSO server, ou peut être la nouvelle appli C2 Identity si elle propose cette fonctionnalité ? 2- est-ce qu'il y a une manière de convertir les utilisateurs locaux du NAS en utilisateurs LDAP ? EDIT : ça ne semble pas possible, et iol faut bien veiller à ne pas donner le même nom à un utilisateur local et à un du LDAP

Merci à toutes et tous pour ces réponses. En effet, si je peux aider ce sera avec plaisir, mais j'avoue qu'au vue de mes tâtonnements pour déployer tout ça, je serai bien illégitime à donner des conseils tranchés. Mais évidement, si mes réflexions peuvent aider, je contribuerai avec plaisir. Pour répondre à Andréa, en effet j'ai aussi Portainer sur le NAS (j'ai laissé tombé l'Agent sur le Pi pour centraliser, car il ne permet pas d'éditer les containers "distants") et aussi sur le Pi. J'ai Watchtower pour m'informer des mises à jour disponibles (j'ai préféré ne pas activer la mise à jour automatique des containers). Je regarde Bitwarden du coin de l'oeil (mais j'utilise un autre gestionnaire de mot de passe pour lequel j'ai mis un moment à "éduquer" mon entourage, je préfère pour l'instant m'en tenir à ça). Concernant Drive, je suis d'accord, ma position n'est pas encore très clair : à la fois j'aimerai vraiment être indépendant, mais en même temps je m'appuie encore pour l'instant sur un NAS Synology (et pas un NAS monté de toute pièce, ce qui sera peut être l'étape suivante). Et Drive fonctionne bien, à la fois avec les applis mobile et la synchro "à la dropbox" sur nos ordis. Et je trouve que l'interface n'est pas trop compliqué. Alors que dans mes expériences passées (de OwnCloud, mais Nextcloud est proche si je ne me trompe pas), c'est un peu une usine à gaz, et j'avais eu des souci pour le paramétrer et le maintenir. Donc je suis hésitant (globalement) pour trouver le bon équilibre entre dégooglisation / personnalisation / simplicité. Un exemple de ça est mon cheminement vers le reverse proxy : celui du NAS était trop limité (et buggué pour ma part sous DSM6, avec des comportements que je ne m'expliquais pas). Nginx Proxy Manager sur le Pi est beaucoup mieux selon moi avec par exemple les certificats SSL wildcard pour l'ensemble de mon domaine (j'attends la prochaine version avec impatience). Et finalement j'ai découvert SWAG de Linux Server, qui ajoute en plus des briques de sécurité (GeoIP2, FailBan, etc. mais en perdant par contre l'ergonomie via une interface utilisateur inexistante). En l'état, j'ai choisi SWAG (que je peine à configurer justement, cf. mon prochain poste 😉 l'état). Un autre exemple (qui selon moi mériterait une exploration par les experts de ce forum) : l'authentification centralisée : Nginx PM ou SWAG propose une version simple via liste d'utilisateur ; Authelia pousse ça encore plus loin avec un serveur LDAP sur le NAS ; mais il y a aussi la nouvelle appli C2 Identity depuis DSM 7, ou encore SSO server de Synology. Quelle est la meilleure solution (pour gérer les accès par exemple à mon combo "services sous docker" et "app synology natives" ? Voilà, je suis donc encore dans l'expectative... 😉 mais en s'aidant on trouvera dans l'intérêt de tous.

Bonjour, Lecteur depuis 1 an environ, je viens de rejoindre votre communauté. A 40 ans, il était temps me direz-vous ! Utilisateur de l'outil informatique depuis mon plus jeune âge (merci papa), je travaille dans la création graphique et audiovisuelle. Avec une conscience politique grandissante, et des enfants suivant la même trajectoire, je cherche à me degoogleiser (pas facile à écrire) le plus possible, et montrer le chemin à mon entourage. Je possède depuis 10 ans un NAS Synology (pas le même évidement), et depuis un peu plus d'1 an, je m'essaye à l'auto-hébergement de mes services, avec une relative réussite (j'arrive en général à mes fins, même si parfois le cheminement est long et que je tape encore régulièrement dans google "tuto commande SSH"). Je ne me considère donc pas comme un expert, mais un utilisateur aguerri, qui apprend. Pour détailler mes équipements (repris en signature) : - 1 Synology DS918+ (Drive en natif, et des services sous docker : Plex, Snapdrop, Searx, Homer/DashMachine, FreshRSS, Ghost, etc.) derrière un onduleur ; - 1 Raspberry Pi 4B (serveur DNS sous AdGuard Home, et Reverse proxy avec Nginx Proxy Manager mais je teste Sawg en ce moment pour ses fonctions avancées et l'authentification avec Authelia) ; - Des clients sous MacOS et iOS ; - ...le tout derrière une Freebox Pop et une connexion fibre en IP fixe. Voilà, j'espère que cela vous aidera à vous faire une idée de mon profil, et vous encouragera à m'aider à l'avenir 😉 Merci d'avance, et à très vite sur le forum. SwagMe