[devel-distro] [devel] ОЕМ при установке всегда

Sun May 26 05:01:36 MSK 2024

Всем привет!

On 5/26/24 02:06, Evgeny Sinelnikov wrote:
> Доброй ночи,
>
> пт, 19 апр. 2024 г. в 12:00, Антон Мидюков <midyukov-anton at ya.ru>:
>> 19.04.2024 14:50, Sergey V Turchin пишет:
>>> On Thursday, 18 April 2024 21:51:28 MSK Leonid Krivoshein wrote:
>>>
>>> [...]
>>>> Предлагался как вариант отказ от нынешнего инсталлятора, перенос части
>>>> шагов в stage1, другой части шагов как это сделано с OEM уже при первой
>>>> загрузке (alterator-setup),
>>> Мне нравится идея выделить ОЕМ-подобное, выполнять его отдельно после
>>> перезагрузки и лишь менять состав шагов в зависимости от дистрибутива.
>>> Это нужно потому, что отдельная настройка ОЕМ после установки портит некоторые
>>> настройки, которые делают installer-features-* и их надо запускать ещё раз, но
>>> никто этого не делает. При установке по сети достаточно будет закинуть какой-
>>> нибудь autoinstall-файл, по которому всё само сделается.
>>>
>> А всё от того, что надо запускать эти настройки из /etc/firsttime.d/
>> Перенести их надо, и всё будет работать правильно.
>>
>> Если уж и делить, то с той целью, чтобы не нужно было как сейчас запускать alterator в чруте.
>> Но установка grub и настройка пароля LUKS, как-то не OEM-но, а они выполняются в чрутном альтераторе.
>> Да и пароль root может быть необходимо задать.
>>
>> Такое разделение облегчило бы переход на новый альтератор, количество необходимых модулей старого типа резко бы сократилось.
>> Новый альтератор не нужно было бы запускать в инсталляторе.
>>
>>>> тогда установщик не нужен, мы развёртываем подготовленную rootfs
>>> Это можно решить отдельно, но уже видна такая тенденция у коллег из других
>>> дистрибутивов.
>>>
> Это очень интересная тема. Не кажется ли она более подходящей для:
> - https://lists.altlinux.org/pipermail/devel-distro/ ?

Да, наверное. Хотя, будущее инсталлятора может интересовать многих и в 
рассылке devel at .

> В целом, по существу, я уверен в том, что использование механизмов не
> выполняющихся "системно", а выполняющихся исключительно скриптах (или
> копированием скриптов в /etc/firsttime.d/) в mkimage-profiles - не
> очень хорошая идея.

Хорошо, что такой механизм уже есть. Он вроде как единственный, 
позволяющий выполнить предварительное развёртывание на "чужой" 
архитектуре. Например, мы можем распаковать систему на microSD, 
используя intel'овую машину, вставить эту microSD в какую-нибудь не 
intel'овую экзотику, где при первом включении будет выполнен postinstall.

Стоит сразу заметить, что даже при развёртывании на эту microSD не 
должны выполняться %post в RPM-пакетах, предназначенные для работы на 
целевой ("чужой") архитектуре. Заодно вспомнить про /_NEW_SYSTEM_ и 
$DURING_INSTALL.

Здесь же про воспроизводимость и тестирование: мы собрали образ на 
сборочнице, но никакие скрипты, включая %post в пакетах, предназначенные 
для работы на целевой архитектуре, раньше времени не должны выполняться. 
Они должны отработать только при первом запуске после развёртывания.

> На примере сервера я планирую постепенное изживание
> installer-features-*, как механизмов несистемной, тонкой настройки,
> более никакими методами не воспроизводимых и скрытых в недрах профиля
> продукта. Их перенос в /etc/firsttime.d/ будет уже большой шаг вперед,
> но всех необходимых задач это не решает. Например, развертывание
> различных служб следует, всё-таки, переносить в контролируемые
> администратором инструменты, а не в эвристику, результаты работы
> которой администратору приходится потом вычищать вручную.

Да, нынешние installer-features-* надо изживать во всех дистрибутивах, 
особенно *-stage3, и не только по названным причинам. Стоит подумать об 
их миграции в /etc/firsttime.d так, чтобы было системно, воспроизводимо, 
опакечено, в дальнейшем управляемо и изначально интегрировано с m-p.

> Ниже попытаюсь изложить минимальный концепт реализации этого плана:
> 1) вариативность установки и деталей, доступных в процессе
> инсталляции, необходимо свести к минимуму;
> 2) выбор дополнительно устанавливаемых групп пакетов перенести в
> постустановчный процесс;
> 3) все дополнительные настройки, исполняемые для дополнительно
> устанавливаемых групп пакетов перенести в механизмы доступные штатно
> через инструменты администрирования;
> 4) параметры настройки штатных механизмов перенести в системные файлы
> настройки, редактируемые как вручную, так и через API на DBus;
> 5) модулям, применяющим системные настройки, предполагается
> предоставить возможность чтения настроек без запуска службы DBus,
> чтобы чтение и применение настроек могло выполняться даже в
> ограниченном окружении в хешера (если это применимо, конечно).

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

> ______________
>
> По поводу идеи с темой "ОЕМ при установке всегда" у меня есть
> предложение предварительно выполнить следующий набор шагов:
>
> 1. Рассмотреть возможности Kickstart для того, чтобы отобрать перечень
> уже существующих сценариев использования, которые могут быть у нас
> реализованы:
> - https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/

К слову, в make-initrd функционал разбивалки для stage1 с таким 
синтаксисом частично реализован: 
https://github.com/osboot/make-initrd/tree/master/features/kickstart , 
но до полной совместимости ещё далеко. Установщик должен уметь 
развёртывать систему по файлам ответов не задавая вопросов, он должен 
изначально под это проектироваться, и синтаксис должен быть удобным для 
этих целей.

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

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

> 3. Выделить значимые задачи, для решения которых требуется функционал
> ОЕМ-установки.
>
> Хочу отметить, не я этот термин применил, что OEM означает "original
> equipment manufacturer". Действительно ли мы тут обсуждаем механизм,
> который означает оригинальное значение этой аббревиатуры? Ожидание от
> него не в том, что можно будет автоматически установить Альт на
> заданную железку, с заданными настройками, а в том, что внешний, по
> отношению к нам производитель железки сможет, взяв базовый
> установочный образ, сделать кастомную сборку под свою аппаратную
> разработку. Легитимность и лицензионная чистота этого результата -
> вопрос второй.
>
> В-первую очередь, для внешнего аппаратного вендора стоит вопрос в том,
> как завести его железку. А для этого, как правило, требуется
> установить обновлённое, или даже кастомное, ядро (кто будет отвечать
> за его сопровождение - это тоже второй вопрос).
> Во-вторую очередь, внешний вендор ожидает возможность напихать своей
> "блобятины" (firmware и драйверов, и, может быть, даже
> "криптокостылей" и т.п.).
>
> Всё это и нам полезно было бы для отладки и создания кастомных сборок.
> Ставится ли так вопрос при проектировании ОЕМ-установки?

Крайне неудачное название "OEM установка", вызывающее много слов.

Вот что на самом деле бывает (и нужно нам), это из разных областей:

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

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

Запихнув "OEM установку" в инсталлятор, мы закрыли только часть 
потребностей, это редко востребованный кейс.

-- 
WBR, Leonid Krivoshein.