Journal Notes de migration vers l'architecture 64 bits de Debian sur un Raspberry Pi 3B

Sommaire

• • La petite machine
  • Le problème
  • Réinstallation d’un OS 64 bits et restauration
    • La sauvegarde
    • La réinstallation
    • Les premières choses à faire
    • Les fichiers de config
    • Récupérer les données
    • Réinstaller les paquets
    • Restaurer la base de données
    • Le mot de la fin

Voici quelques notes prises à l’occasion de la migration d’une Raspbian 32 bits au même système, mais en 64 bits.

La petite machine

Il s’agit d’un Raspberry Pi 3B (rev 1.2) de 2015 qui joue depuis près de 8 ans fidèlement le rôle de serveur :

• partage local SMB ;
• hébergement du site Wordpress de l’artiste Lucy Nuzit. Allez-y, ça vaut le détour (je suis parfaitement objectif). À ce propos, si vous avez des commandes à lui passer pour votre association, institution, éditeur, ou une proposition d’exposition, n’hésitez pas à la contacter ;
• hébergement d’un site destiné aux élèves du secondaire qui préparent les épreuves anticipées de français du baccalauréat ;
• une instance freshrss, indispensable pour la veille ;
• une instance Nextcloud.

La carte est vissée dans un boîtier avec un disque dur de 1 To connecté en USB qui permet aussi l’amorçage du système : il n’y a plus de carte SD depuis belle lurette. Le disque dur est bien moins cher au Go, et surtout bien plus fiable vu la quantité d’écriture sur le système.

Le tout est gentiment propulsé par Raspberry Pi OS, de mise à niveau en mise à niveau, jusqu’à aujourd’hui une base Debian 11 (Bookworm est sortie, mais pas sa déclinaison de chez Raspberry à ce stade).

Le problème

Tout fonctionnait à peu près correctement. Les ennuis viennent essentiellement de Nextcloud.

Nextcloud fonctionne plutôt bien sur ce matériel. Les 1024 Mo de RAM ne sont pas un problème quand l’instance compte seulement 3 utilisateur·ices. De version en version, les exigences techniques pour maintenir un niveau de réactivité efficace au quotidien se sont faites plus pressantes. Il a fallu modifier les schémas de la base Mariadb, gérer sa montée en version ainsi que celle de PHP, configurer PHP, mettre en place le cache, déployer une base Redis en plus. Dans l’ensemble, le système fonctionne très bien, au point qu’il est depuis plusieurs années utilisé en permanence pour nos besoins professionnels.

Pour donner une idée sudo -u www-data du -h /var/www/nextcloud → 31G.

Mais ces derniers mois, je me suis heurté à un mur : le support de l’architecture armhf, historique du Pi depuis ses débuts, a commencé à sérieusement battre de l’aile. Une mise à niveau s’est d’abord très mal passée parce que certaines variables dans le code étaient écrites avec uniquement un OS 64 bits en tête. Le bug est apparu, a été corrigé, puis est réapparu, et finalement l’annonce est tombée : fin du support 32 bits.

Utiliser une instance Nextcloud sans mises à jour de sécurité à la fin du support n’a rien de réjouissant, surtout quand on utilise le système au quotidien.

Les RPI 3B ont un processeur 64 bits. Sur le principe tout était donc possible, mais les quelques pages consacrées aux tentatives de crossgrade faisaient surtout le récit d’échecs lamentables ou de considérations de haute volée expliquant que c’est trop compliqué.

Une seule solution rapide, donc : repartir sur une base propre.

Réinstallation d’un OS 64 bits et restauration

La sauvegarde

Pour la sauvegarde, ce n’était pas très compliqué. J’avais déjà un script très court qui procède à une sauvegarde, avec un cron qui l’exécute chaque nuit.

#!/bin/bash

cd /
mysqldump --all-databases -uroot -pXXXXXXXXXX --default-character-set=utf8mb4 | zstd - > /backup/dump.zst
mysqldump -uwordpress -pYYYYYYYY wordpress_db | zstd - > /backup/wordpress_db.zst # au cas où

dpkg --get-selections > /backup/packages.txt

rsync -e "ssh -i /zzzzz/id_ed25519" -axvz --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/var/swap"}  /   user@user.rsync.net:/data1/home/user/backup

Simple et rustique, mais très efficace, justement pour cette raison (par ailleurs, j’ai confiance en la plateforme qui héberge les données, sinon il faut chiffrer.)

Pour assurer ses arrières, il suffit d’une adaptation du script et de faire la même chose avec un disque dur externe.

Prendre un snapshot avec dd n’avait pas grand intérêt : déjà parce que ça aurait été très long, ensuite parce que de toute façon les données étant sauvegardées, par question de revenir en arrière.

La réinstallation

