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

Wed Sep 22 22:03:48 MSK 2021

On Wed, Sep 22, 2021 at 07:12:06PM +0300, Leonid Krivoshein wrote:
> 
> 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.

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

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

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

Начало происходить то чего я опасался. Ты где-то отдельно пишешь код
вместо того чтобы обсуждать и порциями добавлять. В итоге ты уверенно
движешься к форку уже самого 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>", ведь их же потом
> неудобно будет парсить. Но видимо так задумано, чтобы читать потом всю
> конфигурацию в едином формате.

Потому что это не формат, а опции ip.

> Если сравнивать фичу network с etcnet из stage2, то у меня возникает два
> недоумения... ))
> 
> 1. Зачем такой навороченный network в stage1? Ведь для сетевой загрузки
> нужен только один интерфейс.

Это малая доля того что реализовано в redhat [1]. Я реализовал, что сходу
смог. Не могу сказать, что она навороченная. Большинство рецептов в
интернете про redhat (без обид, altlinux) и хорошо бы если бы они работали
и в альте.

[1] https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_network

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

etcnet не очень готов работать с busybox. Плюс он работает как чёрный ящик
то есть его интерфейс ifup/ifdown.

Насчёт vlan и bond: я думал их добавить, но не стал потому что мне сложно
это тестировать.

Если network не нравится, то можно хоть NetworkManager в образ поместить.
Я так пробовал делать если что.

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

Если переделать работу с 60-persistent-net.rules, то возможно
останавливать и не нужно будет. udev перечитывает правила, если они
меняются.

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

С каждым перезапуском cmdline.d/network в 60-persistent-net.rules будет
всё больше и больше дублирующихся правил.

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

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

> > > > Также перед запуском 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 повторно конфигурировать все
> интерфейсы, чтобы он сам удалял то, что было раньше. :-)

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

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

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

> > > Если удастся найти рабочий вариант с диалогами настройки сети "вдогонку", у
> > > нас снимется много вопросов о том, как интегрировать bootchain/interactive с
> > > уже имеющимися фичами make-initrd. Будет хороший пример, как это можно
> > > сделать.
> > То есть ты предлагаешь мне сделать диалоги для конфигурирования сети ? (я
> > не против).
> 
> Нет, наоборот, диалоги же как раз по моей части:
> https://lists.altlinux.org/pipermail/devel/2018-April/204192.html :-)

-- 
Rgrds, legion