Bonjour à tous depuis peut le tag latest sur docker est régulièrement mis à jour avec alpha, j’ai essayé de l’installer mais je rencontre des soucis de droits root dès l’installation de jeedom sur la base de donnée et une fois l’installation terminé les droits root restent en orange dans l’onglet santé.
J’ai tout tenté chown chmod sur dossier et ficher ainsi que la remise à plat des droits sur OS_DB mais rien y fait.
Quelqu’un à réussit à contourner ce problème ?
Hello,
J’ai tenté d’installer Jeedom récemment sur Docker, sans y arriver. J’arrive sur la page web, la config SQL se passe bien, puis j’arrive sur la page d’authentification et là j’ai une erreur 404.
Pourtant, je l’ai utilisé sous Docket pendant quelques années avant de passer sur Raspberry. Mais là je voulais en monter un second pour pour se surveiller l’un l’autre avec le plugin Link.
Affaire à suivre
Pour la procédure en jeedom:master il n’y a pas de soucis tu peux suivre ce tuto et s’il manque quelque chose dite le moi: [Installation complète et sécurisée de Jeedom sur docker » Haade.fr](http://installation complète jeedom sur docker).
Cependant avec la version latest je rencontre toujours des soucis de droits et je n’arrive pas à changer les fichiers concernés qui ne semble pas être les mêmes qu’avec le tag master.
1 « J'aime »
Bonjour, j’ai suivi le tuto et plein d’autre mais impossible d’avoir un jeedom fonctionnel sous omv4 et docker.
En suivant le tuto Redirecting…, j’obtiens :
Et voici le log consistency :
[START CONSISTENCY]
[START CHECK AND FIX DB]
[END CHECK AND FIX DB]
Check jeedom database...OK
Check filesystem right...chmod: changing permissions of '/var/www/html/core/class/../../..': Operation not permitted
OK
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
sh: 1: cannot create /etc/systemd/system/mariadb.service.d/jeedom.conf: Directory nonexistent
sh: 1: cannot create /etc/systemd/system/mariadb.service.d/jeedom.conf: Directory nonexistent
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
[END CONSISTENCY]
Pour le sudo, le rétablissement des droits des dossiers et fichiers dans l’interface de jeedom n’y change rien, mais les lignes de commandes à la fin de ce tuto le règle https://community.jeedom.com/t/tuto-installation-de-jeedom-sur-synology-avec-docker-en-mode-host/5290, mais ce n’est que temporaire, un redémarrage du containter suite à une coupure de courant par exemple et tout est effacé.
Avez vous une solution pour les poblèmes sudo et de démarrage svp ?
Merci
Avec une installation Docker sur Synology, on ne perd pas la configuration après un redémarrage du conteneur …
Comme sur omv, mais je ne parle pas de la configuration qui est stocké dans le volume de donnée /var/www/html mais de tous les changement apportés dans les autres répertoires stockés dans la partie volatile.
Je vais encore faire des essais pour les droits root mais est-ce que vous avez une idée du problème ou une piste pour le demarrage NOK ?
Edit: Je vais ouvrir un nouveau sujet pour plus de clareté.
En fait, tout dépend comment est configurer le lancement du container.
Par défaut, le conteneur, lorsqu’il est stoppé est simplement arrêté. un docker container start <conteneur_name> va relancer le conteneur arrêté, en conservant les modifications.
Si on lance le conteneur avec un docker container run <conteneur_name>, il va râler car le conteneur existe déjà.
Si le conteneur est lancé avec docker container run -rm <container_name> le conteneur sera supprimé sur sur docker container stop ou kill.
Dans le cas d’un docker-compose; docker-compose down va supprimer la stack (conteneurs compris) alors qu’un docker-compose stop va stopper les containers en les stoppants uniquement et en gardant les networks, etc…
Ne pas oublier qu’un conteneur est un élément « Jetable ». Il n’est pas destiné à être conservé. Surtout dans les cas d’utilisation avec orchestration (swarm, K8s, etc…). Par conséquent, il faut pensé à faire une image de la configuration finale (mais c’est assez lourd, et pas forcément recommandé de toute façons), soit scripter le lancement (avec réinstallation des dépendances, etc…)
Par exemple, on peut avoir un docker-entrypoint.sh dans le genre :
#!/bin/bash
echo "=================================="
echo " Application Name : JEEDOM"
echo " Dockerfile version : $DOCKERFILE_VERSION"
echo "================================="
echo ' ==> Start container init'
hostIpAddress=$(curl -s ifconfig.me)
echo " - Hostname : $HOSTNAME"
echo " - IP Address : $(ifconfig eth0 | grep 'inet' | cut -d " " -f 10)"
echo " - Host IP Address : $hostIpAddress"
if [ -f /var/www/html/core/config/common.config.php ]; then
if [ ! -z $JEEDOM_BDD_SVC_SERVICE_HOST ] ; then
echo "[INFO] Change IP address of the database in case of service ip adress change"
sed -i -e "s/^.*'host'.*$/ 'host' => '$JEEDOM_BDD_SVC_SERVICE_HOST',/g" /var/www/html/core/config/common.config.php
fi
fi
# Mandatory - Wrong default values
sed -i -e "s/^max_execution_time = 30$/max_execution_time = 600/g" /etc/php/7.3/apache2/php.ini
sed -i -e "s/^upload_max_filesize = 2M$/upload_max_filesize = 1G/g" /etc/php/7.3/apache2/php.ini
sed -i -e "s/^post_max_size = 8M$/post_max_size = 1G/g" /etc/php/7.3/apache2/php.ini
# Apache configuration
chown www-data:www-data /var/lib/php/sessions
# Update plugins dependencies
if [ ! -f .dependencies_installed ] ; then // En cas de redémarrage, le fichier sera présent, pas d'installation
updateDependencies.sh // Lancement des dépendances
fi
echo ' ==> Container Init finished'
echo
echo
"$@"
et le scripts des dépendances
#!/bin/bash
PLUGINS_DIRECTORY="/var/www/html/plugins"
CMD="/bin/bash"
mkdir -p /tmp/jeedom
echo "[INFO] Dependencies installation" > .dependencies_installed
if [ -d $PLUGINS_DIRECTORY/alexaapi ] ; then
echo
echo "================================================="
echo "[INFO] Instalation des dependances alexaapi"
echo
$CMD $PLUGINS_DIRECTORY/alexaapi/resources/nodejs.sh $PLUGINS_DIRECTORY/alexaapi/resources "" 0
echo "================================================="
echo "Dependencies for alexaapi" >> .dependencies_installed
fi
cd ${PLUGINS_DIRECTORY}
declare -a files="$(find -name install_apt.sh)" // Recherche de tous les plugin avec un script install_apt.sh (Merci pour la normalisation d'ailleurs)
for file in $files
do
pluginDir="${file%/$(basename $file)}"
pluginName=$(basename ${pluginDir%/$(basename $pluginDir)});
echo
echo "================================================="
echo "[INFO] Dependencies for $pluginName"
echo
$CMD $file /tmp/jeedom/${pluginName}-dependance
echo "Dependencies for alexaapi" >> .dependencies_installed
done
cd -
# Configure Https
if [ ${USE_HTTPS:-} == "true" ] ; then
echo "[INFO] Configuring HTTPS with HTTP-01"
cd /etc
wget https://dl.eff.org/certbot-auto
chmod a+x ./certbot-auto
echo "./certbot-auto --apache -n -d ${DOMAIN_NAME} --email ${CERTBOT_EMAIL} --agree-tos --redirect"
./certbot-auto --apache -n -d ${DOMAIN_NAME} --email ${CERTBOT_EMAIL} --agree-tos --redirect
cd -
Cela prend un peu de temps au démarrage, mais au moins tous est clean au démarrage. C’est beaucoup plus clean avec un orchestrateur de type Kubernetes. avec 2 ou 3 pods on peux facilement gérer avec un load balancer et une répartition de la mise a jour ou du redémarrage de la stack (canary, half, etc…)
Tu utilise bien l’image docker
docker pull jeedom/jeedom:master
Bonjour,
j’ai testé cette commande et j’ai l’erreur manifest:
$ docker pull jeedom/jeedom:latest
Error response from daemon: manifest for jeedom/jeedom:latest not found: manifest unknown: manifest unknown
par contre ça marche avec le tag :beta par exemple, pourquoi ne peut-on pas pull la dernière version?
Autre question, on peut faire du docker sur un pi3+ ?
@pifou Docker Hub
en allant sur le hub docker on voit une erreur, c’est « lastest » qu’il faut utiliser, probablement ça?
latest est le tag par défaut, même si je ne le spécifie pas c’est celui que git recherche:
$ docker pull jeedom/jeedom
Using default tag: latest
Error response from daemon: manifest for jeedom/jeedom:latest not found: manifest unknown: manifest unknown
Par contre, en effet si je force le tag lastest il le trouve 
Je suppose que la branche master n’est pas à jour et c’est la branche par défaut qui porte ce tag par défaut…
Pour ceux qui suivent ce post et pas l’autre: