AdGuard Home et OpenVPN

[molinadiaz]

@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 !

[MilesTEG1]

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.

 

[molinadiaz]

@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 😉

[MilesTEG1]

@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 :

 

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

 

[molinadiaz]

@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 ?

 

[MilesTEG1]

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.

[molinadiaz]

@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 ).

[MilesTEG1]

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 :

'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 ).

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... 🤪 🤣

[molinadiaz]

@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

[MilesTEG1]

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... 

[.Shad.]

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.

[molinadiaz]

@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 🙂

[MilesTEG1]

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... 😅

[.Shad.]

@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 :

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.

[molinadiaz]

@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 ? 

[.Shad.]

@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.

[molinadiaz]

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

[.Shad.]

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...

[molinadiaz]

Attends ! Le groupe "docker" avait été créé sur ton Synology, dans les Utilisateurs locaux aux côtés des groupes administrators, users, http et video, et ce à l'installation de Docker depuis le Centre de paquets ? Tu l'as pas créé manuellement ? o_O !

[.Shad.]

De souvenir oui, je peux me tromper, je testerai avec un vDSM pour ne pas dire de bêtise. 😉 

[molinadiaz]

@.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 ?

[MilesTEG1]

Hello 🙂

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

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 :

Ça correspond à quoi comme permissions du coup ?