xenonserge: 2019

mercredi 11 décembre 2019

Augmenter et réduire les volumes logiques (LVM) avec le système de fichiers XFS - CENTOS 7

Pour commencer, sachez que le système de fichiers XFS n'est pas prévu pour être diminué de taille.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-xfs

De ce fait, il sera nécessaire de faire un dump du système de fichier de la partition à diminuer avec xfsdump.

Mon système actuel:

$ df -h
Sys. de fichiers        Taille Utilisé Dispo Uti% Monté sur
devtmpfs                  7,7G       0  7,7G   0% /dev
tmpfs                     7,7G       0  7,7G   0% /dev/shm
tmpfs                     7,7G     19M  7,7G   1% /run
tmpfs                     7,7G       0  7,7G   0% /sys/fs/cgroup
/dev/mapper/centos-root    50G     31G   20G  61% /
/dev/nvme0n1p2           1014M    219M  796M  22% /boot
/dev/nvme0n1p1            200M     12M  189M   6% /boot/efi
/dev/mapper/centos-home   873G     11G  862G   2% /home
tmpfs                     1,6G     32K  1,6G   1% /run/user/1000

On va réduire la partition /home et on va augmenter la partition /

Scan des LVM:

# lvscan 
  ACTIVE            '/dev/centos/swap' [7,75 GiB] inherit
  ACTIVE            '/dev/centos/home' [<872,56 GiB] inherit
  ACTIVE            '/dev/centos/root' [50,00 GiB] inherit

Réduire le volume logique /home

On commence par la partition /home qui dispose de 816Go.
On va réduire cette partion à 500Go.

Vérifier le système de fichiers:

# mount | grep home
/dev/mapper/centos-home on /home type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

Le type du système de fichier est XFS. Etant donné que ce système de fichiers n'est pas prévu pour etre diminué en taille, il va falloir adopter la stratégie suivante:

Sauvegarde des données de la partition à réduire
Suppression du volume logique
Recréation du volume logique
Formation de la partition en XFS
Restauration des données

Sauvegarde des données de la partition à réduire:
(Assurer vous d'avoir assez d'espace disque sur la partition cible.)

# xfsdump -l 0 -f /root/home.image /dev/centos/home 
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.1.7 (dump format 3.0) - type ^C for status and control

 ============================= dump label dialog ==============================

please enter label for this dump session (timeout in 300 sec)
 -> 20191211
session label entered: "20191211"

 --------------------------------- end dialog ---------------------------------

xfsdump: WARNING: most recent level 0 dump was interrupted, but not resuming that dump since resume (-R) option not specified
xfsdump: level 0 dump of alien1.local:/home
xfsdump: dump date: Wed Dec 11 15:22:56 2019
xfsdump: session id: 1cbba971-874e-4259-8f64-af9a784abaf0
xfsdump: session label: "20191211"
xfsdump: ino map phase 1: constructing initial dump list
xfsdump: ino map phase 2: skipping (no pruning necessary)
xfsdump: ino map phase 3: skipping (only one dump stream)
xfsdump: ino map construction complete
xfsdump: estimated dump size: 11285116672 bytes

 ============================= media label dialog =============================

please enter label for media in drive 0 (timeout in 300 sec)
 -> home.old
media label entered: "home.old"

 --------------------------------- end dialog ---------------------------------

xfsdump: creating dump session media file 0 (media 0, file 0)
xfsdump: dumping ino map
xfsdump: dumping directories
xfsdump: dumping non-directory files
xfsdump: ending media file
xfsdump: media file size 11282653552 bytes
xfsdump: dump size (non-dir files) : 11278948096 bytes
xfsdump: dump complete: 60 seconds elapsed
xfsdump: Dump Summary:
xfsdump:   stream 0 /root/home.image OK (success)
xfsdump: Dump Status: SUCCESS

L'idéal est de se connecter avec l'utilisateur root sans passer par un utilisateur pour éviter que la partition home soit utilisée, ce qui pourrait empécher un umount.

umount de la partition home

# umount /dev/centos/home

Suppression du volume logique home

# lvremove /dev/centos/home 
Do you really want to remove active logical volume centos/home? [y/n]: y
  Logical volume "home" successfully removed

Création du volume logique home avec une taille de 500Go.

