Re: [devel] NetworkManager и пользовательские настройки по умолчанию

[Evgeny Sinelnikov <sin@altlinux.org>]

пт, 8 мая 2020 г. в 17:21, Mikhail Efremov <sem@altlinux.org>:
>
> On Fri, 8 May 2020 07:09:58 +0400 Evgeny Sinelnikov wrote:
> > пт, 8 мая 2020 г. в 00:57, Paul Wolneykien <manowar@altlinux.org>:
> >
> > > В Fri, 8 May 2020 00:46:35 +0400
> > > Evgeny Sinelnikov <sin@altlinux.org> пишет:
> > >
> > > > Здравствуйте.
> > > >
> > > > Я прочитал багу, но не понял как решать проблему:
> > > > https://bugzilla.altlinux.org/show_bug.cgi?id=18795
> > > > https://www.altlinux.org/NetworkManager/feature
> > > >
> > > > Хочу разобраться с вопросом настройки сетевых соединений через
> > > > NetworkManager. Какой сценарий предлагается пользователю по
> > > > умолчанию?
> > > >
> > > > По умолчанию, после установки, в /etc/net/ifaces/eth0 имеем
> > > > настройки:
> > >
> > >   Думаю, что бага ровно в этом и состоит: в том, что в свежей
> > > установке имеем /etc/net/ifaces/eth0. Потому что даже в
> > > документации по etcnet-alt сказано, что он придуман потому, что
> > > "если уже есть настройки в etcnet — нет смысла настраивать все это
> > > еще раз". То есть плагин решает задачу дедупликации настроек, когда
> > > в одном месте эти настройки уже есть.
> > >   Следовательно, если убрать /etc/net/ifaces/eth0 из свежей
> > > установки, то у пользователя будет чистый NM, а данной проблемы не
> > > будет.
> >
> > Да, действительно. В таком виде поведение именно такое, как ожидается.
> >
> > Таким образом, для интерфейса включается NM, то каталог
> > /etc/net/ifaces/$IFACENAME должен быть удалён.
>
> При этом сети нет во время загрузки со всеми вытекающими. Потому что
> соединение в NM можно создать только после загрузки.
> Тогда надо вообще убрать шаг настройки сети из инсталлятора т.к.
> в этом случае это не настройка, а профанация.

Интересный момент. В моих тестах это не учитывалось, я удалял каталог
и перезапускал NM. Сетевое соединение перезапускалось.

При этом каталог /etc/net/ifaces/$IFACENAME уже отсутствовал, а
соединение "System $IFACENAME" оставалось. Но, если каталог интерфейса
удалить, то после перезагрузки этот сайд-эффект пропадает.

То есть, при отсутстввии файла options, где указано
NM_CONTROLLED=yes
DISABLED=yes
во время загрузки сети не будет. Причём ровно до того момента пока
пользователь не ткнёт в интерфейсе в соединение и не укажет явно, что
это соединение должно быть включено.

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


Понятно, но это только часть варианта настройки. Кстати, от идеи
"удалять /etc/net/ifaces/$IFACENAME" я тоже сразу отказался в этом же
рассуждении ниже. Но несколько по другой причине. Необходимо, чтобы
- возможность настройки была доступна через UI (я имею в виду
alterator control center - acc), а удаление всего каталога интерфейса
для пользовательских нужд в нём не предусмотрено;
- состояние настройки (Сетевая подсистема: Network Manager) корректно
определелялось и отображалось через UI (если удалить
/etc/net/ifaces/$IFACENAME, то определение не работает).

Так что это ещё один гвоздь к первому варианту, который был предложен.
Правда тут стоит отметить, что это рабочий вариант для сценария в
котором пользователь отказывается использовать Альтератор для
настройки сети. И не стоит этот вариант сбрасывать со счетов, если не
будет найден системный, решающий ту же задачу.

Какую задачу? Повторюсь. Задача выглядит так:
- IP получаем через DHCP;
- NAMESERVER задаём вручную;
- все действия осуществляем через UI (Альтератор, NetworkManager, ...
как угодно, но желательно так же просто, как в родном варианте с
NetworkManager без интеграции с etcnet).

Сейчас как это сделать - непонятно. Непонятно и почему не
предусмотрено никагого вариант через Etcnet и никакого простого
варианта решения для переключения к NetworkManager. Весь абсурд
состоит в том, что он как бы включен, но перейти к настройкам нельзя и
что делать - непонятно. Догадаться невозможно, а настроек в
Альтераторе недостаточно.

Первый предложенный вариант "догадаться" выглядит так:
- удалить каталог интерфейса в /etc/net/ifaces (для этого нужно знать
что он существует, как его удалить, и иметь для этого основания);
- перезагрузить NetworkManager;
- настроить интерфейс через NetworkManager;
- а потом не пугаться того, что Альтератор показывает, что для данного
интерфейса включен etcnet. И понимать, что он так пишет не потому, что
так настроено, а потому, что настройки отсутствуют.

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

