Image docker jeedom/jeedom:4.4-buster - Access denied for user 'jeedom'@'localhost' (using password: YES)

Didier3L · Mars 4, 2024, 5:19

Bonjour la communauté,

J’ai créé un conteneur avec l’image officielle sur docker hub : jeedom/jeedom:4.4-buster
Mais l’installation se passe mal :
On trouve dans le log d’installation et lors d’un acces à jeedom :

Access denied for user 'jeedom'@'localhost' (using password: YES)

@pifou : es tu au courant de ce problème ?

Didier3L · Mars 5, 2024, 3:11

Bonjour @pifou

Sais tu si l’image tien compte de la correction MariaDB vs MySQL identifiée à l’époque ?

pifou · Mars 10, 2024, 9:17

Bonjour,
Le fichier install.sh contient mariadb donc ta suggestion n’est pas implémentée à ce jour. C’est spécifique à ton image ? Je referais le test chez moi, normalement on a le bon client mariadb dans le container donc pas lié.

Tu installe comment, via docker-compose avec la db externalisée dans un autre container je suppose?

Didier3L · Mars 11, 2024, 8:02

Bonjour

Non la BD n’est pas externalisée puisque l’image est censée l’avoir ou l’installer

Voici mon docker-compose

version: '3.1'

networks:
  default:
    external: true
    name: macvlan-224-231

services:
  jeedom:
    container_name: jeedom
    image: jeedom/jeedom:4.4-buster # image officielle  
    privileged: false
    cap_add:
      - SYS_PTRACE 
      - SYS_ADMIN
      - NET_ADMIN # Pour OpenVPN
    tty: true
    hostname: jeedom
    mac_address: a0:ca:ab:cd:ef:06
    networks:
      default:
        ipv4_address: 192.168.1.226

    tmpfs:
       - /tmp/jeedom # chemin dans le conteneur
       
    healthcheck:
      test: ["CMD", "curl", "-fs", "-S", "--max-time", "2", "http://localhost:80"]
      interval: 30s
      timeout: 10s
      retries: 5
    
    restart: unless-stopped
      
    volumes:
      - /usr/share/zoneinfo/Europe/Paris:/etc/localtime:ro
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
      - /volume1/docker/jeedom/html:/var/www/html
      - /volume1/docker/jeedom/db:/var/lib/mysql

#     devices:
#       - "/dev/ttyUSB0:/dev/ttyUSB0"   # MyHome / cp210x
#       - "/dev/ttyUSB1:/dev/ttyUSB1"   # RFLink / ch341-uart
#       - "/dev/ttyACM0:/dev/ttyACM0"   # Zwave / ACM0

    environment:
      PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      PUID: 1026
      PGID: 101

rwaesely · Avril 4, 2024, 3:45

Hello, du nouveau sur le sujet ? J’ai une image docker fonctionnelle en 4.3, et je me demandais si on pouvait relancer un conteneur basé sur le 4.4 avec les mêmes répertoire que ceux montés sur la 4.3 ? A priori je dirai que non, il faut instancier un conteneur vierge 4.4 et restaurer un backup de notre 4.3 dessus, c’est bien ça ?

ludoh · Avril 4, 2024, 4:45

Pour donner le détail, j’ai créé le container de cette facon :

docker run --name Jeedom --runtime runc -v /docker_volumes/jeedom/script:/plugins/script/data:rw -v /docker_volumes/jeedom/html:/var/www/html:rw -v /docker_volumes/jeedom/db:/var/lib/mysql:rw -p 9083:1883/tcp -p 51000:51000/tcp -p 51001:51001/tcp -p 9080:80/tcp --net bridge --restart always -h Jeedom -e ‹ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin › -d -t -i jeedom/jeedom:latest ‹ sh › ‹ /root/init.sh ›

Contrairement à l’image 4.3, j’ai du lancer l’installation à la main :
sudo docker exec -it Jeedom /bin/bash
et ensuite sh /root/install.sh

C’est maintenant ok

Ludo

pifou · Avril 4, 2024, 7:08

Bonjour,
Je ne reproduis pas, à noter qu’il y a beaucoup de redondance dans tes options:

runtime runc (je ne connaissais même pas ce truc)
les ports exposés, à priori le seul utile est le port 80 que tu map sur 9080 sur l’host, mais les autres ports ? Si Jeedom a des démons ça reste à l’intérieur du container, il n’y a pas besoin de l’exposer - mapper - avec l’host…
le volume /plugins/script/data n’existe pas, il faudrait remettre la totale /var/www/html/plugins/script/data (pour les data du plugin script) mais comme tu a déjà le volume /var/www/html, toute l’arborescence est déjà dispo.
-h Jeedom ne sert à rien non plus (pour définir le hostname de la machine mais c’est le nom du container qui te servira)
-e pour la variable d’environnement PATH n’ajoute aucun path supplémentaire il me semble
-t -i c’est pour le mode interactif c’est incompatible avec -d (mode détaché justement), pour notre utilisation il faut garder -d
sh /root/init.sh c’est la commande par défaut il ne sert à rien de la remettre non plus
–net bridge ? je ne sais pas… un alias de --network ?

Bref, au final j’ai réussi à lancer le container avec cette « simple » commande et ça marche quand même!

docker run --name JeedomTest --runtime runc  -p 9080:80/tcp  --net bridge
  --restart always  -h Jeedom
  -e PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
 -d -t -i jeedom/jeedom:latest  sh /root/init.sh

Pour avoir les logs du container que j’ai nommé JeedomTest je fais cette commande:

