J’ai migré de Jessie à Buster mon raspberry pi. C’est ma centrale domotique principale. Elle héberge plusieurs services dont

• Homebridge, un portail permettant d’attaquer le serveur par l’écosystème apple homekit
• apache/php/mariadb/python et mon système diego qui permettent de gérer l’état de quelques modules domotiques fabriqué maison, et qui pilotent entre autres le module ci-dessous
• telldusd, qui me permet de piloter des (micro)modules RF 433MHz

Ce qui m’a motivé à faire cette mise à jour, c’est l’acquisition d’un module LoraTap pour piloter un volet roulant électrique. Celui-ci s’intègre parfaitement dans le homebridge grâce à l’extension milo526/homebridge-tuya-web. Or, celui-ci nécessite une version récente de node.js.

Sauvegarde de l’installation

J’ai suivi 2 tutos pour la sauvegarde. Le premier nécessite de débrancher le serveur, et consiste à faire une image de la carte SD, en suivant ce genre de tuto: https://all3dp.com/2/back-up-raspberry-pi-sd-card/. Ça consiste à

• Connecter dans mon cas sur mon mac la carte SD
• Lancer l’utilitaire de disque
• Afficher tous les appareils (menu présentation)
• Faire une image sur le disque

Le deuxième tuto me parait beaucoup plus élégant. J’ai itéré plusieurs fois dessus, en modifiant quelques options de la ligne de commande. Au final, sur le raspberry pi, j’ai fait

sudo tar -cvp --one-file-system / /boot | nc -q 0 192.168.1.10 1024

J’ai oublié le /boot lorsque je l’ai fait, mais sans conséquence puisque je n’en ai pas eu besoin
Sur la machine de destination:

nc -l 1024 > backup.tar

1024, c’est le numéro de port. Ça peut prendre à peu près n’importe quelle valeur.

Mise à jour du système

Pour faire la mise à jour du système, j’ai modifié mon /etc/source.list, sur la ligne

deb http://raspbian.raspberrypi.org/raspbian/ jessie main contrib non-free rpi

J’ai modifié jessie en buster, puis

sudo apt-get update
sudo apt-get dist-upgrade

Après cette manip, j’avais des messages bizarres me disant que certains paquets n’étaient pas mis à jour. J’ai insité, mais au final, c’est mon paquet telldus qui a disparu, car dépendant de librairies obsolètes.

Recompilation de telldus-core

J’ai donc suivi un autre tuto

Après quoi, j’ai dû mettre à jour le chargement des librairies pour qu’il les trouve en ajoutant un fichier contenant /usr/local/lib/ dans /etc/ld.so.conf.d/telldus.conf, puis relancé ldconfig.

Ajout du service telldusd

teddusd, le démon de telldus-core ne se lançait pas seul. Pour cela, j’ai dû recréer un service. L’ancienne façon ne me convenait pas, avec un fichiers dans /etc/init.d. Pour une raison qui m’échappe, il ne lançait pas correctement le démon. J’ai fini par re-créer un fichier trouvé dans https://aur.archlinux.org/cgit/aur.git/tree/telldusd.service?h=telldus-core-git pour créer le fichier telldusd.service ci-dessous, à mettre dans /lib/systemd/system/telldusd.service

[Unit]
Description=Telldus-core service telldusd
After=basic.target

[Service]
Type=forking
PIDFile=/run/telldusd.pid

ExecStart=/usr/bin/telldusd

ExecReload=/usr/bin/kill --signal HUP "${MAINPID}"

[Install]
WantedBy=multi-user.target

et à partir de là, j’ai mis à jour la cache de systemd par

sudo systemctl daemon-reload

puis, je pouvais lancer telldusd

sudo system start telldusd

Je redémarre la machine pour m’assurer que ma configuration résiste à un reboot. C’est le cas. Puis j’essaie mon front-end web diego. Mais il ne fonctionne pas. Après une multitude d’essais, je comprends que c’est apache qui est lancé par systemd avec l’option PrivateTmp=true.

Cette option crée un répertoire /tmp différent pour le service, améliorant la sécurité. Mon problème est que telldusd utilise des pipes nommés dans ce répertoire pour communiquer avec l’outil tdtool. Ainsi, mon code php ne peut y accéder. J’ai commenté cette option dans le fichier service /lib/systemd/system/apache2.service, et ai relancé le service. Depuis, ça fonctionne très bien.

Enfin, j’ai mis à jour la configuration de homebridge pour intégrer mon volet roulant, et voilà !

Ça m’a valu quelques soirées à travailler pour démêler tout ça. Au final, je suis satisfait d’avoir mon serveur qui fonctionne à nouveau, qui a une installation plus récente. J’ai pu renouveler l’export de mes services perso via homebridge. J’ai aussi améliorer mes connaissances en matière de services.

J’aurais aimé une solution un poil plus élégante, du genre changer l’emplacement des fichiers socket ailleurs que dans /tmp. Mais c’est codé en dur dans telldus-core, et ne souhaitais pas modifier plus ce code. J’aurais bien vu quelque chose dans /var/run. En vrai, mon serveur apache n’est pas exposé à l’extérieur de mon LAN, ou très peu, et ponctuellement. Donc cette sécurité supplémentaire n’est pas critique.

Ça y est. Avec le serveur mysql, ça commence à faire trop opur le dockstar. Les temps de réponses sont trop long pour que l’interface soit agréable. J’ai donc décidé de le migrer vers un raspberry pi 2.

Pour la migration, facile ! J’ai pris une raspbian. Ensuite, j’ai cherché à récupérer la liste des paquets que j’avais installé.  Pas si évident. J’ai du tricoter un peu:

On extrait la liste des

sudo apt-get dotty > paquets.txt
grep -- "->" installed.dot | grep -v springgreen | cut -d \" -f 2 | sort -u > installed
grep -- "->" installed.dot | grep -v springgreen | cut -d \" -f 4 | sort -u > dep
grep -vf dep installed > min_list

Et voilà, dans min_list, la liste des paquets installés.

J’ai tout de même fait la même chose sur mon autre install avant de commencer afin de retirer la liste des paquets en commun, celle de la distrib.

Je finissais alors avec une liste d’une cinquantaine de paquets, qui correspondaient à ceux que j’avais installés à la main.

Naturellement, j’ai réinstallé que ceux qui me semblaient nécessaires, à savoir apache2, mariadb, telldus-core, vim.

et hop, ça fonctionnait.

Prochaine étape: le SSL !