Hello and welcome to this series covering Linux
This time we will introduce the Linux device manager - udev, and udev rules, by covering
the following:
* Understand the role of udev
* Outline how udev and udev rules work
* How to locate the udev rules files
So, let's start by asking 'what is udev'?
Udev is the device manager for the Linux kernel and stands for 'userspace/dev'
Udev is started during the Linux boot up and executes as a background deamon process for
the lifetime of the Linux system.
It creates, and removes, devices dynamically in the /dev directory in response to physical
events related to the peripheral devices detected.
On Oracle Linux systems which are based on systemd, it is the systemd-udevd service which
reads, and stores in memory, all of the rules files as part of the boot process.
So how does the Linux kernel know a device has been added to the system, and where can
the rules files on a system be found?
Let's look at each of those questions in turn...
The udev daemon listens for kernel notifications from sysfs, which are known as uvents, on
any of the hardware devices defined in the /etc/udev/rules.d or the
/usr/lib/udev/rules.d directories.
I'll explain why there are two locations in just a minute, for now let's continue describing
how the kernel identifies a change and notifies udev...
When a uevent occurs udev references the information located in device files located in the these
directories to understand how it should process it.
Hopefully this representation will help to outline the flow of events that occurs when
sysfs sends a uevent to udev:
1/ The kernel detects a new device is attached 2/ The kernel creates a device entry in the
/dev directory 3/ The kernel sends a uevent via sysfs
4/ The udev service (systemd-udevd) responds to the uevent
5/ udevd looks for a match against the uevent among the udev rules files
6/ If match located, udev processes the uevent 7/ udev configures the device based on the
udev rules file
So that is what happens when a new device is attached to the Linux system, but where
are the rules definition files located?
As mentioned previously, the udev rules files are located in two places on the Linux filesystem,
and all end with the .rules suffix:
a/ /etc/udev/rules.d/ b/ /usr/lib/udev/rules.d/
The rules located in the /usr/lib/udev/rules.d
directory are those shipped along with Oracle Linux - they must NOT be altered in anyway.
The rules located in the /etc/udev/rules.d directory however are possible to be added,
or edited, by the system's administrator.
So which takes precedence if there are two with the same name in both the /usr/lib/..
and /etc/udev/.. locations?
The rules written by the administrator and placed in the /etc/udev/ location.
But why would an administrator create a custom rule?
Well, for numerous reasons actually and here are some examples:
* The ability to rename a device from its system assigned default
* Provide an alternative name for a device node by creating a symbolic link to that node
* To alter the permissions and ownership of a device (eg: to restrict access to a device)
* Complete an automated action when a device is created or removed (eg: when the device
is physically attached or removed) * Rename network interfaces
An extra thing to be aware of is that there is also an execution hierarchy beyond that
based on their location.
The rules are processed in the following order:
* Numbered files are processed first - higher numbers have precedence over lower numbers
* If multiple files have the same number, then names are processed alphabetically
Hopefully this provides an indication of the flexibility provided by udev.
For now, that is probably sufficient theory, so let's log on to a system for a quick look
at some of this...
First up, lets look at the udev rules that ship with the system in the /usr/lib/udev/rules.d
directory
For most systems this covers all the requirements needed for that system - again, these should
not be altered.
These files all vary in size and complexity, so let's take a quick peek inside a couple
of them...
First up let's look at a (random) small .rules file: 99-systemoci-persistent-names.rules
Notice that it also contains some SYMLINK definitions - in this instance differentiating
between certain block type devices.
At the other end of the scale a more complex .rules file example is: 99-systemd.rules
A quick scroll provides an idea of the standard functionality provided 'out of the box'
Next let's take a look at the /etc/udev/rules.d directory
Remember that if there is a requirement to alter, or update, any of the default behaviours
the correct place to make these changes is here.
Because this is the ONLY location where it is permitted to make alterations to existing
rules, and also that anything placed in this directory has precedence over the .rules files
in the /usr/lib/udev/rules.d directory.
In all likelihood though, it's unlikely that any changes will be required for most systems,
but it's always good to know that it is possible.
In summary, this only scratches the very basics of udev.
Because udev is both flexible and powerful in the way it provides the functionality to
define and apply rules allowing the administrator to control who has access to any devices attached
to the system.
Many thanks for taking the time out to watch, and be sure to keep an eye for further instalments
in this series...
For additional information about Oracle Linux technologies, please access the Oracle Linux
documentation, or Oracle Linux Learning Library.