predictable interface names: по-моему это fail

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

менял.

лог загрузки.

Зачем нужны какие-то новые имена?

прочитай на wiki fdo-шной, там понятно написано, заодно в обсуждении там можешь поутверждать, что у раз у тебя проблемы нет, то ни у кого нет, а у кого есть так-то руки кривые. Проблемы объективно есть, их можно решить разными способами без predictable naming rules, можно и с ним, это один из вариантов со своими плюсами и минусами, не являющийся ни панацеей ни злом во плоти.

нет. Не показал.

нет, показал, ты сказал, что проблема из-за системд, я тебе возразил, что это чисто udev-во решение введенное в 197 и никаким боком к systemd не относящееся. По этому вопросу возражения есть?

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

Если обозвать eth0 как eth0, то он будет eth0, в чём проблема-то?

я попросил тебя сделать так, чтобы eth0 стало eth1, а eth1 стало eth0 при следующей загрузке. Что ты там решаешь - я не понимаю..

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

у меня на моих use-case в генте проблем с сетевыми интерфейсами нет. Ну и мне кажется, что ты даже не понял о чем разговор.

немного не так, для сетевухи они будут обозваны ядром в ethX в порядке загрузки модулей + порядке инициализации шины. В случае pci это pci-bus order, в случае usb это как попало, в зависимости от оборудования, причем для монолита все проще т.к. модули уже загружены, в отличии от отдельных модулей. Параллельно с этим при появлении ethX устройства в дело вступает udev, который переименовывает их в том же namespace в ethY в зависимости от правил; соответсвенно если udev хочет переименовать eth0 -> eth1, но в ~этот же момент ядро создало eth1, то процесс переименования обламывается, и когда udev хочет переименовать eth1 в eth0 он опять обламывается. Решений много, решения не сложные, а использовать уникальную инфу для сетевухи (predictable-network-naming) это одно из решений, со своими плюсами и минусами.

Ну дык удав их и переименовывает как надо

а не может это случиться после того как интерфейс уже будет сконфигурен?

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

udev их переименовывает в нужном порядке в момент загрузки ориентируясь по их MAC. В слаке так сделано. Ну а если ты на своём сервере провода перетыкаешь по горячему - ССЗБ.

udev их переименовывает в нужном порядке в момент загрузки ориентируясь по их MAC.

Не может быть так что перименование произойдёт после того как будут прописаны айпишники и роуты?

лог загрузки.

будет под рукой - кину. Сейчас у мну десктоп с одной сетевой.

прочитай на wiki fdo-шной, там понятно написано, заодно в обсуждении там можешь поутверждать, что у раз у тебя проблемы нет, то ни у кого нет, а у кого есть так-то руки кривые. Проблемы объективно есть, их можно решить разными способами без predictable naming rules, можно и с ним, это один из вариантов со своими плюсами и минусами, не являющийся ни панацеей ни злом во плоти.

ты слышал про бритву Оккама? Вот и объясни мне, нафейхуя?

А нужный порядок — это какой? Если он по MAC в алфавитном порядке выставляет, то что будет, если его сменить?

Ну а если ты на своём сервере провода перетыкаешь по горячему - ССЗБ.

Ну конечно. Если ты свет выключаешь — ссзб, бэкапы для слабаков. Если железо перевтыкаешь без перезагрузки — ссзб. А еще есть такой ССЗБ-пакет для обновления ядра без перезагрузки.

нет, показал, ты сказал, что проблема из-за системд, я тебе возразил, что это чисто udev-во решение введенное в 197 и никаким боком к systemd не относящееся. По этому вопросу возражения есть?

нет.

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

ну значит у тебя неправильный удав, раз он даже eth не умеет.

я попросил тебя сделать так, чтобы eth0 стало eth1, а eth1 стало eth0 при следующей загрузке.

ну для этого надо правила переписывать. Я переписывал как-то, в чём проблема? Мне как раз и надо было, что-бы eth0 стало eth1, ибо конфиги переписывать меня ломало, а я их с другого сервера скопипастил.

