Migration Stretch -> Buster

Tags: #<Tag:0x00007f2830cedc90>

Bonjour,

Procédure de migration de Stretch vers Buster

Etapes identifiées:

  1. Sauvegarde de la Jeedom
  2. Vérification et externalisation de cette sauvegarde
  3. Connexion SSH à la machine
  4. 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
  5. Connexion SSH à la machine
  6. 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
  7. Relancer la machine

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.

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
2 J'aimes

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

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?

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, … ?

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

pour les plugins, oui les dépendances

Je ne sais pas, ca dépend des plugins :slight_smile:

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)

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.

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) {

1 J'aime

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}')

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

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

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

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.

tu as en effet pas bien compris,

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

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

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 :slight_smile:

1 J'aime

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

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

t’as un doublon

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.