[devel] подсистема настройки сети в дистрибутивах

[devel] подсистема настройки сети в дистрибутивах

[Alexey Shabalin]

День добрый.
Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
Ситуация сейчас следующая:
- в рабочей станции и других дистрибутивах с GUI используют NetworkManager
- в сервере есть попытка перехода на systemd-networkd (почему поытка -
ниже :). etcnet оставлен как запасной вариант.

При этом настройщик сети в инсталяторе alterator-eth гвоздями прибит к
etcnet. То что в нем можно выбрать NetworkManager или networkd на
самом деле "обманка", настроить можно только статику или динамику на
интерфейсе (а для NetworkManager и этого кажется нет, могу ошибаться).
Никаких bridge, bond, vlan недоступны для настройки для NM или
networkd в alterator-eth.

Сам проект etcnet в стагнации. Не развивается, только закрываются
откровенные баги.
И есть серьезные причины избегать его использования.
Например, service network reload по факту делает restart всей сети, в
том числе теряет подключение всех виртуальных машин к bridge, после
чего виртуалки приходится переключать заного к "виртуальному
коммутатору". Т.е. нет возможности применить только изменения в
конфигах, кладется вся сеть целиком.

Итого: уходим от использования etcnet в дистрибутивах, но
alterator-eth еще не готов для использования с другими подсистемами
настройки сети.

Предложение:
Давайте рассмотрим вариант использовать в дистрибутивах netplan
https://netplan.readthedocs.io/en/stable/structure-id/
Расписывать все плюсы и минусы я тут не буду. Только основные.
Плюсы:
- работает и с NetworkManager и с networkd. Причем можно чётко указать
что использовать
- один конфигурационный файл, нет нужды править множество кофигов.
(хотя yaml для кого-то может быть минусом)
- умеет настраивать bond, bridge, vlan, openvswitch, wireguard, wifi,
тунели. Вроде все что нам обычно нужно.
- есть dbus интерфейс (может пригодиться для нового alterator)
- netplan apply применяет изменения настроек, без полной перезагрузки сети

Минусы:
- админские утилиты на python


Если перерабатывать alterator-eth, то может сразу на использование
netplan, который умеет генерировать настройки для NM и networkd?

PS: я не призываю удалять etcnet из сизифа. Я говорю о дистрибутивах,
которые по факту уходят от использования etcnet.

-- 
Alexey Shabalin

[devel] netplan (was: подсистема настройки сети в дистрибутивах)

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Wed, Apr 17, 2024 at 08:21:40PM +0300, Alexey Shabalin wrote:
> День добрый.
> Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
> <...>
> Предложение:
> Давайте рассмотрим вариант использовать в дистрибутивах netplan
> https://netplan.readthedocs.io/en/stable/structure-id/
> Расписывать все плюсы и минусы я тут не буду. Только основные.
> <...>
> 
> Минусы:
> - админские утилиты на python
YAML сам по себе — один большой минус. https://noyaml.com

Та же коллекция фактов, но в менее шуточном виде:
https://github.com/ghuntley/noyaml/blob/db7b929f99c42e0f792c7322438297ec9ee6331d/index.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] netplan (was: подсистема настройки сети в дистрибутивах)

[Alexey Shabalin]

ср, 17 апр. 2024 г. в 21:02, Arseny Maslennikov <arseny@altlinux.org>:
>
> On Wed, Apr 17, 2024 at 08:21:40PM +0300, Alexey Shabalin wrote:
> > День добрый.
> > Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
> > <...>
> > Предложение:
> > Давайте рассмотрим вариант использовать в дистрибутивах netplan
> > https://netplan.readthedocs.io/en/stable/structure-id/
> > Расписывать все плюсы и минусы я тут не буду. Только основные.
> > <...>
> >
> > Минусы:
> > - админские утилиты на python
> YAML сам по себе — один большой минус. https://noyaml.com
>
> Та же коллекция фактов, но в менее шуточном виде:
> https://github.com/ghuntley/noyaml/blob/db7b929f99c42e0f792c7322438297ec9ee6331d/index.html

Зато он единый и понятный для всех настроек.
в etcnet:
option - в формате key=value
ipv4address - значение для команды ip address
ipv4route - значения для команды ip route
iplink - значение для команды ip link
ovpnoptions - конфиг openvpn
pppoptions - конфиг ppp

А еще огромную роль играет местоположение файла, в какой папке он
находится. Про настройки fw я вообще промолчу :)
Понятно, файл считывается и передается на вход или как параметр нужной
утилите, это упрощает реализацию etcnet.
Но глядя со стороны - никакого однообразия. Если пользователь не
админ, то никогда не поймет формат кофигов ip*

С этой точки зрения, yaml уже не так страшен :)

-- 
Alexey Shabalin

Re: [devel] подсистема настройки сети в дистрибутивах

[Alexey Shabalin]

