Bonjour,
Il ne s’agit pas ici de remonter un probleme mais d’avantage de partager un retour d’experience et emettre une suggestion.
Le contexte : Debian 11 sous Rpi 3B, elle sature, migration vers une Opi 5 Max, toujours Debian 11 pour garder la compatibilité des plugins (j’ai testé Debian 12 puis suis reparti vers 11).
Le backup/restore n’est pas concluant, de nombreux problèmes et ‹ Jeedom qui persiste a démarrer eternellement ›).
La procédure :
1- backup de l’arbre jeedom (chez moi /opt/jeedom) + dump MySQL + tout mon système d’exploitation pour retrouver mes configs/scripts maison.
2- Install de la Debian 11 sur l’ordi cible.
3- Installation de Jeedom selon la procédure
4- restauration de mon /opt/jeedom
5- restauration des configs satellites (effacement + restore /var/lib/mysql, restore /etc/apache2, /etc/php etc).
Au bout de la procedure, assez rapide, Jeedom « fonctionne comme avant »
Pourquoi les guillemets ? Parce que je peux entrer dans Jeedom mais celui-ci ne fait plus rien et se plaint de demarrer.
Pour résoudre cela :
J’ai "réinstallé (recompilé) tous les plugin, ainsi tous sont retombés sur leurs pattes.
J’ai désactivé puis reactivé le cron jeedom
J’ai lancé chaque tache du moteur une par une.
Dans mon cas, cette procédure à remis 99% de tout en place. Il ne me reste que des petits sujets anecdotiques d’automatisation.
Pourquoi tout ce bla bla ?
Ce genre de migration n’est pas rare, je me dis qu’il pourrait etre facile pour qui connait bien le core Jeedom (pas moi donc), de faire un script qui ferait tout cela. Après tout Jeedom n’est qu’API et il doit être possible de recuperer la liste des plugins, de lancer leur reinstall, de recuperer la liste des taches, de lancer chacune d’elles etc. Ainsi en cas d’insuccès avec le backup/restore, on peut s’en sortir…
Cela peut inclure d’autres actions qui m’ont échappé.
Au bout du compte, cela pourrait offrir à Jeedom une sorte de script de migration matériel à équivalent ISO logiciel
Pourquoi tout faire « à la main » alors que les backups Jeedom sont faits pour ça ?
Pourquoi restaurer l’arborescence Jeedom qui tournait sur un RPI vers une machine avec un processeur d’une autre architecture ?
Il me semble que la procédure existe :
faire un backup Jeedom de la source
externaliser le backup
faire un restore sur la cible
tester / corriger
« Même un mécanicien de formule 1 utilise une simple clé allen pour régler les freins de son vélo »
Curieuse manipulation , je viens de faire le test d’un restauration de backup Jeedom 4.4.19 externalisé debian 10 provenant d’un raspberry 3b+ sur un mini pc celeron debian 11 et je n’ai eu aucun souci, juste à réinstaller les dépendances des plugins.
Bonjour Aurel,
le dump SQL fait 114Mo en texte brut.
J’ai rallumé la Pi3B, le tarball annonce 260Mo
cote restauration, globalement les compilations se sont bien passées, par contre des refus de lancer des démons et le fameux jeedom est en train de démarrer qui dure éternellement (sans le souci du privatetmp apache ;-)) mais cette fois-ci impossible de m’en sortir…
Je confirme que ca n’est pas systematique. J’ai Jeedom depuis plus de 6 ans, j’ai du migrer par 3 fois si je me rappelle bien : Rpi 1 → 2 → 3b → 5. C’est la premiere fois que ca coince vraiment.
D’ailleurs ca n’est pas encore ‹ parfait › le cron fonctionne et ne fonctionne pas, il me fait son capricieux et impossible de trouver pourquoi. C’est le dernier souci que j’ai…
Bonjour Michel,
Je connais cette théorie et comme toutes, elle n’est pas infaillible
C’est la première fois qu’elle me trahit en 6 ans.
Dans mon cas j’ai changé de device, du coup j’ai encore l’ancienne Rpi3B intacte dans le pire des cas. Mais j’ai tout de même tenté 2 fois pour arriver au même résultat, avec les memes conditions (OPi fraichement installée, Jeedom installé selon la procédure (wget+run install) puis le restore.
A noter une subtilité qui ‹ pourrait › jouer : Rpi3B c’est un ARMbian. OPi 5 Max en debian 11, c’est une Debian 11 faite OrangePi. Je n’ai rien remarqué mais il pourrait y avoir des points clés différents…
La réponse est non, Jeedom est agnostique de la machine sur lequel il tourne. Il m’arrive régulièrement de restaurer des Jeedom :
en source Raspberry Pi 4B, Raspberry Pi OS 64 bit
en cible : machines virtuelles Debian x64
et Raspberry Pi 3B, Raspberry Pi OS 32 bit
Ce qui n’est pas possible (du moins pour les profanes) c’est de restaurer d’une Debian 12 vers une Debian 11.
Il arrive, que certains plugins embarque une partie des dépendances dans la sauvegarde de Jeedom, il suffit de supprimer un dossier et de réinstaller les dépendances.
Restaurer une 12 sur une 11…
« Techniquement », si une restauration relance la compilation de toutes les dépendances (versus arriver avec le backup), ca pourrait passer si chaque module est compatible…
De toute facon quand j’ai profité du changement pour passer en 12, j’ai suivi ma procédure aussi, histoire d’arriver « propre »
Entre temps j’ai trouvé l’origine de mon problème de jeeCron, assez simple somme toute : jeedom lance son cron qu’il considère par defaut en /var/www/html quand j’utilise ce repertoire pour le web frontal dont jeedom n’est qu’une instance.
Avec la redirection vers dev null + pas de log, impossible de détecter l’erreur sauf à remarquer le chemin dans syslog. Partant de la j’ai pu corriger et tout est a nouveau parfait
Des « plugins ». Abus de langage, pour moi installer des modules, des packages, des librairies, qu’il y ai compilation réelle ou pas, je met tout dedans car cela engendre des interdépendances au niveau des librairies…
Je vais être désagréable mais il y a trop d’erreur dans vos propos:
arrêtez de parler de compilation, dans 99% des cas il n’y a aucune compilation; on parle bien d’installation des dépendances.
les dépendances des plugins n’ont jamais été incluses avec le backup jeedom, cela ne peut donc pas être la source d’un problème; c’est bien pour cela qu’il faut relancer leur installations après une restauration
le problème de la restauration entre deb12 (php8 en fait) et deb11 (php7) n’est pas sur les dépendances des plugins mais sur les dépendances php (géré via composer) du core (et non une dépendance php n’est pas compilée)
et donc non aucun rapport avec des « interdépendances au niveau des librairies »
, je viens de faire le test d’un restauration de backup Jeedom 4.4.19 externalisé debian 10 provenant d’un raspberry 3b+ sur un mini pc celeron debian 11 et je n’ai eu aucun souci, juste à réinstaller les dépendances des plugins.