LINUX.ORG.RU
ФорумTalks

Попрощаемся с eth*

 , ,


1

1

Сегодня обновился udev до версии 200. С этой версии из systemd/udev удалён функционал переименования ядерных интерфейсов eth в eth же. По факту это означает, что привязать сетевухи по макам и оставить их имена eth* более невозможно. Как результат придётся отвыкать от привычных имён.

В качестве причины называется:

«The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same „ethX“ namespace, a race condition with all kinds of weird effects, among them that assignment of names sometimes failed. As a result support for this has been removed from systemd/udev a while back.»

http://wiki.gentoo.org/wiki/Udev/upgrade

За 6 лет достаточно активно использовал переименования интерфейсов, никаких «weird effects» не видел ни разу. И никаких проблем с назначением кастомных имён тоже не было.

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

★★

Ответ на: комментарий от drBatty

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

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

в ведре этого никогда не было - непонятно что чинить.

всё очень даже понятно: ядро СРАЗУ ВСЁ инициализирует, и нумерует интерфейсы так, как они инициализируются. Очевидно, номер зависит от случайных причин (вплоть до степени окисления контактов на RJ45), причём это не исключение, а правило - сетевые карты обычно одинаковые, даже из одной партии. Зачем разные ставить?

Есть только два решения:

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

Выбрали второй путь, и он отлично работал. У кого не работал, мог подправить что-нить, не показатель. Багрепортов я так и не увидел.

Пришёл Леннарт, впилил новый инит, и ВНЕЗАПНО начались гонки. А что было в предыдущие 5..7 лет???

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

несмотря на то, что я очень не люблю творчество поттеринга

при чём тут «любовь»? Давай конкретные аргументы, а любовь для женщин оставим. Их-то я как раз и не вижу.

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

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

5 лет в продакшене работал алгоритм который не работал? Ты вообще сам понимаешь, что ты пишешь? И да, все молчали, и стали плакать почему-то только ПОСЛЕ появления поттеринговой поделки?

ЗЫЖ я ничего против Леннарта не имею, я просто считаю, что скорость загрузки для серверов в продакшене малозначительна. Также, как и для десктопов (которые можно не выключать), также как и для ноутов (которые умеют засыпать). А ещё, я никаких плюсов, кроме скорости ребута, в systemd не наблюдаю. За то наблюдаю _реальные_ проблемы. Такие как поломанный /usr, который Леннарт чинить отказался, и поломанный механизм переименования eth, который никто тоже чинить не желает. Это уродство, однозначно. Как в MS-Win, где всем насрать на пользователей/админов.

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

Багрепортов я так и не увидел.

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

Пришёл Леннарт, впилил новый инит, и ВНЕЗАПНО начались гонки. А что было в предыдущие 5..7 лет???

Масаракш... были они были гонки и 5 и 7 лет назад.

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

5 лет в продакшене работал алгоритм который не работал?

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

Слушай у тебя какие-то проблемы со скоростью и Леннартом.. я даже не знаю, что и сказать..

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

в ведре этого никогда не было - непонятно что чинить.
В юзерспейсе - полноценного решения тоже никогда не было - непонятно что ломать.

Чинить? Вы пишите эпический бред. Стена --> там.

Было решение в ядре+ юзерспейс+ скрипты_загрузки+ api_для_демонов которое работало. У него было ОТСУТСТВИЕ ФУНКЦИОНАЛА (Так как да, это xxxxx вместо осознания проблемы в комплексе начинают гадить в компонентах системы занимаясь безмозглым кодеписательством. Нормальные инженеры пляшут от задачи). Решение было вынуждено запускать демоны после загрузки сетевых интерфейсов, что приводило к длительному времени загрузки. Это не баг. Это отсутствие фичи. Такой фичи никто не ставил в тз когда создавали архитектуру всегоэтого.

Теперь у нас появилась ДОПОЛНИТЕЛЬНАЯ НОВАЯ ЗАДАЧА В ТЗ - параллелная загрузка по зависимостям, включая зависимости от хардвара (плюс еще всякие штуки, не буду перечислять потому что всего не упомню). В которой мы должны сохранить старый функционал и добавить новый. И вот процессы добавления этого нового функционала и колбасят всю эту связку ядро+ юзерспейс+ скрипты_загрузки+ api_для_демонов .

