Jeedom: latest installation docker

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

J’ai réussi avec la procédure décrite ici :


:slightly_smiling_face:

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: [https://www.haade.fr/blog/tutoriel-domotique-electronique/domotique-smarthome-jeedom-homeassistant/installation-complete-et-securisee-de-jeedom-sur-docker/](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 https://www.haade.fr/blog/tutoriel-domotique-electronique/domotique-smarthome-jeedom-homeassistant/installation-complete-et-securisee-de-jeedom-sur-docker/, j’obtiens :
image

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 [Tuto] Installation de Jeedom sur Synology avec docker en mode Host, 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