From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716688901; x=1717293701; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:cc:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=wXMnN/LZ6arp9uZMWzPTi2QLXDeFoDrFeKnMiOtaM2Q=; b=WJrW/cL7XHTkjheqyUwhvCDOMmK3zQJfmKwjYmUOSANTktb2anOI6foQaSZM6zSw4t mn9uzeBv1YgAjQOqITm0a8NnSh1roEcZ3xSmYZ+G9znghR6GT8up/A/sdw3uyMu+7dHu qgNjNimVFoaj2XVn01qhSO2tQhKpEzT1CZ//AqudJ5rDVRf3RhJLOIoVpYRfCBsM+ZLI 38R468WpttQuPJvHY+XzABJc2a6bR+G33QvkLxMwqr0PIXtSZdpY3IsB0ciUdrBKZRqU fwU82++dMNR+nctVsiX3I3+Mer2YvDrWhOL+YW6Ef9poKNAPzu942NAzHTls6ADh6BzX rDyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716688901; x=1717293701; h=content-transfer-encoding:in-reply-to:cc:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wXMnN/LZ6arp9uZMWzPTi2QLXDeFoDrFeKnMiOtaM2Q=; b=KkVSGQSPe2TcjNTTr2LSOgjk9IeA/eg1n89pDQDbcw9SuLstds28VoTuJb2fBDwKDB 7aU5Qh50sRtt4VH6cGBk55SeqxUFozLrfJcnlFo+0ZkY6MFRJ6LaQPYm/w7iPGwyVi8h 6ahPyxH4wCDVgb/J22PG4U+OjxQzARsGL6zj2ae/AJP0/8ak8z0YXXit9ErdDpU0qUmq zmCeHam9FRz6NwQK6SBX3nBXNf3ya9QNCtzitCwEl35DtDV8KM8Jg+8iHNqswAeAr1KT NI4m4fhpnjwM2kFXdar6KuRFXpyf895ljQaQb5hYyphZ6um/wyt6P//U/TGf0pZeHwjc uQCA== X-Gm-Message-State: AOJu0Yxrc3Bn0H/QfK2MeSszOx5vK4nXUWevuXPqcN0sd9MZCQKsXTRU n+nBfKji5RtSDieCNAlmsvs4woDiRyCDGL+EMqsOqr0OIe6zeI46KDOh9A== X-Google-Smtp-Source: AGHT+IGqzU7DlXzPT5pUL6O/3KNcbV7i8BAQJlAjinATQ0rZ2bqYfwFNQ/velGKDoyUmNsYqur4qbQ== X-Received: by 2002:a2e:bc08:0:b0:2d6:f69d:c74c with SMTP id 38308e7fff4ca-2e95b256308mr39359311fa.38.1716688900485; Sat, 25 May 2024 19:01:40 -0700 (PDT) Message-ID: <1115f401-e7a2-4f78-97f1-1f1da6fd7e20@gmail.com> Date: Sun, 26 May 2024 05:01:36 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel@lists.altlinux.org References: <1c3dc62c-874e-4dac-9a97-43eb26454fb2@gmail.com> <6040161.lOV4Wx5bFT@zerg.malta.altlinux.ru> Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Distributions development Subject: Re: [devel] =?utf-8?b?0J7QldCcINC/0YDQuCDRg9GB0YLQsNC90L7QstC60LUg?= =?utf-8?b?0LLRgdC10LPQtNCw?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2024 02:01:54 -0000 Archived-At: List-Archive: List-Post: Всем привет! On 5/26/24 02:06, Evgeny Sinelnikov wrote: > Доброй ночи, > > пт, 19 апр. 2024 г. в 12:00, Антон Мидюков : >> 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.