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

[Leonid Krivoshein <klark.devel@gmail.com>]

On 10/15/24 07:59, Evgeny Sinelnikov wrote:
> Доброй ночи,
>
> Ещё один конкретный вопрос. Кому и зачем нужен браузер в инсталляторе? 
> (про конфигуратор - далее)
>

Я бы говорил иначе: при работе над конфигуратором нужен стиль 
"веб-разработки" из фронтэнда, бэкенда и описания модели данных (MVC), 
при котором интерфейсная часть модуля работает в браузере или в том, что 
его заменяет, без внесения изменений в кодовую базу. Это не разделение 
на компоненты, а отделение представления от исполняющей части, но это 
единое целое. Которое, тем не менее, можно запускать как из браузера с 
другого хоста, так и локально, и не только из браузера.

Инсталлятор я бы упростил до минимума. Он должен запускаться с LiveCD, 
это можно делать сразу после запуска общесистемного конфигуратора. Тогда 
и не придётся сильно мудрить с его архитектурой.


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

Типичный кейс -- безголовые сервера в датацентрах, всякие недоустройства 
с COM-портом или коннектором USB, одним словом всё, к чему монитор в 
реальной жизни не подключают даже на время установки. Ну нет у них 
графической карты. И не стоит надеяться на IPMI, он тоже есть не везде, 
и не везде он такой стандартный, что автоматом становится 
VGA-совместимой картой и клавиатурой. Каких-только зоопарков не бывает, 
особенно с Java и множеством проприетарных "улучшений".


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

Преимущество веб в том, что работающих с ним по одному принципу платформ 
очень много, и не надо думать, мы пишем программу под Qt5 или под gtk3. 
В случае вебовского тулкита, фронтэнд будет гарантировано доступен хоть 
с Андроида, хоть с Айфона. При этом, можно завёртывать браузер в толстое 
приложение, а можно и без этого обойтись как в случае с ранее 
называвшимися flutter, slint, Qt Assembly. Разработчик не думает о "не 
браузере", исходники пригодны для работы везде.


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

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

Если развёртывается много машин в большой сети, то чем плохи 
самоподписанные сертификаты? Опять же, нынешний alterator-fbi только так 
и работает "из коробки". Но ничто не мешает поменять сертификаты на 
более правильные с т.з. политики компании.


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

Полагаю, https (точнее TLS-каналов) у apt'а должно быть два, а не один, 
как сейчас в методе https. До самого прокси он должен ходить по одному 
TLS с корпоративным сертификатом, а уже внутри этого соединения 
заработает HTTP CONNECT до конечного сервера и тогда закомментированный 
сейчас в нашем apt'е код с https proxy заработает. Но я не специалист в 
нашем apt'е и https, глубоко не ковырял эту тему.


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

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


>
> Честное слово, грустно думать даже, может быть сразу на дотнете начнём 
> тогда?
>
> ___________
>
> ....
>
> Я уже думал отправлять ответ, как получил в потоке ещё одно сообщение 
> от 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, чтобы 
> подтянуть и этот дополнительный функционал."
>
> Кто, о чём, как, почему должен позаботиться? (это риторический вопрос)
>
> Ответа, полагаю, просто нет. Архитектуры нет. Есть предположения о 
> том, что если удачная архитектура кем-то будет реализована, то всё 
> можно будет как-то сделать.
>
> Про удалённый доступ напишу в ответвлении про интерфейсы.
>

Всё верно. Архитектуры нет, её только начали обсуждать. И да, веб-морда 
для ansible прямо не называлась, но если мы не имеем ресурсов и желания 
делать что-то своё, то хотя бы стоит подумать об адаптации ОС Альт к 
таким готовым решениям, как SaltStack+SaltGUI или аналогам. Из всех с 
кем имел дело по технической линии и совместимости на самых крупных 
внедрениях большинство либо на salt переходят, либо на коммерческие 
допиленные аналоги salt из реестра.


>
> 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?
>>
>> [...]
>>

-- 
WBR, Leonid Krivoshein.