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

Sun May 26 15:50:41 MSK 2024

On 5/26/24 08:44, Антон Мидюков wrote:
> 26.05.2024 09:01, Leonid Krivoshein пишет:
>> Всем привет!
>>
>>
>> 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.
> Если не будет необходимости на этапе установки выбирать разный набор пакетов, то можно собирать тарбол с rootfs и устанавливать его.
>
>> Здесь же про воспроизводимость и тестирование: мы собрали образ на сборочнице, но никакие скрипты, включая %post в пакетах, предназначенные для работы на целевой архитектуре, раньше времени не должны выполняться. Они должны отработать только при первом запуске после развёртывания.
> Не понимаю я этого. Зачем? При сборке rootfs мы всё в hasher ставим, скрипты отрабатывают на нативной архитектуре.

Установка пакета в hasher подразумевает запуск %post, при его наличии. 
Возникает вопрос: данный скрипт предназначен для выполнения только на 
целевой системе? Другой вопрос: установка пакетов подразумевает, что 
зависимости удовлетворены, а можно ли закладываться на то, что и их 
%post-скрипты выполнены? Наиболее характерный пример, в котором всё это 
учтено:

https://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=.gear/grub.spec#l435

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

>>> На примере сервера я планирую постепенное изживание
>>> 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), после чего можно упаковать в тарбол и развёртывать.

Когда касался этого в последний раз, видимо ещё не было. Тогда надо 
будет актуализировать этот кусок: 
https://www.altlinux.org/Rescue/Deploy#OEM_Setup . По крайне мере, эту 
фразу: "Данный режим совсем не предназначен для работы на эталонном 
компьютере в промежутке между установкой ОС и запечатыванием образа".

-- 
WBR, Leonid Krivoshein.