J'en ai rien à foutre, j'aurai mon bash dans mon compute
Je dédie cet article à toutes les organisations qui pensent qu’utiliser des machines Windows serveur distantes pour développer est une bonne idée.
Merci du fond du cœur de me donner de la matière pour faire tourner mon moteur à haine et produire du contenu journalistique de qualité bière 8.6 abandonnée au soleil.
J’aimerais prendre un moment pour dire à mes collègues présents ou futurs qui pourraient se sentir visés par cet article, que je n’ai absolument rien contre eux et que cet article n’a pas pour vocation d’attaquer personnellement des gens. Vous le savez, je n’attaque jamais les gens, seulement les outils et les situations.
J’ai une détestation presque viscérale pour travailler en environnement Windows et c’est d’ailleurs pour ça que je n’en fais pas. Je trouve ce système d’exploitation particulièrement crétin et problématique sur plein d’aspects, le plus gênant étant d’avoir la désagréable impression de ne pas le contrôler et de le subir.
Seulement voilà, dans mon environnement de travail actuel, après 6 mois passés sur CloudShell, je me retrouve contraint et forcé d’utiliser cet e-tron. Du coup je vous mets ici les bricolages que j’ai dû faire pour avoir un environnement de travail que je juge acceptable.
J’ai mal à mon GNU/Linux
Et mon script bash ? je le run comment ?
Il s’avère que je travaille sur un savoureux mélange de Bash avec des commandes gcloud qui génèrent du code Terraform. Tu vas me dire, il y a déjà une division par zéro dans ton truc, qu’est-ce que c’est encore que ce machin-là ? Ça ressemble juste à un lundi pour moi, haha !
En gros, j’ai fait un Apollo 13 (j’ai fait rentrer un truc carré dans un truc rond). J’ai 278 projets GCP à manager en Terraform et j’ai fait un script qui me produit le code Terraform associé à mes ressources (activation d’API, compte de service, gestion IAM folder + project).
Seulement voilà, j’ai fait tout ça avec CloudShell de GCP et je me retrouve coincé à cause de la taille du disque qui ne peut pas être étendue. (5 Go ce n’est pas beaucoup) Donc le process dans mon organisation actuelle, c’est de se connecter à une machine de rebond et à une machine Windows distante et ensuite de se connecter sur une machine Linux, on est sur le max du confort et de l’optimisation.
J’ai besoin de gcloud, Terraform et Bash et le repo git seulement disponible via cette machine Windows ou via un autre rebond Linux.
En télétravail je me retrouve avec :
- une connexion au gestionnaire de mot de passe + MFA
- un premier compte user password + MFA pour le VPN
- une interface web qui fait du web RDP vers un bastion
- une connexion vers une machine Windows serveur avec un autre compte et un nouveau mot de passe
- une connexion SSH supplémentaire dans mon Windows si je veux accéder en plus à une machine Linux
- un proxy qui doit être configuré sur la machine pour accéder au réseau (j’en parle ici vous allez comprendre pourquoi plus tard)
Ma machine locale étant restreinte, de toute façon c’est un Chromebook, j’ai l’impression de bosser avec des gants de boxe dans une piscine remplie de crocos avec des sacs de ciment aux pieds et un œil crevé.
Et dites-vous bien que j’aurais pu avoir une machine Windows client, mais ça implique des reboots intempestifs pour faire des mises à jour forcées du BIOS et de l’OS que je ne peux pas reporter. Mais finalement à côté, le Chromebook est un bonheur en termes de mise à jour et largement efficace pour faire du web et du GCP. Une mise à jour n’est jamais forcée et c’est juste un swap de version d’OS au redémarrage de la machine (qu’on peut faire quand on veut, mais forcé au bout de 3 jours). Donc ça prend tout au plus quelques secondes de redémarrage.
Du coup j’ai essayé par tous les moyens de faire rentrer mon besoin dans leurs contraintes, et j’ai voulu me servir de la machine Windows comme machine de dev principal et faire tourner WSL pour avoir mon bash qui marche.
Configurer cette machine Windows pour avoir un vrai bash
J’aurais pu utiliser Git Shell ou Cygwin, mais j’en ai vraiment marre de ces outils pseudo-shell bricolés, alors j’ai donné sa chance à WSL (Windows Subsystem for Linux) qui est une sorte de couche de compatibilité Linux installée dans Windows nativement. Ce qui me permet d’avoir un Ubuntu mais pas tout à fait, mais toujours plus proche que Git Shell et Cygwin. Moi je veux juste pouvoir faire mes installations de packages apt en paix et pouvoir faire mes scripts bash terriblement alambiqués tranquille.
Du coup vous l’avez compris, je profite de cet article pour documenter et compiler les workarounds dégueux que j’ai dû faire, au cas où j’ai besoin une prochaine fois de le refaire et peut-être vous économiser du temps si vous avez les mêmes problèmes.
Installer WSL c’est assez bidon, il faut juste des permissions admin pour pouvoir le faire, là où ça se complique c’est si votre machine Windows utilise un proxy et que vous ne pouvez pas utiliser la fonctionnalité d’utilisation du réseau hôte dans WSL. Par défaut WSL utilise un réseau naté et sa propre carte réseau, il faudra donc ruser pour l’accès internet, et on peut s’asseoir sur les outils de debug réseau et tous les protocoles hors http/https.
BTW: ne pas essayer d’installer WSL sur un compute Windows serveur sur GCP, y’a pas Hyper-V donc c’est pas possible
L’étape la plus simple en somme, c’est d’activer et d’installer WSL
Il faut lancer un PowerShell en mode administrateur
|
|
Donc là on pourrait dire c’est fini, tu peux faire tes trucs sur Ubuntu, terminé bonsoir, ça valait pas un article ton truc, je vais me coucher. Dans les faits oui, y’a un Ubuntu, mais seulement, impossible d’accéder à internet à cause du proxy qui n’est pas accessible depuis la machine WSL.
La galère commence
Donc là j’ai fouillé un peu, je me suis dit, boh ça doit être la machine Linux qui n’accède pas au proxy, probablement qu’en l’ajoutant dans la conf de ma machine Ubuntu (WSL), ça fonctionnera sans problème.
Alors oui mais non, je n’ai jamais réussi à atteindre le proxy depuis la machine Ubuntu directement car le réseau est naté entre la machine Ubuntu et ma machine Windows et le mode partage de la carte réseau de l’hôte n’était pas disponible sur cette version de Windows, rageant un peu non ? En fait, si la carte réseau de la machine Ubuntu n’adresse pas sur la plage de réseau de la machine Windows, le firewall empêche l’accès au proxy, yes.
Du coup bah, toujours pas d’apt install, tu peux te brosser Martine !
On m’a dit que t’aimais les proxy ? Du coup j’ai reverse proxifié ton proxy
Connaissez-vous l’ami Fiddler Proxy ? C’est un petit logiciel sympathique d’interception de trafic web, qui permet de faire un reverse proxy entre le navigateur et les sites qu’on visite, un genre de man-in-the-middle mais dans un but de debug et d’analyse. Eh bien il s’avère que cet outil peut aussi proxifier le trafic vers un proxy, pas mal non (c’est pas français) ?
Du coup, il faudra toujours avoir ce proxy allumé pour pouvoir faire des accès internet, mais ça me permettra de faire des installations apt et du trafic web.
Installation et configuration de Fiddler
Et donc bien sûr comme c’est un proxy d’interception de trafic, il a été flagué comme potentiellement malveillant par l’antivirus. Qu’à cela ne tienne, je le désactive le temps de l’installation. Alors avant, j’ai passé le binaire sur VirusTotal pour être sûr que le danger était écarté, et j’ai téléchargé mon installeur Windows depuis le site officiel de Fiddler.
Donc je me rends sur le super site du fabricant, qui te fait un jeu de piste et de la collecte de données abusive, comme si tu allais chercher ton binaire Java JRE sur le site d’Oracle.
https://www.telerik.com/download/fiddler-everywhere
Je remplis dûment mon formulaire avec mes données personnelles exactes et un email valide.
La résolution est floue et dégueulasse ? T’as envie de gerber ? Bienvenue dans un remote desktop Windows, doublement rebondi à travers une interface Web…
Une fois mon installation de cheval de Troie chinois, euh je veux dire mon super proxy de proxification, je réactive mon antivirus et c’est reparti pour une tour.
J’allume Fiddler et dans le menu Options > Connections, je choisis l’option Allow remote computers to connect.
Dans l’onglet HTTPS, je choisis l’option Capture HTTPS CONNECTs + decrypt traffic.
Ensuite, dans le même menu, il faut télécharger le certificat avec le bouton Action. On va plus tard installer le cert pour faire de l’HTTPS.
Donc maintenant qu’on a un Fiddler proxy, il faut connaître l’IP privée de la machine hôte Windows. Dans un PowerShell, il faut lancer ipconfig et récupérer l’adresse.
Retour dans WSL, peut-être que je vais avoir accès aux internets à un moment
Exporter cette variable le temps de faire apt update et installer au moins vim.
|
|
En gros, sans le certificat Fiddler, l’HTTPS ne fonctionnera pas, mais on peut au moins installer des packages avec apt et mettre à jour la machine.
|
|
Voici ce que ça donne un coup d’apt update en HTTP (depuis j’ai installé deux trois trucs comme gcloud ou docker, c’est pour ça que j’ai des repos en plus).
|
|
Et du coup je peux faire un curl en HTTP chez Google aussi avec le proxy.
|
|
Ouais, trop bien les jeux olympiques ! (J’ai reformaté et tronqué l’output, parce que sinon on a un énorme HTML sur une seule ligne et c’est pas joli)
Par contre, je peux manger mes dents avec de la sauce barbecue pour faire du HTTPS.
|
|
Ah CKC !
On persiste la configuration et on active le HTTPS
Donc on sait faire du HTTP, c’est sympa, mais sans HTTPS on a toujours une machine amputée de la plupart de ses fonctionnalités. Pas de script d’installation custom (genre je veux installer Docker avec get-docker.sh, par exemple), pas de gcloud, enfin c’est pas la joie quoi.
On va en profiter pour persister la configuration dans ~/.bashrc.
|
|
Avant de poser la question, non je n’ai pas trop picoler, on donne une adresse http pour le proxy https aussi, parceque le proxy fiddler n’à pas de vrai nom de domaine et il porte un cert autosigné tout naze donc on fait du https TKT, mais pas vraiment, mais un peu quand même.
Installer le certificat Fiddler dans le gestionnaire de certificats de WSL
Dans mon cas, le certificat est sauvegardé sur mon bureau.
Il faut convertir le fichier .cer en fichier .pem pour qu’il soit pris en compte comme un certificat “valide” par Ubuntu ensuite.
|
|
Ensuite, il faut le copier dans le dossier des certificats.
|
|
On donne les permissions suffisantes pour que la mise à jour du certificat puisse être effectuée par update-ca-certificates.
|
|
Et donc là, normalement, si les variables d’environnement sont correctement définies, on peut faire du curl en HTTPS et utiliser apt, à condition que le proxy Fiddler soit démarré en même temps.
Certificat certifiant la certification certifiante, d’après ma machine.
Maintenant, j’ai besoin d’installer et d’utiliser de vrais outils
Bon, c’est bien beau toutes ces conneries, mais moi, j’ai besoin d’utiliser de vrais outils, et ce serait bien que je puisse faire du git et du gcloud. Parce que dans mon organisation, ils ont un Bitbucket, mais accessible uniquement via les machines dans le réseau interne, là où se trouve ma machine Windows, bien entendu.
Installation de gcloud
Bon, je ne vais pas vous faire l’affront de copier-coller la documentation de gcloud,
il faut suivre la doc dans le lien, ça devrait aller, non ?
https://cloud.google.com/sdk/docs/install
Et du coup, maintenant qu’on a un proxy proxifié double Axel triple piquet (ceci est un hommage aux JO d’hiver), bien évidemment que Google gueule à juste titre que le trafic SSL n’est pas de confiance.
Désactiver la vérification SSL (oui, on a mis un certificat intermédiaire, mais ça ne suffit pas pour gcloud puisque c’est un certificat auto-signé).
|
|
|
|
Donc, on a une erreur SSL toute pourrie qui vous suivra partout pour vous dire que le setup est à chier.
Après avoir défini un projet dans gcloud, je lance une commande gcloud arbitraire pour voir si ça fonctionne.
|
|
Très bien, j’ai un gcloud qui fonctionne en mode super clodo.
Connexion au repo Git
Ça me fait une belle jambe d’avoir une interface web pour Git, mais par contre, c’est hors de question que je tape mon mot de passe à chaque fois que j’ai besoin d’interagir avec mon repo distant en ligne de commande.
Du coup, comme je ne peux pas utiliser SSH à cause du réseau NATé de WSL, et peut-être aussi parce que SSH est filtré sur Bitbucket, je passe par HTTP et le credential store. Je prends le lien HTTP de mon repo Git, je clone, et je lance cette commande pour stocker le mot de passe Git sur ma machine.
|
|
Bon OK, j’installe VSCode parce que sinon c’est trop la galère
Il faut reconnaître que le shell WSL n’est pas des plus pratiques à utiliser avec Vim, donc j’ai craqué et j’ai installé VSCode, qui s’intègre bien avec WSL puisqu’il a une extension faite pour ça.
Voici une image issue d’Internet qui illustre mon bureau sans montrer sur quoi je travaille chez mon client. L’intérêt, c’est d’avoir ma fenêtre de shell en même temps que mon code, comme je pourrais le faire en multi-fenêtres avec une distribution Linux desktop.
Et donc IDE okayish, shell Linux okayish, Bitbucket okayish, mais bon, ça casse bien les roustons.
Boss Final, mon besoin est trop déviant pour cette organisation
Donc, à partir de là, j’ai déployé des efforts conséquents, j’ai vraiment pris sur moi pour que ça fonctionne. J’ai passé au moins 2 semaines à régler mes différents problèmes.
Malheureusement, j’ai totalement abandonné cette machine.
Mon besoin Terraform est tel qu’il me génère plus de 50 Go de cache Terraform, parce que chaque projet génère un dossier avec un remote Terraform et un cache de plusieurs Mo. Ce n’est pas un problème quand on a 10 dossiers qui font du Terraform, mais dès qu’on commence à monter sur plus de 100 remote buckets, ça devient significatif.
J’ai demandé d’agrandir mon disque système, on m’a dit que ce n’était pas possible mais qu’on pouvait me mettre un NAS.
J’ai essayé de copier mon projet Git sur le NAS, mais au bout de plusieurs dizaines de minutes, j’ai laissé tomber. Impossible de lancer des scripts qui font des I/Os intensifs sur un NAS asthmatique.
Pourtant, le besoin n’est même pas si fou : lancer des commandes gcloud et écrire des dossiers et des fichiers avec Bash.
Conclusion
J’ai passé deux bonnes semaines à configurer une machine que j’ai abandonnée, l’espace d’un après-midi, pour configurer une machine Debian opérationnelle pour mon besoin sur GCP en moins de 15 minutes. Désolé, mais là c’est end game.
