Questions sur migration Rpi2/Debian8/Jeedom3 vers Rpi4/Debian10/Jeedom4

Bonjour,

J’ai un jeedom qui tourne depuis 2016, et que je souhaite mettre à jour
Matériel : Raspberry Pi 2
OS : Raspbian GNU/Linux 8.0 (jessie)
Jeedom Version : 3.3.52
Dongle Z-wave.me (1ère version GPIO)

Je souhaite passer sur un raspberry pi 4 en boot USB3 sur disque SSD, Debian 10 Buster et Jeedom 4.X (quitte à mettre à jour, autant y aller)
Et vu que l’installation de l’époque devait certainement être artisanale, je souhaite reprendre tout from scratch, et migrer les données et la configuration des plugins.

J’ai donc tenté de faire une réinstallation propre avec une raspbian vierge et le script https://raw.githubusercontent.com/jeedom/core/master/install/install.sh

Mes questions :

  • Est-ce que debian 10 est réellement supporté ?
    Je n’ai pas vu passer d’annonce officielle
    Le lien de la page officielle Jeedom - Le logiciel mène sur https://jeedom.github.io/documentation/installation/fr_FR/index qui indique Debian 9
    Alors que la page https://doc.jeedom.com/fr_FR/installation/rpi indique Debian 10

  • Est-ce que jeedom V4 est réellement en version stable ?
    Je n’ai pas trouvé d’info officielle l’annoncant (des infos du forum indiquait fin août possiblement), mais le script d’installation me dit « Version d’installation de Jeedom : V4-stable »

  • Est-ce qu’il y a des choses à faire pour éviter la perte d’information ?
    Est-ce que le backup que jeedom génère toutes les nuits suffit à la migration, et contient tout l’historique ? Avec les données et la configuration de tous les plugins ?

  • Est-ce que l’utilisation de apache, php-cgi et exim4 est obligatoire ?
    En plus d’avoir l’habitude de travailler avec nginx, php-fpm et postfix, j’ai d’autres éléments de ma configuration qui s’appuient dessus (et je ne suis pas chaud pour tout refaire)
    J’entends l’argument du « [Apache] Permet d’avoir les dernières mises à jour de sécurité au niveau de l’accès aux fichiers (grâce au .htaccess) lors des mises à jour de Jeedom », mais mon installation est dans un réseau isolé, et je gère la sécurité de mon coté.

  • Et sinon est-ce qu’il est possible d’installer jeedom dans notre environnement perso de manière un peu moins automatique ?

  • Est-ce normal pour un serveur headless d’installer une aussi grosse quantité de librairies graphiques (wayland, x11, qt, …) ?
    Pour une installation de base, j’ai du mal à voir à quoi correspondent toutes ces dépendances

    Merci d’avance à tous pour vos réponses !

Bonsoir,
Tu trouveras plein de sujets qui répondront à tes questions.
Mais pour faire court, oui, RPI4 et buster supporte Jeedom, oui bien que pas encore annoncé officiellement annoncé, la V4 est en prod depuis de nombreux mois chez énormément de particuliers.
Tu peux n’installer que la version lite de buster (sans desktop).
Les sauvegardes faites pourront te permettre de faire un roll-back (v4->V3).

Bonjour,

Merci pour ta réponse.
Les compatibilités récentes me confortent dans ma migration.
Cependant même en fouillant la communauté, j’ai toujours quelques interrogations

  • Il semble qu’on ne puisse pas installer autrement qu’en faisant install.sh, soit une installation complète qui modifie tout le système en installant toutes les dépendances.
    Je n’ai rien trouvé (de récent) qui indiquerai comment limiter l’installation quand on a des outils équivalents déjà en place (par exemple éviter exim4 quand on a déjà postfix installé, …)
  • j’ai déjà la version lite de raspbian d’installée, mais ça ne me dit toujours pas pourquoi avec ma version headless, le script installe autant de librairies graphiques.
    Quand on veut un système headless, minimal et secure, c’est genant de savoir qu’il y a autant de librairies (inutiles?) qui sont installées
  • J’ai aussi trouvé que « La sauvegarde de Jeedom est consistante, elle comprend l’ensemble des données et binaires »
    J’ai finalement testé une install+restauration pour voir, et effectivement l’ensemble des données et binaires est ramenée … globalement tout ce qui est dans le backup, soit la sauvegarde complète du repertoire de l’ancien système
    Mon but étant de retrouver une structure de fichier propre, ça me pose vraiment problème de savoir que la restauration ramène tout, dont les fichiers et repertoires devenus obsolètes. Côté sécurité, c’est pas génial
    Bien entendu la migration vers V4 ne semble pas avoir corrigé ce problème, en laissant des vieux fichiers (utilisés par la V3 ou inférieur ?)
    Vu que le système de MAJ/restauration ne semble pas supprimer les vieux fichiers obsolètes, quelle est la meilleure option pour le faire ?

Merci d’avance (et désolé pour les pavés à rallonge)

Salut.

La politique de jeedom est simple, on installe tout sans se poser de questions, comme ça au cas où : c’est là…
C’est pas uniquement un choix appliqué à l’installation, par exemple l’usage du sudo est parfois un peu abusif aussi. Ou encore duplicity qui se réinstalle à chaque mise à jour même si on a pas l’option de backup cloud jeedom en place…
Personnellement tout ça m’ennuie également.

Pour en revenir au sujet général, en fait tu as 2 solutions :

  • tu prends le fichier install.sh, tu édites ce que tu ne veux pas…
  • tu gardes l’installation classique et tu fais le ménage ensuite.

La première solution est techniquement la meilleure, la deuxième un peu moins longue mais l’une comme l’autre sont quand même réservées à ceux qui maîtrisent un tant soit peu Linux et leur système. On a vite fait de tout casser. Et puis le support…

Quant aux reliquats des v2, v3 et autres trucs inutiles dans le répertoire jeedom, pas d’autre solution que de faire la chasse manuellement. D’autant que la mise à jour a également vite fait de remettre tout un tas de trucs…

Allez pour finir j’ajoute un dernier point mais ça ne va pas t’aider : la version 64 bits de Raspios est meilleure au niveau des performances, mais elle n’existe pas encore en version light (donc headless) … Donc dans ce cas, tu as aussi tout un tas de trucs inutiles

Hello,

Merci pour toutes ces informations. Tu as dit tout haut, ce que j’avais cru comprendre tout bas, à savoir « On met tout, on garde tout, ça (re)servira bien à un moment »
ça ne m’arrange pas, mais c’est un choix qui peut s’avérer compréhensible/gagnant pour une boite qui veut un système opérationnel pour mme Michu, mais qui a pas beaucoup de temps/budget à allouer au nettoyage, face à l’innovation nécessaire pour survivre.
Je vais mettre les mains dans le cambouis, et voir pour adapter ce fichier install à mes besoins, et faire un petit diff avec une V4 from scratch pour identifier les reliquats du passé.

Pour la 64 bits, je viens de voir que y’a de la beta dans l’air. Mais merci pour l’information, je n’avais pas fait attention que j’étais encore en 32bits. Mon rpi2 suivait la cadence, donc je ne cous pas après les perfs tout de suite. Je pourrai refaire une migration à l’occasion, ça sera certainement moins galère que celle en cours :slight_smile:

En tout cas @naboleo je valide ta réponse, qui a couvert pas mal de mes problèmes.

Merci à tous !

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.