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