MilesTEG1 Posté(e) le 8 juin Partager Posté(e) le 8 juin Salutation à tous, Pour ceux qui utilises le MOD Maxmind, il faut maintenant ajouter une variable d'environnement MAXMINDDB_USER_ID en plus de la licence MAXMINDDB_LICENSE_KEY. MAXMINDDB_LICENSE_KEY=<license-key> with your license key MAXMINDDB_USER_ID=<user-id> with your user id J'avais vu passer cette info il y a quelques mois dans les logs de SWAG, mais maintenant (enfin je ne sais pas vraiment si c'est très récent ou pas) il la faut. PS : quelqu'un utilise-t 'il ce mod ? https://github.com/linuxserver/docker-mods/tree/swag-auto-uptime-kuma Bonne journée à tous 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 10 juin Auteur Partager Posté(e) le 10 juin Merci bien ! Je suis en train de refaire un tuto pour swag, même si j'avance pas depuis un mois, ça devrait aller mieux dans les jours qui viennent.😅 @MilesTEG1 J'ai essayé d'utiliser uptime-kuma un temps, mais ça faisait redondance avec d'autres systèmes de supervision déjà en place de mon côté.. Ce que j'utilise par contre ce sont les modes auto-proxy et auto-reload, ça marche très bien je trouve. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
MilesTEG1 Posté(e) le 10 juin Partager Posté(e) le 10 juin Il y a 2 heures, .Shad. a dit : Ce que j'utilise par contre ce sont les modes auto-proxy et auto-reload, ça marche très bien je trouve. Salut @.Shad. J'utilise aussi autp-reload. Mais pas auto-proxy, je trouve préférable de faire moi-même mes fichiers de configuration 🙂 Merci pour ton retour ^^ PS : je n'utilise plus le Syno pour héberger SWAG @ Docker, mais un mini PC 😉 bien plus fiable, plus pratique, pas besoin de macvlan, et j'ai du vrai 2,5GbE natif ^^ 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 10 juin Auteur Partager Posté(e) le 10 juin (modifié) @MilesTEG1 Pour l'auto-proxy, je pensais pareil que toi mais depuis que j'y ai goûté je trouve ça génial. 😉 Modifié le 10 juin par .Shad. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
MilesTEG1 Posté(e) le 10 juin Partager Posté(e) le 10 juin Il y a 2 heures, .Shad. a dit : @MilesTEG1 Pour l'auto-proxy, je pensais pareil que toi mais depuis que j'y ai goûté je trouve ça génial. 😉 Du coup j’ai pas dû saisir ce que ça faisait 🤪 qu’est-ce qui te fait le préférer à faire tes .conf ? et comment ça marche ? j’ai externalisé plein de service en dehors de la machine où est hébergé swag. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
L. Tech Posté(e) le 22 juillet Partager Posté(e) le 22 juillet (modifié) Bonjour, J'ai un problème dont je ne trouve absolument pas la cause avec une redirection vers un site WordPress derrière le reverse proxy swag En me connectant sur : https://site.ndd.fr Aucun soucis , en me connectant en http://site.ndd.fr Aucun soucis Mais dès que j'essaye de me connecter sur la partie admin L'url de mon site se transforme comme ceci : https://site.ndd.fr:3030/wp-admin/ Si je modifie mon URL en https://site.ndd.fr/wp-admin la ça fonctionne. C'est la redirection http vers https qui ne se fait pas correctement mais uniquement pour la partie wp-admin Sur mon DSM le port HTTP est le 3030, le port HTTPS est le 3545 , je n'ai pas activé HSTS Mon fichier conf sur le reverse proxy SWAG est comme ceci : server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name site.ndd.fr; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; set $upstream_app 192.168.1.200; set $upstream_port 3030; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Je n'arrive pas du tout à trouver ce qui cloche ? Edit 26/07/2024 j'ai finalement trouvé d'ou venez le problème il faut savoir que le fonctionnement de Wordpress est un peu particulier : Dans mon cas , j'avais personnaliser la configuration des ports dans mon site Wordpress et c'est pour cela que ça ne fonctionner pas correctement derrière le reverse proxy. Il y a 3 solutions pour corriger le problème soit on peut se connecter à l'interface d'administation de Wordpress et dans ce cas il faut corriger l'adresse du site comme la capture d'écran ci dessous Ou si on y a plus accès à cause de la redirection du reverse proxy qui nous bloque il faut editer le fichier wp-config.php qui est situé à la racine du site et ajouter ces 2 directives : define('WP_HOME', 'https://site.ndd.fr'); define('WP_SITEURL', 'https://site.ndd.fr'); 3 ème solution si on accès à la base de données via par exemple phpmyadmin il faut modifier dans la table options les variables : siteurl et home Modifié le 26 juillet par L. Tech Résolution de l'erreur 1 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 1 août Auteur Partager Posté(e) le 1 août @L. Tech Salut et désolé j'avais oublié de te répondre. Bien joué ! Effectivement sur certaines applications il est important que la base_url soit correctement renseignée. 1 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
L. Tech Posté(e) le 16 septembre Partager Posté(e) le 16 septembre Bonjour, je rencontre un problème avec le fail2ban intégré à SWAG , j'ai une erreur dans les logs de fail2ban il n'arrive pas à bannir les IP sur le synology ? est ce que quelqu'un à déjà rencontrer l'erreur ? J'utilise un docker Jellyfin avec une IP MCVLAN , j'ai correctement renseigner l'adresse du Proxy inversé swag dans la config de Jellyfin fail2ban.utils [938]: ERROR 7f6829904db0 -- exec: { iptables -w -C f2b-jellyfin -j RETURN >/dev/null 2>&1; } || { iptables -w -N f2b-jellyfin || true; iptables -w -A f2b-jellyfin -j RETURN; } for proto in $(echo 'tcp' | sed 's/,/ /g'); do Quand je lance docker exec -it swag fail2ban-client status jellyfin je vois bien l'adresse IP Banni mais rien ne m'empêche d'accéder au docker du NAS malgré tout. Après pas mal de recherche j'ai lu qu'il fallais créer un fichier iptables.local dans le dossier fail2ban\action.d avec ce contenu : [Init] blocktype = DROP [Init?family=inet6] blocktype = DROP Mais ce n'est pas pour autant que cela fonctionne, je séche un peu la ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
L. Tech Posté(e) le 20 septembre Partager Posté(e) le 20 septembre Bonjour, J'ai une petite question sur le fonctionnement du reverse proxy , j'ai installé swag et j'ai un container jellyfin qui tourne dessus, je rencontre un léger soucis pour les logs au niveau de la remontée des adresses ip distante. Quand c'est une IP distante hors de mon réseau celle ci remonte bien dans les log , idem pour les ip local. Mais en me connectant en OpenVPN via la connexion Native du NAS, l'adresse IP qui remonte est l'adresse IP de l'interface bridge qui fait le lien entre le drivers macvlan et le NAS. Est ce qu'il y a une solution pour remonter l'adresse IP du VPN distant ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 21 septembre Auteur Partager Posté(e) le 21 septembre @L. Tech est-ce que tu as bien ajouté l'IP de swag en tant que proxy fiable dans DSM ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
L. Tech Posté(e) le 21 septembre Partager Posté(e) le 21 septembre Il y a 4 heures, .Shad. a dit : @L. Tech est-ce que tu as bien ajouté l'IP de swag en tant que proxy fiable dans DSM ? Oui j'ai bien mis l'adresse , j'ai aussi essayé de mettre l'adresse qui fait le lien bridge => MacVLAN mais ça ne change rien au problème 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CHILLY996 Posté(e) le 2 octobre Partager Posté(e) le 2 octobre Bonsoir, J'ai un nas synology en 192.168.XXX.31 avec SWAG, authelia et différents conteneurs docker. SWAG, Authelia et Adguard sont en mac-vlan je précise. Pour accéder aux conteneurs de ce nas tout se passe bien en interne comme en externe. Sur mon réseau, j'ai un autre nas en 192.168.xxx.30 avec un packet synology rutorrent car il n'accepte pas docker. Je souhaite accéder à cette instance en reverse proxy mais il me manque beaucoup d'informations sur la page web mais en étant sur mon réseau LAN. En standard, il faut entrer l'adresse http://192.168.XXX.30/rutorrent/. En interne celà fonctionne parfaitement Ma config dans swag est la suivante avec un fichier ds415rutorrent.subdomain.conf: ## Version 2021/05/18 # make sure that your dns has a cname set for rutorrent server { listen 443 ssl; listen [::]:443 ssl; server_name ds415rutorrent.*; include /config/nginx/ssl.conf; client_max_body_size 0; #GEOIP2 test if ($lan-ip = yes) { set $geo-whitelist yes; } if ($geo-whitelist = no) { return 404; } # 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; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/passwd/rutorrent_passwd; # 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.XXX.30; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app/rutorrent/; } location /RPC2 { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/passwd/rutorrent_passwd; # 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; # block rpc access by default because it is unprotected # you can comment out the next line to enable remote rpc calls deny all; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.XXX.30; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app/rutorrent/; } } Je ne sais pas comment retranscrire mon adresse ds415rutorrent.ZZZ.ZZZ en 192.168.XXX.30/rutorrent. En fait je n'ai pas de port. Merci pour vos conseils. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 13 octobre Auteur Partager Posté(e) le 13 octobre @CHILLY996 Quand tu ne vois pas un port visible en HTTP, c'est le port 80 (voir ton fichier de config ci-dessus), quand tu ne vois pas de port en HTTPS, c'est 443. Quel message d'erreur obtiens-tu sur ta page d'accueil ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bidh Posté(e) le 14 octobre Partager Posté(e) le 14 octobre (modifié) Bonjour, je me permet de signaler qu'il est possible d'utiliser SWAG+Authelia (comme décrit dans le tuto) et le reverse proxy de DSM, l'un derrière l'autre. Pour pallier une limitation de DuckDNS signalée ICI. Et puis pourquoi pas ? Révélation duckdns validation has one big limitation. Duckdns service only lets you set one dns txt record for the account. Therefore, you can only validate one address with letsencrypt. When you set subdomains to wildcard, that address is *.customsubdomain.duckdns.org. Everything else in extra domains is ignored. If you want multiple addresses covered with duckdns, you’ll have to use http validation, which allows multiple addresses, but no wildcard. Ce qui me permet d'utiliser le reverse proxy de DSM sur mon LAN et SWAG+Authelia en dehors. Sans avoir des erreurs de certificats avec les applications sur Pc ou smartphone. J'utilisais, au début, le reverse proxy de synology limité à mon seul LAN avec le profil de contrôle d'accès (en plus du pare feu). Mais après avoir installé SWAG, avec DuckDNS, mon routeur pointe maintenant sur l'IP (réelle, pour utilisation avec réseau macvlan) du conteneur SWAG. Et non plus sur l'IP de mon NAS, donc le reverse proxy DSM n'est plus utilisé. Mais pour plusieurs raisons, je voulais utiliser le reverse proxy DSM sur mon LAN. Malheuresement DuckDNS n'accepte pas la variable EXTRA_DOMAINS environment: - EXTRA_DOMAINS=NOM_DU_NAS.synology.me, *.NOM_DU_NAS.synology.me J'ai donc dû régler le souci différemment. Modifié le 14 octobre par bidh 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 15 octobre Auteur Partager Posté(e) le 15 octobre @bidh : Je n'ai pas bien compris ta question ni ton besoin. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bidh Posté(e) le 15 octobre Partager Posté(e) le 15 octobre (modifié) @.Shad. Juste qu'il est possible d'utiliser SWAG+Authelia avec les certificats et le nom de domaine issus du reverse proxy de DSM. Créer un fichier pour que SWAG redirige de NOM_DU_NAS.synology.me vers le port 443 de l'IP virtuelle de l'hôte (ici 192.168.1.200). Il faut créer dans le répertoire /docker/swag/config/nginx/proxy-confs un fichier synology.subdomain.conf, une entrée préconfigurée à peine modifiée par ces deux lignes server_name *.NOM_DU_NAS.synology.me NOM_DU_NAS.synology.me; include /config/nginx/ssl_syno.conf; Révélation ## Version 2024/04/09 # redirect *.NOM_DU_NAS.synology.me server { listen 443 ssl; listen [::]:443 ssl; server_name *.NOM_DU_NAS.synology.me NOM_DU_NAS.synology.me; include /config/nginx/ssl_syno.conf; client_max_body_size 0; if ($lan-ip = yes) { set $geo-whitelist yes; } if ($geo-whitelist = no) { return 404; } # 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.1.200; set $upstream_port 443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; # Clear Authorization Header if you are using http auth and normal homepage auth #proxy_set_header Authorization ""; } location ~ (/boitedejr.synology.me)?/api { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.1.200; set $upstream_port 443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } nginx va importer tous les paramètres définis dans un nouveau fichier, ssl_syno.conf, qui contient les nouveaux paramètres propres aux certificats de DSM. Créer dans le répertoire /docker/swag/config/nginx un fichier ssl_syno.conf identique au fichier ssl.conf sauf pour 2 lignes ssl_certificate /config/keys/ECC-fullchain.crt; ssl_certificate_key /config/keys/ECC-cert.key; Révélation ## Version 2023/08/13 - Changelog: https://github.com/linuxserver/docker-baseimage-alpine-nginx/commits/master/root/defaults/nginx/ssl.conf.sample ### Mozilla Recommendations # generated 2023-06-25, Mozilla Guideline v5.7, nginx 1.24.0, OpenSSL 3.1.1, intermediate configuration # https://ssl-config.mozilla.org/#server=nginx&version=1.24.0&config=intermediate&openssl=3.1.1&guideline=5.7 ssl_certificate /config/keys/ECC-fullchain.crt; ssl_certificate_key /config/keys/ECC-cert.key; ssl_session_timeout 1d; ssl_session_cache shared:MozSSL:10m; # about 40000 sessions ssl_session_tickets off; # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam ssl_dhparam /config/nginx/dhparams.pem; # intermediate configuration ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off; # HSTS (ngx_http_headers_module is required) (63072000 seconds) add_header Strict-Transport-Security "max-age=63072000" always; # OCSP stapling ssl_stapling on; ssl_stapling_verify on; # verify chain of trust of OCSP response using Root CA and Intermediate certs ssl_trusted_certificate /config/keys/cert.crt; # Optional additional headers #add_header Cache-Control "no-transform" always; #add_header Content-Security-Policy "upgrade-insecure-requests; frame-ancestors 'self'" always; #add_header Permissions-Policy "interest-cohort=()" always; add_header Referrer-Policy "same-origin" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; #add_header X-UA-Compatible "IE=Edge" always; add_header X-XSS-Protection "1; mode=block" always; add_header X-Robots-Tag "noindex, nofollow, nosnippet, noarchive"; qui pointent vers les certificats de DSM que l'on copiera Créer dans le répertoire /docker/swag un fichier syno_cert_install.sh sudo install -C -m 744 -o NOM_UTILISATEUR -g users /usr/syno/etc/certificate/system/default/ECC-fullchain.pem /volume1/docker/swag/config/keys/ECC-fullchain.crt sudo install -C -m 744 -o NOM_UTILISATEUR -g users /usr/syno/etc/certificate/system/default/ECC-privkey.pem /volume1/docker/swag/config/keys/ECC-cert.key qui copie les certificats DSM vers le répertoire de SWAG avec le bon utilisateur et les bons droits Ne reste plus qu'à créer une tache planifiée qui lancera syno_cert_install.sh régulièrement tous les mois. Et si vous voulez que SWAG soit relancé dès que ces deux fichiers sont modifiés, pensez à utiliser le mod auto-reload. https://github.com/linuxserver/docker-mods/tree/swag-auto-reload Et ajouter cette ligne dans votre docker compose - WATCHLIST="/config/keys/ECC-cert.key|/config/keys/ECC-fullchain.crt" Modifié le 17 octobre par bidh 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CHILLY996 Posté(e) le 16 octobre Partager Posté(e) le 16 octobre @.Shad.J'obtiens la page d'accueil de SWAG par défaut en https. Welcome to your SWAG instance A webserver and reverse proxy solution brought to you by linuxserver.io with php support and a built-in Certbot client. We have an article on how to use swag here: docs.linuxserver.io For help and support, please visit: linuxserver.io/support 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
MilesTEG1 Posté(e) le 17 octobre Partager Posté(e) le 17 octobre Salut par ici 🙂 Quelqu'un aurait-il réussi à personnaliser les pages d'erreurs ? comme la 404, 403 etc... J'ai essayé divers trucs trouvés sur le net, comme j'ajout d'include dans divers .conf dont le default.conf, mais rien ne semble fonctionner XD 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jeff777 Posté(e) le 17 octobre Partager Posté(e) le 17 octobre Bonjour @MilesTEG1 Je n'ai jamais essayé ce qui suit. Est-ce que cela répond à ta question ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
MilesTEG1 Posté(e) le 17 octobre Partager Posté(e) le 17 octobre il y a une heure, Jeff777 a dit : Bonjour @MilesTEG1 Je n'ai jamais essayé ce qui suit. Est-ce que cela répond à ta question ? Je parlais bien évidemment de SWAG 😉 Pas du reverse proxy de DSM 😅 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bidh Posté(e) le 17 octobre Partager Posté(e) le 17 octobre (modifié) Le 02/10/2024 à 8:20 PM, CHILLY996 a dit : Bonsoir, J'ai un nas synology en 192.168.XXX.31 avec SWAG, authelia et différents conteneurs docker. SWAG, Authelia et Adguard sont en mac-vlan je précise. Pour accéder aux conteneurs de ce nas tout se passe bien en interne comme en externe. Sur mon réseau, j'ai un autre nas en 192.168.xxx.30 avec un packet synology rutorrent car il n'accepte pas docker. Je souhaite accéder à cette instance en reverse proxy mais il me manque beaucoup d'informations sur la page web mais en étant sur mon réseau LAN. En standard, il faut entrer l'adresse http://192.168.XXX.30/rutorrent/. En interne cela fonctionne parfaitement Ma config dans swag est la suivante avec un fichier ds415rutorrent.subdomain.conf: Je ne sais pas comment retranscrire mon adresse ds415rutorrent.ZZZ.ZZZ en 192.168.XXX.30/rutorrent. En fait je n'ai pas de port. Merci pour vos conseils. Bonjour @CHILLY996 , ton ds415rutorrent.subdomain.conf date du ## Version 2021/05/18, est ce que ton container SWAG est à jour ? Ensuite dans ton fichier .conf, est ce que tu as modifié la ligne ? proxy_pass $upstream_proto://$upstream_app/rutorrent/; Parce que dans mon fichier rutorrent.subdomain.conf.sample, la ligne ressemble à cela proxy_pass $upstream_proto://$upstream_app:$upstream_port; Révélation ## Version 2024/07/16 # make sure that your rutorrent container is named rutorrent # make sure that your dns has a cname set for rutorrent server { listen 443 ssl; listen [::]:443 ssl; server_name ds415rutorrent.*; 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.XXX.30; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location /RPC2 { # 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; # block rpc access by default because it is unprotected # you can comment out the next line to enable remote rpc calls deny all; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 192.168.XXX.30; set $upstream_port 80; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } Au pire, Download Station fonctionne bien avec les fichiers torrents et SWAG. Modifié le 17 octobre par bidh 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 17 octobre Auteur Partager Posté(e) le 17 octobre @bidh @CHILLY996 Effectivement, bien vu, il y a un problème, tu n'es pas sensé voir de subfolder apparaître : https://github.com/linuxserver/reverse-proxy-confs/blob/master/rutorrent.subdomain.conf.sample @bidh je comprends l'idée developpée ici, c'est intéressant, même si dans ce cas-là je préfère encore éventuellement faire tourner acme.sh pour obtenir mon certificat + déployer dans DSM, et utiliser un volume docker nommé partagé pour récupérer les certificats à utiliser dans Nginx Proxy Manager (NPM) + Authelia. On s'affranchit de l'utilisation d'un script qui tourne en superuser, et on n'a pas de recouvrement de fonction (SWAG se caractérise par son côté tout en un, si on ne se sert pas de leur certbot c'est un peu dommage je trouve). 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CHILLY996 Posté(e) le 20 octobre Partager Posté(e) le 20 octobre @.Shad. @bidh Attention sur mon DS415, ce n'est pas un conteneur DOCKER mais un paquet SYNOCOMMUNITY. Ce qui explique qu'il n'y a pas de port mais un dossier derrière l'IP du NAS. Donc pour accéder à rutorrent en interne, il faut entrer l'adresse http://192.168.XXX.30/rutorrent/. Mais de l'extérieur je souhaite taper ds415rutorrent.mondomaine.xxx pour que ca tape en interne sur http://192.168.XXX.30/rutorrent/. Je ne sais pas comment modifier ce fichier conf pour obtenir ce résultat particulier. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
bidh Posté(e) le 20 octobre Partager Posté(e) le 20 octobre (modifié) CHILLY996 Citation Attention sur mon DS415, ce n'est pas un conteneur DOCKER mais un paquet SYNOCOMMUNITY. Ce qui explique qu'il n'y a pas de port mais un dossier derrière l'IP du NAS. Non, cela n'a rien à voir. C'est dû à rtorrent et rutorrent. Citation Donc pour accéder à rutorrent en interne, il faut entrer l'adresse http://192.168.XXX.30/rutorrent/. Rutorrent est un serveur web fournissant une interface graphique pour rtorrent. Donc à priori, le port 80 en http. Personnellement, j'utilise https://NOM_du_NAS.NDD.fr/file/ pour accéder à Filestation https://NOM_du_NAS.NDD.fr/audio/ pour accéder à DS Audio https://NOM_du_NAS.NDD.fr/download/ pour accéder à Downloadstation Et dans ces 3 cas, la redirection se fait sur 192.168.1.200:5001 par le même fichier Nom_du_NAS.subdomain.conf set $upstream_app 192.168.1.200; IP virtuelle set $upstream_port 5001; port https de DSM Au final, je pense que tu écriras ds415rutorrent.mondomaine.fr/rutorrent pour aller sur http://192.168.XXX.30:80/rutorrent. Citation Je ne sais pas comment modifier ce fichier conf pour obtenir ce résultat particulier. Il ne faut pas les modifier, il faut juste les adapter en changeant les adresses IP. Citation proxy_pass $upstream_proto://$upstream_app/rutorrent/; Cela n'est pas bon. Il manque $upstream_port et /rutorrent/ n'a rien à faire là. Regarde les exemples rutorrent.subdomain.conf.sample et rutorrent.subfolder.conf.sample dans /docker/swag/config/nginx/proxy-confs Modifié le 20 octobre par bidh 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.