.Shad.

@anorec Bon j'ai investigué. Alors le système de mapping fonctionne bien, même s'ils ne mappent que 2 users et qu'eux en utilisent plus que ça dans le conteneur, d'où le fait qu'on se retrouve avec encore quelques utilisateurs non nommés, mais heureusement ça ne semble pas poser problème pour l'écriture des fichiers. Optionnel : si tu as configuré des listes, des exceptions, etc... que tu souhaites récupérer, tu peux le faire en 2022.07 via Settings -> Teleporter -> Backup. Le mieux est donc de partir d'une installation vierge, créer un dossier pihole dans le dossier partagé docker via Filestation, et des sous-dossiers etc et dnsmasq.d. Ensuite on crée un utilisateur dédié à pihole dont les droits se limitent au dossier partagé docker. On donne la propriété du dossier pihole et ses enfants à l'utilisateur dédié (via Filestation) : Ensuite, ne plus monter comme je le fais dans le tutoriel le volume contenant les logs, en fait c'est inutile car il y a tous les outils nécessaires dans pihole même : Et on va ajouter les variables d'environnement pour mapper les uid/gid entre conteneur et hôte (je rappelle, en SSH on fait id <utilisateur> pour connaître son UID (>1026) et son GID (100 pour users) - PIHOLE_UID=1041 - PIHOLE_GID=100 - WEB_UID=1041 - WEB_GID=100 On peut maintenant créer le conteneur, la première fois les logs affichaient une erreur persistante : Starting lighttpd Stopping lighttpd lighttpd: no process found J'ai arrêté et redémarré le conteneur, pour l'instant plus une erreur, puis j'ai importé tous mes paramétrages via Settings -> Teleporter -> Restore (browse) J'ai récupéré mes groupes, mes whitelist ainsi que mes réglages (mais tous viennent du fichier compose dans mon cas). Car oui, pour information, tout (ou quasi) peut être configuré à la création du conteneur via les variables d'environnement mises à disposition, seules les plus importantes sont listées sur Github, mais dans la doc... 😄 : https://docs.pi-hole.net/ftldns/configfile/ Voilà, dis-moi si ça fonctionne bien chez toi, si oui, mon setup est reproductible et je mettrai à jour le tutoriel, en attendant je vais placer un avertissement concernant les risques liés à la 2022.08

Via les virtual host ? Je veux bien que tu m'expliques alors. Car pour moi les virtual host de Webstation, c'est l'équivalent Apache des blocs "server" de Nginx mais ma connaissance d'Apache est quasi nulle. S'il y a moyen d'avoir Nginx sur les ports 80 et 443 du NAS sans se passer de Webstation et commencer à désinstaller/stopper des paquets du NAS je suis preneur. Mais à ma connaissance 80 est pris par Apache (ou Nginx si on le configure ainsi) et par Nginx sur le 443.

@anorecRécemment, Pihole est exécuté par l'utilisateur "pihole", et ils ont mis à disposition des variables pour mapper cet utilisateur interne au conteneur à un utilisateur de l'hôte : Tu peux ajouter dans le fichier compose la variable DNSMASQ_USER=root pour revenir sur le fonctionnement classique. Et quand tu as le temps, faire le mapping sur un utilisateur non privilégié de DSM (mieux qu'utiliser root quand on nous en donne la possibilité). Chez moi je me rends compte que j'ai fait à un moment donné un chmod 777 sur le dossier pihole : Donc ça explique pourquoi je n'ai pas eu de problème. Du coup je vais de la semaine repartir sur un nouveau conteneur et dossier, avec le mapping, et vérifier si ça marche bien, et je mettrai le tutoriel à jour. Dis-moi si ce que j'ai suggéré arrange les choses de ton côté (et pour moi tu peux enlever les autorisations SYS_NICE et CHOWN).

@Einsteinium D'une part parce que les ports 80 et 443 du NAS sont déjà utilisés. Et que je préfère ne pas toucher à DSM. D'autre part on pourrait se dire on map les ports 80 et 443 du NAS sur 10080 et 10443 par exemple et sur le modem/routeur on fait un NAT 80 -> 10080 du NAS et 10443 du NAS. De l'extérieur c'est transparent, mais si on veut utiliser les mêmes noms de domaine en interne qu'en externe on est coincé. En macvlan on règle ces deux problèmes, même si je reconnais que c'est plus facile en bridge. Le plus simple étant de mettre SWAG en bridge sur une machine dont les ports 80 et 443 sont libres (ou passer par une VM, mais ça revient peu ou prou à faire un conteneur en macvlan, avec en plus des ressources dédiées qui seront toujours trop importantes pour du Nginx qui ne consomme quasi rien).

OK et bien des impressions d'écran plutôt. Avec les variables, les volumes, etc... Un fichier compose est bien plus pratique pour debugger des situations. 😃

Il semblerait que Synology se reprenne enfin en main. Après tout ce temps c'est une bonne nouvelle, comme la synchro à la demande pour Drive sur périphériques Apple.

Tu peux afficher ton fichier compose ?

Hello @anorec, Je viens de mettre à jour Pihole en 2022.8 sur mon serveur Debian et mon NAS (pour la redondance) et je n'ai aucun problème. J'ai regardé le log FTL par acquis de conscience et je vois des erreurs datant du 19, par contre depuis la màj à l'instant pour l'instant pas d'erreur : 2022-07-19 22:32:10: server.c.1513) server started (lighttpd/1.4.59) 2022-07-19 22:32:10: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-10 18:55:36: server.c.1513) server started (lighttpd/1.4.59) 2022-08-10 18:55:36: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-10 18:57:55: server.c.1513) server started (lighttpd/1.4.59) 2022-08-10 18:57:55: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-13 13:48:42: server.c.1513) server started (lighttpd/1.4.59) 2022-08-13 13:48:42: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-15 21:00:55: server.c.1513) server started (lighttpd/1.4.59) 2022-08-15 21:00:55: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-16 20:03:24: server.c.1513) server started (lighttpd/1.4.59) 2022-08-16 20:03:24: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-19 21:04:07: server.c.1513) server started (lighttpd/1.4.59) 2022-08-19 21:04:07: gw_backend.c.475) unlink /run/lighttpd/php.socket-0 after connect failed: Connection refused 2022-08-23 05:03:41: server.c.1513) server started (lighttpd/1.4.59) 2022-08-23 05:55:22: server.c.1513) server started (lighttpd/1.4.59) 2022-08-23 06:00:16: server.c.1513) server started (lighttpd/1.4.59) Vu que l'erreur est liée à localhost au sein du conteneur, je ne pense pas que ce soit un problème de configuration.

Tu devrais regarder dans les logs nginx du NAS, je ne suis pas chez moi donc je ne peux pas vérifier, mais de souvenir ça doit être en SSH dans /etc/nginx/logs ou quelque chose d'approchant. EDIT : ou dans /var/log peut-être, avec DSM 7 beaucoup de logs y ont été rapatriés.

172.21.0.0/24 ça entre en conflit avec la plage utilisée par Docker. Utilise plutôt une plage dans 10.0.0.0/8 pour ton réseau VPN, car on ne sait pas changer facilement le réseau utilisé par défaut par Docker sur DSM. Sinon en théorie, si pas de conflit induit par ma remarque ci-avant, ça devrait pourtant fonctionner, quel message d'erreur obtiens-tu ?

Pour les notifications, vu que Discord ne te convient pas, tu as aussi Gotify, partie 8-d du tutoriel de EVOTk : https://www.forum-nas.fr/threads/tuto-installer-swag-en-docker-reverse-proxy.15057/ Pour le SMTP d'OVH c'est simple : port 587 -> STARTTLS / port 465 -> SSL Sachant qu'on utilise maintenant plutôt STARTTLS que SSL. Et le SMTP de Google c'est bien STARTTLS qu'ils utilisent. De là à dire que c'est illisible dans un seul fichier de jail : ## Version 2020/05/10 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/jail.local # This is the custom version of the jail.conf for fail2ban # Feel free to modify this and add additional filters # Then you can drop the new filter conf files into the fail2ban-filters # folder and restart the container [DEFAULT] # Changes the default ban action from "iptables-multiport", which causes issues on some platforms, to "iptables-allports". banaction = iptables-allports # "bantime" is the number of seconds that a host is banned. bantime = 24h # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 30m # "maxretry" is the number of failures before a host get banned. maxretry = 5 # Ignore local IPs ignoreip = 10.0.0.0/8 192.168.0.0/16 172.16.0.0/12 2a02:xxxx:xxxx:da01::/64 [ssh] enabled = true filter = sshd port = ssh logpath = /log/host_auth.log action = discordEmbed[bantime=24] iptables-allports [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /config/log/nginx/error.log [nginx-badbots] enabled = true port = http,https filter = nginx-badbots logpath = /config/log/nginx/access.log maxretry = 2 [nginx-botsearch] enabled = true port = http,https filter = nginx-botsearch logpath = /config/log/nginx/access.log [nginx-deny] enabled = true port = http,https filter = nginx-deny logpath = /config/log/nginx/error.log [bitwarden] enabled = true port = http,https filter = bitwarden logpath = /log/host_bitwarden.txt action = discordEmbed[bantime=24] iptables-allports [calibre-web] enabled = true port = http,https filter = calibre-web logpath = /log/calibre-web/calibre-web.log action = discordEmbed[bantime=24] iptables-allports [embyserver] enabled = true port = http,https filter = embyserver logpath = /log/host_embyserver.txt action = discordEmbed[bantime=24] iptables-allports

Pour de la sauvegarde pas besoin d'avoir des disques de première jeunesse. Tant qu'ils sont reconnus et utilisables par DSM. Prévoir quand même du coup une deuxième sauvegarde des données importantes, dans le cloud par exemple ou sur un disque externe.

@_DR64_ Ok avec ce qu'a dit @MilesTEG1, et quand tu as des erreurs comme ça, au lieu de lancer les 5 commandes d'un coup, déjà tu les lances une par une pour voir laquelle plante. 😉 Si ton proxy inversé est celui du NAS, alors tu dois pointer vers http://IP_VIRTUELLE_DU_NAS:32400 et pas l'IP du NAS. Un conteneur en macvlan ne peut pas communiquer avec son hôte via son interface physique (et vice-versa).

Autant prendre une Shield Pro en serveur dans ce cas-là, et monter les fichiers du NAS via Samba.

Tu as l'air d'avoir un avis bien arrêté sur ce que tu veux. Pas sûr que nos réponses apportent vraiment une quelconque plus-value. Pour conclure mes interventions ici, je dirai que je trouve dommage de n'avoir que 5 baies en SHR-2, tu condamnes 40% de ta capacité de stockage. Autant partir sur du 6 ou 8 baies alors dans ce cas-là. Et peut-être être acheter des disques moins gros, en cas de perte ils seront moins coûteux à remplacer. Avec 6 baies en SHR-2, 6 disques de 8 To donnent 32 To de stockage.

Les Red Plus Pro tournent plus vite également, et sont donc plus bruyants. C'est un critère à prendre en compte en plus du nombre de disques. Gné ? Qu'est-ce que "lent" pour toi ? Pour quelle utilisation ? Sans plus d'information sur le besoin cette question n'a pas de sens. Si tu es dans un environnement multi-utilisateurs type bureau et que le transfert de fichiers est légion, l'agrégation de liens peut être une piste. Le 10Gb exige un réseau adapté, outre les points A et B de terminaison (NAS et client). Un routeur, un switch, les câbles cat 6 et plus, et niveau budget ce n'est plus la même histoire. Sans parler de la consommation énergétique qui augmente grandement. Si tu as un vrai besoin de vitesse (hors environnement multi-utilisateurs), tu peux toujours envisager une clé USB3 -> RJ45 2.5 ou 5Gb/s, mais il faut vérifier ce qu'accepte DSM depuis la version 7. @maxou56 est plus versé que moi dans ce domaine, il pourra sûrement te conseiller le cas échéant.

Ce n'est pas sensé fonctionner ça, voici les valeurs acceptées pour network_mode : Compose file version 3 reference | Docker Documentation Pour la modification dans le service, oui c'est bon ainsi, par contre tu n'as pas la même indentation entre "plex:" et "image:..." et entre "networks:" et "macvlan:". 2 espaces dans le premier cas, 3 dans le suivant. Ca ne pose pas de problème ici, seulement si "macvlan:" est aligné avec tes éventuelles variables d'environnement, par exemple "- PUID=..." De manière générale définis un nombre d'espaces à utiliser et respecte le dans tous tes fichiers yaml (compose ou autres). Par contre, quand tu utilises "networks:" et pas "network_mode:" tu dois déclarer ton réseau par après. Ici le réseau est créé en dehors du fichier docker-compose, donc il te faut quelque chose comme ça : version: "2.4" services: plex: #image: linuxserver/plex:latest # https://github.com/linuxserver/docker-plex image: ghcr.io/linuxserver/plex container_name: plex networks: macvlan: ipv4_address: 192.168.64.254 networks: macvlan: external: true

Tu peux regarder ce que je dis dans mon tutoriel aux points 11-A-1 et 11-A-2 Via docker compose dans un service : networks: reseau-toto: ipv4_address: 192.168.1.xxx Pas besoin d'ajouter la MAC, même si tu peux le faire si tu as envie, vu que ça ne passe pas par le serveur DHCP ce n'est pas forcément utile.

En même temps dans leur jail.local je ne vois pas d'include, essaie d'ajouter : include jail.d/*.conf et de redémarrer le conteneur. Si ça fonctionne tu peux toujours créer une demande d'amélioration sur leur GitHub. 😉

@Einsteinium Ca fait longtemps que je n'ai pas testé sur le NAS, mais de mémoire ça marchait bien. @MilesTEG1 Mais de quelle application tu aurais encore besoin sur le 443 sur le NAS directement ? Tout passe par SWAG comme l'a dit @Einsteinium, ce qui ne passe pas par SWAG (Drive, HBK, etc...) passe par un port dédié (6690, 6281, etc...) et là il te faut un certificat pour ces applis là sur le NAS, méthode acme par Docker ou ndd Synology, peu importe.

Ca ne change pas le fond de mon message, pour moi les dossiers partagés sont plus aptes à être gérés par le gestionnaire de permissions de DSM. On est d'accord que tu utilises la fonction de partage c'est ça ? et pas le panneau de configuration -> dossiers partagés ?

A vérifier je n'ai jamais fait le test, mais pour moi les fonctions de partage sont destinées à l'espace personnel de préférence. Pour ce qui sort des dossiers personnels, donc par un exemple un dossier partagé lambda, il est préférable que l'utilisateur administrateur gère les permissions de chacun pour chaque dossier. Je regarderai ce soir ce que j'arrive à faire éventuellement, je ne suis pas chez moi.

Tu n'as pas compris comment fonctionne la synchronisation de Drive. Et pareil pour l'histoire des certificats sur le NAS, le port 443 n'a plus rien à faire ici dans ton cadre d'utilisation. Ce serait trop long de tout reprendre, on peut en parler en vocal si tu veux, je t'envoie mes dispos en MP.

Non pas du tout, c'est un webhook, Discord crée un token d'accès pour une application donnée avec des droits définis, comme tu trouves sur Spotify, Google, Youtube, etc... Ben la réponse est dans ce que tu viens d'écrire, normalement dans la fenêtre en question ce que tu dois mettre c'est l'IP ou un ndd menant à l'IP du NAS. Pourquoi avoir mis drive.ndd.tld ? c'est pas une entrée de ton proxy inversé ça ? SI c'est le cas il y a grosse confusion. Si tu veux avoir une certificat pour le même nom de domaine pour SWAG et le NAS, c'est simple, tu laisses ton setup acme.sh qui exposera un certificat pour les applications type Drive sur le NAS (bien vérifier les associations certificat - application dans DSM). Et parallèlement tu auras un certificat pour le même nom de domaine avec SWAG. Rien n'empêche d'avoir plusieurs certificats wildcard pour un même nom de domaine. Ainsi c'est transparent pour toi. Moi j'utilise le ndd Synology uniquement pour joindre localement et à distance (via le DDNS gratuit) mon NAS principal pour ses services intrinsèques, ca marche très bien. Oui, en bridge ou en host, car tu es lié à l'hôte. Pas en macvlan. Oui donc tu as ce qu'il faut en amont, donc c'est ok pour la sécurité par rapport à l'extérieur. A toi l'honneur. 😄 Je fais pas de tutoriel de toute façon sur quelque chose dont je ne maîtrise pas tous les aspects, c'est au moins parti pour quelques semaines d'observation.

Ah ok ! Je n'avais remarqué sa présence que lors de DSM 7, du coup je croyais que c'était un des changements induits par la version 7. Merci de la correction. 😉