source: postlfs/config/devices.xml@ fe142cc

10.0 10.1 11.0 ken/refactor-virt lazarus qt5new trunk xry111/git-date xry111/git-date-for-trunk xry111/git-date-test
Last change on this file since fe142cc was fe142cc, checked in by Douglas R. Reno <renodr@…>, 16 months ago

Make the 'Devices for Servers' text SysV only

git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@23309 af4574ff-66df-0310-9fd7-8a98e5e911e0

  • Property mode set to 100644
File size: 9.0 KB
Line 
1<?xml version="1.0" encoding="ISO-8859-1"?>
2<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
4 <!ENTITY % general-entities SYSTEM "../../general.ent">
5 %general-entities;
6]>
7
8<sect1 id="postlfs-devices" xreflabel="About Devices">
9 <?dbhtml filename="devices.html"?>
10
11 <sect1info>
12 <othername>$LastChangedBy$</othername>
13 <date>$Date$</date>
14 </sect1info>
15
16 <title>About Devices</title>
17
18 <indexterm zone="postlfs-devices">
19 <primary sortas="e-etc-udev-rules">/etc/udev/rules.d</primary>
20 </indexterm>
21
22 <para>
23 Although most devices needed by packages in BLFS and beyond are set up
24 properly by <application>udev</application> using the default rules
25 installed by LFS in <filename
26 class="directory">/etc/udev/rules.d</filename>, there are cases where
27 the rules must be modified or augmented.
28 </para>
29
30 <para condition="html" role="usernotes">User Notes:
31 <ulink url="&blfs-wiki;/aboutdevices"/></para>
32
33 <sect2>
34 <title>Multiple Sound Cards</title>
35
36 <para>
37 If there are multiple sound cards in a system, the "default"
38 sound card becomes random. The method to establish sound card order
39 depends on whether the drivers are modules or not. If the sound card
40 drivers are compiled into the kernel, control is via kernel command line
41 parameters in <filename>/boot/grub/grub.cfg</filename>. For example,
42 if a system has both an FM801 card and a SoundBlaster PCI card, the
43 following can be appended to the command line:
44 </para>
45
46<screen><literal>snd-fm801.index=0 snd-ens1371.index=1</literal></screen>
47
48 <para>
49 If the sound card drivers are built as modules, the order can be
50 established in the <filename>/etc/modprobe.conf</filename> file with:
51 </para>
52
53<screen><literal>options snd-fm801 index=0
54options snd-ens1371 index=1</literal></screen>
55
56 </sect2>
57
58 <sect2 id="usb-device-issues">
59 <title>USB Device Issues</title>
60
61 <para>
62 USB devices usually have two kinds of device nodes associated with them.
63 </para>
64
65 <para>
66 The first kind is created by device-specific drivers (e.g.,
67 usb_storage/sd_mod or usblp) in the kernel. For example, a USB mass
68 storage device would be /dev/sdb, and a USB printer would be
69 /dev/usb/lp0. These device nodes exist only when the device-specific
70 driver is loaded.
71 </para>
72
73 <para>
74 The second kind of device nodes (/dev/bus/usb/BBB/DDD, where BBB is
75 the bus number and DDD is the device number) are created even if the
76 device doesn't have a kernel driver. By using these "raw" USB device
77 nodes, an application can exchange arbitrary USB packets with the
78 device, i.e., bypass the possibly-existing kernel driver.
79 </para>
80
81 <para>
82 Access to raw USB device nodes is needed when a userspace program is
83 acting as a device driver. However, for the program to open the device
84 successfully, the permissions have to be set correctly. By default, due
85 to security concerns, all raw USB devices are owned by user root and
86 group usb, and have 0664 permissions (the read access is needed, e.g.,
87 for lsusb to work and for programs to access USB hubs). Packages (such
88 as SANE and libgphoto2) containing userspace USB device drivers also
89 ship udev rules that change the permissions of the controlled raw USB
90 devices. That is, rules installed by SANE change permissions for known
91 scanners, but not printers. If a package maintainer forgot to write
92 a rule for your device, report a bug to both BLFS (if the package is
93 there) and upstream, and you will need to write your own rule.
94 </para>
95
96 <para>
97 There is one situation when such fine-grained access control with
98 pre-generated udev rules doesn't work. Namely, PC emulators such as KVM,
99 QEMU and VirtualBox use raw USB device nodes to present arbitrary USB
100 devices to the guest operating system (note: patches are needed in order
101 to get this to work without the obsolete /proc/bus/usb mount point
102 described below). Obviously, maintainers of these packages cannot know
103 which USB devices are going to be connected to the guest operating
104 system. You can either write separate udev rules for all needed USB
105 devices yourself, or use the default catch-all "usb" group, members
106 of which can send arbitrary commands to all USB devices.
107 </para>
108
109 <para>
110 Before Linux-2.6.15, raw USB device access was performed not with
111 /dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD
112 pseudofiles. Some applications (e.g., VMware Workstation) still use only
113 this deprecated technique and can't use the new device nodes. For them to
114 work, use the "usb" group, but remember that members will have
115 unrestricted access to all USB devices. To create the fstab entry for
116 the obsolete usbfs filesystem:
117 </para>
118
119<screen><literal>usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0</literal></screen>
120
121 <note>
122 <para>
123 Adding users to the "usb" group is inherently insecure, as they can
124 bypass access restrictions imposed through the driver-specific USB
125 device nodes. For instance, they can read sensitive data from USB
126 hard drives without being in the "disk" group. Avoid adding users
127 to this group, if you can.
128 </para>
129 </note>
130
131 </sect2>
132
133 <sect2>
134 <title>Udev Device Attributes</title>
135
136 <para>
137 Fine-tuning of device attributes such as group name and permissions
138 is possible by creating extra <application>udev</application> rules,
139 matching on something like this. The vendor and product can be found by
140 searching the <filename class='directory'>/sys/devices</filename>
141 directory entries or using <command>udevadm info</command> after the
142 device has been attached. See the documentation in the current
143 <application>udev</application> directory of <filename
144 class='directory'>/usr/share/doc</filename> for details.
145 </para>
146
147<screen><literal>SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002", \
148 GROUP:="scanner", MODE:="0660"</literal></screen>
149
150 <note>
151 <para>
152 The above line is used for descriptive purposes only. The
153 scanner <application>udev</application> rules are put into place when
154 installing <xref linkend='sane'/>.
155 </para>
156 </note>
157
158 </sect2>
159
160<!--
161 <sect2>
162 <title>Multiple Network Interfaces</title>
163
164
165 </sect2>
166-->
167
168<!-- These instructions are invalid on systemd because we don't use bootscripts.
169 In addition, we should probably verify that these are valid on SysV too.-->
170
171 <sect2 revision="sysv">
172 <title>Devices for Servers</title>
173
174 <para>
175 In some cases, it makes sense to disable
176 <application>udev</application> completely and create static devices.
177 Servers are one example of this situation. Does a server need the
178 capability of handling dynamic devices? Only the system administrator
179 can answer that question, but in many cases the answer will be no.
180 </para>
181
182 <para>
183 If dynamic devices are not desired, then static devices must be
184 created on the system. In the default configuration, the
185 <filename>/etc/rc.d/rcS.d/S10udev</filename> boot script mounts a
186 <systemitem class="filesystem">tmpfs</systemitem> partition over the
187 <filename class="directory">/dev</filename> directory. This problem can
188 be overcome by mounting the root partition temporarily:
189 </para>
190
191 <warning>
192 <para>
193 If the instructions below are not followed carefully, your
194 system could become unbootable.
195 </para>
196 </warning>
197
198
199<screen><userinput>mount --bind / /mnt
200cp -a /dev/* /mnt/dev
201rm /etc/rc.d/rcS.d/{S10udev,S50udev_retry}
202umount /mnt</userinput></screen>
203
204 <para>
205 At this point, the system will use static devices upon the next
206 reboot. Create any desired additional devices using
207 <command>mknod</command>.
208 </para>
209
210 <para>
211 If you want to restore the dynamic devices, recreate the
212 <filename>/etc/rc.d/rcS.d/{S10udev,S50udev_retry}</filename> symbolic
213 links and reboot again. Static devices do not need to be removed
214 (console and null are always needed) because they are covered by the
215 <systemitem class="filesystem">tmpfs</systemitem> partition. Disk
216 usage for devices is negligible (about 20&ndash;30 bytes per entry.)
217 </para>
218
219 </sect2>
220
221 <sect2 id="dev-dvd">
222 <title>Devices for DVD Drives</title>
223
224 <para>
225 If the initial boot process does not set up the
226 <systemitem>/dev/dvd</systemitem> device properly, it can
227 be installed using the following modification to the default udev rules.
228 As the <systemitem class="username">root</systemitem> user, run:
229 </para>
230
231<screen><userinput>sed '1d;/SYMLINK.*cdrom/ a\
232KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", OPTIONS+="link_priority=-100"' \
233/lib/udev/rules.d/60-cdrom_id.rules > /etc/udev/rules.d/60-cdrom_id.rules</userinput></screen>
234
235 </sect2>
236
237</sect1>
Note: See TracBrowser for help on using the repository browser.