27-го января - тестовый день Fedora

>А убивать ненужные не пробовал?

Когда это все происходило не было времени на «убивать», были куда важные задачи. Да и какая разница, сейчас все уже прописано в файрволле, и sed из vim'a все делает за раз :)

Жесть. Дистрибутив «не запомнил».

Вот редхатовцы тоже задумались. Посмотрим что у них получится.

главное, чтоб можно было по-старому. почему-то в макоси en<X> и нормально

А если интеловская на 4 гнезда сетевуха -> 1 pci порт = 4 сетевухи ???

А куда это он его запомнил интерестно? Конфиги какие-то свои автоматически поменял?

почисти от старых маков /etc/udev/что-то_там...

У меня другой вопрос, это вот так уже неизвестно сколько лет интерфейсы рендомом меняются и всех все устраивает? Или это просто наглая ложь и федоровцы - идиоты?

>не возможно с точностью сказать, какой адаптер будет именоваться

Для этого есть: «ethtool -p ethN»

>А если интеловская на 4 гнезда сетевуха -> 1 pci порт = 4 сетевухи ???

У меня двухголовые интеловские, так что по порядку eth(n), eth(n+1)...eth(n+i) Фишка в том, что по привязке на MAC они не путаются.

> Так что правильно начали

Правильно будет просто поправить /etc/udev/rules.d/70-persistent-net.rules.

>почисти от старых маков /etc/udev/что-то_там...

Ага, гляну.

>интерфесов

Проверено: maxcom

Уже не первый раз.
Когда будет Тестовый День ЛОРа?

PS Вы што, кудата спешыте?

фишки на самом деле две - одна это наличие кучи сетевух, так что кмоды для них грузятся долго, и инитскрипты не успевают переименовать все найденное по маку из ifcfg из dev$RANDOM в ethN
а вторая - если сетевух много, и они разных производителей - тогда все еще хуже, потому что рейс между загрузкой кмодов и инитскриптами никаким udevом не поправить. только прогнать заново набор нужных скриптов в rc.local - а это вообще уродство.

когда сетевуха привязана к физическому адресу в системе, ей сразу после загрузки кмода дается название, и не надо соревноваться кто первый - модуль драйвера или скрипт переименования по маку

>Написали что при кол-во интерфейсов больше чем 1 они могут меняться

а так при перетыкании карты из слота в слот они тоже будут меняться.

Все это странно и глупо.

вот уж не надо

>когда сетевуха привязана к физическому адресу в системе, ей сразу после загрузки кмода дается название, и не надо соревноваться кто первый - модуль драйвера или скрипт переименования по маку

а, то есть вопрос в том, что модуль ядра гарантированно именует интерфейс в своем пространстве, чтобы не помешать udev переименовывать его затем в нужный ethX и быть уверенным, что это имя не занято?

Тогдабез вопросов, это верное решение.

> Даже при смене адаптеров, все что требовалось поправить - udev rules, и ifcfg-ethN. Зачем они это делают?

Что бы не приходилось переписывать, очевидно же. Основная проблема в том, что если сетевуха меняется (например, старая вышла из строя), то её MAC уже не совпадает и имя может измениться. Теперь же замену можно осуществлять по принципу: Переткнул и пошёл.

У меня куча скриптов написанных мною с завязкой под «eth*». Теперь придется все переписывать?

Не думаю. Вам ничто не помешает добавить udev правило, создающее для новых интерфейсов привычные вам eth<X> алиасы. И после этого переписывать уже не придётся ничего.

а поправить ручками

/etc/udev/rules.d/70-persistent-net.rules

не пробовали?

или стереть его после замены сетевухи и перезагрузиться?

> У меня куча скриптов написанных мною с завязкой под «eth*». Теперь придется все переписывать?

Нет, не придётся. Просто добавь в юдев правило для старого имени и живи спокойно.

> Вам ничто не помешает добавить udev правило.

И как я добавлю такое правило, если например скрипт, расчитан на выполнение при установке системы для моих респинов.

я уже не смогу сделать что-то вроде:

for i in 0,1,2,3,4,5; do «something with eth$i»; done

т.к. заранее понятия не имею на какое железо будет ставится система и с чем мне там надо работать и чего ожидать.

P.S. скачал rawhide по ссылке - в виртуалбоксе вообще не запускается... lol

>а, то есть вопрос в том, что модуль ядра гарантированно именует

интерфейс в своем пространстве, чтобы не помешать udev переименовывать

его затем в нужный ethX и быть уверенным, что это имя не занято?

сейчас модуль ядра дает рандомальное имя интерфейсу по формату dev$RANDOM, а инитскрипт (или udev, у энтузиастов), парсит мак из драйвера или из ifcfg-ethX и переименовывает dev$RANDOM в соответствующий ethX.

при маленьком кол-ве интерфейсов, и/или когда они все обнаруживаются одним и тем же модулем (то есть все они одинаковые, и разница только в МАКе), все пашет. но если их много, да еще и разных производителей, получается что одни модули грузятся быстрее других, и переименовываются вовремя, а другие тормозят (привет bnx2!), и к тому времени когда они поднялись, инитскрипты уже отработали, и интерфейсы остаются dev$RANDOM вместо своего нормального названия

А если интеловская на 4 гнезда сетевуха -> 1 pci порт = 4 сетевухи ???

Думаю слот будет один, порты разные.. Что нибудь типа

ethernet 2#3265
ethernet 2#3465
ethernet 2#3665
ethernet 2#3865

>>на wiki страничку

