Actuellement, mon installation de Home Assistant est sur une machine virtuelle qemu que je gère donc avec Virtmanager, sur une machine qui tourne sous Debian Buster.
Sachant que je gère actuellement le réseau avec systemd-network, est-ce que ça peut valoir le coup que je change pour network-manager pour en suite passer à une installation en supervised ? Sachant que je fais déjà tourner des containers Docker, du coup à part network-manager tout semble être bon pour accueillir HA supervised.
à savoir : je fais déjà tourner un serveur samba ainsi que SSH sur cette machine.
Je l’utilise également pour faire tourner un serveur web (Nginx) et MiniDLNA pour pouvoir regarder des vidéos avec des Chromecast avec Google TV.
Est-ce que tout ce qui est déjà là risque de poser problème pour cette migration dans le cas où ça vaudrait le coup de la faire ?
Vu que du côté de la doc, l’ordre est donné de n’utiliser la machine que pour ça, ce qui serait fort dommage dans mon cas et pas envie d’investir dans un rasp berry Pi sachant que je pense que les performances de cette machine devraient être correctes pour Home Assistant :
Il s’agit d’un VHS-4 débaracé du système de Ve-hotech.
Plus précisément, son processeur est un Intel i3-4130T et il a 4GO de RAM.
Qu’en pensez-vous ?
Vu le chantier je préfère avoir des avis de personnes connaissant mieux HA que moi.
Si tu arrives à faire marcher ton installation comme ça, pour moi, ça n’a aucun intérêt de passer sous supervised.
Qu’est ce que tu voudrais faire en plus que tu n’arrives pas à faire avec ton installation actuelle?
Si on maitrise Linux, passer en installation avec le superviseur n’apporte rien. En tout cas, pour moi…
En fait, c’est plus en terme de performences que je pense, à savoir qu’avec mon installation actuelle, j’ai la VM en plus. Alors qu’en supervised, j’ai tous les avantages de HAssOS avec notemment les addons que je ne pourrais pas avoir dans un autre cadre d’installation, et ils m’arrangent bien pour MQTT par exemple où au moins j’ai pas à faire la config moi-même. Le système de sauvegarde intégré est un petit plus que je perdrais dans un autre type d’installation que OS ou supervised.
J’ai l’impression que finalement, le superfised c’est tous les avantages de l’installation avec Home Assistant OS mais en ayant vraiment la main sur la machine hôte, pas mal de choses en lecture seule dans Home Assistant OS, par exemple je voulais changer la swappiness dans ma VM ce qui est impossible vu qu’il me faudrait ajouter un fichier dans /etc/sysctl.d ou une ligne dans sysctl.conf
Pour mon souci d’accès via Wireguard, j’aurais bien plus de souplesse en supervised vu que Wireguard tournerait sur la machine hôte et c’est moi qui gèrerait donc le firewall de ce côté.
Non pas que la maîtrise de Linux soit un problème pour moi mais j’ai un peu du mal à évaluer la somme de chose en plus à apprendre si je me passe des facilités offertes.
L’intégration du matériel aussi me laisse quelques appréhensions même si j’ai l’impression qu’il y a du bien mieux notamment en ce qui concerne le bluetooth dans une VM Qemu.
HA ne consomme « rien » en CPU. Donc, certes ta VM va consommer un peu mais, bon, c’est pas grave.
Alors là, typiquement, pour moi, c’est l’addon qui ne s’impose pas du tout. Mosquitto dans un container OK, mais, en addon? Le seul argument, c’est la facilité d’installation. C’est effectivement faisable en deux clics. Et le container c’est en ligne de commande.
C’est un bon résumé. Mais, je suis convaincu que si on maitrise Linux, Home Assistant OS c’est vraiment se brider plus qu’autre chose.
J’ai des odroid C2. J’ai testé les trois installations:
Home Assistant OS
Home Assistant Supervised sur Debian
Home Assistant Container sur Debian (avec Portainer et Watchtower pour faciliter les upgrades)
Sur mon NUC sous proxmox, j’ai fait la même chose dans une VM (l’équivalent de ce que tu as avec QEMU). Et là encore, le mode Container me donne la souplesse et la maitrise de mon environnement.
D’accord, je me disais que vu que c’est tout un OS qui tourne en plus avec du docker, retirer la couche OS en retirerait pas mal même si ça reste un bon vieux buildroot donc du léger.
Pour être honnête, je n’ai même pas essayé de me documenter j’ai lu dans les tuto ici et vu la facilité, je me suis dit que ça me permettrait de me concentrer sur le principal plus rapidement sans avoir à configurer un serveur en plus.
C’est si simple que ça ?
Finalement, vu que je suis un brin borné mais ouvert au compromis, tu penses que me passer des addons du coup (et de la sauvegarde intégrée) en passant en mode containers ça vaudrait déjà plus le coup ?
Même si je commence à me dire que je suis sur une réflexion de migration mais pour une mauvaise raison, à savoir ne plus être sur une VM de ce que j’analyse de tes réponses.
Vu qu’en add-on pour le moment j’ai :
Home Assistant Google Drive Backup (finalement remplaçable par une autre solution de stockage) ;
MariaDB (bon là j’abuse parce qu’installer MariaDB sous Debian c’est pas sorcier lol) ;
Mosquitto broker ;
Samba et SSH que j’ai déjà sur la machine hôte.
Dans les addons, il y a celui pour le zigbee qui semble bien si finalement je fini par passer par Zigbee2MQTT au lieu de ZAH, pour le coup sans Home Assistant OS est-ce que ça ne complique pas un peu ?
C’est mon avis.
Pour la sauvegarde, comme le disque où les données de HA sont accessibles avec Samba ou alors avec rclone sur le serveur et tu copies tout ce que tu veux « ailleurs » (dropbox, google,…).
Effectivement, je suis en train détudier l’installation en simple container y compris pour ZB2MQTT et ça semble largement dans mes cordes.
Avec un container Watchtower dédié (j’ai déjà un fork de Watchtower qui tourne pour un noeud Storj mais je ne souhaite pas l’utiliser pour HA vu qu’il a un délai de 12 à 72 heures.
ça permettrait une mise à jour automatique que je n’avais pas avec HAssOS.
Même si ça reste en réflexion finalement, n’est-ce pas une fausse bonne idée de mettre à jour HA automatiquement ?
J’attends un peu au cas où d’autres membres auraient envie de faire part d’un point de vue mais pour le moment, je pense partir sur ce type de migration.
Car j’ai pu voir un des « mauvais » côtés d’une VM vendredi, quand la machine sur laquelle tout ça tourne n’a semble-t-il pas apprécié d’avoir été nettoyé de sa poussière après un trop long moment, drôle de comportement avec un disque que j’ai dû rajouter aux grappes RAID du coup resynchro d’un RAID5 de plusieurs TO. le fait d’être en disque dur virtuel a rendu la marge d’erreur moins grande, heureusement que j’avais des sauvegardes.
Sans parler qu’avec HAssOS, le temps de démarrage est horriblement lent je trouve, le temps que tout soit effectivement lancé et j’avais les guest additions de Qemu qui n’étaient plus démarrées apparemment.
Absolument!!! Il ne faut surtout pas le faire. Mais, tu peux dire à watchtower de vérifier et de t’informer. Et c’est tout. Tu as plusieurs modes à watchtower, l’un est de vérifier seulement. Et ça marche!
Effectivement… Une simple notification native est largement suffisante du coup.
Y aurait moyen de récupérer un lien vers la release note en suite ? Je sais, un truc de flemmard.
Ce dernier est plus spécifique : c’est un fork pour les nœuds de stockage Storj : https://www.storj.io
Il a un délai alléatoir de 12 à 72 heures rajouté pour ne pas que tout le réseau Storj soit mis à jour en même temps, en cas de bug découvert tous les nœuds ne seront pas impactés.
En fait il semble y avoir l’original plus plein de fork pour des usages spécifiques.
Petite question qui me vient à l’esprit mais globalement, si je me contente de recopier tout le répertoire config vers le répertoire que je défini pour mon container ça suffit ?
Enfin ça plus modifier l’URL de connexion MariaDB et en suite reconfigurer mes intégrations genre MQTT pour se connecter au bon serveur en suite HA saura détecter le bon environnement sans que ça parte totalement en vrille ?
EDIT : sans oublier de virer les addons avant parce que ça doit bien laisser des données qui seront donc inutiles une fois migré en container.
Tu fais une copie du repertoire config entier et tu mets ça au frais.
Ensuite, tu dis à ton container que tu lances que le répertoire de la configuration c’est config et c’est parti.
Inutiles sans doute, mais, ça ne doit pas gêner pour que ça marche. Donc, tu peux faire le ménage après.
Vu que je suis quelqu’un de super patient (ou pas), j’ai sauté le pas et ai migré vers un container Docker.
Accès en SSH à la VM pour arrêter Home Assistant Core, parce que ça aurait été trop facile de le faire via l’interface web ;
tar -cpvf config.tar.gz /config histoire de tout sauvegarder ;
Copie de l’archive et extraction là où tourne le container ;
Arrêt de la VM ;
Création du container en spécifiant le répertoire où j’ai extrait la config.
Et ça roule, seule l’intégration Freebox m’a dû refaire l’objet d’une autorisation sur la Freebox. Je ne comprends pas trop pourquoi mais soit…
Je me suis bien fait une petite frayeur au moment de tester une automatisation qui diffuse un message sur une Nest Mini mais forcément, quand on ne change pas l’URL interne de Home Assistant et qu’elle a toujours l’IP d’avant ça peut poser problème j’ai compris en lisant cinq fois le log.
J’ai également eu une erreur de" zeroconf qui n’arrivait pas à utiliser une socket, que j’ai résolu en rajoutant ceci dans configuration.yaml :
zeroconf:
default_interface: true
Si j’ai bien saisi, c’est parce que la machine que j’utilise a deux cartes réseau, sauf qu’une seule est effectivement utilisée.
Du coup avec ça Zeroconf n’utilise que l’interface réseau par défaut.
Je me suis également fait quelques scripts bash basiques (vérification de la configuration, redémarrage du container et un pour la mise à jour don je verrais s’il fonctionne vraiment qu’à la prochaine MAJ de HA).
Merci @golfvert de m’avoir aiguillé sur l’installation en container au lieu du supervised sur lequel je partais à l’origine, c’est moins contraignant et même si j’y perds quelques facilités ça ne devrait pas être insurmontable.
Il m’en reste encore à faire mais le principal est là.
Au ciècle prochain, quand ma clé Zigbee commandée sur slae.sh sera peut-être enfin expédiée puis reçue, je verrais bien ce que ça donne pour l’intégrer au container et utiliser ZAH.
J’oubliais un point : Mosquitto.
Vu que Debian l’a dans ses paquets et qu’il est très léger, je ne vais pas m’embêter à le faire tourner dans Docker
Je le fais pour HA parce que l’installer en « Core » demande pas mal de dépendances et que j’ai la flemme de faire ce qu’il faut pour le lancer au démarrage, alors que Docker le relancera sans que j’ai à faire quoi que ce soit.
Il y a une v2 de mosquitto qui est sortie récemment. Pour la beauté de l’exercice, ce serait mieux d’utiliser cette version-là
Je ne sais pas si debian la propose déjà…
Et j’ai plus confiance en moi pour la gestion des ports en installant la version par apt, j’ai eu des mauvaises surprises de ports exposés avec des containers alors que là au moins je suis sûr qu’il n’écoutera que sur localhost.
En postant tout à l’heure je ne me suis aperçu que trop tard que je n’avais pas été assez claire
La machine sur laquelle tout ça est installé est ma DMZ.
Dans la config que HA propose pour Docker, on n’expose aucun port, ça utilise directement la machine hôte donc Docker ne modifie rien au niveau du firewall.
Alors que dans le cas de l’installation de Mosquitto en container Docker, on expose explicitement des ports donc Docker cré des règles pour ouvrir le port sur la machine, ce qui outre-passe ce que j’ai mis en place pour que quand un port est ouvert, seul les IP de mon réseau local puissent accéder sauf si je spécifie clairement le contraire.
Et j’ai pas très envie de désactiver ma DMZ mais c’est sûr que le rythme de mise à jour par Docker est probablement plus rapide. Et le dépôt Debian pour Mosquitto est clairement indiqué comme étant expérimental.
EDIT : en plus vu que je compte utiliser du Tasmota je ne peux pas me contenter de faire écouter Mosquitto sur localhost.
Et tout est ouvert sur ta box pour « attaquer » ton serveur? Tu gères des IPTABLES/FIREWALLD dessus?
Si tu mets en mode « host » et que dans docker tu utilises le port par défaut 1883 vers 1883, docker te fais une règle d’autorisation globale par défaut vers 1883? Je ne savais pas. C’est très vilain
PS: Quand tu auras fini avec HA (si ça arrive un jour), tu peux regarder mettre un « vrai » firewall devant ton serveur (par exemple opnsense) avec deux interfaces Ethernet et filtrer dessus.
Oui.
C’est justement pour ça que je me suis « permis » de mettre cette machine en DMZ.
La règle est de fermer en INPUT sauf ports précisés.
Avec une exception pour les IPs du sous-réseau utilisé en local.
Avec NFTable.
En tout cas, si je prends la ligne de commande que tu avais mis, si j’expose le port il va créer une règle globale oui.
Seule solution que j’ai trouvé : n’ouvrir que pour 127.0.0.1 mais c’est trop restrictif.
Je m’étais fait avoir avec mon noeud Storj, j’avais exposé le port du dashboard sans préciser 127.0.0.1 me disant que mes règles nftables allaient faire que le port serait restreint comme les autres sauf que… C’était open-bar ! ça va que le dashboard n’était qu’informatif.
Comment ça si ça arrive un jour dis tout de suite que ça traîne lol.
ça coûte une fortune en plus non ? Un firewall hardware.
j’ai lu dans les tuto ici et vu la facilité, je me suis dit que ça me permettrait de me concentrer sur le principal plus rapidement sans avoir à configurer un serveur en plus.
parce que ça doit bien laisser des données qui seront donc inutiles une fois migré en container.