Systemd-udevd

Added by Alexander Tratsevskiy over 2 years ago

Самое на наш взгляд неприятное, чем грозит повальный переход на systemd, это отсутствием выбора! Откройте Gentoo Handbook и вы увидите всё богатство выбора, которое предоставляет вам Linux: выбор системной службы журналирования, выбор демона cron, выбор dhcp-клиента, выбор загрузчика и т.д. Пробуйте, сравнивайте, оценивайте по вашим задачам и выбирайте для себя лучшие решения!

А теперь давайте посмотрим, что нам предлагает интегрированный в состав systemd udev. Возможно вы сталкивались с такой вещью, как изменение имён сетевых интерфейсов после обновления ядра "eth0 <-> eth1". Это может происходить по разным причинам, например для двух карт стал использоваться один драйвер, либо его логика изменилась. Если ваш сервер имеет более одной сетевой карты, случайное переименование может сделать сервер недоступным! В своё время, чтобы не наступить на эти грабли дважды, мы просто отключили вторую сетевую карту в Bios.

Позже с приходом Udev появилось неплохое решение, вы могли чётко зафиксировать имена eth0 и eth1 по мак-адресу в файле настроек /etc/udev/rules.d/70-persistent-net.rules. Переименование работало корректно даже если ядро использовало те же имена. В этом случае Udev переименовывал примерно так: eth1 -> eth125, eth0 -> eth126, eth125 -> eth0 и eth126 -> eth1. И всё работало ровно до того момента пока Udev не начали прибивать гвоздями к systemd, выпиливая идеологически ненужный функционал. В новых версиях Udev переименование работает только в том случае, если оно не конфликтует с уже присвоенными ядром сетевыми именами интерфейсов. Изменения коснулись и 70-persistent-net.rules, который больше не создаётся по умолчанию.

Около двух месяцев назад мы проводили опрос о предпочтениях пользователей. В опросе участвовало 220 человек. Из них 76% опрошенных отдали предпочтение классическим именам "eth0" и только 6% новым "enp0s25". Мы задались вопросом о том, можно ли вернуть классические имена. Вспомнили предложение пользователей мигрировать на eudev. К этому времени уже были выполнены успешные переходы на eudev в других дистрибутивах. Eudev на тот момент использовал как раз классические имена по умолчанию и обладал всем тем функционалом, который был удалён в Udev. Казалось бы вот оно счастье.

Но вышел Eudev 3.0, главной целью которого похоже ставят отсутствие зависимостей от systemd. В остальном, к сожалению, он остаётся всё тем же клоном Udev. Похоже разработчики просто смирились, выбрав меньшее зло. У себя вы можете по прежнему использовать классические имена несколькими способами: передачей параметра net.ifnames=0 ядру при загрузке или удалением скрипта отвечающего за именование сетевых интерфейсов /lib/udev/rules.d/80-net-setup-link.rules. Потребуется так же удалить готовые правила /etc/udev/rules.d/70-persistent-net.rules, либо вписать классические имена. Если сетевая карта одна, проблем никаких не будет.

Восстановление и поддержка правил переименования интерфейсов потребует дополнительных временных затрат. Всё же это не наша цель. Скорей всего в итоге все дистрибутивы Linux будут использовать новые имена. То ли ещё будет.

Сегодняшним обновлением портежей 30-я ревизия (/var/lib/layman/calculate/profiles/templates/3.3/6_ac_update_sync/revision/30-net_trigger) создаст /etc/udev/rules.d/70-persistent-net.rules, если он у вас не создан. Обратите внимание, если у вас несколько сетевых карт, вы используете классические имена сетевых интерфейсов "eth0" и вы используете openrc для настройки сети, с переходом на eudev 3.0 переименование может не сработать! Дайте именам свои названия, отредактировав файл 70-persistent-net.rules, после чего проверьте ваши настройки сети /etc/conf.d/net, наличие символических ссылок в /etc/init.d/net.XXX, а так же другие ваши настройки, где используются сетевые имена, например маршрутизатора, файрвола.

bamboo_bike.jpg (63.8 KB)


Comments

Comment

Added by Николай Ка over 2 years ago

