Bug 13353 - не следует добавлять правило для udev, если используется etcnet
Summary: не следует добавлять правило для udev, если используется etcnet
Status: CLOSED NOTABUG
Alias: None
Product: Sisyphus
Classification: Development
Component: ifrename (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-08 09:44 MSK by Sergey Y. Afonin
Modified: 2007-11-08 22:54 MSK (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Y. Afonin 2007-11-08 09:44:50 MSK
Согласно 
http://lists.altlinux.org/pipermail/devel/2007-October/065410.html
не следует допускать самостоятельное использование ifrename, если используется
etcnet. Возможно, это правило (и /etc/iftab) следует оформить отдельным пакетом,
после чего в etcnet указать на него конфликт, а в net-scripts требование.
Comment 1 Alexey Gladkov 2007-11-08 10:11:02 MSK
Я могу отделить утилиту от правила, но никаких конфликтов делать не нужно т.к.
это делает невозможным НЕ использование /etc/net/iftab т.е. связка etcnet +
/etc/iftab будет невозможна, что мне кажется недопустимым.

Вообще, в текущей схеме (ifrename + udev.rule) использовать или нет /etc/iftab
это дело каждого. Мне эта схема кажется более гибкой.
Comment 2 Alexey Rusakov 2007-11-08 10:35:31 MSK
Поддерживаю.
Comment 3 Alexey Rusakov 2007-11-08 10:38:07 MSK
То есть, поддерживаю отделение утилиты от правила :) Насчёт наличия конфликта -
насколько я понял из аргументации Дениса, функциональность переименования
интерфейсов делает /etc/iftab ненужным (за исключением, правда, случая перемены
местами...)
Comment 4 Alexey Gladkov 2007-11-08 10:43:08 MSK
не вижу проблемы в использовании /etc/iftab. Если ты не хочешь им пользоваться,
то просто обнули его.
Опиши проблему ?
Comment 5 Alexey Rusakov 2007-11-08 11:02:26 MSK
Это не то чтобы проблема, просто "не следует творить сущности без
необходимости". Существование /etc/iftab меня в своё время сбило с толку и мне
понадобилось некоторое время для того чтобы понять, каким файлом пользоваться.
Фактически, я только намедни понял, что сделанная как квикфикс ссылка
/etc/net/iftab -> /etc/iftab - это неправильно. В общем, это относится не
столько к функциональности, сколько к юзабилити. Но поблизости лежащие файлы с
одинаковым именем провоцируют на внесение изменений не в тот. Так что лучше
пусть etcnet предоставляет полную функциональность по переименованию, а
/etc/iftab и правило тогда останутся в отдельном пакете, который нужен только
нетскриптсам и мешает etcnet.
Сорри за многословие. Надеюсь, я всё же понятно объяснился.
Comment 6 inger@altlinux.org 2007-11-08 11:51:14 MSK
(In reply to comment #5)
> Это не то чтобы проблема, просто "не следует творить сущности без
> необходимости". 
Не надо было делать комбайн ;)

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


Comment 7 Alexey Gladkov 2007-11-08 11:53:38 MSK
(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.

Comment 8 Sergey Y. Afonin 2007-11-08 12:46:02 MSK
В данном случае это всплыло только из-за того, что Альтератор ошибся с тем, 
какие интерфейсы следует заносить в iftab (#13350). В принципе, если бы он 
занёс только ethN, проблемы бы не возникло.
Comment 9 Alexey Gladkov 2007-11-08 13:01:22 MSK
(In reply to comment #8)
> В данном случае это всплыло только из-за того, что Альтератор ошибся с тем, 
> какие интерфейсы следует заносить в iftab (#13350). В принципе, если бы он 
> занёс только ethN, проблемы бы не возникло.

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

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

Более того, etcnet не использует /etc/iftab (конфигурационный файл для ifrename)
, а вызывает напрямую со своими настройками, следовательно правила udev никак не
могут помешать работе etcnet.
Comment 10 Sergey Y. Afonin 2007-11-08 13:15:58 MSK
> ifrename предназначен для переименовывания интерфейсов. Он это делает будучи
> запущенным вручную (из скрипта или руками) и автоматически (через udev). Кто 
и
> как будет его использовать, его не касается.

Именно так. Однако, имея в своём составе правило для udev, он становится 
единоличным в своём выборе. Предлагаю, всё-таки, правило в отдельный пакет 
убрать.
Comment 11 Alexey Gladkov 2007-11-08 13:22:17 MSK
(In reply to comment #10)
> Именно так. Однако, имея в своём составе правило для udev, он становится 
> единоличным в своём выборе. Предлагаю, всё-таки, правило в отдельный пакет 
> убрать.

Я не понял про "единоличным в своём выборе".
Comment 12 Sergey Y. Afonin 2007-11-08 13:35:34 MSK
В смысле, что наличие этого правила однозначно заставляет его срабатывать, что, 
в общем-то, сразу не очевидно. А /etc/iftab может быть кем-то поправлен, как 
практика показала, и не всегда правильно. Особенный сюрприз получается для тех, 
кто целиком полагается на etcnet и не ждёт подвоха...
Comment 13 Michael Shigorin 2007-11-08 13:58:26 MSK
(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.
Comment 14 Alexey Gladkov 2007-11-08 14:07:30 MSK
(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, ...) интерфейсы
именовались так как во время установке системы.
Comment 15 Sergey Y. Afonin 2007-11-08 16:45:23 MSK
(In reply to comment #14)

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

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

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

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

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

У меня - с точностью до наоборот. Мне не очень интересно, что там захочет 
делать udev.
Comment 16 Alexey Gladkov 2007-11-08 16:59:10 MSK
(In reply to comment #15)
> В общем, если ifrename не используется, а в options стоит привязка к драйверу,
> то название остаётся постоянным.

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

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

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

К сожалению, его нужно учитывать в работе. Потом, даже если отказаться от udev
описанный выше рэйс останется. Проблема не в том, кто загрузил модуль, а втом,
что инициализируется более чем один интерфейс.
Comment 17 Sergey Y. Afonin 2007-11-08 17:30:31 MSK
(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 и более сетевых карт десятка два.

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

Ни разу не было.
Comment 18 Alexey Gladkov 2007-11-08 17:45:38 MSK
Я видел эту багу на 4 машинах вовремя разработки Server.

Вы в этом случае используете /etc/net/iftab ?
businfo хорошее решение, но что будет с pcmcia или usb карточками ?
Comment 19 Alexey Gladkov 2007-11-08 17:48:08 MSK
У нас воспросизводилось 100% . Гипотиза которую могу выдвинуть, что эта бага
зависит от модуля.
Comment 20 Sergey Y. Afonin 2007-11-08 20:17:54 MSK
> Вы в этом случае используете /etc/net/iftab ?

Нет, только

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

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

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

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

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

Это может быть. 2 4-х портовых D-Link (sundance) - это у нас, практически,
случайность. Всё остальное - Intel всяких разновидностей, соответственно e100 и
e1000. Одиночные Marvell (кстати странно, зачем Intel на серверные материнки их
ставил), соответственно, не в счёт - там выбора у драйвера нет.
Comment 21 Denis Ovsienko 2007-11-08 22:54:15 MSK
> Почему смущает наличие дубликатов /etc/iftab, но не смущает наличие дубликатов
> resolv.conf и почему resolv.conf используется в системе профилей, а
> /etc/sysconfig/network нет ?

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