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=1728510723; x=1729115523; darn=lists.altlinux.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=8fZD+N9WdP3c6xdpCNkoxLP6XzLmsNk/RA7Bs4as8o8=; b=jqTw0yNlW0o00YDmd0P93GkmrPAhVXi2aV5hSKMzoJdoeX/1a6ywQQrm5b1FHNW4D7 jItIClTFf09yWGUmP8ISFqMkZ+PnyOGry3vYTNEIjF9//NKbC9oSeD3MEY+AEu+NyGmt BwOuG/yq3qF1c4K5QKDmt76al5IL4vzKQhpRdGxpegB7wfyAByF/K5FGsKhkK8hBMXfw Izl1aMGrqtojnt7xk6TNptFT7Z0MelipkK27ejXsvG0ZxvQ3Xwan//B+0qJNWxf+Rnve jX8YdykxYpdLOekqlwwxrMeRsMEZqm4z7Es5loL4OIO9giqLxIMRg+jcHwDRC0MCdiex F7qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728510723; x=1729115523; h=content-transfer-encoding:in-reply-to: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=8fZD+N9WdP3c6xdpCNkoxLP6XzLmsNk/RA7Bs4as8o8=; b=VaeHSk+mbcD32xJDHBzbXOgdrWJdEzs9vXuSt0YUzgPRDlRTyelb9r5fywOmxvYZh6 ns9IQGiM0qlRfTJOYyZGMxe0DkQ6dvFZSZjWk33c9vTb2nF+QWhNJha8ZLPJh6GmF/BB AEmUN+MZh+R3xxvRImXLEp1snOSgsVjutK/yXd4qlHHsU10lTZ8BFvMLDfcQlTgegwW1 AYPIiomnReVG9LSoHtg0tuUvMXuFn4Sh70qW5GPYRC887KZAUswFKeu4fduSW+r9tdcB GdcX/j8Zk9R5UOD4I+fea+GMIeuwxa4X8bYpFua0vK+9xZPXSkIpL4EcvJ4bxKd+Ga4h u0Jw== X-Gm-Message-State: AOJu0YyJNDjfoESbKxgmh85CVvyUDmuYuqfeGe7py+bEDj7x+4Z2594J Sn6MN/qrtk0cyhb0A2bDIeH+uogXT4M17X/sc4LlGhJxluwiHjoOi3c78w== X-Google-Smtp-Source: AGHT+IG3NRodBKupurL7FMY1pYOfr29jm2+xabqWR6GPhtAFF3Dm1jPT1mSO9b11stdUUz+wrFEZ4A== X-Received: by 2002:a2e:bc24:0:b0:2fa:d49d:45ac with SMTP id 38308e7fff4ca-2fb207bd660mr3584491fa.1.1728510722927; Wed, 09 Oct 2024 14:52:02 -0700 (PDT) Message-ID: <3cb9b945-2e78-4a53-a142-66054c0d9b9a@gmail.com> Date: Thu, 10 Oct 2024 00:52:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: devel-distro@lists.altlinux.org References: Content-Language: ru, en-US From: Leonid Krivoshein In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel-distro] =?utf-8?b?0KLQtdC30LjRgdGLINC00LvRjyDQuNC90YHRgtCw?= =?utf-8?b?0LvQu9GP0YLQvtGA0LAg0L3QsCDQsdCw0LfQtSDQsNC70YzRgtC10YDQsNGC?= =?utf-8?b?0L7RgCAyLjA=?= X-BeenThere: devel-distro@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Distributions development List-Id: Distributions development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2024 21:52:07 -0000 Archived-At: List-Archive: On 10/9/24 05:13, Evgeny Sinelnikov wrote: > Здравствуйте. > > ср, 9 окт. 2024 г. в 03:29, Leonid Krivoshein : >> On 10/8/24 16:43, Антон Мидюков wrote: >>> Доброго времени суток >>> >>> Три недели назад обсуждали в составе: sin@ cas@ sem@ shaba@ antohami@, каким должен быть новый инсталлятор на базе альтератор 2.0. >>> >>> По результатам обсуждения я сформулировал следующие тезисы: >>> [...] >> На мой взгляд, вот до этого пункта: >> >>> 9. Первоначальной задачей является создание Настройки первого запуска (новый alterator-setup), для которой не нужно делать две наиболее технологически сложных части: разбивка диска и собственно установку, но можно реализовать поддержку создания и выполнения kickstart-файла. >>> >>> Предлагаю для начала определиться корректны изложенные тезисы или нет. >> ...именно как тезисы -- нет, но перечисленное тоже можно обсудить. Нет, >> потому что начинать стоит с того: от чего, к чему и почему мы движемся, >> это даст определённые критерии оценки. А многое из перечисленного -- >> детали повторной реализации того, что уже есть. > Мы движемся от одного механизма реализации бекендов к другому. В этом предложении речь о реализации, а не целеполагании. > От > механизма, в котором нет, по сути, определенных интерфейсов, к > механизму, где их можно задавать, фиксировать, контролировать доступ > на уровне каждого отдельного метода и получать возможность написания > фронтендов, не требующих выполнения под рутом. При этом установить ОС можно только под рутом. И тогда непонятно, зачем нужны все эти интерфейсы, разделение прав и тому подобные усложнения. > В том виде, как сейчас, затруднительно делать многое. Большую часть > того, к чему мы движемся осуществить невозможно без полной > переработки. > > Технологически мы движемся: > 1) от службы alteratord на базе woo-bus к службе alterator-manager на базе dbus. Разделение на фронтэнды и бекенд в альтераторе уже неудачно спроектировано и ещё хуже реализовано. В улучшенной версии предлагается ещё больше усложнить механизм создания бекендов. Для установщика этого всего вообще не требуется. > 2) от дублирования механизмов, встроенных в современные > GNU/Linux/Systemd системы к их расширению. Наш установщик давно перешёл на systemd? У нас все установочные образы на systemd? Чего нам в установщике нужно от systemd, дёргая его исключительно через dbus? > Например, очень странно только из-под-рута уметь запускать через > unix-socket shell-скрипт, который выполняет systemctl, который в свою > очередь обращается к dbus, вместо того, чтобы напрямую обращаться к > интерфейсу org.freedesktop.systemd1.Manager. Команда systemctl на шеле -- одна строка. Мы готовы обучать детей и внуков механизму работы с dbus на Си, вместо того, чтобы сделать их счастливыми? :-) > Чтобы увидеть перечень методов достаточно набрать и "потабать": > $ busctl call org.freedesktop.systemd1 /org/freedesktop/systemd1 > org.freedesktop.systemd1.Manager > > Впрочем "потабать" можно всё. Это называется интроспекция. В некоторых > случаях её скрывают, но это детали и особенности реализации. Горячо поддерживаю интроспекцию, наследование, полиморфизм и повторную реализацию. :-) Но не думаю, что первое необходимо для всего и вся в установщике. > Технологически мы движемся: > 3) от не соответствующего потребностям автоустановки autoinstall.scm к > формату, который нужно определить, зафиксировать (специфицировать) и Да. > реализовать "движок" инсталлятора с учётом возможностей бекендов - > доступных методов и интерфейсов на dbus. И туда же (в музей мазохизма) я бы отправил движок альтератора. Вообще всё, что на scheme. Как слишком сложно поддерживаемое и несоответствующие тому, к чему мы хотим двигаться. Креативная команда должна генерить несколько десятков модулей конфигуратора в месяц, по мере роста хотелок со всех сторон. Вот какая цель должна быть декларирована -- простота создания новых модулей, простота их поддержки, а не усложнение. > 4) мы движемся от отсутствия API для администрирования к его > оформлению для всех механизмов ОС, которым необходимо повышение > привилегий. Существуют и другие способы, не требующие манипулировать API. > 5) мы движемся от строгой технической необходимости реализовывать > фронтэнды вместе с бекендами к возможности (например, по аналогии с > NetworkManager) реализации множества фронтендов под соответствующие > среды исполнения (графические, консольные, любые). Например, с помощью > новых бекендов на базе alterator-manager можно расширять возможности > уже применяемого на практике cockpit (но, это при желании): > - https://cockpit-project.org/applications + https://pub.dev/ -- сюда же. Если использование описанного через dbus -- цель полезная, просто ради переиспользования множества уже готовых наработок, то усложнять ещё и умножением бекендов и фронтендов -- напротив, цель сомнительная. У нас два фронтенда уже в полном рассинхроне, хотя цели нынешнего альтератора декларировались те же. > 6) мы движемся от сценария один, бекенд один фронтенд к сценариям: > + один бекенд, множество разных реализаций фронтендов; > + один фронтенд, множество разных бекендов, реализующих один и тот же > интерфейс на разных объектах шины dbus. > > Оба сценария уже активно задействованы в существующих наработках. > Ключевые детали по текущим наработкам опубликованы у нас на wiki: > - https://www.altlinux.org/Alterator_на_D-Bus Почитал это и смежное про Alterator-manager, что дополнило мой немного критический взгляд. У нас не все дистрибутивы завязаны на dconf/gsettings. Не все установщики работают с systemd. Наработки по групповым политикам, компетенция по работе с dbus не пропадут даром. Делать же это концептуальным стержнем я бы точно не стал. В копилку плюсов dbus&Co: https://events.canonical.com/event/2/contributions/48/attachments/34/49/Flutter%20on%20Linux.pdf , стр. 7. И даже установщик там это использует (Ubuntu Desktop Installer). Но стоит учесть, что это одна вполне конкретная среда, у нас же решения разные. > ___________________ > > На текущий момент важно ввести уровень абстракции инсталлятора, как > расширенного приложения исполняющего пошаговую "инструкцию", > использующую специфицированный формат. Выбором этого формата > необходимо заняться в первую очередь. Мне кажется, сначала нужно решить, будет ли установщик связан с конфигуратором или нет. Если будет, то каким форматом данных будет манипулировать конфигуратор? Мы для установщика определяем конфигурацию решения, установщик её натягивает на устанавливаемое. А конфигуратором мы раскидываем её по 100500 машин домена. > Один из вариантов взять вот этот для вдохновения и (может быть, совместимости): > - https://docs.fedoraproject.org/en-US/fedora/f36/install-guide/appendixes/Kickstart_Syntax_Reference/ > - https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-commands-and-options-reference_rhel-installer > - https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html > - https://rhinstaller.github.io/anaconda-addon-development-guide/sect-anaconda-addon-architecture.html > > И далее, постепенно, реализовать на его основе своё подмножество. Не > хотелось бы брать anaconda. Хотя... если делать эту часть на python, > то что-то форкнуть, урезать и переписать под себя - вариант. > Вообще, конечно, один в один оно достаточно тяжелое. Главное - формат: > Есть ли технический смысл брать kickstart за основу? Нет, это не вариант, только как одна из входных точек для проектирования чего-то своего. > Мне кажется, что в этом формате, как минимум, проведён теханализ > потребностей инсталлятора. Хотя бы к ним стоит присмотреться. Да. > ___________________________ > > PS: Последней, требующей внимание особого внимания особенностью > реализации нового стека на dbus, которая ещё только предстоит, > является переход от пространства имён /ru/basealt/alterator к > пространству /org/altlinux/alterator (от ru.basealt.alterator к > org.altlinux.alterator). Тщетно пытался отделить обсуждение конфигуратора от установщика. Тут всё слилось обратно в единое целое. В тесном связывании этих двух разных программ есть плюсы и минусы. Может, обсудить тогда уж их сначала? Но фичи их точно нужно обсуждать в отдельных тредах. И если решать в пользу тесного связывания, то отложить пока обсуждение установщика. -- WBR, Leonid Krivoshein.