Libérez le potentiel Cygwin

1 Présentation

1.1 Rappel des faits

Débuté en 1984, le projet GNU s'attela pendant plusieurs années à réécrire sous licence libre les commandes du système UNIX, en vue de créer un OS alternatif qui en reprenne les bons concepts [GNU]. Le portage de la collection de commandes de manipulation de fichiers, de flux de texte, de communication en réseau etc., avança à grands pas, mais le projet coinçait sur le noyau. Or un OS sans noyau (gestion de la mémoire, du matériel, des processus, etc.), ce n'est pas un OS. Il a fallu attendre l'arrivée de Linux en 1992 pour boucler la boucle et obtenir un système GNU/Linux complet (moyennant quelques efforts tout de même) [LINUX].

D'autres options existent pour doter le système GNU d'un noyau, dont le célèbre FreeBSD, et une tentative maison nommée the Hurd [HURD], qui n'a jamais vraiment réussi à se stabiliser ni à convaincre. Néanmoins, les auteurs du projet GNU sont beaux joueurs et admettent que mieux vaut un efficace et libre GNU/Linux que rien du tout.

Pour autant, le projet Cygwin (initialement porté par la société Cygnus Solutions en 1989, rachetée par RedHat en 2000 [CYGN]) est parti du constat que les outils GNU présentent un intérêt en eux-mêmes, indépendamment du noyau, et méritent d'être utilisés sur les systèmes Windows. L'équipe, non dénuée d'humour [ACRO], débuta donc un travail de portage des outils GNU pour cette plate-forme. Aujourd'hui la presque totalité des shells et commandes en ligne disponibles sur Linux le sont aussi sur Cygwin, pour le plus grand bonheur des utilisateurs Windows.

1.2 Cyqui ?

