From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: <1d93cbdf-0997-44c2-bc3d-48df533fe482@gmail.com> <2595755.KHDaQ3PfBV@zerg.malta.altlinux.ru> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: 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 List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2024 20:54:00 -0000 Archived-At: List-Archive: 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.