This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

AdGuard Home et OpenVPN


molinadiaz

Messages recommandés

@MilesTEG1 C'est, par intuition, exactement ce que je viens de faire durant les minutes qui se sont écoulées entre mon post et le tien ^^ Résultat des courses : j'ai maintenant mon Vaultwarden (je fais très bien la différence, t'inquiète, j'ai simplement mentionné "Bitwarden" par abus de langage), mon ADG et mon Watchtower qui sont en "stack" avec le label "watchtower". Ce simple label va suffire à mettre à jour automatiquement tous mes containeurs ? Donc à les supprimer puis les recréer dans mon dos sans que je ne me préoccupe plus de quoi que ce soit ? Valable pour Watchtower lui-même ? Est-il possible de watchtowerisé également le Portainer ? Encore merci pour tout !

Lien vers le commentaire
Partager sur d’autres sites

il y a 51 minutes, molinadiaz a dit :

@MilesTEG1 C'est, par intuition, exactement ce que je viens de faire durant les minutes qui se sont écoulées entre mon post et le tien ^^ Résultat des courses : j'ai maintenant mon Vaultwarden (je fais très bien la différence, t'inquiète, j'ai simplement mentionné "Bitwarden" par abus de langage), mon ADG et mon Watchtower qui sont en "stack" avec le label "watchtower". Ce simple label va suffire à mettre à jour automatiquement tous mes containeurs ? Donc à les supprimer puis les recréer dans mon dos sans que je ne me préoccupe plus de quoi que ce soit ? Valable pour Watchtower lui-même ? Est-il possible de watchtowerisé également le Portainer ? Encore merci pour tout !

Oui à tout 😁

watchtower va s’occuper de tout 😊 pour peu que les conteneurs aient bien le label et ils seront mis à jour.

 

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1 Actuellement, j'ai /volume1/docker/portainer que j'ai renommé en /volume1/docker/portainer.old. J'ai donc pu me créer un nouveau /volume1/docker/portainer/data et y placer le contenu de /volume1/docker/portainer.old. Mon docker-compose.yml est le suivant :

version: '3.8'
services:
  portainer:
    container_name: portainer
    image: portainer/portainer-ce:latest
    restart: unless-stopped
    command: -H unix:///var/run/docker.sock
    ports:
      - 9000:9000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /volume1/docker/portainer/data:/data
    labels:
      - com.centurylinklabs.watchtower.enable=true

En SSH, j'ai balancé ceci :

sudo docker run -d -p 8000:8000 -p 9000:9000 --label="com.centurylinklabs.watchtower.enable=true" --restart=unless-stopped --name="portainer" -v /var/run/docker.sock:/var/run/docker.sock -v /volume1/docker/portainer/data:/data portainer/portainer-ce

Je peux rejoindre la WebUI via le port 9000 et m'y connecter. Parfait !.. mais je voudrais que Portainer lui-même soit une Stack de façon à pouvoir update le docker-compose.yml à la volée pour avoir un contrôle total plutôt que de passer par le "container" du menu de gauche qui consiste à paramétrer le conteneur avec les inputs texte de l'application. C'est possible de faire ça ? Je ne sais pas si je me fais comprendre LOUL.

Merci 😉

Modifié par molinadiaz
Lien vers le commentaire
Partager sur d’autres sites

@molinadiaz Salut 🙂

Alors pour Portainer, tu ne pourras jamais l'avoir sous forme de stack dans Portainer lui-même... c'est pas possible vu que tu dois l'installer avec la ligne de commande.

 Par contre, je n'ai pas compris ce que tu veux dire par ça :

Il y a 8 heures, molinadiaz a dit :

pour avoir un contrôle total plutôt que de passer par le "container" du menu de gauche qui consiste à paramétrer le conteneur avec les inputs texte de l'application.

 

J'ai ça pour portainer dans portainer :
lfZStoE.png

 

Sinon pourquoi lancer un docker run pour installer Portainer ?? Et avec le port 8000 ?

Il faut utiliser la commande docker-compose up -d.

Tu te place dans le dossier .../docker/portainer/ qui contient le fichier docker-compose.yml, et tu lances la commande précédente pour créer le conteneur.

Pour l'arrêter docker-compose down.

 

Sinon je ne comprends pas pourquoi tu as cette ligne dans ton yml :

    command: -H unix:///var/run/docker.sock

 

J'ai ceci comme conteneur dans mon docker-compose.yml :

version: "2.1"
services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    hostname: portainer
    network_mode: bridge
    environment:
      - PUID=1000
      - PGID=100
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    volumes:
      - /volume1/docker/portainer/data:/data
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 9000:9000
    restart: always

 

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1

