Ce blog est hébergé sur une Nintendo Wii

• Une vraie Nintendo Wii sert un blog statique Hugo avec NetBSD 10.1 et lighttpd ; pendant que l’expérience se poursuit, les lecteurs consultent des pages fournies directement par la Wii
• Contrairement à d’anciens ports amateurs, le port NetBSD pour Wii propose la dernière version stable ainsi que des builds daily HEAD, signe d’un état de maintenance suffisant pour y faire tourner une vraie charge de production
• L’installation consiste à softmoder la Wii pour lancer le Homebrew Channel, écrire wii.img.gz sur une carte SD, puis configurer SSH, un réseau statique, pkgin et lighttpd
• Le CPU monocœur PowerPC 750 de la Wii peut gérer du HTTP statique, mais il a du mal à traiter en parallèle de nombreuses requêtes chiffrées avec un TLS moderne ; Caddy prend donc en charge en frontal la terminaison TLS et la gestion des certificats ACME
• Malgré la contrainte nécessitant une Wiimote et une sensor bar après redémarrage, avec une consommation au repos d’environ 18 W et environ 13,2 kWh par mois, cette expérience ludique devient un véritable environnement d’apprentissage de l’infrastructure

---

Une expérience pour servir un vrai blog depuis une Wii

• Pendant la durée de l’expérience, une vraie Nintendo Wii sert ce blog
• La charge système de la Wii peut être consultée sur la page d’état live(-ish)
• Le point de départ est un intérêt pour l’exécution de systèmes d’exploitation généralistes sur du matériel qui n’est pas conçu pour un usage généraliste
• Il y a déjà eu par le passé des exemples comme Yellow Dog Linux sur PS3, PS2 Linux, Dreamcast Linux ou PSPLinux
• Toutefois, l’image du noyau de PSP Linux a été compilée pour la dernière fois en 2008, et Dreamcast Linux utilise un noyau 2.4.5 compilé en 2001, ce qui ne convenait pas à une charge d’exploitation au long cours

Le port NetBSD pour Wii rend l’expérience possible

• Dans la section des supports d’installation du site de NetBSD, la Wii apparaît aux côtés de cibles de premier rang comme le Raspberry Pi et les machines x86 classiques
• Le port NetBSD pour Wii pointe vers NetBSD 10.1, dernière version stable de décembre 2024
• Des builds daily HEAD sont également configurés pour la Wii
• Comme la maintenance était bien active, il devenait possible d’expérimenter le déploiement d’une vraie charge de production sur une Wii ; cette charge, c’est ce blog

Matériel et conditions de performance

• La Wii utilisée pour l’expérience a été récupérée à l’EMF Camp 2024 Swap Shop
• Le CPU monocœur Broadway de la Wii s’inscrit dans la lignée de l’IBM PowerPC 750
  • Cette famille remonte jusqu’à l’iMac Bondi Blue d’Apple en 1998
  • La puce commerciale équivalente, le PowerPC 750CL, a un TDP maximal de 9,8 W, avec une fréquence environ 33 % supérieure à celle de la version intégrée à la Wii
• Avec un seul cœur, une architecture de la fin des années 1990 et un TDP inférieur à 10 W, la puissance de calcul est limitée
• La famille PowerPC 750 est aussi utilisée dans le domaine spatial et satellitaire, et il existe une version durcie contre les radiations, le RAD750
  • Des documents de la NASA permettent de vérifier des cas d’utilisation du PowerPC 750
  • Des puces liées ont aussi été utilisées sur les rovers martiens Curiosity et Perseverance

Softmod de la Wii et installation de NetBSD

• Pour exécuter du code non signé sur la Wii, l’exploit Wilbrand est utilisé
• Wilbrand exploite la fonction d’enregistrement et de chargement de messages du Wii Message Board via une carte SD pour permettre l’exécution de code non signé
• Ce processus permet de démarrer HackMii et d’installer le Homebrew Channel
• L’opération nécessite l’adresse MAC de la console et la génération de fichiers à placer sur la carte SD ; un outil dans le navigateur se charge de ce processus
• L’exécution de Wilbrand posait problème avec les grandes cartes SDHC, et fonctionnait le mieux avec une carte non-SDHC de 1 Go
• La carte SD pour NetBSD se prépare en téléchargeant l’image wii.img.gz depuis le site de NetBSD
  • La Wii ne prend pas en charge les cartes SDXC ou plus récentes, la limite est donc de 32 Go
  • NetBSD se montre moins sensible que Wilbrand aux grandes cartes ; une carte SDHC rapide et de bonne qualité de 32 Go a donc été choisie
• Raspberry Pi Imager permet de gérer à la fois la décompression, l’écriture et la vérification de l’image
• L’image NetBSD pour Wii possède les métadonnées et la structure nécessaires pour être démarrée directement depuis le Homebrew Channel comme une application homebrew classique
• Le mérite revient à Jared McNeill, développeur NetBSD, qui semble être l’un des principaux auteurs du port Wii

Configuration initiale du système

