[devel] [bugzilla-daemon на altlinux.ru: [Bug 34347] Странный временный нуль-маршрут ломает сетевую rootfs]

Пн Май 28 19:19:21 MSK 2018

On Thu, May 24, 2018 at 03:14:39AM +0300, Leonid Krivoshein wrote:
> По предыдущему опыту желающих тестировать и ревьювить такое мало, если
> не сказать "нет совсем".

Я готов содействовать по мере наличия времени.
Нам в ACL пропагатора (пока его ещё не закопали) нужен кто-то, кто готов
мониторить возможность сетевой загрузки дистрибутивов, без этого ошибки
исправляться не будут. Насколько мне известно, текущий состав ACL просто
сильно загружен.

https://bugzilla.altlinux.org/34347
https://bugzilla.altlinux.org/34320

Пользуясь случаем, всё-таки прошу одобрить таск 206842, исправляющий
баги 34347 и 34320. Если код слишком плохой даже для пропагатора,
я поправлю, мне не жалко. :)

> ...такие вещи обсуждать лучше в devel на .

Тогда пойдёмте в devel@!

> Например, вот эту цитату:
> 
> Servers that respond SHOULD only use option 43 to return the vendor-specific
> information to the client.
> из RFC-2132 9.13 трактуют по-разному, вплоть до того, что получив от клиента
> опцию 60 (Vendor Class Identifier) DHCP-сервер должен ему возвращать только
> значение опции 43 (Vendor Specific Information), в которой закодирован и
> TFTP-сервер, и имя файла-образа, а опции 66 (next-server) и 67 (filename) при
> этом должны игнорироваться.

Когда я это реализовывал, я решал общую задачу вычленения
DHCP-сообщений от пропагатора из общей массы трафика. Для этого можно
было снабдить сообщения опцией 60 (так, как сейчас в таске; так же
поступает dhcpcd), либо, например, опцией 77 (так делает iPXE).
Опцию 77 описывает RFC 3004; из этого документа легко сделать вывод, что
она вообще предназначена для самоидентификации со стороны
клиента либо категории его пользователя:

} DHCP clients implementing this option SHOULD allow users to enter one
} or more user class values.

Что касается трактовки «Servers that respond SHOULD only use option 43
to return the vendor-specific information to the client», посмею предположить,
что здесь по правилам грамматики английского языка подразумевалось
не разговорное «only» в начале предложения, а «серверам СЛЕДУЕТ заносить 
особенную информацию только лишь в опцию 43». Как-то оно менее абсурдно
в такой интерпретации звучит.

Большинство option-ROMs сетевых карт заполняет опцию 60 чем-то вроде
"PXEClient:ARCH:0007:UNDI:003010", или в последнее время
"HTTPClient:Arch:00016:UNDI:003001". Сервер, который им бы на это
отвечал тарабарщиной в опции 43, не был бы пригоден к использованию.

К тому же строчка вроде
«ALT-Propagator-20180601-alt1:Linux-4.9.99-std-def-alt1:amd64»
передаёт очень ценную информацию и совершенно бесповоротно описывает
вендора DHCP-клиента, а именно Alt Linux Team.

> я уже говорил, где у нас в сетевой загрузке совершенно точно нарушен
> стандарт и на что это влияет
Хоть я и не настаиваю, но прошу всё же посвятить в курс, ибо сейчас этого
нигде в непосредственной близости не задокументировано.
Связано ли это с root-path?

----- Forwarded message from bugzilla-daemon на altlinux.ru -----

Date: Thu, 24 May 2018 03:14:41 +0300 (MSK)
From: bugzilla-daemon на altlinux.ru
To: arseny на altlinux.org
Subject: [Bug 34347] Странный временный нуль-маршрут ломает сетевую rootfs

https://bugzilla.altlinux.org/34347
Component: Sisyphus/propagator

--- #13 Leonid Krivoshein <klark.devel на gmail.com> 2018-05-24 03:14:39 ---
(В ответ на комментарий №12)
> С пропагатором 20180423-alt1 сетевые карточки действительно подхватываются
> (спасибо, Леонид!), но проблема из сабжа всё же ещё не решена.

Проблему с нуль-маршрутом я действительно не решал, хоть и видел ваш патч,
поскольку мало что в этом понимаю. А что масштабно потестировали новую версию
пропагатора -- вам отдельное спасибо!

> Прошу желающих/заинтересованных потестировать, а тех,
> кто в ACL — одобрить таск №206842 с исправлением ошибки.

Предлагаю анонсировать максимально масштабно и в devel@, и в sisyphus@ хотя бы.
По предыдущему опыту желающих тестировать и ревьювить такое мало, если не
сказать "нет совсем". А в данном случае тестирование ещё более сложное,
поскольку нужны шлюзы. Код посмотрел и даже есть что сказать, но такие вещи
обсуждать лучше в devel на . Например, вот эту цитату:

Servers that respond SHOULD only use option 43 to return the vendor-specific
information to the client.

из RFC-2132 9.13 трактуют по-разному, вплоть до того, что получив от клиента
опцию 60 (Vendor Class Identifier) DHCP-сервер должен ему возвращать только
значение опции 43 (Vendor Specific Information), в которой закодирован и
TFTP-сервер, и имя файла-образа, а опции 66 (next-server) и 67 (filename) при
этом должны игнорироваться.

Но я не уверен в правильности такой трактовки RFC-2132/4361/etc и исхожу из
того, что вы лучше понимаете, что делаете. Георгию Курячему я уже говорил, где
у нас в сетевой загрузке совершенно точно нарушен стандарт и на что это влияет.

-- 
You reported the bug.

https://bugzilla.altlinux.org/e (basic email parameters)
https://bugzilla.altlinux.org/s (additional subscription)

----- End forwarded message -----
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20180528/3db18175/attachment.bin>