Отсюда вообще говоря ОЧЕВИДНО что «не менять функционал ядра» в общем случае банально НЕВОЗМОЖНО. И не ЧИНИТЬ его. Оно даже не сломано - оно в стадии прототипа где везде все сломано по дефолту.

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

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

То есть да, демоны которые ловят каждое устройство при включении очевидно должны висеть в ядерном пространстве имен интерфейсов. Которое должно быть вроде eth-kernel-XXX . И не переименовываться вообще, а так и оставаться.

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

Стена--> там. Порушилась удобнейшая схема именования устройств которым пользовалось очень много народу. В угоду редхатоэнтерпрайз баблопроблем. Никто не говорит что эти проблеемы редхата не надо решать - надо. Но надо их решать не портя жизнь нередхатам.

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

Это у вас от того что вы в голову только кашу едите.

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

были они были гонки и 5 и 7 лет назад.

были. И отлично фиксились удавом. У меня. А сейчас почему-то перестали, причём по странному совпадению, перестали у тех, кому вклячили systemd. А может это не совпадение? Может это вполне логичное следствие загрузки за 910мс, когда ты запускаешь ВСЕ демоны и поднимаешь СРАЗУ ВСЕ интерфейсы, и при этом их ещё и пытаешься переименовывать? Ессно, за 910мс всё это корректно поднять тупо невозможно, разве что накостылять схему на злобу дня, привязав сетевые к каким-то «слотам» каких-то PCI (очень интересный ход, учитывая, что на большинстве десктопных материнок этого PCI тупо уже нет. На серверных ещё есть?)

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

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

у меня udev-200 и eth0/wlan0, дальше что?

ммм.. я подозреваю, что каша в голове не у меня.

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

были. И отлично фиксились удавом. У меня.

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

А сейчас почему-то перестали, причём по странному совпадению, перестали у тех, кому вклячили systemd.

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

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

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

любая автоматика может не сработать. Очевидно же! Ну дык пусть и дальше-бы так было, чем плохо-то? Это для меня было вполне годное решение, которое отлично работало, и не давало никаких сбоев. У кого не работало - мог делать иначе, я не против.

Слушай у тебя какие-то проблемы со скоростью и Леннартом..

пока в слаке нет systemd, у меня нет и проблем. В частности с eth. Совпадение?

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

весь линукс just for fun
у меня никаких проблем не вызывает
а ты как хочешь

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

а вот ещё раньше никаких sda не было. Были hda.

Не надо вот этого - sda были почти всегда... вместе с hda :D

Потом их заменили на sda, ВНЕЗАПНО всё обморозилось, что теперь известно, как «12309». Совпадение конечно…

Ну может и нет - все таки драйвер целиком заменили.

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

Ну да, я какбэ в курсе. Опять же - способ привязки к линку могут и придумать в конце концов. Учитывая что линк сейчас в почти любом случае втыкается в умный свитч, при чем VLAN-capable. Придумать как сделать так что бы свитч отдавал на запрос имя канала тащемта технически несложно.

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

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

у меня udev-200 и eth0/wlan0, дальше что?

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

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

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

а у меня всё поломалось (поломается), ибо все интерфейсы переименуются. Я когда писал конфиги, про это не знал. Думал, что eth0 всегда будет eth0. Вот такой я глупый, и вообще не Ванга. А ты сволочь, ибо знал, предвидел, и не рассказал.

А сейчас почему-то перестали, причём по странному совпадению, перестали у тех, кому вклячили systemd.

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

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

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

я доказываю, что:

1). проблема была независимо от systemd давно, т.е. что «у меня в слаке работало это не аргумент».

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

3). ethX можно продолжать использовать, но теперь udev не врет о том, что дает гарантии работы, кто хочет может продолжать использовать.

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

как обычно - кому тебе удобнее.

Верить кому удобнее это признак того что кашу не только в голову пихаете, но часто не попадаете. И по физиономии размазываете.

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

