À propos des périphériques

Bien que la plupart des périphériques dont ont besoin les paquets de BLFS ont été correctement paramétrés par udev en utilisant les règles par défaut installées par LFS dans /etc/udev/rules.d, il y a des cas où il faut modifier ou ajouter des règles.

Notes utilisateur : http://wiki.linuxfromscratch.org/blfs/wiki/aboutdevices

Cartes sons multiples

S'il y a plusieurs cartes sons sur un système, la carte son « default » (par défaut) devient aléatoire. La méthode pour établir un ordre dans les cartes sons dépend du fait que les pilotes soient en modules ou pas. Si les pilotes de la carte son sont compilés dans le noyau, leur contrôle s'effectue via des paramètres de la ligne de commande du noyau. dans /boot/grub/grub.cfg. Par exemple, si un système contient une carte FM801 et une carte PCI SoundBlaster, ce qui suit peut être ajouté à la ligne de commande :

snd-fm801.index=0 snd-ens1371.index=1

Si les pilotes de la carte son sont construits en modules, on peut établir l'ordre dans le fichier /etc/modprobe.conf avec :

options snd-fm801 index=0
options snd-ens1371 index=1

Problèmes sur les périphériques USB

Les périphériques USB ont habituellement deux types de nœuds de périphériques associés avec eux.

Le premier type est créé par le pilote du périphérique spécifique (usb_storage/sd_mod ou usblp) dans le noyau. Par exemple, un périphérique de stockage USB peut être /dev/sdb, et une imprimante USB peut être /dev/usb/lp0. Ces nœuds de périphériques existent seulement quand le pilote du périphérique spécifique est chargé.

Le second type de nœud de périphériques (/dev/bus/usb/BBB/DDD, ou BBB est le numéro du bus et DDD est le numéro du périphérique) est créé chaque fois que le périphérique n'a pas de driver dans le noyau. En utilisant ces nœuds de périphérique USB "directs", une application peut échanger arbitrairement des paquets USB avec le périphérique, c'est à dire, court-circuiter le possible pilote existant du noyau.

Accéder aux nœuds périphériques USB directement est nécessaire quand un programme de l'espace utilisateur est considéré comme un pilote de périphérique. Cependant, pour que le programme ouvre avec succès le périphérique, les permissions doivent être initialisées correctement. Par défaut, pour des considérations de sécurité, tous les périphériques USB directs appartiennent à l'utilisateur root et au groupe usb, et ont la permission 0664 (l'accès en lecture est nécessaire, par exemple pour que lsusb puisse travailler et pour les programmes d'accès aux concentrateurs USB). Des paquets (comme SANE et libgphoto2) contenant un pilote de périphérique USB dans l'espace utilisateur utilisent aussi les règles udev pour changer les permissions des périphériques USB contrôlés. Ce qui fait que les règles installées par SANE changent les permissions pour les scanners reconnus, mais pas pour les imprimantes. Si le mainteneur du paquet oublie d'écrire une règle pour votre périphérique, signalez le bug à BLFS (si le paquet est ici) et en amont, et vous aurez besoin d'écrire votre propre règle.

Il y a une situation ou un contrôle d'accès fin avec des règles udev prégénérées ne marche pas. Nommément, les émulateurs de PC comme KVM, QEMU et VirtualBox utilisent des nœuds de périphérique USB direct pour les périphériques USB arbitrairement présent dans le système d'exploitation invité (note : des correctifs sont nécessaires pour que cela fonctionne dans les points de montage obsolètes /proc/bus/usb décris précédemment). Naturellement, les mainteneurs de ces paquets ne peuvent pas connaître quels périphériques USB seront connectés sur le système d'exploitation invité. Vous pouvez soit écrire des règles udev séparées pour tous les périphériques USB nécessaires vous même, soit utiliser les règles par défaut du groupe "usb", les membres de celui-ci pouvant envoyer des commandes arbitraires pour tous périphériques USB.

Avant Linux-2.6.15, l'accès direct aux périphériques USB n'était pas géré avec les nœuds de périphériques /dev/bus/usb/BBB/DDD, mais avec des pseudo-fichiers /proc/bus/usb/BBB/DDD. Quelques applications (e.g., VMware Workstation) semblent utiliser seulement cette technique obsolète et ne peuvent pas utiliser les nouveaux nœuds de périphériques. Pour qu'elles puissent fonctionner, utiliser le groupe "usb", mais rappelez-vous que les membres ont un accès complet à tous les périphériques USB. Pour créer l'entrée fstab pour le fichier système obsolète usbfs:

usbfs  /proc/bus/usb  usbfs  devgid=14,devmode=0660  0  0
[Note]

Note

Ajouter les utilisateurs dans le groupe "usb" est par nature pas sécurisé, car cela court-circuite les restrictions d'accès imposées par les pilotes spécifiques des nœuds de périphériques USB. Par nature, ils peuvent lire des données sensibles des disques USB sans être dans le groupe "disque". Évitez d'ajouter des utilisateurs dans ce groupe si vous le pouvez.

Attributs de périphériques d'Udev

Le peaufinage des attributs de périphériques tels que le nom du groupe et les droits est possible en créant des règles udev supplémentaires, correspondant à quelque chose de ce genre. On peut trouver le fabricant et le produit en cherchant les entrées du répertoire /sys/devices ou en utilisant udevinfo après avoir attaché le périphérique. Voir la documentation dans le répertoire d'udev actuel /usr/share/doc pour des détails.

SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \
  GROUP:="scanner", MODE:="0660"
[Note]

Note

On n'utilise la ligne ci-dessus qu'à des fins descriptives. Les règles d'analyse d'udev sont mises en place lors de l'installation de SANE-1.0.25.

Périphériques pour les serveurs

Dans certains cas, il est utile de désactiver udev complètement et de créer des périphériques statiques. Les serveurs sont un exemple de cette situation. Est-ce qu'un serveur a besoin de la possibilité de gérer des périphériques dynamiques ? Seul l'administrateur système peut répondre à cette question, mais dans de nombreux cas, la réponse est non.

Si vous ne désirez pas de périphériques dynamiques, vous devez créer des périphériques statiques sur le système. Dans la configuration par défaut, le script de démarrage /etc/rc.d/rcS.d/S10udev monte une partition tmpfs dans le répertoire /dev. Ce problème peut être résolu en montant temporairement la partition racine :

[Avertissement]

Avertissement

Si vous ne suivez pas rigoureusement les instructions ci-dessous, votre système pourrait ne plus pouvoir démarrer.

mount --bind / /mnt
cp -a /dev/* /mnt/dev
rm /etc/rc.d/rcS.d/{S10udev,S50udev_retry}
umount /mnt

Dès lors, le système utilisera des périphériques statiques lors du prochain redémarrage. Créez les périphériques supplémentaires désirés en utilisant mknod.

Si vous voulez restaurer les périphériques dynamiques, recréez les liens symboliques /etc/rc.d/rcS.d/{S10udev,S50udev_retry} et redémarrez de nouveau. Il n'est pas nécessaire de supprimer les périphériques statiques (console et null sont toujours nécessaires) car ils sont recouverts par la partition tmpfs. L'utilisation du disque par des périphériques est négligeable (environ 20–30 octets par entrée).

Last updated on 2012-03-13 19:19:34 +0100