Ну то есть мы вернулись к ситуации полуторалетней давности, когда udev форкнули параллельно две команды, после долгой и мучительной дискуссии на багзилле коды слили на условиях разработчиков gentoo, а теперь опять появилась необходимость в форке форка... что и будет, вернее всего, сделано. Появились уже сообщения о переводе грядущих версий некоторых пакетов с gtk3 обратно на gtk2... Имена интерфейсов -- не самое большое зло, хотя помимо неэстетичности/неудобности длинных имён есть свои недостатки. Переткнув карточку в другой слот мы получим ровно ту же проблему, только без средств её решения в виде 70-persistent-net.rules в стиле "прописал один раз и голова не болит". Главная проблема -- искусственное создание головных болей для всего линукс сообщества как силового аргумента в пользу своих решений.

У меня иногда создаётся впечатление, что подпольная цель красной шапочки -- популяризация FreeBSD... я для себя решил, что если линукс сообщество всё-таки прогнётся под Red Hat с их маниакальным желанием контролировать развитие системы полностью, я готов свалить на фрю. Не так уж она и отличается от gentoo, по большому счёту.

Comment

Added by Никита Блюдин over 2 years ago

Симлинк 80-net-setup-link.rules -> /dev/null в /etc/udev/rules.d/ более правилен чем удаление /lib/udev/rules.d/80-net-setup-link.rules, который к тому же вернётся после переустановки/обновления.

Comment

Added by Alexander Tratsevskiy over 2 years ago

Не вернётся если удалять шаблоном.

Comment

Added by Jonny Talker over 2 years ago

Alexander Tratsevskiy писал(а):

Сегодняшним обновлением портежей 30-я ревизия (/var/lib/layman/calculate/profiles/templates/3.3/6_ac_update_sync/revision/30-net_trigger) создаст /etc/udev/rules.d/70-persistent-net.rules, если он у вас не создан.

Не создал.

Comment

Added by Alexander Tratsevskiy over 2 years ago

Не создал.

В /etc/calculate/ini.env в секции [overlay-distros] world = 30? eudev какой версии?

Попробуйте выполнить

/bin/udevadm trigger -c add -s net

Отработает, если у вас eudev версии < 3.0

Comment

Added by Jonny Talker over 2 years ago

Alexander Tratsevskiy писал(а):

В /etc/calculate/ini.env в секции [overlay-distros] world = 30?

...world = 28
обновлял через cl-update сегодня, буквально недавно
т.е. сегодняшняя 30-я ревизия будет более позднее чем сегодня?

eudev 3.0 (думаю что если бы версия была бы ниже, то не писал бы ничего, а так мне это eth сломало)

/bin/udevadm trigger -c add -s net

ни к чему визуальному или хорошему не привел

И еще один вопрос, не совсем про eudev, но с ситуаций связаный возможно:
Если что-нибудь устанавливась с использованием --oneshot - то "cl-update -e -v" под конец выдаёт предложение это "что-нибудь" удалить. Удалять не хотим и на "No" получаем "Update failed", хотя вроде всё обновилось: http://www.calculate-linux.org/issues/659
Будет ли более правильным делать в таком случае "cl-update -e -v -o " ? (ибо оно хотя бы не заказнчиватся "Update failed")

Comment

Added by Alexander Tratsevskiy over 2 years ago

Немного ошибся, посмотрите в секции "[overlay-calculate]" чему равно значение world.

Обновление до eudev 3.0 привело к поломке путей. Мы сделали откат до 2.1.1, после чего написали ревизию, прописывающую имена в 70-persistent-net.rules. Возможно вы не обновляли несколько дней, получилось так, что ревизия не отработала, т.к. в 3.0 уже нет правила, создающего файл с именами.

По поводу "Update failed", поправим в ближайшее время.

Comment

Added by Jonny Talker over 2 years ago

Да, так и было. Это был стейдж cds-20150312-x86_64 и он с установки не обновлялся. Система была тестовая (жду номерного релиза), так что ничего страшного не случилось

В ini.env сейчас имею: http://pastebin.calculate-linux.org/en/show/10680

[overlay-calculate]
remerge = 35
world = 3
revision = 30

И по "Update failed". Может стоит добавить выключенный по дефолту ключ который предлагал бы удаление не всем "набором", а "поштучно"? И не так категорично: No => Failed.

Comment

Added by Alexander Tratsevskiy over 2 years ago

Поштучно думаю не очень неудобно будет, если допустим 5-10 пакетов будут удаляться, в этом случае нужно запастись терпением и жать Yes/No с определёнными интервалами. Опять же это будет не поведение по-умолчанию.

Thank you!