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

[Evgeny Sinelnikov <sin@altlinux.org>]

пт, 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_CONTROLLED=yes в
options и некорректно отображает состояние настройки.

Таким образом получаем странную коллизию:
- если мы включаем в Альтераторе вариант "Сетевая подсистема:
NetworkManager", то NetworkManager'у не разрешается изменять настройки
интерфейса;
- а если удаляем эти настройки (то есть весь каталог
/etc/net/ifaces/$IFACENAME вместе с файлом NM_CONTROLLED=yes и
DISABLED=yes, чтобы интерфейсы не дублировались), то NetworkManager
начинает работать так, как ожидается, но при этом в Альтераторе
указано, что включен etcnet.

Правда, беглый тест выявил ещё одну особенность. Возврат к
NetworkManager через Alterator не ломает поведения...
То есть дело не просто в наличии или отсутствии каталога
/etc/net/ifaces/$IFACENAME.

Замечено, что после "чистой" установки options файл интерфейса выглядит так:
BOOTPROTO=dhcp
TYPE=eth
NM_CONTROLLED=yes
DISABLED=yes
CONFIG_WIRELESS=no
CONFIG_IPV4=yes

А после его удаления и создания заново через Альтератор в режим
"Сетевая подсистема: NetworkManager" выглядит так:
TYPE=eth
CONFIG_WIRELESS=no
BOOTPROTO=static
CONFIG_IPV4=yes
DISABLED=yes
NM_CONTROLLED=yes
ONBOOT=yes

Казалось бы, что могло повлиять? Возможно, ONBOOT=yes? Нет. Влияет
BOOTPROTO=static.

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

Гибридную схему при этом, да и при установке тоже, никто не просил. И
как её отключить родными средствами - непонятно. Удалять каталог
/etc/net/ifaces/$IFACENAME - дело нехорошее. Я-то теперь буду
пользоваться. Но как пользователям быть? У нас есть GUI, но чтобы всё
заработало из коробки нужно лезть в консоль.
_________________

Итого, удалять /etc/net/ifaces/$IFACENAME, чтобы отключить гибридную
схему вовсе не обязательно, достаточно:
- установить BOOTPROTO=static
- удалить файл /etc/net/ifaces/$IFACENAME/ipv4address

И это отличный сайд-эффект текущей реализации. Его можно использовать
таким образом, чтобы включать NetworkManager через альтератор. Для
этого достаточно отключать гибридную схему, если она явно не задана.
То есть, при переключении на NetworkManager ставить static и удалять
ipv4address.

Я, пожалуй, попробую сделать соответствующие правки для
alterator-net-eth, чтобы предложить решение данной проблемы.

>   Если же пользователю захочется etcnet или сочетания etcnet и NM, то
> тогда он сам решит, что делать с дублирующимися настройками (убрать NM
> или использовать read-only отображение etcnet в NM).

Пользователю, в большем количестве случаев, не нужно ни то, ни другое.
Ни etcnet, ни сочетание etcnet и NM. Ему хочется определённости. Если
включен NetworkManager, если NetworkManager что-то умеет (например,
получать IP по DHCP, а NAMESERVER задавать вручную), то нужно, чтобы
эта возможность была доступна. И чтобы эта возможность включалась и
отключалась штатными средствами - через Альтератор.

Честно говоря, у "гибридного варианта" поведение совершенно не
определённое. То ли так получится, то ли эдак.  На практике такой
вариант никто не посоветует.

>   По-моему так.

Главное, что из коробки это не так. И привести поведение к ожидаемому
штатными средствами не предусмотрено. Но теперь это можно
предусмотреть.

> > BOOTPROTO=dhcp
> > TYPE=eth
> > NM_CONTROLLED=yes
> > DISABLED=yes
> > CONFIG_WIRELESS=no
> > CONFIG_IPV4=yes
> >
> > При этом NetworkManager запущен, но редактировать настройки через него
> > невозможно, потому что плагин etcnet-alt это запрещает.
> >
> > Задача, при этом выглядит так:
> > - нужно оставить в получение ip по DHCP, но задать при этом другой
> > nameserver.
> >
> > Если возможно (а этот простой кейс вполне допустим), то почему такая
> > возможность отключена по умолчанию?
> >
> > Если для этого нужно переключиться в etcnet, то зачем это включено по
> > умолчанию?
> >
> > По этому поводу я завёл багу:
> > https://bugzilla.altlinux.org/show_bug.cgi?id=38455

-- 
Sin (Sinelnikov Evgeny)