Guide de survie du Linuxien en environnement Windows

Nov. 27, 2019   0   61

Linuxien depuis plus de dix ans, il m'a récemment fallu sortir de ma zone de confort pour raisons professionnelles et affronter ma vieille allergie aux environnements graphiques à tiroir, pop up incessants et autres messages d'erreur sans logs. Voici ce que je retiens :

Cmder est ce qui se rapprochera le plus d'un terminal Unix avec Bash

Connaissez vous commander (ou Cmder pour les intimes) ? La description que l'on trouve sur le site du projet a attiré mon attention :

Cmder is a software package created out of pure frustration over the absence of nice console emulators on Windows

Sounds good to me. Dans les faits, vous pouvez voir Cmder comme un powershell intégrant out of the box plus d'alias issus de Bash, un client git et un client ssh. Dans un dossier versionné, cmder vous indique la branche du projet sur laquelle vous vous trouvez ainsi que si celle-ci contient des changement non-commités (un peu dans le genre de zsh). Bref, bienvenue chez vous.

Vous retrouverez quelques éléments de /etc

Je ne sais pas vous mais j'ai toujours apprécié la possibilité de binder localement certains domaines à des IP spécifiques. Outre un temps de résolution plus court, cela permet par exemple de tester localement une configuration serveur en ne changeant rien aux requêtes émises par le client. Sur Linux (resp OpenBSD, Solaris), vous éditeriez /etc/hosts pour que l'ensemble des services (client ssh, navigateur, etc...) héritent de cette résolution DNS locale. Sur Windows, je vous invite à aller jeter un œil à C:\windows\system32\drivers\etc

NTLM: Kesako?

Si le réseau LAN de la boite dans laquelle vous venez d'atterrir ne vous permet d'accéder à internet que par le biais d'un proxy et que l'ensemble des postes tournent sous Windows, il y a de forte chances pour qu'il s'agisse d'un proxy NTLM. Un quoi ?

"Bah, un proxy NTLM" (l'admin-sys)

NT Lan Manager est un protocole d'authentification propre à Microsoft reposant sur l'envoi de vos identifiants et mot de passe d'utilisateur hashés en LM (de ce que j'en ai compris). Un genre de Kerberos mais en vieux, vulnérable et propriétaire si vous préférez. Il y a de grande chance pour que votre système, configuré par votre admin adoré, et plus particulièrement votre navigateur gère ce protocole sans même que vous vous en rendiez compte. En revanche, si vous avez besoin d'intégrer un client git ou de réaliser des curls vers le monde extérieur, le présent environnement nécessitera quelques ajustements.

Curl gère les proxy NTLM (en fait, trouvez moi quelque chose que curl ne puisse faire). Il vous suffira de préciser --proxy-ntlm. Vous pourrez ainsi dire:

curl https://endroit/ou/vous/désirez/vous/rendre --proxy-ntlm 
--proxy http://le_nom_du_proxy:8080 -U :

-U : enverra par défaut les noms d'utilisateur et mot de passe hashé de l'utilisateur invoquant la commande (cela revient donc au même que -U user:mot_de_passe). C'est très con, mais vous ne pouviez pas le deviner. En ce qui concerne git > v1.7, celui détecte et gère NTLM de la même manière que n'importe quel proxy:

git config --global http.proxy 
http://proxyUsername:proxyPassword@proxy.server.com:port

Le retour de chariot ..... dans ta gueule

Éditer du code sur Windows et le pousser avec un client git vient avec son lot de mauvaises surprises lorsque l'ensemble des outils (voire les serveurs) situés en aval fonctionnent sous Linux (et vice versa). Ces systèmes n'utilise tout simplement pas le même caractère pour signaler la fin d'une ligne (End Of Line of EOL).

Comment cela les caractères de fin de ligne?! Une ligne se finit ......bah quand on arrive au bout (Gérard)

Descendons d'un degré dans les niveaux d'abstraction. Ce que Gérard ne voit pas, c'est que les caractères qui composent un document texte ne sont pas tous visibles. Le "plain text" est une abstraction, un épiphénomène généré par nos IDE préférés pour nous pauvres humains et le simple fait d'arriver "au bout de la ligne" repose sur l'existence d'un caractère spécial indiquant justement la fin de de cette dernière. Or, historiquement, il y a deux manière d'indiquer cela:

  • \n LF pour "Line Feed": standard Unix (que vous retrouverez sur MacOSX, Linux, OpenBSD)
  • \r\n CRLF pour "Carriage Return Line Feed": standard Dos (que vous retrouverez sur Windows)

Le passage de l'un à l'autre est responsable de Bug ou comportement parfois difficile à circonscrire, tant l'origine de ces derniers est bas niveau. A titre d'illustration, je me suis déjà retrouvé devant un Studio Eclipse qui me pointait des erreurs de syntaxe tout simplement aberrante au vue de ce que j'avais sous les yeux. En revanche, à titre d'heuristique, vous retrouverez souvent ce genre de bug lorsqu'un parsing un peu bas niveau est impliqué: compilation de code, pointeur de moteur de base de données à l'importation, etc, etc.

Guide de survie du Linuxien en environnement Windows
 
Guide de survie du Linuxien en environnement Windows
 
Guide de survie du Linuxien en environnement Windows