Настройка udev rules в Linux
Начнём с небольшого введения для новичков. Философия Unix гласит, что всё есть файл. Таким образом, файлы в Unix — это не только информация, хранимая на жёстком диске, но и устройства. Да, в Linux жёсткий диск, мышь, клавиатура, флешка, сетевой адаптер и другие устройства имеют свои файлы, с помощью которых с ними и взаимодействуют различные системные программы.
Все файлы устройств хранятся в каталоге /dev. Этот каталог генерируется во время загрузки специальным сервисом — udev. Происходит это на основе подключённых к компьютеру устройств и определённых правил. По умолчанию в udev уже заложены все необходимые для нормальной работы устройств правила. Но некоторые пользователи хотят самим настраивать устройства и выбирать им имена и права доступа. Кроме того, понимание процесса генерации файлов устройств даёт возможность глубже понять работу операционной системы.
Правила udev помогут вам, если вы хотите:
- переименовать устройство, например жёсткий диск или сетевую карту;
- создать дополнительное имя для устройства;
- поменять права доступа к устройству;
- установить владельца и группу;
- выполнить скрипт при подключении или отключении устройства.
Общая информация про udev
Правила udev хранятся в папке /etc/udev/rules.d. Файл правил обязательно должен иметь расширение .rules. Обычно в этой папке уже есть несколько файлов udev rules, но их трогать не рекомендуется, для своих правил лучше создать отдельный файл, например:
Правило udev состоит из нескольких пар ключ — значение, разделённых запятой. Одни ключи используются для проверки соответствия устройства определённому правилу. В таких ключах используется знак == для разделения пары, например: SUBSYSTEM == «block». Это значит, что правило будет применено, только если значение ключа SUBSYSTEM для этого устройства равно block. Другие ключи используются для указания действия, если все условия соответствия выполняются. Для разделения пар в таких ключах используется знак равно «=», Например, NAME=»mydisk». Ну и полностью правило:
SUBSYSTEM==»block», ATTR(size)==»1343153213″, NAME=»mydisk»
Это правило выполниться только для устройства подсистемы block и с размером 1343153213 байт. Откуда брать эти значения, мы рассмотрим ниже, а пока разберёмся, что же значат те или иные ключи. Сначала ключи соответствия:
- SUBSYSTEM — подсистема устройства;
- KERNEL — имя, выдаваемое устройству ядром;
- DRIVER — драйвер, обслуживающий устройство;
- ATTR — sysfs-атрибут устройства;
- SUBSYSTEMS — подсистема родительского устройства.
Устройство может иметь родительские устройства, например, жёсткий диск имеет родительское устройство SSCI, которое в свою очередь имеет родительское устройство — шину BUS. Иногда необходимо получить информацию от родительского устройства. Для этого используются ключи SUBSYSTEMS, KERNELS, DRIVERS, ATTRS соответственно.
Для действий используются ключи:
- NAME — установить имя файла устройства;
- SYMLINK — альтернативное имя устройства;
- RUN — выполнить скрипт при подключении устройства;
- GROUP — группа, у которой есть доступ к файлу;
- OWNER — владелец файла устройства;
- MODE — маска прав доступа.
Рассмотрим подробнее ключ ATTR. Он позволяет получить информацию об устройстве, доступную в sysfs. Например, ATTR
udevadm info -a -n sda1
Опция -n задаёт имя устройства, -p — путь в sysfs. Например, то же самое получим, если выполнить:
udevadm info -a -p /sys/block/sda/sda1
Как переименовать устройство в Linux
Теперь на основе полученной из udevadm информации можем составить udev rules для добавления альтернативного имени диска:
SUBSYSTEM==»block», ATTR
Или смены названия:
SUBSYSTEM==»block», ATTR
Получим устройство /dev/root, которое будет указывать на корневой раздел (sda1), то же самое можно сделать для привода оптических дисков:
udevadm info -a -p /sys/block/sr0
Затем добавляем правило на основе модели:
SUBSYSTEM==»block», ATTRS
После перезагрузки появиться файл устройства /dev/cdrom. Хотя, конечно, это можно сделать без udev, прописав в автозагрузку команду создания символической ссылки:
ln -s /dev/sr0 /dev/cdrom
Как переименовать сетевую карту
Настройка udev Linux на этом не заканчивается. Сетевая карта — тоже устройство и тоже управляется udev. Файлы сетевых устройств хранятся в /sys/class/net. Поэтому получаем информацию о ней с помощью udevadm:
udevadm info -a -p /sys/class/net/enp24s0
И создаём правило, например на основе mac-адреса:
SUBSYSTEM==»net», ATTR
==»00:d8:61:16:a5:a5″, NAME=»eth0″Перезагружаем компьютер, и теперь устройство называется eth0.
Как запустить скрипт при подключении устройства
Например, мы хотим автоматически скопировать все данные с флешки при её подключении к компьютеру. Мы знаем, что флешка будет называться /dev/sdb, тогда можно создать правило udev такого вида:
При подключении флешки выполнится скрипт /usr/bin/my_script и сделает необходимые действия. Нужно заметить, что скрипт не должен выполняться слишком долго, так как udev остановится и будет ожидать завершения его работы.
Отладка правил
Если вы не уверены, правильно ли составлено правило, можно воспользоваться командой udevadm test для проверки. В единственном параметре нужно передать путь sysfs-устройства. Например, проверим наше правило для жёсткого диска:
udevadm test /sys/block/sda
Среди многочисленного вывода видим строчку:
creating link ‘/dev/root’ to ‘/dev/sda’
Значит всё работает, и настройка udev выполнена успешно. Если же в правиле допустить синтаксическую ошибку, например UBSYSTEM вместо SUBSYSTEM, udevadm test выдаст что-то подобное:
read rules file: /etc/udev/rules.d/10-local.rules
unknown key ‘UBSYSTEM’ in /etc/udev/rules.d/10-local.rules:2
invalid rule ‘/etc/udev/rules.d/10-local.rules:2’
Здесь мы видим саму причину ошибки, неверный ключ, а также файл и строку, в которой допущена ошибка.
Выводы
На этом всё. Теперь вы знаете, как создать правило udev и взять под полный контроль все ваши устройства. Если нужна более подробная информация по созданию и использованию правил udev, читайте официальную документацию по udev в man.
Do not remove linux udev hardware record after restoring
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto | Site FAQ | Sitemap | Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
 | Introduction to Linux — A Hands on Guide This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter. For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author’s experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own. /etc/udev/rules.d/70-persistent-net.rules #770CommentsCopy link Quote reply gdha commented Feb 12, 2016I was doing a test with a VM restore (cloning) of a RHEL6 system and noticed that the eth0 device was renamed to eth2, and eth1 to eth3. After the recover the system came up, but with no IP address configured to eth2. In the recover log we find the following: However, this is easy to fix by:
This makes my think, wouldn’t it be better to remove this restored /etc/udev/rules.d/70-persistent-net.rules file during the recover process? As this file gets recreated during the reboot. Copy link Quote reply schlomo commented Feb 12, 2016Isn’t that a bug earlier up in the rescue part? E.g. when we boot the system and decide how to map the old interfaces of the source system to the new interfaces of the recovery system? the logic in 41_migrate_udev_rules.sh suggests that all decisions have been made much earlier and not here. Copy link Quote reply jsmeix commented Feb 12, 2016On my SLES12 system /etc/udev/rules.d/70-persistent-net.rules contains: I think it is a generic issue what to do during backup restore with files that are in the backup but should not be restored because they are automatically created and maintained by the system. The generic traditional example of such a file is /etc/mtab. As long as it was a regular file it must not have been restored with outdated content from a backup. Nowadays it is a symbolic link to /proc/self/mounts which should probably be restored to ensure that link is available (I don’t know if that link is automatically created by the system). I think in general the backup should contain all files to be complete and it is the task of the admin to explicitly exclude files from his backup restore that he does not want to restore via EXCLUDE_RESTORE. I think in general rear should handle the backup and restore task as «completely separated third party stuff» and not try to mess around with it. |