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

[Leonid Krivoshein]

22.09.2021 22:03, Alexey Gladkov пишет:
> On Wed, Sep 22, 2021 at 07:12:06PM +0300, Leonid Krivoshein wrote:
>> [...] Поэтому
>> я бы предпочёл не менять нынешнюю конструкцию, конфигурировать в диалогах
>> после запуска udev то, что не было сконфигурировано в командой строке, на
>> худой конец, прибегать к технике повторного сканирования, реализованной в
>> пропагаторе. И пусть параллельно с этим отрабатывают эвенты udev.
> А то что хочешь делать ты не ложится в текущую архитектуру. Во многих
> местах код рассчитывает, что конфигурация уже задана. Настройка сети одно
> из таких мест. Эвенты от интерфейса будут проигнорированы если нет
> конфигурации.

В сегодняшней версии 0.1.5-alt3 эту проблему устранили, благодаря тебе, 
конечно лучше глянуть код. Уже проверил и скоро выгружу. Теперь сеть 
идеально взлетает без диалогов и без форка фичи network. Без диалогов -- 
временная мера, просто сделан задел на будущее. Если сравнивать altboot 
с propagator, то один из минусов первого -- отсутствие диалогов 
конфигурирования сети. Но благодаря фиче network в самом make-initrd это 
можно пережить, хотя лучше, чтобы эти диалоги тоже были. Другой минус, я 
надеюсь, мы тоже почти преодолели -- он в теме. Теперь все те же опции 
мы можем брать по протоколу DHCP. А других минусов нет, остаются только 
плюсы, их становится всё больше.


> То есть придётся понимать такую ситуацию и ставить очередь network на
> паузу в ueventd. Это решит одну проблему, но все.

Как раз я представлял себе работу всего pipeline/bootchain с диалогами, 
в целом, как полноценную программу, работающую в обычной среде. Мы же не 
останавливаем в stage2 работающий udev каждый раз, когда нам что-то 
нужно. Propagator работает параллельно с udev, такое же поведение у 
altboot. Главное, как мне кажется, это две вещи: make-initrd при 
root=pipeline/bootchain ни при каких обстоятельствах не должен найти 
корень раньше, чем ему об этом скажет pipeline/bootchain, какие бы 
эвенты ему не пришлось параллельно обрабатывать. И второе: код самих 
pipeline/bootchain/altboot должен быть готовым работать в ситуации 
готовности к начальной загрузке, чтобы сканировать, ждать, если 
устройств ещё нет, при этом не создавать рейсов. Тогда эта концепция 
будет работать. Про диалоги и опции конфигурирования отдельно скажу.


> Если ты хочешь вернуться в начало, то нужно будет уметь откатываться на
> исходное состояние и начинать с начала. К этому некоторый код вообще не
> готов.

К этому всегда должен быть готов код в altboot. Сейчас он пишется с 
таким расчётом. Сеть там просто единожды опрашивается, поднятый 
интерфейс запоминается. При перезапуске altboot используется ранее 
созданная конфигурация. Пока так...


> Начало происходить то чего я опасался.

Не начало и не начнёт. Напротив, ждём не дождёмся, когда это закончится! 
Вот и Антон Мидюков вчера настаивал, чтобы я приступил к процессу 
апстрима, т.к. почти все его замечания были устранены, а он проверяет на 
всех мыслимых кейсах и регулярках, на разных архитектурах. Не начнёт, 
потому что мне эту ношу не потянуть, я лишь помогу в той части, что 
обещал, но не более.


> Ты где-то отдельно пишешь код

Код отправляю пока в Сизиф и в локальную гитовницу:

git.altlinux.org/people/klark/packages/make-initrd-bootchain.git


> вместо того чтобы обсуждать и порциями добавлять.

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

Лично мне кажется, что ни один пакет у нас так пристально не проверялся, 
попадая в обычные продукты. Но altboot -- важное звено в процессе 
загрузки и моя задача учесть совместимость с уже сделанным в Альте за 
многие годы.


> В итоге ты уверенно
> движешься к форку уже самого make-initrd (именно это ты и делаешь,
> поверь).

Поверь, этому не бывать! ;-)


> Ты уже спроектировал и реализовал свою систему так с чем я не
> могу согласиться.

Предлагаю не делать поспешных выводов. Фичи pipeline и network ты 
спроектировал. propagtor проектировал не я, но мне приходится во многом 
повторять его и его поведение, при этом я стараюсь не делать форк фич 
там, где это возможно, мы решаем задачу по избавлению от propagator и 
запихиванию его функционала в make-initrd. Всё это проделано зря, если 
вместо propagator предложить в чистом виде pipeline или иную новую 
концепцию загрузки, которая будет идеальной с точки зрения make-initrd, 
но непригодной для реального применения без переделки всего остального.

