eudev обновился

Ты теперь о каждом обновлении ебилда eudev будешь в толксы докладывать?

Народ, у вас сабж с glibc 2.17 нормально собирается?

glibc 2.17

А его что, уже размаскировали?

А его что, уже размаскировали?

Да, в арче. :)

а в будущем удеве красота, меняют правила именовая persisent-net девайсов, возвращая проблемы решенные в 2007.

Младореформаторы - они такие.

Ага, в RedHat'е одни дураки сидят.

возвращая проблемы решенные в 2007.

Можно с этого места поподробнее?

Ну почему же одни. Не одни.

а где почитать от кого лес горит?

насколько я понял:

возвоможные race condition в случае одновременного переименования и появляения устройства с таким же именем. Насколько я понял системы с systemd не затронет, т.к. изменения придут вместе с решением со стороны системд.

Ну и как обычно утверждения, что это даёт гарантии действительно неизменяемых имён, хотя это и так есть.

Я как заинтересованый в разработке eudev пользователь написал.

репозиторий udev? Я знаком по обсуждению на #gentoo-dev, моя информация может быть не до конца верной, ибо я плохо разбираюсь в udev.

Где же они раньше то были? Я уже везде смержил / и /usr, благо lvm.
Или у сабжа есть еще какие-то фичи, кроме поддержки /usr отдельным разделом?

Арчепроблемы:-)

В генте он хардмаскед.

Основная фича - это старый, добрый и работающий udev.

Добавил лог изменений.

Новый 'systemd-шный' udev тоже работает, если /usr на отдельном разделе не нужен.

Новый 'systemd-шный' udev тоже работает, если /usr на отдельном разделе не нужен.

Официально стартовал проект eudev — форк udev от Gentoo (комментарий)

блин лень ковырять их рассылки

Ну теперь Пёттерингу точно капец.

это более того в irc было, а логируется ли канал, чтобы дать ссылку я не знаю.

Я удалил gentoo.

а в будущем удеве красота, меняют правила именовая persisent-net девайсов, возвращая проблемы решенные в 2007.