# lvcreate -L 500G -n home centos
WARNING: xfs signature detected on /dev/centos/home at offset 0. Wipe it? [y/n]: y
  Wiping xfs signature on /dev/centos/home.
  Logical volume "home" created.

Formatage de la partition en XFS.

# mkfs.xfs /dev/centos/home 
meta-data=/dev/centos/home       isize=512    agcount=4, agsize=32768000 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=131072000, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=64000, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Monter le volume logique vers /home

# mount /dev/centos/home /home/

Le contenu de la partition /home est vide

# ll /home
total 0

Restaurer les datas précédemment sauvegardés

# xfsrestore -f /root/home.image /home
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.7 (dump format 3.0) - type ^C for status and control
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description: 
xfsrestore: hostname: alien1.local
xfsrestore: mount point: /home
xfsrestore: volume: /dev/mapper/centos-home
xfsrestore: session time: Wed Dec 11 15:22:56 2019
xfsrestore: level: 0
xfsrestore: session label: "20191211"
xfsrestore: media label: "home.old"
xfsrestore: file system id: 42b1e204-4621-4062-83b5-6426aba0dfc3
xfsrestore: session id: 1cbba971-874e-4259-8f64-af9a784abaf0
xfsrestore: media id: 235c086a-c08e-4cdc-b377-d671ab81cf7f
xfsrestore: using online session inventory
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 207 directories and 5099 entries processed
xfsrestore: directory post-processing
xfsrestore: restoring non-directory files
xfsrestore: restore complete: 15 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore:   stream 0 /root/home.image OK (success)
xfsrestore: Restore Status: SUCCESS

Augmenter le volume logique /

Voila, il ne reste plus qu'à étendre le volume logique avec l'espace disque libre.

# lvextend -l +100%FREE /dev/centos/root
  Size of logical volume centos/root changed from 50,00 GiB (12800 extents) to 422,56 GiB (108176 extents).
  Logical volume centos/root successfully resized.

Etendre le système de fichiers XFS pour occuper le volume logique complet.

# xfs_growfs /dev/centos/root 
meta-data=/dev/mapper/centos-root isize=512    agcount=4, agsize=3276800 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=13107200, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=6400, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 13107200 to 110772224

Vérification:

# df -hP /root/
Sys. de fichiers        Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/centos-root   423G     42G  381G  10% /

dimanche 24 novembre 2019

Jeedom avec Docker - configuration réseau et plugin mobile

Comment configurer jeedom avec docker et le plugin mobile, en local et à distance.

Le problème, c'est que le plugin mobile va récupérer les urls dans la configuration réseau de jeedom:

Accès interne: utilisation du port docker 9070 avec http
Accès externe: utilisation du port 443 en https avec traefik

Si le port 9070 est précisé en interne, alors les plugins seront en echec.
En effet, un curl est exécuté sur le serveur web avec l'adresse 127.0.0.1 et le port 9070 non disponible, vu que c'est le port 80 qui est utilisé.

Modification à apporter au container jeedom-server :

Aller dans le container jeedom pour modifier le fichier hosts

Dans /etc/hosts:

127.0.0.1 localhost jeedom.domain.net

Dans /etc/apache2/ports.conf

Listen 80
Listen 9070

service apache2 reload

9070 est le port mappé sur le host avec docker

Dans les paramètres réseaux de jeedom:

J'utilise un resolver interne avec une entree pour jeedom.domain.net

docker-compose pour jeedom avec docker et traefik 2

Voici mon docker-compose:

version: '2.3'