> > Но тут возникает одна
> > важная нестыковка: Модуль Альтератора, управляющий сетевыми
> > интефейсами, в этом случае, не находит записи NM_CONTROLLED=yes в
> > options и некорректно отображает состояние настройки.
>
> Это можно пофиксить. Плагин NM etcnet-alt работает так: нет файла
> options для интерфейса - управляем интерфейсом. Есть файл и там не
> написано NM_CONTROLLED=yes - не управляем.

Да, это понятно, что он так работает. И да, конечно, нужно пофиксить.
А как это предлагается "пофиксить"? Я имею виду alterator-net-eth. В
этом же нестыковка. Логика NM etcnet-alt одна, а alterator-net-eth ей
не соответствует. Ведь в нём нужно предусмотреть разные варианты.

Если каталог интерфейса отсутствует, а интерфейс обнаружен, то это ещё
не значит, то он управляется через NM. Это значит, что он не
управляется через etcnet. А управляться он может, например,
systemd-networkd.

Ну, то есть, "фиксить" этот UI нужно с двух сторон: со стороны
отображения и со стороны "угадывания". Ну, и, наверное, это не тот
случай, когда сложная эвристика стоит больших усилий.


> > Казалось бы, что могло повлиять? Возможно, ONBOOT=yes? Нет. Влияет
> > BOOTPROTO=static.
>
> Плагин пытается прочитать соединение из /etc/net, BOOTPROTO=dhcp уже
> достаточно. В случае BOOTPROTO=static нужен еще как минимум адрес в
> ipv4address, разумеется.
> ONBOOT указывает будет ли соединение использоваться автоматически.
>
> > Я не знаю что здесь не соответствует задумке и где тут бага, а где
> > фича (наверное, это бага, если по задумке)... Но в режиме
> > BOOTPROTO=static при отсутствии файла
> > /etc/net/ifaces/$IFACENAME/ipv4address всё работает, как надо
> > пользователю. Мы включили в Альтераторе "Сетевая подсистема:
> > NetworkManager" и, как ожидается, у нас всё работает, через
> > NetworkManger.
>
> "Как надо пользователю" - это чтобы сеть была не настроена? Я в этом
> совсем не уверен.

Действительно, с точки зрения NM c нашим плагином, вариант
BOOTPROTO=static
NM_CONTROLLED=yes
DISABLED=yes
при отсутствующем файле /etc/net/ifaces/$IFACENAME/ipv4address
ведёт себя так, будто соединение через плагин не управляется (ну,
потому что настройки не были найдены).

Хотя при этом всё выглядит немного лучше:
- Интерфейсом через NM управлять можно;
- Альтератор показывает, что Сетевая подсистема: Netwotk Manager.

Но, действительно... Остаётся всё та же проблема. Если всё так
включить, оставить и перезагрузить, то сети не будет. А если сразу
после этого, до перезагрузки, зайти в настройки NM и включить
проводное соединение, то всё подключиться и успешно сохраниться и
после перезагрузки.

Если зафиксировать состояние более формально, то это выглядит так:
- указываем для интерфейса в options:
BOOTPROTO=static
NM_CONTROLLED=yes
DISABLED=yes
- удаляем файл /etc/net/ifaces/$IFACENAME/ipv4address
- перезапускаем NetworkManager
- выполняем команду:
nmcli connection add ethernet ifname $IFACENAME


> > Гибридную схему при этом, да и при установке тоже, никто не просил. И
> > как её отключить родными средствами - непонятно. Удалять каталог
> > /etc/net/ifaces/$IFACENAME - дело нехорошее. Я-то теперь буду
> > пользоваться. Но как пользователям быть? У нас есть GUI, но чтобы всё
> > заработало из коробки нужно лезть в консоль.
>
> Я не понимаю зачем лезть в консоль.
> Все просто: штатное средство настройки сети у нас - alterator-net-eth
> (в том числе и в инсталляторе). Alterator-net-eth умеет настраивать
> сеть в /etc/net. NM умеет этими настройками пользоваться (с помощью
> плагина etcnet-alt). Но да, эти соединения read-only, редактировать их
> плагин не умеет. Если нужно их изменить - нужно использовать
> alterator-net-eth. Если хочется, чтобы сеть была не настроена, как вы
> предлагаете, достаточно в alterator-net-eth указать static и не
> настраивать.

etcnet нужный вариант настроек не умеет совсем.

Я несколько раз повторил задачу. etcnet так, как надо это не умеет (да
даже если бы и умел - вопрос шире, но в данном случае не умеет):
- IP получаем через DHCP;
- NAMESERVER задаём вручную;
- все действия осуществляем через UI (Альтератор).