Il y a 4 heures, MilesTEG1 a dit :

Sinon pourquoi lancer un docker run pour installer Portainer ?? Et avec le port 8000 ?

J'avais simplement suivi ce tuto https://www.forum-nas.fr/threads/tuto-installer-portainer-en-docker-sur-un-nas-synology.14030/, je pensais que le port 8000 était absolument nécessaire mais pas vraiment (du moins, pas dans mon cas de figure https://www.reddit.com/r/docker/comments/lbjuyn/port_8000_in_a_dockerstackyml/). Merci de l'avoir souligné !

C'est étonnant, dans ton .yml tu as ta variable d'environnement PUID à 1000. J'avais cru comprendre que le premier utilisateur créé sur un Synology démarrait au PUID 1026. D'ailleurs, j'ai vérifié sur mon système et ça se confirme. Comment t'as fait pour sortir un PUID à 1000 ?

 

Lien vers le commentaire
Partager sur d’autres sites

il y a 5 minutes, molinadiaz a dit :

C'est étonnant, dans ton .yml tu as ta variable d'environnement PUID à 1000. J'avais cru comprendre que le premier utilisateur créé sur un Synology démarrait au PUID 1026. D'ailleurs, j'ai vérifié sur mon système et ça se confirme. Comment t'as fait pour sortir un PUID à 1000 ?

 

Oui tu as raison 🙂 

je mets toujours 1000 comme valeur pour une diffusion internet 🙂 
Il faut mettre la valeur donnée par la commande id user_machin.

Sinon pour ton installation de Portainer, je ne sais pas comment ça va gérer le label de mise à jour... Tu nous diras si ça fonctionne 😉
Mais perso, j'aurais fait une installation via docker-compose.

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1 T'inquiète, j'ai recréé le conteneur avec ton docker-compose.yml, plus propre 😉

Il y a 2 heures, MilesTEG1 a dit :

je mets toujours 1000 comme valeur pour une diffusion internet

Mais du coup, je comprends pas. Avoir un PUID à 1000, ça signifie que seul le user de PUID 1000 peut interagir avec Portainer, non ? Parce qu'il n'y a pas de user à PUID 1000 sur Synology 😮

Je profite de mon post pour revenir à Watchtower. D'après https://www.nas-forum.com/forum/topic/63740-tuto-mise-à-jour-automatique-des-images-et-conteneurs-docker/, j'ai mis les variables d'environnement suivantes dans /volume1/docker/watchtower/watchtower.env :

- WATCHTOWER_NOTIFICATION_EMAIL_FROM=XXX
- WATCHTOWER_NOTIFICATION_EMAIL_TO=XXX
- WATCHTOWER_NOTIFICATION_EMAIL_SERVER=XXX
- WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=XXX
- WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=XXX
- WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=XXX

Sauf qu'avec ce docker-compose.yml (et le fichier .env bien présent dans le dossier) :

version: "2.1"
services:
  watchtower:
    container_name: watchtower
    image: containrrr/watchtower:amd64-latest
    network_mode: bridge
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=100
      - TZ=Europe/Brussels
      - WATCHTOWER_SCHEDULE= 0 0 8 * * *
      - WATCHTOWER_LABEL_ENABLE=true
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_REMOVE_VOLUMES=true
      - WATCHTOWER_NOTIFICATIONS=email
      - WATCHTOWER_NOTIFICATIONS_LEVEL=debug
      - WATCHTOWER_NOTIFICATION_EMAIL_DELAY=2
    env_file:
      - /volume1/docker/watchtower/watchtower.env
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

J'ai ceci lorsque je veux mettre à jour la stack :

EDIT : trouvé ! https://docs.docker.com/compose/environment-variables/#:~:text=env file is placed at,is executed ( %2B1.28 ).

image.thumb.png.235c3919d7bade9a2435f495093e31ff.png

image.png

Modifié par molinadiaz
Lien vers le commentaire
Partager sur d’autres sites

Il y a 1 heure, molinadiaz a dit :

Mais du coup, je comprends pas. Avoir un PUID à 1000, ça signifie que seul le user de PUID 1000 peut interagir avec Portainer, non ? Parce qu'il n'y a pas de user à PUID 1000 sur Synology 😮

J'ai dit que je mettais cette valeur quand je diffusais le contenu du fichier docker-compose.yml sur internet. Je suis probablement un peu trop parano, mais je donne pas les IDs de mes utilisateurs.