pi@raspberrypi:~ $ docker logs JeedomTest
Start init
Jeedom is already install
Start atd
Stopping deferred execution scheduler: atd.
Starting deferred execution scheduler: atd.
Starting mariadb
mysql: unrecognized service
Stopping MariaDB database server: mariadbd.
Starting MariaDB database server: mariadbd . . . . . . . . . ..
All init complete
Start apache2
Starting Apache httpd web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.5. Set the 'ServerName' directive globally to suppress this message

admin / admin sur l’IP:9080 de mon rpi4 et ça marche.
Que donne vos logs du container ?

pifou · Avril 4, 2024, 7:16

En vrai, ça n’a aucun intérêt si tu a les reps /var/www/html et celui pour la db partagé sur l’host.
La seule différence entre le container 4.3 et 4.4 c’est la version de Jeedom qu’on a mis dedans. Sauf que, dans le /var/www/html tu va écraser la 4.4 par ta version actuelle 4.3 …

Et même, si tu instancie un nouveau conteneur vierge 4.4, lorsque tu va restaurer ton backup rebelote tu retombe en 4.3 donc… là encore aucun intérêt.

Le seul moyen d’upgrader Jeedom 4.3 => 4.4 c’est via l’upgrade intégré Jeedom.

Par contre, recréer un nouveau conteneur ça prend tout son sens pour upgrader l’OS: 4.3-buster vers 4.3 qui sera donc sur debian bullseye. Ou bien maintenant pour avoir la dernière version 4.4-bookworm (pas encore compatible avec tous les plugins par contre).

ludoh · Avril 4, 2024, 8:12

Merci pour le retour

J’ai auto généré cette commande depuis mon NAS synology (GitHub - nexdrew/rekcod: docker inspect → docker run 🏃)
Effectivement certaines options ne sont pas nécessaires.
Pour les ports, il s’agit de port utilisés par certains plugins (mqtt, SIA, …)

Je vais tenter de récréer le container et vérifier les logs, mais ca a fonctionné en lancant l’install à la main

Ludo

rwaesely · Avril 5, 2024, 7:43

ok donc si j’ai bien compris je recrée un conteneur avec les mêmes mapping de dossier etc sauf que je pointe sur l’image 4.3 bullseye… et je fais l’upgrade dans jeedom vers la 4.4 (toujours dans le conteneur 4.3). Donc j’aurais un conteneur estampillé 4.3 avec un jeedom 4.4 dedans ; on est en ligne ou j’ai mal compris un truc ? XD

mguyard · Avril 5, 2024, 12:14

Hello,

Même souci que @Didier3L.
@pifou il n’y aurait pas une erreur dans le init.sh du container : core/install/OS_specific/Docker/init.sh at 26ff36b1d59152b26c86d54a024486dbf0458632 · jeedom/core · GitHub

On créé un password random à la ligne 42 core/install/OS_specific/Docker/init.sh at 26ff36b1d59152b26c86d54a024486dbf0458632 · jeedom/core · GitHub mais on utilise une autre variable d’env qui n’existe pas. Donc on set le mot de passe à vide alors qu’on set le random dans la config Jeedom

Loic · Avril 5, 2024, 12:18

Bonjour,
Effectivement c’est pas normal, je viens de pousser la correction en alpha ca sera donc dans la prochaine stable

pifou · Avril 5, 2024, 5:30

Pas besoin de recréer un nouveau conteneur du coup, fais la migration dans ton conteneur actuel

Ou sinon, si vraiment tu veux faire un nouveau conteneur, tant qu’à faire tu peux prendre l’image 4.4 puis tu restaure le backup (donc, pendant une fraction de seconde tu aura un conteneur taggé 4.4 mais avec un jeedom 4.3) et hop migration, et retour en jeedom 4.4

rwaesely · Avril 6, 2024, 9:25

bon je fais l’update sur le conteneur actuel comme tu dis. Le jour où ça apportera un plus et je où je suis sûr qu’il n’y a pas de souci de compatibilité avec le nouvel OS, je passerai sur un conteneur avec bullseye

Lemars · Mai 3, 2024, 4:03

J’ai une question de débutant … désolé
j’ai un DS218+ avec Jeedom en Docker : pourquoi faut il que j’utilise une image avec Buster pour creer le Docker ?
Cela vient du DS218+ qui est en Debian 10 (buster) ?
Et qui ne peut accepter Bullseye ?
merci

pifou · Mai 3, 2024, 4:29

Bonjour,
il n’y a pas de question bête c’était en effet un problème d’incompatibilité entre l’OS du syno et mariaDB dans un container Debian 11 … ça date de plus d’1 an, la mise à jour côté synologie a peut être corrigé depuis le temps, si tu peux, essaye avec la version bullseye et dis nous si ça marche mieux maintenant ?

Lemars · Mai 3, 2024, 7:30

Je viens de créer un Docker avec Jeedom 4.3
Capture1
Debian 11
Je viens d’installer le plugin networks et il n’arrive pas à détecter mon tel en wifi alors que sous 4.3 buster mon autre jeedom détecte bien mon tel en wifi
donc le preobleme persiste a priori

C’est que le NAS est encore en Debian 10 ? afin que je comprenne ?
merci

Didier3L · Mai 3, 2024, 7:56

Bonjour

Ce n’est pas la version de Debian qui pose problème
Mais plutôt le noyaux Linux (kernel) choisi par Synology

Lemars · Mai 4, 2024, 6:05

merci de l’info
Chez QNAP il n’y a pas ces soucis ? Pas de restriction sur les ports USB à priori ?