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

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

[Paul Wolneykien]

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

> 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

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

[Evgeny Sinelnikov]

пт, 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)

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

[Mikhail Efremov]

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

Это можно пофиксить. Плагин NM etcnet-alt работает так: нет файла
options для интерфейса - управляем интерфейсом. Есть файл и там не
написано NM_CONTROLLED=yes - не управляем.

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

Плагин пытается прочитать соединение из /etc/net, BOOTPROTO=dhcp уже
достаточно. В случае BOOTPROTO=static нужен еще как минимум адрес в
ipv4address, разумеется.
ONBOOT указывает будет ли соединение использоваться автоматически.

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

"Как надо пользователю" - это чтобы сеть была не настроена? Я в этом
совсем не уверен.

> Гибридную схему при этом, да и при установке тоже, никто не просил. И
> как её отключить родными средствами - непонятно. Удалять каталог
> /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 и не
настраивать.
В принципе, можно обучить alterator-net-eth создавать соединения для NM
и вообще выкинуть плагин etcnet-alt. Правда, потеряется возможность
указывать NM_CONTROLLED для интерфейсов, можно будет только глобально
выбрать либо всей сетью управляет NM, либо etcnet. И все настройки в
etcnet будут теряться при переключении на NM.

-- 
WBR, Mikhail Efremov

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

[Evgeny Sinelnikov]

пт, 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)

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

[Evgeny Sinelnikov]

Добрый день,

всех с праздником!

сб, 9 мая 2020 г. в 00:37, Evgeny Sinelnikov <sin@altlinux.org>:
>
> пт, 8 мая 2020 г. в 17:21, Mikhail Efremov <sem@altlinux.org>:
> >
[...]
>
> > В принципе, можно обучить alterator-net-eth создавать соединения для NM
> > и вообще выкинуть плагин etcnet-alt. Правда, потеряется возможность
> > указывать NM_CONTROLLED для интерфейсов, можно будет только глобально
> > выбрать либо всей сетью управляет NM, либо etcnet. И все настройки в
> > etcnet будут теряться при переключении на NM.

Не уверен, что стоит выкидывать то, что работает.
Рабочее дополнение мне кажется более предпочтительным.

Предложенный и реализованный ниже вариант добавляет создание
NM-соединений в текущей реализации в режиме управления "NetworkManager
(native)". По умолчанию остаётся оригинальное поведение в режиме
"Network Manager (etcnet)".

Думаю, что без установки и запуска NetworkManager на третьей стадии
инсталляции от нового режима толку будет мало. Если его выбрать, а
соединение не создаться, то получится поведение, проблема с которым и
решается текущим плагином etcnet-alt.


> Я предлагаю такой вариант, который потребует минимума усилий -
> поправить нужно 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 создаётся.
>
> Остальное, как обычно.

Я реализовал предложенный вариант. Сборка доступна в таске:
#251467 TESTED #1 [test-only] sisyphus alterator-net-eth.git=5.1.7-alt1

Буду благодарен за тесты и комментарии.

> _______________
>
> Второе дополнение, с этим малосвязное - добавить нужный "кейс" в
> alterator-net-eth. Не в качестве единственной замены NetworkManager в
> нативном режиме, а в качестве рабочей системной альтернативы в режимах
> Etcnet и NetworkManager (etcnet).
>
> Для этого, при включении режима dhcp нужно предусмотреть
> дополнительный вариант Конфигурации.
>
> К вариантам:
> - Использовать DHCP
> - Использовать Zeroconf
> - Вручную
>
> Нужно добавить один или несколько дополнительных вариантов:
> - Использовать DHCP, только адрес (хороший вариант - непонятно как его
> обеспечить - значения серверов имён у нам смешиваются средствами
> openresolv - но, наверное, это возможно);
> - Использовать DHCP, задать основной сервер имён (в этом случае
> разумно, что настройки DNS смешиваются - но тут нужно починить всё
> так, чтобы заданный сервер имён был первым, а не последним);
> - ...
> При этом настройки DNS остаются доступными для модификации.