services:

  jeedom-server:
    container_name: jeedom-server
    image: jeedom/jeedom:master
    networks:
     - traefik
     - internal
    labels:
     - "traefik.enable=true"
     - "traefik.http.middlewares.https-only-jeedom.redirectscheme.scheme=https"
     - "traefik.http.routers.jeedom.middlewares=https-only-jeedom"
     - "traefik.http.routers.jeedom.rule=Host(`jeedom.domain.net`)"
     - "traefik.http.routers.jeedom.entrypoints=web"
     - "traefik.http.routers.jeedom-secured.rule=Host(`jeedom.domain.net`)"                                                                                                                                                                
     - "traefik.http.services.jeedom.loadbalancer.server.port=80"
     - "traefik.docker.network=traefik"
     - "traefik.http.routers.jeedom-secured.entrypoints=websecure"
     - "traefik.http.routers.jeedom-secured.tls.certresolver=myhttpchallenge"
    ports:
     - "9070:80"
    volumes:
     - /home/docker/jeedom/data/jeedom:/var/www/html
    depends_on:
     - db
    devices:
      - "/dev/ttyUSB0:/dev/ttyUSB0"
      - "/dev/ttyUSB1:/dev/ttyUSB1"
    mac_address: 03:45:aa:bb:cc:dd
    restart: always

  db:
    container_name: jeedom-mysql
    image: mysql:5.7
    command: --default-authentication-plugin=mysql_native_password
    networks:
     - internal
    volumes:
     - /home/docker/jeedom/data/mysql:/var/lib/mysql
    environment:
     - MYSQL_DATABASE=jeedom
     - MYSQL_USER=jeedom
     - MYSQL_PASSWORD=jeedom_mdp
     - MYSQL_ROOT_PASSWORD=mdp_root
    labels:
     - "traefik.enable=false"
    restart: always

networks:
   traefik:
     external: true
   internal:
     external: false

samedi 16 novembre 2019

Bug client windows Nextcloud - Docker - Traefik

Le client ne veut pas se connecter car l'application doit être autorisé par le serveur NextCloud.
Sauf que le navigateur reste bloqué à :
https://nextcloud.myserver.net/index.php/login/v2/grant.

Le bouton "Grant access" reste inactif.

Dans /home/docker/nextcloud/data/config, modif à faire dans le fichier config.php:

ajout de :

'overwriteprotocol' => 'https',

