Sbinske et ZimaOS : créer un serveur rétro pour LAN party

À la rencontre de sbinske

sbinske se décrit comme un utilisateur non professionnel de la technologie et un amateur de projets DIY. Cette distinction est importante dans cette histoire. Il n’abordait pas ZimaOS comme un administrateur système à la recherche d’une autre plateforme à comparer. Il l’abordait comme quelqu’un qui aime construire, réutiliser du matériel et obtenir un résultat concret sans transformer chaque projet en infrastructure d’entreprise.

Avant d’adopter ZimaOS, il a longtemps cherché une alternative à Unraid. Ce qui l’a attiré n’était pas une parité fonctionnalité par fonctionnalité. En fait, l’une des choses qu’il appréciait était que ZimaOS lui semblait plus léger et ne cherchait pas à être aussi étendu qu’Unraid.

Son projet de février 2026 est devenu un test très concret de cette idée : un système d’exploitation léger pour serveur domestique pouvait-il exécuter le mélange de conteneurs, de machines virtuelles, de réseau et de stockage nécessaire à une LAN party rétro ?

Une LAN party rétro est devenue le cas de test

Le serveur était préparé pour une LAN party à l’ancienne, où l’infrastructure devait fonctionner localement et prendre en charge l’événement sans dépendre d’un ensemble de services externes.

Au moment où il a documenté son installation, ZimaOS exécutait déjà deux conteneurs Docker : un serveur TeamSpeak et un serveur DNS. À leurs côtés se trouvaient trois machines virtuelles : un ETI-SyncServer, une VM LanPage et une autre VM destinée à organiser les services restants autour de l’événement.

C’est cette charge de travail qui a rendu le projet plus intéressant qu’un simple test de NAS. Le stockage n’en était qu’une partie. Le système devait également héberger des services réseau et plusieurs machines virtuelles isolées en même temps.

Pourquoi ZimaOS s’est révélé être une alternative légère à Unraid

La comparaison de sbinske avec Unraid était délibérément pragmatique. Il ne s’attendait pas à ce que ZimaOS reproduise toutes les fonctionnalités d’Unraid. Il voulait un système plus modeste, couvrant les fonctions dont il avait réellement besoin et restant suffisamment compréhensible pour être utilisé par un amateur.

Une fois les problèmes matériels maîtrisés, son expérience globale a été positive. Le système a retrouvé un fonctionnement stable et a géré la charge de travail liée à la LAN-party qu’il avait mise en place.

La documentation actuelle de ZimaOS décrit toujours les machines virtuelles comme une fonctionnalité en cours d’évolution, tandis que le système dans son ensemble combine le stockage, les applications Docker et la virtualisation dans une même interface. Le projet de sbinske constitue donc un bon exemple de l’utilisation conjointe de ces éléments, plutôt que de traiter chaque fonctionnalité comme une démonstration distincte.

Le premier problème majeur ressemblait à un gel de ZimaOS

La configuration n’a pas démarré sans difficulté. sbinske a indiqué que ZimaOS se figeait complètement après environ 20 minutes de fonctionnement.

Après avoir vérifié les journaux et testé les composants, il a attribué la première série de problèmes à une ancienne NVIDIA GeForce GT 710. Il a tenté d’installer manuellement les pilotes via le terminal, mais cela n’a pas résolu le problème. Il a également expérimenté des modifications liées aux disques virtuels, sans succès.

Il a finalement retiré la carte graphique, réinitialisé le système et réinstallé ZimaOS sans celle-ci. L’installation propre a de nouveau fonctionné correctement.

Il faut considérer cela comme un problème de compatibilité signalé par un créateur sur sa machine spécifique, et non comme l’affirmation générale que chaque GT 710 est incompatible avec chaque version de ZimaOS. Les documents sources décrivent ce qui s’est produit dans cette configuration ; ils n’établissent pas une règle universelle concernant les pilotes.

La remise en place du GPU a révélé un problème matériel plus complexe

Lorsque sbinske a réinstallé la carte graphique, le comportement a changé. Au lieu de voir uniquement ce qui ressemblait à un problème de pilote graphique, la machine a commencé à déconnecter puis à redétecter à répétition les disques durs et les cartes réseau.

Les journaux affichaient des erreurs, mais il ne pouvait pas les attribuer avec certitude à un adaptateur réseau précis ou à la seule carte graphique. Il a donc changé de méthode de dépannage : retirer les composants matériels un par un et surveiller le moment où le système cessait de signaler des problèmes.

Ce processus a abouti au résultat le plus clair de toute la session de débogage. Le système était instable avec trois cartes réseau ajoutées, en plus de l’interface réseau intégrée à la carte mère. Avec seulement deux cartes réseau ajoutées, la machine fonctionnait correctement.

Il soupçonnait une répartition des lignes PCIe, mais ne l’a pas prouvé

Le serveur hôte n’était pas du matériel serveur conçu à cet effet. Il utilisait un AMD Ryzen 5 2600, une carte mère MSI B450 Plus et 64 Go de RAM — essentiellement du matériel de rechange disponible pour le projet.

sbinske soupçonnait que la combinaison de la carte mère, du processeur, de la carte graphique et de plusieurs adaptateurs réseau avait pu rencontrer un problème lié aux lignes PCIe ou à l’allocation des ressources. Mais il n’a pas poursuivi suffisamment l’enquête pour démontrer cette théorie, car la machine répondait déjà à ses besoins avec deux cartes réseau supplémentaires.

Cette limite est importante. Le résultat positif du dépannage est connu : en réduisant la combinaison de cartes d’extension, le système est devenu stable. La cause exacte, qu’elle soit électrique, liée au micrologiciel ou à l’allocation des lignes, reste une hypothèse du créateur et non un défaut confirmé de ZimaOS.

