Démarrage NOK car port interne (réseau) != port local (docker)

Bonjour,

J’ai un problème en tentant d’installer MQTT Manager pour les besoins d’un plugin. J’utilise déjà jMQTT et je suis confronté au même problème que j’avais eu à l’époque pour ce plugin.

J’ai un Mosquitto externe. Mon accès Jeedom externe est 192.168.XX.XX:9080, mon Docker contenant Jeedom est en réalité sur 127.0.0.1:80, il y a une translation de port 9080->80. Lorsque je démarre le démon, j’ai droit à un échec :

Callback error.Please check your network configuration page : {« errno »:-111,« code »:« ECONNREFUSED »,« syscall »:« connect »,« address »:« 127.0.0.1 »,« port »:9080} ».

Ce qui est normal, car localement, le port 9080 n’existe pas, uniquement le port 80.

En attendant que Jeedom différencie Accès interne (réseau local) et Accès interne (docker), il faudrait pouvoir préciser l’IP et le port de callback dans les options. Ce qu’on a du faire avec le plugin jMQTT.

Bonjour,

Ou alors vous changez la config de votre container pour exposer le port 80 et pas 9080 et/ou vous passez le reseau en macvlan (ou host)
Parce que vous allez avoir le même problème avec tous les plugins qui ont un démon

Le port 80 est déjà pris ailleurs, donc le mode host n’est pas possible et l’usage macvlan me demandera trop de changement dans mon installation historique. C’est uniquement la 2e fois que je suis confronté à ce problème, pourtant j’ai 52 plugins^^

Après je trouve que le plugin ne suit pas mon accès interne, car j’ai 192.168.X.X:9080 et le plugin attaque en 127.0.0.1:9080, s’il attaque en 192.168.X.X:9080, je n’aurais pas eu de souci.

En attendant, j’ai modifié en dur le --callback vers http://127.0.0.1/plugins/… dans le mqtt2.class.php. Tout fonctionne.

Slt, quelle adresse est renseigné dans IP interne de jeedom dans les paramètres de Jeedom ?

Tous les plugins que j’ai vu n’utilisent jamais la config accès interne pour la communication avec le démon mais toujours localhost.
Et cela me semble préférable (par exemple cela permet de restreindre l’accès api sur localhost) donc c’est normal pour moi.

En fait vous n’avez pas besoin d’aller configurer votre ip lan 192… dans l’accès interne. Pourquoi avoir fait ça ?

En effet, mais en l’occurrence le problème est le port : Jeedom étant accessible sur le port 9080 en dehors de Docker, @defmy mets 9080 comme port local/interne, or Apache tourne bien sur le port 80. Mqtt2 se basant sur le port interne, il y a un problème…

J’ai bien compris ca :wink:

reste à savoir pourquoi il y a besoin de configurer ip et port « lan » dans la config interne au lieu de l’ip & port réel (« container »)

Mon Jeedom était sur un Rapsberry avant de passer sur Docker, je me suis jamais posé la question.

Pour moi accès interne, ça a toujours était de savoir comment joindre Jeedom dans le réseau local (chez moi). Effectivement mon Jeedom est bien joignable en http://192.168.X.X:9080. L’accès externe confirme mon compréhension, chez moi c’est https:NOM_DE_DOMAINE:443
L’application mobile utilise d’ailleurs cette notion pour savoir comment joindre Jeedom. Dire qu’il n’est pas nécessaire de mettre l’IP LAN dans l’accès interne est sans doute faussé. De plus, si je me base sur la documentation, ça dit : « Accès interne : informations pour joindre Jeedom à partir d’un équipement du même réseau que Jeedom (LAN) ».
D’ailleurs il y a pas de sens de mettre l’IP du Docker dans accès interne, puisqu’elle est dynamique et changeante à tout moment.

Après je peux comprendre qu’utiliser 127.0.0.1 par défaut c’est sécurisant mais on a déjà une fonction « Accès API » pour restreindre l’accès à l’API d’un plugin.

En utilisation network::getNetworkAccess(‹ internal ›, ‹ proto:127.0.0.1:port:comp ›) on récupére le port de l’accès interne et on force à 127.0.0.1, pourquoi ne pas laisser à network::getNetworkAccess(‹ internal ›) pour récupérer l’IP et le port de l’accès interne ?

Il est vrai que je n’utilise pas le même port sur le Docker et l’hôte, mais c’est le fonctionnement même de Docker. Ici j’ai laissé le port 80 défini par l’équipe de Jeedom et Docker me donne le choix de mon déploiement sur mon réseau, j’ai fait un autre choix de port car le port 80 était déjà utilisé par un autre service.

Maintenant, j’aimerais bien que @Loic éclaircisse la situation. Est-ce moi qui sort du cadre de fonctionnement ? Je m’adapte sans problème, ce que j’ai déjà fait. Est-ce à Jeedom de prendre en charge cette situation ? ou c’est à chaque développeur de trouver une solution individuellement ? Ce qu’on avait fait avec le dev de jMQTT en proposant de personnaliser l’adresse de callback.

j’ai le meme probleme que vous a priori

Pas tout à fait, ton adresse de callback semble bon. Ton problème c’est parce que Mosquitto n’est pas exécuté, donc le démon MQTT Manager plante, il faut voir pourquoi. Je ne peux pas t’aider, mon Mosquitto est installé ailleurs et non en local.

merci,
mais sauriez vous me dire comment savoir si mosquitto est bien installé ? A bien démarrer ?