Bug 13353

Я могу отделить утилиту от правила, но никаких конфликтов делать не нужно т.к.
это делает невозможным НЕ использование /etc/net/iftab т.е. связка etcnet +
/etc/iftab будет невозможна, что мне кажется недопустимым.

Вообще, в текущей схеме (ifrename + udev.rule) использовать или нет /etc/iftab
это дело каждого. Мне эта схема кажется более гибкой.

Поддерживаю.

То есть, поддерживаю отделение утилиты от правила :) Насчёт наличия конфликта -
насколько я понял из аргументации Дениса, функциональность переименования
интерфейсов делает /etc/iftab ненужным (за исключением, правда, случая перемены
местами...)

не вижу проблемы в использовании /etc/iftab. Если ты не хочешь им пользоваться,
то просто обнули его.
Опиши проблему ?

Это не то чтобы проблема, просто "не следует творить сущности без
необходимости". Существование /etc/iftab меня в своё время сбило с толку и мне
понадобилось некоторое время для того чтобы понять, каким файлом пользоваться.
Фактически, я только намедни понял, что сделанная как квикфикс ссылка
/etc/net/iftab -> /etc/iftab - это неправильно. В общем, это относится не
столько к функциональности, сколько к юзабилити. Но поблизости лежащие файлы с
одинаковым именем провоцируют на внесение изменений не в тот. Так что лучше
пусть etcnet предоставляет полную функциональность по переименованию, а
/etc/iftab и правило тогда останутся в отдельном пакете, который нужен только
нетскриптсам и мешает etcnet.
Сорри за многословие. Надеюсь, я всё же понятно объяснился.

(In reply to comment #5)
> Это не то чтобы проблема, просто "не следует творить сущности без
> необходимости". 
Не надо было делать комбайн ;)

Почему смущает наличие дубликатов /etc/iftab, но не смущает наличие дубликатов
resolv.conf и почему resolv.conf используется в системе профилей, а
/etc/sysconfig/network нет ?

