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

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

Оно нацелено на десктоп.

На 99.99% десктопов один ethernet-интерфейс. И теперь юзер должен гадать как же он называется, и менять все конфиги при смене сетевухи.

Сервер на арче?

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

Будь это файлы, все решалось бы элементарно, как в случае с /dev/disk/

Будь это файлы, все решалось бы элементарно, как в случае с /dev/disk/

Эммм... Я с утра в танке. Что бы это поменяло? Дало возможность понаставить симлинков?

Дало возможность понаставить симлинков?

This.

А ваще, будь поцтеринг вменяемее, он бы решил проблему нормальным способом:

Взял бы свои predictable interface names, отсортировал по алфавиту, и в соответствии с получившимся порядком назначил бы обычные имена eth0, eth1...

А ваще, будь поцтеринг вменяемее, он бы решил проблему нормальным способом:

Взял бы свои predictable interface names, отсортировал по алфавиту, и в соответствии с получившимся порядком назначил бы обычные имена eth0, eth1...

А потом появляется новый вендор сетевого оборудования, и мы имеем всякие eth9+3/4...

это решение переусложнённое и не решает задачи при изменении кол-ва сетевух, т.е. решение практически настолько же unpredictable как и сейчас.

А при чем тут systemd? это чисто udev фича.

А persistent names в udev уже давно реализованы.

«names» ненужны. Нужны алиасы и HW-dependent identifiers, типа net0018718026df.

т.е. решение практически настолько же unpredictable как и сейчас.

Не совсем. Как было с udev persistent names?

Вставили адаптер -> он стал eth0. Вытащили его, вставили другой в тот же слот - он тал уже eth1.

Теперь

Вставили адаптер -> он стал p3p1. Вытащили его, вставили другой - он остался p3p1. Имена как раз предсказуемые, вот только... Дурацкие.

unpredictable как и сейчас.

А разве сейчас не persistent naming rules? Т.е. привязка названия к MAC. Это во многих дистрах так.

А при чем тут systemd? это чисто udev фича.

udev часть systemd и заведует им тот же товарищ, не?

Достаточно просто удалить/закомментировать /usr/lib/udev/rules.d/80-net-name-slot.rules.

<самопиар>
Кстати, в моём eudev-git так и сделано. Если вам всё же понадобиться включить сабжевую фичу, просто откройте /etc/udev/rules.d/80-net-name-slot.rules и раскомментируйте нужные строки.
</самопиар>

Сервер на арче?

Мастер-машина и бэкапные виртуалки на арче. В «боевых» виртуалках ubuntu lts чтобы меньше возни было.

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

Для udev раньше было решение с persistent names, которое работало не всегда, т.е. там присутствуют race conditions (решается или использованием другого пространства имен, или в случае фейла переименования попытаться переименовать ещё раз через небольшой таймаут). Насчет сейчас тоже как-то неясно, они предсказуемые после 1 запуска, если мы втыкаем сетевуху в голый комп - мы понятия не имеем, какое у неё будет имя, хотя у меня нету опыта работы с серверами, чтобы судить насколько это там важно.

А разве сейчас не persistent naming rules? Т.е. привязка названия к MAC. Это во многих дистрах так

да, только с гонками.

udev часть systemd и заведует им тот же товарищ, не?

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

systemd на десктоп? Сам поцеринг говорил, что оно и для серверов делается.

Нужны алиасы и HW-dependent identifiers, типа net0018718026df.

А что делать в случае с Link Aggregation?

На сервере с несколькими сетевухами мне не нужны ни eth0, eth1, ни enp0s3, enp0s4 итп. Мне нужны int, ext, dmz итп. Т.е. осмысленные имена.

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

А persistent names в udev уже давно реализованы.

давно выпилены, если про net

В общем, я считаю что Поттеринг зря потратил на эту фичу время.

Это все проделки Кая )

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

По поводу билда у Кая очень сильный бугурт при этих вопросах, так что раньше чем его собьет камаз, ситуация не изменится. Впрочем, как раз отдельная сборка udev не вызывает особых проблем, чего не скажешь про systemd.

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

