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

[Michael Shigorin]

On Tue, Oct 15, 2024 at 11:53:54PM +0300, Leonid Krivoshein wrote:
> Я бы говорил иначе: при работе над конфигуратором нужен стиль
> "веб-разработки" из фронтэнда, бэкенда и описания модели данных
> (MVC), при котором интерфейсная часть модуля работает в
> браузере или в том, что его заменяет, без внесения изменений в
> кодовую базу.

http://altlinux.org/alterator/architecture

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

Попробуй.  Там так-то не старались мудрить, лишь бы намудрить
-- скорее наслоения, чем архитектурное.

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

IPMI SP, который и реализует удалённую консоль --
даёт, гругря, VGA с клавомышью как раз в расчёте
на "обычный" графический/текстовый инсталятор.

> > А ставить в таком режиме сотни клиентских машин -
> > сомнительная затея.

Да; у нас на эту тему есть что рассказать gremlin@
как практику по датацентрам.

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

Да.

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

Потому что там нет https.

> Если развёртывается много машин в большой сети, то чем плохи
> самоподписанные сертификаты?

<банальное>
Тем, что их потребуется дотащить до всех браузеров, очевидно.
И это или своя PKI, или головняк с потенциалом к дальнейшему
росту пофигизма и реального ущерба безопасности на ровном месте.
</>

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

Для администрирования считаю более уместным заворачивать
в SSH, чем в SSL.  В том числе из-за глубокой порочности
самого принципа SSL CA "кому-то там доверяю, не знаю".

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

И результат типично ужасен -- "ой, ну и что, что не работает
на вчерашнем браузере, зато посмотрите, какие уголочки!".

Вплоть до дегенератов, которые умудряются сломать своими
обмотками единственное важное поле ввода во всём магазине
(у грамотных оно и без js будет работать, и на голом POST
вообще хоть в lynx -- но грамотные нам не по карману).

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

Дададад.  И сразу под winapi, всё равно же libwine есть.

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

"через веб" тут избыточно, хоть там и наиболее очевидно.

> > - Самые активные уже сейчас могут начать осваивать cockpit,
> > в который нативно встраиваются интерфейсы на dbus.

...и пойти на курсы риторики, чтоб ещё более убедительно
рассказывать про Самую Отечественную Разработку, ага.

> > - Желающим написать срочно свой веб-движок, аналогичный
> > cockpit, вне какой-либо модели безопасности предлагаю сначала
> > подумать...  (подробности в отдельной теме).

...о том, в чём предполагается отличие хотя бы целей для начала,
а затем уж архитектуры и реализации (разумеется, изучив таковые
по сравниваемому).

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

И чем степень понятности отличается от уже имеющейся
для собственно alterator?

> > Вот, вроде хотим конфигуратор, а превращается всё в
> > веб-интерфейс для ansible.

"Когда в руке молоток..." :)

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

"У меня архитектуры нет.  Но то, что имеет архитектуру
и вообще-то вывозило нас двадцать лет -- надо заменить" (ц)

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

В том числе с ansible? (я здесь совсем не в контексте)

> >>>>>> 1.4. Разве вебовский UI/UX сейчас не приоритетней?

Смотря среди кого.

> >> Какой веб-браузер будем использовать в установщике на e2k?
> >> Или только по сети из Internet Explorer?

Прямщас это Firefox 91.  И нет, я приду в гости с кирпичом
к тому, кто попытается мне такое навязать.

-- 
Michael Shigorin
http://altlinux.org/elbrus