.Shad.

Je ne me sers plus de Pihole depuis un petit temps. Que ce soit en physique ou virtualisé. La commande que je t'ai donnée permet d'exécuter une commande donnée dans un container donné, donc : Oui 🙂 (tu peux enlever sudo si tu te connectes directement en root)

Il faudrait que je l'installe chez moi, je ne m'en sers plus, la commande pihole -a -p permet de changer le password de la WebUI sur une installation classique hors Docker, je pensais que dans le container c'était une installation classique, du coup je t'ai filé la commande permettant d'exécuter cette commande dans le container directement. Est-ce que tu arrives à te connecter au container déjà avec : sudo docker exec -it pihole bash Si ça ne marche pas avec bash ça devrait fonctionner avec ash. Une fois connecté au container tu tapes : pihole Dis-moi ce que ça te dit.

Tu es en SHR, équivalent Synology du RAID 1, ça veut dire que ton deuxième disque est un miroir du premier. En cas de défaillance d'un disque, il n'y aura pas de discontinuité de service et ton NAS continuera de fonctionner. Ça implique que pour deux disques de capacité égale, tu ne pourras utiliser que la capacité d'un seul disque. Ceci n'est pas une sauvegarde !! Une sauvegarde implique qu'en cas de perte des données, tu puisses les restaurer, ça n'a rien à voir avec le RAID 1. Ce que tu avais l'air de vouloir c'est deux volumes distincts, un utilisable et l'autre servant de destination de sauvegarde. Ce n'est pas du tout la même chose.

@Varx Tu ne créerais pas un nouveau sujet ? C'est compliqué de retrouver ta liste, et ce sera de pire en pire avec le temps... Je pense que ce serait pas mal qu'un modérateur dés-épingle le sujet présent d'ailleurs, vu que l'initiateur n'est plus actif pour l'étoffer (dernier message en 2015).

Normalement dans la partie WAN des box/routeur, il n'y a pas besoin d'utiliser Pihole, c'est le serveur DHCP qui se charge de distribuer son adresse. Tu es resté sur le driver macvlan ? ou tu es passé en host ?

Tu peux très bien te connecter en local sur ton NAS via ton navigateur. Dans ce cas-là les données ne transiteront pas par l'extérieur. Ou faire comme a dit @EVOTk PS : On aime bien que les gens se présentent dans la section appropriée avant de poser leurs questions 🙂

Plex par Docker c'est sur le 218+ uniquement. Par le package officiel c'est tous les modèles je pense.

Oui pardon, je ne l'ai pas précisé.

Variable d'environnement WEBPASSWORD dans ton script de création du container. Sinon, si tu ne veux pas le recréer, tu dois te connecter au container et entrer la commande pour ça : sudo docker exec -it pihole pihole -a -p Le premier pihole c'est le nom du container, à adapter à ton cas.

Bienvenue !

127.0.0.1 c'est localhost c'est pareil. Ça permet que s'il change son IP locale, il n'y ait pas d'impact. Ok pour 172.28.0.0/24, par contre t'es parti pour faire une règle de pare-feu pour chaque container avec lequel tu dois communiquer, ça me semble fastidieux. Tu chiffres deux fois, une fois pour arriver à ton proxy inversé, là c'est bien, et une fois entre ton proxy inversé et ton container, là il n'y a aucun intérêt. Le HTTPS est utile si tu dois directement accéder à Bitwarden de manière sécurisée sans passer par un proxy inversé.

Si tu es en mode host, tu ne peux pas, tout simplement car Pihole utilise les ports du NAS directement, il est installé sur l'hôte, donc il n'y a pas de mappage de ports possible. Je sais très bien quelle méthode tu as utilisé, j'ai bien vu quand tu lui demandes dans les commentaires s'il a une solution au fait de voir juste l'IP de la passerelle, il a répondu à côté (incompréhension ou il botte en touche, je ne sais pas). Regarde cette discussion : https://github.com/pi-hole/docker-pi-hole/issues/135 Personne n'a trouvé de solution. Hormis celle de passer en mode host, et cette méthode a les gros inconvénients cités plus hauts. Essaie ce que je t'ai dit dans un premier temps. Une idée : je n'ai aucune expérience avec les VM classiques, est-il possible quand on crée une VM que ce soit le serveur DHCP qui lui attribue une adresse IP ou elle doit être rentrée manuellement ? Car si c'est possible, alors le serveur DHCP donnera toutes les infos nécessaires à la VM faisant tourner Pi-Hole, et le conditional forwarding devrait permettre de voir en plus le nom des appareils à la place de leurs IP.

Dans ton pare-feu, tu autorises l'accès aux adresses 172.28.0.1 à 172.28.0.254, es-tu sûr que le container bitwarden de l'interface a cette adresse-là ? Remplace cette règle par 172.16.0.0/255.240.0.0 Ça autorisera tous les containers créés en mode bridge à discuter avec ton NAS. Et dans ta règle, tu n'as pas besoin de passer deux fois par du HTTPS, dans destination tu mets HTTP / 127.0.0.1 (ou localhost) / 81 (si tu as bien renseigné le mapping du port 81 lors du script d'installation de Bitwarden). Ensuite si tu n'as pas d'ouverture vers le réseau local sur le port 81, crée une règle pour ce port, et teste si ça marche. Pour moi c'est ta règle de pare-feu qui n'est pas bonne.