• Après le démarrage de NetBSD, le clavier USB fonctionne correctement, mais SSH est configuré pour permettre l’administration à distance
• Le démon SSH tourne par défaut ; il faut définir le mot de passe root et ajouter PermitRootLogin yes dans sshd_config
• La configuration réseau statique se fait en modifiant /etc/ifconfig.axe0
• L’adaptateur réseau utilisé est l’adaptateur LAN Wii officiel RVL-015
  • Dans dmesg, il apparaît comme un contrôleur Ethernet USB 2.0 10/100 ASIX Electronics AX88772
  • Après le démarrage de NetBSD, les pilotes NetBSD étant utilisés, on peut s’attendre en théorie à ce que des adaptateurs USB classiques fonctionnent aussi

Gestion des paquets et configuration du serveur web

• Le gestionnaire de paquets pkgin de NetBSD s’installe avec pkg_add pkgin après définition des variables d’environnement
• Le chemin des paquets utilisé est https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/evbppc/10.1/All/
• Les paquets installés incluent bsdfetch, iperf3, lighttpd, nano et rsync
• Le serveur web choisi est lighttpd, adapté aux environnements contraints en ressources
• Le script rc d’exemple de lighttpd est copié dans /etc/rc.d, lighttpd=YES est ajouté à /etc/rc.conf, puis le service est démarré
• Le chemin par défaut du contenu statique est /srv/www/htdocs
• Le blog étant un ensemble de pages statiques générées avec Hugo, il a suffi de copier les fichiers avec rsync pour les servir directement en HTTP standard

Charge TLS et reverse proxy Caddy

• Après de longs tests de charge, le PowerPC 750 montre ses limites lorsqu’il doit servir simultanément plusieurs pages chiffrées avec un TLS moderne
• Pour libérer des ressources, certains services lancés par défaut sous NetBSD sont désactivés
  • devpubd, dhcpcd, inetd, mdnsd et postfix sont arrêtés
  • Dans /etc/mailer.conf, sendmail, mailq et newaliases sont remplacés par /bin/true afin d’empêcher le lancement des processus associés
• ntpd utilise 15,6 % de la RAM système et est donc désactivé
• La synchronisation de l’heure restant nécessaire, ntpdate time.cloudflare.com est ajouté au crontab pour s’exécuter toutes les heures à :42
• Au final, la terminaison TLS du blog est assurée par une instance Caddy placée devant la Wii
  • Caddy fonctionne comme reverse proxy et gère le chiffrement ainsi que les certificats ACME
  • Aucune option de cache n’est activée dans Caddy
  • Toutes les requêtes sont traitées directement par la Wii ; en incluant les images de cet article, le chargement complet de la page pèse presque exactement 1 Mo
• Les requêtes provenant de User-Agent de scrapers connus sont bloquées au niveau de Caddy pour éviter qu’elles n’atteignent la Wii
  • Le blocage s’appuie sur les User-Agents de scrapers connus

Configuration du monitoring d’état

• En déplaçant la terminaison TLS vers Caddy, il devient possible d’utiliser l’exporter Prometheus de Caddy
• Ces données sont importées dans une stack InfluxDB + Grafana pour surveiller la charge du site
• Aucun processus supplémentaire de type exporter Prometheus n’est lancé directement sur la Wii
• À la place, un petit script shell est créé, exécuté toutes les 15 minutes via crontab, et écrit l’état du système dans un fichier HTML à la racine web
• La page d’état affiche des informations comme uname -a et uptime
• La page d’état complète est disponible sur blog.infected.systems/status

Contraintes d’exploitation et consommation électrique

• L’ensemble fonctionne bien mieux que prévu, et l’installation s’est révélée simple
• Redémarrer NetBSD ne redémarre pas seulement l’application NetBSD : toute la console Wii redémarre et revient au menu Wii
• Après un patch du noyau ou une mise à niveau système, la Wiimote et la sensor bar deviennent des composants indispensables de l’infrastructure d’exploitation
• Lors d’un test basé sur le monitoring de l’onduleur, la Wii ajoute environ 18 W à la consommation totale du homelab lorsqu’elle est au repos
• Le calcul donne une consommation mensuelle d’environ 13,2 kWh
• Sur la base des tarifs d’électricité britanniques, cela revient à environ 3,47 £ par mois, moins cher que les VPS de certains fournisseurs cloud
• C’était une expérience amusante pour un long week-end, et si elle continue de bien fonctionner, elle sera maintenue quelque temps
• Ce type d’expérience est intéressant parce que les environnements de déploiement avec des contraintes artificielles sont de bons supports d’apprentissage

Mise à jour de février 2026

• Après la publication de l’article, plusieurs personnes ont indiqué comment faire démarrer directement la Wii sur NetBSD
• La méthode consiste à installer Priiloader puis à configurer NetBSD comme application Homebrew à démarrer automatiquement
• Avec cette configuration, une exploitation headless complète devient possible, sans Wiimote critique pour la mission

[ifmkl]

Ça me rappelle l’époque où je faisais tourner un serveur web sur un vieux téléphone Android inutilisé avec Debian installé dessus.

[ndrgrd]

Je trouvais étrange d’utiliser Caddy et lighttpd en même temps, mais on dirait que seuls les fichiers statiques sont servis par la Wii et que le reste est géré par Caddy sur une autre machine.