[devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Антон Мидюков]

Доброго времени суток

Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.

По результатам обсуждения я сформулировал следующие тезисы:

1. Графический интерфейс инсталлятора представляет собой конфигуратор, который создаёт сценарий автоустановки (kickstart-файл)

2. Сценарий автоустановки состоит из секций конфигураций, соответствующих бекенду. Если бекенд не доступен, секция конфига пропускается

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

4. После того, как выполнена конфигурация и нажата кнопка установить (при настройке первого запуска - это Применить), происходит автоустановка. В графическом режиме процесс автоустановки визуализируется отдельным шагом "Установка", а в режиме автоустановки графический интерфейс не запускается и процесс визуализируется текстовыми сообщениями о выполненных операциях.

5. Установка разделена на две части: собственно установка и настройка при первом запуске.

5.1 Настройки установки

5.1.1 Выбор языка

5.1.2 Принятие лицензионного соглашения

5.1.3 Настройка даты/времени

5.1.4 Настройка сети

5.1.5 Создание пароля root

5.1.6 Создание пользователей

5.1.7 Выбор компонентов для установки

5.1.8 Разбивка диска, настройка загрузчика и задание пароля LUKS (кажется логичным делать это одним шагом, а не тремя)

5.2 Настройки первого запуска

5.2.1 Выбор языка

5.2.2 Принятие лицензионного соглашения

5.2.3 Настройка даты/времени

5.2.4 Настройка сети

5.2.5 Создание пароля root

5.2.6 Создание пользователей

5.2.7 Выбор компонентов для установки

6. Настройка первого запуска является опциональной

7. Настройки из пунктов 5.1.1-5.1.7 необязательно выполнять при установке, если будет выполняться настройка первого запуска

8. Настройки выполняются параллельно

9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.

Предлагаю для начала определиться корректны изложенные тезисы или нет.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] на базе альтератор 2.0

[Leonid Krivoshein]

Всем привет!


On 10/8/24 16:43, Антон Мидюков wrote:
> Доброго времени суток
>
> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.

Пересмотрел доклады XX DevConf про alterator 2.0 -- пока не увидел 
внятного описания концепта и целей. И сколь-нибудь предметного 
обсуждения в паблике не встречал.

Декларировано внедрение системы управления конфигурациями на 
dconf/gsetteings, описанная как рекомендация замены виндового реестра в 
мае 2005 года компанией IBM 
(http://web.archive.org/web/20121029054935/http://www.ibm.com/developerworks/ru/library/linux_migr/intro.html?ca=drs-ru 
, увы, полной версии этого гигантского документа у меня не сохранилось). 
Т.е., 19 лет спустя мы забываем про паппеты, ансиблы, сальты и иже с 
ними, и начинаем применять эти рекомендации IBM, внедряя свою самобытную 
систему управления, так?

При этом нет ничего плохого в dconf, gsettings и dbus, у нас они активно 
много лет используются по назначению. И нет ничего плохого в том, чтобы 
использовать шину dbus для обмена данными между приложениями. Но 
управление конфигурацией?.. IBM это видела так... но в 2005 году!

В ответе на главный вопрос Павла Волнейкина про источник конфигурации 
говорится об опакечивании дефолта с пакетом. Где же тогда 
конфигурируемость? Мы и сейчас без dconf можем переконфигурировать 
единственный дефолт, идущий с пакетом. Наша беда в том, что нам для 
одного пакета нужны разные конфигурации, в зависимости от того, как и в 
каком решении будет использоваться пакет.

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



> По результатам обсуждения я сформулировал следующие тезисы:
>
> 1. Графический интерфейс инсталлятора представляет собой конфигуратор, который создаёт сценарий автоустановки (kickstart-файл)
>
> 2. Сценарий автоустановки состоит из секций конфигураций, соответствующих бекенду. Если бекенд не доступен, секция конфига пропускается
>
> 3. Один и тот же сценарий автоустановки может использоваться для установки и запуска настройки первого запуска, так как в инсталляторе и установленной системе разный набор бекендов (в установленной системе точно нет модуля разбивки диска).
>
> 4. После того, как выполнена конфигурация и нажата кнопка установить (при настройке первого запуска - это Применить), происходит автоустановка. В графическом режиме процесс автоустановки визуализируется отдельным шагом "Установка", а в режиме автоустановки графический интерфейс не запускается и процесс визуализируется текстовыми сообщениями о выполненных операциях.
>
> 5. Установка разделена на две части: собственно установка и настройка при первом запуске.
>
> 5.1 Настройки установки
>
> 5.1.1 Выбор языка
>
> 5.1.2 Принятие лицензионного соглашения
>
> 5.1.3 Настройка даты/времени
>
> 5.1.4 Настройка сети
>
> 5.1.5 Создание пароля root
>
> 5.1.6 Создание пользователей
>
> 5.1.7 Выбор компонентов для установки
>
> 5.1.8 Разбивка диска, настройка загрузчика и задание пароля LUKS (кажется логичным делать это одним шагом, а не тремя)
>
> 5.2 Настройки первого запуска
>
> 5.2.1 Выбор языка
>
> 5.2.2 Принятие лицензионного соглашения
>
> 5.2.3 Настройка даты/времени
>
> 5.2.4 Настройка сети
>
> 5.2.5 Создание пароля root
>
> 5.2.6 Создание пользователей
>
> 5.2.7 Выбор компонентов для установки
>
> 6. Настройка первого запуска является опциональной
>
> 7. Настройки из пунктов 5.1.1-5.1.7 необязательно выполнять при установке, если будет выполняться настройка первого запуска
>
> 8. Настройки выполняются параллельно
>
> 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
>
> Предлагаю для начала определиться корректны изложенные тезисы или нет.
>

-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/8/24 16:43, Антон Мидюков wrote:
> Доброго времени суток
>
> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.
>
> По результатам обсуждения я сформулировал следующие тезисы:
>
> [...]

На мой взгляд, вот до этого пункта:

> 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
>
> Предлагаю для начала определиться корректны изложенные тезисы или нет.

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


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Evgeny Sinelnikov]

Здравствуйте.

ср, 9 окт. 2024 г. в 03:29, Leonid Krivoshein <klark.devel@gmail.com>:
> On 10/8/24 16:43, Антон Мидюков wrote:
> > Доброго времени суток
> >
> > Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.
> >
> > По результатам обсуждения я сформулировал следующие тезисы:
> > [...]
>
> На мой взгляд, вот до этого пункта:
>
> > 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
> >
> > Предлагаю для начала определиться корректны изложенные тезисы или нет.
>
> ...именно как тезисы -- нет, но перечисленное тоже можно обсудить. Нет,
> потому что начинать стоит с того: от чего, к чему и почему мы движемся,
> это даст определённые критерии оценки. А многое из перечисленного --
> детали повторной реализации того, что уже есть.

Мы движемся от одного механизма реализации бекендов к другому. От
механизма, в котором нет, по сути, определенных интерфейсов, к
механизму, где их можно задавать, фиксировать, контролировать доступ
на уровне каждого отдельного метода и получать возможность написания
фронтендов, не требующих выполнения под рутом.

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

Технологически мы движемся:
1) от службы alteratord на базе woo-bus к службе alterator-manager на базе dbus.
2) от дублирования механизмов, встроенных в современные
GNU/Linux/Systemd системы к их расширению.

Например, очень странно только из-под-рута уметь запускать через
unix-socket shell-скрипт, который выполняет systemctl, который в свою
очередь обращается к dbus, вместо того, чтобы напрямую обращаться к
интерфейсу org.freedesktop.systemd1.Manager.

Чтобы увидеть перечень методов достаточно набрать и "потабать":
$ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1
org.freedesktop.systemd1.Manager

Впрочем "потабать" можно всё. Это называется интроспекция. В некоторых
случаях её скрывают, но это детали и особенности реализации.

Технологически мы движемся:
3) от не соответствующего потребностям автоустановки autoinstall.scm к
формату, который нужно определить, зафиксировать (специфицировать) и
реализовать "движок" инсталлятора с учётом возможностей бекендов -
доступных методов и интерфейсов на dbus.
4) мы движемся от отсутствия API для администрирования к его
оформлению для всех механизмов ОС, которым необходимо повышение
привилегий.

5) мы движемся от строгой технической необходимости реализовывать
фронтэнды вместе с бекендами к возможности (например, по аналогии с
NetworkManager) реализации множества фронтендов под соответствующие
среды исполнения (графические, консольные, любые). Например, с помощью
новых бекендов на базе alterator-manager можно расширять возможности
уже применяемого на практике cockpit (но, это при желании):
- https://cockpit-project.org/applications

6) мы движемся от сценария один, бекенд один фронтенд к сценариям:
+ один бекенд, множество разных реализаций фронтендов;
+ один фронтенд, множество разных бекендов, реализующих один и тот же
интерфейс на разных объектах шины dbus.

Оба сценария уже активно задействованы в существующих наработках.
Ключевые детали по текущим наработкам опубликованы у нас на wiki:
- https://www.altlinux.org/Alterator_на_D-Bus


___________________

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

Один из вариантов взять вот этот для вдохновения и (может быть, совместимости):
- https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/
- https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-commands-and-options-reference_rhel-installer
- https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html
- https://rhinstaller.github.io/anaconda-addon-development-guide/sect-anaconda-addon-architecture.html

И далее, постепенно, реализовать на его основе своё подмножество. Не
хотелось бы брать anaconda. Хотя... если делать эту часть на python,
то что-то форкнуть, урезать и переписать под себя - вариант.
Вообще, конечно, один в один оно достаточно тяжелое. Главное - формат:
Есть ли технический смысл брать kickstart за основу?

Мне кажется, что в этом формате, как минимум, проведён теханализ
потребностей инсталлятора. Хотя бы к ним стоит присмотреться.


___________________________

PS: Последней, требующей внимание особого внимания особенностью
реализации нового стека на dbus, которая ещё только предстоит,
является переход от пространства имён /ru/basealt/alterator к
пространству /org/altlinux/alterator (от ru.basealt.alterator к
org.altlinux.alterator).


-- 
Sin (Sinelnikov Evgeny)

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/9/24 05:13, Evgeny Sinelnikov wrote:
> Здравствуйте.
>
> ср, 9 окт. 2024 г. в 03:29, Leonid Krivoshein <klark.devel@gmail.com>:
>> On 10/8/24 16:43, Антон Мидюков wrote:
>>> Доброго времени суток
>>>
>>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.
>>>
>>> По результатам обсуждения я сформулировал следующие тезисы:
>>> [...]
>> На мой взгляд, вот до этого пункта:
>>
>>> 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
>>>
>>> Предлагаю для начала определиться корректны изложенные тезисы или нет.
>> ...именно как тезисы -- нет, но перечисленное тоже можно обсудить. Нет,
>> потому что начинать стоит с того: от чего, к чему и почему мы движемся,
>> это даст определённые критерии оценки. А многое из перечисленного --
>> детали повторной реализации того, что уже есть.
> Мы движемся от одного механизма реализации бекендов к другому.

В этом предложении речь о реализации, а не целеполагании.


> От
> механизма, в котором нет, по сути, определенных интерфейсов, к
> механизму, где их можно задавать, фиксировать, контролировать доступ
> на уровне каждого отдельного метода и получать возможность написания
> фронтендов, не требующих выполнения под рутом.

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


> В том виде, как сейчас, затруднительно делать многое. Большую часть
> того, к чему мы движемся осуществить невозможно без полной
> переработки.
>
> Технологически мы движемся:
> 1) от службы alteratord на базе woo-bus к службе alterator-manager на базе dbus.

Разделение на фронтэнды и бекенд в альтераторе уже неудачно 
спроектировано и ещё хуже реализовано. В улучшенной версии предлагается 
ещё больше усложнить механизм создания бекендов. Для установщика этого 
всего вообще не требуется.


> 2) от дублирования механизмов, встроенных в современные
> GNU/Linux/Systemd системы к их расширению.

Наш установщик давно перешёл на systemd? У нас все установочные образы 
на systemd? Чего нам в установщике нужно от systemd, дёргая его 
исключительно через dbus?


> Например, очень странно только из-под-рута уметь запускать через
> unix-socket shell-скрипт, который выполняет systemctl, который в свою
> очередь обращается к dbus, вместо того, чтобы напрямую обращаться к
> интерфейсу org.freedesktop.systemd1.Manager.

Команда systemctl на шеле -- одна строка. Мы готовы обучать детей и 
внуков механизму работы с dbus на Си, вместо того, чтобы сделать их 
счастливыми? :-)


> Чтобы увидеть перечень методов достаточно набрать и "потабать":
> $ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1
> org.freedesktop.systemd1.Manager
>
> Впрочем "потабать" можно всё. Это называется интроспекция. В некоторых
> случаях её скрывают, но это детали и особенности реализации.

Горячо поддерживаю интроспекцию, наследование, полиморфизм и повторную 
реализацию. :-) Но не думаю, что первое необходимо для всего и вся в 
установщике.


> Технологически мы движемся:
> 3) от не соответствующего потребностям автоустановки autoinstall.scm к
> формату, который нужно определить, зафиксировать (специфицировать) и

Да.


> реализовать "движок" инсталлятора с учётом возможностей бекендов -
> доступных методов и интерфейсов на dbus.

И туда же (в музей мазохизма) я бы отправил движок альтератора. Вообще 
всё, что на scheme. Как слишком сложно поддерживаемое и 
несоответствующие тому, к чему мы хотим двигаться. Креативная команда 
должна генерить несколько десятков модулей конфигуратора в месяц, по 
мере роста хотелок со всех сторон. Вот какая цель должна быть 
декларирована -- простота создания новых модулей, простота их поддержки, 
а не усложнение.


> 4) мы движемся от отсутствия API для администрирования к его
> оформлению для всех механизмов ОС, которым необходимо повышение
> привилегий.

Существуют и другие способы, не требующие манипулировать API.


> 5) мы движемся от строгой технической необходимости реализовывать
> фронтэнды вместе с бекендами к возможности (например, по аналогии с
> NetworkManager) реализации множества фронтендов под соответствующие
> среды исполнения (графические, консольные, любые). Например, с помощью
> новых бекендов на базе alterator-manager можно расширять возможности
> уже применяемого на практике cockpit (но, это при желании):
> - https://cockpit-project.org/applications

+ https://pub.dev/ -- сюда же.

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

> 6) мы движемся от сценария один, бекенд один фронтенд к сценариям:
> + один бекенд, множество разных реализаций фронтендов;
> + один фронтенд, множество разных бекендов, реализующих один и тот же
> интерфейс на разных объектах шины dbus.
>
> Оба сценария уже активно задействованы в существующих наработках.
> Ключевые детали по текущим наработкам опубликованы у нас на wiki:
> - https://www.altlinux.org/Alterator_на_D-Bus

Почитал это и смежное про Alterator-manager, что дополнило мой немного 
критический взгляд. У нас не все дистрибутивы завязаны на 
dconf/gsettings. Не все установщики работают с systemd. Наработки по 
групповым политикам, компетенция по работе с dbus не пропадут даром. 
Делать же это концептуальным стержнем я бы точно не стал.

В копилку плюсов dbus&Co: 
https://events.canonical.com/event/2/contributions/48/attachments/34/49/Flutter%20on%20Linux.pdf 
, стр. 7. И даже установщик там это использует (Ubuntu Desktop 
Installer). Но стоит учесть, что это одна вполне конкретная среда, у нас 
же решения разные.


> ___________________
>
> На текущий момент важно ввести уровень абстракции инсталлятора, как
> расширенного приложения исполняющего пошаговую "инструкцию",
> использующую специфицированный формат. Выбором этого формата
> необходимо заняться в первую очередь.

Мне кажется, сначала нужно решить, будет ли установщик связан с 
конфигуратором или нет. Если будет, то каким форматом данных будет 
манипулировать конфигуратор? Мы для установщика определяем конфигурацию 
решения, установщик её натягивает на устанавливаемое. А конфигуратором 
мы раскидываем её по 100500 машин домена.


> Один из вариантов взять вот этот для вдохновения и (может быть, совместимости):
> - https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/
> - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-commands-and-options-reference_rhel-installer
> - https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html
> - https://rhinstaller.github.io/anaconda-addon-development-guide/sect-anaconda-addon-architecture.html
>
> И далее, постепенно, реализовать на его основе своё подмножество. Не
> хотелось бы брать anaconda. Хотя... если делать эту часть на python,
> то что-то форкнуть, урезать и переписать под себя - вариант.
> Вообще, конечно, один в один оно достаточно тяжелое. Главное - формат:
> Есть ли технический смысл брать kickstart за основу?

Нет, это не вариант, только как одна из входных точек для проектирования 
чего-то своего.


> Мне кажется, что в этом формате, как минимум, проведён теханализ
> потребностей инсталлятора. Хотя бы к ним стоит присмотреться.

Да.


> ___________________________
>
> PS: Последней, требующей внимание особого внимания особенностью
> реализации нового стека на dbus, которая ещё только предстоит,
> является переход от пространства имён /ru/basealt/alterator к
> пространству /org/altlinux/alterator (от ru.basealt.alterator к
> org.altlinux.alterator).

Тщетно пытался отделить обсуждение конфигуратора от установщика. Тут всё 
слилось обратно в единое целое. В тесном связывании этих двух разных 
программ есть плюсы и минусы. Может, обсудить тогда уж их сначала? Но 
фичи их точно нужно обсуждать в отдельных тредах. И если решать в пользу 
тесного связывания, то отложить пока обсуждение установщика.


-- 
WBR, Leonid Krivoshein.

[devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0

[Sergey V Turchin]

On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:

[...]
> > От
> > механизма, в котором нет, по сути, определенных интерфейсов, к
> > механизму, где их можно задавать, фиксировать, контролировать доступ
> > на уровне каждого отдельного метода и получать возможность написания
> > фронтендов, не требующих выполнения под рутом.
> 
> При этом установить ОС можно только под рутом. И тогда непонятно, зачем
> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
Если помните, текущий aterator умееет и пользовательские настройки(реально 
какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас 
востребовано.

[...]

-- 
Regards, Sergey.

[devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Evgeny Sinelnikov]

Доброй ночи,

хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
ориентироваться на конструктивные предложения. Архитектурных решений не 
так много, на самом деле. Архитектурных решений реализуемых в разумные 
сроки еще меньше.


14.10.2024 11:17, Sergey V Turchin пишет:
> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:
>
> [...]
>>> От
>>> механизма, в котором нет, по сути, определенных интерфейсов, к
>>> механизму, где их можно задавать, фиксировать, контролировать доступ
>>> на уровне каждого отдельного метода и получать возможность написания
>>> фронтендов, не требующих выполнения под рутом.
>> При этом установить ОС можно только под рутом. И тогда непонятно, зачем
>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
> Если помните, текущий aterator умееет и пользовательские настройки(реально
> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас
> востребовано.
>
> [...]

Удивительное дело. Давайте не будем путать. Общая тенденция создания 
безопасных систем приводит к очень сложным в сопровождении решениям, 
вроде SELinux. Проблема в том, что приложения под рутом невозможно 
проконтролировать иначе. Любое приложение под рутом может всё. И 
остаётся только доверять коду и надеяться на то, что этого кода будет 
немного и в нем не будет критических уязвимостей.

Текущий Альтератор построен на концепции общего набора механизмов 
конфигуратора, как в инсталляторе, так и в установленной системе. 
Недоработка текущей реализации в этом плане привела к тому, что 
графический интерфейс мы вынуждены запускать под рутом. И это, я 
полагаю, напрямую связано с тем, что кем-то тоже было сказано или 
подумано нечто подобное:

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

То есть упор был на инсталлятор, а конфигуратор остался как есть. А 
концепт, одних и тех же модулей сохранился.

Сейчас мы идём от обратного. Сначала конфигуратор, а потом инсталлятор. 
Хоть под рутом, хоть не под рутом. С другой стороны, а в чём, 
собственно, переусложнение?

Один из вариантов запуска нашего текущего инсталлятора - это запуск его, 
как приложения, в обычном livecd. В большинстве дистрибутивов оно так и 
работает. В графическом виде. При этом консольного (не графического) 
инсталятора у нас так пока и не было сделано.

А, если нам нужен графический инсталлятор, то графику, в любом случае, 
не стоит запускать под рутом.

____________________

Итого, по теме под рутом, не под рутом. Если будет графика, то не 
понимаю что мы обсуждаем. Чем нам графика под рутом жизнь облегчит? Тем, 
что shell-скрипты можно будет писать не только на bash, но и на C или 
Python? На я имею в виду fork/exec консольных приложений.

На текущий момент имеется dbus - не вижу ничего противоестественного 
использовать его в инсталляторе. Кстати, как альтернативу, с недавних 
пор 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

В выше приведенной статье указаны многие проблемы, с которыми 
сталкиваются в systemd. Они там хорошо структурированы и технически 
обоснованы. Возможно, нам тоже стоит к этому присмотреться к systemd 
версии 257.

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

Предлагаю об этом подумать сразу после написания новых модулей. И, 
главное, интерфейсов для них. В смысле бекендов. Сделать к ним 
интерфейсы на varlink'е будет не сложно. И проблема необходимости dbus 
перестанет быть.


-- 
Синельников Евгений Александрович
Руководитель обособленного подразделения
«Инженерный отдел «Саратовский» ООО "Базальт СПО"
тел. +7 (495) 123-47-99 (доб. 531)
моб. тел. +7-917-207-53-96

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/14/24 22:57, Evgeny Sinelnikov wrote:
> Доброй ночи,
>
> хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
> ориентироваться на конструктивные предложения. Архитектурных решений 
> не так много, на самом деле. Архитектурных решений реализуемых в 
> разумные сроки еще меньше.
>

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


>
> 14.10.2024 11:17, Sergey V Turchin пишет:
>> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:
>>
>> [...]
>>>> От
>>>> механизма, в котором нет, по сути, определенных интерфейсов, к
>>>> механизму, где их можно задавать, фиксировать, контролировать доступ
>>>> на уровне каждого отдельного метода и получать возможность написания
>>>> фронтендов, не требующих выполнения под рутом.
>>> При этом установить ОС можно только под рутом. И тогда непонятно, зачем
>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
>> Если помните, текущий aterator умееет и пользовательские 
>> настройки(реально
>> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас
>> востребовано.
>>
>> [...]
>
> Удивительное дело. Давайте не будем путать. Общая тенденция создания 
> безопасных систем приводит к очень сложным в сопровождении решениям, 
> вроде SELinux. Проблема в том, что приложения под рутом невозможно 
> проконтролировать иначе. Любое приложение под рутом может всё. И 
> остаётся только доверять коду и надеяться на то, что этого кода будет 
> немного и в нем не будет критических уязвимостей.
>
> Текущий Альтератор построен на концепции общего набора механизмов 
> конфигуратора, как в инсталляторе, так и в установленной системе. 
> Недоработка текущей реализации в этом плане привела к тому, что 
> графический интерфейс мы вынуждены запускать под рутом. И это, я 
> полагаю, напрямую связано с тем, что кем-то тоже было сказано или 
> подумано нечто подобное:
>
> "При этом установить ОС можно только под рутом. И тогда непонятно, зачем
> нужны все эти интерфейсы, разделение прав и тому подобные усложнения."
>

Совершенно верно. Нет нужды разграничивать доступ в установщике. Нет 
необходимости запускать графическую часть установщика или конфигуратора 
под root'ом. Но разграничение прав внутри конфигуратора необходимо, и не 
только в пределах локальных пользователей хоста. Конфигуратор может не 
ограничиваться одним хостом.


> То есть упор был на инсталлятор, а конфигуратор остался как есть. А 
> концепт, одних и тех же модулей сохранился.
>
> Сейчас мы идём от обратного. Сначала конфигуратор, а потом 
> инсталлятор. Хоть под рутом, хоть не под рутом. С другой стороны, а в 
> чём, собственно, переусложнение?
>
> Один из вариантов запуска нашего текущего инсталлятора - это запуск 
> его, как приложения, в обычном livecd. В большинстве дистрибутивов оно 
> так и работает. В графическом виде. При этом консольного (не 
> графического) инсталятора у нас так пока и не было сделано.
>
> А, если нам нужен графический инсталлятор, то графику, в любом случае, 
> не стоит запускать под рутом.

Да.

Конфигуратор я бы рассматривал как веб-интерфейс, работающий не под 
root'ом, и не обязательно на том же хосте. Как фоновый агент, через 
который можно менять настройки системы, будучи администратором сети, у 
которого есть полномочия, а не только как локальный root. И одной из 
обязанностей этого фонового агента может быть периодическое обновление 
куска дерева конфигурации с какого-то условного контроллера домена.

Часть настроек может быть изначально в ведении обычного пользователя. В 
идеале иметь возможность как делегировать пользователям полномочия 
менять конкретные системные настройки, так и наоборот, забирать у 
обычного пользователя полномочия менять изначально пользовательские 
настройки. Всё это разделение прав решается в пределах одной программы 
конфигуратора без SELinux, Polkit и интроспекции dbus. Как вариант, в 
пределах иерархической БД конфигурации. К слову, в виндовом реестре, 
помимо древовидных "кустов" предусматривалась раздача ACL на целый "куст".


> ____________________
>
> Итого, по теме под рутом, не под рутом. Если будет графика, то не 
> понимаю что мы обсуждаем. Чем нам графика под рутом жизнь облегчит? 
> Тем, что shell-скрипты можно будет писать не только на bash, но и на C 
> или Python? На я имею в виду fork/exec консольных приложений.
>
> На текущий момент имеется dbus - не вижу ничего противоестественного 
> использовать его в инсталляторе.

Давно стоило акцентироваться, что dbus, прежде всего -- IPC, а зачем 
нужен IPC в инсталляторе? Это точно кажется противоестественным. И в 
конфигураторе-то он может быть нужен далеко не в каждом модуле.


> Кстати, как альтернативу, с недавних пор 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, чтобы подтянуть и 
этот дополнительный функционал.


> В выше приведенной статье указаны многие проблемы, с которыми 
> сталкиваются в systemd. Они там хорошо структурированы и технически 
> обоснованы. Возможно, нам тоже стоит к этому присмотреться к systemd 
> версии 257.
>
> И это, как раз, то, что предлагалось в рамках всех разумных 
> альтернатив для dbus. Но... ресурсов спроектировать всё на новом стеке 
> прямо сейчас пока не наблюдается.
>
> Предлагаю об этом подумать сразу после написания новых модулей. И, 
> главное, интерфейсов для них. В смысле бекендов. Сделать к ним 
> интерфейсы на varlink'е будет не сложно. И проблема необходимости dbus 
> перестанет быть.
>

-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Антон Мидюков]

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

Про админов "на местах" я уже где-то слышал. Ах, да:
https://www.altlinux.org/Alterator#Обращение_к_системным_администраторам


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

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

Не изучал вопрос, насколько их заинтересовала нынешняя технология. Можно 
сделать выводы по авторству в коде модулей. Но если считать, что не 
очень заинтересовала, то и несложно догадаться, почему: тот, кто умеет 
писать скрипты, автоматизировать свою работу, не нуждается в GUI, в 
конфигураторах. Таким грамотным админам наоборот не хватает возможностей 
штатных конфигураторов и они делают свою автоматизацию.

Если же ориентироваться на людей, не умеющих программировать, не умеющих 
грамотно формулировать ТЗ, дать им возможность отрисовать нужный 
интерфейс и сделать к нему краткое описание, то дописать за них бэкенд 
агента нам будет проще, чем как сейчас делать два разных GUI на guile.

Админы на местах разными бывают. Некоторые работают в крупных 
интеграторах. Если технология простая, а задача большая и сложная, если 
таких интеграторов много, от нас требуется минимум консультаций и 
поддержки, помощь только с hello world. И что-то качественное и 
востребованное из этого может стать частью нашего репозитория -- чтобы 
мы поддерживали и для упрощения доступности.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Anton Farygin]

On 15.10.2024 04:11, Leonid Krivoshein wrote:
>
>
> On 10/15/24 00:57, Антон Мидюков wrote:
>> 15.10.2024 00:23, Leonid Krivoshein пишет:
>>> On 10/14/24 22:57, Evgeny Sinelnikov wrote:
>>>> Доброй ночи,
>>>>
>>>> хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
>>>> ориентироваться на конструктивные предложения. Архитектурных 
>>>> решений не так много, на самом деле. Архитектурных решений 
>>>> реализуемых в разумные сроки еще меньше.
>>>>
>>> Только здесь основная цель -- не сам конфигуратор, а множество 
>>> работающих в нём модулей, т.е. если в разумные сроки мы сможем 
>>> создавать несколько новых модулей, если к этому можно будет 
>>> подключить множество разработчиков, если технология будет интересна 
>>> не только нам, но и админам "на местах".
>>>
>> Про админов "на местах" я уже где-то слышал. Ах, да:
>> https://www.altlinux.org/Alterator#Обращение_к_системным_администраторам
>
> Не изучал вопрос, насколько их заинтересовала нынешняя технология. 
> Можно сделать выводы по авторству в коде модулей. Но если считать, что 
> не очень заинтересовала, то и несложно догадаться, почему: тот, кто 
> умеет писать скрипты, автоматизировать свою работу, не нуждается в 
> GUI, в конфигураторах. Таким грамотным админам наоборот не хватает 
> возможностей штатных конфигураторов и они делают свою автоматизацию.
>
> Если же ориентироваться на людей, не умеющих программировать, не 
> умеющих грамотно формулировать ТЗ, дать им возможность отрисовать 
> нужный интерфейс и сделать к нему краткое описание, то дописать за них 
> бэкенд агента нам будет проще, чем как сейчас делать два разных GUI на 
> guile.
>
> Админы на местах разными бывают. Некоторые работают в крупных 
> интеграторах. Если технология простая, а задача большая и сложная, 
> если таких интеграторов много, от нас требуется минимум консультаций и 
> поддержки, помощь только с hello world. И что-то качественное и 
> востребованное из этого может стать частью нашего репозитория -- чтобы 
> мы поддерживали и для упрощения доступности.
>
>
Не надо делать заново ошибок и ориентироваться на "грамотных 
пользователей умеющих писать скрипты" и "админов, которые будут писать 
модули альтератора".

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

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Michael Shigorin]

On Tue, Oct 15, 2024 at 07:49:59AM +0300, Anton Farygin wrote:
> > Админы на местах разными бывают. Некоторые работают в крупных
> > интеграторах. Если технология простая, а задача большая и
> > сложная, если таких интеграторов много, от нас требуется
> > минимум консультаций и поддержки, помощь только с hello
> > world. И что-то качественное и востребованное из этого может
> > стать частью нашего репозитория -- чтобы мы поддерживали и
> > для упрощения доступности.
> Не надо делать заново ошибок и ориентироваться на "грамотных
> пользователей умеющих писать скрипты" и "админов, которые будут
> писать модули альтератора".

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

Западная мне лично кажется тупиковой, да и линукс до своего
пика в ~2010 вырос по сути по восточной.

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

Примеры подобного и у нас нечасто, но бывают:
http://bugzilla.altlinux.org/38146

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

Думаю, здесь стоит посмотреть список авторов коммитов в alterator*
и сверить со списком сотрудников альта/базальта; прилагаю выхлоп

mike@team /gears/a $ for i in alterator*git; do
  cd $i && { git log sisyphus 2>/dev/null || git log \
  $(git branch | grep old/sisyphus | head -1); } |
  sed -rn 's,^Author:.*<(.*)@altlinux.*$,\1,p' \
  || echo $i; cd ..; done | sort -u

(сходу radik@, rom_as@, snejok@, wrar@ -- из сообщества)

Как минимум я принимал относительно активное участие именно как
админ; интересу и желания что-то ещё отложенное сделать прибывало
по мере того, как альтератор улучшали inger@ и slazav@ (особенно
воодушевили труды Славы по причёсыванию и документированию),
а так -- работает и ладно.

Любой желающий поменять инсталятор должен начать с задачи разбивки
по той простой причине, что если его элементная база не будет её
реализацию обеспечивать -- затянется ещё лет на пять.

Ну и да, своя шина плюс отдельный язык для системной задачи сильно
лучше закладки на dbus и python: кто работал с серверами по IPMI
и понимает термин "сторонний канал управления" (out-of-band),
тому это может быть ближе.

А в целом ничего нового: что любят и делают -- то и растёт.

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

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Denis Medvedev]

On Tue, 15 Oct 2024 12:44:38 +0300
Michael Shigorin <mike@altlinux.org> wrote:

> On Tue, Oct 15, 2024 at 07:49:59AM +0300, Anton Farygin wrote:
> > > Админы на местах разными бывают. Некоторые работают в крупных
> > > интеграторах. Если технология простая, а задача большая и
> > > сложная, если таких интеграторов много, от нас требуется
> > > минимум консультаций и поддержки, помощь только с hello
> > > world. И что-то качественное и востребованное из этого может
> > > стать частью нашего репозитория -- чтобы мы поддерживали и
> > > для упрощения доступности.
> > Не надо делать заново ошибок и ориентироваться на "грамотных
> > пользователей умеющих писать скрипты" и "админов, которые будут
> > писать модули альтератора".
> 
> Долгосрочно тут выбор между западной моделью (клиент-сервер,
> потребитель-вендор) и восточной (соучастие в сотворении).
> 
> Западная мне лично кажется тупиковой, да и линукс до своего
> пика в ~2010 вырос по сути по восточной.
> 
> Если мы собираемся идти "как там" -- это инструментарий, API,
> документация, поддержка.  Если "как тут" -- это они же, но не
> в ключе "жри что дают", а с прямым и ясным призывом вспомнить
> свои инженерные способности и наконец реализовать их; не ждать
> у вендора патча, а сделать хотя бы его набросок.
> 
> Примеры подобного и у нас нечасто, но бывают:
> http://bugzilla.altlinux.org/38146
> 
> > Использование инструментов конфигурирования - это часть работы
> > и тех и других, но странно ожидать от них активного участия в
> > разработке.
> 
> Думаю, здесь стоит посмотреть список авторов коммитов в alterator*
> и сверить со списком сотрудников альта/базальта; прилагаю выхлоп
> 
> mike@team /gears/a $ for i in alterator*git; do
>   cd $i && { git log sisyphus 2>/dev/null || git log \
>   $(git branch | grep old/sisyphus | head -1); } |
>   sed -rn 's,^Author:.*<(.*)@altlinux.*$,\1,p' \
>   || echo $i; cd ..; done | sort -u
> 
> (сходу radik@, rom_as@, snejok@, wrar@ -- из сообщества)
> 
> Как минимум я принимал относительно активное участие именно как
> админ; интересу и желания что-то ещё отложенное сделать прибывало
> по мере того, как альтератор улучшали inger@ и slazav@ (особенно
> воодушевили труды Славы по причёсыванию и документированию),
> а так -- работает и ладно.
> 
> Любой желающий поменять инсталятор должен начать с задачи разбивки
> по той простой причине, что если его элементная база не будет её
> реализацию обеспечивать -- затянется ещё лет на пять.
> 
> Ну и да, своя шина плюс отдельный язык для системной задачи сильно
> лучше закладки на dbus и python: кто работал с серверами по IPMI
> и понимает термин "сторонний канал управления" (out-of-band),
> тому это может быть ближе.
Может быть запустить хотя бы свой собственный экземпляр dbus чисто для
целей управления а не паразитировать на общесистемном, кстати?
> 
> А в целом ничего нового: что любят и делают -- то и растёт.
> 



-- 

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/15/24 12:44, Michael Shigorin wrote:
> Долгосрочно тут выбор между западной моделью (клиент-сервер,
> потребитель-вендор) и восточной (соучастие в сотворении).
>
> Западная мне лично кажется тупиковой, да и линукс до своего
> пика в ~2010 вырос по сути по восточной.

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


> Как минимум я принимал относительно активное участие именно как
> админ; интересу и желания что-то ещё отложенное сделать прибывало
> по мере того, как альтератор улучшали inger@ и slazav@ (особенно
> воодушевили труды Славы по причёсыванию и документированию),
> а так -- работает и ладно.

А slavaz@ это не тот, что рефакторил mc? Кажется, ему я отправлял пару 
коммитов через LOR.))


> Любой желающий поменять инсталятор должен начать с задачи разбивки
> по той простой причине, что если его элементная база не будет её
> реализацию обеспечивать -- затянется ещё лет на пять.

Над этой задачей думал много лет, но не было времени сесть за неё 
капитально. Сейчас всё поменялось и есть понимание, как сделать замену 
evms. Пока только примеряюсь к инструментальной части. Так что до 
инсталлятора нам ещё очень далеко. Но если evms устраивает в качестве 
бэкенда (а у него есть полноценный CLI), или если взять другие 
аналогичные решения (blivet, libstorage-ng), то меня можно не ждать. :-)


-- 
WBR, Leonid Krivoshein.

[devel-distro] Re: Интерфейсы для инсталлятора на базе альтератор 2.0

[Sergey V Turchin]

On Wednesday, 16 October 2024 03:25:37 MSK Leonid Krivoshein wrote:

[...]
> Хоть какая-то польза от потребителей: пусть творят прямо в браузере
> своего телефона, даже не выходя из туалета. :-)
Будем патчить Blink под E2K в сортире. ;-)

[...]