(In reply to comment #5)
> Это не то чтобы проблема, просто "не следует творить сущности без
> необходимости".

Вот эта фраза прежде всего относится к etcnet в данном случае. Прошу поверить
мне на слово, но не я придумал /etc/iftab и существует он давно, как и
/etc/network/interface. Эти конфиги хорошо задокументированы.
Скажите, зачем их дублирует etcnet ?

Следуя вашей логике, нам нужно избавится также избавится от /etc/sysctl.conf,
/etc/sysconfig/iptables  т.к. они (их функционал) дублируется в etcnet.

> Фактически, я только намедни понял, что сделанная как квикфикс ссылка
> /etc/net/iftab -> /etc/iftab - это неправильно. В общем, это относится не
> столько к функциональности, сколько к юзабилити. Но поблизости лежащие файлы с
> одинаковым именем провоцируют на внесение изменений не в тот.

/etc/iftab помечен как ghost и при установке не появляется и не заполняется.
Следовательно, никакие udev привила ничего делать не будут.

> Так что лучше
> пусть etcnet предоставляет полную функциональность по переименованию, а
> /etc/iftab и правило тогда останутся в отдельном пакете, который нужен только
> нетскриптсам и мешает etcnet.

Всё что вы говорите, я готов рассматривать тогда когда etcnet научится
переименовывать один интерфейс в другой (eth0 <=> eth1). В Desktop он этого не
умел и насколько мне известно, не умеет этого сейчас. В ifrename этот функционал
 есть.

Хотя я до сих пор не понимаю чем и кому мешает правила udev в этом пакете. Так
как сама эта утилита его _не_заполняет_. А вот возможность избавиться от рейсов
при загрузке дров может быть просто потеряться. Напомню, что udev стартует много
раньше etcnet.

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

(In reply to comment #8)
> В данном случае это всплыло только из-за того, что Альтератор ошибся с тем, 
> какие интерфейсы следует заносить в iftab (#13350). В принципе, если бы он 
> занёс только ethN, проблемы бы не возникло.

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

ifrename предназначен для переименовывания интерфейсов. Он это делает будучи
запущенным вручную (из скрипта или руками) и автоматически (через udev). Кто и
как будет его использовать, его не касается.

Более того, etcnet не использует /etc/iftab (конфигурационный файл для ifrename)
, а вызывает напрямую со своими настройками, следовательно правила udev никак не
могут помешать работе etcnet.

> ifrename предназначен для переименовывания интерфейсов. Он это делает будучи
> запущенным вручную (из скрипта или руками) и автоматически (через udev). Кто 
и
> как будет его использовать, его не касается.

Именно так. Однако, имея в своём составе правило для udev, он становится 
единоличным в своём выборе. Предлагаю, всё-таки, правило в отдельный пакет 
убрать.

(In reply to comment #10)
> Именно так. Однако, имея в своём составе правило для udev, он становится 
> единоличным в своём выборе. Предлагаю, всё-таки, правило в отдельный пакет 
> убрать.

Я не понял про "единоличным в своём выборе".

В смысле, что наличие этого правила однозначно заставляет его срабатывать, что, 
в общем-то, сразу не очевидно. А /etc/iftab может быть кем-то поправлен, как 
практика показала, и не всегда правильно. Особенный сюрприз получается для тех, 
кто целиком полагается на etcnet и не ждёт подвоха...

(In reply to comment #6)
> Почему смущает наличие дубликатов /etc/iftab, но не смущает наличие дубликатов
> resolv.conf
Это тебя не смущает, всех новичков -- очень здорово выбивает из колеи.  Особенно
потому, что нигде это особо не расписано -- типа, надо знать про update_chrooted.

(In reply to comment #7)
> Скажите, зачем их дублирует etcnet ?
Он расширяет их статическую функциональность профилями.  "Зачем придумали git
branch, если есть каталог проекта?".

> Следуя вашей логике, нам нужно избавится также избавится от /etc/sysctl.conf,
Нет, поскольку частично (префикс net).  Плюс традиция/вариант.  Плюс не мешает.

> /etc/sysconfig/iptables  т.к. они (их функционал) дублируется в etcnet.
Нет, поскольку это традиция/вариант и не мешает.

> Всё что вы говорите, я готов рассматривать тогда когда etcnet научится
> переименовывать один интерфейс в другой (eth0 <=> eth1).
Ну я тоже Дениса попросил по возможности уважить тех, кому дорог именно eth0 ;-)

> А /etc/iftab может быть кем-то поправлен,
> как практика показала, и не всегда правильно.
Ну так это баг этого "кого-то", собсно #13351.

(In reply to comment #12)
> В смысле, что наличие этого правила однозначно заставляет его срабатывать,
> что, в общем-то, сразу не очевидно. 

Да. Заполнение /etc/iftab активирует это правило. Вот сделать нечто для более
тонкого упраления имеет смысл. Например вернуть функционал сервиса и добавить
возможность вообще его выключать.

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

> А /etc/iftab может быть кем-то поправлен, как 
> практика показала, и не всегда правильно. Особенный сюрприз получается для 
> тех, кто целиком полагается на etcnet и не ждёт подвоха...

Если /etc/net/iftab будет неправильно заполнен, будет тоже самое (а равно и
любой другой кнфигурационный файл). Выход тут один заполнять когфиги правильно.

Кроме, того я не вижу противоречий, даже при учёте использования
alterator-net-eth (в случае его правильной работы). etcnet настраивает сетевые
интерфейсы. Загрузка модулей не его дело (уже не его)... это дело udev. Имена им
даёт udev (разумеется ядро, он грузит модули именно он)... Существует проблема с
рейсами при выдачи этих имён (это факт). Правило для udev позводяет на этапе
зарузки модулей зафиксировать эти имена. Фактически исправить ошибку (иногда
фатальную). Далее стартует etcnet, который настраивает эти интерфейсы по своим
правилам и если надо может переименовать их в более благозвучные значения.

Мне кажется что тут всё логично.

Назначение /etc/iftab и этих правил в том, чтобы даже в простейшем случае
настройки сети (не важно через что etcnet, net-scripts, ...) интерфейсы
именовались так как во время установке системы.

(In reply to comment #14)

> Разве очевидно, что при загрузке интерфейсы называются именно так как вы
> предписали (я правда не пониаю) ?

В общем, если ifrename не используется, а в options стоит привязка к драйверу,
то название остаётся постоянным.

> Если /etc/net/iftab будет неправильно заполнен, будет тоже самое (а равно и
> любой другой кнфигурационный файл). Выход тут один заполнять когфиги 
правильно.

Тут, конечно, да. По мне, так лучше бы в iftab-ы ни в какие никто не лазил. :-)
Но это, наверное, останется в мечтах.

> Загрузка модулей не его дело (уже не его)... это дело udev. 

У меня - с точностью до наоборот. Мне не очень интересно, что там захочет 
делать udev.

(In reply to comment #15)
> В общем, если ifrename не используется, а в options стоит привязка к драйверу,
> то название остаётся постоянным.

Вы рассматриваете простейший вариант.

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

> У меня - с точностью до наоборот. Мне не очень интересно, что там захочет 
> делать udev.

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

(In reply to comment #16)

> В случае если на машине есть несколько _одинаковых_ сетевых карт, после 
загрузки

$ lspci|grep Ethernet
04:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] 
(rev 08)
04:08.0 Ethernet controller: Intel Corporation 82801G (ICH7 Family) LAN 
Controller (rev 01)
05:04.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 
14)
05:05.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 
14)
05:06.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 
14)
05:07.0 Ethernet controller: D-Link System Inc DL10050 Sundance Ethernet (rev 
14)


# lspci|grep Ethernet
0000:02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8050 PCI-E 
ASF Gigabit Ethernet Controller (rev 17)
0000:03:03.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet 
Controller (rev 03)
0000:03:03.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet 
Controller (rev 03)
0000:04:03.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet 
Controller (rev 05)


$ lspci|grep Ethernet
0000:04:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 
100] (rev 04)
0000:04:02.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 
100] (rev 08)
0000:04:03.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 
100] (rev 08)
0000:04:08.0 Ethernet controller: Intel Corporation 82801G (ICH7 Family) LAN 
Controller (rev 01)

Ещё вариантов ? По меньшей мере, e100, e1000 и sundance, будучи запущены в 
строгом порядке, хватают "свои" железки в порядке следования bus id. Машинок
с 3 и более сетевых карт десятка два.

> модуля возникает рэйс т.к. инициализаруются сразу несколько интерфейсов.

Ни разу не было.

Я видел эту багу на 4 машинах вовремя разработки Server.

Вы в этом случае используете /etc/net/iftab ?
businfo хорошее решение, но что будет с pcmcia или usb карточками ?

У нас воспросизводилось 100% . Гипотиза которую могу выдвинуть, что эта бага
зависит от модуля.

> Вы в этом случае используете /etc/net/iftab ?

Нет, только

USE_HOTPLUG=no
MODULE=<в зависимости от карточки>

И ещё NEVER_RMMOD=yes, но это уже к выгрузке модуля при ifdown относится.

> но что будет с pcmcia или usb карточками ?

Вот это не знаю. Не проверял.

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

Это может быть. 2 4-х портовых D-Link (sundance) - это у нас, практически,
случайность. Всё остальное - Intel всяких разновидностей, соответственно e100 и
e1000. Одиночные Marvell (кстати странно, зачем Intel на серверные материнки их
ставил), соответственно, не в счёт - там выбора у драйвера нет.

> Почему смущает наличие дубликатов /etc/iftab, но не смущает наличие дубликатов
> resolv.conf и почему resolv.conf используется в системе профилей, а
> /etc/sysconfig/network нет ?

Последний --- один, но большой переключатель.