Это совершенно не нужно.

grep ^1 /sys/class/net/*/type -l | cut -f 5 -d /

На 99.99% десктопов с линаксом стоит NM, которому глубоко покуй, какие там имена сетевух

Взял бы свои predictable interface names, отсортировал по алфавиту, и в соответствии с получившимся порядком назначил бы обычные имена eth0, eth1...

што

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

Если ты пишешь конфиги до того как знаешь название своей сетевухи (даже без udev), ты, вероятно, пишешь в общем случае. В таком случае тебе логичнее было бы полагаться на интроспекцию ОС. Если ты пишешь конфиги после того как знаешь название своей сетевухи, то.. то проблемы нет. Если ты пишешь конфиги для конкретной тачки и ситуации, но не знаешь название сетевухи, то не понятно что тебе мешает запустить ip и его узнать.

А при чем тут systemd? это чисто udev фича.

в слаке есть удав и есть eth0, eth1 и т.д.

А разве сейчас не persistent naming rules? Т.е. привязка названия к MAC. Это во многих дистрах так

да, только с гонками.

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

На 99.99% десктопов с линаксом стоит NM, которому глубоко покуй, какие там имена сетевух

ну стоять-то оно стоит, только далеко не все его юзают (сужу как всегда и по себе).

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

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

Как мне интроспекция поможет узнать имя которое назначит udev?

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

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id...

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

Ну здрасте. Создание правил для переименования сетевых интерфейсов в ethX строго не рекомендуется, так как именно это и вызывает race condition. RTFM.

Ну здрасте. Создание правил для переименования сетевых интерфейсов в ethX строго не рекомендуется, так как именно это и вызывает race condition. RTFM.

до свидания. Я с Патрегом создаю, УМВР, ЧЯДНТ?

Потому что узнать имя которое назначит удев очень просто, собственно:

я это видел, это не сработало в моём случае, см. predictable interface names: узнать имя заранее

может я просто не юзаю systemd?

сказать то что хотел?

в генте тоже есть удав, при этом можно поставить как 171 (как в слаке, если не ошибаюсь), так 197 или live версию, и там есть eth0, eth1 и т.д.

сказать то что хотел?

вопрос был:

А при чем тут systemd?

УМВР, ЧЯДНТ?

Рассчитываете на это. Когда сломается, вспомните, что я предупреждал.

тебе уже сказали, что systemd отношения к этому не имеет. Race же есть, но далеко не всегда, хочешь посмотреть на race - поменяй маки eth0 и eth1 в persistent конфиге местами.

может я просто не юзаю systemd?

Это не имеет никакого значения.

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

ну я тебе показал, что ты не прав.

Дополню, в генте можно иметь udev-197 и там будет predictable имена, если захочешь (установишь use-flag или руками добавишь файл).

Оно нацелено на десктоп.

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

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

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

Просто гонку по какой-нибудь причине выиграет ядро, и привет.

чо?

У меня такое было, например.

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

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

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

достаточно маловероятно

Редкое но вполне себе обычное явление.

Рассчитываете на это. Когда сломается, вспомните, что я предупреждал.

и долго мне ждать, пока оно «сломается»? Вангую, что твой systemds в твоём арчике сломается куда как раньше.

тебе уже сказали, что systemd отношения к этому не имеет. Race же есть, но далеко не всегда, хочешь посмотреть на race - поменяй маки eth0 и eth1 в persistent конфиге местами.

менял. И что? Всё равно eth0 остаётся eth0, как его не меняй. В чём проблема-то? Что eth1 опознаётся раньше eth0? Ну дык удав их и переименовывает как надо. Зачем нужны какие-то новые имена?

ну я тебе показал, что ты не прав.

нет. Не показал. Если обозвать eth0 как eth0, то он будет eth0, в чём проблема-то? В наличие второго eth(третьего и т.д)? Ну есть такое, что дальше?

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