Bug 14872 - please do by-mac hw binding by default
: please do by-mac hw binding by default
Status: CLOSED WONTFIX
: Sisyphus
(All bugs in Sisyphus/alterator-net-eth)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
: 12100
  Show dependency tree
 
Reported: 2008-03-12 15:05 by
Modified: 2008-05-08 15:59 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-03-12 15:05:33
Просьба по умолчанию ставить Hardware binding в "by MAC address" -- сейчас
получается регресс относительно того, когда этого переключателя не было (после
установки интерфейсы могут прыгать).
------- Comment #1 From 2008-03-17 23:13:03 -------
Хорошо бы до выпуска очередного дистрибутива на 4.0/branch.
NMU делать?
------- Comment #2 From 2008-03-18 09:13:19 -------
Кстати, вопрос ещё, лучше by MAC или by bus id... Мне кажется, что смерть 
сетевой карты более вероятна, чем смерть материнки...
------- Comment #3 From 2008-03-18 16:49:55 -------
Поскольку было by mac и никто не жаловался, предлагаю выбрать его :)
(есть и другие соображения, но вида "шило на мыло")
------- Comment #4 From 2008-04-03 16:39:26 -------
ping

(это бы надо в 4.1)
------- Comment #5 From 2008-04-03 16:56:33 -------
уже записал в TODO
------- Comment #6 From 2008-04-08 15:26:11 -------
<gvy> я тут попытался слазить в net-eth насчёт
https://bugzilla.altlinux.org/show_bug.cgi?id=14872 -- пока застрял на том, как
бы различить "hw binding просто не было" и "сознательно не было"
<gvy> пока думаю, что должно бы быть достаточно в режиме инсталера по умолчанию
подсовывать нужный индекс (ну или там 0, поставив mac первым)
<gvy> вот только как бы это сделать опять же так, чтоб снять-то можно было...
------- Comment #7 From 2008-04-10 13:56:43 -------
TWIMC: в installer-ltsp-school пока делаю так для обеспечения стабильного
порядка следования и именования интерфейсов:

