Устойчивые имена сетевых интерфейсов

Разработчики systemd продолжают вести нас в светлое будущее. В udev уже давно реализован механизм Predictable Network Interface Names, который представляет из себя кусочек кода на C, заполняющий переменные ID_NET_NAME_* исходя из свойств расположения физического сетевого устройства.

Считается, что подобный подход дает больше информации, чем прибитие гвоздями имен интерфейсов eth? к MAC-адресам в 70-persistent-net.rules. Однако, не обходится без недостатков. Например, при запуске системы под гипервизором VMWare ESXi, единственный сетевой интерфейс у меня называется eno16777728. Устройства, определяемые в DTB для одноплатных компьютеров на базе ARM, не поддерживаются схемой именования и имеют обычные имена eth?. А при подключении USB устройств, типа мобильных телефонов или модемов, схема именования генерирует скорее неустойчивые имена, потому-что в имя входит расположение устройства на шине USB, которое изменится при следующем подключении, таким образом придется настраивать интерфейс заново, потому-что предыдущие сохраненные настройки будут относиться к интерфейсу с другим именем.

К счастью, udev заполняет переменную ID_NET_NAME_MAC, представляющую имя интерфейса, основанное исключительно на его MAC-адресе. По-умолчанию, эта переменная не используется, но можно поменять стандартное поведение для USB-устройств. Один способ - через настройку udev, второй - используя systemd.link, файл, используемый systemd, для конфигурации сетевых интерфейсов.

Создадим файл /etc/systemd/network/90-usb.link следуя инструкции:

[Match]
Path=*-usb-*
[Link]
NamePolicy=mac

Юнит-файл состоит из двух секций: [Match] для описания устройств к которым он относится и [Link] для описания того, что с ними делать. В примере выше мы просим systemd использовать политику именования основанную на MAC-адресах для всех устройств подключенных через USB. После выполнения systemctl daemon-reload можно подключить устройство и увидеть его интерфейс с именем enx112233445566. Достаточно длинное, но уникальное (в известных пределах) и не изменится при следующем подключении устройства.

Кроме изменения имени через systemd.link можно настроить WOL, MTU, ограничить скорость на интерфейсе, назначить устройству другой MAC-адрес.

udev и camsource

(Пере)запускалка camsource (программы для показывания картинок с веб-камер) с помощью udev:

SUBSYSTEM=="video4linux", ACTION=="add", RUN+="/usr/bin/camsource -r /etc/camsource.conf"

Запускается на старте (когда udev обнаруживается usb-устройства), и перезапускается при их перетыкании (или перетыкивании).

Можно было бы сделать более красиво, т.е. использовать события "add" и "remove" и переменную DEVICE. Однако этому мешает, во-первых, использование нескольких источников в моей конфигурации (и camsource -k выключил бы сразу все), во-вторых какой-то встроенный глюк в самой программе. Дело в том, что запускаясь, процесс почему-то уходит в состояние зомби, и в /proc/NNNNN/fd оказывается пустота. А при использовании параметра [device] код ищет процесс именно по файловым дескрипторам. Иначе говоря, этот параметр вообще не работает.

Применив фантазию к udev, можно например включать трансляцию видео-потока. Что даже удобнее, чем вписывание не комплектуемых init.d-скриптам запуска camsource, ffserver и т.п. во всякие странные места типа /etc/init.d/boot.local.

Режим EPP для Winbond W83627D

Попался компьютер (с Intel Atom), в котором, не смотря на все установки в BIOS, LPT-порт не попадал в EPP-моду. Симптоматика стандартная — EPP-timeout не сбрасывается. Оказалось, что контроллер W83627D, несмотря на все установки BIOS, оставался в ECP-моде, либо сбрасывался туда по какой-то причине.

Данный контроллер имеет служебный режим и его можно переключать в нужную моду прямо на ходу. Ничего не взломав, не сломав и не испортив, в интернете можно даже найти его полное описание, где все нужные команды содержатся. Кроме того, полезной подсказкой является кусок исходников ядра Linux, а именно parport_pc.c.

Запуск enable_epp добавляется например в udev.

udev и video4linux

Оказывается, /lib/udev/rules.d/60-persistent-v4l.rules делает символические ссылки на устройства video4linux (/dev/videoN): /dev/v4l/by-id и /dev/v4l/by-path.

Очень удобно оказалось использовать, например, /dev/v4l/by-id/usb-0471_0329_01690000A6480288-video-index0 вместо /dev/video0 (или /dev/video1), когда камер много.