Artisan Numérique

/système/stockage/pmount/système de fichier/ La traversée des médias amovibles

Depuis huit ans que j'utilise GNU/Linux, je crois bien que pas une version n'est passée sans son lot de changement concernant la prise en charge des médias amovibles. Et à ce rythme, cela finit par devenir assez délicat de capter par quelles obscures couches le système passe avant d'afficher ce bête petit miracle d'une icône sur son bureau.

L'épineuse question des médias non-fixes

D'aussi loin que je me souvienne le monde *NIX a toujours eu un peu de mal avec tout ce qui n'était pas solidement accroché au serveur et qui ne pouvait par conséquent pas se traduire par une ligne dans /etc/fstab.

Mais poussé un peu de force sur le bureau, voilà ce bon vieil *NIX, conçu pour de bon vieux serveurs bien stables, qui se doit de découvrir si un disque a embarqué sans prévenir sur son système, qui se doit d'autoriser un "non-root" à monter ce disque et/ou y accéder en écriture, qui se doit de comprendre que cet utilisateur a une session graphique et le bureau qui va avec, qui se doit d'y coller une icône représentative, et enfin qui se doit de permettre à cet environnement d'exécuter sur ce disque diverses actions au compte de cet utilisateur.

Et bien croyez moi, cela fait beaucoup, et ce n'est pas pour rien qu'une solution viable et fiable aura mis près de 8 ans à aboutir.

De la détection du périphérique...

Du classique et ancestrale couple "mount"/"fstab", est d'abord né le plus "conviviale" supermount qui demandait rien de moins qu'un patch du kernel pour permettre de monter magiquement un CD-ROM à l'insertion et de le démonter à l'éjection. Nous sommes en 99 et cette solution tiendra jusqu'en 2005 notamment sur la Mandrake qui en avait développé une version spéciale. Cela et une série de scriptes PERL sensés permettre avec plus ou moins de bonheur un comportement similaire avec une clef USB. On était encore loin de l'icône sur le bureau et d'un accès tranquille au contenu pour un utilisateur "de base".

Les choses ont pas mal changé avec l'arrivée fracassante de HAL. Cette couche chargée d'énumérer l'ensemble du hardware présent sur une machine allait devenir le point de départ de la chaîne du montage automagique. En 2005, la version 2.2.2 commence à être correctement crédible et permet via DBUS, de communiquer avec un autre outil, ivman, le montage, toujours en tant que "root" pour l'instant mais avec dés répercussions plus ou moins efficace sur le bureau.

A l'arrivée sur bureau

Rapidement HAL a un peu étendu son domaine et s'est mis à monter tout seul les périphériques rendant ivman quelque peu inutile. Mais le paramétrage de cette approche était pour le moins casse-bonbons. Alors les bureaux s'en sont mêlés avec gnome-mount et gnome-volume-manager un client DBUS consommant les évènements de HAL. HAL faisait toujours le montage mais cette fois par le biais d'ordres donnés par ses clients. On commençait à approcher d'une solution propre et stable en 2006.

Maintenant que la chaîne était quasi-compléte, ne restait plus qu'à rajouter à cela une couche de droits ce qui fut fait en 2007 avec polkit. Cet outil a en effet pour l'objectif de permettre aux utilisateurs sans privilège de causer avec des processsus qui eux sont privilégiés, le tout dans un cadre de permissions que vous pouvez aujourd'hui définir dans Système/Administration/Performances.

Une outil peu connu et néanmoins très utile qui utilise polkit est pmount qui permet, sans lien avec HAL, de monter, en tant qu'utilisateur standard, un device de type bloc (ex. pmount /dev/sdc1).

Padaboum et GVFS

Tout semblait bien huilé et pourtant, depuis la version 2.24 du bureau, il semble que gnome-volume-manager se soit fait lâchement damer le pion par GVFS, laissant ce dernier un peu bête et désoeuvré dans son coin. Je ne sais pas si grand monde avait remarqué ce changement insidieux mais ce fût pour moi la cause de la perte sêche d'une journée entière à tenter de comprendre pourquoi mes clefs ne se montaient plus malgré la présence de HAL en bon état de marche, et de gnome-volume-manager en mémoire. Tout cela pour finalement découvrir totalement par hasard que j'avais oublié d'installer gvfs et que gnome-volume-manager ne servait au fond plus à rien.

