From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <klark.devel@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
 sa.local.altlinux.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
 DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no
 version=3.4.1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1729025637; x=1729630437; darn=lists.altlinux.org; 
 h=content-transfer-encoding:in-reply-to:from:content-language
 :references:to:subject:user-agent:mime-version:date:message-id:from
 :to:cc:subject:date:message-id:reply-to;
 bh=1woUPWUIw72DOh+4vty+D3IefRjugq6DfOuOb5hvbuI=;
 b=a2ug0IOVcdAf10vrwALc5l43dpgel+xuYQJK7GOf3eo3/Wi/+UoSjTPEBHivNFS3AY
 qS8cW2+gcyqojC5dR3MpTpbcrKvpKleht0VY8sM+jrSfsm9Sxb7ugi9Jgmq9BPyZJ6np
 Tii+ve5BnVA+QzBbjh4ZFcoRLvun5Q06LqCzHLW/u1JKVqcmoJTet/VzLOfrrCYbCxss
 tHDNXMfLsMOz+bfJgFWu4u/YQ0xHahp2K1589VF6iAjxxDmqAil/mFqIWKdBCKqJiS5i
 C9UxROZuDa5RIsQtlX3wND/nalULfcHqrB+tQ2WQ6WSlahcYcrmBSurkg5NGFlHWFwK4
 xLBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1729025637; x=1729630437;
 h=content-transfer-encoding:in-reply-to:from:content-language
 :references:to:subject:user-agent:mime-version:date:message-id
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=1woUPWUIw72DOh+4vty+D3IefRjugq6DfOuOb5hvbuI=;
 b=CTbqxuf6d4VGl9cWljGa2mmNQsfQRZezgCofCZSWoVz0sIBJtZKvQwzdClxFlLNCQX
 +8BAlUCBapoZuHAzT9J9B3NcF+qIGh2u+mSxtd347o8ByInXCpCEftrakZrBcOmQGCr3
 NsPgI6yN2e2j4q0Ap6GxJ01S80UZzbzDEk+A6W0Hk0eaD8r6JLHnd74SUReMqEhJQxT2
 ktWQrtqrYtxag+5Xpme3gFWI4oqJZRQqaxMoWj/GSTHqcwRo7pupNBakWtZBasxlj0m2
 vl2GUqh41lm38wra/wB1KCz7MzYjOAGtLa+z3pKgx7mrHE/45Ow3CC9NZ1X9QEPIkPw/
 Qbfw==
X-Gm-Message-State: AOJu0YwD2nHfcnCYSFQwejFHMMqnBw8XiR2Q+l5XnR/+ct+i0uVJOybT
 8nMG9ZP1pwUw1dw6+kze3VKTwH/ttfKECWjIhQ3MpZHBjyrofAHeO/WSAQ==
X-Google-Smtp-Source: AGHT+IH0tfdmfpDkGV7gMJ4zf6UkUXa++11p2SG18qiaZcKSB+inHML9NeOq8MVTLGM2nHn8U20QGA==
X-Received: by 2002:adf:fdc3:0:b0:37d:5301:6edb with SMTP id
 ffacd0b85a97d-37d86d651f8mr1053260f8f.57.1729025636235; 
 Tue, 15 Oct 2024 13:53:56 -0700 (PDT)
Message-ID: <70ee8512-6dab-4ae8-9a99-3c3d1a570543@gmail.com>
Date: Tue, 15 Oct 2024 23:53:54 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: devel-distro@lists.altlinux.org
References: <aeb9c0be-fd5b-4697-a52f-edccdcd32da8@ya.ru>
 <1d93cbdf-0997-44c2-bc3d-48df533fe482@gmail.com>
 <d3d76368-1e78-45a5-96aa-4bc67f8c9284@gmail.com>
 <2595755.KHDaQ3PfBV@zerg.malta.altlinux.ru>
 <e4b63d5f-3298-43f3-8a8f-51a83275408e@basealt.ru>
Content-Language: ru, en-US
From: Leonid Krivoshein <klark.devel@gmail.com>
In-Reply-To: <e4b63d5f-3298-43f3-8a8f-51a83275408e@basealt.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [devel-distro]
 =?utf-8?b?0JLQtdCxLdCx0YDQsNGD0LfQtdGAINCyINC40L0=?=
 =?utf-8?b?0YHRgtCw0LvQu9GP0YLQvtGA0LUg0LjQu9C4INC00LvRjyDQuNC90YHRgtCw?=
 =?utf-8?b?0LvQu9GP0YLQvtGA0LA/?=
X-BeenThere: devel-distro@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Distributions development <devel-distro@lists.altlinux.org>
List-Id: Distributions development <devel-distro.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/devel-distro>,
 <mailto:devel-distro-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/devel-distro>
List-Post: <mailto:devel-distro@lists.altlinux.org>
List-Help: <mailto:devel-distro-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/devel-distro>,
 <mailto:devel-distro-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2024 20:54:00 -0000
Archived-At: <http://lore.altlinux.org/devel-distro/70ee8512-6dab-4ae8-9a99-3c3d1a570543@gmail.com/>
List-Archive: <http://lore.altlinux.org/devel-distro/>


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.