Такой сценарий на текущий момент неосуществим. Если явно переключиться
в режим dhcp, то потом задать nameserver уже не получится (не важно,
включить для etcnet и NetworkManager) - все поля в alterator-net-eth
будут отключены.

Но, если после этого вручную создать в каталоге
/etc/net/ifaces/$IFACENAME/ файл resolv.conf, то после перезагрузки
сети можно получить ожидаемый эффект. А можно и не получить. Всё
зависит от порядка следования настроек, которые при таком варианте
смешиваются, а не заменяются. В некоторых случаях помогает прописать
resolv.conf для интерфейса /etc/net/ifaces/lo, но после перезагрузки
он в некоторых конфигурацях не подхватывается.

Тут моментов два:
- при попытке переключения между подсистемами (Etcnet или Network
Manager) файл /etc/net/ifaces/$IFACENAME/resolv.conf будет удаляться и
его придётся каждый раз пересоздавать.
- в зависимости от того, какая выбрана подсистема, порядок следования
DNS-серверов (записей nameserver в /etc/resolv.conf) будет разным:
  + если выбран Network Manager, то запись будет в конце и такой
вариант не подходит;
  + если выбран Etcnet, то запись будет в начале и такой вариант уже подходит.

Но с Etcnet ещё всё. Нужен же dhcp. А его нужно уметь переподключать.
И тут есть такие проблемы:
- etcnet с включенным dhcp на клиенте не отработает сценарий - кабель
ethernet отключен, машина загрузилась (потупила на старте dhcp к тому
же), а потом кабель включили;
- etcnet с включенным dhcp не повзолит пользователю перезапустить
сеть, если dhcp отвалится в процессе.
В etcnet для таких задач предусмотрена интеграция с ifplugd, но  и там
граблей хватает. К тому же этот вариант не предусмотрен для настройки
в Альтераторе.
- если включен etcnet, то в плагине NetworkManager'а невозможно
посмотреть настройки сети для данного интерфейса (и как предлагается
это делать пользователю? смотреть вывод ip a в консоли?).

Таким образом получаем, что:
- через UI (Альтератор) необходимый сценарий неосуществим;
- ручной вариант работает иногда, и то только через Etcnet;
- переключение же на Еtcnet приводит к тому, что отвалившийся на
клиенте dhcp нужно идти и руками перезапускать;
- отображение состояния сети в плагине NetworkManager'а, после
переключения на Etcnet, теряется.

В совокупности получаем множество неочевидных проблем и множество
нерабочих сценариев. И я не понимаю, почему для этих сценариев нельзя
предусмотреть вариант работы NeworkManager в нативном режиме.

> В принципе, можно обучить alterator-net-eth создавать соединения для NM
> и вообще выкинуть плагин etcnet-alt. Правда, потеряется возможность
> указывать NM_CONTROLLED для интерфейсов, можно будет только глобально
> выбрать либо всей сетью управляет NM, либо etcnet. И все настройки в
> etcnet будут теряться при переключении на NM.

Я предлагаю такой вариант, который потребует минимума усилий -
поправить нужно alterator-net-eth таким образом:

Вместо вариантов подсистем:
- Etcnet
- NetworkManager
- Не контролируется

Задаются варианты:
- Etcnet
- NetworkManager (etcnet)
- NetworkManager (native)
- Не контролируется

В случае NetworkManager (native)
- в options задаются:
BOOTPROTO=static
NM_CONTROLLED=yes
DISABLED=yes
- Файл /etc/net/ifaces/$IFACENAME/ipv4address удаляется
- дополнительно можно предусмотреть команду (но это уже не обязательно):
nmcli connection add ethernet ifname $IFACENAME

В случае NetworkManager (etcnet)
- в options задаются:
NM_CONTROLLED=yes
DISABLED=yes
- если BOOTPROTO=static задано, то файл
/etc/net/ifaces/$IFACENAME/ipv4address создаётся.

Остальное, как обычно.

_______________

Второе дополнение, с этим малосвязное - добавить нужный "кейс" в
alterator-net-eth. Не в качестве единственной замены NetworkManager в
нативном режиме, а в качестве рабочей системной альтернативы в режимах
Etcnet и NetworkManager (etcnet).

Для этого, при включении режима dhcp нужно предусмотреть
дополнительный вариант Конфигурации.

К вариантам:
- Использовать DHCP
- Использовать Zeroconf
- Вручную

Нужно добавить один или несколько дополнительных вариантов:
- Использовать DHCP, только адрес (хороший вариант - непонятно как его
обеспечить - значения серверов имён у нам смешиваются средствами
openresolv - но, наверное, это возможно);
- Использовать DHCP, задать основной сервер имён (в этом случае
разумно, что настройки DNS смешиваются - но тут нужно починить всё
так, чтобы заданный сервер имён был первым, а не последним);
- ...
При этом настройки DNS остаются доступными для модификации.


--
Sin (Sinelnikov Evgeny)