En macvlan, avec une adresse IP sur la plage de ton réseau local, ou en bridge avec une adresse en 172.x.0.1, la passerelle est le NAS, tout passe par celui-ci avant d'aller à ton container. Un peu comme internet passe par ton routeur avant d'arriver à ton périphérique. Le driver macvlan permet non pas de changer les ports, tu peux déjà le faire avec un driver bridge, mais justement d'utiliser les ports par défaut de Pihole (80 et 53), sans être en conflit avec le NAS car le container a sa propre adresse IP "physique". En bridge, le container en 172.x.0.1 n'est accessible à aucun autre périphérique que son hôte le NAS, on contourne le problème en exposant les ports qu'utilise le container sur des ports libres du NAS ; par exemple le port 80 (WebUI) du container peut être associé au port 8080 du NAS. Quand on installe le container sur l'hôte directement (paramètre --net=host en ligne de commande ou network_mode: host via docker-compose v2.x), il n'y a plus de passerelle, le container s'exécute directement sur le NAS. Donc normalement, tu devrais être capable de voir la liste des clients. Ça ne diffère d'une installation classique (sans docker) que dans le sens où le container embarque ses propres dépendances, quand tu supprimes ton container ça ne touche à rien de ce qui est installé sur le NAS (et de facto tu n'as rien à installer en plus). Mais le problème de ce mode est que tu utilises les ports par défaut, et ceux-ci sont utilisés par Webstation et DNS serveur. Tu peux faire un test, désactiver les deux paquets, créer ton container en mode host et voir si ça fonctionne comme tu le souhaites.

La meilleure solution reste de loin de l'installer sur un périphérique tiers, sur l'hôte directement. Ou alors, il faut désactiver les paquets DNS serveur et Webstation, pour libérer les ports 53 et 80, et utiliser le driver net=host lors de la création du container. mais ça peut être handicapant pour ceux qui ont besoin de ces paquets. Après c'est surtout au niveau de l'analyse et le traitement des métriques que ça pose problème d'avoir un seul client dans les dashboard. D'un point de vue fonctionnalité c'est parfaitement opérationnel.

Si tu peux répondre à ma question stp 🙂

@unPixel Ok en effet on ne s'était pas compris. 🙂

Il a quand même déjà mis un proxy inversé en place, même s'il est nouveau sur le forum il a probablement une petite connaissance du NAS, et peut-être une lecture de quelques tutos. Quant au port 80, c'est possible. Je sais juste que si je tente de créer un container utilisant un port déjà en cours dutilisation surnle NAS, il me dira que ce n'est pas possible. Un lien à me donner pour voir de quoi il est question avec le .htaccess ?

Ok merci de l'info 🙂

S'il a ouvert tous les ports vers son LAN, comme préconisé dans le tutoriel de la sécurisation du NAS, et qu'il utilise le proxy inversé du NAS (ce n'est pas dit explicitement mais j'imagine que oui), il n'a pas besoin d'ouvrir de port supplémentaire. En revanche oui, il faut éviter d'utiliser les ports 80 (utilité par Webstation) et 443 (utilisé par le proxy inversé). Erreur 504 en revanche c'est étrange, peux-tu poster le contenu de l'entrée de ton proxy inversé relative à Bitwarden ?

Je crois qu'il est prévu que Drive devienne l'unique solution de synchronisation à moyen terme, à la façon de la fusion de Photostation et Moments dans DSM 7. Pour ma part je ne suis pas du tout satisfait de Drive et j'utilise Syncthing sous Docker pour la synchronisation de mes fichiers sur les différents appareils. Et j'entends beaucoup parler de Nextcloud, il faudrait que je teste. 🙂

Oui j'ai pris ce modèle-là pour l'exemple il y a plusieurs modèles il faut trouver celui qui correspond au besoin. Et là dessus les autres intervenants s'y connaissent mieux. 🙂

Bienvenue !

Ce n'était pas spécialement à ton intention la suggestion de PyLoad, surtout si tu débutes dans le domaine. Docker demande pas mal d'apprentissage, tu as le temps. 🙂 C'est plus pour les autres qui rencontrent le même problème (et vous êtes nombreux) et qui ont déjà des bases solides. A partir de là il serait facile de faire un tutoriel si personne ne trouve comment régler ça en utilisant Download Station.

Il faudrait que quelqu'un utilisant les services de téléchargement en direct download teste pyLoad : https://hub.docker.com/r/writl/pyload Ça a l'air très simple d'utilisation, et ça permettrait de confirmer que ça vient bien de Download Station et rien d'autre. J'aurais bien essayé moi-même mais je n'utilise aucun de ces services.