D’après ce que je vois dans tes logs, il n’y a pas d’erreur sur l’installation et le démarrage des containers.
C’est étonnant puisque tu dis avoir déjà un container avec ce nom.
Le broker mqtt est lancé sur le port 1884 pour ne pas entrer en conflit avec celui du service MQTT.
Si j’ai bien compris, @pierre-gilles préférait un broker séparé.
Du coup, pour ton problème de connexion, peux-tu regarder les logs des 2 containers du service ?
J’ai oublié de vous dire qu’on peut voir physiquement si la configuration du service a bien fonctionné : au démarrage, la led du dongle devrait s’éteindre.
Autre chose, il y a un bonus caché dans un des onglets. Un bon point à celui qui le trouve…
Hello, d’abord je souhaite te remercier pour ton taff, ça va être cool de pouvoir se passer d’une passerelle Xiaomi
J’ai cependant un problème de droit sur mon installation, le conteneur MQTT démare bien mais redémarre en boucle, car il n’arrive pas à ouvrir son fichier de conf (log du conteneur mqtt : 1605448659: Error: Unable to open config file /mosquitto/config/mosquitto.conf.).
J’ai pourtant bien le mapping $DATA_PATH/gladys_zigbee:/var/lib/gladysassistant dans mes volumes et j’ai également forcé Gladys a utilisé l’user root (user: “0:0”) dans mon fichier docker-compose mais rien n’y fait…
OK je regarde ça ce soir, mais le problème c’est que comme le conteneur existe déjà, il n’est pas configuré pour le conteneur mqtt créé par le service.
Ce doit être une question de droits.
Vérifie que les droits sur le fichier /var/lib/gladysassistant/zigbee2mqtt/mqtt/mosquitto.conf.
Dans le container mqtt, l’utilisateur n’est pas root mais mosquitto. Ce pourrait être le problème.
Les droits sur le fichier sont bien en root/root et avec la valeur 644 que j’ajoute ou non dans mon docker-compose la valeur user: "0:0".
Du coup il y aurait un moyen de spécifier au conteneur MQTT l’utilisateur à utiliser ? (si il le même que celui de Gladys ça faciliterait la chose je pense et ça éviterai ce genre de soucis à l’avenir).
EDIT : ou bien d’utiliser une image alternative ?
Dans mon cas sur des test précédant j’utilisais l’image eclipse-mosquitto qui est si mes souvenirs sont bons en root par défaut (même si c’est pas top forcément niveau sécu…)
D’un point de vue sécurité, il n’est absolument pas conseillé de lancer les containers en tant que root !
Pourquoi lances-tu Gladys de cette façon ?
L’exemple de la doc ne le fait pas. Par contre, l’option privileged est utilisée.
C’est bien l’image eclipse-mosquitto qui est lancée et elle n’utilise pas l’utilisateur root. Aucune image bien faite, d’ailleurs…
Pour l’utilisation du root, c’était juste un test (ce n’est pas comme ça que je le lance habituellement) pour voir si l’ajout d’un user changeait les droits sur le fichier de config de mosquitto mais cela ne change rien.
Ça doit donc venir de HypriotOS alors, puisque l’ensemble des fichiers de Gladys sont créés par root…
Dommage j’aimais bien cette distri légère avec un simple docker dessus…
Normalement, le propriétaire du répertoire mqtt devrait être 1883:1883 sur l’hôte et mosquitto:mosquitto dans le container.
Il faut que tu relances le container sans l’utilisateur root mais avant, il faut nettoyer ce qui a été généré par l’install précédente :
Il s’agit bien du conteneur sans l’utilisateur root et avec nettoyage au préalable, je pense que par défaut sur HypriotOS, l’utilisateur qui a les droits sur Docker est root, j’ai beau lancer n’importe quel conteneur, les données en persistances sont toujours root…
J’ai pas pu tester plus car il faudra gérer cette erreur ( renvoyé l’info dans l’UI )
2020-11-15T18:05:02+0100 <error> installMqttContainer.js:43 (Zigbee2mqttManager.installMqttContainer) MQTT broker failed to install as Docker container: Error: (HTTP code 500) server error - toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit
at /src/server/node_modules/docker-modem/lib/modem.js:257:17
at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:284:9)
at IncomingMessage.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1223:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
reason: 'server error',
statusCode: 500,
json: null
}
ça ne m’était pas encore arrivé, quoi qu’il en soit j’avais pas l’info qu’un truc se passer mal
Tu peux faire un “docker login” sur l’hôte de ton docker, ça permet de se connecter au Docker Hub qui maintenant nécessite une authentification car il y a une limite sur le nombre de pull depuis ce Docker Hub…
J’ai dû bricoler pour avoir les 3 conteneurs qui tournent, impossible d’avoir le conteneur zigbee2mqtt ( j’ai du virer les pass sur la conf mqtt pour pouvoir utiliser mon ancien conteneur , bref )
Du coup normalement c’est bon car coté status
Par contre dans les logs:
Edit: ça a fini par fonctionner
Bien jouer @Reno , j’ai jamais été aussi content de voir mes sensors sur le dashboard