<?php $CONFIG = array (
...
 'overwrite.cli.url' => 'http://nextcloud.myserver.net',
 'overwriteprotocol' => 'https', 
 'dbtype' => 'mysql',
...

source : https://github.com/nextcloud/desktop/issues/1470

samedi 9 novembre 2019

Installation du driver NVIDIA sur Centos et Redhat 7

Installer le driver NVIDIA sur un Linux Centos 7

$ sudo yum-config-manager --add-repo http://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/cuda-rhel7.repo
$ sudo yum clean all
$ sudo yum -y install nvidia-driver-latest-dkms cuda

source : https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=RHEL&target_version=7&target_type=rpmnetw ork

Traefik 2.0 et https (Let's Encrypt et redirection https)

Utilisation de Traefik 2.0

docker-compose.yaml de traefik:

version: "3.7"

networks:
  traefik:
    name: traefik


services:
  traefik:
    image: "traefik:latest"
    container_name: "traefik"
    networks:
      - traefik
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.useBindPortIP=true"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myhttpchallenge.acme.httpchallenge=true"
      - "--certificatesresolvers.myhttpchallenge.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.myhttpchallenge.acme.email=mail@domaine.com"
      - "--certificatesresolvers.myhttpchallenge.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

Exemple avec un container whoami
Challenge Let's Encrypt http

version: "3.7"

services:

  whoami:
    image: "containous/whoami"
    container_name: "simple-service"
    networks:
      - traefik
    labels:
      - "traefik.enable=true"
      - "traefik.http.middlewares.https-only-whoami.redirectscheme.scheme=https"
      - "traefik.http.routers.whoami.middlewares=https-only-whoami"
      - "traefik.http.routers.whoami.rule=Host(`xxx.domaine.com`)"
      - "traefik.http.routers.whoami.entrypoints=web"
      - "traefik.http.routers.whoami-secured.rule=Host(`xxx.domaine.com`)"
      - "traefik.http.routers.whoami-secured.entrypoints=websecure"
      - "traefik.http.routers.whoami-secured.tls=true"
      - "traefik.http.routers.whoami-secured.tls.certresolver=myhttpchallenge"

networks:
  traefik:
   external: true

Attention, pour la redirection, le nom du middlewares doit être unique.
Pour ma part, je l'ai appelé https-only-whoami
Pour un autre container https-only-container2

Par exemple, dans la capture suivante du dashboard de traefik, ils sont nommés:
https-only
https-only2

vendredi 6 septembre 2019

DAC_READ_SEARCH / DAC_OVERRIDE

J'ai repris un post de l'excellent Dan Walsh afin de bien comprendre la subtilité des "capabilities" et sur les logs AVC DAC_READ_SEARCH et DAC_OVERRIDE que je rencontre.

https://danwalsh.livejournal.com/69478.html

Commençons par un mythe bien connu : ROOT a tous les droits.

L'idée que ROOT possède tous les droits est une erreur. Cela fait quelques années que le noyau Linux a essayé de décomposer les privilèges de root en plusieurs fonctionnalités, les "capabilities".

A l'origine, ils étaient de 32 et sont passés récemment à 64.

Les capabilities donnent la possibilité au programmeur de coder des applications de manière a ce que la commande ping par exemple puisse ouvrir une socket ou httpd puisse ouvrir un port inférieur à 1024, sans utiliser les autres capabilities de root.

SELinux contrôle également l'accès à toutes les fonctionnalités d'un processus.

Un bugzilla courant concerne un processus nécessitant la fonctionnalité DAC_READ_SEARCH ou DAC_OVERRIDE.

DAC (Discretionnary Access Control) signifie un contrôle d'accès discrétionnaire. Cela indique que les droits sur un fichier sont laissés à la discrétion du propriétaire du fichier. En tant que propriétaire du fichier, vous pouvez modifier n'importe quels droits dessus. Dans ce modèle, l'état est non déterminable par l'administrateur. Et root outrepasse tout le contrôle d'accès. C'est le mode par défaut des systèmes Linux/ Unix avec les read-write-execute et users et groups.

Regardons maintenant la puissance des capabilities:

more /usr/include/linux/capability.h
...
/* Override all DAC access, including ACL execute access if
   [_POSIX_ACL] is defined. Excluding DAC access covered by
   CAP_LINUX_IMMUTABLE. */

#define CAP_DAC_OVERRIDE     1

/* Overrides all DAC restrictions regarding read and search on files
   and directories, including ACL restrictions if [_POSIX_ACL] is
   defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE. */

#define CAP_DAC_READ_SEARCH  2

En lisant la description dans le code, cela signifie d’un processus s'exécutant avec l'UID=0 peut lire tous les fichiers du système, même si les flags de permissions n'autorisent pas root de lire le fichier.

De façon similaire, DAC_OVERRIDE signifie qu'un processus peut ignorer les droits de permissions et propriétaires de tous les fichiers d'un système.

Si on voit un message AVC qui requière cet accès, il faut regarder l'UID du processus et bien souvent, ce processus s'exécute avec l'uid=0.

Le réflexe dans la plupart du temps est d'ajouter des autorisations, ce qui est bien souvent une erreur.

Ces AVC indique que vous avez des droits d'accès positionnés pour restreindre l'accès à ces fichiers. Il s'agit souvent de fichiers de configurations.

Prenons l'exemple du processus https ayant besoin de lire le contenu de /var/lib/myweb/content avec comme propriétaire l'utilisateur httpd et les permissions 600.

ls -l /var/lib/myweb/content
-rw-------. 1 apache apache 0 May 12 13:50 /var/lib/myweb/content

Si pour différente raison, le processus a besoin de lire ce fichier et qu'il tourne avec l'UID=0, alors le système va refuser l'accès et générer un DAC_* AVC.

Un simple fix serait de changer les permissions du fichier à 644.

# chmod 640 /var/lib/myweb/content
# chgrp root /var/lib/myweb/content
# ls -l /var/lib/myweb/content
-rw-r-----. 1 apache root 0 May 12 13:50 /var/lib/myweb/content

Cela va permettre à un processus root de lire le fichier en utilisant les droits "other".

Une autre solution serait de changer le groupe du fichier à root et de changer les permissions du fichier à 640.

A présent, root peut lire le fichier en fonction des autorisations du groupe, mais other ne pourra pas le lire.

Il est possible aussi d'utiliser les ACL pour gérer les access.

Au final, il ne s'agit pas d'un problème lié à SELinux, ni d'un problème imposant d'assouplir la sécurité SELinux

Le problème avec SELinux est que le message AVC n'indique pas quel objet du système de fichiers a bloqué l'accès par défaut. La raison est celle de la performance.

Il faut donc activer l'audit complet et régénérer l'AVC afin d'obtenir le chemin de l'objet avec les mauvais contrôles DAC.

# echo "-w /etc/shadow -p wr" >> /etc/audit/audit.rules
# service auditd restart

Ou de façon non permanente:

# auditctl -w /etc/shadow -p w

dimanche 19 mai 2019

Rendre l'antenne BLEA autonome pour Jeedom

Mise en place de systemd sur antenne BLEA pour jeedom. (Raspberry Pi Zero W)

Mon antenne blea:

Avec la configuration suivante, cela permet d'une part de démarrer le deamon blea automatiquement, mais en plus, systemd surveille le process et le redémarre si celui ci tombe, ce qui arrive fréquemment avec ce plugin, certainement lié à l'instabilité du bluetooth.

Dans /etc/systemd/system, ajouter le fichier blearpistart.service

[Unit]
Description=BlEA service
After=hciuart.service

[Service]
Type=simple
PIDFile=/tmp/blead.pid
ExecStart=/home/pi/blearpistart start
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Le fichier blearpistart est un script bash que j'ai positionné dans /home/pi:

#! /bin/sh

# If you want a command to always run, put it here
touch /tmp/blea
chmod 666 /tmp/blea

# Carry out specific functions when asked to by the system
case "$1" in
  start)
    echo "Starting BLEA"
    # run application you want to start
    /usr/bin/python /home/pi/blead/resources/blead/blead.py --loglevel error --device hci0 --socketport 55008 --sockethost "" --callback http://192.168.1.5/plugins/blea/core/php/jeeBlea.php --apikey xxxxxxxxxxxxxxxxxxxxxx --daemonname "antennaBLEA1" >> /tmp/blea 2>&1
    ;;
  stop)
    echo "Stopping BLEA"
    # kill application you want to stop
    sudo kill `ps -ef | grep blea | grep -v grep | awk '{print $2}'`
    ;;
  *)
    echo "Usage: blearpistart {start|stop}"
    exit 1
    ;;