Enfin pas totalement à rien, le pov' chou a encore deux trois choses que GVFS, et par conséquence Nautilus, n'ont pas encore accaparé. Dans le tas notons la syncro des PDA, le montage des WEBCAM, le lancement de cheese, bref pas grand chose de très important me concernant. J'ai donc viré l'obsolète de ma session et tout marche aussi bien qu'avant.

Du coup si vos montages ne se font plus, vérifiez que le paquet gvfs est bien installé et fonctionne, cela peut vous faire gagner une journée...

Déverminage

Déverminer toute cette chaîne n'est pas une sinécure car peu ou pas de logs sont générés de manière standard. Il est cependant possible de localiser au mieux la cause de la "non-apparition" d'une périphérique sur le bureau en procédant avec méthode.

La première couche à valider est HAL. C'est elle qui va aller causer à uDev mais aussi faire du monitoring sur diverses sections du noyau (ex. la gestion de l'énergie via ACPI) pour agréger les informations dans sa base de données et émettre les événements en direction des clients DBUS. Les logs contiennent quelques informations sur ce qui se passe du côté de HAL mais le mieux reste de relancer le démon hald, à la main, en mode "bavard" :

rootpkill hald
roothald --daemon=no --verbose=true
lancement manuel du démon hald en mode bavard

Là vous pouvez insérer votre clef et vérifier que HAL se mette bien à raconter sa vie. A un moment où à un autre il doit vous parler de votre clef, de sa marque, du point de montage, etc. S'il ne dit rien, c'est que la clef n'a pas été reconnue en tant que telle, sans doute par la couche au dessus, typiquement uDev.

Lorsque vous avez validé le bon ou le mauvais fonctionnement de HAL, vous pouvez le relancer en mode normal

rootCTRL-C
roothald
lancement manuel du démon hald en mode standard

Si hal a bien parlé de votre clef, il faut maintenant regarder ce qu'il en a retenu. Pour cela vous pouvez vider sa base de données à l'aide de la commande lshal. Généralement je redirige le résultat vers un fichier que j'étudie avec un éditeur comme vi en recherchant l'enregistrement correspondant à ma clef, le plus simple pour cela est de repérer l'ID USB avec lsusb ou PCI avec lspci, et de le rechercher dans le résultat de la commande lshal.

