Мы дадим вам enp1s0, говорили они, имена интерфейсов зафиксируются, говорили они

Мы дадим вам enp1s0, говорили они, имена интерфейсов зафиксируются, говорили они (комментарий)

Например, как «один раз не накатить себе этот ваш» поможет «автоматически разворачивать одинаковые сервера».

1. Накатываем ОС и системдэ на один из серверов.
2. Снимаем образ и раскатываем на остальные
3. Системдэ не работает.
4. Фейл.

Таким образом, любители системдэ сношаются со своей поделкой, а у нормальных людей по-прежнему всё работает. Все довольны (на самом деле нет).

"- Малыш, ну что ты шумишь?"(ц)

не мешай людЯм пилить очередной svchost.exe

Я тебе ещё раз повторяю,

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

Нехрен было выкидывать код, умеющий переименовать интерфейсы.

Всё всем понятно. Только ты вот в этот момент зачем-то начал говорить про проблему переименования из ethN в ethM, хотя исходно говорили вообще о другом.

Врали они.

Только ты вот в этот момент зачем-то начал говорить про проблему переименования из ethN в ethM

Это именно она. Читай внимательно. Речь про _несколько_ eth, когда у тебя, в момент переименования, ethM уже тоже есть изначально.

То есть, с приходом systemd начался адовый трешак, и systemd тут совсем ни при чём?

Не учи меня читать. Речь исходно шла про проблему недетерминистичной нумерации сетевых интерфейсов, без каких-либо уточнений:

Я разворачиваю сервера, бывает, с десятком физических интерфейсов.

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

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

(src, mironov_ivan)

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

Первый — переименовывать из ethN в ethM, запоминая порядок обнаружения «как в первый раз». В этом случае приходится решать вторичную проблему, которая возникает, когда целевое имя уже существует (это то, о чём ты говоришь). А ещё важно отметить, что недетерминистичность в этом случае никуда не исчезает, т. к. запоминается порядок, случайным образом полученный при первой загрузке.

Второй — это переименовывать детерминистично с самого начала, пользуясь при этом другой схемой именования (enX).

В этом треде обсуждается именно второе. Твоя реплика выглядит так: «нехрен было выкидывать первое, тогда и второе не было бы нужно» (src). На что я тебе ответил сравнением первого и второго (src).

Так что пойди и сам перечитай весь тред ещё раз.

что на? как это говно вообще в основную ветку попало? короче, ты опять выставил себя ну очень «крутым» и бывалым» обмином, но «немного» неполучилось, ну как обычно, ничего не меняется.

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

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

Твоя реплика выглядит так: «нехрен было выкидывать первое, тогда и второе не было бы нужно»

Да. Потому как второе всё равно можно решить ручной заготовкой под конкретное железо, а реально оно не работает: смотри первое сообщение.

Ты можешь доказать, что он гарантирует работу в любой ситуации? Есть ли гарантии, что там не случится live-lock?

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

что на? как это говно вообще в основную ветку попало?

Иди вздёрни на своего кумира и Ко.

т.е. это udev, в данном случае, eudev.

Дано: сервер заранее известной модели. Одна штука. Его конфигурация заранее известна с точностью до всех установленных устройств и версий их прошивок. На сервере две сетевые карты. Они всегда подключены в разные сети, требующие разных настроек. Мы всегда знаем, что левая eth-дырка на корпусе сервера всегда подключена в сеть A, а правая - в сеть B.

Вы всё говорите правильно, но есть один ньюанс. Делать изменения, которые негативно затрагивают огромное множество людей, ради положительных эффектов, интересных лютому меньшинству глупо. Это всё равно, что заставлять всех ходить в скафандрах, потому что космонавтам без них бывает неуютно. Правильный подход: у всех нормальные интерфейсы ethN, у некоторых, кому это действительно нужно — enp23asdf8sfadsf8 или что они там хотят.

Ну немного напрячься все же придется, зато потом

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
wan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Первый способ был недетерминирован и у админов вц были проблемы. Ввели второй способ, сломав соглашение о наименовании для всех. Второй способ внезапно тоже оказался недетерменирован. Так?

Ввели второй способ, сломав соглашение о наименовании для всех

Какое соглашение о наименовании?

Второй способ внезапно тоже оказался недетерменирован.