On se lance. Le début n’est pas très compliqué : l’outil mis à disposition a l’avantage sur dd de préconfigurer certains éléments : l’utilisateur, ssh, etc. L’importation des clés SSH n’a pas bien marché, mais par précaution j’avais configuré la connexion par mot de passe pour éviter les ennuis de cette nature.

Les premières choses à faire

Une fois que le système a redémarré une ou deux fois, et est branché en ethernet, il suffit de se connecter en SSH. Évidemment comme on se connecte d’ordinaire avec une clé, là il faut penser à utiliser une commande différente :

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@domain

La première chose à faire, c’est d’installer tmux. La deuxième, c’est de restaurer les clés publiques pour accéder au serveur, puis les clés privées du serveur pour accéder aux sauvegardes distantes.

Les fichiers de config

Une fois que c’est fait, il suffit d’un mv /etc/ssh /etc/ssh.bak && rsync -a user@user.rsync.net:/data1/home/user/backup/etc/ssh /etc && systemctl restart ssh

Si ça ne fonctionne pas, on a toujours la connexion ouverte dans le premier shell, à ne surtout pas fermer tant qu’on n’est pas certain d’arriver à se connecter avec la clé.

À partir du moment où ça fonctionne, ce n’est plus très compliqué. Dans /etc, il suffit de répéter l’opération qu’on a fait pour SSH et récupérer les éléments importants, comme :

• letsencrypt
• apache2
• php
• mysql
• fail2ban

et quelques autres. Pourquoi pas tout /etc ? Parce qu’après 8 ans de mises à niveaux et de configurations modifiées, il m’a semblé utile de repartir sur des bases saines.

Récupérer les données

Même opération, avec une subtilité.

rsync -a user@user.rsync.net:/data1/home/user/backup/var/www /var

Sous Debian, les paquets créent un utilisateur www-data pour apache, qui a évidemment un accès limité au système. En gros, tout ce qui est dans /var/www lui appartient. Or le userid de mon ancien utilisateur www-data ne correspondait pas au nouveau, puisque d’autres utilisateurs avaient été créés. Un coup de sudo chown -R www-data:www-data /var/www/* règle l’affaire.

Réinstaller les paquets

Là on arrive à la magie des gestionnaires de paquets. Vous vous rappelez que le script sauvegardait à la fois tous les fichiers, mais aussi une liste des paquets installés :

dpkg --get-selections > /backup/packages.txt

En l’ouvrant, je me suis rendu compte que je n’avais pas anticipé un certain nombre d’occurrences de l’architecture : armhf. Qu’à cela ne tienne, un coup de sed -e 's/armhf/aarch64/' sur le fichier, et on est prêt·e à le donner en entrée au gestionnaire de paquets :

apt update
apt-cache dumpavail | dpkg --merge-avail
dpkg --set-selections < newpackages.txt
apt-get dselect-upgrade

Le gestionnaire de paquets avertit que certains vieux machins ne sont pas disponibles pas, mais ce n’est sans doute pas trop grave, il doit s'agir de résidus d'installations précédentes. En tout cas, ça n'a pas l'air bloquant. Hop ! On saute le pas. Il faut faire attention une fois que les paquets ont été téléchargés et que l’installation à proprement parler commence, à toujours exiger que la version du mainteneur n’écrase pas notre belle config qui marche. Le plan se déroulait à la perfection, chaque petite ligne permettait d'écraser une larme de satisfaction, au bout de 20 min…

La machine fige. Panique à bord. Après avoir espéré une demi-douzaine de minutes, de guerre lasse, il faut redémarrer. Et sur un pi, redémarrer, c'est débrancher la prise, littéralement, ce qui inspire toujours une confiance très relative. Au bout d’une minute après avoir rebranché, la connexion en SSH répond, le système semble stable… bon. Il faut finir la configuration des paquets par un dpkg –configure -a qui s’achève sans autre incident.

Restaurer la base de données

Restaurer mariadb, en fait, c’est tout simple. Mon script de sauvegarde exportait toute la base :

mysqldump --all-databases -uroot -pXXXXXXXXXX --default-character-set=utf8mb4 | zstd - > /backup/dump.zst

Avec précaution, il suffit de restaurer :

unzstd dump.zst
mysql -u root < dump

Le mot de la fin

Au redémarrage, tout fonctionne. Nextcloud, FreshRSS, Wordpress… tout roule, sans noter ni amélioration, ni dégradation des performances : de toute façon, avec 1Go de RAM et un disque dur en USB, il ne faut pas s’attendre à des changements extraordinaires. La mise à niveau de Nextcloud se déroule sans accroc. Mais bientôt, il faudra passer à Bookworm, puisque Nextcloud ne supporte plus php-7.4…

En tout état de cause, ce type de procédure est relativement facile à mettre en œuvre pour une solution auto-hébergée.