molinadiaz

Hello @.Shad., À mon tour désolé pour le délais de réponse, je suis toujours en déplacement. Alors, merci pour la petite astuce pour retrouver facilement l'ID de traitement. Tout se passe comme je l'imaginais, je peux te le confirmer : La commande ps -p <PID> au me retourne bel et bien le processus watchtower exécuté par l'utilisateur watchtower créé au préalable sur le système, et ce grâce à la stack déployée via Portainer de la manière suivante : version: "3.8" services: watchtower: image: containrrr/watchtower:amd64-latest user: xxxx:yyyy où xxxx et yyyy représentent respectivement le UID et le GID ! Pour mon container vaultwarden, même chose, il est bien exécuté par mon utilisateur vaultwarden ! Tout roule 🙂 Les processus sont mieux isolés s'ils ne sont pas gérés par root et la surface d'attaque est amoindrie (du moins, je crois et je l'espère lol). Forcément, je n'ai que le container portainer-ce qui est exécuté par root, puisque je ne suis pas en mesure de déployer une stack pour portainer lui-même si celui-ci ... n'existe pas encore ! Si maintenant il existe une manière de changer à la volée le user qui exécute le container portainer-ce (maintenant qu'il tourne) pour que celui-ci ne soit plus exécuté par root, je suis preneur ! Reste encore à se poser la question de savoir si ce sera possible de déployer des stacks si Portainer a des droits limités.

Hello @.Shad., Oui, oui 😅 Je suis toujours en déplacement. Je repasserai ici naturellement une fois que je serai un peu plus posé car j'ai quelques questions à poser, effectivement. En attendant, sais-tu pourquoi la commande ne retourne rien ? Je confirme que mon Docker est bel et bien en cours de processus, et que mes containers tournent. Par avance, merci !

Hello @.Shad., Je suis en déplacement. J'avais prévu de répondre longuement. Mais je vais morceler ma réponse afin d'avancer au compte goutte. Je voulais d'abord m'assurer de ça. Étrangement, la commande ne me retourne rien si ce n'est grep lui-même (forcément) exécuté par l'utilisateur du terminal. Comment ça se fait ? Docker avait été installé via le Centre de paquets Synology. Il tourne pourtant actuellement. Et 3 containers aussi, d'ailleurs. Merci 🙂

Merci pour vos réponses @.Shad. @bliz ! Je crois que je vais rester comme ça. C'est un peu fastidieux à gérer la première fois (c'est le seul inconvénient, en soi) mais une fois que c'est paramétré, on est tranquille. Comme dit @.Shad., je ne veux pas chmod le dossier partagé docker pour les raisons évoquées. Le coup de la VM minimale, ça ferait peut-être un peu trop de surcouche. Si je comprends bien, il y aurait DSM qui fait tourner Virtual Machine Manager (qui n'est pas installé chez moi, d'ailleurs), lui-même faisant tourner une VM légère comme Alpine Linux qui à son tour ferait tourner Docker, ce dernier exécutant mes containers ? 😅 À ce moment-là, je crois que je préférais encore faire tourner chaque container dans le home directory de son utilisateur. L'idée étant aussi de ne pas gonfler la RAM si une alternative plus légère est possible. Après tout, j'ai pas encore upgrade les barrettes du DS918+ 😂

Hello @.Shad., On est bien d'accord qu'avec : version: "3.8" services: vaultwarden: image: vaultwarden/server user: 1001:1001 C'est bel et bien l'utilisateur du système hôte ayant pour UID 1001 et GID 1001 qui exécute mon container ? Je ne me fais pas de fausse idée là-dessus ? En d'autres termes, mon container vaultwarden est bien exécuté en non-root, n'est-ce pas ? Je suis tombé sur ça : https://github.com/portainer/portainer/issues/1888 Bon, ça date un peu, c'est vrai. Et c'est pas vraiment la même image (le repo portainer/portainer est considéré comme déprécié). À ce que je comprends, le gars serait parvenu à exécuter portainer par un utilisateur non-root en mappant depuis l'extérieur un fichier config.json vide dans le container. Juste comme ça : volumes: - "./data:/data" - "./config.json:/config.json" J'ai essayé. Ça ne fonctionne pas.

