C’est pas trop la question ou le problème mais j’ai déjà expliqué que dans la vie on ne peut pas toujours repartir de zéro. dist-upgrade c’est parfaitement standard dans le monde linux, on ne reset pas son système à chaque changement de version, et heureusement ^^
Si je relance une install jeedom, et que je replace mon backup, je peux peut etre récupérer quelque chose, j’imagine ?
Il y a des procédures de recovery ? je vois rien dans la doc ? un health check, un truc pour dire ce qui est normal, ce qui ne l’est pas.
Un début de réponse: j’ai mariadb-server qui a sauté. La question qu’il va falloir que je me pose … c’est est ce que c’était le seul truc qui a sauté !
La procédure la plus propre est de faire une fresh install buster puis Jeedom puis restauration d’une sauvegarde.
Édit: ne pas oublier d’externaliser la dernière sauvegarde avant de faire la fresh install
J’ai pas souvenir d’avoir lu ton explication à ce sujet, ne pas pouvoir c’est surement pas le mot. Ne pas vouloir c’est un autre débat
La notion de standard est relative : Dans le monde professionnel Linux… Comment dire… C’est banni ce truc …
Quand on bricole c’est acceptable mais ça expose à des risques. Avoir une installation hybride en passant de Jessie => Stretch => Buster, c’est le meilleur moyen de tout foirer
Nada… ça servira à rien du tout.
Jeedom c’est pas fait pour faire du monitoring système… Il sait en gros se soigner lui-même mais pas plus
Ok, bah je ne vous embête pas plus, je vais continuer à réparer mon install.
Si jamais quelqu’un à fait l’upgrade buster et passe dans le coin, qu’il n’hésite pas à me dire, je pense qu’il y a un soucis d’upgrade php-curl également, la version installée par jeedom semble étrange.
J’ai écrit un tuto sur l’upgrade stretch → buster que tu peux retrouver, donc je connais bien le sujet.
J’avais pris un certain nombre d’avis auprès d’autres membres qui s’y connaissaient plutôt bien.
Tu peux retrouver ce tuto dans le forum.
La conclusion est ce que je viens de te dire.
L’upgrade est long, très long, très très long, te fait perdre des services qu’il faut réinstaller, laisse une config bancale et, au final, ne présente aucun avantage voire que des inconvénients.
Si tu veux le faire quand même, libre à toi.
Oh je crois en plus que j’étais tombé sur ton retour d’expérience, et que je me disais que c’était pas si mal, contrairement à d’autres upgrade que j’ai pu faire par le passé.
Je dois tourner la vidéo d’install de jeedom prochainement. Là c’est pas le moment et mon install date de 2016. Jusqu’à présent j’ai toujours mis à jour jeedom sans rien réinstaller, de version en version. Pour l’exercice, mais aussi parce que j’ai énormément d’intégration techniques dans mon raspberry pi, backup, onduleur, monitoring, … sans compter toute la sécurité que j’ai mise en place, et tout refaire, c’est pas du tout dezippe et install.sh, pour moi ce sera des heures de boulot. Donc je le ferai. Mais plus tard, en faisant en même temps une mise à jour matérielle par l’occasion, pour soulager mon RPI2B.
Pour l’instant, je fais au mieux avec ce que j’ai, et il ne me reste plus que zwave à remonter, et ce sera parti.
Pour moi c’est bon, j’ai suivi les diverses indications que j’ai pu trouver sur tes posts, mich0111, ou par d’autres.
Je ne sais pas si mon jeedom est 100% fonctionnel, je vérifie tout en ce moment, mais à part le swap qui a un comportement bizarre, tout le reste à l’air parfait !
Merci !
Concernant le sujet de mettre a niveau ou de repartir sur un système neuf.
Si il y a seulement jeedom et qu’on ne maîtrise pas Linux je pense en effet comme mic0111, c’est plus simple de réinstaller.
Mais sinon il vaut mieux mettre à niveau, Linux est quand-même bien fait.
Et il n’y a pas que les changements de version de la distribution, il est important de faire la mise à jour des services et paquets !
On est quand même sur un système qui est accessible de l’extérieur, et les maj corrigent les failles.
Et ces maj peuvent poser les même problème. . .
Attention, je ne sais pas ce que veut dire ton message, mais ici ce n’est pas linux qui était en vrac, c’est jeedom qui ne repartait pas. Je n’ai eu aucun soucis avec raspberry pi os, l’upgrade c’est superbement bien passé. Je dis superbement, parce que entre jessie et stretch ça a été une autre histoire, si je me rappelle bien, avec les changements de la manière de gérer le réseau et les uuid de partitions.
Mais là, j’étais serein, c’est la partie apache et dependences jeedom qui n’a pas été correctement réalisé.
J’en suis pas à dire qu’il faut dire à tout le monde de faire ainsi. Mais ici, je suis sur le forum communautaire, pas sur la page Facebook, et j’attends effectivement le niveau d’info que j’ai trouvé chez lamor ou mich01111, pas un guide du « tu fais reset et tu réinstalles ». C’est pour moi une solution de dernier recours.
edit: surtout que dans mon cas ce qui bloquait c’était mettre à false une config apache et le redémarrer. Faire réinstaller pour ça, faut vraiment pas pousser ^^ (évidemment, ça nécessite de pouvoir diagnostiquer ce qui ne va pas)
Ben à titre perso tu peux toujours monter la version comme tu le fais là.
Fonctionnellement c’est pas l’idée
tu te traines des repository périmés
tu conserves des libraires anciennes qui servent à rien, sauf à ralentir le système
les versions de python 2/3 et les conflits qui vont avec
ça remet les valeurs par défaut
Bref, c’est vraiment pas propre. Dans le cas, où tu utilises le PI pour autre chose, je comprends bien que c’est plus long…
Mais sachant que Jeedom est quand même pas fait pour cohabiter avec autre chose et à quand même tendance à se croire seul sur le PI, faire de la mutualisation ici, c’est un choix que je ne fais plus. Encore plus quand l’installation du système global (monitoring etc) est critique
On peut polémiquer pendant des années, mais je traine un RPI2B qui n’est certainement pas la plus grosse plateforme pour faire tourner jeedom, et ça tourne très très bien, c’est ultra réactif pour ce que c’est.
Et je n’ai jamais parlé de mutualisation, j’ai dis que dessus j’ai des intégrations. Par exemple, reconfigurer nut, ça ne se fait pas comme ça. Et c’est qu’un exemple. J’ai mes backups externalisés qui sont réglés via scripts. Il faut le remettre en place, le retester quand on repart de zéro.
J’ai la sécurité, avec user dédié et audit que j’ai réalisé. Je réinstalle, je recommence. J’ai la configuration technique: IP fixe, DNS statiques, et autres joyeusetés (swapiness par exemple) que j’ai hardcodé pour supporter toutes les pannes possibles et imaginables que j’ai eu ces dernières années.
Je pense que c’est de la folie que de faire croire qu’on peut prendre la première image raspberry os qui traine, balancer jeedom dessus, et c’est reparti.
Une vraie installation jeedom en production, pour moi, c’est beaucoup plus de réglages que ça quand on est en DIY.
Nut, je sais pas trop, mais la config IP/DNS et swappiness c’est 15 secondes chrono…
Les backup externalisés, ça doit aussi pourvoir se gérer sans trop de souci le temps de la remise en état.
Les intégrations, à voir ce que c’est mais je suis quand même dubitatif.
ça sert à quelque chose ? Si jeedom, veut faire un truc, il est soit www-data, soit avec les droits sudo… J’imagine pas trop ce que ça apporte de mettre de l’audit.
Perso j’ai tout scripté pour gérer ça… Non seulement ça trace les modifs, mais on gagne vachement de temps. Je fais ça au fur et à mesure et c’est pas trop consommateur. Et on est certain d’être idempotent
Bref, c’est pas le but du sujet c’est certain mais il y a des soluces
