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

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

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

Здесь же про воспроизводимость и тестирование: мы собрали образ на 
сборочнице, но никакие скрипты, включая %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.

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

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

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>

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

[Alexey Gladkov]

On Sun, May 26, 2024 at 05:01:36AM +0300, Leonid Krivoshein wrote:
> > По поводу идеи с темой "ОЕМ при установке всегда" у меня есть
> > предложение предварительно выполнить следующий набор шагов:
> >
> > 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 , 
> но до полной совместимости ещё далеко.

Я намеренно не стал реализовывать всё, а сделал только необходимую _мне_
(моим тестам) часть кикстартера. По поводу совместимости, ту часть,
которая реализована я тестировал на сохранившихся у меня со старой работы
kickstart-файлах для родной анаконды.

Остальную часть в каких-то случаях реализовать просто, в каких-то довольно
трудозатратно.

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

Когда-то мы со Стасом Иевлевым пытались продвинуть эту идею в реализации
инсталлятора, но не получилось по не техническим причинам.

Я написал фичу kickstarter на основе тогдашних набросков для инсталлятора.

P.S. Пишу тебе лично т.к. потерял возможность писать что-либо с альтового
адреса и в рассылку написать не могу. Извини.

-- 
Rgrds, legion

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

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



>>> На примере сервера я планирую постепенное изживание
>>> 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.

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

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

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>