URL: https://linuxfr.org/users/brndan/journaux/notes-de-migration-vers-l-architecture-64-bits-de-debian-sur-un-raspberry-pi-3b Title: Notes de migration vers l'architecture 64 bits de Debian sur un Raspberry Pi 3B Authors: Brndan Date: 2023年07月13日T10:57:59+02:00 License: CC By-SA Tags: raspberry_pi, 64bits et debian Score: 22 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](https://lux.wyrm.fr/). 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é](https://cours.wyrm.fr/) 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](https://www.raspberrypi.com/software/), 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](https://github.com/nextcloud-snap/nextcloud-snap/issues/2265) 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](https://fr.wikipedia.org/wiki/ARM_Cortex-A53). 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. ```bash #!/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](https://www.raspberrypi.com/software/) 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 : ```bash 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 : ```bash 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.

AltStyle によって変換されたページ (->オリジナル) /