LINUX.ORG.RU

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

 


1

6

А потом втыкаешь видеокарту и enp1s0 становится enp2s0, и всё равно всё ломается.

Ну и. Ради чего? Всю жизнь жил с net.ifnames=0 в CONFIG_CMDLINE и дальше буду жить.

★★★★★
Ответ на: комментарий от i-rinat

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

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

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

h578b1bde ★☆
()

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

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

anonymous
()
Ответ на: комментарий от AS

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

AS ★★★★★
()
Ответ на: комментарий от AS

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

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

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

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

(src, @mironov_ivan)

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

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от AS

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

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

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

AS ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

AS ★★★★★
()
Ответ на: комментарий от anonymous

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

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

AS ★★★★★
()
Ответ на: комментарий от Quasar

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

Deleted
()
Ответ на: комментарий от Deleted

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

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

ugoday ★★★★★
()

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

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

kawaii_neko ★★★★
()
Ответ на: комментарий от intelfx

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

Нет.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от AS

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

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

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

i-rinat ★★★★★
()

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

Deleted
()

Попробуй eudev.

ass ★★★★
()
Ответ на: комментарий от intelfx

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

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

Нет.

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

anonymous
()
Ответ на: комментарий от i-rinat

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

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

anonymous
()
Ответ на: комментарий от i-rinat

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

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

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

KivApple ★★★★★
()
Ответ на: комментарий от intelfx

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

Нет.

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

AS ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

anonymous
()
Ответ на: комментарий от AS

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

KivApple ★★★★★
()
Ответ на: комментарий от KivApple

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

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

Deleted
()
Ответ на: комментарий от i-rinat

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

Shadow ★★★★★
()

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

targitaj ★★★★★
()
Ответ на: комментарий от ugoday

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

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

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

pkuutn
()
Ответ на: комментарий от Deleted

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

anon8
()
Последнее исправление: anon8 (всего исправлений: 2)

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

Deleted
()
Ответ на: комментарий от Deleted

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

hbars ★★★★★
()
Ответ на: комментарий от aol

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

TeopeTuK ★★★★★
()

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

Ты не знал?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.