Translators
Un article de HurdFr_Wiki.
Cet article est une ébauche. Cela signifie qu'il est n'est pas considéré par son auteur comme terminé.
Vous êtes libre de l'améliorer et de retirer cet avertissement si vous jugez que l'article est maintenant finalisé.
Sommaire |
Qu'est ce qu'un translator ?
Les translators, ou traducteurs en français, sont des programmes non-interactifs. On les utilise à travers un ou plusieurs noeuds du VFS (Système de Fichiers Virtuel). En effet, lorsqu'un programme de type translator est démarré, on l'associe à un fichier ou à un répertoire.
Pourquoi ceci ? Il s'agit en fait d'une spécificité du Hurd. Les développeurs se sont dit qu'au lieu de créer un service centralisant tous les autres services, qui constituerait un goulot d'étranglement et un point de fragilité du système (single point of failure), le VFS pouvait être utilisé car il fournissait un chemin unique (chaque chemin correspond à un seul fichier. De plus, par sa hiérarchisation il permet d'éviter les conflits de nom tout en gardant des noms compréhensibles. Il est ainsi très facile de retrouver le composant X, il suffit d'accèder à "/servers/X" par exemple.
En résumé, un translator est un programme qui s'attache à un ou plusieurs nœuds du VFS.
Comme tout programme, un translator va exécuter des fonctions. Ces fonctions sont en fait des callbacks (ou fonction de rappel -- une fonction qui réagit à un événement). Ces évènements sont les opérations classiques sur un fichier, comme l'ouverture, l'écriture, la modification des droits, etc.
Par exemple, sur un système Un*x classique, si vous tapez ls, le système de fichiers va normalement vous renvoyer la liste des fichiers dans le répertoire courant. Dans notre cas, un message va être envoyé au translator, lui indiquant que l'utilisateur souhaite lister les fichiers de tel répertoire. Ce dernier va alors pouvoir y répondre de la manière qu'il veut. On peut donc inventer autant de manières d'y répondre que l'on peut imaginer.
Donc, vous l'aurez compris, un translator est un programme qui s'attache à un noeud du VFS et exécute des callbacks, notamment ceux liés aux actions standards d'un VFS.
Utilité et avantages
Le concept des translators est utilisé dans le Hurd pour diverses tâches, allant du composant système au petit jeu.
Les translators standards sont contenus dans le dossier "/hurd". On y trouve par exemple une pile TCP/IP, un serveur d'exécution de binaires, ou encore un système de fichiers ext2.
Vous l'aurez compris, il est possible de créer énormément de composants avec ce concept, et ce, de manière simple car vous développez quasiment un programme classique (voir plus bas).
Comme il s'agit d'un simple programme, y attacher un débogueur est alors très simple et aide grandement au développement.
Enfin, un autre avantage, et pas des moindres, est qu'il est possible de remplacer très aisément les composants. En effet, il suffit de changer un simple binaire pour faire ce remplacement.
De plus, il est possible de lancer ces translators en tant qu'utilisateur non-privilégié, ce qui permet d'éviter des problèmes de sécurité par exemple. Prenons l'exemple d'ext2.
Si un utilisateur crée une disquette formatée en ext2, sur une machine où il est root, il peut y mettre un binaire setuid root (bash par exemple). S'il arrive sur une machine Un*x, et que l'administrateur a autorisé le montage de disquette, il pourra alors devenir root sur la machine (car le montage sera réalisé en root). Si Linux a développé les moyens de limiter les droits associés au montage - nosuid, noexec -, le problème fondamental reste toujours le même : monter un volume, c'est ajouter un contenu non maîtrisé (contenu d'une disquette, d'un CD...) à un espace de confiance (le VFS). Il est ainsi facile de provoquer l'effondrement du système avec de simples droit d'utilisateur, voire de profiter de failles de sécurité.
En revanche, avec la méthode du Hurd (translator non-privilégié), comme le translator pour ext2 a été lancé par l'utilisateur non-privilégié, il ne lui est plus possible de s'élever au privilège root.
Un exemple
Passons maintenant à un exemple pratique : ftpfs. Comme son nom l'indique, il s'agit d'un translator permettant de se connecter à un FTP au travers du VFS.
$ pwd
/home/glibersat/
$ mkdir ftp-debian
$ [Attacher le translator ftpfs au noeud ftp-debian
en indiquant l'adresse ftp.fr.debian.org (nous verrons la syntaxe plus tard)]
$ cd ftp-debian
$ ls
debian debian-amd64 debian-non-US
$ cd debian
$ pwd
/home/glibersat/ftp-debian/debian
$ ls
README README.mirrors.txt doc ls-lR.patch.gz
README.CD-manufacture README.non-US indices pool
README.html README.pgp ls-lR project
README.mirrors.html dists ls-lR.gz tools
$ head -n 5 README.non-US
Debian non-US packages
----------------------
Prior to the release of Debian 3.1, United States laws placed restrictions o
Comme vous pouvez le voir, nous navigons dans le FTP de manière complètement transparente. On ne peut pas distinguer (temps de réaction exclu) si nous explorons des fichiers locaux ou si nous sommes sur un serveur distant.
Mais nous pouvons encore faire mieux ! Sur cet exemple, nous avons indiqué explicitement l'adresse du FTP (ftp.fr.debian.org). L'idéal serait de pouvoir accèder à tous les FTPs sans avoir à activer un translator sur tel FTP, puis le désactiver, en activer un nouveau pour tel autre FTP, etc. etc.
Ceci est possible grâce à l'imbrication de deux translators : hostmux et ftpfs. Hostmux est un multiplexeur d'hôtes, en d'autres termes, il permet de sélectionner une adresse et de lancer le sous-translator avec cette dernière. Un exemple sera plus parlant :
$ pwd /home/glibersat $ mkdir ftp $ [Attacher le translator hostmux avec comme sous-translator ftpfs] $ cd ftp $ ls $ cd ftp.fr.debian.org $ pwd /home/glibersat/ftp/ftp.fr.debian.org $ ls debian debian-amd64 debian-non-US $ cd .. $ pwd /home/glibersat/ftp $ ls ftp.fr.debian.org $ cd ftp.hurdfr.org $ pwd /home/glibersat/ftp/ftp.hurdfr.org $ ls duck duckcorp gps hurdfr myserver
N'est-ce pas magique ? :-)
Dès que nous tentons d'accèder à un répertoire dans le dossier ftp, hostmux va créer ce répertoire et lancer un ftpfs sur ce dernier. Nous pouvons alors naviguer dedans comme auparavant.
Utilisation des translators
Précsion
On peut attacher un translator à un noeud de deux manières :
- En mode actif
Le mode actif connecte le translator au noeud jusqu'à ce qu'il meurt (e.g., quand la machine est redémarrée). Les sorties standard et d'erreur sont connectées au terminal courant lors du lancement.
- En mode passif
Le mode passif, en revanche, se rapproche plus du fonctionnement d'un daemon. On va écrire dans le système de fichiers le fait qu'à tel nœud est attaché tel translator. Ainsi, lorsqu'un utilisateur accède pour la première fois à ce nœud, le translator est automatiquement lancé par le système de fichiers. Si le translator meurt, il sera relancé automatiquement dès la prochaine solliciation. Comme l'information est écrite dans le système de fichier, cela survit même au redémarrage. Dans ce mode, les sorties standard et d'erreur ne sont connectées à aucun terminal.
Utilisation sur la CLI
Les translators sont utilisés à travers un ensemble d'outils. Sur la distribution Debian GNU/Hurd, ils sont livrés dans le paquet "hurd".
settrans
La commande settrans permet d'attacher ou détacher un translator sur un nœud du VFS.
On peut lui demander d'attacher un translator soit de manière passive ("-p") ou de manière active ("-a") (ou les deux).
On notera particulièrement les options "-c" (create), qui permet de créer le nœud sur le VFS s'il n'existe pas, et "-g" (goaway), qui permet de demander à l'éventuel ancien translator de s'en aller.
Par exemple, pour l'exemple du ftpfs, on l'utilise ainsi :
settrans -cagp ftp-debian /hurd/ftpfs / ftp.fr.debian.org
- ftp-debian correspond au nœud sur lequel il faut attacher le translator
- /hurd/ftpfs est le chemin du translator à exécuter
- / et ftp.fr.debian.org sont deux arguments passés à /hurd/ftpfs
On peut aussi demander à settrans de détacher tout translator d'un noeud en utilisant :
settrans -g ftp-debian
L'option "-f" (force) peut éventuellement être utile pour les plus récalcitrants.
showtrans
Cette commande permet de savoir si un nœud est lié à un translator passif. Son fonctionnement est très simple :
glibersat@daphne:~$ showtrans /home /hurd/ext2fs /dev/hd0s7
Cela nous indique qu'au nœud "/home" est associé le translator "/hurd/ext2fs" avec l'argument "/dev/hd0s7". Ainsi, au prochain accès à /home, c'est cette commande qui sera exécutée.
fsysopts
Cet utilitaire permet de connaître et de modifier les options du translator actuellement attaché à un nœud.
Par exemple, pour connaître l'état d'un point de montage, on peut simplement faire :
glibersat@daphne:~$ fsysopts /home /hurd/ext2fs --writable /dev/hd0s7
On peut aussi indiquer de passer un système de fichiers en lecture-écriture avec la commande suivante :
fsysopts /home --writable
L'utilitaire est au départ conçu pour les systèmes de fichiers, les options courantes sont donc "--writable", "--readonly", etc. (cf. l'aide de la commande pour une liste plus complète). Cependant, chaque translator peut choisir les options qu'il souhaite être contrôlables et/ou visibles par cet utilitaire.
Développement de translators
Classes de translators
L'auteur d'un translator peut choisir d'implémenter telle ou telle interface (une interface est une collection de callbacks) en plus de celle qui regroupent les actions standards du VFS. De cette façon, le translator peut facilement fournir des fonctionnalités supplémentaires telles que la gestion des attributs sans recourir à une API externe non standard.
TrivFS
Les translators de type TrivFS sont des translators qui ne s'attachent qu'à un seul nœud. Ce nœud sera un simple fichier, il n'est pas possible de créer une aborescence.
Un exemple de tel translator est le translator fortune.
Les mécanismes de TrivFS sont expliqués dans le Hurd reference manual.
NetFS
Les translators NetFS sont, contrairement à TrivFS, des translators qui créent une arborescence. Ils vont s'attacher à un noeud qui sera un répertoire, contenant des fichiers et des sous-répertoires. Ceci est récursif.
xmlfs et ftpfs sont des exemples de translators de type NetFS.
Malheureusement, pour NetFS, il n'existe pas de documentation réelle : le mieux est de lire quelques sources de translators simples comme hostmux.
DiskFS
Les translators DiskFS sont équivalents aux translators NetFS par leur représentation (arborescence), mais sont spécifiquement conçus pour travailler avec une unité physique en backing-store.
De tels translators sont par exemple ext2fs, fatfs ou encore jfs.
Une documentation pour DiskFS est disponible dans le Hurd Reference Manual.
Développer
Actuellement, tous les translators sont écrits en C (ou presque). On commence à voir des bindings pour certains langages apparaître. Cela signfie que pratiquement toute la documentation est écrite pour le C. Vous devrez donc passer par la documentation C avant d'utiliser les bindings pour votre langage préféré.
Un bon point de départ est de commencer par développer un translator simple de type TrivFS.
En C
Il existe une documentation appelée le et dans le Hurd Hacking Guide.
Elle permet de comprendre les mécanismes des translators, fait un tour d'horizon des bibliothèques disponibles et donne un bon exemple guidé pour la création d'un translator TrivFS.
Il existe une traduction française sur le site de Colin Pitrat.
Malheureusement, pour les translators plus costauds, il faudra lire les sources d'autres translators et programmer à partir ceux-ci.
En Perl
Il existe un ancien binding, non-maintenu, à l'adresse suivante : http://john-edwin-tobey.org/Hurd/.
Il est appelé "Pith" pour "Perl Interface to The Hurd". Il s'agit d'une interface Perl pour TrivFS. Les dernières modifications ont été faites en 2000.
L'état de fonctionnement est inconnu.
En Python
Un projet de binding python pour TrivFS est en cours de réalisation. Il n'en est qu'au stade très expérimental et ne permet que de créer des translators en lecture-seule.
Le projet se trouve à l'adresse suivante : http://www.patapouf.org/projects/python-trivfs.
