[jacobalberty / unifi-docker] comment ne pas exécuter en tant que root

[Spi]

Bonjour à tous,
J'ai réinstallé mon conteneur pour migrer de la version 5 à la 6, je me suis rendu compte que ce dernier était exécuté en tant que root.
Dans l'ancienne version il suffisait de passer les variables “RUNAS_UID0” à false, le tuto que j'avais suivi conseillait aussi de le faire avec “BIND_PRIV” (qui permet d'utiliser des ports sous inférieur à 1024).

Malheureusement la manip ne fonctionne plus et je n'ai pas envie de laisser un conteneur tourner en root. Est-ce que quelqu'un aurait une solution svp? Merci.

[.Shad.]

Tu peux passer sur l'image linuxserver/unifi-controller qui utilise les variables d'environnement PUID/PGID pour déterminer l'utilisateur qui exécute le service.
Sinon on évite d'utiliser de toute façon les ports < à 1024, ils sont souvent utilisés par des processus système.

Pour forcer l'utilisateur quand même sur ton image, il faut passer en ligne de commande ou par docker-compose :

En CLI :

--user uid:gid

en utilisant l'uid et le gid de l'utilisateur/groupe que tu souhaites voir exécuter le conteneur.

Par docker-compose :

user: "uid:gid"

 

[Spi]

Salut @.Shad.,
Je viens de faire le test aujourd'hui et ça fonctionne sans soucis.

Merci pour ton aide!

[StéphanH]

Je rebondis sur ce sujet en tant qu’utilisateur de ce conteneur ...

je crois comprendre que DSM7 ne tolérera plus qu'un conteneur tourne en root. Est-ce exact ?

Du coup, la solution est de ???  :

• Changer d'image : linuxserver/unifi-controller 
• Faire une de ces manipulations (que je ne sais pas faire ...) :

Pour forcer l'utilisateur quand même sur ton image, il faut passer en ligne de commande ou par docker-compose :

En CLI :

--user uid:gid

en utilisant l'uid et le gid de l'utilisateur/groupe que tu souhaites voir exécuter le conteneur.

Par docker-compose :

user: "uid:gid"

[.Shad.]

il y a 29 minutes, StéphanH a dit :

Je rebondis sur ce sujet en tant qu’utilisateur de ce conteneur ...

je crois comprendre que DSM7 ne tolérera plus qu'un conteneur tourne en root. Est-ce exact ?

Tu as une source pour ça ? Je n'ai rien vu de tel.

[StéphanH]

je crois que c'est cette discussion :

https://www.cachem.fr/synology-dsm-7-0-apercu-des-nouvelles-fonctionnalites/

Mais ce n'est qu'un commentaire utilisateur ... 

[.Shad.]

A priori c'est sans fondement, sauf instructions particulières (que tu as citées), Docker exécute un conteneur via l'utilisateur root.
Synology se base de toute façon sur les évolutions du logiciel officiel (avec quelques trains de retard quand même) et font juste en sorte de fournir une interface graphique pour celui-ci.

Par contre Docker a récemment sorti une version "rootless" justement, qui permet l'exécution et l'utilisation de Docker par un utilisateur lambda. Mais aucune garantie que ça n'arrive même un jour sur DSM.

[Spi]

Il y a 9 heures, StéphanH a dit :

Je rebondis sur ce sujet en tant qu’utilisateur de ce conteneur ...

je crois comprendre que DSM7 ne tolérera plus qu'un conteneur tourne en root. Est-ce exact ?

Du coup, la solution est de ???  :

• Changer d'image : linuxserver/unifi-controller 
• Faire une de ces manipulations (que je ne sais pas faire ...) :

Pour forcer l'utilisateur quand même sur ton image, il faut passer en ligne de commande ou par docker-compose :

En CLI :

--user uid:gid

en utilisant l'uid et le gid de l'utilisateur/groupe que tu souhaites voir exécuter le conteneur.

Par docker-compose :

user: "uid:gid"

Pas besoin de passer par Docker Compose, si tu veux je peux te donner les infos.
En gros commence par installer le conteneur et créer un utilisateur spécifique pour lui.

Sinon là je suis en DSM7, mon ancien conteneur en root tournait encore. 🙂

[Jeff777]

Bonjour @.Shad.

J'essaie de dockériser sur le nas mon unifi-controller qui tourne sur mon PC. Je tente en docker-compose.

Peux-tu me préciser comment faire ceci :

Le 22/01/2021 à 10:17, .Shad. a dit :

Par docker-compose :

user: "uid:gid"

 

Modifié le 22 mai 2021 par Jeff777

[.Shad.]

Tu utilises l'uid et gid de l'utilisateur avec lequel tu souhaites exécuter l'application. Je ne sais pas comment tu t'organises pour tes autres conteneurs.

[Jeff777]

Merci @.Shad....je n'ose même pas te dire ce que je croyais avoir compris tellement c'est bête 🙃

[Jeff777]

Bonjour,

J'ai galéré mais j'ai réussi avec:

Le 22/01/2021 à 10:17, .Shad. a dit :

Tu peux passer sur l'image linuxserver/unifi-controller 

Pour ceux qui, comme moi, n'y arriverait pas du premier coup quelques infos pour utiliser docker compose :

Faire un reset de la borne (attendre le clignotement blanc et relâcher)

 Dans /volume1/docker/unifi-controller mettre le docker-compose.yml et créer un répertoire data.

Edit Créer aussi le répertoire unifi dans usr/lib puis data dans usr/lib/unifi.

Créer le container (docker-compose up -d) vérifier dans le log qu'il fini bien par 

[services.d] starting services

[services.d] done.

S'il y a une notification à propos du fichier system.properties la relance du container a solutionner ce problème chez moi (docker-compose down puis docker-compose up -d)

Se connecter sur iplocalenas:8443

Pour que la borne soit détectée bien suivre les instructions du tuto dans Application Setup, à savoir:

Settings > System Settings > Controller Configuration advanced> host for inform : IPlocalenas

cocher la première case : Override inform host

Pour adopter la borne :

Se connecter en SSH sur la borne (IPlocale borne, port 22) utilisateur et mot de passe 'ubnt' (edit : ou dans la section SSH de Settings/System settings/advanced si déjà configuré)

commande : set-inform http://iplocalenas:8080/inform  (edit : rafraichir et patienter jusqu'à la proposition d'adopter le borne)

 

Modifié le 19 mars 2023 par Jeff777

[oracle7]

@Jeff777

Bonjour,

Merci beaucoup pour ce récapitulatif bien utile.

Juste une question : tu ne crains pas que les répertoires /usr/lib/unifi et /usr/lib/data ne disparaissent avec une mise à jour de DSM ?

Cordialement

oracle7🥴

 

[Jeff777]

Il y a 7 heures, oracle7 a dit :

Juste une question : tu ne crains pas que les répertoires /usr/lib/unifi et /usr/lib/data ne disparaissent avec une mise à jour de DSM ?

Je n'en sais rien et je ne sais pas à quoi sert le répertoire usr/lib/unifi/data (que j'ai créer suite à la notification) qui curieusement est vide. Le fichier system.properties se trouve dans le répertoire /volume1/docker/data . Je te dirai à la prochaine MàJ.

