[Tuto] Installer SWAG en Docker ( Reverse Proxy )

Tu semble etre sur DSM, tu ne peut pas suivre ce tuto comme il est si tu veut utiliser fail2ban. Le reverse proxy intégré de DSM prend le dessus sur la gestion des IP, et en fait SWAG se trouve a ne voir que des IP locale. Donc pour le bannissement, cela devient compliqué ^^' Sinon faut faire une installation en macvlan + ip virtuelle, je suppose que cela marcherait, mais c'est hors de mes compétences
 
Une autre question :
à partir du téléphone, j'ai attaqué scrypted sur mon nom de domaine, qui est reverse proxifié.
J'ai tapé exprès un login/password bidon... des disaines de fois sans me faire bannir.
Je pensais que fail2ban gérait tout ça ?
Dans ce cas il faut vérifier dans les logs du reverse que l'appli remonte bien l'erreur , sinon il faut fournir a fail2ban les logs de l'appli directement
 
@ablyes regarde par exemple le point 8/c du tuto, comme exemple
Si le logs du reverse n'est pas assez parlant, il te faudra alors recupérer le logs de ton appli, et le fournir en lecture a fail2ban
 
Bonjour j'ai un soucis je configurer swag sur docker avec une validation ovh, je remplis bien les clés generer depuis l'api de ovh, mais j'ai cette erreur
[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] 02-swag-old-certbot-paths: skipped
[migrations] done
───────────────────────────────────────
██╗ ███████╗██╗ ██████╗
██║ ██╔════╝██║██╔═══██╗
██║ ███████╗██║██║ ██║
██║ ╚════██║██║██║ ██║
███████╗███████║██║╚██████╔╝
╚══════╝╚══════╝╚═╝ ╚═════╝
Brought to you by linuxserver.io
───────────────────────────────────────
To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot
To support LSIO projects visit:
───────────────────────────────────────
GID/UID
───────────────────────────────────────
User UID: 1002
User GID: 1002
───────────────────────────────────────
Linuxserver.io version: 3.3.0-ls371
Build-date: 2025-03-17T13:53:41+00:00
───────────────────────────────────────

using keys found in /config/keys
Variables set:

2

2
TZ=Europe/Paris
URL=xxx.com
SUBDOMAINS=wildcard
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=dns
CERTPROVIDER=
DNSPLUGIN=ovh
EMAIL=sabega@xxx.com
STAGING=
Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for xxx.com will be requested
E-mail address entered: sabega@xxx.com
dns validation via ovh plugin is selected
Generating new certificate
Saving debug log to /config/log/letsencrypt/letsencrypt.log
Requesting a certificate for xxx.com and *.xxx.com
Unsafe permissions on credentials configuration file: /config/dns-conf/ovh.ini
Error determining zone identifier for xxx.com: 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 /config/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.



VOICI mon fichier compose
version: "2.1"
services:
swag:
image: lscr.io/linuxserver/swag
container_name: swag
cap_add:
- NET_ADMIN
environment:
- PUID=1002
- PGID=1002
- TZ=Europe/Paris
- URL=xxx.com
- SUBDOMAINS=wildcard
- VALIDATION=dns
- DNSPLUGIN=ovh
- EMAIL=sabega@xxx.com
volumes:
- /data/compose/1/swag:/config
ports:
- 444:443
restart: unless-stopped
 
Je commencerai par résoudre ce problème de permission :
Unsafe permissions on credentials configuration file: /config/dns-conf/ovh.ini
Faire un ls -l dans le dossier config/dns-conf et voir quelles sont les permissions du fichier OVH.ini
S'il n'appartient pas au user 1002, et au groupe 1002, il faut faire un chown 1002:1002 ./ovh.ini dans le répertoire dns-conf, ceci afin de l'attribuer aux bons user/group.
Si après un redémarrage du container ça ne le fait toujours pas et que l'erreur persiste, c'est que ce n'est pas un problème d'attribution mais plutôt de permissions trop "ouvertes" (ce que semble vouloir dire "unsafe" au début de l'erreur.
Là on avisera selon le retour de ton ls -l sur le fichier ovh.ini