Как раз я старался учесть возможность перехода в будущем на более 
правильные концепции. Но сейчас и тебе надо принять, как данность, что 
пусть "функционал пропагатора" с твоей точки зрения не идеален, лучше 
чтобы он был внутри make-initrd и работал как 1/80 часть его рантайма, а 
не наоборот, чтобы настоящий propagator полностью выкидывал и заменял 
собой все 100% рантайма make-initrd. Можно и нужно обсуждать, как лучше 
сделать это, не ломая совместимости, и учитывая потребности перехода на 
что-то более правильное в перспективе.


> И я до сих пор не видел ни одного патча. Поэтому для
> меня каждая твоя проблема является большим сюрпризом.

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


> [...]
> Я говорил про удаление всей конфигурации не только из-за IFNAME. Если у
> тебя был dhcp на интерфейсе, а теперь пользователь хочет статику, то dhcp
> нужно аккуратно остановить.

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

http://git.altlinux.org/gears/m/make-initrd-bootchain.git?p=make-initrd-bootchain.git;a=blob;f=bootchain-waitnet/data/lib/bootchain/waitnet;h=5a1a8d2acd09c06d8091b921803850ea313de2ed;hb=9305bcd041b50b018d7fa4c11cebac4123514b26#l24

Т.е. в версии 0.1.5-alt2 тут вообще диалог о том, что "перезагрузись и 
сконфигурируй сеть через /proc/cmdline". В версии 0.1.5-alt3 этот же 
диалог и перезагрузка будет только в случае, если недоступен протокол IPv4.


> [...]
> Сначала я хочу понять зачем так в принципе делать т.к. cmdline.d/network
> не для этого вообще. Мне кажется странным пытаться сконфигурировать сеть
> путём эмуляции указания /proc/cmdline.

/proc/cmdline удобен тем, что можно что-то подлатать на лету, обойти 
проблемы, но это не лучшее место для хранения конфигурации. Даже 
ядерщики дожили до bootconfig. Я понимаю, что когда ты писал код фич, ты 
не рассчитывал на их повторный запуск. Но как мне быть, если нужно не 
сконфигурированную фичу сконфигурировать и перезапустить? Не делать же 
очередной форк!

Твоя фича рассчитывает на параметры из /proc/cmdline. А полная 
совместимость с пропагатором требует другого синтаксиса, который я мог 
бы расширить. В общем, я прикладываю усилия, чтобы использовать твою 
готовую фичу. И кажется, это удалось! Я же как раз не хочу делать форк 
всей или даже части фичи network, хотя и она "часть замены пропагатора", 
напротив, есть желание пристроится к уже готовому.


> [...]
> Я с самого начала обсуждения диалогов говорил, что они должны быть сделаны
> на системном уровне, чтобы весь код был готов к изменению параметров, но
> почему-то меня не услышали.

Тебе видней, как это реализовать на системном уровне, разве кто-то будет 
возражать! Я не так хорошо пока знаю архитектуру make-initrd, но 
предлагал перетащить на верхний уровень bootchain-interactive. Кстати, 
только сегодня думал, что может как раз не стоит перетаскивать, а лучше 
оставить в составе пошаговой загрузки на отдельном терминале. Потому что 
разные фичи (запущенные демоны) должны выстраиваться в очередь, диалоги 
не должны мешаться, они не всегда бывают диалогами ввода. Про перевод 
всех параметров /proc/cmdline в форму диалогов я правда слышу в первый 
раз. Мне кажется сомнительной такая возможность. Но пристраивание 
диалогов к имеющимся фичам мы тоже хотели с тобой обсудить и возможно 
нам сегодня удалось это реализовать, ниже-то речь как раз об этом:

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


P.S.: Если хочешь, давай остановимся на версии 0.1.5-alt3 и начнём её 
апстримить. Вот прямо сегодня! :-) А там уже будем обсуждать изменения, 
необходимые сразу и после апстрима. Я уверен, что хуже от этого никому 
не станет. Даже если что-то там ещё окажется не идеальным, наличие 
altboot внутри make-initrd не помешает никому собирать образы с 
проверенным пропагатором. И никто не заставляет ставить фичи типа 
make-initrd-bootchain в свою систему. К тому же эта версия последняя, 
исправляющая замечания, две следующие планировались по "хотелкам", 
которые можно отложить на полгода. Самое жёсткое пересечение -- это форк 
фичи pipeline в bootchain, только оно может затронуть нынешних 
пользователей pipeline, коих не так много.


-- 
Best regards,
Leonid Krivoshein.