13353 2007-11-08 09:44:50 +0300 не следует добавлять правило для udev, если используется etcnet 2007-11-08 22:54:16 +0300 1 1 4 Development Sisyphus ifrename unstable all Linux CLOSED NOTABUG P2 normal --- 1 asy placeholder glebfm ktirf ldv mike pilot placeholder vt qa-sisyphus oldest_to_newest 57605 0 asy 2007-11-08 09:44:50 +0300 Согласно http://lists.altlinux.org/pipermail/devel/2007-October/065410.html не следует допускать самостоятельное использование ifrename, если используется etcnet. Возможно, это правило (и /etc/iftab) следует оформить отдельным пакетом, после чего в etcnet указать на него конфликт, а в net-scripts требование. 57606 1 legion 2007-11-08 10:11:02 +0300 Я могу отделить утилиту от правила, но никаких конфликтов делать не нужно т.к. это делает невозможным НЕ использование /etc/net/iftab т.е. связка etcnet + /etc/iftab будет невозможна, что мне кажется недопустимым. Вообще, в текущей схеме (ifrename + udev.rule) использовать или нет /etc/iftab это дело каждого. Мне эта схема кажется более гибкой. 57608 2 ktirf 2007-11-08 10:35:31 +0300 Поддерживаю. 57610 3 ktirf 2007-11-08 10:38:07 +0300 То есть, поддерживаю отделение утилиты от правила :) Насчёт наличия конфликта - насколько я понял из аргументации Дениса, функциональность переименования интерфейсов делает /etc/iftab ненужным (за исключением, правда, случая перемены местами...) 57612 4 legion 2007-11-08 10:43:08 +0300 не вижу проблемы в использовании /etc/iftab. Если ты не хочешь им пользоваться, то просто обнули его. Опиши проблему ? 57618 5 ktirf 2007-11-08 11:02:26 +0300 Это не то чтобы проблема, просто "не следует творить сущности без необходимости". Существование /etc/iftab меня в своё время сбило с толку и мне понадобилось некоторое время для того чтобы понять, каким файлом пользоваться. Фактически, я только намедни понял, что сделанная как квикфикс ссылка /etc/net/iftab -> /etc/iftab - это неправильно. В общем, это относится не столько к функциональности, сколько к юзабилити. Но поблизости лежащие файлы с одинаковым именем провоцируют на внесение изменений не в тот. Так что лучше пусть etcnet предоставляет полную функциональность по переименованию, а /etc/iftab и правило тогда останутся в отдельном пакете, который нужен только нетскриптсам и мешает etcnet. Сорри за многословие. Надеюсь, я всё же понятно объяснился. 57623 6 inger 2007-11-08 11:51:14 +0300 (In reply to comment #5) > Это не то чтобы проблема, просто "не следует творить сущности без > необходимости". Не надо было делать комбайн ;) Почему смущает наличие дубликатов /etc/iftab, но не смущает наличие дубликатов resolv.conf и почему resolv.conf используется в системе профилей, а /etc/sysconfig/network нет ? 57625 7 legion 2007-11-08 11:53:38 +0300 (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. 57635 8 asy 2007-11-08 12:46:02 +0300 В данном случае это всплыло только из-за того, что Альтератор ошибся с тем, какие интерфейсы следует заносить в iftab (#13350). В принципе, если бы он занёс только ethN, проблемы бы не возникло. 57639 9 legion 2007-11-08 13:01:22 +0300 (In reply to comment #8) > В данном случае это всплыло только из-за того, что Альтератор ошибся с тем, > какие интерфейсы следует заносить в iftab (#13350). В принципе, если бы он > занёс только ethN, проблемы бы не возникло. Не нужно решать одну проблему засчёт уничтожения функционала, лишь косвенно к ней относящегося. ifrename предназначен для переименовывания интерфейсов. Он это делает будучи запущенным вручную (из скрипта или руками) и автоматически (через udev). Кто и как будет его использовать, его не касается. Более того, etcnet не использует /etc/iftab (конфигурационный файл для ifrename) , а вызывает напрямую со своими настройками, следовательно правила udev никак не могут помешать работе etcnet. 57641 10 asy 2007-11-08 13:15:58 +0300 > ifrename предназначен для переименовывания интерфейсов. Он это делает будучи > запущенным вручную (из скрипта или руками) и автоматически (через udev). Кто и > как будет его использовать, его не касается. Именно так. Однако, имея в своём составе правило для udev, он становится единоличным в своём выборе. Предлагаю, всё-таки, правило в отдельный пакет убрать. 57642 11 legion 2007-11-08 13:22:17 +0300 (In reply to comment #10) > Именно так. Однако, имея в своём составе правило для udev, он становится > единоличным в своём выборе. Предлагаю, всё-таки, правило в отдельный пакет > убрать. Я не понял про "единоличным в своём выборе". 57646 12 asy 2007-11-08 13:35:34 +0300 В смысле, что наличие этого правила однозначно заставляет его срабатывать, что, в общем-то, сразу не очевидно. А /etc/iftab может быть кем-то поправлен, как практика показала, и не всегда правильно. Особенный сюрприз получается для тех, кто целиком полагается на etcnet и не ждёт подвоха... 57654 13 mike 2007-11-08 13:58:26 +0300 (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. 57658 14 legion 2007-11-08 14:07:30 +0300 (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, ...) интерфейсы именовались так как во время установке системы. 57689 15 asy 2007-11-08 16:45:23 +0300 (In reply to comment #14) > Разве очевидно, что при загрузке интерфейсы называются именно так как вы > предписали (я правда не пониаю) ? В общем, если ifrename не используется, а в options стоит привязка к драйверу, то название остаётся постоянным. > Если /etc/net/iftab будет неправильно заполнен, будет тоже самое (а равно и > любой другой кнфигурационный файл). Выход тут один заполнять когфиги правильно. Тут, конечно, да. По мне, так лучше бы в iftab-ы ни в какие никто не лазил. :-) Но это, наверное, останется в мечтах. > Загрузка модулей не его дело (уже не его)... это дело udev. У меня - с точностью до наоборот. Мне не очень интересно, что там захочет делать udev. 57694 16 legion 2007-11-08 16:59:10 +0300 (In reply to comment #15) > В общем, если ifrename не используется, а в options стоит привязка к драйверу, > то название остаётся постоянным. Вы рассматриваете простейший вариант. В случае если на машине есть несколько _одинаковых_ сетевых карт, после загрузки модуля возникает рэйс т.к. инициализаруются сразу несколько интерфейсов. > У меня - с точностью до наоборот. Мне не очень интересно, что там захочет > делать udev. К сожалению, его нужно учитывать в работе. Потом, даже если отказаться от udev описанный выше рэйс останется. Проблема не в том, кто загрузил модуль, а втом, что инициализируется более чем один интерфейс. 57700 17 asy 2007-11-08 17:30:31 +0300 (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 и более сетевых карт десятка два. > модуля возникает рэйс т.к. инициализаруются сразу несколько интерфейсов. Ни разу не было. 57703 18 legion 2007-11-08 17:45:38 +0300 Я видел эту багу на 4 машинах вовремя разработки Server. Вы в этом случае используете /etc/net/iftab ? businfo хорошее решение, но что будет с pcmcia или usb карточками ? 57704 19 legion 2007-11-08 17:48:08 +0300 У нас воспросизводилось 100% . Гипотиза которую могу выдвинуть, что эта бага зависит от модуля. 57708 20 asy 2007-11-08 20:17:54 +0300 > Вы в этом случае используете /etc/net/iftab ? Нет, только USE_HOTPLUG=no MODULE=<в зависимости от карточки> И ещё NEVER_RMMOD=yes, но это уже к выгрузке модуля при ifdown относится. > но что будет с pcmcia или usb карточками ? Вот это не знаю. Не проверял. > Гипотиза которую могу выдвинуть, что эта бага зависит от модуля. Это может быть. 2 4-х портовых D-Link (sundance) - это у нас, практически, случайность. Всё остальное - Intel всяких разновидностей, соответственно e100 и e1000. Одиночные Marvell (кстати странно, зачем Intel на серверные материнки их ставил), соответственно, не в счёт - там выбора у драйвера нет. 57711 21 pilot 2007-11-08 22:54:15 +0300 > Почему смущает наличие дубликатов /etc/iftab, но не смущает наличие дубликатов > resolv.conf и почему resolv.conf используется в системе профилей, а > /etc/sysconfig/network нет ? Последний --- один, но большой переключатель.