[devel-distro] Веб-браузер в инсталляторе или для инсталлятора?

Tue Oct 15 07:59:40 MSK 2024

Доброй ночи,

Ещё один конкретный вопрос. Кому и зачем нужен браузер в инсталляторе? 
(про конфигуратор - далее)

Я разобрал этот вопрос с antohami@ и вот к чему я пока что пришёл:

Единственное, для чего нужен браузерный вариант инсталлятора - это 
проблема необходимости для удалённой установки использовать что-то, 
кроме браузера. Например, как у нас сейчас, VNC-клиент.

Мне вот интересно. А кто у нас этим, вообще, пользуется, хотя бы через 
VNC? И кто будет пользоваться, если такую возможность реализовать? А 
ещё, насколько это актуально для "железных" машин, а не виртуалок. У 
серверных, "железных" машин обычно, для этих целей имеется IPMI (или 
аналоги). А ставить в таком режиме сотни клиентских машин - сомнительная 
затея.

___________________

Ещё один момент - это "современные" тенденции всё превращать в веб. И у 
этого есть свои преимущества, даже перед VNC, наверное. Прежде всего, 
потому, что "всё что движется" заворачивают в http.

Кстати, следом за http появляется https и любителям веба хочется задать 
вопрос: "А с этим как быть? Жить на самоподписанных сертификатах на 
каждой инсталлируемой машине?".

Предлагаю тому, кто топит за эту историю решить простой, по сравнению и 
инсталлятором вопрос - реализовать в нашем apt поддержку https-proxy. 
После этого можно будет всерьёз говорить о компетенциях в теме веба для 
низкоуровневых задач.

___________

Ещё один момент про веб для инсталлятора, который даже обсуждать не 
хочется.... Звучит он так, что "на вебе вон чего делают, смотрите как 
просто! И разработчиков на рынке во сколько".

Честное слово, грустно думать даже, может быть сразу на дотнете начнём 
тогда?

___________

....

Я уже думал отправлять ответ, как получил в потоке ещё одно сообщение от 
klark@, которое привожу ниже. По крупицам пытаюсь понять недовысказанное 
про веб...

15.10.2024 01:23, Leonid Krivoshein пишет:
>
> On 10/14/24 22:57, Evgeny Sinelnikov wrote:
>> Доброй ночи,
>>
>> хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
>> ориентироваться на конструктивные предложения. Архитектурных решений 
>> не так много, на самом деле. Архитектурных решений реализуемых в 
>> разумные сроки еще меньше.
>>
>
> Только здесь основная цель -- не сам конфигуратор, а множество 
> работающих в нём модулей, т.е. если в разумные сроки мы сможем 
> создавать несколько новых модулей, если к этому можно будет подключить 
> множество разработчиков, если технология будет интересна не только 
> нам, но и админам "на местах".
>
Трудно отвечать на недосказанное, подразумеваемое и предлагаемое, как 
очевидное.

Тезисно:
- Не нужно заставлять админов быть разработчиками, если они этого сами 
не хотят.
- Возможности админам давать нужно, и такие возможности, как раз, и 
предоставлены для бекендов.
- При этом, давать возможность делать простые, кривые, небезопасные 
фронты через веб - полная чушь.
- Самые активные уже сейчас могут начать осваивать cockpit, в который 
нативно встраиваются интерфейсы на dbus.
- Желающим написать срочно свой веб-движок, аналогичный cockpit, вне 
какой-либо модели безопасности предлагаю сначала подумать... 
(подробности в отдельной теме).
- "Cрочно" ничего, кроме cockpit, получить в виде веб-интерфейса пока не 
вижу ни смысла, ни ресурсов.
- А от админов нам нужна понятная, подробная аналитика (то есть 
адекватная обратная связь), иначе всё так и останется в недоделанных 
костылях.

В целом, ничего не имею против костылей, кроме того, что их 
проблематично масштабировать. Но и встраивать в продукты их не вижу 
смысла. alterator-net-domain тому хороший пример.

На текущий момент сценариев "подключения множества разработчиков" 
предполагается несколько:

1) разрабатываемые в рамках unix-way бекенды могут быть встроены в 
реализованные толстые клиенты.

Для этого требуется удовлетворять при реализации этих бекендов 
поддерживаемым уже разработанным фронтендами интерфейсам, которые лежат 
в соответствующих пакетах:
- 
https://packages.altlinux.org/ru/search/?branch=sisyphus&q=alterator-interface-