у меня на моих use-case в генте проблем с сетевыми интерфейсами нет. Ну и мне кажется, что ты даже не понял о чем разговор.

ну дык поясни, нафейхуя какие-то новые имена интерфейсам дают?

В случае pci это pci-bus order

на одном моём локалхосте pci карточки определяются рандомно, иной раз первая первой, а иной раз наоборот. От чего зависит - я не знаю.

соответсвенно если udev хочет переименовать eth0 -> eth1, но в ~этот же момент ядро создало eth1, то процесс переименования обламывается

не обламывается, а переименовывает в eth2, а потом в eth1(после переименования eth1 → eth0). Я потом тебе лог с этой ерундой покажу, если ты мне не веришь.

а не может это случиться после того как интерфейс уже будет сконфигурен?

меня просили не поливать говном systemd, потому ответ - нет. У меня такого быть не может. У тебя - без понятия, man systemd.

Разве удев умеет прерывать контекст правил и продолжать его после каких то новых событий?

Не может быть так что перименование произойдёт после того как будут прописаны айпишники и роуты?

именно потому мой локалхост грузится 7 секунд, а не 3. Что-бы такой ерунды не было.

Разве удев умеет прерывать контекст правил и продолжать его после каких то новых событий?

нет. Судя по логу, сначала определяются интерфейсы ВСЕ ВМЕСТЕ, а затем удав их переименовывает. Или даже переименовывает ОДНОВРЕМЕННО, потому-что иногда в логах видно, что переименование было ДО определения.

Но - какая разница? Главное, что одна сетевуха eth0, вторая eth1 и так далее, как их не втыкай. Не вижу проблемы.

вот тебе объяснение сути проблемы: predictable interface names: по-моему это fail (комментарий)

сжато: проблем нет в том случае если гарантируется, что ядро не создает устройства в том же namespace, куда переименовывает udev. На самом деле условие можно ослабить, но мне строго не сформулировать это. Для решения этой проблемы есть 2 пути: 1). использовать разные пространства имен (так сделали в predict-n-n, так делают руками как ТС -давая логические имена), 2). делать повтор операции в случае фейла, при этом переименовывать через временное имя (мне этот вариант нравится больше) но из-коробки его нигде нет.

Есть третий путь закрыть на проблему глаза, т.к. она не частая.

Не, то что оно их может перименовать в какое то новое нечто - это понятно. А как оно переименовывает обратно?

делать повтор операции в случае фейла, при этом переименовывать через временное имя (мне этот вариант нравится больше) но из-коробки его нигде нет.

4.2

в слаке именно так и сделано. Т.ч. это всё-же гентопроблема. Пинай своих маинтейнеров, Патрег осилил.

ну для этого надо правила переписывать. Я переписывал как-то, в чём проблема?

видать не та ситуация, просто это я привел простейший вариант, как получить гонку и интерфейсы в этом случае должны остаться не переименованными несмотря на правила. Хотя тут может и не прокатить, и чтобы было уж совсем правильно хорошо бы sleep добавить.

ну дык поясни, нафейхуя какие-то новые имена интерфейсам дают?

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

тебя попросили поливать говном удев, а не системд да и то в рамках этого треда .

Не, то что оно их может перименовать в какое то новое нечто - это понятно. А как оно переименовывает обратно?

ну так и переименовывает

eth1 → eth2
eth0 → eth1
eth2 → eth0

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

/me пнул себя, а Вильяма позже пну.

в persistent-names.rules что-то принципиально отличное от:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:21:cc:4a:a9:d0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

видать не та ситуация, просто это я привел простейший вариант, как получить гонку и интерфейсы в этом случае должны остаться не переименованными несмотря на правила. Хотя тут может и не прокатить, и чтобы было уж совсем правильно хорошо бы sleep добавить.

УМВР без всяких слипов. И я-бы не назвал это «гонкой», просто интерфейсы определяются одновременно, и ядро даёт им имена от балды. А удав их переименовывает как надо. Мне кажется, что это не в слаке фича, а в вашей генте баг.

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

