Faudrait-il plutôt dire « réseau du bord », au vu de ce qui va suivre. Ce dernier sera en effet doté de plusieurs unités chargées de gérer le pilote, la cartographie, la navigation, le journal de bord, l’électricité et les loisirs.
État des lieux
En 2023 et 3024, j’ai ajouté à notre réseau quelques Raspberry Pi et Odroids. Ces petites bêtes fabuleuses ont pour avantage leur prix et leur faible rapport consommation / puissance. En revanche, côté logiciel c’est parfois plus compliqué, car le choix des systèmes d’exploitation est un peu plus restreint.
Composition du réseau informatique
Un petit résumé des machines que j’envisage d’installer sur ce nouveau réseau :
- Un Raspberry Pi 4 surmonté d’un HAT PyPilot gérera le pilote sous OpenPlotter. Le RPI4 est le serveur le plus puissant capable de supporter OpenPlotter (de manière stable) et PyPilot, tout en consommant très peu d’électricité. Il sera dédié aux tâches primordiales pour la navigation, telles que la gestion du réseau (DHCP + DNS), du pilote et du démon SignalK, sorte de nœud qui centralise l’ensemble des informations du bord (nmea, seatalk, victron…). Son horloge sera mise à jour automatiquement via GPS et il servira de serveur de temps (service ntp) pour la synchronisation de l’ensemble des horloges du bord.
- Un Raspberry Pi 3B+ doté d’un HAT 4G global, peu consommateur, fera office de routeur et de passerelle internet. Un point d’accès wifi permettra de se connecter à internet en dehors du réseau du bord.
- Mon Odroid n2+ maintiendra son rôle d’ordinateur de bord principal, avec cartographie, météo, tableau de bord et divers services utiles pour la navigation. Ce SBC propose un très bon rapport puissance / consommation, une alimentation 12V et un refroidissement 100% silencieux.
- Le Raspberry Pi 5 surmonté d’un HAT Nvme servira de NAS, d’ordinateur « média » avec une interface kodi et d’ordinateur de bord de secours. Le serveur média devrait être accessible via un point d’accès dédié, utile pour le projecteur ou des tablettes. Je le doterai certainement d’un serveur Nextcloud.
- Un Thinkerboard situé à l’extérieur (en France) s’occupera de réceptionner et chiffrer des sauvegardes, de même que mon hébergement o2switch.
- Des Raspberry Pi Zero 2 W seront parfaits pour équiper Arthur de caméras (pour les glaces et les manœuvres) et capteurs (qualité de l’air, etc.). Les capteurs se raccorderont à OpenPlotter tandis que les caméras seront accessibles sur l’ordinateur de bord ou les ordinateurs de travail.
- Les SBC restants (Odroids C2, RPI < 3) me serviront à monter des clusters et à faire des tests… ils auront peut-être une autre utilité plus tard.
- Enfin, un mini-ordinateur N100 et un ordinateur portable X86_64 serviront de support aux systèmes de toute la famille… qui sont hébergés sur des clés USB ou des disques externe.
Systèmes personnels sur clé USB / disque externe
Depuis que j’ai découvert que mon disque USB-C était plus rapide que le disque interne de mon petit ordinateur tout neuf (y compris pour les accès en écritures), j’ai adopté cette solution très pratique pour que chacun puisse balader son système où il veut. D’autres ordinateurs X86_64 pourront de cette manière servir de support matériel, y compris ceux de la maison, des amis, etc.
Choisir un système d’exploitation UNIX / Linux
C’est sur ce point que porte mes réflexions du moment. J’ai en gros cinq possibilités :
- Utiliser les OS recommandés, en général basés sur Debian ou Ubuntu.
- Mettre en place un réseau d’ordinateurs basés sur Arch Linux et ses dérivés.
- Basculer sur FreeBSD / OpenBSD.
- Uniformiser avec une solution portable et simple telle que Diet Pi.
- Sécuriser et automatiser avec un OS immuable et déclaratif tel que NixOS.
La première solution ne me plaît pas trop, car les systèmes des odroids sont vieux et pas mis à jour, en particulier la distribution Ubuntu de l’odroid n2+. De plus, j’aimerais éviter une distribution basée sur APT pour les paquetages.
La deuxième solution serait vraiment bien, car je commence à maîtriser les systèmes Arch, donc la documentation est très complète et à jour. Seul problème, Arch n’est compatible qu’avec les processeurs x86_64, le projet Arch-ARM semble presque abandonné et je ne sais pas encore ce que valent les supports ARM des distributions annexes telles que Manjaro et AndeavourOS. A suivre.
Ce qui me plaît dans la solution BSD, c’est d’une part la robustesse de ces systèmes qui ont eu la bonne idée d’améliorer leurs outils historiques plutôt que d’en changer tous les 4 matins, d’autre part de retrouver une solution que j’ai utilisée par le passé et qui fut une très bonne expérience. Cependant, certains logiciels devront certainement être compilés pour être portés et il me faut expérimenter le support ARM.
La solution DietPi, bien que basée sur Debian, est intéressante pour sa portabilité et ses optimisations dédiées aux SBC. Un système qui fonctionne bien et qui ferait gagner beaucoup de temps, mais qui malheureusement ne me convient pas à cause de ses outils qui nécessitent une configuration sous-jacente compatible. J’ai notamment tenté d’y installer ma conf dnsmasq basée sur un pont réseau maison, une expérience douloureuse.
Choisir NixOS serait en théorie parfait, car cela permettrait pour chaque ordinateur de déclarer dans un fichier unique l’état des systèmes et ainsi permettre à chacun d’eux de tourner de manière stable, fiable et reproductible. Mes premiers essais m’ont d’ailleurs bluffés ! Ce mécanisme serait vraiment adapté pour une société qui doit gérer des centaines d’ordinateurs monotypes… exit Puppet et Ansible, bonjour la simplicité et l’efficacité. Les principaux freins sont la courbe d’apprentissage assez raide et les différences importantes qu’il y a entre un NixOS et une distribution Linux classique. Quant à la portabilité sur ARM et Aarch64, cela semble fonctionner sur le papier mais reste à vérifier. Une solution à garder sous le coude.
La liaison satellite Iridium
La liaison satellite (chère, très lente et instable) via Iridum est directement connectée à l’ordinateur de bord. Une routine déconnecte tout ce qui pourrait faire des appels au réseau internet au moment de la connexion, pour laisser l’exclusivité à l’application météo.
Limiter les accès à internet
Le point qu’il faut que j’optimise encore est la stratégie pour limiter les accès à internet, en particulier pour une utilisation à l’étranger. Le fait d’avoir plusieurs systèmes qui utilisent des sources de paquetages différents n’est pas vraiment optimal. Il reste donc à faire un choix sur le système d’exploitation universel à utiliser à l’avenir, en particulier quand il faudra partir en long voyage.
