Migration Stretch -> Buster

mich0111 · Janvier 7, 2020, 1:45

Bonjour,

Procédure de migration de Stretch vers Buster

Etapes identifiées:

Sauvegarde de la Jeedom
Vérification et externalisation de cette sauvegarde
Connexion SSH à la machine
Exécution des commandes suivantes :
cd /var/www/html/plugins; grep -R « object:: » * -------------------------------> vérification de la compatibilité Buster des plugins installés (si trop d’incompatibilités, stop)
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo cp /etc/apt/sources.list /etc/apt/sources.list_backup
sudo sed -i ‹ s/stretch/buster/ › /etc/apt/sources.list
sudo apt-get update
sudo apt-get dist-upgrade
sudo reboot
Connexion SSH à la machine
Exécution des commandes suivantes :
sudo apt remove php7.0*
sudo apt autoremove
sudo apt-get -y install php php-curl php-gd php-imap php-json php-mysql php-xml php7.3-opcache php-soap php-xmlrpc libapache2-mod-php php-common php-dev php-zip php-ssh2 php-mbstring
sudo apt-get -y install php-ldap
sudo /var/www/html/install/install.sh -s 2
for file in $(sudo find / -iname php.ini -type f); do
sudo echo « Update php file ${file} »
sudo sed -i ‹ s/max_execution_time = 30/max_execution_time = 600/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/upload_max_filesize = 2M/upload_max_filesize = 1G/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/post_max_size = 8M/post_max_size = 1G/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/expose_php = On/expose_php = Off/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/;opcache.enable=0/opcache.enable=1/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/opcache.enable=0/opcache.enable=1/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/;opcache.enable_cli=0/opcache.enable_cli=1/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/opcache.enable_cli=0/opcache.enable_cli=1/g › ${file} > /dev/null 2>&1
sudo sed -i ‹ s/memory_limit = 128M/memory_limit = 256M/g › ${file} > /dev/null 2>&1
done
sudo apt-get -y install mariadb-client mariadb-common mariadb-server
sudo a2dismod php7.0
sudo a2enmod php7.3
sudo systemctl restart apache2.service
sudo apt-get --purge autoremove
sudo apt-get purge $(dpkg -l | grep ‹ ^rc › | awk ‹ {print $2} ›)
sudo reboot
Relancer la machine

Mips · Janvier 7, 2020, 1:49

Bonjour,

Sur quel type de machine es-tu pour le moment? (je vois dans ton profil pi & i5)
Si tu es sous vm, à ta place

j’installerais une nouvelle sous buster,
nouvelle install jeedom
shutdown de l’ancienne (sans la détruire)
restore d’un backup jeedom sur la nouvelle
réinstallation des dépendances / branchement des dongles usb

Si problème, on éteint la nouvelle et rallume l’ancienne et c’est reparti.

nebz · Janvier 7, 2020, 2:00

d’après @Loic, il avait indiqué ceci :

https://community.jeedom.com/t/debian-buster-is-coming/1762/7

(voici une copie pour ceux qui n’ont pas accès au Salon Dev) :

apt-get update
apt-get upgrade
apt-get dist-upgrade
cp /etc/apt/sources.list /etc/apt/sources.list_backup
sed -i 's/stretch/buster/g' /etc/apt/sources.list
apt-get update
apt-get dist-upgrade
reboot
apt remove php7.0*
apt autoremove
apt-get -y install php php-curl php-gd php-imap php-json php-mysql php-xml php-opcache php-soap php-xmlrpc libapache2-mod-php php-common php-dev php-zip php-ssh2 php-mbstring
apt-get -y install php-ldap
/var/www/html/install/install.sh -s 2
for file in $(find / -iname php.ini -type f); do
    echo "Update php file ${file}"
    sed -i 's/max_execution_time = 30/max_execution_time = 600/g' ${file} > /dev/null 2>&1
    sed -i 's/upload_max_filesize = 2M/upload_max_filesize = 1G/g' ${file} > /dev/null 2>&1
    sed -i 's/post_max_size = 8M/post_max_size = 1G/g' ${file} > /dev/null 2>&1
    sed -i 's/expose_php = On/expose_php = Off/g' ${file} > /dev/null 2>&1
    sed -i 's/;opcache.enable=0/opcache.enable=1/g' ${file} > /dev/null 2>&1
    sed -i 's/opcache.enable=0/opcache.enable=1/g' ${file} > /dev/null 2>&1
    sed -i 's/;opcache.enable_cli=0/opcache.enable_cli=1/g' ${file} > /dev/null 2>&1
    sed -i 's/opcache.enable_cli=0/opcache.enable_cli=1/g' ${file} > /dev/null 2>&1
    sed -i 's/memory_limit = 128M/memory_limit = 256M/g' ${file} > /dev/null 2>&1