Тире мы, видите ли, потеряли!

Граммар-оборотни, не отличающие тире от дефиса, будут торжественно сожжены на следующем юбилее Розенталя.

ЛОР работать не будет?

Что бы не приходилось переписывать, очевидно же. Основная проблема в том, что если сетевуха меняется (например, старая вышла из строя), то её MAC уже не совпадает и имя может измениться. Теперь же замену можно осуществлять по принципу: Переткнул и пошёл.

а если вместо сгоревшей воткнуть 2 сетевухи, какая из них встанет на место сгоревшей?

Зачем они это делают? У меня куча скриптов написанных мною с завязкой под «eth*». Теперь придется все переписывать? Это только усложняет жизнь.

что не судьба было в начале скрипта определить переменные соответствующие сетевым картам?

Почему у меня не меняются на 2х серваках? ЧЯДНТ?

не пользуетесь Федорой, не?

>при маленьком кол-ве интерфейсов, и/или когда они все обнаруживаются одним и тем же модулем (то есть все они одинаковые, и разница только в МАКе), все пашет. но если их много, да еще и разных производителей, получается что одни модули грузятся быстрее других, и переименовываются вовремя, а другие тормозят (привет bnx2!), и к тому времени когда они поднялись, инитскрипты уже отработали, и интерфейсы остаются dev$RANDOM вместо своего нормального названия

Я помотрел в федорную страничку. Ими предлагается использовать в правилах udev вместо ручной прописи постоянного соответствия маков->ethX, автоматическую юзерспейсную утилиту, рожденную в недрах dell

http://linux.dell.com/biosdevname/

каким образом другое правило в udev излечит вышеуказанную вакуумносферическую проблему с рейсами при загрузке нескольких модулей для меня остается загадкой...

>не пользуетесь Федорой, не?
в федоре какой-то другой udev?

для меня тоже на самом деле :) я с этой проблемой сталкиваюсь в основном на больших монстрах для виртуализации, где 10-30 интерфейсов, и намешан салат из гигабитных и 10гб карточек. на «монстрах» установлен RHEL а не федора

> У меня более десяти серверов работают в разных школах от fc7 до fc14

А я думал партизаны-вредители в 45-ом перевелись.
Федора на сервере в школе, это все равно как мой дед во вторую мировую эшелоны под откос пускал.

... ложь и федоровцы - идиоты?

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

Федора на сервере в школе, это все равно как мой дед во вторую мировую эшелоны под откос пускал.

Свои, что ли, эшелоны пускал под откос?

Я так понял, в этом случае проблема в таймаутах в /etc/init.d/network. То есть сеть не успевает проинициализироваться и скрипт вылетает с ошибкой.

А в федоре проблема в именованиях устройств. Это совсем другое.

я с этой проблемой сталкиваюсь в основном на больших монстрах для виртуализации, где 10-30 интерфейсов, и намешан салат из гигабитных и 10гб карточек. на «монстрах» установлен RHEL а не федора

как там раздаются имена карточкам, через udev ищи ещё как-то?

> Свои, что ли, эшелоны пускал под откос?

Почему? Чужие.

через initscripts обычно

>А в федоре проблема в именованиях устройств. Это совсем другое.

почему другое? принцип тот же

Что-то в этом всём не так...

После прочтения комментариев сложилось впечатление, что все-таки нужно. Пусть тестируют. Посмотрим, что получится.

Кто разобрался в вопросе полностью, скажите, чем XX-persistent-*.rules не устраивают генераторов идей из топика?

>брали бы пример с OpenBSD или с Солярки - там сетевухи называются по имени драйвера.

Спасибо. Хавайте это г... сами.

И..?

>Кто разобрался в вопросе полностью, скажите, чем XX-persistent-*.rules не устраивают генераторов идей из топика?

Всех все устраивает. Федоровцы хотят запулить эту фичу для серверов. Дела десктопщиков не сильно интересуют. И кстати от 70-persistent-net.rules никто не отказывается еще, скорее всего правило (+ скрипт) перепишут по физическому расположению исходя из pci<слот>#<порт>_<виртуальный-экземпляр-функции>.

Да нет. В федоре вопрос поставлен в том ключе, что нельзя точно сказать заранее, какое из ethX получит устройство. Причем если на картчке несколько портов, то вообще хрен знает, как они проинициализруются. А тут каждое из них получит свое устройство в зависимости от того, как его воткнули в комп. И пока ты его не переткнешь, ничего не изменится.

Если где-то возникают devRAND, то они так и останутся неопределенными.

А чо, хорошая идея. У меня дома стояла машинка с четыремя разными PCI-ными сетевушками. С номерами творились просто какие-то чудеса, особенно если что-нибудь поменять.

В федоре вопрос поставлен в том ключе, что нельзя точно сказать заранее, какое из ethX получит устройство. Причем если на картчке несколько портов, то вообще хрен знает, как они проинициализруются.

Во время первой установки или после каждой перезагрузки?

Можно тестить с загрузочного livecd.

При первой установке.

А если отключить запоминание макадресов в /etc/udev, то теоретически и при перезагрузке, поскольку какой модуль первым стартует, такой и пронумерует.

Собственно предлагается вместо запоминания макадресов использовать механизм разделения по месту подключения.

>теперь я работаю с eth13 и eth14

осиль, блджад, правила удава. Я на серваках своих сменил туеву хучу сетевух - и УМВР

Поддерживаю начинание. Действительно ждёшь чего угодно при втыкании новой сетевухи.