Une fois le matériel stabilisé, le serveur est resté stable

Après avoir réduit le nombre de cartes réseau et retiré la combinaison matérielle problématique, sbinske a indiqué que le système fonctionnait de manière stable.

Cela a changé sa perception du projet. Les blocages initiaux donnaient l’impression que l’installation n’était pas fiable, mais le comportement ultérieur suggérait une interaction plus complexe entre le système d’exploitation et un ensemble inhabituel de composants de bureau réutilisés.

Pour une configuration DIY, cette distinction comptait davantage que l’identification d’une cause première parfaite. Il était parvenu à une configuration capable de maintenir les services de sa LAN-party en fonctionnement, et deux cartes réseau suffisaient déjà pour le rôle qu’il avait prévu.

C’est dans l’App Store que ZimaOS semblait moins convivial qu’Unraid

La critique d’ergonomie la plus marquante du questionnaire de sbinske concernait l’expérience de l’App Store pour les conteneurs Docker tiers.

Son point de référence était Unraid : installer une App Store, rechercher le conteneur, suivre une description claire et un formulaire de configuration, puis l’installer. Il estimait que ZimaOS pouvait parvenir au même résultat, mais que l’ajout d’un conteneur inconnu ou tiers nécessitait trop de connaissances pour les non-professionnels et les amateurs.

Ces commentaires ont été recueillis en février 2026. La documentation actuelle de ZimaOS indique désormais que les utilisateurs peuvent importer n’importe quel fichier YAML Docker Compose, modifier directement les configurations, exécuter des stacks multi-conteneurs et utiliser des boutiques tierces gérées par la communauté. La documentation destinée aux développeurs décrit également beaucoup plus en détail le processus actuel de création des paquets pour l’App Store.

Ces fonctionnalités plus récentes n’effacent pas son expérience initiale. Elles fournissent un contexte utile : le flux de travail qu’il avait trouvé trop compliqué correspondait précisément à un domaine que ZimaOS a continué à développer plus tard en 2026.

La flexibilité du stockage était l’autre élément manquant

sbinske souhaitait également pouvoir répartir plus librement plusieurs disques en différents groupes de stockage pour des charges de travail distinctes.

Son exemple était pratique : une paire de disques pouvait être utilisée en RAID 0 lorsque la capacité et la vitesse comptaient davantage que la redondance, tandis qu’une autre paire pouvait être configurée en RAID 1 pour les données qui méritaient une mise en miroir. En particulier, sa charge de travail SyncServer nécessitait plus de 4 To d’espace, mais n’exigeait pas le même niveau de protection des données que son stockage plus important.

De son point de vue, pouvoir combiner des disques existants moins coûteux en ensembles adaptés à chaque charge de travail pourrait réduire le coût du matériel et permettre de mieux utiliser les disques déjà disponibles.

La documentation actuelle de ZimaOS couvre désormais les configurations RAID 0, RAID 1, RAID 5, RAID 6, JBOD et ZFS. Toutefois, la documentation publique examinée pour cet article ne confirme pas explicitement le flux de travail exact avec plusieurs ensembles RAID demandé par sbinske — par exemple, créer indépendamment un RAID 0 à deux disques et un RAID 1 distinct à deux disques sur le même hôte au moyen de l’interface utilisateur standard. Pour cette raison, cette page conserve sa demande au lieu d’affirmer qu’elle a été entièrement résolue.

La définition de la réussite selon un utilisateur non professionnel

Ce qui rend ce projet intéressant, c’est que sbinske n’a pas évalué le système en fonction du nombre de fonctionnalités avancées qu’il proposait. Il l’a évalué selon sa capacité à prendre en charge les services qu’il voulait réellement exécuter.

Après le dépannage matériel, la réponse était en grande partie oui. ZimaOS était plus léger qu’Unraid, mais cela convenait, car son serveur pour la LAN party n’avait pas besoin de toutes les fonctionnalités d’Unraid. Deux conteneurs Docker, trois machines virtuelles, un DNS local, la communication vocale, la synchronisation et des services de gestion d’événements suffisaient à rendre le serveur utile.

Ses critiques venaient du même état d’esprit pragmatique. Une installation plus facile des conteneurs Docker tiers réduirait la courbe d’apprentissage. Un regroupement des disques plus flexible pourrait réduire le coût du matériel. Une meilleure compatibilité avec les combinaisons inhabituelles de cartes d’extension pour ordinateur de bureau rendrait les projets fondés sur du matériel de récupération moins imprévisibles.

L’histoire est toujours en train de s’écrire

L’histoire de sbinske et de Zima est toujours en train de s’écrire. Son projet actuel a commencé comme une alternative légère à Unraid pour une LAN party rétro, puis est devenu un véritable test du comportement de ZimaOS sur du matériel de bureau réutilisé, avec une charge de travail combinant Docker et des machines virtuelles.

Le résultat final n’a pas été une première installation parfaitement propre. Il s’agissait d’un système DIY fonctionnel, obtenu grâce à un dépannage au niveau des composants : retirer la GT 710, réduire la combinaison de cartes d’extension, conserver les deux cartes réseau réellement nécessaires, puis continuer une fois la machine stabilisée.

Pour quelqu’un qui se décrit explicitement comme un amateur plutôt que comme un professionnel, c’est peut-être le résultat le plus utile du projet. Le système ne lui a pas caché tous les détails techniques, mais une fois la combinaison matérielle simplifiée, il lui a fourni l’environnement de serveur domestique plus léger qu’il recherchait.

Pour le contexte actuel de la plateforme, consultez la présentation des fonctionnalités de ZimaOS et la référence actuelle de configuration RAID.