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

Sun May 26 17:00:25 MSK 2024

26.05.2024 19:50, Leonid Krivoshein пишет:
> 
> 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 �� 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 ставим, скрипты отрабатывают на нативной архитектуре.
> 
> Установка пакета в hasher подразумевает запуск %post, при его наличии. Возникает вопрос: данный скрипт предназначен для выполнения только на целевой системе? Другой вопрос: установка пакетов подразумевает, что зависимости удовлетворены, а можно ли закладываться на то, что и их %post-скрипты выполнены? Наиболее характерный пример, в котором всё это учтено:
> 
> https://git.altlinux.org/gears/g/grub.git?p=grub.git;a=blob;f=.gear/grub.spec#l435
> 
> При переходе на сборку rootfs в сборочнице, думать надо об остальных пакетах с такими подводными камнями, где это не учтено, где их %post закладывается на выполнение при установке на конечном железе. Всё же надеюсь, что такого у нас немного, но это нужно выкорчёвывать.
> 

Так ставить предполагается только базовую систему. Всё остальное устанавливаем на развёрнутой системе при первом запуске. Если бы такие проблемы были в базовых пакетах, мы бы давно об этом знали, так как с 2019 года собираем rootfs.

> 
> 
>>>> На примере сервера я планирую постепенное изживание
>>>> 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 . По крайне мере, эту фразу: "Данный режим совсем не предназначен для работы на эталонном компьютере в промежутке между установкой ОС и запечатыванием образа".
> 

Убрал эту фразу.

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