Bonjour
Contexte : Installation sur un RPI4 avec SSD tournant sous Umbrel OS 1.1 (sorti il y a un mois).
L’intégration est en review ici, mais je voulais tester sur un vrai RPI (et pas en VM).
J’ai récemment restauré une sauvegarde Gladys Plus sur une installation Umbrel toute fraîche (pour tester le comportement sur cet OS).
J’ai l’erreur suivante à la fin de la restauration et j’ai dû lancer le container gladys à la main (tout fonctionne bien depuis).
2024-04-23T15:14:36+0200 <info> gateway.restoreBackup.js:39 (Gateway.restoreBackup) Backup restored. Need reboot now.
2024-04-23T15:14:36+0200 <info> system.shutdown.js:13 (System.shutdown) Database is probably already closed
2024-04-23T15:14:36+0200 <warn> system.shutdown.js:14 (System.shutdown) Error: SQLITE_MISUSE: Database is closed
at /src/server/node_modules/sequelize/src/dialects/sqlite/connection-manager.js:31:79
at node:internal/util:441:7
at new Promise (<anonymous>)
at node:internal/util:427:12
at /src/server/node_modules/sequelize/src/dialects/sqlite/connection-manager.js:31:85
at Array.map (<anonymous>)
at ConnectionManager._onProcessExit (/src/server/node_modules/sequelize/src/dialects/sqlite/connection-manager.js:31:10)
at ConnectionManager.close (/src/server/node_modules/sequelize/src/dialects/abstract/connection-manager.js:116:23)
at Sequelize.close (/src/server/node_modules/sequelize/src/sequelize.js:1292:35)
at System.shutdown (/src/server/lib/system/system.shutdown.js:11:26)
at Gateway.restoreBackupEvent (/src/server/lib/gateway/gateway.restoreBackupEvent.js:18:23)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at EventEmitter.<anonymous> (/src/server/utils/functionsWrapper.js:13:7) {
errno: 21,
code: 'SQLITE_MISUSE'
}
Ah, c’est peut-être dû à l’option dans le docker-compose
restart: on-failure
Alors j’ai un comportement bizarre. Le container Gladys n’arrive pas à contacter localhost (ce qui pose problème pour contacter MQTT).
Le ping localhost me renvoie ping: bad address 'localhost'
Le ping 127.0.0.1 fonctionne.
J’ai tout vérifié (/etc/hosts, DNS, interface loopback, container en mode network: host). Je sèche
Salut @cicoub13 
Effectivement, le mécanisme de restauration se base sur le fait que Gladys est relancée automatiquement si elle « s’auto-kill ». Si tu es en restart: on-failure, ça ne marche plus. Il faut être en restart: always !
ça j’avoue que je ne sais pas comment fonctionne Umbrel., il n’y a pas un network spécial umbrel dans leur config Docker, ou autre ?
J’avais réussi à tout faire fonctionner et fait la PR ici Add gladys assistant by cicoub13 · Pull Request #1044 · getumbrel/umbrel-apps · GitHub
Mais ils posent plein de questions sur nos accès assez larges. Je vais répondre en essayant d’expliquer pourquoi on en a besoin (comme home assistant…).
Cool super @cicoub13
J’ai vu les questions, effectivement c’est assez étonnant qu’ils posent ces questions sachant qu’ils donnent les mêmes permissions à Home Assistant : umbrel-apps/home-assistant/docker-compose.yml at master · getumbrel/umbrel-apps · GitHub
Tiens moi au courant si tu as besoin d’aide pour répondre
nmfretz (Nathan Fretz) · GitHub a l’air d’avoir plus d’expertise et comprend une grande partie des paramètres.
J’ai commenté en ajoutant des détails sur notre besoin.
Je sèche un peu sur le cgroup: host et sur privileged: true. Est-ce que tu saurais me donner la raison de ces parramètres ?
1 « J'aime »
Merci @cicoub13 pour les réponses, j’ai ajouté mes réponses pour cgroup et privileged
Réponse négative concernant l’exposition du daemon docker (trop risqué). Ils proposent plusieurs solutions ici Add gladys assistant by cicoub13 · Pull Request #1044 · getumbrel/umbrel-apps · GitHub
Le docker in docker me paraît intéressant (même pour nous), mais cela me paraît complexe et je me pose la question de l’intérêt pour Gladys hors Umbrel.
Hello @cicoub13 !
J’ai vu la réponse, à tester mais pour moi le Docker in Docker ça ne fonctionne pas et c’est même très bancale.
Lancer un container Zigbee2mqtt à l’intérieur d’un autre container, est-ce qu’il aura accès au système (Privileged? port USB?)
De ce que je comprend, le projet Umbrel veut rester maitre du host et ne pas laisser le droit aux containers de lancer d’autres containers, or c’est justement ce qu’on essaie de faire ^^
Si leur projet n’accepte pas ce comportement, plutôt que de mettre en place des hacks, le mieux est peut-être de ne pas permettre ce comportement dans ces installations et l’utilisateur pourra juste utiliser Z2M en mode distant, pareil pour MQTT…
Mais à tester !
Je me demande si ces applications (Portainer, Home Assistant) sont vraiment utilisés au sein d’Umbrel ?
Salut @cicoub13 Je viens aux nouvelles sur ce sujet !
Au vu de leur dernière réponse, j’ai laissé tomber. Je pense que l’investissement de dev/temps ne vaut pas le coup aujourd’hui.
Ce que je ne comprends pas, c’est pourquoi c’est oui pour HA et non pour nous. Enfin, si, ils essayent de faire mieux et du coup, on arrive un peu tard 
Et si on abandonne juste la partie « lancement de container » ? Vu que maintenant on est capable de se connecter à un container Zigbee2mqtt existant, c’est bon
Sachant que Gladys sait quand elle n’a pas le démon Docker de dispo, donc normalement pas de changement dans le produit ?
C’est juste une seule ligne à changer sur la PR Umbrel
1 « J'aime »