esac

exit 0

La commande python est récupérable en vérifiant les process qui tournent:

pi@antennaBLEA1:/etc/systemd/system $ ps -ef | grep blead.py
root      7778  7775 23 20:02 ?        00:00:15 /usr/bin/python /home/pi/blead/resources/blead/blead.py --loglevel error --device hci0 --socketport 55008 --sockethost  --callback http://192.168.1.5/plugins/blea/core/php/jeeBlea.php --apikey xxxxxxxxxxxxxxxxxxxxxxx --daemonname antennaBLEA1
pi        8243 19986  0 20:03 pts/0    00:00:00 grep --color=auto blead.py

Activer systemd pour le service blearpistart.service

sudo systemctl enable blearpistart.service
systemctl start blearpistart.service
systemctl status blearpistart.service

lundi 8 avril 2019

PODMAN et CNI (Container Network Interface)

Podman permet de gérer vos containers, vos pods, vos images et vos volumes de conteneur, tout ça sans démon.

Cela apporte des avantages indéniables en termes de sécurité, et de flexibilité.
Podman utilise les mêmes commandes que Docker, à quelques exceptions près.

Le lien sur github:
https://github.com/containers/libpod

Exemple de lancement d'un container avec podman:

[root@localhost ~]# podman run --name busybox1 -it --rm busybox
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 46:d8:4e:35:f3:f5 brd ff:ff:ff:ff:ff:ff
    inet 10.88.0.43/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::44d8:4eff:fe35:f3f5/64 scope link
       valid_lft forever preferred_lft forever
/ #

Le pool par défaut du CNI est 10.88.0.0/16

[root@localhost ~]# ip netns list
cni-a8efaeae-04dc-88d4-7cbe-db589c24e362 (id: 0)

Il existe plusieurs types de configurations CNI.

Nous verrons les modes réseaux suivants:

mode bridge
mode portmap
mode host-device

Le lien sur github:

https://github.com/containernetworking/cni

mardi 12 février 2019

Jeedom sous docker avec mysql 5.7

Voici ma conf avec le reverse proxy traefik en utilisant docker-compose:

docker-compose.yml

version: '2'