Не решенные. Из-за ненадежности старой схемы привязки имен интерфейсов к MAC-адресам у меня на работе только чуть-чуть не дошло до суда с хостером (который мы бы все равно проиграли, т.к. баг был в udev'е).

Сути такая. Заказали у американского хостера выделенный сервер Dell, попросили поставить Debian Stable. В сервере две набортные сетевые карты broadcom (на момент заказа это было невозможно знать), требуют firmware, которого в debian installer'е нет. Сотрудник хостера временно поставил туда сетевую карту от Intel, поставил Debian через нее по сети, в результате eth0 = intel, eth1 = broadcom, eth2 = broadcom. Все три карты подключены к одному свитчу. Udev благополучно записал свой файлик с персистентными правилами привязки имен к MAC'ам. Сотрудник хостера поменял в /etc/network/interfaces, чтобы система ходила в интернет через eth1, а не через eth0, выключил сервер, убрал intel'овскую карту, включил сервер обратно. Итог: eth0 не существует, eth1 = broadcom (с интернетом), eth2 = broadcom (с доступом во внутреннюю сеть хостера - т.е. по сути не используется), все работает, можно пользоваться сервером. На свитче хостер прописал соответствие нашего IP и MAC от eth1 (мы об этом не знали).

После этого сервер несколько раз перезагружали, и все работало как надо. Только один раз дело дошло до незапланированной перезагрузки. После нее сервер перестал пинговаться. Письмо хостеру, они рапортуют «все исправлено». Ну да, пингуется и работает, более детально проверять не стал, т.к. не было повода. До следующей перезагрузки. После чего начали на них собирать материалы для судебного иска за нарушение SLA.

А хостер спрашивает: «а что это у вас там за система резервирования каналов? почему ваш IP прыгает по MAC'ам, а я ничего не знаю?». Я тоже ничего не знаю. Подняли логи хостера - выяснилось, что IP прыгал с первой broadcom'овской сетевой карты на вторую. Т.е. персистентное правило существовало, но не применялось!

Потом на IRC мне объяснили, что избежать такого рода проблем при переименовании ethX -> ethY при условии, что целевое имя может быть занято (а у нас это так, в наиболее распространенном случае надо переименовать eth0 -> eth1, eth1 -> eth2), практически невозможно, и что я ССЗБ, так как использовал Debian, а не RHEL, где biosdevname есть по умолчанию и такого глюка просто не может быть. Приятно видеть, что и остальной мир отвяжут от этой ненадежной старой схемы.

P.S. хостера все равно сменили по другим причинам.

Ага, в RedHat'е одни дураки сидят.

Текущая версия systemd не интересует RedHat.

СПВ уже да...

а у меня

undefined reference to `mq_getattr'

Я вот думаю - хотелось бы обновить вино (1.4.1), но новое вино хочет новый удав, а новый удав ставить не хочется, поставить eudev?

Сотрудник хостера временно поставил туда сетевую карту от Intel, поставил Debian через нее по сети, в результате eth0 = intel, eth1 = broadcom, eth2 = broadcom. Все три карты подключены к одному свитчу. Udev благополучно записал свой файлик с персистентными правилами привязки имен к MAC'ам. Сотрудник хостера поменял в /etc/network/interfaces, чтобы система ходила в интернет через eth1, а не через eth0, выключил сервер, убрал intel'овскую карту, включил сервер обратно.

если я всё правильно понимаю, то он должен был потереть файлик persistent-net. ну или втыкать карточку последней. Т.к. имена интерфейсов выдаются в PCI-bus-order, то они бы выдавались правильно даже без персистентных правил.

Остаются некоторые проблемы, которые этот патч решает лучше, чем другие, но при этом он ломает настроенные системы, таким образом это является хорошим решением, но плохим умолчанием.

тебе ведь приходилось рыться в редхато-коде не относящемся к ядру, особенно тому поддержка, которого в последний год стала неактивной?

undefined reference to `mq_getattr'
баг завтра запилю

Уже запилил, уже исправили. :)

https://github.com/gentoo/eudev/issues/40

имена интерфейсов выдаются в PCI-bus-order

Это неверно. Собственно, именно из-за неверности этого весь сыр-бор.

Имена на самом деле даются ядром интерфейсам в порядке привязки драйверов к PCI-устройствам. Драйвера привязываются к PCI-устройствам приблизительно в том порядке, в котором udev загружает их модули. А модули загружаются параллельно и, следовательно, в _случайном_ порядке, который даже не является неизменным между перезагрузками системы.

понял, тогда согласен.

в общем-то решения можно сделать и с существующим udev, напр. если бы ядро и удев переименовывали девайсы в разных пространствах имён, или делать тоже самое хаком, автоматом переименовывая девайс в _renaming и потом применяя персистент правила.

В любом случае принятое решение решает проблемы достаточно эффективно, но при этом ломая часть систем. В целом мне лично пофиг, поскольку в gentoo будет use flag на это дело.

cat /etc/network/interfaces ?

Вчера-сегодня ставил с нуля генту на работе, система матюгалась что нету /sbin/udevd. Потребовалось поставить eudev, иначе большая и мохнатая.

cat /etc/network/interfaces

К сожалению, уже не могу. Контракт расторгнут. А с того сервера, который на замену у другого хостера - ничего интересного, статика с алиасами на одном интерфейсе eth0.

Навскидку не вспомнишь? ethX подымался через auto-правила или allow-hotplug? (сильно думаю, что проблема в автоподъёме).

По умолчанию в Debian используется allow-hotplug, но на большинстве серверов, которые настраиваю сам, я переделываю на auto. Думаю, что там тоже переделал, но на 100% уже не уверен.

Впрочем, не понимаю, как это может привести к имевшему место багу. Ведь в случае использования auto попытка поднять интерфейс получается ровно одна, из init-скриптов, никак не привязанная к обработчикам uevent'ов (в отличие от allow-hotplug), и заведомо после udevadm settle.