Et si tu regardes les fichiers fournis en exemples dans plusieurs dépôts GitHub, tu y trouveras aussi 1000 comme valeur.
Donc non je ne mets pas 1000 dans mon NAS, c'est une valeur différente.

Sache que je crée (quasi tout le temps) un utilisateur dédié pour chaque conteneur, donc avec son propre ID (forcément différent de la valeur 1000 ou de la valeur minimale sur un Syno).

Il y a 1 heure, molinadiaz a dit :

Du coup c'est bon, tu as trouvé comment faire ?
Ça a bien changé avec les dernières version de Portainer... Avant on ne pouvait pas spécifier de fichier .env... 

Du coup moi je met tout dans le fichier 😉

Il y a 2 heures, molinadiaz a dit :

Je profite de mon post pour revenir à Watchtower.

Rhô punaise, j'avais lu "pour revenir à Portainer"... purée, je suis crevé...
Du coup je comprenais pas pourquoi tu mettais les variables d'environnement pour les notifications email... 🤪 🤣

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1 Non mais, en vrai, c'est toi qui a raison. On est jamais trop prudent. Et j'avais mal compris ta phrase aussi concernant la diffusion sur internet. Bref, j'ai édité mon post mentionnant le PUID ^^

Il y a 4 heures, MilesTEG1 a dit :

Sache que je crée (quasi tout le temps) un utilisateur dédié pour chaque conteneur, donc avec son propre ID (forcément différent de la valeur 1000 ou de la valeur minimale sur un Syno).

C'est un bon réflex. Je le fais pour les paquets DSM. J'ai pas songé à le faire pour les containeurs Docker. Ma foi, je vais le faire aussi 😉

EDIT : je dois avoir un soucis de compréhension avec le PUID/PGID contenu dans le docker-compose.yml. À titre d'exemple, j'ai créé un user "vaultwarden" faisant partie du groupe "docker" depuis DSM. J'ai récupéré le PUID/PGID du user et du groupe, et je l'ai inséré dans le docker-compose.yml. En quoi cela isole-t-il mon conteneur du point de vue de la sécurité ? J'y vois pas clair.

En d'autres termes, en admettant un nouveau user "vaultwarden" (PUID 200) du groupe "docker" (PGID 200) créés sur le Syno, dois-je chown -R vaultwarden:docker /volume1/docker/vaultwarden ?

Aussi, j'ai beau avoir spécifié le PUID/PGID du user "vaultwarden" et du groupe "docker"' dans le docker-compose.yml, comment puis-je m'assurer que ce soit bien cet utilisateur qui ait exécuté le conteneur ? @.Shad. @MilesTEG1

Modifié par molinadiaz
Lien vers le commentaire
Partager sur d’autres sites

Il y a 4 heures, molinadiaz a dit :

En d'autres termes, en admettant un nouveau user "vaultwarden" (PUID 200) du groupe "docker" (PGID 200) créés sur le Syno, dois-je chown -R vaultwarden:docker /volume1/docker/vaultwarden ?

 

J'aurais tendance à dire oui 😉

Je viens de regarder de mon coté, et mon groupe d'utilisateur Docker n'est pas précisé dans les permissions des dossiers...
Par exemple sur le dossier vaultwarden j'ai ça :

drwxrwxrwx+ 1 Doc_Vault  users  120 Oct 10 06:05 vaultwarden

APrès pour certains, c'est même :

drwxrwxrwx+ 1 mon_admin        users  290 May 17 20:37 Acme
drwxrwxrwx+ 1 Doc-Git        root   182 Aug  9 23:05 gitea

XD

Là pour le coup je ne suis pas sûr d'être un bon exemple...
Mon groupe d'utilisateur a les accès complets sur le dossier de docker et sur quelques autres dossiers partagés (pour les médias de Plex).

Je pense qu'un jour faudra que je revoie tout ça 🙂

@.Shad. @oracle7 Vous faites comment pour les permissions de votre groupe dédié aux utilisateurs Docker ? Et même chose pour les utilisateurs Docker ?

Il y a 4 heures, molinadiaz a dit :

Aussi, j'ai beau avoir spécifié le PUID/PGID du user "vaultwarden" et du groupe "docker"' dans le docker-compose.yml, comment puis-je m'assurer que ce soit bien cet utilisateur qui ait exécuté le conteneur ? @.Shad. @MilesTEG1

Il me semble que quoiqu'on fasse, l'utilisateur qui exécute le conteneur est le root du NAS. Par contre, les permissions que ce conteneur doit respecter devrait être celle de l'utilisateur spécifié... mais j'en suis franchement pas sûr car il y a des conteneurs qui n'ont pas d'utilisateur à mettre dans le docker-compose... 

