[devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл

[Leonid Krivoshein]

On 10/10/24 12:10, Alexey Gladkov wrote:
> On Wed, Oct 09, 2024 at 10:54:03PM +0300, Leonid Krivoshein wrote:
>> On 10/9/24 12:49, Alexey Gladkov wrote:
>>> On Wed, Oct 09, 2024 at 04:40:37AM +0300, Leonid Krivoshein wrote:
>>>> При этом kickstart уже известен и хорошо понятен рынку, только в этом
>>>> его плюс при полной совместимости, которая, скорее всего, недостижима.
>>>> Чтобы не быть голословным, сравните покрытое этой фичей:
>>>> https://github.com/osboot/make-initrd/tree/master/features/kickstart с
>>>> тем, что предлагает офдок RedHad по Kickstart. А без полной
>>>> совместимости ремейк этого старья 20-летней давности теряет смысл.
>>> Ага. Вот только при создании этой фичи никогда не ставилась задача сделать
>>> полное покрытие.
>> Это понятно. И хорошо, что у нас есть хоть какой-то kickstart в
>> make-initrd для разбивки диска и развёртывания без вопросов прямо из
>> stage1. Автоустановщику не требуется графика. Просто напомнил о такой
>> возможности.
> Ты просто сформировал тезис, что без полной совместимости это теряет
> смысл.

Да, это так.


> Я с этим не согласен.

Но у нас другие реалии.

>>> Кроме того, это полное покрытие вам и не требуется.
>> Нам то нет, но для пользователей не полный набор уже не будет привычным
>> и пригодным (с их-то наработками), нас этими запросами просто задолбают.
> Я такие аргументы слышу много лет. Откуда ты это знаешь ?

Последние годы по работе в техподдержке и совместимости. Условно можно 
считать, что если у заказчика его ks-файл выполняет всё в соответствии с 
ожиданиями на CentOS, РедОС, RHEL и в множестве основанных на RedHat 
дистрибутивов, а у нас это не работает, мы оказываемся в пролёте. Нам 
проще сказать, что здесь у нас не RedHat.


> За время существования kickstart redhat его менял и продолжает это делать.
> Он конечно старается не ломать сам синтаксис, но функционал команд и опций
> у них меняется.
>
> https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#creating-the-kickstart-file
>
> Можешь поискать "Deprecated since" или "Removed in version" по этому
> документу.
>
> Представление о том, что kickstart-файл 10 летней давности применится без
> проблем это миф. Тебе в любом случае нужно проверять не устарели ли твои
> команды и опции в нём. Разумеется это относится к разным командам в разной
> степени (разбивка диска меняется реже).
>
> Цитирую их официальную документацию:
>
>    If deprecated commands, options, or syntax are used during a kickstart
>    installation, a warning message will be logged to the anaconda log.
>    Since deprecated items are usually removed within a release or two, it
>    makes sense to check the installation log to make sure you haven’t
>    used any of them. When using ksvalidator, deprecated items will cause
>    an error.

Возможности продукта меняются в ногу со временем, он эволюционирует, это 
понятно. Но это всё относительно локальные, точечные изменения для 
продукта и всего поддерживающего его инфраструктуру. Нам же нужно пройти 
повторно 20-летний путь, чтобы воссоздать чужой продукт и всю 
инфраструктуру вокруг, при том, что всё это концептуально ущербно.

Когда его придумали, это был привычный подход к командам и ключам в 
командной строке. Это команды и опции для конкретной безмолвной 
развёртывалки системы. Это не команды и опции для вызываемых ею 
программ. Потеря семантики, требующая интерпретации и отдельного 
документирования. Это синтаксис конкретной развёртывалки, а не 
конфигурационная база центра управления системой.

>> Поэтому поддержка конкретного формата kickstart в установщике не нужна.
> Я ещё с Server 4 последовательно выступаю против того чтобы городить "свои
> правильные" форматы кикстартера. Их сложно изучать, их никто не описывает,
> для них нет примеров.

Я начинал именно с этого формата, затем пытался подражать, придумывая 
разбивалку диска. Вкупе с вышесказанным мне этот синтаксис не понравился 
ещё и своей громоздкостью, плохой читабельностью. Кусочек по приведённой 
тобой ссылке:

autopart [--encrypted] [--passphrase PASSPHRASE] [--escrowcert <url>]
      [--backuppassphrase] [--nolvm] [--type TYPE] [--cipher CIPHER]
      [--fstype FSTYPE] [--nohome] [--noboot] [--noswap]
      [--luks-version LUKS_VERSION] [--pbkdf PBKDF]
      [--pbkdf-memory PBKDF_MEMORY] [--pbkdf-time PBKDF_TIME]
      [--pbkdf-iterations PBKDF_ITERATIONS] [--hibernation]
      [--hw-passphrase HW_PASSPHRASE]


> Именно поддержка конкретного формата kickstart позволяет сделать
> кикстартер узнаваемым и привычным пользователю.

Нам-то какой смысл делать его узнаваемым?


> Я знаю компании, у которых
> есть (может быть уже нет) генераторы для redhat kickstarter. В них проще
> добавить костыль для другой реализации, чем писать новый генератор.

Важным элементом является возможность сконфигурировать будущее 
развёртывание заранее в графической среде, это уже отмечалось в 
обсуждении. Видимо этим компаниям не хватает какого-то функционала 
штатной system-config-kickstart, раз они делают свои генераторы.

Мы от RedHat унаследовали отсутствие стройной системы конфигурирования. 
В Debian и based есть debconf и dpkg-reconfigure, решающие задачу 
управления конфигурацией пакетов отдельно от пакетной базы, делающие 
возможным использовать один и тот же пакет в разных конфигурациях или 
менять его настройки через фронтэнды, не внося порчу в целостность 
системы. Установщик Debian -- это набор вызовов dpkg-reconfigure.

И наш текущий конфигуратор (альтератор) ничего такого не предоставляет. 
У каждого модуля есть что-то где-то своё. И у RedHat изначально был 
только /etc/sysconfig со значимыми переменными конфигурации для 
стартовых скриптов, и множество пакетов system-config-SOMETHING, в 
какой-то степени аналог наших модулей альтератора, 
system-config-kickstart -- один из таких модулей, позволяющий 
сгенерировать ks-файл для безмолвной развёртывалки.


-- 
WBR, Leonid Krivoshein.