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
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 envoyé sur 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
Les périphériques USB ont habituellement deux types de noeuds de périphériques associés avec eux.
Le premier type est créé par le driver 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 imprimpante USB peut être /dev/usb/lp0. Ces noeuds de périphériques existe seulement quand le driver du périphérique spécifique est chargé.
Le second type de noeud 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 noeuds de périphérique USB "direct", une application peut échanger arbitrairement des paquets USB avec le périphérique, c'est à dire, court-circuiter le possible driver du noyau existant.
Accéder aux noeuds périphérique USB directement est nécessaire quand un programme de l'espace utilisateur est considéré comme un driver de périphérique. Sinon, pour le programme qui ouvre avec succès le périphérique les permissions sont initialisées correctement. Par défaut, pour des considérations de sécurité, tous les périphériques USB direct sont propriétés de l'utilisateur root et du groupe usb, et ont la permission 0664 (l'accès en lecture est nécessaire, e.g., pour que lsusb puisse travailler et pour les programmes d'accès aux concentrateurs USB). Des paquets (comme SANE et libgphoto2) contenant un driver de périphérique USR 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, signaler le bug à BLFS (si le paquet est ici) et upstream, 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 noeuds 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 point de montage obsolete /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 bien écrire des règles udev séparés pour tous les périphériques USB nécessaire vous même, ou utiliser les règles par défaut du groupe "usb", les membres de celui-ci peuvent envoyé 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 noeuds 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 noeuds 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
Ajouter les utilisateurs dans le groupe "usb" est par nature insécurisé, car cela court-circuite les restrictions d'accès imposés par les drivers spécifiques des noeuds de périphérique USB. Par nature, ils peuvent lire des données sensibles des disques USB sans être dans le group "disque". Evitez d'ajouter des utilisateurs dans ce groupe si vous le pouvez.
Le peaufinement 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"
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.24.
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 :
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 +010