Chaque fois que j’essaie de me connecter en SSH depuis mon bureau Windows 11 vers mon nœud Proxmox pour faire tourner un nouveau conteneur, cela se passe rarement sans problème. Parfois, la connexion est interrompue ; d’autres fois, il y a un problème d’autorisation. Mais je ne reçois aucun avertissement, aucun message d’erreur, juste du silence. J’ai donc redémarré le WSL, me suis reconnecté et j’ai continué. Je l’ai fait suffisamment de fois pour que ce soit de la mémoire musculaire maintenant.
Mon laboratoire à domicile exécute un hôte Proxmox avec une poignée de machines virtuelles exécutant divers services, un Raspberry Pi 4 et quelques cartes ESP32. Ces appareils fonctionnent 24h/24 et 7j/7 et se comportent exactement comme prévu. Et lorsque je souhaite les utiliser, l’environnement Linux le moins fiable est le sous-système Windows pour Linux (WSL) avec le terminal Windows.
Microsoft ne cesse de claironner que WSL semblera natif, mais n’a pas encore tenu cette promesse.
Connexes
5 raisons pour lesquelles j’ai arrêté le double démarrage de Windows et Linux sur mon PC
Cela n’en vaut tout simplement plus la peine.
Essayer d’utiliser WSL dans une configuration de laboratoire à domicile
Le mur que tu heurtes à chaque fois
WSL est censé être un centre de commandement. En tant que homelabber, je souhaite accéder à SSH aux nœuds Linux, tester les configurations Docker et tout gérer sans double démarrage sous Linux.
J’ai utilisé WSL sur Windows comme pont. Avec quelques ratés initiaux, je me suis familiarisé avec WSL pour gérer mes machines Linux. Mais il n’a jamais été assez rapide ni assez efficace pour lui faire entièrement confiance.
WSL2 est véritablement meilleur en termes de configuration, de compatibilité et de performances brutes – mieux n’est cependant pas la même chose que natif. Dès que vous commencez à travailler avec les solutions de contournement du système de fichiers Linux, de la mise en réseau et du relais USB, vous vous heurtez au mur. Ces problèmes restent ouverts sur GitHub.
L’accès aux fichiers de projet sous le point de montage de la fenêtre WSL (/mnt/c/) est lent par rapport au travail natif dans un système de fichiers Linux. En effet, WSL et NTFS sous Windows ne communiquent pas efficacement au-delà des limites du système d’exploitation.
Même si j’y parvenais, j’ai dû me battre pour obtenir les autorisations de fichiers, et il m’a fallu beaucoup de recherches pour découvrir le problème. En plus de cela, WSL2 m’oblige à utiliser un outil distinct pour gérer le relais USB, et je dois suivre manuellement la configuration en plusieurs étapes.
WSL fonctionne bien, jusqu’à ce qu’il vous rappelle que vous n’êtes pas natif
Les frictions transfrontalières existent toujours
Par exemple, j’ai connecté mon laboratoire à domicile avec Tailscale afin de pouvoir y accéder lorsque je suis absent. C’est ainsi que je prévois d’accéder à mon Pi, à mon nœud Proxmox et à mon NAS depuis n’importe où. Mais lorsque j’utilise WSL, ce n’est pas aussi simple. Lorsque j’interromps l’utilisation de la connexion active et que j’essaie de la reprendre, le nœud final devient inaccessible.
Après avoir lutté pendant plusieurs minutes, j’ai découvert que j’envoyais une requête ping au mauvais nœud. Le redémarrage de WSL est le seul correctif. J’ai écrit cela sur un post-it sur mon moniteur, et cela a survécu à deux réinstallations.
Suite à de nombreuses erreurs de permission avec /var/run/docker.sock, j’ai abandonné WSL et j’ai tout déplacé vers Docker Desktop. Mais cela a créé un nouveau problème : deux moteurs Docker s’exécutent en même temps, mais la CLI n’en choisit qu’un. Lorsque je change de terminal ou redémarre WSL, il peut choisir un autre moteur sans avertissement. C’est ainsi que j’ai atterri avec des Dockers en bonne santé, mais au mauvais endroit.
Laisser WSL fonctionner est un péché puisque la consommation de mémoire augmente régulièrement avec le temps. Si je laisse WSL en marche, le PC devient progressivement lent et la seule solution est de redémarrer WSL. Avec le recul, je compare toujours la facilité avec laquelle SSH s’exécute sur ma machine virtuelle Linux sur le nœud Proxmox.
Quand le WSL gagne-t-il sa place
Pas mal du tout, mais pas assez
Pour des tâches simples telles que les sessions SSH, l’exécution de scripts, la mise à jour du système d’exploitation et la synchronisation des fichiers sur le stockage, tout cela fonctionne bien avec WSL. Mais un laboratoire à domicile est rarement simple de par sa conception. Pour commencer, la personnalisation d’un réseau implique l’utilisation d’un DNS personnalisé, de VPN à tunnel divisé et de plusieurs VLAN. C’est pourquoi WSL trébuche le plus, car il ne peut pas gérer la suspension temporaire de la connexion active et sa reprise plus tard.
Abonnez-vous à notre newsletter pour les correctifs WSL et homelab
Obtenez un dépannage pratique de WSL et de laboratoire à domicile dans notre newsletter-abonnez-vous pour des correctifs pratiques, des conseils de configuration et des solutions de contournement réalistes pour les problèmes de SSH, Docker, de mise en réseau et de système de fichiers, ainsi qu’une couverture plus large pour les laboratoires à domicile.
Obtenir des mises à jour
En vous abonnant, vous acceptez de recevoir des newsletters et des e-mails marketing, et acceptez nos conditions d’utilisation et notre politique de confidentialité. Vous pouvez vous désinscrire à tout moment.
Je suis un flux de travail simplifié : SSH directement dans Pi ou Proxmox pour conserver les services contenus sur les machines respectives. Pour déplacer des fichiers, je préfère rsync. Cela fonctionne clairement pour mon homelab. Pourtant, il s’agit d’une solution de contournement.
C’est étrange puisque le WSL était censé supprimer exactement les frictions pour offrir une expérience native.
Connexes
WSL est génial, mais le réseau est un gâchis – voici comment je l’ai résolu
Ça ne devrait pas être si compliqué
Ne plus attendre un énième « presque natif »
WSL est la raison pour laquelle je n’effectue toujours pas de double démarrage sur mon bureau. Je continue de lire les changelogs, en espérant que la prochaine mise à jour rendra l’expérience vraiment native. Au lieu d’une multitude de nouvelles fonctionnalités, je souhaite des correctifs de base. Au-dessus se trouvent la gestion de la mémoire avec les versions, tout comme les processus normaux ; un réseau qui survit aux cycles de suspension et de reprise ; et de meilleures performances du système de fichiers, je n’ai donc pas besoin de changer de système d’exploitation.
Je m’en fiche si ces éléments ne contribuent pas à un bon message d’annonce de mise à jour. Je gère mon laboratoire à domicile composé de neuf appareils avec un comportement bien plus prévisible que dans une seule fenêtre de terminal sur mon PC principal. Un Raspberry Pi alimenté par un chargeur USB dans le coin est plus cohérent. Cela devrait déranger Microsoft plus qu’il n’y paraît.
*️⃣ Lien source :
Sous-système Windows pour Linux (WSL) avec le terminal Windows, 5 raisons pour lesquelles j’ai arrêté le double démarrage de Windows et Linux sur mon PC, SSH dans les nœuds Linux, WSL2 est vraiment meilleur, solutions de contournement USB passthrough, laboratoire à domicile avec Tailscale, tout déplacé vers Docker Desktop, synchronisation des fichiers sur le stockage, DNS personnalisé, VPN à tunnel divisé, plusieurs VLAN, , , , , Conditions d’utilisation , Politique de confidentialité , WSL est génial, mais la mise en réseau est un gâchis — voici comment je l’ai résolu , ne effectuez pas de double démarrage sur mon bureau,