Alors, comment ça marche ? Pour faire simple : Cygwin est une couche de bas niveau (en fait une DLL) contenant des fonctions qui simulent le comportement de ce que les programmes d’un système GNU/Linux trouvent au-dessous d’eux (l'interface POSIX [POSIX]). Cygwin s’accompagne donc d’un grand nombre de programmes issus du toolkit GNU, recompilés pour fonctionner avec la DLL Cygwin, plutôt que les appels système spécifiques à Windows et sa fameuse Kernel32.dll.

Il s’agit donc d’un programme Windows (appelons-le un sous-système), qui va vous permettre d’utiliser le shell Bash (ou autre) et toutes vos commandes préférées (find, sed, grep, wget, etc.) ainsi que les liens symboliques de fichiers.

2 Mise en œuvre

2.1 Installation

Le programme se télécharge sur le site du projet [INST], sur toutes les versions modernes de Windows. Vous installerez Cygwin dans un répertoire dédié, sans espaces dans le nom (typiquement C:\cygwin) et il sera une bonne idée de conserver le fichier setup.execar vous vous en resservirez pour modifier l’installation : ajouter et supprimer des outils, monter de version, télécharger les sources, etc. En effet, le sous-système Cygwin n’ayant que très peu à faire avec le Windows sous-jacent (du point de vue de l’utilisateur), vous ne le retrouverez pas dans la rubrique « Ajouter ou Supprimer un Programme » de votre Panneau de Contrôle Windows.

Après sélection d'un miroir de téléchargement (vous jugerez de la popularité du projet au nombre impressionnant de miroirs), le Setup vous laisse choisir (ou modifier, si vous le lancez ultérieurement) quels outils vous intéressent, classés par catégories. Tout s’installera dans le dossier racine que vous aurez choisi au préalable, sans aucune autre interaction avec les fichiers de Windows, ni le registre.

En particulier, pour totalement supprimer Cygwin de votre système, il vous suffira de supprimer le dossier qui le contient.

2.2 Premiers pas

2.2.1 Le Terminal

Si la seule chose que Cygwin apportait était le terminal, le projet vaudrait quand même encore le coup (euh). À tous les familiers de PuTTy sur Windows, le mintty de Cygwin vaut clairement le détour (pour les autres : PuTTy est un client de connexion à des sessions Telnet et SSH... lorsqu'on ne dispose pas d'un terminal décent avec la commande ssh « native » ! d'où Cygwin CQFD).

Il prend en charge le redimensionnement dynamique de la fenêtre, les boutons de la souris, la transparence, les touches de fonction. C'est un terminal multi-fenêtres très agréable qui n'a rien à envier à ceux livrés avec MacOS ou avec votre bureau GNU/Linux préféré.

Le terminal se lance au moyen du raccourci de bureau ou dans le menu Démarrer, et je conseille en outre d'y associer une combinaison de touches afin de l'avoir à portée de Ctrl-Alt- (quitte à sombrer dans la ligne de commandes, autant le faire pour de bon). C'est bien sûr par défaut le bash qui vous accueille lorsque vous ouvrez un terminal.

2.2.2 La croisée des chemins

Une des différences fondamentales entre les modèles Windows et POSIX, du point de vue de la ligne de commandes, se situe au niveau des chemins de fichiers. Pas de C:\ dans un Linux. Et le séparateur de dossier n'est pas la plus grosse divergence, songez plutôt : les points de montage, les liens symboliques, les permissions POSIX, les pseudo-dossiers (processus, devices) etc. Pire, le filesystem de Microsoft n'est pas sensible à la casse.

Pour réconcilier ces deux modèles, Cygwin s'auto-confine dans un répertoire racine / qui correspond « physiquement » à votre C:\cygwinet dans lequel se trouvent les conventionnels bin, etc, home, var, dev, tmp et ainsi de suite. Il y ajoute le répertoire virtuel /cygdrive dans lequel vous retrouverez tous vos volumes Windows lettrés, donc en particulier /cygdrive/c (notez la minuscule et sans les deux-points), qu'il s'agisse de volumes fixes ou amovibles, de disques durs ou optiques, et même de montages réseau réalisés par Windows.

À l'instar de Linux, à chaque user Windows qui lance le shell une première fois, correspond un répertoire (physique) sous /home (c'est-à-dire dans c:\cygwin\home). Quant à vos documents Windows, ils ont toutes les chances de se trouver quelque part vers /cygdrive/c/Users/gabriel/Documents. Aussi, vous pourrez voir un intérêt à créer un lien symbolique (ln -s) dans votre home vers vos documents Windows, et un raccourci Windows dans votre « My Documents » (ou sur votre Desktop) vers votre home (notez l'asymétrie).

Les packages que vous installez dans le setup Cygwin sont placés dans le /bin qui lui-même est par défaut dans votre variable d'environnement PATH (de Cygwin ! pas de Windows) et vous pouvez donc lancer sans attendre vos find et autres tail. Les programmes Cygwin qui manipulent des fichiers en argument s'attendent à des chemins POSIX. Mais vous pouvez tout aussi bien lancer depuis votre terminal des programmes Windows (notepad.exe hihi) : dans ce cas, vous devrez indiquer des chemins Windows, car aucune chance que Notepad ouvre pour vous le fichier /home/gabriel/fichier.txt.

Pourtant, vous pourrez avoir besoin de scripter, avec votre bash tout neuf, l'invocation de programmes Windows (il vous en reste bien quelques-uns d'utiles, autrement vous ne liriez pas cet article). Pour résoudre cette difficulté, Cygwin apporte l'outil cygpath qui permet la conversion (de chaînes) entre les deux formats de chemins.

3 Devenez balaise

Les raisons que l'on peut avoir de vouloir utiliser Cygwin dépassent bien sûr les ls et pwd. Vous allez vouloir révolutionner votre usage de l'automatisation dans Windows, et peut-être même réutiliser tels quels vos scripts préférés que vous faites tourner depuis longtemps sur Linux. Cela est possible pour les raisons exposées ci-dessous.

3.1 Cette chère tuyauterie

Cet article n'étant pas un cours sur POSIX ou Bash ou la ligne de commandes, je n'entrerai pas dans les détails. Notez simplement que le sous-système Cygwin permet la manipulation des pipes entre processus, la redirection des entrées/sorties standards, les commandes imbriquées et les tâches parallèles (^Z, bg, fg, &). Autant de concepts desquels les habitués ne peuvent se passer, et auxquels les nouveaux arrivants trouveront vite un usage incontournable.

3.2 Tel laid commande

(ou : ce que je m'installe dès que j'atterris dans un Windows)

Tout ce que l'on fait de son GNU/Linux n'est pas automatiquement transposable sur Cygwin, et inversement Windows fait certaines choses très bien (ou avec l'aide des bons programmes pour cette plate-forme) sans qu'il ne faille absolument vouloir imiter son voisin pingouin.

Après quelques années de manipulation acharnée, voici donc un petit bouquet (qui n'engage que moi) de ce que j'estime très utile dans mon quotidien (de développeur+bricoleur+sysadmin). J'en profite pour insister sur le fait que l'outil Cygwin en général, et les commandes et paquets ci-dessous en particulier, rendront la vie de certains administrateurs Windows (si vous nous lisez) infiniment plus facile et moins chère (pour leur patron) s'ils veulent bien se donner la peine de s'y pencher.

Là encore, l'ambition n'est pas de détailler ces outils et leur usage, mais simplement de proposer une composition généraliste et efficace pour une première installation de Cygwin que chacun personnalisera :

J'en oublie certainement, mais en général on s'en rend vite compte. Ça n'a l'air de rien, mais la question reste entière : comment fait un sysadmin Windows pour travailler correctement (sans Cygwin) ?

Certains diront que tout ceci n'est bon que pour des traitements finalement très linuxiens, mais que dans la pratique, on ne peut pas tout faire en ligne de commandes (si bonne soit-elle) sur Windows. Ce n'est pas faux, mais lisez le paragraphe suivant (mais, ce n'est pas faux et lisez le chapitre 4).

3.3 Les outils Windows

Cygwin apporte quelques outils supplémentaires propres à ce projet, qui permettent d'aller plus loin dans ce qu'il est possible de faire avec le système Windows en ligne de commandes, en particulier dans des scripts. Vous trouverez notamment : getfacl et setfacl pour manipuler les permissions Windows (Access Control List) sur les fichiers, ainsi que regtool, qui facilite la manipulation du registre Windows, comme son nom l'indique.

En outre, et bien que certaines tâches ne demeurent automatisables qu'au travers du Windows Script Host [WSH], vous retrouverez sûrement grâce à Cygwin une nouvelle vie pour certaines commandes natives Windows depuis longtemps oubliées car, il faut bien le dire, pas très utiles en dehors d'un shell décent (c'est-à-dire à dire offrant pipes, capture de sortie standard, etc.). C'est notamment le cas de la commande net qui permet bien des choses (manipulation des utilisateurs Windows, réinitialisation de mots de passe, partages du réseau, etc.).

Pour le reste, il faudra peut-être tout de même se tourner vers le Windows Script Host, mais cela sort du cadre de cet article.

3.4 Services

La plupart des applications serveur sont disponibles pour la plate-forme Windows, aussi il n'est généralement pas nécessaire de se tourner vers leur portage Cygwin spécifique. Notamment, si les packages Lighttpd et Apache Httpd existent pour Cygwin, vous préférerez probablement pour des raisons de performance leur version native (et lirez pourquoi ici [APA]).

3.4.1 SSH

Néanmoins, pour certains d'entre eux comme OpenSSHd essentiellement, c'est bien sûr en installant la version Cygwin que vous profiterez au maximum de ce que vous offre ce sous-système, pour vos connexions SSH distantes vers votre machine Windows. Pour exécuter sshd comme un service Windows, vous aurez besoin d'installer le package Cygwin cygrunsrv, qui réalise le pont entre daemon Linux et service NT.

Pour déployer votre serveur SSH, configurez tout d'abord l'hôte Windows de la façon suivante :

Répondez yes. La séparation de privilèges est la technique qui permet d'enfermer les éventuels défauts du programme sshd, afin qu'une sortie inopinée du processus dans les graviers ne laisse pas un shell root à l'attaquant par exemple [PRIV].

La séparation de privilèges nécessitera la création par l'assistant d'un compte Windows spécial (très « unprivileged »). À ce titre, il aura fallu que vous lanciez la commande ssh-host-config dans un compte Windows ayant la permission de créer des utilisateurs (généralement, il s'agit des membres du groupe Administrateurs) :

Répondez yes (dire no vous ramènerait au mode sans séparation de privilèges).

yes : vous voudrez manifestement déployer un service Windows (c'est la raison pour laquelle nous faisons tout ceci) et vous pourrez laisser vide la valeur de la variable CYGWIN demandée : il s'agit d'options supplémentaires pour le contexte d'exécution du daemon, dont la plupart sont obsolètes et prises par défaut depuis plusieurs versions.

Ce message est intimement lié à la façon dont Cygwin fait coexister POSIX et Windows, en ce qui concerne l'authentification : il vous informe que la connexion SSH par mot de passe explicite sera toujours possible, mais que si vous souhaitez profiter des fonctionnalités de connexion par paire de clés publique/privée, il faudra pour cela que le processus Windows sache basculer automatiquement de compte utilisateur.

Ceci n'est pas possible pour le compte LocalSystem classiquement utilisé par Windows pour les services (tels que l'assistant de mise à jour Windows Update, ou autres). C'est pourquoi on vous demande la création d'(encore !) un compte Windows (cette fois-ci très « privileged »), qui sera celui sous lequel s'exécuteront vos services Cygwin ayant ce don de transformiste. En particulier, vous pourrez le réutiliser pour le Cron.

Répondez donc no cette fois (sauf si ce nom proposé cyg_server ne vous revient pas).

Si vous préférerez limiter l'usage de votre serveur SSH à votre propre compte uniquement, vous pouvez préciser ici votre nom d'utilisateur plutôt que d'en faire créer un autre par l'assistant. Il vous faudra alors saisir votre mot de passe, et vous ne pourrez jamais vous connecter en SSH sous un autre login.

Puis vous pourrez enfin lancer le service Windows désormais installé :

Vous retrouverez le service sshd dans le panneau de configuration des Services Windows et pourrez également le contrôler indifféremment par net start / stop ou cygrunsrv -S / -E.

N'oubliez pas de configurer votre pare-feu pour permettre les connexions entrantes sur ce daemon, et vous bénéficierez désormais d'un moyen puissant de vous connecter en ligne de commandes sécurisée à votre Windows.

3.4.2 Cron

Cron est également un autre service très intéressant dans le contexte Windows + Cygwin, qui vous permettra de décupler (au moins) les capacités de planification de votre système. Après avoir téléchargé dans le Setup le package Cygwin éponyme, vous l'installerez en lançant :

La documentation complète du Crontab est disponible sur le Web, et le portage Cygwin est parfait, inutile donc de détailler plus avant dans cet article.

3.5 Serveur X

Cygwin offre dans ses paquets un serveur X-Window par le portage de Xorg. Vous devrez installer les paquets xinit et xorg-server, puis vous pourrez démarrer un serveur X sur votre machine Windows de la façon suivante (une seule fenêtre Windows contenant un bureau X) :

Ou encore, pour démarrer le serveur X en mode multi-fenêtres sans fond :

Vous pourrez y rediriger l'affichage d'une application X quelconque (locale ou distante).

Cela peut s'avérer pratique si vous devez exécuter depuis votre Windows une application X distante, sans que vous n'ayez par ailleurs la possibilité d'établir une connexion FreeNX ou VNC ou autre. Mais les possibilités (et le look and feel) sont assez limitées, et ce n'est pas là l'usage principal que l'on fait en général de Cygwin. Notez néanmoins que certains projets [CYGP] s’attellent à porter les environnements Desktop KDE, GNOME et d'autres, pour Cygwin. Leur mise en œuvre est complexe et approximative, et mis à part pour se vanter devant les collègues, je ne vois pas là non plus un intérêt fulgurant en termes de gain en productivité quotidienne sur Windows – mieux vaudrait passer à de la machine virtuelle et du KDE sur Linux natif (sans bien sûr porter de jugement sur l'extrême intérêt que ce projet peut représenter pour ses contributeurs en termes de R&D !).

4 Ce que Cygwin n'est pas

Comme déjà dit plus haut, Cygwin n'est autre, en réalité, qu'une DLL Windows qui apporte des fonctions effectuant la traduction, autant que faire se peut, entre l'API POSIX et l'API native Win32. Pour fonctionner sous Cygwin, un programme doit être compilé spécialement pour cette cible, et lier la cygwin1.dll. Il demeure donc un certain nombre de choses que Cygwin ne permet pas de faire. En particulier :

- Cygwin ne permet pas d'exécuter des binaires Linux sur Windows ;

- ni de faire des montages de filesystem subtiles avec mount ;

- la présence de Cygwin sur un système Windows ne confère pas automatiquement à un programme Windows des compétences POSIX (signaux, pty, etc.). Les programmes doivent être écrits spécialement pour faire usage de ces fonctionnalités, et compilés/liés avec l'environnement Cygwin.

De plus, il existe certaines limites à l'interopérabilité des systèmes POSIX et Windows quant aux permissions sur les fichiers. En effet, dans le modèle Windows, un fichier porte une liste de permissions et interdictions pour un nombre arbitraire d'utilisateurs et de groupes. Le modèle POSIX ne définit que trois niveaux (propriétaire, groupe (un seul !), et tout le monde). Cygwin tâche de faire coexister ces deux conceptions, mais dans certaines situations, il n'est pas possible de conférer convenablement les permissions avec le seul chmod, et à l'inverse la modification de permissions via Windows peut entraîner (plus rarement) des difficultés à ouvrir les fichiers par Cygwin, d'où la nécessité du susmentionné setfacl.

Néanmoins, dans le cas général, cela reste tout à fait acceptable et ne pose que très rarement des difficultés, tout en permettant d'ouvrir d'infinis horizons.

Références

[ACRO] http://www.cygwin.com/acronyms/

[APA] http://httpd.apache.org/docs/1.3/cygwin.html#diff

[CYGN] http://en.wikipedia.org/wiki/Cygnus_Solutions

[CYGP] http://cygwinports.org

[GNU] http://www.gnu.org/

[HURD] http://en.wikipedia.org/wiki/GNU_Hurd

[INST] http://www.cygwin.com/install.html

[LINUX] http://www.gnu.org/gnu/linux-and-gnu.html

[POSIX] http://en.wikipedia.org/wiki/POSIX

[UTIL] http://www.cygwin.com/cygwin-ug-net/using-utils.html

[WSH] http://en.wikipedia.org/wiki/Windows_Script_Host