Lien vers le commentaire
Partager sur d’autres sites

Je ne sais pas pourquoi vous spécifiez les variables PUID et PGID pour Watchtower et Portainer.
Nulle part dans leur documentation respective cette variable n'est évoquée. Elle n'est donc probablement utilisée nulle part.
Ce sont deux variables qu'on retrouve systématiquement chez Linuxserver, et d'autres qui s'en inspirent.
Ca rend bien service pour les propriétaires de NAS qui ont des contraintes concernant les UID/GID utilisables.

Sur les images qui les prennent en charge, PUID (ou parfois UID) et PGID (ou parfois GID) permettent de mapper un utilisateur du conteneur vers un utilisateur d'UID/GID différent sur l'hôte. On assure ainsi qu'il n'y a pas de problème de permissions qui entrent en conflit avec les permissions UNIX ou ACL, et on ne se retrouve pas avec des UID/GID exotiques sur l'hôte.

Ca ne définit en aucun cas qui exécute le conteneur, par défaut c'est toujours root, sauf si on précise via la directive user l'UID/GID d'un utilisateur.

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1 @.Shad. Ce que j'ai fait, c'est que j'ai créé autant de users qu'il existe de dossiers (et donc de conteneurs) dans mon /volume1/docker. Ainsi :

  • Le user "adguardhome" (du usergroup "docker") est le propriétaire du dossier /volume1/docker/adguardhome, de ses sous-dossiers et de ses fichiers ;
  • Le user "portainer" (du usergroup "docker") est le propriétaire du dossier /volume1/docker/portainer, de ses sous-dossiers et de ses fichiers ;
  • Le user "vaultwarden" (du usergroup "docker") est le propriétaire du dossier /volume1/docker/vaultwarden, de ses sous-dossiers et de ses fichiers ;
  • Le user "watchtower" (du usergroup "docker") est le propriétaire du dossier /volume1/docker/watchtower, de ses sous-dossiers et de ses fichiers

À cela, j'ai chown root:docker /var/run/docker.sock pour permette à tous les users que j'ai cité ci-dessus d'accéder au socket sans passer par le compte root. Tiré par les cheveux ?

Et idéalement, j'aimerais ensuite que :

  • le user "adguardhome" (au lieu de root) soit celui qui exécute le conteneur "adguardhome" ;
  • le user "portainer" (au lieu de root) soit celui qui exécute le conteneur "portainer" ;
  • et ainsi de suite ..

Possible ? Ou je rêve en couleur ? Merci pour votre aide 🙂

Lien vers le commentaire
Partager sur d’autres sites

Il y a 7 heures, molinadiaz a dit :

À cela, j'ai chown root:docker /var/run/docker.sock pour permette à tous les users que j'ai cité ci-dessus d'accéder au socket sans passer par le compte root. Tiré par les cheveux ?

Heu, ça me semble très risqué ça...
À mes débuts avec Docker, @.Shad. m'avait expliqué que le /var/run/docker.sock ne doit être utilisé dans un conteneur que s'il y a un vrai besoin... Pour Portainer, c'est indispensable, mais pour les autres, je ne pense pas... ?

Il y a 7 heures, .Shad. a dit :

Je ne sais pas pourquoi vous spécifiez les variables PUID et PGID pour Watchtower et Portainer.
Nulle part dans leur documentation respective cette variable n'est évoquée. Elle n'est donc probablement utilisée nulle part.
Ce sont deux variables qu'on retrouve systématiquement chez Linuxserver, et d'autres qui s'en inspirent.
Ca rend bien service pour les propriétaires de NAS qui ont des contraintes concernant les UID/GID utilisables.

C'est probablement par habitude des images Linuxserver... 😅

Lien vers le commentaire
Partager sur d’autres sites

@molinadiaz Pour ma part je suis les directives de l'image que j'installe. Si elle prévoit un mappage d'utilisateur comme décrit avant, je m'en sers. Sinon je laisse très généralement root en tant qu'utilisateur exécutant le conteneur. Dans tous les cas root reste l'utilisateur exécutant le service Docker sur le NAS.

Je ne sais pas pourquoi tu as fait ce chown car ça correspond aux propriétés par défaut sur DSM 7 du moins :

permissions_docker.png

Il y a 7 heures, molinadiaz a dit :

Et idéalement, j'aimerais ensuite que :

  • le user "adguardhome" (au lieu de root) soit celui qui exécute le conteneur "adguardhome" ;
  • le user "portainer" (au lieu de root) soit celui qui exécute le conteneur "portainer" ;
  • et ainsi de suite ..

