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

Sun May 26 08:44:56 MSK 2024

26.05.2024 09:01, Leonid Krivoshein пишет:
> Всем привет!
> 
> 
> On 5/26/24 02:06, Evgeny Sinelnikov wrote:
>> Доброй ночи,
>>
>> пт, 19 апр. 2024 г. в 12:00, Антон Мидюков <midyukov-anton �� 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 �� .
> 
> 
>> В целом, по существу, я уверен в том, что использование механизмов не
>> выполняющихся "системно", а выполняющихся исключительно скриптах (или
>> копированием скриптов в /etc/firsttime.d/) в mkimage-profiles - не
>> очень хорошая идея.
> 
> Хорошо, что такой механизм уже есть. Он вроде как единственный, позволяющий выполнить предварительное развёртывание на "чужой" архитектуре. Например, мы можем распаковать систему на microSD, используя intel'овую машину, вставить эту microSD в какую-нибудь не intel'овую экзотику, где при первом включении будет выполнен postinstall.
> 
> Стоит сразу заметить, что даже при развёртывании на эту microSD не должны выполняться %post в RPM-пакетах, предназначенные для работы на целевой ("чужой") архитектуре. Заодно вспомнить про /_NEW_SYSTEM_ и $DURING_INSTALL.

Если не будет необходимости на этапе установки выбирать разный набор пакетов, то можно собирать тарбол с rootfs и устанавливать его.

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

Не понимаю я этого. Зачем? При сборке rootfs мы всё в hasher ставим, скрипты отрабатывают на нативной архитектуре.

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

Никакой интеграции с m-p не требуется. Просто опакетить в /etc/firsttime.d и добавить пакеты в сборочный профиль.

> 
> 
>> Ниже попытаюсь изложить минимальный концепт реализации этого плана:
>> 1) вариативность установки и деталей, доступных в процессе
>> инсталляции, необходимо свести к минимуму;
>> 2) выбор дополнительно устанавливаемых групп пакетов перенести в
>> постустановчный процесс;

Это и сейчас поддерживается. Можно собрать rootfs с целью use/oem/install.

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

Вообще-то она позволяет установить систему в виртуалку с универсальным initrd, донастроить систему (нужно убрать параметр загрузки systemd.unit=setup.target), после чего можно упаковать в тарбол и развёртывать.

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