-- 
Regards, Sergey.

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/15/24 07:49, Anton Farygin wrote:
> On 15.10.2024 04:11, Leonid Krivoshein wrote:
>>
>>
>> On 10/15/24 00:57, Антон Мидюков wrote:
>>> 15.10.2024 00:23, Leonid Krivoshein пишет:
>>>> On 10/14/24 22:57, Evgeny Sinelnikov wrote:
>>>>> Доброй ночи,
>>>>>
>>>>> хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы 
>>>>> ориентироваться на конструктивные предложения. Архитектурных 
>>>>> решений не так много, на самом деле. Архитектурных решений 
>>>>> реализуемых в разумные сроки еще меньше.
>>>>>
>>>> Только здесь основная цель -- не сам конфигуратор, а множество 
>>>> работающих в нём модулей, т.е. если в разумные сроки мы сможем 
>>>> создавать несколько новых модулей, если к этому можно будет 
>>>> подключить множество разработчиков, если технология будет интересна 
>>>> не только нам, но и админам "на местах".
>>>>
>>> Про админов "на местах" я уже где-то слышал. Ах, да:
>>> https://www.altlinux.org/Alterator#Обращение_к_системным_администраторам 
>>>
>>
>> Не изучал вопрос, насколько их заинтересовала нынешняя технология. 
>> Можно сделать выводы по авторству в коде модулей. Но если считать, 
>> что не очень заинтересовала, то и несложно догадаться, почему: тот, 
>> кто умеет писать скрипты, автоматизировать свою работу, не нуждается 
>> в GUI, в конфигураторах. Таким грамотным админам наоборот не хватает 
>> возможностей штатных конфигураторов и они делают свою автоматизацию.
>>
>> Если же ориентироваться на людей, не умеющих программировать, не 
>> умеющих грамотно формулировать ТЗ, дать им возможность отрисовать 
>> нужный интерфейс и сделать к нему краткое описание, то дописать за 
>> них бэкенд агента нам будет проще, чем как сейчас делать два разных 
>> GUI на guile.
>>
>> Админы на местах разными бывают. Некоторые работают в крупных 
>> интеграторах. Если технология простая, а задача большая и сложная, 
>> если таких интеграторов много, от нас требуется минимум консультаций 
>> и поддержки, помощь только с hello world. И что-то качественное и 
>> востребованное из этого может стать частью нашего репозитория -- 
>> чтобы мы поддерживали и для упрощения доступности.
>>
>>
> Не надо делать заново ошибок и ориентироваться на "грамотных 
> пользователей умеющих писать скрипты" и "админов, которые будут писать 
> модули альтератора".
>
> Использование инструментов конфигурирования - это часть работы и тех и 
> других, но странно ожидать от них активного участия в разработке.
>

Тем не менее, есть много примеров, когда люди из совершенно другой 
предметной области овладевают простым инструментом визуального 
проектирования и делают для себя автоматизацию, не дожидаясь 
программистов. Когда-то Microsoft сделала ставку на VBA и подобные вещи, 
в нашем мире это реально работает.


-- 
WBR, Leonid Krivoshein.

[devel-distro] Re: Интерфейсы для инсталлятора на базе альтератор 2.0

[Sergey V Turchin]

On Tuesday, 15 October 2024 22:29:07 MSK Leonid Krivoshein wrote:

[...]
> Тем не менее, есть много примеров, когда люди из совершенно другой
> предметной области овладевают простым инструментом визуального
> проектирования и делают для себя автоматизацию, не дожидаясь
> программистов. Когда-то Microsoft сделала ставку на VBA и подобные вещи,
> в нашем мире это реально работает.
Я видел к это работает! Главный технолог выстроил всю цепочку от технологов до 
станочников на Excel и это потом тупило и глючило на всё пути со всей 
возможной и невозможной силой.

-- 
Regards, Sergey.

[devel-distro] [JT] мировоззренческое по путям развития

[Michael Shigorin]

On Thu, Oct 17, 2024 at 10:27:27AM +0300, Sergey V Turchin wrote:
> > Тем не менее, есть много примеров, когда люди из совершенно
> > другой предметной области овладевают простым инструментом
> > визуального проектирования и делают для себя автоматизацию,
> > не дожидаясь программистов. Когда-то Microsoft сделала ставку
> > на VBA и подобные вещи, в нашем мире это реально работает.

В мире, который усердно строят гейтсы всякие --
реально *хреново* работает, ага.

> Я видел к это работает! Главный технолог выстроил всю цепочку
> от технологов до станочников на Excel и это потом тупило и
> глючило на всё пути со всей возможной и невозможной силой.

И я видел -- как цельная контора нашлёпала систему автоматизации
химпрома на Access, а потом заказчик упёрся в два миллиона строк.

Вот эти "нацарюваты сто рублыкив" имеют общее прям по АЕНу[1]:
жадность и непрофессионализм.

Альт всю дорогу выезжал именно на противоположном.

И России в целом сейчас стоит предлагать не "автоматизировать,
не включая то, что осталось вместо мозга" -- но восстанавливать,
местами создавать заново ИНЖЕНЕРНУЮ школу на основе ВОСПИТАННОГО,
а не просто обученного человека.

И мы выедем скорее на Альт Платформе, чем на Альт Профессиональном
для полных чайников за 24 часа.  Заботиться о людях -- не значит
потакать их немощам, скорее наоборот: помогать им преодолеть то,
что в любом случае придётся.

[1] http://users.livejournal.com/aen-/110138.html

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

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Evgeny Sinelnikov]

Доброе утро,

ответы на вопросы по теме веба, отправлены в отдельном сообщении:
- https://lists.altlinux.org/pipermail/devel-distro/2024-October/003050.html

Ниже предлагаю продолжить разбор по поводу интерфейсов.


15.10.2024 01:23, Leonid Krivoshein пишет:
>
> On 10/14/24 22:57, Evgeny Sinelnikov wrote: 
[...]
>
>>
>> 14.10.2024 11:17, Sergey V Turchin пишет:
>>> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:
>>>
>>> [...]
>>>>> От
>>>>> механизма, в котором нет, по сути, определенных интерфейсов, к
>>>>> механизму, где их можно задавать, фиксировать, контролировать доступ
>>>>> на уровне каждого отдельного метода и получать возможность написания
>>>>> фронтендов, не требующих выполнения под рутом.
>>>> При этом установить ОС можно только под рутом. И тогда непонятно, 
>>>> зачем
>>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
>>> Если помните, текущий aterator умееет и пользовательские 
>>> настройки(реально
>>> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас
>>> востребовано.
>>>
>>> [...]
>>
>> Удивительное дело. Давайте не будем путать. Общая тенденция создания 
>> безопасных систем приводит к очень сложным в сопровождении решениям, 
>> вроде SELinux. Проблема в том, что приложения под рутом невозможно 
>> проконтролировать иначе. Любое приложение под рутом может всё. И 
>> остаётся только доверять коду и надеяться на то, что этого кода будет 
>> немного и в нем не будет критических уязвимостей.
>>
>> Текущий Альтератор построен на концепции общего набора механизмов 
>> конфигуратора, как в инсталляторе, так и в установленной системе. 
>> Недоработка текущей реализации в этом плане привела к тому, что 
>> графический интерфейс мы вынуждены запускать под рутом. И это, я 
>> полагаю, напрямую связано с тем, что кем-то тоже было сказано или 
>> подумано нечто подобное:
>>
>> "При этом установить ОС можно только под рутом. И тогда непонятно, зачем
>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения."
>>
>
> Совершенно верно. Нет нужды разграничивать доступ в установщике. Нет 
> необходимости запускать графическую часть установщика или 
> конфигуратора под root'ом. Но разграничение прав внутри конфигуратора 
> необходимо, и не только в пределах локальных пользователей хоста. 
> Конфигуратор может не ограничиваться одним хостом.

Всё это звучит ("нет нужды разграничивать доступ в установщике"), как 
оторванные от возможной реализации предположения. При этом 
предполагается что-то недостаточно целостное.

"Установщик", в этом смысле, как что-то вне графической части - это и 
есть набор бекендов + движок исполнения сценариев.

Давайте рассмотрим несколько принципов:

0) от графического интерфейса мы не отказываемся, а его мы под рутом 
(даже если бы это был веб-интерфейс) точно запускать не собираемся.

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

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

3) часть необходимых dbus-бекендов в рамках systemd и других подсистем 
уже везде используется.

4) вне этих бекендов современные Linux-дистрибутивы теряют прикладную 
актуальность.

5) придумывать свой дополнительный протокол, когда уже придуман varlink 
(посмотрим, как пойдёт переезд на него в systemd) тоже пока не имеет смысла.

6) сейчас важнее заниматься бекендами...

Текущие интерфейсы, которые и так есть у всех (с точностью до DE):

$ busctl call org.<TAB><TAB>
org.blueman.Mechanism
org.bluez
org.cinnamon.SettingsDaemon.DateTimeMechanism
org.freedesktop.Accounts
org.freedesktop.Avahi
org.freedesktop.ColorManager
org.freedesktop.DBus
org.freedesktop.DisplayManager
org.freedesktop.Flatpak.SystemHelper
org.freedesktop.fwupd
org.freedesktop.GeoClue2
org.freedesktop.hostname1
org.freedesktop.locale1
org.freedesktop.login1
org.freedesktop.ModemManager1
org.freedesktop.NetworkManager
org.freedesktop.oom1
org.freedesktop.PackageKit
org.freedesktop.PolicyKit1
org.freedesktop.realmd
org.freedesktop.RealtimeKit1
org.freedesktop.sssd.infopipe
org.freedesktop.systemd1
org.freedesktop.timedate1
org.freedesktop.UDisks2
org.freedesktop.UPower
org.gnome.RemoteDesktop.Configuration
org.kde.drkonqi
org.kde.fontinst
org.kde.kcontrol.kcmclock
org.kde.kcontrol.kcmkwallet5
org.kde.kcontrol.kcmlightdm
org.kde.ksysguard.processlisthelper
org.kde.ktexteditor6.katetextbuffer
org.kde.ktexteditor.katetextbuffer
org.kde.powerdevil.backlighthelper
org.kde.powerdevil.chargethresholdhelper
org.kde.powerdevil.discretegpuhelper
org.opensuse.CupsPkHelper.Mechanism

Нам необходимо определиться:

1) Какие интерфейсы из системных (доступных в сизифе) мы переиспользуем?

2) Какие из них мы переписываем?

3) Какие адаптируем под наш стек (tcb, libnss-role, ...)?

4) Какие дополняем собственными, поскольку системных (доступных в 
сизифе) пока что не существует?

______________________

Мешать в одну кучу системные механизмы и удалённый доступ - очень 
странная и непонятная затея.

Что придумано и уже в основных деталях реализовано для удалённого доступа?

Реализован механизм (alterator-module-remote), позволяющий 
автоматизировать удалённое подключение по ssh к объектам и интерфейсам 
через:
- 
https://www.freedesktop.org/software/systemd/man/latest/systemd-stdio-bridge.html

Работает по ключам и krb5-кредам в юзера (если в рута по ключу, так ещё 
проще, но тогда невозможно ограничить доступ), пробрасывает запросы 
polkit'а по сети. В ближайшее время пакеты поедут в сизиф. Так что одним 
хостом оно не ограничивается. Alterator-browser (а также alteratorctl, 
др.) можно будет запустить на другом узле. Но старые legacy-модули так 
не получится пробросить.

Реализовано на сессионной шине-dbus, соответственно работает из-под 
кредов доступных пользователю.

В ближайшее время планируется начать отладку удалённого доступа в 
alteratorctl.

Кроме того, cockpit и аналогичные возможности выставления этого же 
набора интерфейсов иным образом никто не отменяет.