Si tout est bon à ce stade, la seule chose qui reste à faire est de vérifier que les messages transitent correctement sur le bus de communication, cela se fait très simplement en lançant la commande dbus-monitor --system. Là devraient apparaître les échanges entre HAL et GVFS (plus exactement le client GVFS /usr/lib/gvfs-hal-volume-monitor. Maintenant si tout est bon, il ne reste plus grand chose mis à part un bug dans la couche GVFS/Nautilus, ou simplement un mauvais paramétrage dans Nautilus/Préférences/Supports.

Réduire la complexité de tout cela

Comme le faisait justement remarquer Zanko dans son commentaire (voir plus bas), cela peut paraître vaguement overkill d'avoir la chaîne suivante pour l'insertion d'une malheureuse clef USB :

  1. kernel/usb - Détection de l'insertion
  2. uDev - création des diverses entrées dans /dev (ex. /dev/sdc1)
  3. HAL - Détection de l'arriver du nouveau device, création de l'enregistrement et notification sur DBus.
  4. DBUS - Transport de la notification "nouveau device" aux clients connectés.
  5. gvfs via gvfs-hal-volume-monitor - Réception de la notification, lancement de la procédure de montage.
  6. gnome-mount - Demande le montage du device sur un dossier (ex. /media/...).
  7. PolKIT - Vérification des droits de l'utilisateur "console courrante", lancement du montage si OK.
  8. Kernel/Mount - Montage (ouf !!).

En encore, je ne suis pas certain que ce ne soit pas HAL qui fasse effectivement le montage en étant donc le relais avant l'appel du mount() kernel. Bref, cela fait tout de même beaucoup, c'est certain.

Malgré tout c'est GNU/Linux et pas Windows, et il y a toujours moyen de changer les choses. Ainsi il est possible de réduire fortement le rôle de Gnome dans cette histoire, ce qui n'est pas une mauvaise option sachant que vous pouvez vouloir jouir de l'auto-montage en console (sans X11) ou avec un bureau minimaliste comme IceWM. Pour obtenir cela, il suffit simplement de tout faire pour qu'ivman, dont nous parlions plus haut, reprenne du service.

En effet, ivman est un très bon client HAL capable de faire à peu près ce que l'on veut lorsqu'un nouveau périphérique est détecté. Il suffit pour cela de modifier les configurations dans /etc/ivman, ou de ne rien modifier du tout d'ailleur car tout est déjà paramétré par défaut pour auto-monter les médias amovibles. Vous pouvez donc coller tranquillement son exécution dans votre ~/.bashrc et désinstaller ou désactiver GVFS. L'auto-montage devrait marcher tout aussi bien qu'avant. La raison de cela est que Nautilus est suffisamment intelligent pour aller lire la table des montages réalisés et mettre l'icône correspondante sur le bureau, même si ce n'est pas lui qui a fait ce montage.

Nous avons dés lors un circuit beaucoup plus simple kernel/usb->uDev->HAL->DBus->ivMan->PolKit->kernel/mount et PolKIT est donc toujours dans la boucle. En effet, par défaut un ivman lancé par un utilisateur va chercher à utiliser d'abord gnome-mount, puis pmount. Dans les deux cas POLKit est utilisé.

Du coup pour réduire encore le circuit, il est possible de court-circuiter POLKit en lançant cette fois ivman en tant que démon système. Ainsi les montages se feront en tant "root", sans POLKit, mais il va falloir à ce moment là bidouiller un peu la configuration pour rendre les montages visibles à un utilisateur lambda.

Paramétrage des montages

Ce qui est ennuyeux avec cette dualité gvfs/gvm est que ce dernier est encore bien présent dans les installations standards et rien n'indique par exemple que le panneau de configuration disques amovibles et médias ne sert presque plus à rien, au profit de l'onglet supports des préférences de Nautilus.

En revanche, les options de montages sont heureusement conservées au même endroit et sont donc en quelque sorte "partagées" par Nautilus et GVM. Ainsi pour forcer l'utilisation d'UTF8 pour un montage VFAT, la première méthode consiste toujours à lancez Système/Préférences/Avancé/Editeur de configuration. Puis dans system/storage/default_options/vfat, double-cliquez sur mount_options, puis Ajouter et saisissez la valeur iocharset=utf8. Ceci fait, validez, retirez la clef et re-insérez là, tout devrait rentrer dans l'ordre.

Si en revanche vous ne voulez pas changez la politique par défaut, mais faire un cas particulier pour une clef spécifique, il faut passer par la ligne de commande. En effet Nautilus et GVM utilisent tous les deux gnome-mount pour effectuer le montage.

Imaginons que le device soit /dev/disk/by-lab/disk_backup. Vous pouvez lire les réglages pour cette clef en tapant ceci :

gnome-mount --display-settings --device /dev/disk/by-lab/disk_backup

Pour modifier les réglages utilisez cette syntaxe :

gnome-mount --write-settings --fstype vfat --mount-options iocharset=utf8 --device /dev/disk/by-lab/disk_backup

Enfin pour supprimer des réglages spécifiques :

gnome-mount --erase-settings --device /dev/disk/by-lab/disk_backup

Conclusion

Ca en fait du monde pour finalement réussir à faire efficacement une chose en apparence aussi simple qu'ouvrir une clef USB. Maintenant UNIX reste UNIX dans l'âme et dans le coeur, les avancées s'ajoutent mais ne se remplacent pas, et il reste encore aujourd'hui possible d'utiliser des choses comme Automount ou IVMan. IVMan qui au delà de la blague reste d'actualité car c'est finalement le seul client de montage qui fonctionne dans tous les cas de figure, avec une simple console comme sur n'importe quel bureau.