(J'ai oublié de dire que mon DSM sur ce NAS est DSM7)

Modifié le 23 mai 2021 par Jeff777

[.Shad.]

Je n'ai jamais eu besoin de créer autre chose que le dossier config pour les données du conteneur Unifi basé sur l'image de Linuxserver. Où as-tu vu une notification qui te le demande ?

[Jeff777]

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

Où as-tu vu une notification qui te le demande ?

Au premier lancement du docker-compose dans les logs de unifi_controller dans portainer il était signalé une erreur :

le fichier sytem.properties n'avait pas pu être enregistré dans /usr/lib/unifi/data/ qui n'existait pas.

 

Modifié le 23 mai 2021 par Jeff777

[.Shad.]

Un conteneur ne te donnera jamais d'infos dans ses logs ni où que ce soit relatives à un chemin sur le NAS. Uniquement au sein du conteneur. Donc si tu as créé ce dossier sur le NAS c'est logique qu'il soit vide.

Un conteneur n'a aucune idée de l'arborescence de son hôte, jamais.

[Jeff777]

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

Un conteneur ne te donnera jamais d'infos dans ses logs ni où que ce soit relatives à un chemin sur le NAS

Ben en tout cas c'est bien ici que j'avais le commentaire sur le fait que system.properties n'avait pas pu être enregistré dans /usr/lib/unifi/data :

[.Shad.]

Oui mais ce que je veux dire c'est que ce chemin concerne le conteneur et pas le NAS.

Donc créer ce dossier sur le NAS ne fera rien. 🙂

[Jeff777]

Ah j'ai encore beaucoup de choses à apprendre sur docker 😄

Donc il faut que je crée un volume dans le docker-compose ?

comment je fais, comme cela ? :

- /usr/lib :/unifi/data

En fait je ne suis pas certain que ce soit utile puisque ça fonctionne sans cela et j'ai un fichier system.properties dans /volume1/docker/unifi-controller/data.

[.Shad.]

Je te dis j'ai jamais eu besoin de créer ce dossier. Simplement celui pour les fichiers de configuration stipulé dans la doc.

[Jeff777]

Bon je corrige mon post.

 

[Dimebag Darrell]

Bonjour tout le monde,

J'ai trouvé ceci, je ne sais pas si vous avez eu l'occasion de tester cette procédure

https://github.com/jacobalberty/unifi-docker/commit/d3da6bf047f741fd62720b0322ebe4f933a76740

``yaml
version: '2.3'
services:
  mongo:
    image: mongo:3.6
    # container_name: ${COMPOSE_PROJECT_NAME}_mongo
    container_name: unifi_mongo
    networks:
      - unifi
    restart: always
    volumes:
      - db:/data/db
      - dbcfg:/data/configdb
  controller:
    # image: "jacobalberty/unifi:${TAG:-latest}"
    image: jacobalberty/unifi:latest
    # container_name: ${COMPOSE_PROJECT_NAME}_controller
    container_name: unifi_controller
    depends_on:
      - mongo
    init: true
    networks:
      - unifi
    restart: always
    volumes:
      - dir:/unifi
      - data:/unifi/data
      - log:/unifi/log
      - cert:/unifi/cert
      - init:/unifi/init.d
      - run:/var/run/unifi
      # Mount local folder for backups and autobackups
      - ./backup:/unifi/data/backup
    user: unifi
    sysctls:
      net.ipv4.ip_unprivileged_port_start: 0
    environment:
      DB_URI: mongodb://mongo/unifi
      STATDB_URI: mongodb://mongo/unifi_stat
      DB_NAME: unifi
      TZ: Europe/Stockholm
    ports:
      - "3478:3478/udp" # STUN
      - "6789:6789/tcp" # Speed test
      - "8080:8080/tcp" # Device/ controller comm.
      - "8443:8443/tcp" # Controller GUI/API as seen in a web browser
      - "8880:8880/tcp" # HTTP portal redirection
      - "8843:8843/tcp" # HTTPS portal redirection
      - "10001:10001/udp" # AP discovery
  logs:
    image: bash
    # container_name: ${COMPOSE_PROJECT_NAME}_logs
    container_name: unifi_logs
    depends_on:
      - controller
    command: bash -c 'tail -F /unifi/log/*.log'
    restart: always
    volumes:
      - log:/unifi/log
volumes:
  db:
  dbcfg:
  data:
  log:
  cert:
  init:
  dir:
  run:
networks:
  unifi:
```

Il semblerait qu'il propose un db séparée pour le controller

Modifié le 8 novembre 2022 par Dimebag Darrell

[firlin]

Pour ma part moi j'ai appliqué ce tutos, par contre je suis pas passer en 7.xx

 

[Jeff777]

Il y a 13 heures, firlin a dit :

je suis pas passer en 7.xx

Bonjour,

Avec tout ce qui est dit ci-dessus ça fonctionne avec DSM 7.1-42962  

version: "2.1"
services:
  unifi-controller:
    image: ghcr.io/linuxserver/unifi-controller
    container_name: unifi-controller

    environment:
      - PUID=1033
      - PGID=100
      - MEM_LIMIT=1024M #optional
    volumes:
      - /volume1/docker/unifi-controller:/config
      - /etc/localtime:/etc/localtime:ro

    ports:
      - 3478:3478/udp
      - 10001:10001/udp
      - 8080:8080
      - 8443:8443
      - 1910:1910/udp #optional
      - 8843:8843 #optional
      - 8880:8880 #optional
      - 6789:6789 #optional
      - 5514:5514/udp #optional
    networks:
         unifi-controller:
#            ipv4_address: 172.23.0.2
    labels:
      - "com.centurylinklabs.watchtower.enable=true"
    restart: unless-stopped
    
networks:
    unifi-controller:
        external: true