Avant de sortir la RC, j’aimerais être absolument sûr que l’image Raspbian qu’on va fournir est pérenne dans le temps, et qu’elle se mette à jour à vie sans action de l’utilisateur.
Mise à jour de Gladys
La mise à jour du container Docker Gladys est faite automatiquement grâce à watchtower, donc là dessus on est déjà bon.
Mise à jour des paramètres du containers de Gladys
Pour l’instant, Gladys est lancée avec un docker run avec certains paramètres. Hors, à l’avenir, peut-être que l’on voudrait exposer plus de volumes? Ou changer un paramètre?
Comment pourra on faire sur les images distantes déjà déployées?
Mise à jour de l’OS
Je ne sais pas les bests practices sur ce genre de device embarqué, car d’un côté faire des mises à jour des packets automatiquement c’est risky et c’est le meilleure moyen de bricker l’installation, mais d’un côté c’est pas fou de laisser Gladys tourner sans mise à jour.
Si quelqu’un a des tuyaux là dessus, je suis preneur.
Alors là ça va être compliqué, pour les bind mount obliger de détruire et recréer le conteneur donc pas smooth du tout.
Les paramètres modifiables à chaud sont ceux là => docker container update | Docker Docs donc tout ce qui touche aux ressources. ( pas vraiment ce qui nous intéresse )
Mm ok, dans ce cas il vaut peut-être mieux viser large et être sûr que l’image Raspbian de base a tous les volumes dont on va avoir besoin à l’avenir.
Est-ce que tu vois des choses qui pourraient manquer dans l’image actuelle?
On a /dev, mais est-ce qu’il nous manque pas des trucs? Genre pour accéder aux GPIO par exemple, ou la caméra Raspberry Pi officielle, il faut absolument que l’image soit compatible avec le maximum de chose même si on les gère pas encore là. Il faut pas que Docker nous freine pour développer la suite
C’est possible de les activer dans l’image que tu build?
@VonOx En fait, j’utilise déjà ça ( unattended-upgrades ) sur tout mes serveurs, c’est fourni par défaut dans Ubuntu 18.04, donc oui c’est super stable et ça fait le boulot. On peut le rajouter à l’image !
Top ! Tu veux dire faire une PR sur le repo Gladys?
Je ne sais pas quelle est la meilleure stratégie pour merger ça en fait (pareil que ta PR sur les images Docker avec l’architecture).
Parce que tant qu’on est en beta, c’est cool si toutes les instances qui tournent continuent d’être mise à jour. Hors pour l’instant, la PR avec les images Docker build sur le tag avec version, pas le tag beta.
Tu as une idée?
Sinon on prévient tout le monde (tant qu’on est pas encore des milliers à utiliser Gladys 4) qu’on va builder sur le tag version, et qu’on arrête le beta, mais bon ça risque de grogner vu que ça veut dire que tout le monde doit tout réinstaller (au dernière nouvelle, on a genre 200 instances v4 actives)
Je vois pas 36 solutions , tout le monde tourne sur le tag beta, donc si tu merge aucune instance ne se mettra à jour.
Comme tu dis,un gros coup de comm pour dire aux utilisateurs comment faire la mise à jour manuellement ou de reflash la dernière image.
On peut toutefois prévoir une période transitoire où on fourni encore le tag beta, et ajouter une notif dans Gladys si le tag contient beta ? ça sera moins brutal.
Je passais rarement ces derniers temps, je viens de faire un déménagement ^^
Je n’ai jamais testé de mise a jour automatique de serveur et je ne pense pas que je testerais.
Des fois il y a des fichiers de config qui change entre tel ou tel version, ou tout simplement des option qui n’existe plus. Je préfère les appliquer avec ansible et faire une série de tests derrière.
Par contée je me questionne sur un truc, comment va s agencer Security Update sachant que Gladys va tourner dans un docker ?
Il faudrait qu’il tourne sur le raspbian qui héberge le docker non ?
Il faudrait avertirent l’utilisateur ou laisser un paramétrage possible. Le raspberry est peut être utiliser aussi pour d’autres services
Partager le répertoire contenant le script de lancement de Gladys avec le container Gladys afin de pouvoir modifier les paramètres du container voir créer de nouveaux répertoires si besoin avant le lancement.
Un reboot de la machine permettrait la mise à jour.
Lancer un container de maintenance à partir de Gladys. Celui-ci pourrait alors stopper-supprimer le container Gladys, appliquer les nouveaux paramètres avant de relancer Gladys.
Je viens de pensé a un truc sans vraiment le creuser pour le moment.
Du coup le package serait installer sur la raspbian, donc figée niveau paramétrages. L’utilisateur devra forcément passer par du ssh pour le modifier, sur le reboot automatique dans la nuit notamment.
Est-ce qu’il n’y a pas une solution webui qui permettrait de lancée les mise a jours et / ou avoir access au paramétrage du package ?
Il y a très longtemps j’utilisais webmin, je sais qu’il en existe d’autre.
Comme l’utilisateur ne doit plus passer par du ssh, je me dis qu’un webui de ce style aurais aussi des avantages pour choisir DHCP / static, choisir son resolver DNS, appliquer des mises a jours.
Le truc que je vois qui pourrait être aussi pas mal, hors upgrade sécurité, que ce soit Gladys qui avertis le user qu’il y a une mise a jour a faire, type kernel, et que l’utilisateur la déclenche via une webui.
Je pense aussi ! On peut continuer à builder le tag beta tant qu’on est pas en RC (en ne fournissant plus que l’image avec le tag v4 sur le site), et ensuite à la sortie de la RC on pourra annoncer que le tag beta n’est plus mis à jour. ça parait plus doux
Oui, ce sujet ne parle que de l’image Raspbian, pas du container.
Attention, ce sujet ne parle pas de Gladys, mais de l’image Raspbian que l’on fournit pour les débutants qui ne se loggueront problablement jamais en SSH sur le Raspberry Pi.
Il faut traiter cette image Raspbian comme si on était un fabricant d’objet connecté (exemple: une caméra IP qui tourne sur linux) et qui fournit des caméras à ses clients: le client ne se connectera jamais en SSH à la caméra, il ne sait même pas ce qu’est le SSH, linux, etc… il veut juste que la caméra fonctionne, point bar.
Ici, c’est pareil: notre image Raspbian va être clonée sur des cartes SD, une manipulation que n’importe qui peut faire grâce à Etcher, ensuite Gladys tournera peut-être 5 ans sans jamais que l’utilisateur ne se connecte en SSH!
Si tu es un utilisateur avancé, que tu as des configs très particulières, soit: tu es donc capable de modifier la config de l’image Raspbian. Les défauts de base que l’on choisit sont pour l’utilisateur lambda, et doivent être des bons defaults.
En soit, on a déjà accès au docker daemon de l’intérieur de Gladys, donc en fait j’y pensais on peut tout à fait faire re-poper un nouveau container Gladys avec une autre commande
aha exactement, on a pensé à la même chose
Sinon, on peut simplement exposer le reboot de l’host dans Gladys
D’ailleurs ça me fait penser, @VonOx je pense qu’on va vouloir retrouver toutes les fonctionnalités du packages rpi-info qu’avait fait Piznel dans Gladys 4.
Est-ce que l’image actuelle expose assez de trucs pour qu’on ait toutes les informations? Je pense qu’il manque des trucs
La question que je me pose, qui sera sans doute plus précis avec un cas :
Un utilisateur installe gladys, il a une ip qui lui est fournit par sa box et configure le tout avec ça.
Demain la box est HS, avec le changement de box, il y a beaucoup de chance que l’ip attribué au raspberry ne soit plus la même que ce qu’il avait au départ.
Forcément pour un utilisateur lambda, il ne retrouve plus gladys, en faisant des recherches ou question sur le forum, il tombera sur les notions d’ip etc etc. Pour retrouver la nouvelle ip de son raspberry, il faudra qu’il passe par un soft de scan ip.
Justement, beaucoup de device, lors de la configuration propose de fixer une adresse ip ou la laisser en dhcp.
Ce boulot n’est clairement pas fait pour gladys, c’est pour cela que j’ai penser a webmin, ou encore cockpit https://cockpit-project.org/, il y’en a encore bien d’autres, qui pourrait être embarquer en package (donc mise à jours facile) dans le raspbian et avoir une webui pour des configuration type réseau.
Après dans mon exemple, même s’il y a une webui pour faire la configuration du réseau et que l’utilisateur ne le fait pas, ça ne changera en rien que si pour une raison le dhcp ne lui fournit plus la même ip, il ne retrouvera pas son gladys.
Personnellement, je trouve que de fixer une ip pour un service comme celui-ci permet d’éviter des problèmes par la suite. J’ai trop souvent du régler des problèmes de ce type ^^
Ca reste aussi du réseau pur, lorsque l’utilisateur client utilise xxx.local, il faut que le DHCP soit dans le domaine .local ce qui n’est pas nécessairement le cas.
Si la box est paramétrer avec un domaine local .lan, le DHCP va distribuer une ip, et s’il renseigne aussi le hostname dans sa bases, son fqdn sera gladys.lan.
D’une manière générale, il est plus que fortement conseillé tous ce qui est device qui gère des services (serveur, imprimante, caméra, détecteur)
d’être en IP fixe ou d’avoir une réservation mac au niveau du DHCP pour toujours lui attribué la même et dans ce cas c’est au niveau de la box de chaque utilisateur ou c’est a faire.
Le plus user-friendly c’est que l’utilisateur se connecte toujours via Gladys Plus, ainsi l’URL ne change jamais (plus.gladysassistant.com), mais effectivement c’est pour les utilisateurs du pack payant.
Dans tous les cas, on peut recommander l’application de network scanner (iOS/Android), qui est assez user-friendly pour retrouver ton Pi si son IP a changé et que sa box ne gère pas le .local/.lan. Après, d’expérience, ça n’arrive pas tous les 4 matins non plus: la plupart des box grand public gère le .local, et au pire il y a l’appli network scanner
Mise à jour de Gladys
Mise à jour des paramètres du containers de Gladys