а зачем, если УМВР?

В связи с настройкой нового сервера
arch

ССЗБ

в persistent-names.rules что-то принципиально отличное от:

нет, оно и есть. Только две строки - eth0 и eth1. Они сами на установке появились, их утилита netconfig вписала, если я не ошибаюсь. И эта утилита входит в стандартный setup из Slackware Linux. Я, во всяком случае, ничего туда не вписывал.

УМВР без всяких слипов.

слип, это чтобы было не одновременно и чтобы ты смогу увидеть проблему если есть.

Мне кажется, что это не в слаке фича, а в вашей генте баг.

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

И я-бы не назвал это «гонкой», просто интерфейсы определяются одновременно, и ядро даёт им имена от балды.

если бы это гарантировано было так, то проблем бы не было, проблемы появляются тогда, когда устройства появляются не одновременно

еще есть парочка вайфаев и туча впнов

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

чо?

https://wiki.archlinux.org/index.php/Udev#Network_device

When choosing the static names it should be avoided to use names in the format of «ethX» and «wlanX», because this may lead to race conditions between the kernel and udev during boot.

ты сможешь объяснить процесс, который там происходил?

Нет. А вы?

еще есть парочка вайфаев и туча впнов

Это на стандартном десктопе-то? Кстати, а нафига там вообще может понадобиться >1 wi-fi адаптера?

было бы прикольно в интерактивном режиме отлавливать запросы на подключение оборудования и вписывать названия ДО подключения. Чтобы ведро маячило каким-нибудь Кедам, а они выдавали диалоговое окно «Вставлена сетевая карта производства Вротмненоги Inc. Как желаете назвать ее?». И только чтобы после подтверждения она добавлялась.

Это вообще очень бы помогло. Например, админ попивает чай дома, а тут в офисе неустановленный Вася пихает в сервер свою сетевуху (чтобы порево смотреть по выделенному каналу). В таком случае админ мог бы посмотреть на сообщение «вставлено новое оборудование» и просто отклонить его.

С анакондой шото типа такого и есть, если правильно помню. Правда я видел её последний раз в районе RH 7.x :D

Впрочем, неустановленные Васи - совсем другой юзкейс

и просто от фразы «гонку может выиграть ядро» мне захотелось плакать.. выше в треде описано.

на ноутах иногда по 2 вайфая ставят, чтобы можно было пользоваться вайфаем гостиницы или кафе, и одновременно сделать сетку между своими ноутами, телефонами и прочими девайсами (если у тебя их в поездке > 1). Тупо экономит деньги за вайфай (обычно он оплачивается не «на персону», а «на устройство»). Даже на некоторых usb-wifi свистках так делают.

Впны нужны, чтобы играть в варезные игрушки, не покупая лицензий. А еще нужны, если задолбался сидеть в офисе, и поехал работать на пляж - чтобы соединяться с рабочей локалкой (у некоторых их несколько, и несколько vpn-соединений).

слип, это чтобы было не одновременно и чтобы ты смогу увидеть проблему если есть.

пусть будет одновременно, в чём проблемы? А увидеть - не будет сети - увижу.

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

ну слака вообще-то не для серверов нужна, а для десктопов. А на десктопах обычно один интерфейс и такой проблемы нет. Я, кстати, сам на сервера никогда слаку не ставил - я тут про свой локалхост рассказал. Да, не совсем обычный.

если бы это гарантировано было так, то проблем бы не было, проблемы появляются тогда, когда устройства появляются не одновременно

_появляются_ они одновременно, а вот _определяются_ таки нет. По очереди. Причём рандомно. Т.ч. проблема мне вполне знакома. Но меня удивляет, что её решение(udev) опять поломали. Чините…

просто такое правило не решит проблему в общем случае.

это почему?

вот правило с десктопа с одним eth

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

# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:60:6e:d7:5e:45", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

на ноутах иногда по 2 вайфая ставят

Ни разу не видел. Примерчиком не поделитесь?

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

Кто сказал «Bluetooth»?