ср, 17 апр. 2024 г. в 20:21, Alexey Shabalin <a.shabalin@gmail.com>:
> - один конфигурационный файл, нет нужды править множество кофигов.
> (хотя yaml для кого-то может быть минусом)
Тут я ошибся. Обрабатываются
- /run/netplan/*.yaml
- /etc/netplan/*.yaml
- /lib/netplan/*.yaml

-- 
Alexey Shabalin

Re: [devel] подсистема настройки сети в дистрибутивах

[Антон Мидюков]

18.04.2024 00:21, Alexey Shabalin пишет:
> День добрый.
> Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
> Ситуация сейчас следующая:
> - в рабочей станции и других дистрибутивах с GUI используют NetworkManager
> - в сервере есть попытка перехода на systemd-networkd (почему поытка -
> ниже :). etcnet оставлен как запасной вариант.
> 

Добавлю, что есть ещё один блокер, который не позволит использовать systemd-networkd в инсталляторе полноценно.
В инсталляторе не запускется systemd, вместо него запускается простенький install2-init.

> При этом настройщик сети в инсталяторе alterator-eth гвоздями прибит к
> etcnet. То что в нем можно выбрать NetworkManager или networkd на
> самом деле "обманка", настроить можно только статику или динамику на
> интерфейсе (а для NetworkManager и этого кажется нет, могу ошибаться).
> Никаких bridge, bond, vlan недоступны для настройки для NM или
> networkd в alterator-eth.
> 
> Сам проект etcnet в стагнации. Не развивается, только закрываются
> откровенные баги.
> И есть серьезные причины избегать его использования.
> Например, service network reload по факту делает restart всей сети, в
> том числе теряет подключение всех виртуальных машин к bridge, после
> чего виртуалки приходится переключать заного к "виртуальному
> коммутатору". Т.е. нет возможности применить только изменения в
> конфигах, кладется вся сеть целиком.
> 
> Итого: уходим от использования etcnet в дистрибутивах, но
> alterator-eth еще не готов для использования с другими подсистемами
> настройки сети.
> 
> Предложение:
> Давайте рассмотрим вариант использовать в дистрибутивах netplan
> https://netplan.readthedocs.io/en/stable/structure-id/
> Расписывать все плюсы и минусы я тут не буду. Только основные.
> Плюсы:
> - работает и с NetworkManager и с networkd. Причем можно чётко указать
> что использовать
> - один конфигурационный файл, нет нужды править множество кофигов.
> (хотя yaml для кого-то может быть минусом)
> - умеет настраивать bond, bridge, vlan, openvswitch, wireguard, wifi,
> тунели. Вроде все что нам обычно нужно.
> - есть dbus интерфейс (может пригодиться для нового alterator)
> - netplan apply применяет изменения настроек, без полной перезагрузки сети
> 
> Минусы:
> - админские утилиты на python
> 
> 
> Если перерабатывать alterator-eth, то может сразу на использование
> netplan, который умеет генерировать настройки для NM и networkd?
> 
> PS: я не призываю удалять etcnet из сизифа. Я говорю о дистрибутивах,
> которые по факту уходят от использования etcnet.
> 

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] подсистема настройки сети в дистрибутивах

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2024-04-17 20:21:40 +0300, Alexey Shabalin wrote:

 > День добрый. Хочу поднять обсуждение о подсистеме настройки сети
 > в наших дистрибутивах. Ситуация сейчас следующая: - в рабочей
 > станции и других дистрибутивах с GUI используют NetworkManager
 > - в сервере есть попытка перехода на systemd-networkd (почему
 > поытка - ниже :). etcnet оставлен как запасной вариант.

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

 > Сам проект etcnet в стагнации. Не развивается, только закрываются
 > откровенные баги. И есть серьезные причины избегать его
 > использования. Например, service network reload по факту делает
 > restart всей сети, в том числе теряет подключение всех виртуальных
 > машин к bridge, после чего виртуалки приходится переключать
 > заного к "виртуальному коммутатору". Т.е. нет возможности
 > применить только изменения в конфигах, кладется вся сеть целиком.

Конфигурация сети - это не демон, для нее reload|restart хоть и
возможны технически, но особого смысла в абсолютном большинстве
случаев не имеют.

 > Предложение: Давайте рассмотрим вариант использовать в
 > дистрибутивах netplan [...]
 > умеет настраивать bond, bridge, vlan,

VLAN? Вот прямо с перенумерацией и QinQ?

 > openvswitch, wireguard, wifi, тунели. Вроде все что нам обычно
 > нужно.

Как насчет хотя бы VRF? :-)

А ведь есть и другие полезные (а иногда и просто необходимые)
функции сетевой подсистемы ядра. Причем далеко не все они даже
в LARTC описаны (увы, там с 2012 года застой).

 > есть dbus интерфейс (может пригодиться для нового alterator)
 > netplan apply применяет изменения настроек, без полной
 > перезагрузки сети

Вот как раз это совершенно не критично.

 > Минусы: - админские утилиты на python

А это сразу исключает использование данной приблуды там, где
необходимо минимизировать поверхность атаки. Серверы, ага.

 > Если перерабатывать alterator-eth, то может сразу на использование
 > netplan, который умеет генерировать настройки для NM и networkd?
 > PS: я не призываю удалять etcnet из сизифа. Я говорю о
 > дистрибутивах, которые по факту уходят от использования etcnet.

Для десктопов оно избыточно (еще больше, чем NM), для серверов
малопригодно... что остается-то, ноутбуки?


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] подсистема настройки сети в дистрибутивах

[Alexey Shabalin]

чт, 18 апр. 2024 г. в 12:17, Alexey V. Vissarionov <gremlin@altlinux.org>:
>
> Good ${greeting_time}!
>
> On 2024-04-17 20:21:40 +0300, Alexey Shabalin wrote:
>
>  > День добрый. Хочу поднять обсуждение о подсистеме настройки сети
>  > в наших дистрибутивах. Ситуация сейчас следующая: - в рабочей
>  > станции и других дистрибутивах с GUI используют NetworkManager
>  > - в сервере есть попытка перехода на systemd-networkd (почему
>  > поытка - ниже :). etcnet оставлен как запасной вариант.
>
> Все это - решения для рабочих станций. Ну, еще в совсем простых
> сетях можно для локальных серверов как-то что-то наколхозить.

На самом деле все сложное в сетях должно делаться на сетевом оборудовании.
А на сервера или рабочие станции сеть должна подаваться в максимально
простом виде.
Для надежности.
В "сложном" виде (bonding, тэгированные vlan) сеть подается на хосты
виртуализации или програмные маршрутизаторы.
Netplan умеет типовые простые и сложные сети. Понятно, что можно найти
особенный случай, который не поддерживается.
Его тоже можно решить pre и post хуками, запуская скрипты.

>
>  > Сам проект etcnet в стагнации. Не развивается, только закрываются
>  > откровенные баги. И есть серьезные причины избегать его
>  > использования. Например, service network reload по факту делает
>  > restart всей сети, в том числе теряет подключение всех виртуальных
>  > машин к bridge, после чего виртуалки приходится переключать
>  > заного к "виртуальному коммутатору". Т.е. нет возможности
>  > применить только изменения в конфигах, кладется вся сеть целиком.
>
> Конфигурация сети - это не демон, для нее reload|restart хоть и
> возможны технически, но особого смысла в абсолютном большинстве
> случаев не имеют.

У нас разные клиенты :)
Кто-то настраивает сеть через web-интерфейс PVE, и не ожидает, что
нажав кнопку Apply потеряет доступ к хосту.
А теряет потому, что network reload на самом деле restart.

>
>  > Предложение: Давайте рассмотрим вариант использовать в
>  > дистрибутивах netplan [...]
>  > умеет настраивать bond, bridge, vlan,
>
> VLAN? Вот прямо с перенумерацией и QinQ?

да, networkd умеет, в том числе и 802.1ad


>
>  > openvswitch, wireguard, wifi, тунели. Вроде все что нам обычно
>  > нужно.
>
> Как насчет хотя бы VRF? :-)

Да.
Смотри https://github.com/canonical/netplan/blob/main/examples/vrf.yaml


>
> А ведь есть и другие полезные (а иногда и просто необходимые)
> функции сетевой подсистемы ядра. Причем далеко не все они даже
> в LARTC описаны (увы, там с 2012 года застой).
>
>  > есть dbus интерфейс (может пригодиться для нового alterator)
>  > netplan apply применяет изменения настроек, без полной
>  > перезагрузки сети
>
> Вот как раз это совершенно не критично.
>
>  > Минусы: - админские утилиты на python
>
> А это сразу исключает использование данной приблуды там, где
> необходимо минимизировать поверхность атаки. Серверы, ага.
>
>  > Если перерабатывать alterator-eth, то может сразу на использование
>  > netplan, который умеет генерировать настройки для NM и networkd?
>  > PS: я не призываю удалять etcnet из сизифа. Я говорю о
>  > дистрибутивах, которые по факту уходят от использования etcnet.
>
> Для десктопов оно избыточно (еще больше, чем NM), для серверов
> малопригодно... что остается-то, ноутбуки?
>

А мне кажется пригодно для для всех трех случаев.


--
Alexey Shabalin

Re: [devel] подсистема настройки сети в дистрибутивах

[Anton Farygin]

On 18.04.2024 18:04, Alexey Shabalin wrote:
> чт, 18 апр. 2024 г. в 12:17, Alexey V. Vissarionov <gremlin@altlinux.org>:
>> Good ${greeting_time}!
>>
>> On 2024-04-17 20:21:40 +0300, Alexey Shabalin wrote:
>>
>>   > День добрый. Хочу поднять обсуждение о подсистеме настройки сети
>>   > в наших дистрибутивах. Ситуация сейчас следующая: - в рабочей
>>   > станции и других дистрибутивах с GUI используют NetworkManager
>>   > - в сервере есть попытка перехода на systemd-networkd (почему
>>   > поытка - ниже :). etcnet оставлен как запасной вариант.
>>
>> Все это - решения для рабочих станций. Ну, еще в совсем простых
>> сетях можно для локальных серверов как-то что-то наколхозить.
> На самом деле все сложное в сетях должно делаться на сетевом оборудовании.
> А на сервера или рабочие станции сеть должна подаваться в максимально
> простом виде.
> Для надежности.
> В "сложном" виде (bonding, тэгированные vlan) сеть подается на хосты
> виртуализации или програмные маршрутизаторы.
> Netplan умеет типовые простые и сложные сети. Понятно, что можно найти
> особенный случай, который не поддерживается.
> Его тоже можно решить pre и post хуками, запуская скрипты.
>
etcnet как раз хорош тем, что очень сложные случаи в нём можно сделать. 
А от networkmanager и system-networkd я отказался именно потому что он 
не смог.

Оборудование иметь хорошо, но часто бывают ситуации, когда дома его 
банально нет, а сложный конфиг нужен.

Re: [devel] подсистема настройки сети в дистрибутивах

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2024-04-18 18:04:24 +0300, Alexey Shabalin wrote:

 >>> - в рабочей станции и других дистрибутивах с GUI используют
 >>> NetworkManager
 >>> - в сервере есть попытка перехода на systemd-networkd (почему
 >>> поытка - ниже :). etcnet оставлен как запасной вариант.
 >> Все это - решения для рабочих станций. Ну, еще в совсем простых
 >> сетях можно для локальных серверов как-то что-то наколхозить.
 > На самом деле все сложное в сетях должно делаться на сетевом
 > оборудовании.

А у этого сетевого оборудования внутри волшебство происходит?

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

 > А на сервера или рабочие станции сеть должна подаваться в
 > максимально простом виде. Для надежности.

Если не пытаться работать с ядерным сетевым стеком, как с демоном
в userspace, его надежность превосходит, например, надежность
дисковой подсистемы.

 > В "сложном" виде (bonding, тэгированные vlan) сеть подается
 > на хосты виртуализации или програмные маршрутизаторы.

Хосты виртуализации по определению выполняют функции софтроутеров.

А еще серверы умеют не только подключаться к существующим сетям,
но и создавать их.

 > Netplan умеет типовые простые и сложные сети. Понятно, что
 > можно найти особенный случай, который не поддерживается. Его
 > тоже можно решить pre и post хуками, запуская скрипты.

И вся красивая модель управления сетевым стеком через managed
configuration идет коту под хвост :-)

Я через эти грабли еще лет 15 назад прошел. И нашел рабочее
решение, которое с большой вероятностью (могу уточнить днем)
работает до сих пор.

 >> Конфигурация сети - это не демон, для нее reload|restart
 >> хоть и возможны технически, но особого смысла в абсолютном
 >> большинстве случаев не имеют.
 > У нас разные клиенты :) Кто-то настраивает сеть через
 > web-интерфейс PVE, и не ожидает, что нажав кнопку Apply
 > потеряет доступ к хосту. А теряет потому, что network
 > reload на самом деле restart.

Для десктопа (за консолью которого и работает пользователь)
это вполне приемлемо. А если использовать десктопную схему
конфигурации сети на сервере - ну что ж, любой инструмент,
используемый не по назначению, превращается в грабли.

 >>> Предложение: Давайте рассмотрим вариант использовать в
 >>> дистрибутивах netplan [...]
 >>> умеет настраивать bond, bridge, vlan,
 >> VLAN? Вот прямо с перенумерацией и QinQ?
 > да, networkd умеет, в том числе и 802.1ad

Даже любопытно посмотреть, как оно с нетривиальными случаями
перенумерации справится.

 >>> openvswitch, wireguard, wifi, тунели. Вроде все что нам
 >>> обычно нужно.
 >> Как насчет хотя бы VRF? :-)
 > Да. Смотри
 > https://github.com/canonical/netplan/blob/main/examples/vrf.yaml

Так это ж совсем примитив... Ладно, будем считать, что хотя бы
про ip rule оно знает.

 >>> Если перерабатывать alterator-eth, то может сразу на
 >>> использование netplan, который умеет генерировать настройки
 >>> для NM и networkd?
 >>> PS: я не призываю удалять etcnet из сизифа. Я говорю о
 >>> дистрибутивах, которые по факту уходят от использования etcnet.
 >> Для десктопов оно избыточно (еще больше, чем NM), для серверов
 >> малопригодно... что остается-то, ноутбуки?
 > А мне кажется пригодно для для всех трех случаев.

Вот-вот, "кажется". А я говорю (особенно про серверы) на основании
опыта промышленной эксплуатации. В том числе с обеспечением SLA.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] подсистема настройки сети в дистрибутивах

[Leonid Krivoshein]

Добрый день!


On 4/17/24 20:21, Alexey Shabalin wrote:
> День добрый.
> Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
> Ситуация сейчас следующая:
> - в рабочей станции и других дистрибутивах с GUI используют NetworkManager
> - в сервере есть попытка перехода на systemd-networkd (почему поытка -
> ниже :). etcnet оставлен как запасной вариант.

С обывательской точки зрения важно не название инструмента, а его фичи. 
Приблуда для настройки сети (GUI из 2000-х годов) предлагает на выбор 
один из двух стеков IPv4/IPv6, не говорю даже про Infiniband, мало что 
умеет. И современный казалось бы инсталлятор грузится только через IPv4. 
Так оно и после установки одновременно не будет работать с etcnet. 
Другого установщика и Альтератора у нас пока нет.


> [...]
> Предложение:
> Давайте рассмотрим вариант использовать в дистрибутивах netplan
> https://netplan.readthedocs.io/en/stable/structure-id/
> Расписывать все плюсы и минусы я тут не буду. Только основные.
> [...]
>
> Если перерабатывать alterator-eth, то может сразу на использование
> netplan, который умеет генерировать настройки для NM и networkd?

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

Предлагался как вариант отказ от нынешнего инсталлятора, перенос части 
шагов в stage1, другой части шагов как это сделано с OEM уже при первой 
загрузке (alterator-setup), тогда установщик не нужен, мы развёртываем 
подготовленную rootfs, причём для некоторых сборок мы только так и 
делаем, потому что иначе просто нельзя. С ностальгией вспоминаю сборки 
rootfs для mipsel -- они вот прямо сходу были готовые к работе, и не 
надо ничего придумывать.


> PS: я не призываю удалять etcnet из сизифа. Я говорю о дистрибутивах,
> которые по факту уходят от использования etcnet.

-- 
WBR, Leonid Krivoshein.

Re: [devel] подсистема настройки сети в дистрибутивах

[Антон Мидюков]

19.04.2024 01:51, Leonid Krivoshein пишет:
> Добрый день!
> 
> 
> On 4/17/24 20:21, Alexey Shabalin wrote:
>> День добрый.
>> Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
>> Ситуация сейчас следующая:
>> - в рабочей станции и других дистрибутивах с GUI используют NetworkManager
>> - в сервере есть попытка перехода на systemd-networkd (почему поытка -
>> ниже :). etcnet оставлен как запасной вариант.
> 
> С обывательской точки зрения важно не название инструмента, а его фичи. Приблуда для настройки сети (GUI из 2000-х годов) предлагает на выбор один из двух стеков IPv4/IPv6, не говорю даже про Infiniband, мало что умеет. И современный казалось бы инсталлятор грузится только через IPv4. Так оно и после установки одновременно не будет работать с etcnet. Другого установщика и Альтератора у нас пока нет.

Речь о том, что интерфейс, с которого загрузились по сети, не настроить при установке. Правильно?

> 
> 
>> [...]
>> Предложение:
>> Давайте рассмотрим вариант использовать в дистрибутивах netplan
>> https://netplan.readthedocs.io/en/stable/structure-id/
>> Расписывать все плюсы и минусы я тут не буду. Только основные.
>> [...]
>>
>> Если перерабатывать alterator-eth, то может сразу на использование
>> netplan, который умеет генерировать настройки для NM и networkd?
> 
> Меньше всего хотелось бы вкладываться в доработку или переработку модулей Альтератора. В нём невозможно открыть второе дыхание. Поэтому жизнь уже давно заставляет обходиться без этого инсталлятора, если иначе никак.

Альтератор - это не только инсталлятор. Модуль настройки сети работает и в установленной системе, и при OEM настройке, о которой пишешь ниже.

> 
> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части шагов в stage1, другой части шагов как это сделано с OEM уже при первой загрузке (alterator-setup), тогда установщик не нужен, мы развёртываем подготовленную rootfs, причём для некоторых сборок мы только так и делаем, потому что иначе просто нельзя. С ностальгией вспоминаю сборки rootfs для mipsel -- они вот прямо сходу были готовые к работе, и не надо ничего придумывать.
> 

А что их вспоминать? Альт Рабочая станция в виде rootfs для aarch64 - готовая система к использованию.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] подсистема настройки сети в дистрибутивах

[Leonid Krivoshein]

On 4/19/24 03:29, Антон Мидюков wrote:
> 19.04.2024 01:51, Leonid Krivoshein пишет:
>> Добрый день!
>>
>>
>> On 4/17/24 20:21, Alexey Shabalin wrote:
>>> День добрый.
>>> Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
>>> Ситуация сейчас следующая:
>>> - в рабочей станции и других дистрибутивах с GUI используют NetworkManager
>>> - в сервере есть попытка перехода на systemd-networkd (почему поытка -
>>> ниже :). etcnet оставлен как запасной вариант.
>> С обывательской точки зрения важно не название инструмента, а его фичи. Приблуда для настройки сети (GUI из 2000-х годов) предлагает на выбор один из двух стеков IPv4/IPv6, не говорю даже про Infiniband, мало что умеет. И современный казалось бы инсталлятор грузится только через IPv4. Так оно и после установки одновременно не будет работать с etcnet. Другого установщика и Альтератора у нас пока нет.
> Речь о том, что интерфейс, с которого загрузились по сети, не настроить при установке. Правильно?

Нет, не только в stage1 проблему поддержки стеков нужно решать, но и в 
stage2, и в работающей rootfs. И вот эта поддержка стеков IP -- она куда 
более заметно отличает нашу поддержку сети от аналогичной в других 
дистрибутивах, если мы говорим не только о её конфигурировании через 
GUI, но и о дальнейшей работе с сетью.


>
>>
>>> [...]
>>> Предложение:
>>> Давайте рассмотрим вариант использовать в дистрибутивах netplan
>>> https://netplan.readthedocs.io/en/stable/structure-id/
>>> Расписывать все плюсы и минусы я тут не буду. Только основные.
>>> [...]
>>>
>>> Если перерабатывать alterator-eth, то может сразу на использование
>>> netplan, который умеет генерировать настройки для NM и networkd?
>> Меньше всего хотелось бы вкладываться в доработку или переработку модулей Альтератора. В нём невозможно открыть второе дыхание. Поэтому жизнь уже давно заставляет обходиться без этого инсталлятора, если иначе никак.
> Альтератор - это не только инсталлятор. Модуль настройки сети работает и в установленной системе, и при OEM настройке, о которой пишешь ниже.
>
>> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части шагов в stage1, другой части шагов как это сделано с OEM уже при первой загрузке (alterator-setup), тогда установщик не нужен, мы развёртываем подготовленную rootfs, причём для некоторых сборок мы только так и делаем, потому что иначе просто нельзя. С ностальгией вспоминаю сборки rootfs для mipsel -- они вот прямо сходу были готовые к работе, и не надо ничего придумывать.
>>
> А что их вспоминать? Альт Рабочая станция в виде rootfs для aarch64 - готовая система к использованию.
>

-- 
WBR, Leonid Krivoshein.

[devel] ОЕМ при установке всегда (was: подсистема настройки сети в дистрибутивах)

[Sergey V Turchin]

On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:

[...]
> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
> загрузке (alterator-setup),
Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после 
перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые 
настройки, которые делают installer-features-* и их надо запускать ещё раз, но 
никто этого не делает. При установке по сети достаточно будет закинуть какой-
нибудь autoinstall-файл, по которому всё само сделается.

> тогда установщик не нужен, мы развёртываем подготовленную rootfs
Это можно решить отдельно, но уже видна такая тенденция у коллег из других 
дистрибутивов.

[...]

-- 
Regards, Sergey.

Re: [devel] ОЕМ при установке всегда

[Антон Мидюков]

19.04.2024 14:50, Sergey V Turchin пишет:
> On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:
> 
> [...]
>> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
>> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
>> загрузке (alterator-setup),
> Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после 
> перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
> Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые 
> настройки, которые делают installer-features-* и их надо запускать ещё раз, но 
> никто этого не делает. При установке по сети достаточно будет закинуть какой-
> нибудь autoinstall-файл, по которому всё само сделается.
> 

А всё от того, что надо запускать эти настройки из /etc/firsttime.d/
Перенести их надо, и всё будет работать правильно.

Если уж и делить, то с той целью, чтобы не нужно было как сейчас запускать alterator в чруте.
Но установка grub и настройка пароля LUKS, как-то не OEM-но, а они выполняются в чрутном альтераторе.
Да и пароль root может быть необходимо задать.

Такое разделение облегчило бы переход на новый альтератор, количество необходимых модулей старого типа резко бы сократилось.
Новый альтератор не нужно было бы запускать в инсталляторе.

>> тогда установщик не нужен, мы развёртываем подготовленную rootfs
> Это можно решить отдельно, но уже видна такая тенденция у коллег из других 
> дистрибутивов.
> 



-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] ОЕМ при установке всегда

[Evgeny Sinelnikov]

Доброй ночи,

пт, 19 апр. 2024 г. в 12:00, Антон Мидюков <midyukov-anton@ya.ru>:
>
> 19.04.2024 14:50, Sergey V Turchin пишет:
> > On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:
> >
> > [...]
> >> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
> >> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
> >> загрузке (alterator-setup),
> > Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после
> > перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
> > Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые
> > настройки, которые делают installer-features-* и их надо запускать ещё раз, но
> > никто этого не делает. При установке по сети достаточно будет закинуть какой-
> > нибудь autoinstall-файл, по которому всё само сделается.
> >
>
> А всё от того, что надо запускать эти настройки из /etc/firsttime.d/
> Перенести их надо, и всё будет работать правильно.
>
> Если уж и делить, то с той целью, чтобы не нужно было как сейчас запускать alterator в чруте.
> Но установка grub и настройка пароля LUKS, как-то не OEM-но, а они выполняются в чрутном альтераторе.
> Да и пароль root может быть необходимо задать.
>
> Такое разделение облегчило бы переход на новый альтератор, количество необходимых модулей старого типа резко бы сократилось.
> Новый альтератор не нужно было бы запускать в инсталляторе.
>
> >> тогда установщик не нужен, мы развёртываем подготовленную rootfs
> > Это можно решить отдельно, но уже видна такая тенденция у коллег из других
> > дистрибутивов.
> >

Это очень интересная тема. Не кажется ли она более подходящей для:
- https://lists.altlinux.org/pipermail/devel-distro/ ?

В целом, по существу, я уверен в том, что использование механизмов не
выполняющихся "системно", а выполняющихся исключительно скриптах (или
копированием скриптов в /etc/firsttime.d/) в mkimage-profiles - не
очень хорошая идея.

На примере сервера я планирую постепенное изживание
installer-features-*, как механизмов несистемной, тонкой настройки,
более никакими методами не воспроизводимых и скрытых в недрах профиля
продукта. Их перенос в /etc/firsttime.d/ будет уже большой шаг вперед,
но всех необходимых задач это не решает. Например, развертывание
различных служб следует, всё-таки, переносить в контролируемые
администратором инструменты, а не в эвристику, результаты работы
которой администратору приходится потом вычищать вручную.

Ниже попытаюсь изложить минимальный концепт реализации этого плана:
1) вариативность установки и деталей, доступных в процессе
инсталляции, необходимо свести к минимуму;
2) выбор дополнительно устанавливаемых групп пакетов перенести в
постустановчный процесс;
3) все дополнительные настройки, исполняемые для дополнительно
устанавливаемых групп пакетов перенести в механизмы доступные штатно
через инструменты администрирования;
4) параметры настройки штатных механизмов перенести в системные файлы
настройки, редактируемые как вручную, так и через API на DBus;
5) модулям, применяющим системные настройки, предполагается
предоставить возможность чтения настроек без запуска службы DBus,
чтобы чтение и применение настроек могло выполняться даже в
ограниченном окружении в хешера (если это применимо, конечно).

______________

По поводу идеи с темой "ОЕМ при установке всегда" у меня есть
предложение предварительно выполнить следующий набор шагов:

1. Рассмотреть возможности Kickstart для того, чтобы отобрать перечень
уже существующих сценариев использования, которые могут быть у нас
реализованы:
- https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/

2. Оценить и осмыслить перечень всех ожидаемых и планируемых в
ближайшее время к реализации возможностей, которые мы хотим видеть в
первую очередь.

3. Выделить значимые задачи, для решения которых требуется функционал
ОЕМ-установки.

Хочу отметить, не я этот термин применил, что OEM означает "original
equipment manufacturer". Действительно ли мы тут обсуждаем механизм,
который означает оригинальное значение этой аббревиатуры? Ожидание от
него не в том, что можно будет автоматически установить Альт на
заданную железку, с заданными настройками, а в том, что внешний, по
отношению к нам производитель железки сможет, взяв базовый
установочный образ, сделать кастомную сборку под свою аппаратную
разработку. Легитимность и лицензионная чистота этого результата -
вопрос второй.

В-первую очередь, для внешнего аппаратного вендора стоит вопрос в том,
как завести его железку. А для этого, как правило, требуется
установить обновлённое, или даже кастомное, ядро (кто будет отвечать
за его сопровождение - это тоже второй вопрос).
Во-вторую очередь, внешний вендор ожидает возможность напихать своей
"блобятины" (firmware и драйверов, и, может быть, даже
"криптокостылей" и т.п.).

Всё это и нам полезно было бы для отладки и создания кастомных сборок.
Ставится ли так вопрос при проектировании ОЕМ-установки?


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] ОЕМ при установке всегда

[Leonid Krivoshein]

Всем привет!


On 5/26/24 02:06, Evgeny Sinelnikov wrote:
> Доброй ночи,
>
> пт, 19 апр. 2024 г. в 12:00, Антон Мидюков <midyukov-anton@ya.ru>:
>> 19.04.2024 14:50, Sergey V Turchin пишет:
>>> On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:
>>>
>>> [...]
>>>> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
>>>> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
>>>> загрузке (alterator-setup),
>>> Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после
>>> перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
>>> Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые
>>> настройки, которые делают installer-features-* и их надо запускать ещё раз, но
>>> никто этого не делает. При установке по сети достаточно будет закинуть какой-
>>> нибудь autoinstall-файл, по которому всё само сделается.
>>>
>> А всё от того, что надо запускать эти настройки из /etc/firsttime.d/
>> Перенести их надо, и всё будет работать правильно.
>>
>> Если уж и делить, то с той целью, чтобы не нужно было как сейчас запускать alterator в чруте.
>> Но установка grub и настройка пароля LUKS, как-то не OEM-но, а они выполняются в чрутном альтераторе.
>> Да и пароль root может быть необходимо задать.
>>
>> Такое разделение облегчило бы переход на новый альтератор, количество необходимых модулей старого типа резко бы сократилось.
>> Новый альтератор не нужно было бы запускать в инсталляторе.
>>
>>>> тогда установщик не нужен, мы развёртываем подготовленную rootfs
>>> Это можно решить отдельно, но уже видна такая тенденция у коллег из других
>>> дистрибутивов.
>>>
> Это очень интересная тема. Не кажется ли она более подходящей для:
> - https://lists.altlinux.org/pipermail/devel-distro/ ?

Да, наверное. Хотя, будущее инсталлятора может интересовать многих и в 
рассылке devel@.


> В целом, по существу, я уверен в том, что использование механизмов не
> выполняющихся "системно", а выполняющихся исключительно скриптах (или
> копированием скриптов в /etc/firsttime.d/) в mkimage-profiles - не
> очень хорошая идея.

Хорошо, что такой механизм уже есть. Он вроде как единственный, 
позволяющий выполнить предварительное развёртывание на "чужой" 
архитектуре. Например, мы можем распаковать систему на microSD, 
используя intel'овую машину, вставить эту microSD в какую-нибудь не 
intel'овую экзотику, где при первом включении будет выполнен postinstall.

Стоит сразу заметить, что даже при развёртывании на эту microSD не 
должны выполняться %post в RPM-пакетах, предназначенные для работы на 
целевой ("чужой") архитектуре. Заодно вспомнить про /_NEW_SYSTEM_ и 
$DURING_INSTALL.

Здесь же про воспроизводимость и тестирование: мы собрали образ на 
сборочнице, но никакие скрипты, включая %post в пакетах, предназначенные 
для работы на целевой архитектуре, раньше времени не должны выполняться. 
Они должны отработать только при первом запуске после развёртывания.


> На примере сервера я планирую постепенное изживание
> installer-features-*, как механизмов несистемной, тонкой настройки,
> более никакими методами не воспроизводимых и скрытых в недрах профиля
> продукта. Их перенос в /etc/firsttime.d/ будет уже большой шаг вперед,
> но всех необходимых задач это не решает. Например, развертывание
> различных служб следует, всё-таки, переносить в контролируемые
> администратором инструменты, а не в эвристику, результаты работы
> которой администратору приходится потом вычищать вручную.

Да, нынешние installer-features-* надо изживать во всех дистрибутивах, 
особенно *-stage3, и не только по названным причинам. Стоит подумать об 
их миграции в /etc/firsttime.d так, чтобы было системно, воспроизводимо, 
опакечено, в дальнейшем управляемо и изначально интегрировано с m-p.


> Ниже попытаюсь изложить минимальный концепт реализации этого плана:
> 1) вариативность установки и деталей, доступных в процессе
> инсталляции, необходимо свести к минимуму;
> 2) выбор дополнительно устанавливаемых групп пакетов перенести в
> постустановчный процесс;
> 3) все дополнительные настройки, исполняемые для дополнительно
> устанавливаемых групп пакетов перенести в механизмы доступные штатно
> через инструменты администрирования;
> 4) параметры настройки штатных механизмов перенести в системные файлы
> настройки, редактируемые как вручную, так и через API на DBus;
> 5) модулям, применяющим системные настройки, предполагается
> предоставить возможность чтения настроек без запуска службы DBus,
> чтобы чтение и применение настроек могло выполняться даже в
> ограниченном окружении в хешера (если это применимо, конечно).

А что, если доверить пост-конфигурирование какой-то существующей 
системе, типа salt или ansible? Меньше изобретать и допиливать, есть 
готовые веб-морда, документация, возможность управления большим парком 
машин. Просто, мысли вслух...


> ______________
>
> По поводу идеи с темой "ОЕМ при установке всегда" у меня есть
> предложение предварительно выполнить следующий набор шагов:
>
> 1. Рассмотреть возможности Kickstart для того, чтобы отобрать перечень
> уже существующих сценариев использования, которые могут быть у нас
> реализованы:
> - https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/

К слову, в make-initrd функционал разбивалки для stage1 с таким 
синтаксисом частично реализован: 
https://github.com/osboot/make-initrd/tree/master/features/kickstart , 
но до полной совместимости ещё далеко. Установщик должен уметь 
развёртывать систему по файлам ответов не задавая вопросов, он должен 
изначально под это проектироваться, и синтаксис должен быть удобным для 
этих целей.


> 2. Оценить и осмыслить перечень всех ожидаемых и планируемых в
> ближайшее время к реализации возможностей, которые мы хотим видеть в
> первую очередь.

Собственно, всё, что должно и может конфигурироваться при установке, то 
и нужно в первую очередь.


> 3. Выделить значимые задачи, для решения которых требуется функционал
> ОЕМ-установки.
>
> Хочу отметить, не я этот термин применил, что OEM означает "original
> equipment manufacturer". Действительно ли мы тут обсуждаем механизм,
> который означает оригинальное значение этой аббревиатуры? Ожидание от
> него не в том, что можно будет автоматически установить Альт на
> заданную железку, с заданными настройками, а в том, что внешний, по
> отношению к нам производитель железки сможет, взяв базовый
> установочный образ, сделать кастомную сборку под свою аппаратную
> разработку. Легитимность и лицензионная чистота этого результата -
> вопрос второй.
>
> В-первую очередь, для внешнего аппаратного вендора стоит вопрос в том,
> как завести его железку. А для этого, как правило, требуется
> установить обновлённое, или даже кастомное, ядро (кто будет отвечать
> за его сопровождение - это тоже второй вопрос).
> Во-вторую очередь, внешний вендор ожидает возможность напихать своей
> "блобятины" (firmware и драйверов, и, может быть, даже
> "криптокостылей" и т.п.).
>
> Всё это и нам полезно было бы для отладки и создания кастомных сборок.
> Ставится ли так вопрос при проектировании ОЕМ-установки?

Крайне неудачное название "OEM установка", вызывающее много слов.

Вот что на самом деле бывает (и нужно нам), это из разных областей:

1. Подсовывание диска с OEM-драйверами в процессе установки стандартного 
дистрибутива. Без него железо не увидится или не заработает правильно. 
Реализовано во всех дистрибутивах, начиная с Windows, ещё в середине 
90-х, было когда-то и у нас в пропагаторе, пока не прекратилась 
поддержка флоппи-дисков. Именно это и называют "OEM установкой".

2. Подготовка на заводе кастомного образа, при развёртывании с которого 
не придётся отвечать на разные вопросы. Данный процесс не подразумевает 
запихивание нужного функционала в установщик ОС. Напротив, система 
ставится штатным способом на эталонную машину. Производитель вносит в 
неё необходимые изменения. Например, системный интегратор может 
доустановить проприетарные пакеты, что-то донастроить. Затем эталонная 
система должна быть вычищена, запечатана, с неё снимается образ, 
пригодный для штатного установщика, и после развёртывания на целевое 
железо могут быть выполнены какие-то первые шаги приветствия, типа 
alterator-setup (опционально).

Запихнув "OEM установку" в инсталлятор, мы закрыли только часть 
потребностей, это редко востребованный кейс.


-- 
WBR, Leonid Krivoshein.

Re: [devel] ОЕМ при установке всегда

[Антон Мидюков]

26.05.2024 09:01, Leonid Krivoshein пишет:
> Всем привет!
> 
> 
> On 5/26/24 02:06, Evgeny Sinelnikov wrote:
>> Доброй ночи,
>>
>> пт, 19 апр. 2024 г. в 12:00, Антон Мидюков <midyukov-anton@ya.ru>:
>>> 19.04.2024 14:50, Sergey V Turchin пишет:
>>>> On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:
>>>>
>>>> [...]
>>>>> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
>>>>> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
>>>>> загрузке (alterator-setup),
>>>> Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после
>>>> перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
>>>> Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые
>>>> настройки, которые делают installer-features-* и их надо запускать ещё раз, но
>>>> никто этого не делает. При установке по сети достаточно будет закинуть какой-
>>>> нибудь autoinstall-файл, по которому всё само сделается.
>>>>
>>> А всё от того, что надо запускать эти настройки из /etc/firsttime.d/
>>> Перенести их надо, и всё будет работать правильно.
>>>
>>> Если уж и делить, то с той целью, чтобы не нужно было как сейчас запускать alterator в чруте.
>>> Но установка grub и настройка пароля LUKS, как-то не OEM-но, а они выполняются в чрутном альтераторе.
>>> Да и пароль root может быть необходимо задать.
>>>
>>> Такое разделение облегчило бы переход на новый альтератор, количество необходимых модулей старого типа резко бы сократилось.
>>> Новый альтератор не нужно было бы запускать в инсталляторе.
>>>
>>>>> тогда установщик не нужен, мы развёртываем подготовленную rootfs
>>>> Это можно решить отдельно, но уже видна такая тенденция у коллег из других
>>>> дистрибутивов.
>>>>
>> Это очень интересная тема. Не кажется ли она более подходящей для:
>> - https://lists.altlinux.org/pipermail/devel-distro/ ?
> 
> Да, наверное. Хотя, будущее инсталлятора может интересовать многих и в рассылке devel@.
> 
> 
>> В целом, по существу, я уверен в том, что использование механизмов не
>> выполняющихся "системно", а выполняющихся исключительно скриптах (или
>> копированием скриптов в /etc/firsttime.d/) в mkimage-profiles - не
>> очень хорошая идея.
> 
> Хорошо, что такой механизм уже есть. Он вроде как единственный, позволяющий выполнить предварительное развёртывание на "чужой" архитектуре. Например, мы можем распаковать систему на microSD, используя intel'овую машину, вставить эту microSD в какую-нибудь не intel'овую экзотику, где при первом включении будет выполнен postinstall.
> 
> Стоит сразу заметить, что даже при развёртывании на эту microSD не должны выполняться %post в RPM-пакетах, предназначенные для работы на целевой ("чужой") архитектуре. Заодно вспомнить про /_NEW_SYSTEM_ и $DURING_INSTALL.

Если не будет необходимости на этапе установки выбирать разный набор пакетов, то можно собирать тарбол с rootfs и устанавливать его.

> 
> Здесь же про воспроизводимость и тестирование: мы собрали образ на сборочнице, но никакие скрипты, включая %post в пакетах, предназначенные для работы на целевой архитектуре, раньше времени не должны выполняться. Они должны отработать только при первом запуске после развёртывания.

Не понимаю я этого. Зачем? При сборке rootfs мы всё в hasher ставим, скрипты отрабатывают на нативной архитектуре.

> 
> 
>> На примере сервера я планирую постепенное изживание
>> installer-features-*, как механизмов несистемной, тонкой настройки,
>> более никакими методами не воспроизводимых и скрытых в недрах профиля
>> продукта. Их перенос в /etc/firsttime.d/ будет уже большой шаг вперед,
>> но всех необходимых задач это не решает. Например, развертывание
>> различных служб следует, всё-таки, переносить в контролируемые
>> администратором инструменты, а не в эвристику, результаты работы
>> которой администратору приходится потом вычищать вручную.
> 
> Да, нынешние installer-features-* надо изживать во всех дистрибутивах, особенно *-stage3, и не только по названным причинам. Стоит подумать об их миграции в /etc/firsttime.d так, чтобы было системно, воспроизводимо, опакечено, в дальнейшем управляемо и изначально интегрировано с m-p.

Никакой интеграции с m-p не требуется. Просто опакетить в /etc/firsttime.d и добавить пакеты в сборочный профиль.

> 
> 
>> Ниже попытаюсь изложить минимальный концепт реализации этого плана:
>> 1) вариативность установки и деталей, доступных в процессе
>> инсталляции, необходимо свести к минимуму;
>> 2) выбор дополнительно устанавливаемых групп пакетов перенести в
>> постустановчный процесс;

Это и сейчас поддерживается. Можно собрать rootfs с целью use/oem/install.

>> 3) все дополнительные настройки, исполняемые для дополнительно
>> устанавливаемых групп пакетов перенести в механизмы доступные штатно
>> через инструменты администрирования;
>> 4) параметры настройки штатных механизмов перенести в системные файлы
>> настройки, редактируемые как вручную, так и через API на DBus;
>> 5) модулям, применяющим системные настройки, предполагается
>> предоставить возможность чтения настроек без запуска службы DBus,
>> чтобы чтение и применение настроек могло выполняться даже в
>> ограниченном окружении в хешера (если это применимо, конечно).
> 
> А что, если доверить пост-конфигурирование какой-то существующей системе, типа salt или ansible? Меньше изобретать и допиливать, есть готовые веб-морда, документация, возможность управления большим парком машин. Просто, мысли вслух...
> 
> 
>> ______________
>>
>> По поводу идеи с темой "ОЕМ при установке всегда" у меня есть
>> предложение предварительно выполнить следующий набор шагов:
>>
>> 1. Рассмотреть возможности Kickstart для того, чтобы отобрать перечень
>> уже существующих сценариев использования, которые могут быть у нас
>> реализованы:
>> - https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/
> 
> К слову, в make-initrd функционал разбивалки для stage1 с таким синтаксисом частично реализован: https://github.com/osboot/make-initrd/tree/master/features/kickstart , но до полной совместимости ещё далеко. Установщик должен уметь развёртывать систему по файлам ответов не задавая вопросов, он должен изначально под это проектироваться, и синтаксис должен быть удобным для этих целей.
> 
> 
>> 2. Оценить и осмыслить перечень всех ожидаемых и планируемых в
>> ближайшее время к реализации возможностей, которые мы хотим видеть в
>> первую очередь.
> 
> Собственно, всё, что должно и может конфигурироваться при установке, то и нужно в первую очередь.
> 
> 
>> 3. Выделить значимые задачи, для решения которых требуется функционал
>> ОЕМ-установки.
>>
>> Хочу отметить, не я этот термин применил, что OEM означает "original
>> equipment manufacturer". Действительно ли мы тут обсуждаем механизм,
>> который означает оригинальное значение этой аббревиатуры? Ожидание от
>> него не в том, что можно будет автоматически установить Альт на
>> заданную железку, с заданными настройками, а в том, что внешний, по
>> отношению к нам производитель железки сможет, взяв базовый
>> установочный образ, сделать кастомную сборку под свою аппаратную
>> разработку. Легитимность и лицензионная чистота этого результата -
>> вопрос второй.
>>
>> В-первую очередь, для внешнего аппаратного вендора стоит вопрос в том,
>> как завести его железку. А для этого, как правило, требуется
>> установить обновлённое, или даже кастомное, ядро (кто будет отвечать
>> за его сопровождение - это тоже второй вопрос).
>> Во-вторую очередь, внешний вендор ожидает возможность напихать своей
>> "блобятины" (firmware и драйверов, и, может быть, даже
>> "криптокостылей" и т.п.).
>>
>> Всё это и нам полезно было бы для отладки и создания кастомных сборок.
>> Ставится ли так вопрос при проектировании ОЕМ-установки?
> 
> Крайне неудачное название "OEM установка", вызывающее много слов.

Предустановка.

> 
> Вот что на самом деле бывает (и нужно нам), это из разных областей:
> 
> 1. Подсовывание диска с OEM-драйверами в процессе установки стандартного дистрибутива. Без него железо не увидится или не заработает правильно. Реализовано во всех дистрибутивах, начиная с Windows, ещё в середине 90-х, было когда-то и у нас в пропагаторе, пока не прекратилась поддержка флоппи-дисков. Именно это и называют "OEM установкой".
> 
> 2. Подготовка на заводе кастомного образа, при развёртывании с которого не придётся отвечать на разные вопросы. Данный процесс не подразумевает запихивание нужного функционала в установщик ОС. Напротив, система ставится штатным способом на эталонную машину. Производитель вносит в неё необходимые изменения. Например, системный интегратор может доустановить проприетарные пакеты, что-то донастроить. Затем эталонная система должна быть вычищена, запечатана, с неё снимается образ, пригодный для штатного установщика, и после развёртывания на целевое железо могут быть выполнены какие-то первые шаги приветствия, типа alterator-setup (опционально).
> 
> Запихнув "OEM установку" в инсталлятор, мы закрыли только часть потребностей, это редко востребованный кейс.
> 

Вообще-то она позволяет установить систему в виртуалку с универсальным initrd, донастроить систему (нужно убрать параметр загрузки systemd.unit=setup.target), после чего можно упаковать в тарбол и развёртывать.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] ОЕМ при установке всегда

[Alexey Gladkov]

On Sun, May 26, 2024 at 05:01:36AM +0300, Leonid Krivoshein wrote:
> > По поводу идеи с темой "ОЕМ при установке всегда" у меня есть
> > предложение предварительно выполнить следующий набор шагов:
> >
> > 1. Рассмотреть возможности Kickstart для того, чтобы отобрать перечень
> > уже существующих сценариев использования, которые могут быть у нас
> > реализованы:
> > - https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/

Я совсем не в контексте треда и безусловно вам виднее что и как делать.

> К слову, в make-initrd функционал разбивалки для stage1 с таким 
> синтаксисом частично реализован: 
> https://github.com/osboot/make-initrd/tree/master/features/kickstart , 
> но до полной совместимости ещё далеко.

Я намеренно не стал реализовывать всё, а сделал только необходимую _мне_
(моим тестам) часть кикстартера. По поводу совместимости, ту часть,
которая реализована я тестировал на сохранившихся у меня со старой работы
kickstart-файлах для родной анаконды.

Остальную часть в каких-то случаях реализовать просто, в каких-то довольно
трудозатратно.

> Установщик должен уметь развёртывать систему по файлам ответов не
> задавая вопросов, он должен изначально под это проектироваться, и
> синтаксис должен быть удобным для этих целей.

Когда-то мы со Стасом Иевлевым пытались продвинуть эту идею в реализации
инсталлятора, но не получилось по не техническим причинам.

Я написал фичу kickstarter на основе тогдашних набросков для инсталлятора.

P.S. Пишу тебе лично т.к. потерял возможность писать что-либо с альтового
адреса и в рассылку написать не могу. Извини.

-- 
Rgrds, legion