PS: Финальные релизы всего в ближайшее время планируется оформить на 
шине, как /org/altlinux/alterator/* объекты и org.altlinux.alterator.* 
интерфейсы.


-- 
Синельников Евгений Александрович
Руководитель обособленного подразделения
«Инженерный отдел «Саратовский» ООО "Базальт СПО"
тел. +7 (495) 123-47-99 (доб. 531)
моб. тел. +7-917-207-53-96

Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/15/24 08:19, Evgeny Sinelnikov wrote:
> Доброе утро,
>
> ответы на вопросы по теме веба, отправлены в отдельном сообщении:
> - 
> https://lists.altlinux.org/pipermail/devel-distro/2024-October/003050.html
>
> Ниже предлагаю продолжить разбор по поводу интерфейсов.
>
>
> 15.10.2024 01:23, Leonid Krivoshein пишет:
>>
>> On 10/14/24 22:57, Evgeny Sinelnikov wrote: 
> [...]
>>
>>>
>>> 14.10.2024 11:17, Sergey V Turchin пишет:
>>>> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote:
>>>>
>>>> [...]
>>>>>> От
>>>>>> механизма, в котором нет, по сути, определенных интерфейсов, к
>>>>>> механизму, где их можно задавать, фиксировать, контролировать доступ
>>>>>> на уровне каждого отдельного метода и получать возможность написания
>>>>>> фронтендов, не требующих выполнения под рутом.
>>>>> При этом установить ОС можно только под рутом. И тогда непонятно, 
>>>>> зачем
>>>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения.
>>>> Если помните, текущий aterator умееет и пользовательские 
>>>> настройки(реально
>>>> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас
>>>> востребовано.
>>>>
>>>> [...]
>>>
>>> Удивительное дело. Давайте не будем путать. Общая тенденция создания 
>>> безопасных систем приводит к очень сложным в сопровождении решениям, 
>>> вроде SELinux. Проблема в том, что приложения под рутом невозможно 
>>> проконтролировать иначе. Любое приложение под рутом может всё. И 
>>> остаётся только доверять коду и надеяться на то, что этого кода 
>>> будет немного и в нем не будет критических уязвимостей.
>>>
>>> Текущий Альтератор построен на концепции общего набора механизмов 
>>> конфигуратора, как в инсталляторе, так и в установленной системе. 
>>> Недоработка текущей реализации в этом плане привела к тому, что 
>>> графический интерфейс мы вынуждены запускать под рутом. И это, я 
>>> полагаю, напрямую связано с тем, что кем-то тоже было сказано или 
>>> подумано нечто подобное:
>>>
>>> "При этом установить ОС можно только под рутом. И тогда непонятно, 
>>> зачем
>>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения."
>>>
>>
>> Совершенно верно. Нет нужды разграничивать доступ в установщике. Нет 
>> необходимости запускать графическую часть установщика или 
>> конфигуратора под root'ом. Но разграничение прав внутри конфигуратора 
>> необходимо, и не только в пределах локальных пользователей хоста. 
>> Конфигуратор может не ограничиваться одним хостом.
>
> Всё это звучит ("нет нужды разграничивать доступ в установщике"), как 
> оторванные от возможной реализации предположения. При этом 
> предполагается что-то недостаточно целостное.
>

Нет нужды разграничивать доступ в установщике на множество 
пользователей. Установщик запускается под root'ом, и графическая часть, 
если запускается на той же машине, м.б. запущена под обычным 
пользователем. Я просто не вижу смысла обсуждать традиционную 
клиент-серверную архитектуру, это не какое-то делегирование множества 
полномочий разным пользователям.


> "Установщик", в этом смысле, как что-то вне графической части - это и 
> есть набор бекендов + движок исполнения сценариев.
>
> Давайте рассмотрим несколько принципов:
>
> 0) от графического интерфейса мы не отказываемся, а его мы под рутом 
> (даже если бы это был веб-интерфейс) точно запускать не собираемся.
>

Да, это правильный тезис.


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

Логично.


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

Очень спорный тезис. Нет у нас "множества в установщике". В этой 
переписке уже обсуждались плюсы и минусы.


> 3) часть необходимых dbus-бекендов в рамках systemd и других подсистем 
> уже везде используется.
>
> 4) вне этих бекендов современные Linux-дистрибутивы теряют прикладную 
> актуальность.
>

А можно чуть подробнее эти два пункта с примерами? Так не очень понятно.


> 5) придумывать свой дополнительный протокол, когда уже придуман 
> varlink (посмотрим, как пойдёт переезд на него в systemd) тоже пока не 
> имеет смысла.
>

Протокол вообще не нужен, когда в рамках модуля (или кода, 
обеспечивающего некую функциональность) выполняется внутреннее 
разделение на представление интерфейса, данных и исполнительную часть. 
Ты как хочешь, так и организовываешь внутреннее взаимодействие между 
своими частями модуля. Никому больше, кроме самого модуля, дёргать эту 
функциональность не надо, нет смысла для этого навязывать общий протокол 
в обязательном порядке.


> 6) сейчас важнее заниматься бекендами...
>
> Текущие интерфейсы, которые и так есть у всех (с точностью до DE):
>
> $ busctl call org.<TAB><TAB>
> org.blueman.Mechanism
> org.bluez
> org.cinnamon.SettingsDaemon.DateTimeMechanism
> org.freedesktop.Accounts
> org.freedesktop.Avahi
> org.freedesktop.ColorManager
> org.freedesktop.DBus
> org.freedesktop.DisplayManager
> org.freedesktop.Flatpak.SystemHelper
> org.freedesktop.fwupd
> org.freedesktop.GeoClue2
> org.freedesktop.hostname1
> org.freedesktop.locale1
> org.freedesktop.login1
> org.freedesktop.ModemManager1
> org.freedesktop.NetworkManager
> org.freedesktop.oom1
> org.freedesktop.PackageKit
> org.freedesktop.PolicyKit1
> org.freedesktop.realmd
> org.freedesktop.RealtimeKit1
> org.freedesktop.sssd.infopipe
> org.freedesktop.systemd1
> org.freedesktop.timedate1
> org.freedesktop.UDisks2
> org.freedesktop.UPower
> org.gnome.RemoteDesktop.Configuration
> org.kde.drkonqi
> org.kde.fontinst
> org.kde.kcontrol.kcmclock
> org.kde.kcontrol.kcmkwallet5
> org.kde.kcontrol.kcmlightdm
> org.kde.ksysguard.processlisthelper
> org.kde.ktexteditor6.katetextbuffer
> org.kde.ktexteditor.katetextbuffer
> org.kde.powerdevil.backlighthelper
> org.kde.powerdevil.chargethresholdhelper
> org.kde.powerdevil.discretegpuhelper
> org.opensuse.CupsPkHelper.Mechanism
>

В случае d-bus мы можем что-то готовое использовать, чтобы "дёргать", в 
том числе "на лету". Но давайте уж тогда сразу оговорим рамки, где это 
нам удобно и выполнимо, а где наоборот.

D-bus прекрасен, когда нам нужно запустить трек, узнав, что плеер "на 
шине", а он может отправить название трека через тот же d-bus системному 
notifyd. Таких задач в конфигураторе нет, но это основное назначение 
шины IPC в desktop-среде.

Свой d-bus, отдельный от общесистемного... но зачем? Кто и для чего 
будет к этой шине подключаться? В плане безопасности у него и так уже 
есть не только системная, но и отдельная для пользовательского сеанса.

Всё ли в наших ОС завязано на d-bus? Нет. А раз нет, то мы не сможем 
управлять вообще всем через d-bus. Или конфигуратор будет только для 
управления чем-то d-bus'ким? Или мы всё не d-bus'овское будем как-то 
сначала оборачивать в d-bus'овское?

Допустим, мы хотим подтянуть функционал настройки сети в свой 
конфигуратор и продублировали для этого диалоги NetworkManager (прям как 
в установщике Fedora). Мы можем использовать в этом случае d-bus через 
org.freedesktop.NetworkManager, это как проводить операцию через одно 
место автогеном, ведь есть же простой текстовый файл. Я не ярый 
противник d-bus, просто всё, что можно сделать без него, лучше так и 
сделать. Например, я бы отдавал предпочтение работе с простыми 
конфигурационными файлами, нежели чем дёргать интерфейсы через d-bus.

Ниже предлагается совершенно разумная область использования d-bus: мы 
можем взять от системы и сообщества то, что уже готово.


> Нам необходимо определиться:
>
> 1) Какие интерфейсы из системных (доступных в сизифе) мы переиспользуем?
>
> 2) Какие из них мы переписываем?
>
> 3) Какие адаптируем под наш стек (tcb, libnss-role, ...)?
>
> 4) Какие дополняем собственными, поскольку системных (доступных в 
> сизифе) пока что не существует?
>
> ______________________
>
> Мешать в одну кучу системные механизмы и удалённый доступ - очень 
> странная и непонятная затея.
>
> Что придумано и уже в основных деталях реализовано для удалённого 
> доступа?
>
> Реализован механизм (alterator-module-remote), позволяющий 
> автоматизировать удалённое подключение по ssh к объектам и интерфейсам 
> через:
> - 
> https://www.freedesktop.org/software/systemd/man/latest/systemd-stdio-bridge.html
>
> Работает по ключам и krb5-кредам в юзера (если в рута по ключу, так 
> ещё проще, но тогда невозможно ограничить доступ), пробрасывает 
> запросы polkit'а по сети. В ближайшее время пакеты поедут в сизиф. Так 
> что одним хостом оно не ограничивается.

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


> Alterator-browser (а также alteratorctl, др.) можно будет запустить на 
> другом узле. Но старые legacy-модули так не получится пробросить.
>
> Реализовано на сессионной шине-dbus, соответственно работает из-под 
> кредов доступных пользователю.
>
> В ближайшее время планируется начать отладку удалённого доступа в 
> alteratorctl.
>
> Кроме того, cockpit и аналогичные возможности выставления этого же 
> набора интерфейсов иным образом никто не отменяет.
>
> PS: Финальные релизы всего в ближайшее время планируется оформить на 
> шине, как /org/altlinux/alterator/* объекты и org.altlinux.alterator.* 
> интерфейсы.
>

Как уже говорил, труды вокруг d-bus не будут напрасными, просто нужно 
ориентироваться на то, чтобы брать от системы по-максимуму готового, а 
не заставлять разработчиков бэкендов описывать всё через d-bus, добавляя 
к guile ещё один новый барьер сложности. Не нужно стремиться плодить 
фронтенды и бэкенды, тогда и единых интерфейсов между ними не потребуется.


-- 
WBR, Leonid Krivoshein.

[devel-distro] инсталятор как краеугольный камень выбора технологического пути

[Michael Shigorin]

On Mon, Oct 14, 2024 at 11:57:25PM +0400, Evgeny Sinelnikov wrote:
> Текущий Альтератор построен на концепции общего набора механизмов 
> конфигуратора, как в инсталляторе, так и в установленной системе. 
> Недоработка текущей реализации в этом плане привела к тому, что 
> графический интерфейс мы вынуждены запускать под рутом.

Женя, я же тебе говорил на днях -- это чушь полная.

В какой-то момент решили тем, от кого запускается acc,
регулировать то, с какими правами отрабатывает backend
(который запускается службой alteratord, а не мордой).

Насколько помню, пробным модулем был alterator-x11,
который в случае запуска от пользователя лез трогать
не системные настройки, а пользовательские.

В итоге не пошло (в т.ч. трудные годы могли сказаться).

Но _принципиальных_ закладок, которые бы стоили построения
нового чудного мира, на это не было.

Т.е. сделать/вернуть "морда под юзером, бэкенды под рутом"
-- это вопрос переделки (или возвращения, если уже было)
ответа на вопрос "кому и почему можно" с consolehelper
на другой интерфейс к PAM; на шине информации о правах,
насколько опять же помню, уже не было (доверенная).

> "При этом установить ОС можно только под рутом. И тогда
> непонятно, зачем нужны все эти интерфейсы, разделение прав
> и тому подобные усложнения."
> То есть упор был на инсталлятор, а конфигуратор остался как
> есть. А концепт, одних и тех же модулей сохранился.
> 
> Сейчас мы идём от обратного. Сначала конфигуратор, а потом
> инсталлятор.  Хоть под рутом, хоть не под рутом. С другой
> стороны, а в чём, собственно, переусложнение?

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

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

В чём есть как плюсы, так и минусы.

> В графическом виде. При этом консольного (не графического)
> инсталятора у нас так пока и не было сделано.

Его порой 

> А, если нам нужен графический инсталлятор, то графику, в любом
> случае, не стоит запускать под рутом.

Зависит.  Если помнишь, когда-то в альте из коробки рутом
удалённо не пускали вообще никак -- мол, заходите пользователем
и su - ("это пробел минус!"); затем выяснилось, что лишняя точка
возможности _поднятия_ привилегий -- хуже, чем единая точка их
переключения в виде sshd, который и так обязан работать от рута,
и рекомендации сменились на "ходить рутом по ключику".

Графику в нынешнем инсталяторе запускает
installer.git::installer/scripts/install2,
сделать запуск xorg от непривилегированного
пользователя altlinux вполне возможно;
только я не пойму никак, какую именно проблему
разделения привилегий ты решишь, если система
однопользовательская и единственное запущенное
графическое приложение по определению должно иметь
возможность выполнения произвольного кода с euid == 0.

> На текущий момент имеется dbus - не вижу ничего
> противоестественного использовать его в инсталляторе.
> Кстати, как альтернативу, с недавних пор systemd рассматривает
> - https://varlink.org/

Я прекращу своё участие в ALT Linux Team при завязке на systemd.
Можешь считать выражением гражданской позиции в адрес глобалистов.

То, что по этой дорожке ALT неизбежно станет ASP и кончится за
ненадобностью (отсутствие собственных мыслей) при ослаблении
протекционистских мер -- мне и так понятно.

Неясно, зачем с таким упорством пытаться выкорчевать остатки
собственно альтовых технологий, даже не пытаясь их понять --
и тащишь _в фундамент_ технологии кинетического противника,
бишь RHIBM.

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

Задавят ресурсной волной на своей поляне, следующим ходом сам
и скажешь -- "ой, мы три года делали, получилось хуже, чем в
anaconda/calamaris, давайте их и возьмём" (как openmandriva --
там и на dnf перед смертью успели ударно перейти).

Не надо туда лезть.  Куда лезть -- надо думать.
Разведывать -- нужно.  Переть наобум -- нельзя.

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

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/8/24 16:43, Антон Мидюков wrote:
> Доброго времени суток
>
> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0.
>
> По результатам обсуждения я сформулировал следующие тезисы:
>
> 1. Графический интерфейс инсталлятора представляет собой конфигуратор, который создаёт сценарий автоустановки (kickstart-файл)

Типа такого: 
http://www.rhd.ru/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/ch-redhat-config-kickstart.html 
?

Видимо когда-то у нас почти так и задумывалось, но получилось совсем не 
так. Нужна ли совместимость с форматом kickstart? RedHat и на ней 
основанным -- понятно, почему нужна. Формат устаревший, они его тянут по 
нужде, а не от хорошей жизни. Он не подходит как универсальный формат 
для конфигураций при повторных развёртываниях. Достаточно глянуть схему 
описания сложного разбиения дисков. Сейчас для целей массового 
серверного деплоя чаще используют Yaml, реже Toml.

При этом kickstart уже известен и хорошо понятен рынку, только в этом 
его плюс при полной совместимости, которая, скорее всего, недостижима. 
Чтобы не быть голословным, сравните покрытое этой фичей: 
https://github.com/osboot/make-initrd/tree/master/features/kickstart с 
тем, что предлагает офдок RedHad по Kickstart. А без полной 
совместимости ремейк этого старья 20-летней давности теряет смысл.

Но говорить о средствах конфигурирования (видимо dconf-конфигурацией) 
без понимания того, что собой представляет новый конфигуратор, 
бесполезно. Равно как и без обсуждения того, насколько вообще необходимо 
интегрировать конфигуратор в установщик.

Вот концептуальные вопросы по этому разделу:

1.1. Нас устраивает текущий guile формат для файлов ответов? Если нет, 
тогда какой формат и почему?

1.2. Мы хотим возможность заранее сконфигурировать будущую установку без 
инсталлятора в GUI, т.е. отдельную программу в установленной системе, 
создающую файл ответов? Например, как часть будущего конфигуратора.

1.3. Как не повторить ошибок, из-за которых модули установщика и разных 
фронтэндов конфигуратора нельзя использовать во всех окружениях? Другими 
словами: насколько вообще нужно делать часть конфигуратора 
интегрированной в установщик? Может, пусть установщик разворачивает, а 
конфигуратор конфигурирует?

1.4. Разве вебовский UI/UX сейчас не приоритетней? Его давно не проблема 
встраивать в толстые приложения. И хотя этот подпункт скорее про 
конфигуратор, учитывая 1.2 и 1.3, вопрос звучит так: нам интересней 
ограничиться фронтэндом на guile, в т.ч. и дальше заниматься его 
поддержкой, или же интересней использовать простой декларативный язык 
UI/UX или даже готовую рисовалку интерфейсов на декларативном языке?


> 2. Сценарий автоустановки состоит из секций конфигураций, соответствующих бекенду. Если бекенд не доступен, секция конфига пропускается

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


> 3. Один и тот же сценарий автоустановки может использоваться для установки и запуска настройки первого запуска,

Возможно тут есть противоречие с п.7, зависит от того, насколько 
"необязательно". Но главное, конечно, это что настройка первого запуска 
-- другое приложение, выполняющееся в другом окружении уже установленной 
ОС. Если это то же приложение (Installer 2.0), то запускаемое в 
окружении установленной ОС с ключом --firsttime, при котором просто 
жёстко пропускается часть шагов. И это лучше, чем как сейчас дублировать 
код в разных пакетах.

На мой взгляд, важно для всего иметь разумный дефолт. Чтобы его можно 
было поменять в интерактиве, при желании, но без острой необходимости 
проходить какие-то "шаги".


> так как в инсталляторе и установленной системе разный набор бекендов (в установленной системе точно нет модуля разбивки диска).

И поэтому для форматирования флешек используется rosa-imagewriter, для 
работы с имеющимися разделами -- gnome-disk-utility, и т.д. Как раз к 
вопросу 1.3.


> 4. После того, как выполнена конфигурация и нажата кнопка установить (при настройке первого запуска - это Применить), происходит автоустановка. В графическом режиме процесс автоустановки визуализируется отдельным шагом "Установка", а в режиме автоустановки графический интерфейс не запускается и процесс визуализируется текстовыми сообщениями о выполненных операциях.
>
> 5. Установка разделена на две части: собственно установка и настройка при первом запуске.
>
> 5.1 Настройки установки
>
> [...]
>
> 5.2 Настройки первого запуска
>
> [...]
>
> 6. Настройка первого запуска является опциональной
>
> 7. Настройки из пунктов 5.1.1-5.1.7 *необязательно* выполнять при установке, если будет выполняться настройка первого запуска
>
> 8. Настройки выполняются параллельно
>
> 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла.
>
> Предлагаю для начала определиться корректны изложенные тезисы или нет.
>

-- 
WBR, Leonid Krivoshein.

[devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Wednesday, 9 October 2024 04:40:37 MSK Leonid Krivoshein wrote:

[...]
> 1.4. Разве вебовский UI/UX сейчас не приоритетней? Его давно не проблема
> встраивать в толстые приложения.
Проблема. Например, на e2k кроме Gecko/Firefox есть лишь некий libwebkitgtk4, 
который не везде встроишь.
Текущий alterator не зависит от жирного web-движка, который резко поднимает 
системные требования UI и капризен к аппаратным.

[...]

-- 
Regards, Sergey.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

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,
> который не везде встроишь.
> Текущий alterator не зависит от жирного web-движка, который резко поднимает
> системные требования UI и капризен к аппаратным.

Справедливо. Но есть же универсальные декларативщики, начиная с flutter 
или slint. Наверное, таковых не мало, я в них не разбираюсь, но они 
точно умеют из одного исходника делать интерфейс и для Web, и для 
(например) Gtk3/4 или Windows GDI.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] про API и фронтэнды

[Leonid Krivoshein]

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,
>> который не везде встроишь.

Достаточно того, что есть браузер, из него можно конфигурировать систему.


>> Текущий alterator не зависит от жирного web-движка, который резко 
>> поднимает
>> системные требования UI и капризен к аппаратным.
>

Из всего, прошедшего через нас, припоминаю капризы только на mipsel, уже 
нами не поддерживаемом. На нём и правда лагали развесистые веб-движки. 
Мы говорим о десктопных дистрибутивах и встроенном в них конфигураторе. 
Весьма странно ставить такой установщиком с иными требованиями.

Что сейчас очень плохо: различие в функционале ЦУС (acc) и ahttpd (fbi). 
Различия между desktop и web фронтендами. И как ранее было замечено, 
часть будет работать только в среде установщика. Неоправданная 
необходимость умножать затраты на разработку и поддержку.


> Справедливо. Но есть же универсальные декларативщики, начиная с 
> flutter или slint. Наверное, таковых не мало, я в них не разбираюсь, 
> но они точно умеют из одного исходника делать интерфейс и для Web, и 
> для (например) Gtk3/4 или Windows GDI.
>

Откуда вообще взялась необходимость делить фронтенды и придумывать для 
них API? Первоначально автор предполагал возможность появления ещё и 
консольного установщика. Желание иметь только один графический фронтенд 
было, к нему стремились, но не вышло. Не появилось и консольного 
установщика. А раз есть разные компоненты (модули альтератора в виде 
самостоятельных программ или запускаемых скриптов, да ещё и на разных 
языках), требующие интерактивного взаимодействия, то нужен какой-то 
интерфейс между ними, отсюда API woo.

Современный подход также поощряет разделение на бэк и фронт. Большие 
конфигураторы сейчас преобладают в виде веб приложений, это менее 
зависимо от среды рабочего стола и более современно. Среди его 
преимуществ -- нет необходимости тащить графику на сервер, более 
традиционной подход к управлению большой группой машин. Ориентироваться 
на консольный установщик уже поздно в 2024, пусть этот фронтенд 
останется в 80-х.

С единственным фронтендом какой-то обобщённый API становится не нужным. 
Если уж сильно хочется показать два фронтенда, то есть декларативные 
языки, работающие как в десктопном, так и в вебовском окружении.

Организовать работу с единой СУБД -- хранилищем данных конфигурации, для 
каждой стороны проще, чем идти в сторону самоописания API каждого 
модуля. Собственно, модуль и не нужен никому, кроме него самого.

Подписка на изменение каких-то свойств конфигурации через dconf, кроме 
усложнения, имеет ещё два подводных камня. Допустим, мы через 
конфигуратор или dconf-editor поменяли фон рабочего стола и тут же наш 
MATE или Gnome показал это изменение. А теперь то же самое, но через GPO 
на 100500 машин домена. Круто! А что с KDE и Xfce? Нужно адаптеры 
писать? Другой момент: есть изменения, которые нельзя применять, пока не 
будут сделаны все изменения в рамках большой транзакции. Что даст 
подписка подписчику? Может даже поломку системы.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] про API и фронтэнды

[Антон Мидюков]

10.10.2024 22:29, Leonid Krivoshein пишет:
> 
> 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,
>>> который не везде встроишь.
> 
> Достаточно того, что есть браузер, из него можно конфигурировать систему.
> 
> 

Предлагаешь убрать обычный инсталлятор совсем, оставив только автоустановку? У всех есть, а у нас не будет? Нас пользователи не поймут.
Или запускать киоск с веб-браузером, а в нём одна единственную вкладку с инсталлятором?

>>> Текущий alterator не зависит от жирного web-движка, который резко поднимает
>>> системные требования UI и капризен к аппаратным.
>>
> 
> Из всего, прошедшего через нас, припоминаю капризы только на mipsel, уже нами не поддерживаемом. На нём и правда лагали развесистые веб-движки. Мы говорим о десктопных дистрибутивах и встроенном в них конфигураторе. Весьма странно ставить такой установщиком с иными требованиями.
> 

Есть ещё устройства с маленьким экраном, для которых важен адаптивный интерфейс, который можно реализовать на gtk4/libadwaita. Один фронтенд такой для ввода в домен был представлен на конференции. Кроме того, gtk4 приложения могут работать в веб. Так что заманчиво использовать этот стек для написания фронтендов. И этого зоопарка тогда не будет:

> Что сейчас очень плохо: различие в функционале ЦУС (acc) и ahttpd (fbi). Различия между desktop и web фронтендами. И как ранее было замечено, часть будет работать только в среде установщика. Неоправданная необходимость умножать затраты на разработку и поддержку.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] про API и фронтэнды

[Leonid Krivoshein]

On 10/11/24 02:27, Антон Мидюков wrote:
> 10.10.2024 22:29, Leonid Krivoshein пишет:
>> 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,
>>>> который не везде встроишь.
>> Достаточно того, что есть браузер, из него можно конфигурировать систему.
>>
>>
> Предлагаешь убрать обычный инсталлятор совсем, оставив только автоустановку? У всех есть, а у нас не будет? Нас пользователи не поймут.
> Или запускать киоск с веб-браузером, а в нём одна единственную вкладку с инсталлятором?

Речь была о конфигураторе 2.0. Но если он неотъемлемая часть установщика 
2.0, тогда и об установщике.

Тогда для установщика в таком порядке на выбор:

1.4.1. Приложение, работающее с тем же декларативным SDK, что и ЦУП в 
браузере.
1.4.2. Толстое приложение с веб-движком. С т.з. фронтенда оно как бы в 
браузере работает.
1.4.3. Браузер с полноэкранным киоском.
1.4.4. Только серверная часть (ahhtpd/fbi), вывод как с автоустановщиком 
необязателен, управление с другого компьютера.

Для конфигуратора в основной системе:

1.4.5. Браузер.
1.4.6. Только серверная часть (ahhtpd/fbi), управление с другого компьютера.

Оторвать конфигуратор (ЦУП) от установщика считаю хорошей идеей, плюсов 
в этом больше. Установщику какой-то свой конфигуратор, безусловно, 
нужен. Но концептуально они могут быть очень разные, установщик может 
быть вообще вещью в себе, даже модульность необязательна, вполне 
типовое, замкнутое решение.

Кстати, под установщиком я имею ввиду только livecd-installer, другие не 
нужны. Даже, если в livecd не будет кроме него ничего, незачем плодить и 
поддерживать разные установщики.

>>>> Текущий alterator не зависит от жирного web-движка, который резко поднимает
>>>> системные требования UI и капризен к аппаратным.
>> Из всего, прошедшего через нас, припоминаю капризы только на mipsel, уже нами не поддерживаемом. На нём и правда лагали развесистые веб-движки. Мы говорим о десктопных дистрибутивах и встроенном в них конфигураторе. Весьма странно ставить такой установщиком с иными требованиями.
>>
> Есть ещё устройства с маленьким экраном, для которых важен адаптивный интерфейс, который можно реализовать на gtk4/libadwaita. Один фронтенд такой для ввода в домен был представлен на конференции. Кроме того, gtk4 приложения могут работать в веб. Так что заманчиво использовать этот стек для написания фронтендов. И этого зоопарка тогда не будет:
>
>> Что сейчас очень плохо: различие в функционале ЦУС (acc) и ahttpd (fbi). Различия между desktop и web фронтендами. И как ранее было замечено, часть будет работать только в среде установщика. Неоправданная необходимость умножать затраты на разработку и поддержку.

Да, до этого я упомянул slint и flutter. Подозреваю, таких сейчас масса, 
чего не было во времена проектирования нынешнего альтератора. Потому и 
нагородили фронтендов с API. Теперь можно всё очень сильно упростить, 
сделать работу команды разработчиков над модулями конфигуратора 
приятной, получить очень высокую скорость разработки новых модулей. Это 
главная задача при перепроектировании.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] про API и фронтэнды

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

[...]

-- 
Regards, Sergey.

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

[Evgeny Sinelnikov]

Доброй ночи,

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

Я разобрал этот вопрос с 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

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

[Антон Мидюков]

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

IPMI есть только у серверов.
vnc используем на тех же рабочих станциях, когда ничего не помогло и инсталлятор так и не запустился. Тут варианты или автоустановка или vnc. Если машина одна, то ответ очевиден - vnc.
Доступ через веб-браузер актуален для центра усправления системой, а не инсталлятора. Просто раз уж центр управления системой это будет мочь, то почему бы и инсталлятору такую возможность не предоставить.
Я пожалуй согласен, что для инсталлятора это блажь, но для центра управления системой - это необходимость. У нас сейчас какой-никакой, а веб-альтератор есть. Предлагать ставить толстый клиент на ОС отличные от Альта такое себе.

И откуда эта мысль растёт поясню. Нам в любом случае нужен веб-альтератор. Наблюдая, что часть фронтендов у нас только на web, а другая часть только для alterator-browser конечно же приводит в некоторое уныние. И именно поэтому хотелось бы писать один фронтенд и для того и другого сразу.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

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

[Leonid Krivoshein]

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.

Re: [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

[devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Wednesday, 9 October 2024 22:46:36 MSK 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, который не везде встроишь.
> > Текущий alterator не зависит от жирного web-движка, который резко
> > поднимает
> > системные требования UI и капризен к аппаратным.
> 
> Справедливо. Но есть же универсальные декларативщики, начиная с flutter
> или slint. Наверное, таковых не мало, я в них не разбираюсь, но они
> точно умеют из одного исходника делать интерфейс и для Web, и для
> (например) Gtk3/4 или Windows GDI.
Ты перепутал. Qt тоже умеет, только для этого нужет *Web-браузер*. Именно в 
нём проблема.

P.S.
https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing-the-right-framework-for-cross-platform-development-c0ad9f1f174a

-- 
Regards, Sergey.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/14/24 10:22, Sergey V Turchin wrote:
> On Wednesday, 9 October 2024 22:46:36 MSK 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, который не везде встроишь.
>>> Текущий alterator не зависит от жирного web-движка, который резко
>>> поднимает
>>> системные требования UI и капризен к аппаратным.
>> Справедливо. Но есть же универсальные декларативщики, начиная с flutter
>> или slint. Наверное, таковых не мало, я в них не разбираюсь, но они
>> точно умеют из одного исходника делать интерфейс и для Web, и для
>> (например) Gtk3/4 или Windows GDI.
> Ты перепутал. Qt тоже умеет, только для этого нужет *Web-браузер*. Именно в
> нём проблема.

Уже говорил, что:

1. Весьма странно ставить ОС с браузером внутри, если машина этот 
браузер не тянет.
2. Весьма странно управлять большой сетью с какого-то mipsel, который не 
тянет браузер.
3. Мы уже ушли от поддержки платформ, которые не тянут браузер.
4. Но если уж так хочется, чтобы установщик или конфигуратор был не 
[только] в браузере, то достаточно единой кодовой базы для интерфейсов 
фронтендов. А не как сейчас -- этот модуль пишем под один фронтэнд, этот 
под другой.


> P.S.
> https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing-the-right-framework-for-cross-platform-development-c0ad9f1f174a

И даже по этой статье идея с flutter кажется тем, что нам надо для 
конфигуратора. Навскидку flutter видится более подходящим, чем Qt/QML. 
Понятно, что ложки дёгтя прилагаются ко всем бочкам с мёдом, тут важно 
мнение разработчиков, кто с этим непосредственно работает.

P.S.: На сайте есть примеры -- можно не только код почитать, но и тут же 
запустить, заодно проверить, тянет или нет.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Anton Farygin]

On 14.10.2024 22:58, Leonid Krivoshein wrote:
>
> On 10/14/24 10:22, Sergey V Turchin wrote:
>> On Wednesday, 9 October 2024 22:46:36 MSK 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, который не везде встроишь.
>>>> Текущий alterator не зависит от жирного web-движка, который резко
>>>> поднимает
>>>> системные требования UI и капризен к аппаратным.
>>> Справедливо. Но есть же универсальные декларативщики, начиная с flutter
>>> или slint. Наверное, таковых не мало, я в них не разбираюсь, но они
>>> точно умеют из одного исходника делать интерфейс и для Web, и для
>>> (например) Gtk3/4 или Windows GDI.
>> Ты перепутал. Qt тоже умеет, только для этого нужет *Web-браузер*. 
>> Именно в
>> нём проблема.
>
> Уже говорил, что:
>
> 1. Весьма странно ставить ОС с браузером внутри, если машина этот 
> браузер не тянет.
> 2. Весьма странно управлять большой сетью с какого-то mipsel, который 
> не тянет браузер.
> 3. Мы уже ушли от поддержки платформ, которые не тянут браузер.
> 4. Но если уж так хочется, чтобы установщик или конфигуратор был не 
> [только] в браузере, то достаточно единой кодовой базы для интерфейсов 
> фронтендов. А не как сейчас -- этот модуль пишем под один фронтэнд, 
> этот под другой.
>
Леонид, ты отстал от жизни. Браузер давно не нужен на целевом устройстве 
для управления сетью. Браузер нужен на хосте админа.


>
>
>> P.S.
>> https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing-the-right-framework-for-cross-platform-development-c0ad9f1f174a 
>>
>
> И даже по этой статье идея с flutter кажется тем, что нам надо для 
> конфигуратора. Навскидку flutter видится более подходящим, чем Qt/QML. 
> Понятно, что ложки дёгтя прилагаются ко всем бочкам с мёдом, тут важно 
> мнение разработчиков, кто с этим непосредственно работает.
https://shirsh94.medium.com/is-flutter-dead-0f81f2e765d0
>
> P.S.: На сайте есть примеры -- можно не только код почитать, но и тут 
> же запустить, заодно проверить, тянет или нет.
>
>
Сразу на e2k проверяйте, пожалуйста. Начинать надо с упаковки.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/15/24 07:52, Anton Farygin wrote:
> On 14.10.2024 22:58, Leonid Krivoshein wrote:
>>
>> On 10/14/24 10:22, Sergey V Turchin wrote:
>>> On Wednesday, 9 October 2024 22:46:36 MSK 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, который не везде встроишь.
>>>>> Текущий alterator не зависит от жирного web-движка, который резко
>>>>> поднимает
>>>>> системные требования UI и капризен к аппаратным.
>>>> Справедливо. Но есть же универсальные декларативщики, начиная с 
>>>> flutter
>>>> или slint. Наверное, таковых не мало, я в них не разбираюсь, но они
>>>> точно умеют из одного исходника делать интерфейс и для Web, и для
>>>> (например) Gtk3/4 или Windows GDI.
>>> Ты перепутал. Qt тоже умеет, только для этого нужет *Web-браузер*. 
>>> Именно в
>>> нём проблема.
>>
>> Уже говорил, что:
>>
>> 1. Весьма странно ставить ОС с браузером внутри, если машина этот 
>> браузер не тянет.
>> 2. Весьма странно управлять большой сетью с какого-то mipsel, который 
>> не тянет браузер.
>> 3. Мы уже ушли от поддержки платформ, которые не тянут браузер.
>> 4. Но если уж так хочется, чтобы установщик или конфигуратор был не 
>> [только] в браузере, то достаточно единой кодовой базы для 
>> интерфейсов фронтендов. А не как сейчас -- этот модуль пишем под один 
>> фронтэнд, этот под другой.
>>
> Леонид, ты отстал от жизни. Браузер давно не нужен на целевом 
> устройстве для управления сетью. Браузер нужен на хосте админа.
>

Такой вариант я тоже упоминал, просто не в данном контексте (конкретного 
установщика на одиночной станции). И с этим я полностью согласен.


>
>>
>>
>>> P.S.
>>> https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing-the-right-framework-for-cross-platform-development-c0ad9f1f174a 
>>>
>>
>> И даже по этой статье идея с flutter кажется тем, что нам надо для 
>> конфигуратора. Навскидку flutter видится более подходящим, чем 
>> Qt/QML. Понятно, что ложки дёгтя прилагаются ко всем бочкам с мёдом, 
>> тут важно мнение разработчиков, кто с этим непосредственно работает.
> https://shirsh94.medium.com/is-flutter-dead-0f81f2e765d0
>>
>> P.S.: На сайте есть примеры -- можно не только код почитать, но и тут 
>> же запустить, заодно проверить, тянет или нет.
>>
>>
> Сразу на e2k проверяйте, пожалуйста. Начинать надо с упаковки.
>
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro

-- 
WBR, Leonid Krivoshein.

[devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Monday, 14 October 2024 22:58:49 MSK Leonid Krivoshein wrote:

[...]
> Уже говорил, что:
Я тоже примерно об этом.
[...]

> > https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing-t
> > he-right-framework-for-cross-platform-development-c0ad9f1f174a
> И даже по этой статье идея с flutter кажется тем, что нам надо для
> конфигуратора. Навскидку flutter видится
Вскидки то нет. И у меня, но я про неё слышал от того, кто пробовал собрать. И 
исходя из его слов Flutter на порядок проблематичнее, чем Qt WebAssembly. Т.е. 
надо самим пробовать сперва.

> более подходящим, чем 
> Qt/QML.
Qt WebAssembly. QML там лишь один из модулей.

> Понятно, что ложки дёгтя прилагаются ко всем бочкам с мёдом, тут важно
> мнение разработчиков, кто с этим непосредственно работает.
Нет. Мнение того, кто это будет собирать и поддерживать для начала.

-- 
Regards, Sergey.

[devel-distro] Re: Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Tuesday, 15 October 2024 09:33:38 MSK Sergey Turchin wrote:

[...]
> > > https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing
> > > -t
> > > he-right-framework-for-cross-platform-development-c0ad9f1f174a
> > 
> > И даже по этой статье идея с flutter кажется тем, что нам надо для
> > конфигуратора. Навскидку flutter видится
> 
> Вскидки то нет. И у меня, но я про неё слышал от того, кто пробовал собрать.
> И исходя из его слов Flutter на порядок проблематичнее, чем Qt WebAssembly.
> Т.е. надо самим пробовать сперва.
> 
> > более подходящим, чем
> > Qt/QML.
> 
> Qt WebAssembly. QML там лишь один из модулей.
Кстати, текущий alterator-browser-qt можно завернуть в WebAssembly и раздавать 
по Web.

[...]

-- 
Regards, Sergey.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Антон Мидюков]

17.10.2024 10:32, Sergey V Turchin пишет:
> On Tuesday, 15 October 2024 09:33:38 MSK Sergey Turchin wrote:
> 
> [...]
>>>> https://medium.com/@muhammadkhalidkhan/comparing-qt-and-flutter-choosing
>>>> -t
>>>> he-right-framework-for-cross-platform-development-c0ad9f1f174a
>>>
>>> И даже по этой статье идея с flutter кажется тем, что нам надо для
>>> конфигуратора. Навскидку flutter видится
>>
>> Вскидки то нет. И у меня, но я про неё слышал от того, кто пробовал собрать.
>> И исходя из его слов Flutter на порядок проблематичнее, чем Qt WebAssembly.
>> Т.е. надо самим пробовать сперва.
>>
>>> более подходящим, чем
>>> Qt/QML.
>>
>> Qt WebAssembly. QML там лишь один из модулей.
> Кстати, текущий alterator-browser-qt можно завернуть в WebAssembly и раздавать 
> по Web.
> 

Интересно, а можно ли с новым alterator-manager так сделать? Он же тоже на qt5.

А вообще gtk3 и gtk4 приложения могут вполне себе работать в браузере, даже перепаковывать ничего не нужно.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

[devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Thursday, 17 October 2024 10:49:08 MSK Антон Мидюков wrote:

[...]
> > Кстати, текущий alterator-browser-qt можно завернуть в WebAssembly и
> > раздавать по Web.
> 
> Интересно, а можно ли с новым alterator-manager так сделать? Он же тоже на
> qt5.
Теоретически да.

> А вообще gtk3 и gtk4 приложения могут вполне себе работать в браузере, даже
> перепаковывать ничего не нужно.
Возможно, Qt5/6 так же. Точно не скажу, т.к. не пробовал.

-- 
Regards, Sergey.

[devel-distro] qtbrowser vs wasm

[Michael Shigorin]

On Thu, Oct 17, 2024 at 10:32:47AM +0300, Sergey V Turchin wrote:
> > Qt WebAssembly. QML там лишь один из модулей.
> Кстати, текущий alterator-browser-qt можно завернуть
> в WebAssembly и раздавать по Web.

Очень хрупко по платформам -- в частности, на e2k пока
"скорее нет".

Т.е. как дополнительная возможность -- отлично,
но не вместо уже существующего, пожалуйста.

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

[devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Michael Shigorin]

On Mon, Oct 14, 2024 at 10:58:49PM +0300, Leonid Krivoshein wrote:
> 3. Мы уже ушли от поддержки платформ, которые не тянут браузер.

Лёня, люди, которые без браузера в туалет сходить не могут,
уже привели к тому, что заядлые шляпники давно плюются на
минимальные требования инсталятора центоси к _виртуалке_.

Что хорошего было в браузерах -- закончилось примерно с IE6,
когда из средства унифицированного представления разнородной
информации из различных источников браузер по факту стал
платформой исполнения произвольного кода и средством жёсткой
конкурентной борьбы (чуть позже -- ещё и торговли юзером).

А нынешний браузер -- это версталка, дуделка, компилятор как
минимум js (не помню, что там с шейдерами webgl), ну и прочие
баголовки со стучалками, причём в заведомо труднодоступных нам
по отладке объёмах кода (ситуация сравнима разве что с офисом).

Что из этого действительно нужно для установки операционки
на отдельно взятую систему?

В нынешнем qtbrowser знаю ровно одну "фатальную ошибку" --
поддержку только левой кнопки мыши; прямщас она, впрочем,
оказалась фичей на сенсорных устройствах (и alterator-fbi
дизайнили "под lynx", что тоже было ошибкой -- кто с ним
справится, тому подавно удобней ssh).

Кстати, inger@ смотрел на WebKit, когда его втянули в Qt.
Но тащить в альтератор, по счастью, не стали.

> 4. Но если уж так хочется, чтобы установщик или конфигуратор
> был не [только] в браузере, то достаточно единой кодовой базы
> для интерфейсов фронтендов. А не как сейчас -- этот модуль
> пишем под один фронтэнд, этот под другой.

Это уже пробовали -- inger@ с legion@ не осилили.

> Навскидку flutter видится более подходящим, чем Qt/QML. 

Боже упаси нас от вебмакакинга ещё и в фундаменте.
Это "мир" моды -- вчерашняя уже всё, не работает.
Антитехнологии.

PS: "installator" тоже весьма красноречиво, увы.
Жаль тот альт, который мне когда-то понравился.
Впрочем, про молодую шпану уже всё спето ;-)

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

Re: [devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/15/24 13:03, Michael Shigorin wrote:
> Кстати, inger@ смотрел на WebKit, когда его втянули в Qt.
> Но тащить в альтератор, по счастью, не стали.
>
>> 4. Но если уж так хочется, чтобы установщик или конфигуратор
>> был не [только] в браузере, то достаточно единой кодовой базы
>> для интерфейсов фронтендов. А не как сейчас -- этот модуль
>> пишем под один фронтэнд, этот под другой.
> Это уже пробовали -- inger@ с legion@ не осилили.

Думаю, тогда (в начале-середине 2000-х) просто не было такого шикарного 
спектра готовых тулкитов, позволяющих забыть о "веб-не-веб".


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Michael Shigorin]

On Wed, Oct 16, 2024 at 02:49:04AM +0300, Leonid Krivoshein wrote:
> >> 4. Но если уж так хочется, чтобы установщик или конфигуратор
> >> был не [только] в браузере, то достаточно единой кодовой
> >> базы для интерфейсов фронтендов. А не как сейчас --
> >> этот модуль пишем под один фронтэнд, этот под другой.
> > Это уже пробовали -- inger@ с legion@ не осилили.
> Думаю, тогда (в начале-середине 2000-х) просто не было такого
> шикарного спектра готовых тулкитов, позволяющих забыть
> о "веб-не-веб".

Например?

PS пока вспомнил -- ndk++ припоминается в связи с этими пробами
двадцатилетней давности: http://sourceforge.net/projects/ndk-xx
(видимо, того этапа, когда alterator был плюсовым проектом
с guile'выми привязками); и да, в тексте правой кнопки тоже
скорее нет.

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

[devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Wednesday, 9 October 2024 22:46:36 MSK Leonid Krivoshein wrote:

[...]
> есть же универсальные декларативщики, начиная с flutter или slint.
Ещё Qt WebAssembly, но для того чтобы о них пытаться говорить, нужно сначала 
их собрать и попробовать поддерживать, а то Elasticsearch тоже "есть".

> Наверное, таковых не мало, я в них не разбираюсь, но они
> точно умеют из одного исходника делать интерфейс и для Web, и для
> (например) Gtk3/4 или Windows GDI.
В сферическом вакууме точно умеют, гарантирую. Реальность будет отличаться. 
Это не "hellow world", а пирог сверху уже имеющихся UI тулкитов.

-- 
Regards, Sergey.

[devel-distro] Re: Re: Installator 2.0: конфигуратор, создающий kickstart-файл

[Sergey V Turchin]

On Monday, 14 October 2024 10:43:26 MSK Sergey Turchin wrote:
> On Wednesday, 9 October 2024 22:46:36 MSK Leonid Krivoshein wrote:
> 
> [...]
> 
> > есть же универсальные декларативщики, начиная с flutter или slint.
> 
> Ещё Qt WebAssembly, но для того чтобы о них пытаться говорить, нужно сначала
> их собрать и попробовать поддерживать, а то Elasticsearch тоже "есть".
> > Наверное, таковых не мало, я в них не разбираюсь, но они
> > точно умеют из одного исходника делать интерфейс и для Web, и для
> > (например) Gtk3/4 или Windows GDI.
> 
> В сферическом вакууме точно умеют, гарантирую. Реальность будет отличаться.
> Это не "hellow world", а пирог сверху уже имеющихся UI тулкитов.
И ещё жирный веб-браузер сверху. :-)

-- 
Regards, Sergey.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Alexey Gladkov]

On Wed, Oct 09, 2024 at 04:40:37AM +0300, Leonid Krivoshein wrote:
> При этом kickstart уже известен и хорошо понятен рынку, только в этом 
> его плюс при полной совместимости, которая, скорее всего, недостижима. 
> Чтобы не быть голословным, сравните покрытое этой фичей: 
> https://github.com/osboot/make-initrd/tree/master/features/kickstart с 
> тем, что предлагает офдок RedHad по Kickstart. А без полной 
> совместимости ремейк этого старья 20-летней давности теряет смысл.

Ага. Вот только при создании этой фичи никогда не ставилась задача сделать
полное покрытие.

Кроме того, это полное покрытие вам и не требуется.

-- 
Rgrds, legion

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/9/24 12:49, Alexey Gladkov wrote:
> On Wed, Oct 09, 2024 at 04:40:37AM +0300, Leonid Krivoshein wrote:
>> При этом kickstart уже известен и хорошо понятен рынку, только в этом
>> его плюс при полной совместимости, которая, скорее всего, недостижима.
>> Чтобы не быть голословным, сравните покрытое этой фичей:
>> https://github.com/osboot/make-initrd/tree/master/features/kickstart с
>> тем, что предлагает офдок RedHad по Kickstart. А без полной
>> совместимости ремейк этого старья 20-летней давности теряет смысл.
> Ага. Вот только при создании этой фичи никогда не ставилась задача сделать
> полное покрытие.

Это понятно. И хорошо, что у нас есть хоть какой-то kickstart в 
make-initrd для разбивки диска и развёртывания без вопросов прямо из 
stage1. Автоустановщику не требуется графика. Просто напомнил о такой 
возможности.


> Кроме того, это полное покрытие вам и не требуется.

Нам то нет, но для пользователей не полный набор уже не будет привычным 
и пригодным (с их-то наработками), нас этими запросами просто задолбают. 
Поэтому поддержка конкретного формата kickstart в установщике не нужна.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Alexey Gladkov]

On Wed, Oct 09, 2024 at 10:54:03PM +0300, Leonid Krivoshein wrote:
> 
> On 10/9/24 12:49, Alexey Gladkov wrote:
> > On Wed, Oct 09, 2024 at 04:40:37AM +0300, Leonid Krivoshein wrote:
> >> При этом kickstart уже известен и хорошо понятен рынку, только в этом
> >> его плюс при полной совместимости, которая, скорее всего, недостижима.
> >> Чтобы не быть голословным, сравните покрытое этой фичей:
> >> https://github.com/osboot/make-initrd/tree/master/features/kickstart с
> >> тем, что предлагает офдок RedHad по Kickstart. А без полной
> >> совместимости ремейк этого старья 20-летней давности теряет смысл.
> > Ага. Вот только при создании этой фичи никогда не ставилась задача сделать
> > полное покрытие.
> 
> Это понятно. И хорошо, что у нас есть хоть какой-то kickstart в 
> make-initrd для разбивки диска и развёртывания без вопросов прямо из 
> stage1. Автоустановщику не требуется графика. Просто напомнил о такой 
> возможности.

Ты просто сформировал тезис, что без полной совместимости это теряет
смысл. Я с этим не согласен.

> > Кроме того, это полное покрытие вам и не требуется.
> 
> Нам то нет, но для пользователей не полный набор уже не будет привычным 
> и пригодным (с их-то наработками), нас этими запросами просто задолбают.

Я такие аргументы слышу много лет. Откуда ты это знаешь ?

За время существования kickstart redhat его менял и продолжает это делать.
Он конечно старается не ломать сам синтаксис, но функционал команд и опций
у них меняется.

https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#creating-the-kickstart-file

Можешь поискать "Deprecated since" или "Removed in version" по этому
документу. 

Представление о том, что kickstart-файл 10 летней давности применится без
проблем это миф. Тебе в любом случае нужно проверять не устарели ли твои
команды и опции в нём. Разумеется это относится к разным командам в разной
степени (разбивка диска меняется реже).

Цитирую их официальную документацию:

  If deprecated commands, options, or syntax are used during a kickstart
  installation, a warning message will be logged to the anaconda log.
  Since deprecated items are usually removed within a release or two, it
  makes sense to check the installation log to make sure you haven’t
  used any of them. When using ksvalidator, deprecated items will cause
  an error.

> Поэтому поддержка конкретного формата kickstart в установщике не нужна.

Я ещё с Server 4 последовательно выступаю против того чтобы городить "свои
правильные" форматы кикстартера. Их сложно изучать, их никто не описывает,
для них нет примеров.

Именно поддержка конкретного формата kickstart позволяет сделать
кикстартер узнаваемым и привычным пользователю. Я знаю компании, у которых
есть (может быть уже нет) генераторы для redhat kickstarter. В них проще
добавить костыль для другой реализации, чем писать новый генератор.

-- 
Rgrds, legion

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/10/24 12:10, Alexey Gladkov wrote:
> On Wed, Oct 09, 2024 at 10:54:03PM +0300, Leonid Krivoshein wrote:
>> On 10/9/24 12:49, Alexey Gladkov wrote:
>>> On Wed, Oct 09, 2024 at 04:40:37AM +0300, Leonid Krivoshein wrote:
>>>> При этом kickstart уже известен и хорошо понятен рынку, только в этом
>>>> его плюс при полной совместимости, которая, скорее всего, недостижима.
>>>> Чтобы не быть голословным, сравните покрытое этой фичей:
>>>> https://github.com/osboot/make-initrd/tree/master/features/kickstart с
>>>> тем, что предлагает офдок RedHad по Kickstart. А без полной
>>>> совместимости ремейк этого старья 20-летней давности теряет смысл.
>>> Ага. Вот только при создании этой фичи никогда не ставилась задача сделать
>>> полное покрытие.
>> Это понятно. И хорошо, что у нас есть хоть какой-то kickstart в
>> make-initrd для разбивки диска и развёртывания без вопросов прямо из
>> stage1. Автоустановщику не требуется графика. Просто напомнил о такой
>> возможности.
> Ты просто сформировал тезис, что без полной совместимости это теряет
> смысл.

Да, это так.


> Я с этим не согласен.

Но у нас другие реалии.

>>> Кроме того, это полное покрытие вам и не требуется.
>> Нам то нет, но для пользователей не полный набор уже не будет привычным
>> и пригодным (с их-то наработками), нас этими запросами просто задолбают.
> Я такие аргументы слышу много лет. Откуда ты это знаешь ?

Последние годы по работе в техподдержке и совместимости. Условно можно 
считать, что если у заказчика его ks-файл выполняет всё в соответствии с 
ожиданиями на CentOS, РедОС, RHEL и в множестве основанных на RedHat 
дистрибутивов, а у нас это не работает, мы оказываемся в пролёте. Нам 
проще сказать, что здесь у нас не RedHat.


> За время существования kickstart redhat его менял и продолжает это делать.
> Он конечно старается не ломать сам синтаксис, но функционал команд и опций
> у них меняется.
>
> https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#creating-the-kickstart-file
>
> Можешь поискать "Deprecated since" или "Removed in version" по этому
> документу.
>
> Представление о том, что kickstart-файл 10 летней давности применится без
> проблем это миф. Тебе в любом случае нужно проверять не устарели ли твои
> команды и опции в нём. Разумеется это относится к разным командам в разной
> степени (разбивка диска меняется реже).
>
> Цитирую их официальную документацию:
>
>    If deprecated commands, options, or syntax are used during a kickstart
>    installation, a warning message will be logged to the anaconda log.
>    Since deprecated items are usually removed within a release or two, it
>    makes sense to check the installation log to make sure you haven’t
>    used any of them. When using ksvalidator, deprecated items will cause
>    an error.

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

Когда его придумали, это был привычный подход к командам и ключам в 
командной строке. Это команды и опции для конкретной безмолвной 
развёртывалки системы. Это не команды и опции для вызываемых ею 
программ. Потеря семантики, требующая интерпретации и отдельного 
документирования. Это синтаксис конкретной развёртывалки, а не 
конфигурационная база центра управления системой.

>> Поэтому поддержка конкретного формата kickstart в установщике не нужна.
> Я ещё с Server 4 последовательно выступаю против того чтобы городить "свои
> правильные" форматы кикстартера. Их сложно изучать, их никто не описывает,
> для них нет примеров.

Я начинал именно с этого формата, затем пытался подражать, придумывая 
разбивалку диска. Вкупе с вышесказанным мне этот синтаксис не понравился 
ещё и своей громоздкостью, плохой читабельностью. Кусочек по приведённой 
тобой ссылке:

autopart [--encrypted] [--passphrase PASSPHRASE] [--escrowcert <url>]
      [--backuppassphrase] [--nolvm] [--type TYPE] [--cipher CIPHER]
      [--fstype FSTYPE] [--nohome] [--noboot] [--noswap]
      [--luks-version LUKS_VERSION] [--pbkdf PBKDF]
      [--pbkdf-memory PBKDF_MEMORY] [--pbkdf-time PBKDF_TIME]
      [--pbkdf-iterations PBKDF_ITERATIONS] [--hibernation]
      [--hw-passphrase HW_PASSPHRASE]


> Именно поддержка конкретного формата kickstart позволяет сделать
> кикстартер узнаваемым и привычным пользователю.

Нам-то какой смысл делать его узнаваемым?


> Я знаю компании, у которых
> есть (может быть уже нет) генераторы для redhat kickstarter. В них проще
> добавить костыль для другой реализации, чем писать новый генератор.

Важным элементом является возможность сконфигурировать будущее 
развёртывание заранее в графической среде, это уже отмечалось в 
обсуждении. Видимо этим компаниям не хватает какого-то функционала 
штатной system-config-kickstart, раз они делают свои генераторы.

Мы от RedHat унаследовали отсутствие стройной системы конфигурирования. 
В Debian и based есть debconf и dpkg-reconfigure, решающие задачу 
управления конфигурацией пакетов отдельно от пакетной базы, делающие 
возможным использовать один и тот же пакет в разных конфигурациях или 
менять его настройки через фронтэнды, не внося порчу в целостность 
системы. Установщик Debian -- это набор вызовов dpkg-reconfigure.

И наш текущий конфигуратор (альтератор) ничего такого не предоставляет. 
У каждого модуля есть что-то где-то своё. И у RedHat изначально был 
только /etc/sysconfig со значимыми переменными конфигурации для 
стартовых скриптов, и множество пакетов system-config-SOMETHING, в 
какой-то степени аналог наших модулей альтератора, 
system-config-kickstart -- один из таких модулей, позволяющий 
сгенерировать ks-файл для безмолвной развёртывалки.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Alexey Gladkov]

On Thu, Oct 10, 2024 at 03:21:06PM +0300, Leonid Krivoshein wrote:
> 
> On 10/10/24 12:10, Alexey Gladkov wrote:
> > On Wed, Oct 09, 2024 at 10:54:03PM +0300, Leonid Krivoshein wrote:
> >> On 10/9/24 12:49, Alexey Gladkov wrote:
> >>> On Wed, Oct 09, 2024 at 04:40:37AM +0300, Leonid Krivoshein wrote:
> >>>> При этом kickstart уже известен и хорошо понятен рынку, только в этом
> >>>> его плюс при полной совместимости, которая, скорее всего, недостижима.
> >>>> Чтобы не быть голословным, сравните покрытое этой фичей:
> >>>> https://github.com/osboot/make-initrd/tree/master/features/kickstart с
> >>>> тем, что предлагает офдок RedHad по Kickstart. А без полной
> >>>> совместимости ремейк этого старья 20-летней давности теряет смысл.
> >>> Ага. Вот только при создании этой фичи никогда не ставилась задача сделать
> >>> полное покрытие.
> >> Это понятно. И хорошо, что у нас есть хоть какой-то kickstart в
> >> make-initrd для разбивки диска и развёртывания без вопросов прямо из
> >> stage1. Автоустановщику не требуется графика. Просто напомнил о такой
> >> возможности.
> > Ты просто сформировал тезис, что без полной совместимости это теряет
> > смысл.
> 
> Да, это так.
> 
> 
> > Я с этим не согласен.
> 
> Но у нас другие реалии.

А, реалии.

Да, ты прав. Я лезу в уже не свой монастырь.

Пока это не коснётся меня воздержусь от дальнейших комментариев.

-- 
Rgrds, legion

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Ivan A. Melnikov]

On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
> Доброго времени суток
> 

> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
> каким должен быть новый инсталлятор на базе альтератор 2.0.

Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
обсуждении, на днях я доказывал sin@, что нужно делать примерно
то же самое.

> По результатам обсуждения я сформулировал следующие тезисы:

> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
> который создаёт сценарий автоустановки (kickstart-файл)

Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
Поэтому я предлагаю придумать этому файлу другой формат и название.
Взяв у коллег лучшее, естественно.

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

> 2. Сценарий автоустановки состоит из секций конфигураций,
> соответствующих бекенду. Если бекенд не доступен, секция конфига
> пропускается

С этим пунктом я не согласен. Лучше явно помечать, в каких условиях должен
выполняться каждый шаг. Во-первых, explicit is better than implicit (c).
Во-вторых, это позволит конфигуратору (графическому, хотя и не
обязательно) не пытаться идти и выяснять, какие бекенды есть, а просто
делать свою работу.

В целом, конфигуратор я представляю себе как инструмент, получающий
на вход шаблон сценария автоустановки и, возможно, режим работы
(установка/настройка первого запуска/...), и дозаполняющий в нужных
шагах необходимые поля. Грубо говоря, файл на входе, файл на выходе.
Легко писать, легко тестировать, легко пилить альтернативные
реализации.

> 3. Один и тот же сценарий автоустановки может использоваться для
> установки и запуска настройки первого запуска [...]

Опять же да, но мне кажется, что если нужного бекенда нет, это
ошибка, а применимость шага в конкретном сценарии должна быть
явно отмечена.

> 8. Настройки выполняются параллельно

Это важно и было бы круто. Нужно продумать, могут ли быть
зависимости между шагами установки, помимо очевидной
зависимости ВСЕГО от разбивки диска и установки пакетов.
На первый взгляд не вижу ничего такого.

-- 
  wbr,
    iv m.

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Антон Мидюков]

09.10.2024 09:19, Ivan A. Melnikov пишет:
> On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
>> Доброго времени суток
>>
> 
>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
>> каким должен быть новый инсталлятор на базе альтератор 2.0.
> 
> Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
> обсуждении, на днях я доказывал sin@, что нужно делать примерно
> то же самое.
> 
>> По результатам обсуждения я сформулировал следующие тезисы:

Это  скорее конспект тех мыслей, что озвучивались, то есть не мои мысли.

> 
>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>> который создаёт сценарий автоустановки (kickstart-файл)
> 
> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
> Поэтому я предлагаю придумать этому файлу другой формат и название.
> Взяв у коллег лучшее, естественно.
> 
> Формат должен быть документирован, его корректность и наличие
> всех необходимых полей должны быть проверяемы программно (т.е.
> нужна схема).
> 

Согласен.

>> 2. Сценарий автоустановки состоит из секций конфигураций,
>> соответствующих бекенду. Если бекенд не доступен, секция конфига
>> пропускается
> 
> С этим пунктом я не согласен. Лучше явно помечать, в каких условиях должен
> выполняться каждый шаг. Во-первых, explicit is better than implicit (c).
> Во-вторых, это позволит конфигуратору (графическому, хотя и не
> обязательно) не пытаться идти и выяснять, какие бекенды есть, а просто
> делать свою работу.
> 
> В целом, конфигуратор я представляю себе как инструмент, получающий
> на вход шаблон сценария автоустановки и, возможно, режим работы
> (установка/настройка первого запуска/...), и дозаполняющий в нужных
> шагах необходимые поля. Грубо говоря, файл на входе, файл на выходе.
> Легко писать, легко тестировать, легко пилить альтернативные
> реализации.
> 

Мне эта идея нравится.

>> 3. Один и тот же сценарий автоустановки может использоваться для
>> установки и запуска настройки первого запуска [...]
> 
> Опять же да, но мне кажется, что если нужного бекенда нет, это
> ошибка, а применимость шага в конкретном сценарии должна быть
> явно отмечена.
> 

Наш старый альтератор, кстати, пропускает недоступные шаги.
Но да, лучше определять формат на входе. Можно опциональность в параметре определять, то есть на входе.

>> 8. Настройки выполняются параллельно
> 
> Это важно и было бы круто. Нужно продумать, могут ли быть
> зависимости между шагами установки, помимо очевидной
> зависимости ВСЕГО от разбивки диска и установки пакетов.
> На первый взгляд не вижу ничего такого.
> 

На этапе конфигурирования зависимостей быть не должно. Шаги должны располагаться в плане удобства. Я пока слабо представляю, как это всё удобно сделать в плане UI.
Видимо, должен быть отдельный конфиг определяющий их расположение. Но это будет зависеть от того, как будет выглядеть UI.
Шаг выбора языка должен быть выбран при старте, чтобы можно было задать нужный язык инсталлятора, как сейчас. 
А вот на этапе установки, то есть интерпретирования, можно выполнять секции по очереди, тем самым и задавать порядок.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

[devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0

[Sergey V Turchin]

On Wednesday, 9 October 2024 09:19:04 MSK Ivan Melnikov wrote:

[...]
> > 8. Настройки выполняются параллельно
> Это важно и было бы круто. Нужно продумать, могут ли быть
> зависимости между шагами установки, помимо очевидной
> зависимости ВСЕГО от разбивки диска и установки пакетов.
> На первый взгляд не вижу ничего такого.
Ещё есть давно желание сделать как уже у многих: общее резюме, где можно войти 
в любой раздел установки, а можно не ходить, если установщик сам смог всё 
придумать и ни ничего не помечено красным.

-- 
Regards, Sergey.

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/9/24 12:21, Sergey V Turchin wrote:
> On Wednesday, 9 October 2024 09:19:04 MSK Ivan Melnikov wrote:
>
> [...]
>>> 8. Настройки выполняются параллельно
>> Это важно и было бы круто. Нужно продумать, могут ли быть
>> зависимости между шагами установки, помимо очевидной
>> зависимости ВСЕГО от разбивки диска и установки пакетов.
>> На первый взгляд не вижу ничего такого.
> Ещё есть давно желание сделать как уже у многих: общее резюме, где можно войти
> в любой раздел установки, а можно не ходить, если установщик сам смог всё
> придумать и ни ничего не помечено красным.

+1

Задача установщика в ожидании пользователя -- подготовить место для 
развёртывания и развернуть, и даже для этого допустимы дефолты. 
Протопывание шагов в обязательном порядке -- это конец 90-х.


Другая давняя хотелка не только для установщика, но и для дистрибутивов 
-- дружественность к людям с ограниченными возможностями. Установщики 
MacOS X ещё в 2000-ых начинали установку с проговаривания приветствия на 
разных языках. Попробовал разные отечественные ИИ технологии речевого 
синтеза и ввода, был сильно удивлён прорыву... сейчас вообще можно всё 
голосом сделать, при наличии интернета и API-ключа, и это буквально 
несколько строчные скрипты.


-- 
WBR, Leonid Krivoshein.

[devel-distro] о голосовом управлении (was: Тезисы для инст, альтератор 2.0)

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Wed, Oct 09, 2024 at 04:08:08PM +0300, Leonid Krivoshein wrote:
> ещё в 2000-ых начинали установку с проговаривания приветствия на разных
> языках. Попробовал разные отечественные ИИ технологии речевого синтеза и
> ввода, был сильно удивлён прорыву... сейчас вообще можно всё голосом
> сделать, при наличии интернета и API-ключа, и это буквально несколько
> строчные скрипты.

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

(Не-on-prem — это программные компоненты вне контроля пользователя,
например, aaS на хостинге у дяди, который вне воли альт-сообщества и
воли пользователя могут оторвать в любой момент. Может быть, есть термин
точнее и понятнее.)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel-distro] о голосовом управлении

[Антон Мидюков]

09.10.2024 16:56, Arseny Maslennikov пишет:
> On Wed, Oct 09, 2024 at 04:08:08PM +0300, Leonid Krivoshein wrote:
>> ещё в 2000-ых начинали установку с проговаривания приветствия на разных
>> языках. Попробовал разные отечественные ИИ технологии речевого синтеза и
>> ввода, был сильно удивлён прорыву... сейчас вообще можно всё голосом
>> сделать, при наличии интернета и API-ключа, и это буквально несколько
>> строчные скрипты.
> 
> Можно, но, воплощая это всё, стоит не забыть и о безопасности тех
> пользователей, кто в проговаривалках не нуждается, а так же о доле
> обязательных несвободных и не-on-prem компонентов в системе (чем ближе
> она к нулю, тем лучше).
> 
> (Не-on-prem — это программные компоненты вне контроля пользователя,
> например, aaS на хостинге у дяди, который вне воли альт-сообщества и
> воли пользователя могут оторвать в любой момент. Может быть, есть термин
> точнее и понятнее.)
> 

Я могу ошибаться, но необходимости встраивать подобные средства в инсталлятор нет.
Проблема ровно в том, что наш инсталлятор запускается таким образом, что запустить специальные утилиты невозможно.
Необходимо уйти от запуска xinit'ом к запуску некоторой сессии logind или seatd, в которой можно будет запускать дополнительные утилиты.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

[devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0

[Sergey V Turchin]

On Wednesday, 9 October 2024 16:08:08 MSK Leonid Krivoshein wrote:

[...]
> Другая давняя хотелка не только для установщика, но и для дистрибутивов
> -- дружественность к людям с ограниченными возможностями.
alterator-briwser-qt давно уже кое-как умеет разговаривать в начальном виде. Я 
этот код не удалял.

[...]

-- 
Regards, Sergey.

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/9/24 09:19, Ivan A. Melnikov wrote:
> On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
>> Доброго времени суток
>>
>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
>> каким должен быть новый инсталлятор на базе альтератор 2.0.
> Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
> обсуждении, на днях я доказывал sin@, что нужно делать примерно
> то же самое.
>
>> По результатам обсуждения я сформулировал следующие тезисы:
>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>> который создаёт сценарий автоустановки (kickstart-файл)
> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
> Поэтому я предлагаю придумать этому файлу другой формат и название.
> Взяв у коллег лучшее, естественно.
>
> Формат должен быть документирован, его корректность и наличие
> всех необходимых полей должны быть проверяемы программно (т.е.
> нужна схема).

Да. Yaml. СхемЫ тоже на Yaml. Есть возражения? Во множественном, т.к. 
модульность, схемы будут разделены по пакетам. Важна строгая типизация, 
давно обсуждали это и кажется Иван Захарящев даже что-то делал для этого 
с woo.

Но. Многое зависит от того, что будет с конфигуратором, какими данными 
он будет манипулировать и будет ли он связан с установщиком.

>> 2. Сценарий автоустановки состоит из секций конфигураций,
>> соответствующих бекенду. Если бекенд не доступен, секция конфига
>> пропускается
> С этим пунктом я не согласен. Лучше явно помечать, в каких условиях должен
> выполняться каждый шаг. Во-первых, explicit is better than implicit (c).
> Во-вторых, это позволит конфигуратору (графическому, хотя и не
> обязательно) не пытаться идти и выяснять, какие бекенды есть, а просто
> делать свою работу.
>
> В целом, конфигуратор я представляю себе как инструмент, получающий
> на вход шаблон сценария автоустановки и, возможно, режим работы
> (установка/настройка первого запуска/...), и дозаполняющий в нужных
> шагах необходимые поля. Грубо говоря, файл на входе, файл на выходе.
> Легко писать, легко тестировать, легко пилить альтернативные
> реализации.

Да. Только не конфигуратор, а установщик. Или уж тогда та часть 
установщика, что отвечает за ручное конфигурирование.

>> 3. Один и тот же сценарий автоустановки может использоваться для
>> установки и запуска настройки первого запуска [...]
> Опять же да, но мне кажется, что если нужного бекенда нет, это
> ошибка, а применимость шага в конкретном сценарии должна быть
> явно отмечена.
>
>> 8. Настройки выполняются параллельно
> Это важно и было бы круто. Нужно продумать, могут ли быть
> зависимости между шагами установки, помимо очевидной
> зависимости ВСЕГО от разбивки диска

Да. Но если ради нескольких шагов, то усложнение того не стоит.


> и установки пакетов.
> На первый взгляд не вижу ничего такого.

Установка большого числа пакетов из установщика, вероятно, не самое 
лучшее на сегодняшний день решение. Такой шаг уместней в конфигураторе 
из установленной системы после обновления. И тянуть не из repo-main, а 
по сети.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Пример файла разметки и описания

[Leonid Krivoshein]

[-- Attachment #1: Type: text/plain, Size: 5292 bytes --]


On 10/10/24 01:08, Leonid Krivoshein wrote:
>> [...]
>>> По результатам обсуждения я сформулировал следующие тезисы:
>>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>>> который создаёт сценарий автоустановки (kickstart-файл)
>> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
>> Поэтому я предлагаю придумать этому файлу другой формат и название.
>> Взяв у коллег лучшее, естественно.
>>
>> Формат должен быть документирован, его корректность и наличие
>> всех необходимых полей должны быть проверяемы программно (т.е.
>> нужна схема).
>
> Да. Yaml. СхемЫ тоже на Yaml. Есть возражения? Во множественном, т.к. 
> модульность, схемы будут разделены по пакетам. Важна строгая 
> типизация, давно обсуждали это и кажется Иван Захарящев даже что-то 
> делал для этого с woo.
>

Разметка дисков -- существенная часть установщика. Давно хочу написать 
этот бэкенд и уже примеряюсь к инструментарию, хотя архитектура Volume 
Slicer (vs) созрела окончательно в прошлом году.

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

Для предметного обсуждения приложил пару файлов одной и той же 
развесистой разметки и краткое описание основных разделов. Ключи в 
описаниях блочных сущностный должны просто соответствовать длинным 
опциям, создающим эти блочные сущности. К примеру, "homehost: FIXED" в 
файле разметки превратится в "--homehost FIXED" при вызове mdadm. Такой 
подход позволяет полностью сохранить семантику при работе с внешними 
утилитами.

Для проверки схемы используется pydantic. Выбирал из десятка похожих 
проектов. В результате схема описывается где-то в Yaml-файлах, где-то 
прямо в коде. Пример рабочих сниппетов для лучшего понимания:

def to_kebab(s: str) -> str:
     return s.replace('_', '-')

...

class Filesystem(BaseModel):
     id: int | None = None
     fstype: str | None = None
     label: str | None = None
     uuid: UUID | None = None
     no_discard: bool | None = None

     model_config = ConfigDict(
         alias_generator=AliasGenerator(
             validation_alias=to_snake,
             serialization_alias=to_kebab,
         )
     )

     def model_post_init(self, __context: Any) -> None:
         if self.fstype is None:
             self.fstype = self.__class__.__name__
         self.id = id(self)

     @model_validator(mode='after')
     def check_fstype(self) -> Self:
         print(f'fields of the {self.fstype} filesystem are checked')
         return self
...

class vfat(Filesystem):
     uuid: str | None = Field(
         default=None,
         min_length=9,
         max_lenght=9,
         pattern=r'^[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{4}$'
     )
...

Сама разбивалка должна получиться не очень сложной, т.к. используется 
много внешнего и готового. Например, для чтения используется lsblk с 
выводом в json, pyudev, нативные утилиты, типа dumpe2fs. Ближайшее 
чем-то похожее решение -- blivet, который немного залочен на RedHat и 
построен вокруг libblockdev. При желании его можно использовать, в 
Debian смогли прикрутить. Ещё чем-то очень отдалённо напоминает 
libstorage-ng, которая использует DOM/XML-дерево (XML-файл разметки).


-- 
WBR, Leonid Krivoshein.

[-- Attachment #2: condtree.yaml --]
[-- Type: application/x-yaml, Size: 5880 bytes --]

[-- Attachment #3: exp-list.yaml --]
[-- Type: application/x-yaml, Size: 7202 bytes --]

[-- Attachment #4: layout-ru.md --]
[-- Type: text/markdown, Size: 12920 bytes --]

# Формат файла разметки дисков

## VSCT/1.0: Volume Slicer Condensed Tree, Version 1.0

Исходный файл с глубокой иерархией вложенности, позволяющий определить
зависимости одних сущностей от других без необходимости идентификации
каждой блочной сущности. В числе особенностей: поддержка наборов дисков,
автоматическая идентификация узлов дерева устройств, поддержка значений
по умолчанию для блочных сущностей и файловых систем. В этом формате
допускается определение групп дисков под общим идентификатором и групп
операций, выполняемых над ними по одному принципу.

Первый уровень файла разметки предусматривает следующие секции:

* `general`: информация о формате данных и глобальные опции
* `defaults`: значения по умолчанию для других секций этого файла
* `activate`: описания подсистем, задействованных до начала разметки
* `protected`: описания всех исключаемых (защищаемых) дисков
* `targets`: описания всех включаемых целевых дисков
* `layout`: описание проверяемых элементов существующей разметки
* `delete`: список удаляемых элементов существующей разметки
* `change`: описание изменений существующей разметки
* `create`: описание вновь создаваемых элементов будущей разметки
* `volumes`: список форматируемых томов и монтируемых файловых систем

Обязательными являются секции `general` и `targets`. Остальные зависят
от того, что мы хотим сделать при помощи данного файла разметки дисков.

## VSEL/1.0: Volume Slicer Expanded List, Version 1.0

Внутренний формат развёрнутого списка, в котором сохранён только первый
уровень исходного формата. Всем узлам присвоены какие-то идентификаторы,
если их не было в исходном файле. Наборы дисков и операций над ними под
общим идентификатором развёрнуты до индивидуальных дисков и операций,
каждая под своим идентификатором. Каждая блочная сущность перенесена на
второй уровень соответствующего раздела. Каждая файловая система перенесена
из раздела `create` в раздел `volumes`. Все блочные сущности и файловые
системы насыщены дефолтными значениями и информацией о позиционировании
блока в исходном файле. Раздел значений по умолчанию удалён. Добавлены
замыкания блочных устройств, имеющих дочерние устройства.

Первый уровень файла разметки предусматривает следующие секции:

* `general`: информация о формате данных и глобальные опции
* `activate`: описания подсистем, задействованных до начала разметки
* `protected`: описания всех исключаемых (защищаемых) дисков
* `targets`: описания всех включаемых целевых дисков
* `layout`: описание проверяемых элементов существующей разметки
* `delete`: список удаляемых элементов существующей разметки
* `change`: описание изменений существующей разметки
* `create`: описание вновь создаваемых элементов будущей разметки
* `volumes`: список форматируемых томов и монтируемых файловых систем

Обязательными являются секции `general` и `targets`. Остальные зависят
от того, что мы хотим сделать при помощи данного файла разметки дисков.

## Секция general

Определяет по сути две вещи:

* `data-format`: формат данных («VSCT/1.0» либо «VSEL/1.0»), «auto»
  по умолчанию, это поле можно сделать необязательным, если определить
  тип данных окажется возможным автоматически.
* `*`: глобальные флаги и опции, перебивающие дефолтные значения vs,
  но имеющие меньший приоритет, чем опции командной строки.

## Секция defaults

Позволяет определить значения по умолчанию для других секций этого файла
персонально для каждого типа описываемой блочной сущности либо файловой
системы. Например, если мы хотим, чтобы все разделы создавались с типом
RAID, можно указать для блочной сущности `part` дефолтное значение:

```
defaults:
  part:
    parttype: R
```

Секция поддерживается только в исходном файле типа `Condensed Tree`, она
удаляется при развёртывании «сжатого дерева» во внутренний формат списка.

## Секция activate

Может включать описание задействованных в разметке подсистем и файловых
систем, проверяемых и активируемых до начала процедуры разметки. Например,
таких, как: `multipath`, `iscsi`, `fcoe`, `aoe`, `ipoib`, `raid`, `lvm2`,
`ext4`, `swap`, `jfs`, `xfs`, `btrfs`, итд. Описание подсистем необходимо
для определения всех необходимых зависимостей на целевой системе и запуска
команд, служб, загрузки модулей ядра, установки соединений, в том числе,
с использованием аутентификационных данных, что позволит обнаружить или
подключить блочные устройства штатными средсвами Linux ядра и userspace
ещё до того, как будет запущен процесс обнаружения целевых дисков.

Нет необходимости перечислять все задействованные подсистемы в исходном
файле типа `Condensed Tree`, они заново определяются автоматически при
развёртывании «сжатого дерева» во внутренний формат списка.

## Секция protected

Перед поиском целевых дисков выполняется активация подсистем, исключаются
все диски и разделы, которые смонтированы в настоящий момент. Дополнительно
исключаются диски, указанные в командной строке, и диски, описания которых
перечислены в настоящей секции файла разметки.

## Секция targets

Второй обязательный раздел, в котором описывается каждый целевой диск или
набор целевых дисков, соответствующие заданным критериям. Каждая следующая
секция файла описывает блочные сущности, которые строятся поверх целевых
дисков.

## Секция layout

В ней описываются блочные сущности и файловые системы, которые должны быть
проверены до внесения в разметку каких-либо изменений. Например, если мы
собираемся удалить два раздела с порядковыми номерами 5 и 6, создать новый
раздел и отформатировать его, в данной секции мы описываем существующую
таблицу разделов и, по меньшей мере, удаляемые разделы с номерами 5 и 6.

## Секция delete

В ней только перечисляются идентификаторы блочных сущностей и файловых
систем, которые были описаны в секции `layout`, и которые должны быть
рекурсивно удалены. Удаление выполняется всегда в указанном порядке
только после проверки и до внесения каких-либо иных изменений.

## Секция change

Описывает изменения отдельных свойств блочных сущностей и файловых систем
в уже существующей разметке, описанной ранее в секции `layout` и с учётом
уже выполненных к данному моменту удалений, если таковые были указаны в
секции `delete`. Здесь можно переопределить названия томов, их UUID'ы,
выполнить очистку, уменьшить или увеличить размеры разделов и другие
поддерживаемые операции, выполняемые всегда в указанном порядке.

## Секция create

Описывает все вновь создаваемые элементы будущей разметки. Они создаются
либо поверх целых дисков, описанных ранее в секции `targets`, либо поверх
элементов существующей разметки, описанной ранее в секции `layout`, но с
учётом уже выполненных к данному моменту удалений, если таковые были указаны
в секции `delete`, и с учётом уже выполненных к данному моменту изменений,
если таковые были указаны в секции `change`. При конвертировании во внутренний
формат из секции `create` удаляются описания форматируемых файловых систем.

## Секция volumes

Описывает все вновь создаваемые файловые системы, т.е. только то, что
должно быть отформатировано. Их можно описывать и в секции `create` в
исходном файле разметки, но во внутреннем формате они все будут перенесны
в секцию `volumes`. В секции `layout` перечисляются только те файловые
системы, которые будут проверены, которые должны существовать на момент
запуска утилиты, и которые могут быть использованы в процессе каскадного
монтирования томов, но они не участвуют в отдельной операции форматирования.

Re: [devel-distro] Пример файла разметки и описания

[Антон Мидюков]

10.10.2024 04:01, Leonid Krivoshein пишет:
> 
> On 10/10/24 01:08, Leonid Krivoshein wrote:
>>> [...]
>>>> По результатам обсуждения я сформулировал следующие тезисы:
>>>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>>>> который создаёт сценарий автоустановки (kickstart-файл)
>>> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
>>> Поэтому я предлагаю придумать этому файлу другой формат и название.
>>> Взяв у коллег лучшее, естественно.
>>>
>>> Формат должен быть документирован, его корректность и наличие
>>> всех необходимых полей должны быть проверяемы программно (т.е.
>>> нужна схема).
>>
>> Да. Yaml. СхемЫ тоже на Yaml. Есть возражения? Во множественном, т.к. модульность, схемы будут разделены по пакетам. Важна строгая типизация, давно обсуждали это и кажется Иван Захарящев даже что-то делал для этого с woo.
>>
> 
> Разметка дисков -- существенная часть установщика. Давно хочу написать этот бэкенд и уже примеряюсь к инструментарию, хотя архитектура Volume Slicer (vs) созрела окончательно в прошлом году.
> 
> Всегда считал, что описание разметки -- весьма непростая сущность, оно не обязано быть в том же формате, что и файл ответов, хотя служит тем же целям. Если вдруг это совпадёт, будет здорово, можно вложить одно Yaml-дерево в другое, но всегда можно использовать просто ссылку на отдельный файл.
> 

Я даже думаю, что разметка диска не должна быть частью конфигуратора. Это должен быть отдельный модуль, генерирующий отдельный файл.
Тогда выглядит схема инсталлятора так:

Конфигуратор (если необходимо) -> Разбивка диска -> Установка (из пакетов, из live или архива, неважно) -> Интерпертатор сценария автоконфигурирования, запущенный в chroot -> Перезагрузка в установленную ОС

То есть интерпретатор автоконфигурирования является в данной схеме частью установленной системы вместе с бекендами.
И тогда вообще никаких отличий с предустановкой:
Конфигуратор (если необходимо) ->  Интерпертатор сценария автоконфигурирования -> Перезагрузка

Сразу возникает вопрос, а точно ли нам нужно тогда запускать его в чруте? Мне кажется, что нет. Если это не OEM, то при первом запуске не запускается конфигуратор, а выполняется сценарий автоконфигурирования и перезагрузка. А OEM только и будет отличаться тем, что будет запускаться конфигуратор в установленной системе.

То есть я вернулся в итоге к изначальному варианту реализовать предустановленную систему с возможностью автоустановки.
Конфигуратор в итоге будет готов. И останется реализация модуля разбивки диска и модулей развёртывания из пакетов (а может оно нам и не надо окажется?), live или rootfs (эти два варианта очевидно очень похожи, поэтому это может быть один и тот же модуль).

П.с.: Я свои ответы на разные письма позже резюмирую, как своё видение общей ситуации по данному обсуждению.

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Антон Мидюков]

10.10.2024 01:08, Leonid Krivoshein пишет:
> 
> On 10/9/24 09:19, Ivan A. Melnikov wrote:
>> On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
>>> Доброго времени суток
>>>
>>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
>>> каким должен быть новый инсталлятор на базе альтератор 2.0.
>> Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
>> обсуждении, на днях я доказывал sin@, что нужно делать примерно
>> то же самое.
>>
>>> По результатам обсуждения я сформулировал следующие тезисы:
>>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>>> который создаёт сценарий автоустановки (kickstart-файл)
>> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
>> Поэтому я предлагаю придумать этому файлу другой формат и название.
>> Взяв у коллег лучшее, естественно.
>>
>> Формат должен быть документирован, его корректность и наличие
>> всех необходимых полей должны быть проверяемы программно (т.е.
>> нужна схема).
> 
> Да. Yaml. СхемЫ тоже на Yaml. Есть возражения? Во множественном, т.к. модульность, схемы будут разделены по пакетам. Важна строгая типизация, давно обсуждали это и кажется Иван Захарящев даже что-то делал для этого с woo.
> 
> Но. Многое зависит от того, что будет с конфигуратором, какими данными он будет манипулировать и будет ли он связан с установщиком.

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

> 
>>> 2. Сценарий автоустановки состоит из секций конфигураций,
>>> соответствующих бекенду. Если бекенд не доступен, секция конфига
>>> пропускается
>> С этим пунктом я не согласен. Лучше явно помечать, в каких условиях должен
>> выполняться каждый шаг. Во-первых, explicit is better than implicit (c).
>> Во-вторых, это позволит конфигуратору (графическому, хотя и не
>> обязательно) не пытаться идти и выяснять, какие бекенды есть, а просто
>> делать свою работу.
>>
>> В целом, конфигуратор я представляю себе как инструмент, получающий
>> на вход шаблон сценария автоустановки и, возможно, режим работы
>> (установка/настройка первого запуска/...), и дозаполняющий в нужных
>> шагах необходимые поля. Грубо говоря, файл на входе, файл на выходе.
>> Легко писать, легко тестировать, легко пилить альтернативные
>> реализации.
> 
> Да. Только не конфигуратор, а установщик. Или уж тогда та часть установщика, что отвечает за ручное конфигурирование.
> 

Почему ты так считаешь? Вполне здравая идея, что конфигуратор - инструмент для заполнения сценария автоустановки. На вход может быть подан полностью или частично заполненный сценарий автоустановки, а конфигуратор будет позволять его отредактировать и выдать новый вариант. То есть у дистрибутива будет уже заранее подготовленный сценарий автоустановки с некоторыми дефолтами. Пользователю нужно будет их поменять. Если конфигуратор будет запускаться отдельно от инсталлятора, то он будет позволять загрузить некий сценарий автоустановки и сохранить на выходе новый. Если в составе инсталлятора, то помимо этого появляется возможность произвести установку. В режиме автоустановки конфигуратор конечно же запускаться не должен (чтобы графика была не нужна).
Но на первом этапе нам не нужно делать графический инсталлятор. Нам достаточно реализовать отдельно конфигуратор и модуль интерпретации сценария автоустановки.

>>> 3. Один и тот же сценарий автоустановки может использоваться для
>>> установки и запуска настройки первого запуска [...]
>> Опять же да, но мне кажется, что если нужного бекенда нет, это
>> ошибка, а применимость шага в конкретном сценарии должна быть
>> явно отмечена.
>>
>>> 8. Настройки выполняются параллельно
>> Это важно и было бы круто. Нужно продумать, могут ли быть
>> зависимости между шагами установки, помимо очевидной
>> зависимости ВСЕГО от разбивки диска
> 
> Да. Но если ради нескольких шагов, то усложнение того не стоит.
> 
> 
>> и установки пакетов.
>> На первый взгляд не вижу ничего такого.
> 
> Установка большого числа пакетов из установщика, вероятно, не самое лучшее на сегодняшний день решение. Такой шаг уместней в конфигураторе из установленной системы после обновления. И тянуть не из repo-main, а по сети.
> 

Установка дополнительных пакетов должна быть возможна, как при установке, так и при первом запуске. Это опциональный шаг, который может: совсем не быть, быть только в конфигураторе перед установкой, в конфигураторе после установки, в обоих конфигураторах. То есть как и любой другой шаг, о чём писал в заглавном письме.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0

[Leonid Krivoshein]

On 10/10/24 08:26, Антон Мидюков wrote:
> 10.10.2024 01:08, Leonid Krivoshein пишет:
>> On 10/9/24 09:19, Ivan A. Melnikov wrote:
>>> On Tue, Oct 08, 2024 at 04:43:47PM GMT, Антон Мидюков wrote:
>>>> Доброго времени суток
>>>>
>>>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@,
>>>> каким должен быть новый инсталлятор на базе альтератор 2.0.
>>> Во-первых, я апплодирую, потому что, хотя я и не участвовал в этом
>>> обсуждении, на днях я доказывал sin@, что нужно делать примерно
>>> то же самое.
>>>
>>>> По результатам обсуждения я сформулировал следующие тезисы:
>>>> 1. Графический интерфейс инсталлятора представляет собой конфигуратор,
>>>> который создаёт сценарий автоустановки (kickstart-файл)
>>> Я не считаю, что у нас возможна совместимость с redhat в этом вопросе.
>>> Поэтому я предлагаю придумать этому файлу другой формат и название.
>>> Взяв у коллег лучшее, естественно.
>>>
>>> Формат должен быть документирован, его корректность и наличие
>>> всех необходимых полей должны быть проверяемы программно (т.е.
>>> нужна схема).
>> Да. Yaml. СхемЫ тоже на Yaml. Есть возражения? Во множественном, т.к. модульность, схемы будут разделены по пакетам. Важна строгая типизация, давно обсуждали это и кажется Иван Захарящев даже что-то делал для этого с woo.
>>
>> Но. Многое зависит от того, что будет с конфигуратором, какими данными он будет манипулировать и будет ли он связан с установщиком.
> Конфигуратор должен быть связан с установщиком только сценарием автоустановки. Это принципиальный момент.
> Как я понимаю, должен быть реализован модуль для интерпретации этого сценария, который будет переводить то, что в нём написано, на вызовы API бекендов, после чего производить эти самые вызовы. В итоге будет происходить установка. Выполнение этапов автоустановки должно визуализироваться. При графической установке это фронтенд инсталлятора. При автоустановке - сообщения в консоль.

Про API и разделение на ф/б-енды отдельно напишу.


>>>> 2. Сценарий автоустановки состоит из секций конфигураций,
>>>> соответствующих бекенду. Если бекенд не доступен, секция конфига
>>>> пропускается
>>> С этим пунктом я не согласен. Лучше явно помечать, в каких условиях должен
>>> выполняться каждый шаг. Во-первых, explicit is better than implicit (c).
>>> Во-вторых, это позволит конфигуратору (графическому, хотя и не
>>> обязательно) не пытаться идти и выяснять, какие бекенды есть, а просто
>>> делать свою работу.
>>>
>>> В целом, конфигуратор я представляю себе как инструмент, получающий
>>> на вход шаблон сценария автоустановки и, возможно, режим работы
>>> (установка/настройка первого запуска/...), и дозаполняющий в нужных
>>> шагах необходимые поля. Грубо говоря, файл на входе, файл на выходе.
>>> Легко писать, легко тестировать, легко пилить альтернативные
>>> реализации.
>> Да. Только не конфигуратор, а установщик. Или уж тогда та часть установщика, что отвечает за ручное конфигурирование.
>>
> Почему ты так считаешь?

Выше я прочитал "конфигуратор... автоустанавливает", вопрос терминологии.


> Вполне здравая идея, что конфигуратор - инструмент для заполнения сценария автоустановки.

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

Стоит рассмотреть и другие сценарии, когда установщик и конфигуратор 
(центр управления системой) вообще никак не связаны.


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

Чтобы не было путаницы в терминологии, уточнил: конфигуратор или та 
часть установщика, что отвечает за ручное конфигурирование, это зависит 
от интеграции между центром управления системой (конфигуратором) и 
установщиком.


> То есть у дистрибутива будет уже заранее подготовленный сценарий автоустановки с некоторыми дефолтами. Пользователю нужно будет их поменять. Если конфигуратор будет запускаться отдельно от инсталлятора, то он будет позволять загрузить некий сценарий автоустановки и сохранить на выходе новый. Если в составе инсталлятора, то помимо этого появляется возможность произвести установку. В режиме автоустановки конфигуратор конечно же запускаться не должен (чтобы графика была не нужна).
> Но на первом этапе нам не нужно делать графический инсталлятор. Нам достаточно реализовать отдельно конфигуратор и модуль интерпретации сценария автоустановки.
>
>>>> 3. Один и тот же сценарий автоустановки может использоваться для
>>>> установки и запуска настройки первого запуска [...]
>>> Опять же да, но мне кажется, что если нужного бекенда нет, это
>>> ошибка, а применимость шага в конкретном сценарии должна быть
>>> явно отмечена.
>>>
>>>> 8. Настройки выполняются параллельно
>>> Это важно и было бы круто. Нужно продумать, могут ли быть
>>> зависимости между шагами установки, помимо очевидной
>>> зависимости ВСЕГО от разбивки диска
>> Да. Но если ради нескольких шагов, то усложнение того не стоит.
>>
>>
>>> и установки пакетов.
>>> На первый взгляд не вижу ничего такого.
>> Установка большого числа пакетов из установщика, вероятно, не самое лучшее на сегодняшний день решение. Такой шаг уместней в конфигураторе из установленной системы после обновления. И тянуть не из repo-main, а по сети.
>>
> Установка дополнительных пакетов должна быть возможна, как при установке, так и при первом запуске. Это опциональный шаг, который может: совсем не быть, быть только в конфигураторе перед установкой, в конфигураторе после установки, в обоих конфигураторах. То есть как и любой другой шаг, о чём писал в заглавном письме.

Вопрос в пользе repo-main и целесообразности по-пакетной установки через 
apt'овый pipe каждого RPM-пакета в современном установщике. В 
рекомендуемом дистростроителем способе поддержки ОС, установленный таким 
способом RPM-пакет с вероятностью 99.9% должен быть сразу заменён, мы 
просто тратим время на его не нужную установку очень медленным способом.

В начале 2000-х, когда ADSL был ещё не у всех, это было способом увезти 
на диске в свой мухосранск пакетную базу хоть какой-то давности. В 
современном мире для любителей изолированных контуров есть локальное 
зеркало и можно специально для таких сделать премиум подписку по почте 
на ежемесячный срез репозитория, записанный на BlueRay или даже на 
USB-флешку с фирменной символикой.


-- 
WBR, Leonid Krivoshein.

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог)

[Антон Мидюков]

Здравствуйте

Хочу сделать промежуточный итог, чтобы разговоры не остались просто разговорами.

1. В целом у нас есть консенсус, что нам нужен конфигуратор автоустановки/автонастройки системы, принимающий на вход шаблон файла ответов для установки и выдающий на выход полностью заполненный файл ответов.

2. У нас нет консенсуса по тому, какой формат должен использоваться для написания файла ответов для автоустановки/автонастройки. Должен быть это kickstart или всё же какой-то свой формат (например, на базе yaml). Плюс kickstart в том, что он стандартизирован и знаком многим по Red Hat, минус - обратная сторона плюса, от нас будут ожидать совместимости с kickstart там, где это невозможно.

3. У нас нет консенсуса по тому, нужно ли нам запускать новый конфигуратор в инсталляторе, или пусть в инсталляторе будет что-то иное, не завязанное на systemd и d-bus.

Я вспомнил, что мы обсуждали похожую тему полгода назад:
https://lore.altlinux.org/devel-distro/ZlMikClMGAKrPRVe@example.org/T/#t
начало тут:
https://lore.altlinux.org/devel/1c3dc62c-874e-4dac-9a97-43eb26454fb2@gmail.com/T/#t

И в целом, идея "OEM-установки системы всегда" мне понравилась тогда. Повторюсь, что это нам даёт:
- не нужно текущий инсталлятор переписывать, оставляем в нём только минимум шагов, всё остальное выполняется при первом запуске системы. Потом когда-нибудь напишем новый
- можно готовить rootfs базовой системы, который разворачивать альтернативными способами. При первом запуске устанавливаются нужные компоненты. То есть не делать дважды одну и ту же работу, не заставлять пользователей систему ставить в режиме OEM. Распаковали архив, загрузчик сделали и вперёд.ребов

4. У нас нет консенсуса по тому, должен ли использоваться тот же файл ответов для разбивки диска, что и для файла ответов автоустановки/автонастройки системы.
Если на пункте 3 выбрать вариант "OEM-установки системы всегда", то ответ очевиден - не должен. И эта тема тогда никак не связана с альтератор 2.0, по крайней мере на данном этапе.


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог)

[Leonid Krivoshein]

[-- Attachment #1: Type: text/plain, Size: 7550 bytes --]

Добрый день!


On 10/14/24 07:58, Антон Мидюков wrote:
> Здравствуйте
>
> Хочу сделать промежуточный итог, чтобы разговоры не остались просто разговорами.

Однако замечу, что в заголовке приведён один из дискуссионных вопросов.


> 1. В целом у нас есть консенсус, что нам нужен конфигуратор автоустановки/автонастройки системы, принимающий на вход шаблон файла ответов для установки и выдающий на выход полностью заполненный файл ответов.

Как в других дистрибутивах более чем 20-летней давности.


> 2. У нас нет консенсуса по тому, какой формат должен использоваться для написания файла ответов для автоустановки/автонастройки. Должен быть это kickstart или всё же какой-то свой формат (например, на базе yaml). Плюс kickstart в том, что он стандартизирован и знаком многим по Red Hat, минус - обратная сторона плюса, от нас будут ожидать совместимости с kickstart там, где это невозможно.

Отдельным письмом описал и другие минусы формата ks с технической точки 
зрения.


> 3. У нас нет консенсуса по тому, нужно ли нам запускать новый конфигуратор в инсталляторе, или пусть в инсталляторе будет что-то иное, не завязанное на systemd и d-bus.

Предлагаю сначала обсудить отдельно конфигуратор.

Сейчас это более сотни модулей в репозитории, большая часть из которых 
скорее мертвы. Но это очень мало, с учётом задач программы и скорости 
поступления хотелок. Исходя из этого основная задача -- максимально 
быстрый рост кодовой базы и желание работать с этим инструментом 
разработчикам. Как минимум, это выбрасывание зависимости на guile. Но и 
архитектурить его надо "с нуля" тогда уж, начиная с конфигурационной БД 
и механизмов применения настроек к системе.

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

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


> Я вспомнил, что мы обсуждали похожую тему полгода назад:
> https://lore.altlinux.org/devel-distro/ZlMikClMGAKrPRVe@example.org/T/#t
> начало тут:
> https://lore.altlinux.org/devel/1c3dc62c-874e-4dac-9a97-43eb26454fb2@gmail.com/T/#t
>
> И в целом, идея "OEM-установки системы всегда" мне понравилась тогда. Повторюсь, что это нам даёт:
> - не нужно текущий инсталлятор переписывать, оставляем в нём только минимум шагов, всё остальное выполняется при первом запуске системы. Потом когда-нибудь напишем новый
> - можно готовить rootfs базовой системы, который разворачивать альтернативными способами. При первом запуске устанавливаются нужные компоненты. То есть не делать дважды одну и ту же работу, не заставлять пользователей систему ставить в режиме OEM. Распаковали архив, загрузчик сделали и вперёд.ребов

Если будет отказ от installer-features-stage3 в пользу конфигуратора и 
готовой rootfs, если весь код конфигурирования дистрибутива будет 
выполняться через m-p в хэшере на сборочнице, а по месту уже 
переконфигурироваться из настроенной системы, если выполняемые под 
root'ом установщиком действия будут сведены к обязательному минимуму, то 
такой подход обеспечит много преимуществ.


> 4. У нас нет консенсуса по тому, должен ли использоваться тот же файл ответов для разбивки диска, что и для файла ответов автоустановки/автонастройки системы.
> Если на пункте 3 выбрать вариант "OEM-установки системы всегда", то ответ очевиден - не должен. И эта тема тогда никак не связана с альтератор 2.0, по крайней мере на данном этапе.

Сейчас у нас профиль разметки лежит отдельно от файла ответов. Во втором 
даётся ссылка на первый и профилей авторазметки может быть несколько. 
Ответ прост: чей файл, тот и разбивалка диска либо транслятор своего 
синтаксиса в синтаксис какого-то внешнего инструмента. Так что 
разделение разумно. В качестве примера отдельного файла прицепляю 
простой профиль разбиения диска под timeshift. А если форматы совпадут, 
то вложить одно в другое на лету даже не стоит обсуждения.


-- 
WBR, Leonid Krivoshein.

[-- Attachment #2: subvol.yaml --]
[-- Type: application/x-yaml, Size: 1304 bytes --]