Re: [make-initrd] udhcpc script в фиче network

[Leonid Krivoshein <klark.devel@gmail.com>]

22.09.2021 17:46, Alexey Gladkov пишет:
> On Wed, Sep 22, 2021 at 04:50:57PM +0300, Leonid Krivoshein wrote:
>> 22.09.2021 16:08, Alexey Gladkov пишет:
>>> [...]
>>> Это довольно смелое предположение что когда тебя не просят конфигурировать
>>> сеть, то на самом деле пользователь хотел dhcp ... да ещё и ipv4.
>> [...] Главная подоплёка в том,
>> что если сетевых настроек нет, хорошо бы их спрашивать. Ну, потому что без
>> сети с выбранным методом иначе не загрузиться. Сейчас код более простой.
>> Возможно, тут стоит выводить диалоги. Но вопрос в последующем применении
>> новых настроек.
> Весь вот этот автоугадав и домысливание должно происходить после сервиса
> cmdline. Или же даже проще - до сервиса udev. В этом случае вся
> конфигурация будет готова и не будет никаких гонок.
>
> Вообще почти все диалоги с уточнением конфигурации должны быть тут т.е. до
> udevd и pipelined.

Сначала ужаснулся от мысли о необходимости разделения bootchain на две 
части -- диалоговую для выяснения конфигурации и ту, что работает сейчас 
после udev. Конечно, нет ничего невозможного, так работают многие 
инсталляторы, сначала задавая вопросы, а потом выполняют действия по уже 
подготовленным ответам. Но... не получится! Так как есть диалоги, 
которые предлагают выбор определённого оборудования, а для его 
определения нужен udev. И ещё мы можем всегда вернутся в самое начало. 
Плюс те диалоги, когда в процессе выполнения что-то пошло не так, тут 
тоже могут быть варианты. Немыслимо организовать связку между этими 
двумя частями, когда посредине будет запуск udev. Поэтому я бы предпочёл 
не менять нынешнюю конструкцию, конфигурировать в диалогах после запуска 
udev то, что не было сконфигурировано в командой строке, на худой конец, 
прибегать к технике повторного сканирования, реализованной в 
пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev.


>> Для altboot пока что не имеет значения, что make-initrd умеет работать с
>> IPv6. В нём просто нет пока его поддержки, как и в пропагаторе. Если
>> указывать ip=dhcp, сеть поднимается дольше. Поддержку IPv6 можно будет
>> добавить позже...
> Я считаю, что в 2021 уже не нужно говорить о поддержке IPv6 в новом коде.
> Нужно просто считать, что он есть.
>
> Для того чтобы в пустую не ждать есть функции ipv4_enabled/ipv6_enabled.
> Кстати, IPv4 в современном мире может быть выключен и это стоит учитывать.

Это очень правильное замечание, я даже и не сомневался, что это так. 
Мало того, я уверен, что добавить поддержку IPv6 в altboot до безобразия 
просто. Но лично я мало что понимаю в IPv6, так что если кто-то поможет 
заменить вызовы resolve на resolve6 и ss в паре мест, буду признателен. 
Так, конечно, основная поддержка сети IPv6 уже есть в самом make-initrd 
и грех её не использовать. И основное тут даже не код, а тестирование -- 
я это не смогу проверить как следует.


> [...]
>>> /lib/initrd/cmdline.d/network должен выполняться лишь один раз до всего
>>> это этого subshell. Он генерирует конфигурацию для всех интерфейсов.
>> Но он уже один раз выполнился до входа в bootchain-waitnet, при этом был
>> сконфигурирован только "lo".
> lo всегда есть. Он даже не конфигурируется:
>
> features/network/data/etc/network/ifaces/lo/ipv4address
>
> Зоркий глаз может заметить, что формат конфигов очень похож на etcnet ;)

Да, я заметил, как и разницу. Мне показалось странным, зачем при 
авто-конфигурировании сохранять не полученные значения, а некие строки 
типа "nameserver <value1> <value2>" или "defult via <value>", ведь их же 
потом неудобно будет парсить. Но видимо так задумано, чтобы читать потом 
всю конфигурацию в едином формате.

Если сравнивать фичу network с etcnet из stage2, то у меня возникает два 
недоумения... ))