Нет.

Какое соглашение о наименовании?

Вот, кстати, да. После Linux ставишь FreeBSD, и внезапно обнаруживаешь, что сетевые интерфейсы — не eth0, а, скажем, em0 или dc0. Приходит осознание, что ethX не является стандартом. Просто так сложилось.

А в багтрекере что-то есть про то, что это работает плохо?

Я смотрел в код. И по коду не понятно, является ли поведение костыля корректным. «Раньше же работало» — не аргумент. Там реально костыль для переименования был, и если появилась возможность его выбросить, лучше выбросить.

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

Ахаха, только сегодня после ребута прокса словил отвал сети.
После каких-то обновок enp1s0 переименовался в eno0. Хорошо хоть сервак в шаговой доступности.

Попробуй eudev.

Какое соглашение о наименовании?

То, за которое вас который раз критикуют. Ты опять дартаньяна в пальте из себя корчишь?

Нет.

Первое сообщение в треде.

не является стандартом. Просто так сложилось.

Стандарт — это текст, который описывает как сложилось.

К счастью, udev поставляется в виде исходных кодов

К счастью есть вменяемые мантейнеры даже у systemd, и баги воспринимают, как баги. в ALT это было практически сразу пофикшено даже без меня. ;-) Просто угораздило в короткий промежуток времени наличия беды наступить на это.

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

https://xkcd.com/1172/

Стандарт — это текст, который описывает как сложилось.

Нету текста. Нет.

Второй способ внезапно тоже оказался недетерменирован.

Нет.

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

https://xkcd.com/1172/

А какой там полный ченджлог у этого комбайна (привет, intelfx)?

Нету текста. Нет.

Так никто другого не говорил. Есть соглашение в линухах — ethX. Вся буза от того, что его сломали. Погромируют под линух, на бсд кладут.

Уже не в первый раз вижу «это некрасивое решение, поэтому мы его удалим/не будем принимать патч, красивых и при этом реализуемых альтернатив не предложим, идите нафиг». Слишком много перфекционистов развелось в OpenSource...

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

Это никогда и никто не гарантировал. А в случае, если в системе стоят разные сетёвки с разными драйверами, то разная нумерация на одинаковых системах встречается IRL.

Кстати, в юзкейсе автора с FreeBSD именами было бы проще

Мне надавно ребята из severs.com кинули инфу как они сеть готовят. Они тупо переименовывают интерфейсы согласно МАК-адресу. Надо?

Вот поддерживаю просто люто-бешено.

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

Может, пусть проблему решает тот, у кого она есть?

Да ничего. Чтобы задать точное соответствие физического порта программному интерфейсу нужен какой-то идентификатор. Всегда это был MAC-адрес. Вдруг вылезает Лёня и внезапно решает, что теперь интерфейсы мы будем привязывать к нумерации pci-устройств, мотивируя это тем, что вот я поменял сетевуху, MAC стал другим и всё поехало, нужно топать ногами к серверу (а сетевуха через libastral меняется, как же). Он же хочет счастья для всех, но своими четырмя глазами не видит ничего. Оказывается, что нумерация устройств вполне себе съезжает от всяческих телодвижений. И если раньше это была смена MAC-адреса сетевухи (неважно по какой причине), то теперь втыкание новой платы в систему и даже обновления ядра иногда ломают нам наименование сетей. Отдельный привет пользующимся USB-сетевухами.
Офигеть как все теперь счастливы.
И чтобы такого не случалось, что приходится делать? Правильно, привязывать имя сетевого интерфейса к MAC. Что работало и без Лёниных поделий.

В твою видюху сетевуха встроена? Как такое может быть?

А я забил и привязываю к mac через udev. С wlan помогает стабильно вместо всяких wlxgjvmbmvcnb.

Всё чудесатее и чудесатее: http://www.opennet.ru/openforum/vsluhforumID3/116323.html

«после перехода на udev из состава systemd 240 сетевые интерфейсы адаптеров Ethernet поменяли свои имена с фиксированных на автоматически сгенерированные»

Откатили это изменение уже: https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3...

Откатили

у них был выбор после такого shitstorm-а? :)

Выбор есть всегда, как мне представляется.

systemd для чертей — от чертей, из нашего ада — в ваш.

Ты не знал?

Привет,браток :)