services:

  jeedom-server:
    container_name: jeedom-server
    image: jeedom/jeedom:stable
    networks:
     - proxy
     - internal
    labels:
     - "traefik.enable=true"
     - "traefik.port=80"
     - "traefik.backend=jeedom-server"
     - "traefik.frontend.rule=Host:jeedom.domain.com"
     - "traefik.docker.network=proxy"
    ports:
     - "9070:80"
     - "9022:22"
    volumes:
     - /home/docker/jeedom/data/jeedom:/var/www/html
    depends_on:
     - db
    devices:
      - "/dev/ttyUSB0:/dev/ttyUSB0"
      - "/dev/ttyUSB1:/dev/ttyUSB1"
    environment:
     - ROOT_PASSWORD=mdpssh
    mac_address: 03:45:aa:15:01:03
    restart: always

  db:
    container_name: jeedom-mysql
    image: mysql:5.7
    command: --default-authentication-plugin=mysql_native_password
    networks:
     - internal
    ports:
     - "3306:3306"
    volumes:
     - /home/docker/jeedom/data/mysql:/var/lib/mysql
    environment:
     - MYSQL_ROOT_PASSWORD=mdp_root_mysql
    labels:
     - traefik.enable=false
    restart: always

networks:
   proxy:
     external: true
   internal:
     external: false

Cette configuration utilise le container jeedom/jeedom et le container mysql:5.7
Dans la doc Jeedom, cela n'est pas précisé, donc pensez au tag 5.7.
Aussi, ne pas démarrer un container avec le mode –privileged , tel qu'on peut le lire dans la doc Jeedom.

La ligne:
command: --default-authentication-plugin=mysql_native_password
est importante, car elle force à utiliser le mode d'authentification natif sur la base MYSQL.
La nouvelle méthode d'authentification utilise le sha-256 pour le hash des mots de passe. https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html

Une précision, à partir de MySQL 5.7, le modèle de sécurité a changé. Il n'est plus possible de se connecter en root autrement qu'en localhost.

On obtient l'erreur suivante:
ERROR 1045 (28000): Access denied for user 'root'@'172.17.0.1' (using password: YES)

Il faudrait accepter tous les clients:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password';

Cette solution n'est pas très secure.

La solution à adopter consiste à rajouter un utilisateur uniquement pour la base de données:

Connexion au conteneur mysql:

[root@powernas1 config]# docker exec -it jeedom-mysql /bin/bash
root@0ba7d5saed2a:/# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 18177
Server version: 5.7.25 MySQL Community Server (GPL)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Vous êtes connectés sur la base mysql, reste à saisir les requêtes sql suivantes:

mysql> SELECT User, Host, authentication_string FROM mysql.user;
+---------------+-----------+-------------------------------------------+
| User          | Host      | authentication_string                     |
+---------------+-----------+-------------------------------------------+
| root          | localhost | *BXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
| mysql.session | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
| mysql.sys     | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
| root          | %         | *BXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
+---------------+-----------+-------------------------------------------+
4 rows in set (0.00 sec)

mysql> CREATE USER 'jeedom'@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON jeedom.* To 'jeedom'@'%' IDENTIFIED BY 'mdp_xxxxxxxxxx';
Query OK, 0 rows affected, 1 warning (0.00 sec)

Changer le mot de passe dans la conf de jeedom:

Dans /home/docker/jeedom/data/jeedom/core/config, modifier le fichier common.config.php

/* * *********************** MySQL & Memcached ******************* */
global $CONFIG;
$CONFIG = array(
        //MySQL parametres
        'db' => array(
                'host' => 'jeedom-mysql',
                'port' => '3306',
                'dbname' => 'jeedom',
                'username' => 'jeedom',
                'password' => 'mdp_xxxxxxxxxx',
        ),
);
?>

Suppression de l'utilisateur root@%

mysql> DROP USER 'root'@'%';
Query OK, 0 rows affected (0.00 sec)

Il est aussi possible de prévoir l'utilisateur de la base jeedom en utilisant les variables d'environnements prévues par le container: https://hub.docker.com/_/mysql

environment:
 - MYSQL_ROOT_PASSWORD=mdp_root_mysql
 - MYSQL_DATABASE=jeedom
 - MYSQL_USER=jeedom
 - MYSQL_PASSWORD=mdp_xxxxxxxxxx