1. Зачем такой навороченный network в stage1? Ведь для сетевой загрузки 
нужен только один интерфейс.
2. С другой стороны, etcnet умеет vlan'ы, bond'ы и много чего, а network 
сейчас непригоден для загрузки через такое, а значит придётся менять 
конфигурацию на свичах или использовать отдельную сеть только для 
сетевой загрузки.


>>> Перед этим стоит остановить udev

А как это правильнее сделать? И не лучше ли тогда, не останавливая udev, 
заставить его перечитать правила?


>>> поскольку cmdline.d/network дописывает
>>> /etc/udev/rules.d/60-persistent-net.rules и я вообще сомневаюсь, что там
>>> всё правильно. Скорее всего нужно переделывать работу с
>>> 60-persistent-net.rules, чтобы можно было запускать cmdline.d/network
>>> несколько раз.

Насчёт этого я думаю, что можно вообще не беспокоиться, т.к. если IFNAME 
был синтаксически правильно определён в /proc/cmdline и udev-правило уже 
отработало один раз, то интерфейс с нужным именем уже появился и 
повторная обработка IFNAME не требуется, диалогов для этого не 
предполагается.


>> [...]
>> 2) IFNAME -- должен отрабатывать один раз, конечно, поэтому мне жалко
>> удалять всю конфигурацию. :-)

...а значит и удаление всей конфигурации не должно отрицательно 
сказаться на повторном конфигурировании, которое не предусматривает 
диалогового аналога IFNAME=..., либо я чего-то не учитываю?


>>> Также перед запуском cmdline.d/network нужно удалить старую конфигурацию!
>> А как это правильно сделать? rm -rf -- "$net_autoconfdir" "$net_statedir" ?
> cmdline.d/network кладёт всё сюда:
>
> "$net_confdir/ifaces/$interface"
> "$net_confdir/default"
>
> net_autoconfdir -- это место, куда кладут конфигурацию dhcp. Они отделены
> от системной конфигурации, чтобы они не смешивались. В некоторых случаях
> это нужно.
>
> Для каждого интерфейса параметры могут приехать из:
>
> net_autoconfdir/ifaces/$NET_IF/*
> net_confdir/ifaces/$NET_IF/*
> net_confdir/default/*
>
> net_statedir -- это результат объединения всех. Это стейт.
>
> Наверно, стоит написать отдельную функцию, чтобы "забыть" конфигурацию
> интерфейса.

Тогда уж лучше научить cmdline.d/network повторно конфигурировать все 
интерфейсы, чтобы он сам удалял то, что было раньше. :-)


> [...]
>> но я не рискнул писать развесистую логику, а решил использовать
>> готовую фичу. При этом возникает риск гонок: самое начало загрузки, модуль
>> сетевой карты мог ещё не подгрузиться, сеть заранее никто не
>> сконфигурировал, а тут я пытаюсь что-то перезапускать...
> Гонки с загрузкой модулей неприятные, да. Тут может быть такая эвристика:
> мы догадались, что нужна сеть, ни одного интерфейса нет (кроме lo)? значит
> ждём появления сетевого интерфейса.
>
> Будет другая проблема если интерфейсы будут появляться сильно не сразу, но
> это уже следующая проблема.

Потому я и пытаюсь пристроиться к имеющейся фиче network очень 
аккуратно. Следом за приведённым фрагментом идёт код, который просто 
ждёт появления хоть какого-то реального интерфейса.

В финальном же варианте идеал мне видится таким: конфигурирование сети 
через диалоги, если определённая конфигурация не даёт полного 
представления о единственном сетевом интерфейсе. В ранних исталляторах 
(не альтовых) я видел, что до диалогов настройки сети предпринимаются 
попытки сконфигурировать сеть по DHCP. Не уверен, что это плохая идея, 
потому что лишние диалоги на этапе загрузки -- зло, а когда ещё не 
работает мышь/клавиатура -- даже вредительство. :-)


>> Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у
>> нас снимется много вопросов о том, как интегрировать bootchain/interactive с
>> уже имеющимися фичами make-initrd. Будет хороший пример, как это можно
>> сделать.
> То есть ты предлагаешь мне сделать диалоги для конфигурирования сети ? (я
> не против).

Нет, наоборот, диалоги же как раз по моей части:
https://lists.altlinux.org/pipermail/devel/2018-April/204192.html :-)


-- 
Best regards,
Leonid Krivoshein.