Possible ? Ou je rêve en couleur ? Merci pour votre aide 🙂

C'est possible mais ce n'est pas souhaitable, Docker est conçu pour que ce soit root qui l'exécute, ou alors il faut s'orienter vers Docker rootless, mais ce n'est pas disponible sur les NAS.

il y a 6 minutes, MilesTEG1 a dit :

C'est probablement par habitude des images Linuxserver... 😅

Certes, mais du coup ajouter ces variables dans des images qui ne le prévoient pas n'a pas de beaucoup de sens, même si ça ne présente aucun danger a priori.

Lien vers le commentaire
Partager sur d’autres sites

@MilesTEG1 @.Shad. Si vous avez 5 minutes : https://www.grottedubarbu.fr/docker-touche-pas-groupe/

Ça nous explique pourquoi c'est risky d'avoir un /var/run/docker.sock en root:root 😉 N'hésitez pas à revenir laisser votre avis car j'estime, après lecture, que c'est justement risqué d'avoir un socket en root:root plutôt qu'en root:docker ! Je reste à votre écoute, d'avance merci !

Après y'aura toujours le flag --privileged qui posera question mais bon ..

Disons que je vois pas trop l'intérêt, alors, de créer un user propriétaire par dossier à l'intérieur de /volume1/docker si, dans la finalité, tout sera exécuté par root ! À quoi bon s'emmerder à créer des utilisateurs ? Toute la réflexion démarre de là, non ? 

Modifié par molinadiaz
Lien vers le commentaire
Partager sur d’autres sites

@molinadiaz Je n'ai pas vu sur les versions récentes de socket en root:root, comme je t'ai dit et montré sur DSM c'est en root:docker, pareil sur ma Debian et mes RPi. Je ne dis pas que ça existe pas, mais qu'en tout cas récemment c'est la norme.

Les privilèges élevés sont à éviter autant que faire se peut, je pense même que ça va être déprécié car tu peux arriver au même résultat avec les cap_add et cap_grop, qui permettent d'élever les accès de façon granulaire.

Modifié par .Shad.
Lien vers le commentaire
Partager sur d’autres sites

il y a 7 minutes, .Shad. a dit :

Je n'ai pas vu sur les versions récentes de socket en root:root, comme je t'ai dit et montré sur DSM c'est en root:docker

Ah ? Alors y'a quelque chose que j'ai pas suivi car quand j'avais ls -lart /var/run/docker, j'étais en root:root ! Mais Docker avait été installé depuis DSM 6.2 à l'époque .. peut-être ça ?

EDIT D'ailleurs, je pense même pas que j'avais de groupe "docker" sur mon système. C'est possible ça ? Moi, ce que j'ai fait, c'est que j'ai créé un usergroup "docker" aux côtés de : administrators, http, users et video

image.png.488991998161c81a1c810d680787b52d.png

Modifié par molinadiaz
Lien vers le commentaire
Partager sur d’autres sites

J'ai commencé avec DSM 6 et un groupe docker avait bien été créé.
Mais ce n'est pas une mauvaise idée d'en avoir créé un du coup.
Pour le socket à l'époque je n'avais pas regardé, mais je pense que c'est au moins comme ça depuis la 6.1.

Ce que je n'aime pas avec DSM c'est que le groupe users (auquel appartiennent tous les utilisateurs) a par défaut des accès en lecture seule sur le dossier partagé docker...

Lien vers le commentaire
Partager sur d’autres sites

@.Shad. Ce serait super gentil de ta part, oui ! Je suis vraiment curieux ! Hâte d'avoir un retour. À tester, idéalement, avec une vDSM en 6.2 et une autre directement en 7.0, voir s'il y a une différence ^^ Sinon, j'ai même remarqué que Docker n'apparaissait pas dans la liste des applications depuis Panneau de configuration > Privilèges d'application. Normal, ça aussi ?

Lien vers le commentaire
Partager sur d’autres sites

Hello 🙂

À propos des permissions de docker.sock , moi j'ai ça root:root :

Ilxryfu.png

Je n'ai jamais touché aux permission de docker.sock...
Et Docker est installé depuis un peu plus d'un an maintenant (depuis que j'ai le 920+).

Faut-il que je change les permissions ??

Pour les permissions de mon groupe user : j'ai que des - comme permissions :

LOXD1NU.png

Ça correspond à quoi comme permissions du coup ?

Lien vers le commentaire
Partager sur d’autres sites

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.