Donc c’est pas plus compliqué de faire une VM propre avec un distrib propre … et de restaurer un backup
Quant aux surprises, c’est pas systématique, mais fais déjà un tour sur le forum jeedom, tu verras qu’il y a plein d’exemples
ok,
je vais refaire une installation propre, par contre quelqu’un peut me dire comment on change l’IP de mon Jeedom ainsi que rajouter une port ( actuellement je tourne avec : 192.168.1.22:8088).
Merci pour vos conseils et aides
Hello
Dans les 2 cas, c’est pas jeedom qu’il faut modifier :
- IP => config système ou bail DHCP sur la box
- Port => apache
La question c’est pourquoi le port 8088 plutôt que la conf par défaut en 80 ?
Probablement par des raisons de sécurité ou parce qu’il redirige déjà quelque chose sur du 80 ?!
Ce que je trouve dommage dans Jeedom, c’est l’authentification en http, je comprendrais jamais comment on peut laisser faire çà
Justement je pose la question parce que sécuriser en utilisant autre chose que 80, c’est quasi pareil que de rien faire et mettre autre chose que Jeedom sur la même machine c’est pas idéal quand on fait pas un peu de gestion de sa VM (jeedom est pas vraiment partageur).
Quant à utiliser autre chose que HTTP, c’est bien simple : le pack dns est là pour ça quand on sait pas faire. Sinon on fait soi-même et comme ça nous plait
Le pack DNS active le https ? Moi je n’expose pas jeedom sur le web mais j’aurai bien aimé le passé en https… jamais vu de tuto sur çà
Tu as pas beaucoup cherché pour les 2
Et des exemples de mise en place de https, il a des milliers de sujets à ce propos
De ce que je comprends ce packdns m’impose la création d’une entrée DNS, hors comme je l’ai indiqué je ne souhaite pas exposé Jeedom à l’extérieur, cela ne répond donc pas à mon besoin.
La nuance est dans la rédaction
c’est pas exactement pareil que
Reste les différents sujets qui traitent la mise en place manuelle de https
C’est bien sur ce dernier point que je n’ai rien trouvé d’utile.
Il y a pas 10000 façon de mettre en place le https : l’exposition au final sur le net c’est un détail mineur
Donc n’importe quel tuto marchera
Dans tous les cas, c’est pas le sujet initial du post
Oui j’utilise le port 8088, car je n’utilise pas le pack DNS de jeedom mais ma propre adresse web et il me fallait autre chose que le port 80.
Effectivement c’est pas Jeedom qui gère l’IP et le Port, mais je ne sais plus comment le paramétrer manuellement dans apache .
Et est ce « risqué » de faire comme cela ?
Car je fais pareil : pas de DNS
merci
Voir mon message quelque part un peu plus haut dans la discussion. Ensuite une petite recherche Google et ça devrait aller.
Plus sécurisé qu’avec un port 80 et un dns ?
Probablement autant que la différence entre une 2cv rouge et une verte lors d’un crash test à 200km/h
Du http c’est ce qui existe de moins sûr. Peu importe le port
Le pack dns jeedom ça embarque un vpn malgré son nom
Je ne savais pas qu’il monté un VPN.
Le pack DNS créé un tunnel VPN entre son serveur Jeedom et qui ?
Il utilise quel algo pour le chiffrement ?
Entre ton jeedom et un des serveurs hébergés chez jeedom. Les serveurs jeedom font donc la sécurisation https à ta place.
Quant à l’algo, j’en sais fichtrement rien : c’est ce que propose openvpn
1 « J'aime »
Débat intéressant merci @naboleo pour la qualité de ton contenu.
Pour l’image VM / Docker plutôt que des œufs et une boite d’œufs on pourrait dire que l’image docker c’est un Live CD / USB live et un CD c’est pas fait pour écrire dedans, c’est d’être EN LECTURE avec les données en mode « persistent » à part dans un coin du disque dur.
Comme cela a été dit ce n’est pas faire pour faire de l’apt-get dedans, hors les plugins de Jeedom en sont truffés bien souvent. Apres c’est comme tout, il y a toujours des gens pour détourner les usages des outils.
Pour que docker soit viable il faudrait :
1/ 1 container par protocole
2/ jeedom avec uniquement du mqtt et une image « fixe »
3/ 1 container avec mariadb
4/ un container / service pour la gestion du certificat par exemple
5/ on peut pousser le bouchon avec 1 container php
6/ et un container ngix ou apache
Le tout avec un network dédié « aux 6 oeufs/6 CDs » et un expose que de l’image apache en sortie et du persistent pour les fichiers de paramétrage et pour la base uniquement (pas pour l’ensemble de /var/www hein !)
Jeedom n’a pas du tout cette logique de séparation c’est une solution clé en main monolithe qui convient donc parfaitement pour l’installation sur un OS et donc une VM ou un Pi dédié.
Pour information d’autres solutions ont pris ce type d’orientation.
PS : Si en prime on joue au barbu de service plutôt que Docker pourquoi ne pas passer a kubernetes histoire de faire un versus dans le versus.
1 « J'aime »
Hello
Pas mal l’analogie avec le livecd. C’est exactement ça !
Et tu as bien résumé la structuration idéale si jeedom devait passer sous docker en en suivant les concepts.
Donc après décliner le tout avec k8s, on va encore perdre un peu de monde. Mais l’idée est plaisante ^^
1 « J'aime »
Pourquoi rendre tout compliqué alors qu’il y a plus simple en Docker.
Jeedom sous Docker fonctionne parfaitement sans monter une usine à gaz
Et Docker n’affecte pas les ressources CPU et RAM du Synology à l’inverse de VMM
Hello,
ça n’a rien à voir avec monter une usine à gaz ou pas : docker c’est fait pour organiser des services sans pour autant les rendre dépendants les uns des autres:
Un php + un haproxy … Tu veux changer de proxy, tu mets un nginx à la place… C’est tout !
Donc c’est parfaitement logique de découper en N containers. En plus on s’en contre-fiche du nombre, ça prends pas plus de ressources à faire fonctionner et c’est plus facile à maintenir (montée de version = update de l’image et restart… 5 secondes. ça coupe que ce qui est nécessaire. Point barre). C’est le docker-compose qui fait le boulot de relancer les containers, en gérant l’ordre de lancement, et si besoin les ressources à attribuer
D’ailleurs tu appliques sans savoir exactement le même principe : jeedom d’un coté et son antenne blea de l’autre
Le fait que l’image jeedom marche, c’est juste un usage détourné du principe docker : là ça utilise le container docker comme une VM… ça a un unique avantage : être simple à maintenir (il y qu’un seul install.sh à lancer pour tout le monde Nuc/pi/smart/docker), mais c’est moche/pas conforme/trop lourd à gérer…
Pour finir que docker soit plus performant sous Syno qu’une VM sous Syno, sans doute, mais ça n’empêcherai absolument pas de faire un image jeedom un peu plus dans les standards
1 « J'aime »