Впны нужны, чтобы играть в варезные игрушки, не покупая лицензий.

Как в этом помогают VPNы?

А еще нужны, если задолбался сидеть в офисе, и поехал работать на пляж - чтобы соединяться с рабочей локалкой (у некоторых их несколько, и несколько vpn-соединений).

А некоторые с десктопов инет раздают по дому, и у них там по нескольку сетевух. Это и есть тот 0.01%.

А на десктопах обычно один интерфейс

погрепал technocity.ru, на большинстве матерей за > 5 тыс. руб, или 2 GLAN, или GLAN+Wifi+Bluetooth

пусть будет одновременно, в чём проблемы?

когда одновременно - проблемы нет, так что не пусть.

_появляются_ они одновременно, а вот _определяются_ таки нет.

каким чудом это делается?

это почему?

потому, что это правило не использует никакой инфы о переименовании во временное устройство. и обломается в неудачной ситуации.

если задолбался сидеть в офисе, и поехал работать на пляж

Это и есть тот 0.01%.

мракобесие in action. Можно не сидеть в проклятом офисе, но сидят, потому что нет VPNа. Этими ниасиляторами целые города наполнены :(

Кто сказал «Bluetooth»?

зачем нужен bt, если есть нормальный wifi?..

Ни разу не видел. Примерчиком не поделитесь?

не поделюсь, у друзей были. Вайфай-«флешка» с двумя антеннами рядом лежит - Asus N-13. (ахтунг: в режиме станции работает только под вендой!)

Как в этом помогают VPNы?

во многих играх можно свободно играть по локалочке, а по интернету - платно. VPN - это локалочка. Люди не пользуются центральными серверами, а централизованно организуют свои VPNы.

еще касается игрушек со злобной защитой от подмены центрального сервера, где серверу уже написали полноценный эмулятор. То же касается детекторов читерства (нелегальная копия считается читерством) - можно в кряк зашить ланчер-снифер-монитор, которому удобней следить трафик по специально приготовленному впну (в т.ч. с настроенными тулзами от microsoft, позволяющими локально снифать шифрованый трафик), а не по «открытому интернету»

погрепал technocity.ru, на большинстве матерей за > 5 тыс. руб, или 2 GLAN, или GLAN+Wifi+Bluetooth

нафейхуя? У меня один, но есть два PCIE и один PCI, т.ч. ещё 3 могу воткнуть. Смысл? Есть же роутер с четырьмя дырками.

каким чудом это делается?

слушай, я не знаю. В логе так написано. Или у тебя в одной строчке лога два события? У меня вот по одному событию в каждой строке. А кроме лога - яхз.

вангую модули вкомпиленные в ядро и pci сетевухи.

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

потому, что это правило не использует никакой инфы о переименовании во временное устройство. и обломается в неудачной ситуации.

если в правиле написано «eth0», но переименование в eth0 невозможно, т.к. такой интерфейс уже существует, то что делать-то по твоему? По моему(и по мнению моего удава) надо переименовать в eth2, а уже потом в eth0, когда eth0 освободится. Видать в твоём удаве это поломали… Уже говорил - чините.

реквестирую накладываемые в слаквари на удав патчи.

вангую модули вкомпиленные в ядро и pci сетевухи.

ЕМНИП одна карта pci(8139) с модулем вкомпилленым, а вторая attansic встроенная в карту (тоже считается pci), но там модуль невкомпиллен, а так болтается в lsmod (идёт в комплекте с ядром начиная ЕМНИПП с 2.6.15, ваниль)

там вроде как ваниль. Вот кстати ещё successs story: http://lordfu.wordpress.com/2010/10/21/slackware-udev-renamed-eth0-to-eth1/

В связи с настройкой нового сервера я испытал грабли с этими predictable names: до первой загрузки с systemd
сервера
systemd

в то время, как индусы из Редмонда осознали исторический fail и стали старательно косить под unix в новых версиях вантуз-сервера, некоторые красноглазые экспериментаторы тащат на сервера софт, написанный в лучших традициях этого самого фейла