Не надо вот этого - sda были почти всегда... вместе с hda

sda были, но не IDE. А вот IDE были hda…

Ну может и нет - все таки драйвер целиком заменили.

вот именно. Ладно, в том случае это НУЖНО было, а сейчас? В чём профит-то? Профита нет, а вот куча проблем, как 12309 (это не один баг, а Over9000 нестыковок), будет.

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

с этим согласен.

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

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

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

проблема была независимо от systemd давно

пруфов я так и не увидел. И сам не нашёл, и ты не помог. Может их не существует?

т.е. что «у меня в слаке работало это не аргумент».

это 100% аргумент того, что схема РАБОТАЛА. Да, может не у всех, ну и что? У меня вот федора вообще зависла намертво на этапе установки, что это доказывает?

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

но у меня-то этот алгоритм работал? Причём без сбоев. Значит сам по себе алгоритм годный, и только в некоторых ситуациях он не срабатывает? Давайте выясним - в каких не работает, и почему, и исправим? Ну или напишем в мануале, что вот в таких случаях наш алгоритм не работает.

ethX можно продолжать использовать, но теперь udev не врет о том, что дает гарантии работы, кто хочет может продолжать использовать.

ты так и не рассказал, в каких случаях udev «врёт»? Я пока вижу один случай, когда в федоре17 всё работало, а в 18 поломалось. А гуру говорят, что «всё нормально, мы давно хотели сломать, и сломали, просто переделайте все конфиги, где есть eth».

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

sda были, но не IDE. А вот IDE были hda…

угу, я про это.

вот именно. Ладно, в том случае это НУЖНО было, а сейчас? В чём профит-то? Профита нет, а вот куча проблем, как 12309 (это не один баг, а Over9000 нестыковок), будет.

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

Вот и не видит проблемы, а видит «аргументы» которые воспринимает неадекватно.

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

с этим согласен.

У меня пока вся надежда на Линуса и адекватных кастомеров редхата. Линус знатный тролль - в прошлый раз когда devfs-сники разбушевались, выпилили udev и порешали проблемы. А адекватные кастомеры постепенно разберутся что им грозит - начнут пиннать редхат.

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

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

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

Не надо вот юлить, вы прямо и кратко ответьте. Почему у них p0xx а у вас ethX.

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

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

это да. ИМХО до RHEL эти поделки ещё не скоро дойдут… Если дойдут.

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

потому, что я разобрался в ситуации и отключил predictable-names, которые стоят по умолчанию.

Угу. А надо наоборот - так как те у кого ЕСТЬ уже эти баги, они и включат predictable-names что бы решить свои проблемы. Это решит проблему и не приведет к тому что оно все внезапно поломается.

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

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

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

вот конкретная эта поделка (predictalbe-names) взята из RHEL.

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

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

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

ты когда сервер разворачиваешь, все конфиги к нему с нуля пишешь? Или используешь дефолт везде? А я вот старые и проверенные юзаю, и меняю там только то, что изменилось в железе/назначении. А что изменилось в eth такого, что они ВНЕЗАПНО стали p0x8, или как их там теперь?

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

пожелаю тебе настоящих друзей и мудрости.

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

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

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

в этом посте недостаточно ненависти, я ненасытился (

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

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

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

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

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

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

дай прфлинк, где я «заведомо отказался».

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

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

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

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

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

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

и да описанный тобой второй путь сейчас какраз и используется. но ты и не смотрел СПВ.

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

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

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

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

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

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

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

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

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

ЕМНИП hda было для идешных винтов а sda для Sata(возможно и для sas) но потом ата и сата стали жить в одном драйвере и с тех пор они все sda, не?

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

ты сейчас так в капитана сыграл? что сказать то хотел? впрочем я давно подозревал что разговор ведётся на разных уровнях у вас.

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

ты исходишь из неверного переведённого топикстартером утверждения, что удев 200 запрещает называть интерфесы eth* , что как мы уже несколько раз выяснили неверно и очевидно всякому кто натравил гуглотранслейт на http://wiki.gentoo.org/wiki/Udev/upgrade

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