Этот вариант, при наличии первого, не так критичен.

-- 
Sin (Sinelnikov Evgeny)

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

[Sergey Y. Afonin]

On Friday 08 May 2020, Mikhail Efremov wrote:

> Правда, потеряется возможность указывать NM_CONTROLLED для интерфейсов,
> можно будет только глобально выбрать либо всей сетью управляет NM, либо
> etcnet.

Это не очень хорошо. Для Ethernet NM не нужен (ага :-) ), но вот WiFi
и всякие VPN через него всё же удобно, особенно на нотебуке. Но у нотебука
бывает и провод.

-- 
С уважением, Сергей Афонин

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

[Evgeny Sinelnikov]

сб, 9 мая 2020 г. в 21:09, Sergey Y. Afonin <asy@altlinux.org>:
>
> On Friday 08 May 2020, Mikhail Efremov wrote:
>
> > Правда, потеряется возможность указывать NM_CONTROLLED для интерфейсов,
> > можно будет только глобально выбрать либо всей сетью управляет NM, либо
> > etcnet.
>
> Это не очень хорошо. Для Ethernet NM " (ага :-) ), но вот WiFi
> и всякие VPN через него всё же удобно, особенно на нотебуке. Но у нотебука
> бывает и провод.

В предложенной реализации вся логика с NM_CONTROLLED сохраняется.
Посмотрите её, пожалуйста, если вам интересно:
#251467 TESTED #1 [test-only] sisyphus alterator-net-eth.git=5.1.7-alt1

А вот по поводу того, что "для Ethernet NM не нужен" - это зависит от
опыта и неприхотливости пользователей. Без NM у пользователя нет
никакой графической ручки банально посмотреть полученный по DHCP
IP-адрес своей машины. Не говоря уже о таком сценарии (я его приводил,
но "буков, правда, было много"):
- на стационарном ПК включен etcnet с dhcp;
- выдёргиваем кабель (это может быть временно отключенный роутер);
- загружаемся;
- наблюдаем в процессе загрузки безуспешную попытку получить ip;
- после загрузки входим в систему;
- подключаем кабель и думаем, размышляем...

Как нам сеть настроить?
Подключенное через etcnet Ethernet-соединение в апплете NM при этом не
показывается.

Ну, опытный пользователь откроет консоль, выполнить ip a, потом
systemctl restart network (пока кабель не подключится, или до тех пор
пока роутер не включится, или всякое ещё бывает).
А неопытный как должен поступить? А если он не рядом? Упорно пытаться
перезагружать систему?

Есть вариант для неопытного пользователя - открыть acc (Центр
управления системой) и попытаться нажать кнопку "Применить". Но это
неочевидно, визуально не определить удачно или не удачно всё прошло и,
главное, потребует пароль рута. А пароль рута нужно ещё и помнить. А
если это неопытный пользователь (мама, бабушка, ребёнок, офисный
работник)?

Это же бомба для "неустойчивого поведения" и "отказа в обслуживании",
приводящая к тому, что тебе звонят и ты не знаешь, что ответить,
потому что систему ты ставил полгода назад и пароль рута записан
где-то там у них и забыт уже, скорее всего. А sudo по сложившейся
практике не настроен и ты на это положился. Нет, ну, хорошо... Пароль
рута помнить нужно (хотя для сотни рабочих станций я бы поспорил), но
не для этой же задачи.

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


-- 
Sin (Sinelnikov Evgeny)

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

[Антон Мидюков]

08.05.2020 11:31, Антон Мидюков пишет:
> Я уже давно регулярки и стартеркиты собираю с ненастроенным интерфейсом eth0.

Но так делать было неправильно. Потому исправил в mkimage-profiles:

http://git.altlinux.org/people/antohami/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commit;h=7a6c9a8a13a9610539c37b71ce66dcd551e12d2d

Рекомендую релиз-менеджерам взять этот коммит себе в профили. Касается
это только сборок с NetworkManager, т.е. десктопных сборок.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>