Hello @.Shad., Via File Station. Cela dit, je pense que le comportement était normal, en fait. Certes, j'avais bien coché la case "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" dans les options du dossier partagé docker ... MAIS j'avais omis via File Station depuis mon compte administrateur de créer des permissions de type "Refuser / Contrôle Total" dans les propriétés de chaque sous-dossier de /volume1/docker/. Par exemple, pour le dossier /volume1/docker/portainer-ce (dont l'utilisateur portainer-ce est le propriétaire), et avec des permissions "Refuser / Contrôle Total" pour les utilisateurs mongodb et vaultwarden : De cette manière, et uniquement de cette manière, le dossier /volume1/docker/portainer-ce n'apparaît plus dans File Station lorsque connecté à DSM avec les utilisateurs mongodb et vaultwarden. Je crois qu'on ne peut pas isoler autrement, en fait. J'avais éventuellement songé à arrêter d'utiliser /volume1/docker/dossier_par_container_propre_à_un_utilisateur pour faire tourner chaque container dans son home directory respectif, par exemple le container portainer-ce dans /volume/homes/portainer-ce, le container vaultwarden dans /volume1/homes/vaultwarden pour m'éviter d'enregistrer les permissions à la main comme sur le screenshot juste au-dessus, mais pour tout un tas de raison cette solution me semblait pas folle. Je crois que ça aurait justement poser problème si un jour un container devait partager plusieurs dossiers, non ?

Bonjour, Synology DS918+ DSM 7.1.1-42962 Update 3 Utilisateur : portainer-ce Groupe : docker Image : portainer/portainer-ce https://registry.hub.docker.com/r/portainer/portainer-ce/ Je passe en revue chacun de mes containers Docker. L'objectif étant que chaque container soit exécuté par un utilisateur non-root. Par exemple, pour le container vaultwarden, le docker-compose.yml ressemble à ceci où user: 1001:1001 permet de faire exécuter le container par l'utilisateur PUID 1001 du groupe PGID 1001 du système hôte. version: "3.8" services: vaultwarden: image: vaultwarden/server user: 1001:1001 Tous mes containers s'exécutent en non-root. Il ne me reste plus qu'à sudo docker-compose up -d mon fichier .yml pour Portainer. Mais le coup du user: 1001:1001 ne prend pas. Voici les logs : L'arborescence ainsi que les privilèges pour config.json sur lequel il y a une permission non accordée : Merci pour votre aide. Cordialement,

Bonjour, Synology DS918+ DSM 7.1.1-42962 Update 3 Utilisateurs : mongodb, portainer-ce, vaultwarden Groupe : docker Images : mongo:4.4.9 https://registry.hub.docker.com/_/mongo/, portainer/portainer-ce https://registry.hub.docker.com/r/portainer/portainer-ce/, vaultwarden/server:latest https://registry.hub.docker.com/r/vaultwarden/server/, Dossier partagé : docker dans /volume1 Lorsque je suis connecté à DSM sur File Station avec mon compte administrateur (différent du compte utilisateur admin par défaut), je vois tous les sous-dossiers de /volume1/docker, à savoir : /volume1/docker/vaultwarden, /volume1/docker/portainer-ce et /volume1/docker/mongodb. Comme suit : Lorsque je suis connecté à DSM sur File Station avec, mettons l'utilisateur mongodb, je vois exactement la même chose. D'un point de vue sécurité, ne serait-il pas plus sage de n'afficher que le sous-dossier /volume1/docker/mongodb (et pas les autres sous-dossiers) à l'utilisateur mongodb ? Si oui, comment faire puisque tous ces utilisateurs font partie du groupe docker ? Chacun voit actuellement les sous-dossiers des autres, ça me semble pas très safe. Idéalement, j'aimerais que l'utilisateur mongodb ne puisse même pas avoir d'accès en lecture aux dossiers des utilisateurs portainer-ce et vaultwarden. Masquer l'affichage de ces dossiers dans le File Station de l'utilisateur mongodb. Possible ? L'option "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" est déjà cochée dans les paramètres du dossier partagé docker. Alors, étrange, non ? Merci pour votre aide. Cordialement,

Bonjour @.Shad., merci pour ta réponse ! J'ai checké la page admin de mon switch Netgear Nighthawk S8000 (celui en 192.168.C.X sur le schéma isoflow.io btw) mais il ne semble pas gérer le protocole STP. Aurais-tu deux switches gérant ce protocole à me recommander ? Je les placerais en 192.168.D.X et 192.168.E.X 😉 Aussi, j'ai cru comprendre que je pouvais encore améliorer le schéma. Pour le moment, le switch 1 et/ou le switch 2 devraient passer obligatoirement par la passerelle pour communiquer avec le switch 3. Il pourrait y avoir un multilayer switch L3 qui géreraient la communication entre tous les switches et périphériques, ce qui m'éviterait de passer par la passerelle routeur, si je comprends bien ? Mais bon, un peu overkill pour un réseau domestique, non ? 😅

Bonjour, Je désire ajouter de nouveaux périphériques réseaux à domiciles. Pour ce faire, je dois ajouter de nouveaux équipements. Je compte remplacer mon routeur Wi-Fi par un pare-feu Protecli Vault faisant office de passerelle (192.168.A.X). Je ne sais pas encore si j'utiliserai pfSense ou OpnSense. L'actuel routeur Wi-Fi sera transformé en simple point d'accès sans fil. Afin de minimiser le point de défaillance unique, chacun de mes deux NAS seront connectés à deux switch Ethernet. Considérez plutôt le schéma en pièce jointe. Ma question : pourrai-je facilement joindre mes NAS en 192.168.D.Y ou 192.168.E.Y depuis mon desktop en 192.168.C.Y avec pfSense/OpnSense ? Admettons également une box Android de type Nvidia Shield devant accéder au contenu multimédia du NAS 1 en 192.168.D.Y (ou 192.168.E.Y). Est-il plus propre de placer Nvidia Shield derrière un des deux switch, ou directement derrière la passerelle en 192.168.A.X ? Merci pour votre aide et bonne journée 🙂

@Mic13710 J'imagine que si je ne parviens pas à joindre l'adresse 192.168.1.x à Paris depuis le NAS en 192.168.0.x à Madrid, c'est à cause de l'absence de loopback sur la box de l'ISP à Madrid ?

Merci pour ces précisions, @Mic13710 ! Ce fonctionnement est valable aussi pour OpenVPN ? Ou bien est-ce propre au protocole L2TP/IPSEC ?

Bonjour, Comment dois-je m'y prendre pour faire correspondre une adresse privée 10.2.0.x à l'adresse locale de mon desktop 192.168.1.x ? Je voudrais WOL mon desktop à Paris depuis Madrid. Je peux déjà WOL avec une connexion VPN établie au préalable depuis un smartphone client vers le serveur OpenVPN de mon DS918+ (Paris), ce dernier assurant alors le relais du paquet vers 192.168.1.x (desktop). Mais ayant créé un profil VPN de type L2TP/IPSEC entre mes 2 NAS Paris-Madrid, je devrais pouvoir WOL directement via le réseau privé en 10.2.0.x et non plus via le réseau local en 192.168.1.x, non ? Merci 😉

Merci pour vos réponses @oracle7 et @Mic13710 😉 Signature DKIM okay ! On avance. Mon serveur mail est finalement celui d'o2switch. Problème : je ne peux avoir qu'un seul MX sur les serveurs d'o2switch, déclaré en priorité 0 vers mail.domaine.tld (hébergé chez o2switch). J'aimerais avoir un serveur MX de secours. Mais o2switch n'en propose pas. Puis-je créer la même adresse email contact@domaine.tld chez OVH afin de définir dans ma zone publique un second record MX en priorité 10 pointant vers mail2.domaine.tld (hébergé chez OVH) ? Ça fonctionnerait, ça ?

Bonjour, J'ai mon domaine.tld qui enregistré chez OVH. Sur mon panel OVH, j'ai modifié les zones DNS de mon domaine.tld comme suit : ns1.domaine.tld (qui redirige vers le paquet DNS Server de mon Synology DS720+ à Madrid) ns2.domaine.tld (qui redirige vers le paquet DNS Server de mon Synology DS918+ à Paris) Je désire utiliser une adresse email contact@domaine.tld qui ne soit PAS hébergée sur mon Synology DS720+ à Madrid. En effet, je préfère utiliser le serveur mail de mon hébergeur OVH. Comment puis-je dès lors spécifier un enregistrement TXT pour la signature DKIM pour ma zone publique dans le paquet DNS Server si je n'utilise pas de serveur mail sur mon Synology ? Merci pour votre aide !