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 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 -----