done
apt-get -y install mariadb-client mariadb-common mariadb-server
a2dismod  php7.0
a2enmod php7.3
systemctl restart apache2.service

mich0111 · Janvier 7, 2020, 2:00

Ma prod est sur I5, ma machine de test sur RPI3.
Pas de VMtexte en italique.

mich0111 · Janvier 7, 2020, 2:06

Ta réponse me fait penser que mes plugins domotiques ne retrouveront pas leur état initial après restauration.
Ai-je tort de le croire où c’est pour me faire peur que tu dis ça?

mich0111 · Janvier 7, 2020, 2:09

Merci,
l va falloir que je demande l’accès à ce salon, c’est non seulement instructif mais ça fait gagner pas mal de temps.
Il ne parle pas de la Jeedom proprement-dit dans son post?
Qu’en est-il de ce qui va se passer sur les plugins domotiques, faut-il les réinstaller, à minima relancer les dépendances, à maxima tout reconfigurer, … ?

nebz · Janvier 7, 2020, 2:11

sisi c’est concernant jeedom (il relance le step 2 de l’install)

pour les plugins, oui les dépendances

Mips · Janvier 7, 2020, 2:12

Je ne sais pas, ca dépend des plugins

D’ailleurs, rajoute une étape:
0. Inventaire des plugins et vérifier la compatibilité; d’abord juste pour la partie code (class object <> jeeObject) et/ou en les installant tous sur ta machine de test (que tu auras migré avant)

mich0111 · Janvier 7, 2020, 2:15

Très juste, mais y-a-t-il a un moyen simple de vérifier la compatibilité sans devoir checker les lignes de code?

Du coup, je me demande si ça présente un intérêt quelconque d’avoir écrit cette procédure. Celle de Loic est évidemment bien plus fiable.

nebz · Janvier 7, 2020, 2:18

cd /var/www/html/plugins; grep -R "object::" *

qui donne dans mon cas :

Monitoring/desktop/php/Monitoring.php~: foreach (object::all() as $object) {
XeeCloud/desktop/php/XeeCloud.php: foreach (object::all() as $object) {

lunarok · Janvier 7, 2020, 2:38

Après une migration (et même au quotidien), il est de bon goût de nettoyer un peu :
sudo apt-get --purge autoremove

Ca débarasse le système de tout ce qui n’est plus nécessaire (vieille lib, exe …)
Et celle là, nettoie les traces des paquets supprimés sans faire la purge :
sudo apt-get purge $(dpkg -l | grep '^rc' | awk '{print $2}')

Jeandhom · Janvier 7, 2020, 3:06

Tu as jusqu’en 2022 avant la prise en charge par la LTS.

https://wiki.debian.org/fr/LTS

mich0111 · Janvier 7, 2020, 3:25

Sur ma prod, le résultat du grep donne ça:

Est-ce à dire que ni enocean, ni rfxcom, ni zwave, ni jeeasy (pour le dernier, je m’en moque un peu) ne sont compatibles?
Si c’est le cas, il ne reste plus grand chose de ma domotique et je n’ai pas intérêt à migrer.
Mais, peut-être, n’a-jei pas dû bien comprendre.

nebz · Janvier 7, 2020, 3:29

tu as en effet pas bien compris,

tu as jeeasy (seulement les quelques modales), le panel de Monitoring et pushbullet.

mich0111 · Janvier 7, 2020, 3:32

Désolé, je n’avas pas fait attention que les 3 premières lgnes concernaient également Jeeasy.
Donc, il n’y a que pushbullet.
Pour ça, je peux trouver une autre solution.
Merci

akenad · Janvier 7, 2020, 3:39

Bonjour @mich0111,

Je privilégie la réinstallation d’une image système plutôt qu’une mise à jour afin de repartir sur un état connu.

akenad

nebz · Janvier 7, 2020, 3:45

oui sauf sur smart, d’ou le sujet m’intéresse

mich0111 · Janvier 7, 2020, 3:54

J’ai remis à jour le premier post en intégrant toutes vos remarques et une sauvegarde système.
Pourriez-vous me dire si je ne suis pas totalement à côté de la plaque et m’apporter vos éventuelles remarques?

Merci

nebz · Janvier 7, 2020, 3:55

t’as un doublon

mich0111 · Janvier 7, 2020, 3:56

Oui, c’est pas idiot, d’autrant plus qu’une fresh install de Debian n’est pas trop compliquée.
Ma crainte est qu’au redémarrage, il y ait plus de problèmes que dans l’autre cas.