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

[Alexey Shabalin <a.shabalin@gmail.com>]

чт, 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