* [devel] подсистема настройки сети в дистрибутивах
@ 2024-04-17 17:21 Alexey Shabalin
2024-04-17 18:02 ` [devel] netplan (was: подсистема настройки сети в дистрибутивах) Arseny Maslennikov
` (4 more replies)
0 siblings, 5 replies; 14+ messages in thread
From: Alexey Shabalin @ 2024-04-17 17:21 UTC (permalink / raw)
To: ALT Linux Team development discussions
День добрый.
Хочу поднять обсуждение о подсистеме настройки сети в наших дистрибутивах.
Ситуация сейчас следующая:
- в рабочей станции и других дистрибутивах с 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [devel] netplan (was: подсистема настройки сети в дистрибутивах)
2024-04-17 17:21 [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
@ 2024-04-17 18:02 ` Arseny Maslennikov
2024-04-17 18:52 ` Alexey Shabalin
2024-04-17 18:39 ` [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
` (3 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Arseny Maslennikov @ 2024-04-17 18:02 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-17 17:21 [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
2024-04-17 18:02 ` [devel] netplan (was: подсистема настройки сети в дистрибутивах) Arseny Maslennikov
@ 2024-04-17 18:39 ` Alexey Shabalin
2024-04-18 2:15 ` Антон Мидюков
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Alexey Shabalin @ 2024-04-17 18:39 UTC (permalink / raw)
To: ALT Linux Team development discussions
ср, 17 апр. 2024 г. в 20:21, Alexey Shabalin <a.shabalin@gmail.com>:
> - один конфигурационный файл, нет нужды править множество кофигов.
> (хотя yaml для кого-то может быть минусом)
Тут я ошибся. Обрабатываются
- /run/netplan/*.yaml
- /etc/netplan/*.yaml
- /lib/netplan/*.yaml
--
Alexey Shabalin
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] netplan (was: подсистема настройки сети в дистрибутивах)
2024-04-17 18:02 ` [devel] netplan (was: подсистема настройки сети в дистрибутивах) Arseny Maslennikov
@ 2024-04-17 18:52 ` Alexey Shabalin
0 siblings, 0 replies; 14+ messages in thread
From: Alexey Shabalin @ 2024-04-17 18:52 UTC (permalink / raw)
To: ALT Linux Team development discussions
ср, 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-17 17:21 [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
2024-04-17 18:02 ` [devel] netplan (was: подсистема настройки сети в дистрибутивах) Arseny Maslennikov
2024-04-17 18:39 ` [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
@ 2024-04-18 2:15 ` Антон Мидюков
2024-04-18 9:17 ` Alexey V. Vissarionov
2024-04-18 18:51 ` Leonid Krivoshein
4 siblings, 0 replies; 14+ messages in thread
From: Антон Мидюков @ 2024-04-18 2:15 UTC (permalink / raw)
To: 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>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-17 17:21 [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
` (2 preceding siblings ...)
2024-04-18 2:15 ` Антон Мидюков
@ 2024-04-18 9:17 ` Alexey V. Vissarionov
2024-04-18 15:04 ` Alexey Shabalin
2024-04-18 18:51 ` Leonid Krivoshein
4 siblings, 1 reply; 14+ messages in thread
From: Alexey V. Vissarionov @ 2024-04-18 9:17 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-18 9:17 ` Alexey V. Vissarionov
@ 2024-04-18 15:04 ` Alexey Shabalin
2024-04-19 3:19 ` Anton Farygin
2024-04-19 4:52 ` Alexey V. Vissarionov
0 siblings, 2 replies; 14+ messages in thread
From: Alexey Shabalin @ 2024-04-18 15:04 UTC (permalink / raw)
To: ALT Linux Team development discussions
чт, 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-17 17:21 [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
` (3 preceding siblings ...)
2024-04-18 9:17 ` Alexey V. Vissarionov
@ 2024-04-18 18:51 ` Leonid Krivoshein
2024-04-19 0:29 ` Антон Мидюков
2024-04-19 7:50 ` [devel] ОЕМ при установке всегда (was: подсистема настройки сети в дистрибутивах) Sergey V Turchin
4 siblings, 2 replies; 14+ messages in thread
From: Leonid Krivoshein @ 2024-04-18 18:51 UTC (permalink / raw)
To: devel
Добрый день!
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-18 18:51 ` Leonid Krivoshein
@ 2024-04-19 0:29 ` Антон Мидюков
2024-04-19 11:32 ` Leonid Krivoshein
2024-04-19 7:50 ` [devel] ОЕМ при установке всегда (was: подсистема настройки сети в дистрибутивах) Sergey V Turchin
1 sibling, 1 reply; 14+ messages in thread
From: Антон Мидюков @ 2024-04-19 0:29 UTC (permalink / raw)
To: 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>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-18 15:04 ` Alexey Shabalin
@ 2024-04-19 3:19 ` Anton Farygin
2024-04-19 4:52 ` Alexey V. Vissarionov
1 sibling, 0 replies; 14+ messages in thread
From: Anton Farygin @ 2024-04-19 3:19 UTC (permalink / raw)
To: devel
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 я отказался именно потому что он
не смог.
Оборудование иметь хорошо, но часто бывают ситуации, когда дома его
банально нет, а сложный конфиг нужен.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-18 15:04 ` Alexey Shabalin
2024-04-19 3:19 ` Anton Farygin
@ 2024-04-19 4:52 ` Alexey V. Vissarionov
1 sibling, 0 replies; 14+ messages in thread
From: Alexey V. Vissarionov @ 2024-04-19 4:52 UTC (permalink / raw)
To: ALT Linux Team development discussions; +Cc: gremlin
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [devel] ОЕМ при установке всегда (was: подсистема настройки сети в дистрибутивах)
2024-04-18 18:51 ` Leonid Krivoshein
2024-04-19 0:29 ` Антон Мидюков
@ 2024-04-19 7:50 ` Sergey V Turchin
2024-04-19 8:00 ` [devel] ОЕМ при установке всегда Антон Мидюков
1 sibling, 1 reply; 14+ messages in thread
From: Sergey V Turchin @ 2024-04-19 7:50 UTC (permalink / raw)
To: ALT Linux Team development discussions
On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:
[...]
> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
> загрузке (alterator-setup),
Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после
перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые
настройки, которые делают installer-features-* и их надо запускать ещё раз, но
никто этого не делает. При установке по сети достаточно будет закинуть какой-
нибудь autoinstall-файл, по которому всё само сделается.
> тогда установщик не нужен, мы развёртываем подготовленную rootfs
Это можно решить отдельно, но уже видна такая тенденция у коллег из других
дистрибутивов.
[...]
--
Regards, Sergey.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] ОЕМ при установке всегда
2024-04-19 7:50 ` [devel] ОЕМ при установке всегда (was: подсистема настройки сети в дистрибутивах) Sergey V Turchin
@ 2024-04-19 8:00 ` Антон Мидюков
0 siblings, 0 replies; 14+ messages in thread
From: Антон Мидюков @ 2024-04-19 8:00 UTC (permalink / raw)
To: 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>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] подсистема настройки сети в дистрибутивах
2024-04-19 0:29 ` Антон Мидюков
@ 2024-04-19 11:32 ` Leonid Krivoshein
0 siblings, 0 replies; 14+ messages in thread
From: Leonid Krivoshein @ 2024-04-19 11:32 UTC (permalink / raw)
To: devel
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-04-19 11:32 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-17 17:21 [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
2024-04-17 18:02 ` [devel] netplan (was: подсистема настройки сети в дистрибутивах) Arseny Maslennikov
2024-04-17 18:52 ` Alexey Shabalin
2024-04-17 18:39 ` [devel] подсистема настройки сети в дистрибутивах Alexey Shabalin
2024-04-18 2:15 ` Антон Мидюков
2024-04-18 9:17 ` Alexey V. Vissarionov
2024-04-18 15:04 ` Alexey Shabalin
2024-04-19 3:19 ` Anton Farygin
2024-04-19 4:52 ` Alexey V. Vissarionov
2024-04-18 18:51 ` Leonid Krivoshein
2024-04-19 0:29 ` Антон Мидюков
2024-04-19 11:32 ` Leonid Krivoshein
2024-04-19 7:50 ` [devel] ОЕМ при установке всегда (was: подсистема настройки сети в дистрибутивах) Sergey V Turchin
2024-04-19 8:00 ` [devel] ОЕМ при установке всегда Антон Мидюков
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git