2) для уже разработанных бекендов могут быть использованы разные фронты 
под разные задачи, графические окружения, а также консольные утилиты.

Всё это достаточно понятно админам. Не вижу никаких для них в этом 
сложностей, если они хотят что-то разработать. Документацию будем 
наращивать. Примеры тоже будем создавать.

[...]
>>>
>>> А, если нам нужен графический инсталлятор, то графику, в любом 
>>> случае, не стоит запускать под рутом.
>
> Да.
>
> Конфигуратор я бы рассматривал как веб-интерфейс, работающий не под 
> root'ом, и не обязательно на том же хосте. Как фоновый агент, через 
> который можно менять настройки системы, будучи администратором сети, у 
> которого есть полномочия, а не только как локальный root. И одной из 
> обязанностей этого фонового агента может быть периодическое обновление 
> куска дерева конфигурации с какого-то условного контроллера домена.
>
> Часть настроек может быть изначально в ведении обычного пользователя. 
> В идеале иметь возможность как делегировать пользователям полномочия 
> менять конкретные системные настройки, так и наоборот, забирать у 
> обычного пользователя полномочия менять изначально пользовательские 
> настройки. Всё это разделение прав решается в пределах одной программы 
> конфигуратора без SELinux, Polkit и интроспекции dbus. Как вариант, в 
> пределах иерархической БД конфигурации. К слову, в виндовом реестре, 
> помимо древовидных "кустов" предусматривалась раздача ACL на целый 
> "куст".
>
Ну, давайте... + ещё один какой-то фоновый агент, с непонятным 
протоколом и непродуманным способом аутентификации...

где "всё это разделение прав решается в пределах одной программы 
конфигуратора".

Кто это всё писать собирается, если архитектура даже не продумана? В 
какие сроки?

[...]
>
>> Кстати, как альтернативу, с недавних пор systemd рассматривает - 
>> https://varlink.org/
>>
>> Systemd Looking At A Future With More Varlink & Less D-Bus For IPC
>> https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future
>>
>
> Просто, по нужде люди работают много лет с этим dbus и понимают, что 
> организовать взаимодействие можно намного проще. Причём там, где оно 
> действительно нужно. Например, когда мы связываем фронт с бэком в 
> UI/UX, JSON & Ко уместнее dbus, особенно, если мы выходим за пределы 
> хоста, чего хотелось бы. Если конфигуратор -- одна программа, если наш 
> тулкит уже позаботился о взаимодействии фронт и бэк частей модуля, нам 
> даже не надо об этом думать и остаётся только решить, в каких случаях 
> уместно использовать кем-то написанное с использованием dbus, чтобы 
> подтянуть и этот дополнительный функционал.
>
Вот, вроде хотим конфигуратор, а превращается всё в веб-интерфейс для 
ansible.

Не понимаю что значит: "Если конфигуратор -- одна программа, если наш 
тулкит уже позаботился о взаимодействии фронт и бэк частей модуля, нам 
даже не надо об этом думать и остаётся только решить, в каких случаях 
уместно использовать кем-то написанное с использованием dbus, чтобы 
подтянуть и этот дополнительный функционал."

Кто, о чём, как, почему должен позаботиться? (это риторический вопрос)

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

Про удалённый доступ напишу в ответвлении про интерфейсы.

14.10.2024 11:27, Sergey V Turchin пишет:
> On Thursday, 10 October 2024 22:29:00 MSK Leonid Krivoshein wrote:
>> On 10/9/24 22:46, Leonid Krivoshein wrote:
>>> On 10/9/24 12:06, Sergey V Turchin wrote:
>>>> On Wednesday, 9 October 2024 04:40:37 MSK Leonid Krivoshein wrote:
>>>>
>>>> [...]
>>>>
>>>>> 1.4. Разве вебовский UI/UX сейчас не приоритетней? Его давно не
>>>>> проблема
>>>>> встраивать в толстые приложения.
>>>> Проблема. Например, на e2k кроме Gecko/Firefox есть лишь некий
>>>> libwebkitgtk4,
>>>> который не везде встроишь.
>> Достаточно того, что есть браузер, из него можно конфигурировать систему.
> Какой веб-браузер будем использовать в установщике на e2k? Или только по сети
> из Internet Explorer?
>
> [...]
>
-- 
Синельников Евгений Александрович
Руководитель обособленного подразделения
«Инженерный отдел «Саратовский» ООО "Базальт СПО"
тел. +7 (495) 123-47-99 (доб. 531)
моб. тел. +7-917-207-53-96