bind_by_mac()
{
        MAC="`ip li sh dev $1 | fgrep 'link/ether' | sed 's#^ *link/ether ##' |
cut -d' ' -f1`"
        [ -z "$MAC" ] || echo "$1       mac $MAC" >> "$destdir/etc/iftab"
}

IFS=': '
ip li | fgrep -B1 link/ether \
while read num iface junk; do
        bind_by_mac "$iface"
        read nextline
done
------- Comment #8 From 2008-04-13 21:48:08 -------
И, кстати, hal в Server тащить действительно вовсе незачем, а при текущей
реализации в следующую сборку он вынужденно попадает.  Костик вот уже
возмущается.
------- Comment #9 From 2008-04-14 11:41:32 -------
(In reply to comment #8)
> И, кстати, hal в Server тащить действительно вовсе незачем, а при текущей
> реализации в следующую сборку он вынужденно попадает.  Костик вот уже возмущается.

А я бы так не переживал насчёт hal ;)
------- Comment #10 From 2008-04-14 18:27:47 -------
(In reply to comment #9)
> А я бы так не переживал насчёт hal ;)
Ну не знаю.  Мне этот ^&^&*^ блоат ни разу не симпатичен.  Можно, конечно,
сносить вместе с альтератором, но хотелось бы не делать излишних движений.

Тем более как по-человечески это делается -- чуть выше пример.  Сдаётся, ещё и
быстрей выходит (переделывать одним форком на awk было уже лень :).
------- Comment #11 From 2008-04-15 11:27:29 -------
(In reply to comment #10)
> (In reply to comment #9)
> > А я бы так не переживал насчёт hal ;)
> Тем более как по-человечески это делается -- чуть выше пример.  Сдаётся, ещё и
> быстрей выходит (переделывать одним форком на awk было уже лень :).
А вот и нет.

Без hal ты замучаешься корректно выяснять такие вещи как: выяснение имени
устройства соотвествующего интерфейсу, выяснение типа интерфейса ( я знаю про
всякие каталоги в /proc, но отчего-то они не на всех карточках работают). 

Поверь, я не просто так hal стал использовать. Может быть он и вызывает
религиозное недовольство (как у некоторых evms или UTF-8 по-умолчанию), но это
"подушка", в которой засунуто немало обходных манёвров вокруг ядра и его
странных подходов к жизни.

В будущем завязок на hal будет всё больше и больше ибо народ замучался уже
разбираться с постоянным творчеством в ядре ... поэтому не стоит всё так
драматизировать. Или hal или пляски с libsysfs и ручным парсингом proc.

hal - это база данных, не больше не меньше. Отказ от использования него -
экономия на спичках.
------- Comment #12 From 2008-04-15 15:21:07 -------
(In reply to comment #11)
> > Тем более как по-человечески это делается -- чуть выше пример.  
> > Сдаётся, ещё и быстрей выходит
> А вот и нет.
Мне померять?  Знаешь, не очень интересно, когда на amd64 при переключении табов
мы тормозим.  Понятно, что service network restart может быть главным
оверкиллом, но костыли лучше не добавлять, а потихоньку заменять ногами.

> Без hal ты замучаешься корректно выяснять такие вещи как: выяснение имени
> устройства соотвествующего интерфейсу, выяснение типа интерфейса ( я знаю про
> всякие каталоги в /proc, но отчего-то они не на всех карточках работают). 
Да ничего я не замучался -- link/ether говорит всё необходимое про
ethernet-интерфейсы, применительно к которым идёт разговор о маках.

> Поверь, я не просто так hal стал использовать.
Боюсь, просто в спешке и по незнанию ip(8).

> hal - это база данных, не больше не меньше. Отказ от использования него -
> экономия на спичках.
Хорошо, я попробую исправить это так, как думаю, и провести тесты.

Собственно оригинальный повод для баги (регресс значения по умолчанию для
прибивалки, когда был сделан регулятор её типа), так понимаю, тоже никого не
интересует.  В Линукс Терминал это объехато хуком около настройки ltsp, тоже
назначаю себе как заинтересованному RM.
------- Comment #13 From 2008-04-15 15:33:29 -------
(In reply to comment #11)
> Поверь, я не просто так hal стал использовать. Может быть он и вызывает
> религиозное недовольство (как у некоторых evms или UTF-8 по-умолчанию)
PS: в EVMS2 хватает своих тараканов, а с недоделанным UTF-8 в coreutils у нас
даже хуже, чем в RH (#10445):

$ locale | grep -v ru_RU.UTF-8
$
$ rpm -qf /usr/bin/tr
coreutils-6.10-alt4
$ echo abcабв | tr [[:lower:]] [[:upper:]]
ABCабв

Хорошо хоть текущий sed уже починили:
$ echo abcабв | sed -e 's/Б/1/i' -e 's/B/2/i'
a2cа1в

Пойми -- не от хорошей жизни народ в религию подаётся.

> но это "подушка", в которой засунуто немало обходных манёвров вокруг ядра и его
> странных подходов к жизни.
У этой подушки настолько невменяемый апстрим, что закладываться на неё я лично
конкретно избегаю.
------- Comment #14 From 2008-04-26 12:28:07 -------
done ... хотя не нравится мне это ... то смущает вас привязка, то подавай по
умолчанию ;)
------- Comment #15 From 2008-05-04 20:56:40 -------
(In reply to comment #14)
> done ... хотя не нравится мне это ... то смущает вас привязка, то подавай по
> умолчанию ;)
Не, меня-то и не смущала :)  Собсно здесь попросил _восстановить_ то поведение
по умолчанию, которое было реализовано чуть раньше возможности выбирать, к чему
именно привязываемся.

Спасибо!
------- Comment #16 From 2008-05-05 11:05:08 -------
хотя нет ... не получается. Если делаю дефолт - ломаю потом конфигуратор. Надо
делать installer-feature.
------- Comment #17 From 2008-05-05 11:05:26 -------
Надо делать installer-feature
------- Comment #18 From 2008-05-06 22:10:56 -------
(In reply to comment #16)
> хотя нет ... не получается. Если делаю дефолт - ломаю потом конфигуратор.
Мгм.  Вот и я в то же упёрся.

> Надо делать installer-feature.
Ты/я?  Выдрать можно отсюда:
http://git.altlinux.org/people/mike/packages/?p=installer-feature-ltsp.git;a=blob;f=installer-feature-ltsp/preinstall.d/98-eth0.sh;hb=HEAD
(если нет принципиальных возражений -- для меня работает)
------- Comment #19 From 2008-05-08 12:48:35 -------
(In reply to comment #18)
> (In reply to comment #16)
> > хотя нет ... не получается. Если делаю дефолт - ломаю потом конфигуратор.
> Мгм.  Вот и я в то же упёрся.
> 
> > Надо делать installer-feature.
> Ты/я?  Выдрать можно отсюда:
Ты ;)
------- Comment #20 From 2008-05-08 15:59:05 -------
Сделал installer-feature-eth-by-mac; для архива добавляю пачку ссылок на баги
по
части "пляшущих интерфейсов":

https://bugzilla.altlinux.org/show_bug.cgi?id=10885
https://bugzilla.altlinux.org/show_bug.cgi?id=11786
https://bugzilla.altlinux.org/show_bug.cgi?id=13351
https://bugzilla.altlinux.org/show_bug.cgi?id=13353
https://bugzilla.altlinux.org/show_bug.cgi?id=13358