From: Leonid Krivoshein <klark.devel@gmail.com> To: devel-distro@lists.altlinux.org Subject: Re: [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0 Date: Tue, 15 Oct 2024 00:23:21 +0300 Message-ID: <bce5158b-9bb0-40e4-988c-0453c08327ac@gmail.com> (raw) In-Reply-To: <f7159ebe-d769-4d68-b597-edf7c5bb35ea@basealt.ru> On 10/14/24 22:57, Evgeny Sinelnikov wrote: > Доброй ночи, > > хотелось бы сконцентрироваться на конкретных вопросах. Хотелось бы > ориентироваться на конструктивные предложения. Архитектурных решений > не так много, на самом деле. Архитектурных решений реализуемых в > разумные сроки еще меньше. > Только здесь основная цель -- не сам конфигуратор, а множество работающих в нём модулей, т.е. если в разумные сроки мы сможем создавать несколько новых модулей, если к этому можно будет подключить множество разработчиков, если технология будет интересна не только нам, но и админам "на местах". > > 14.10.2024 11:17, Sergey V Turchin пишет: >> On Thursday, 10 October 2024 00:52:00 MSK Leonid Krivoshein wrote: >> >> [...] >>>> От >>>> механизма, в котором нет, по сути, определенных интерфейсов, к >>>> механизму, где их можно задавать, фиксировать, контролировать доступ >>>> на уровне каждого отдельного метода и получать возможность написания >>>> фронтендов, не требующих выполнения под рутом. >>> При этом установить ОС можно только под рутом. И тогда непонятно, зачем >>> нужны все эти интерфейсы, разделение прав и тому подобные усложнения. >> Если помните, текущий aterator умееет и пользовательские >> настройки(реально >> какой-то модуль был, забыл уже). Не знаю, насколько может быть сейчас >> востребовано. >> >> [...] > > Удивительное дело. Давайте не будем путать. Общая тенденция создания > безопасных систем приводит к очень сложным в сопровождении решениям, > вроде SELinux. Проблема в том, что приложения под рутом невозможно > проконтролировать иначе. Любое приложение под рутом может всё. И > остаётся только доверять коду и надеяться на то, что этого кода будет > немного и в нем не будет критических уязвимостей. > > Текущий Альтератор построен на концепции общего набора механизмов > конфигуратора, как в инсталляторе, так и в установленной системе. > Недоработка текущей реализации в этом плане привела к тому, что > графический интерфейс мы вынуждены запускать под рутом. И это, я > полагаю, напрямую связано с тем, что кем-то тоже было сказано или > подумано нечто подобное: > > "При этом установить ОС можно только под рутом. И тогда непонятно, зачем > нужны все эти интерфейсы, разделение прав и тому подобные усложнения." > Совершенно верно. Нет нужды разграничивать доступ в установщике. Нет необходимости запускать графическую часть установщика или конфигуратора под root'ом. Но разграничение прав внутри конфигуратора необходимо, и не только в пределах локальных пользователей хоста. Конфигуратор может не ограничиваться одним хостом. > То есть упор был на инсталлятор, а конфигуратор остался как есть. А > концепт, одних и тех же модулей сохранился. > > Сейчас мы идём от обратного. Сначала конфигуратор, а потом > инсталлятор. Хоть под рутом, хоть не под рутом. С другой стороны, а в > чём, собственно, переусложнение? > > Один из вариантов запуска нашего текущего инсталлятора - это запуск > его, как приложения, в обычном livecd. В большинстве дистрибутивов оно > так и работает. В графическом виде. При этом консольного (не > графического) инсталятора у нас так пока и не было сделано. > > А, если нам нужен графический инсталлятор, то графику, в любом случае, > не стоит запускать под рутом. Да. Конфигуратор я бы рассматривал как веб-интерфейс, работающий не под root'ом, и не обязательно на том же хосте. Как фоновый агент, через который можно менять настройки системы, будучи администратором сети, у которого есть полномочия, а не только как локальный root. И одной из обязанностей этого фонового агента может быть периодическое обновление куска дерева конфигурации с какого-то условного контроллера домена. Часть настроек может быть изначально в ведении обычного пользователя. В идеале иметь возможность как делегировать пользователям полномочия менять конкретные системные настройки, так и наоборот, забирать у обычного пользователя полномочия менять изначально пользовательские настройки. Всё это разделение прав решается в пределах одной программы конфигуратора без SELinux, Polkit и интроспекции dbus. Как вариант, в пределах иерархической БД конфигурации. К слову, в виндовом реестре, помимо древовидных "кустов" предусматривалась раздача ACL на целый "куст". > ____________________ > > Итого, по теме под рутом, не под рутом. Если будет графика, то не > понимаю что мы обсуждаем. Чем нам графика под рутом жизнь облегчит? > Тем, что shell-скрипты можно будет писать не только на bash, но и на C > или Python? На я имею в виду fork/exec консольных приложений. > > На текущий момент имеется dbus - не вижу ничего противоестественного > использовать его в инсталляторе. Давно стоило акцентироваться, что dbus, прежде всего -- IPC, а зачем нужен IPC в инсталляторе? Это точно кажется противоестественным. И в конфигураторе-то он может быть нужен далеко не в каждом модуле. > Кстати, как альтернативу, с недавних пор systemd рассматривает - > https://varlink.org/ > > Systemd Looking At A Future With More Varlink & Less D-Bus For IPC > https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future > Просто, по нужде люди работают много лет с этим dbus и понимают, что организовать взаимодействие можно намного проще. Причём там, где оно действительно нужно. Например, когда мы связываем фронт с бэком в UI/UX, JSON & Ко уместнее dbus, особенно, если мы выходим за пределы хоста, чего хотелось бы. Если конфигуратор -- одна программа, если наш тулкит уже позаботился о взаимодействии фронт и бэк частей модуля, нам даже не надо об этом думать и остаётся только решить, в каких случаях уместно использовать кем-то написанное с использованием dbus, чтобы подтянуть и этот дополнительный функционал. > В выше приведенной статье указаны многие проблемы, с которыми > сталкиваются в systemd. Они там хорошо структурированы и технически > обоснованы. Возможно, нам тоже стоит к этому присмотреться к systemd > версии 257. > > И это, как раз, то, что предлагалось в рамках всех разумных > альтернатив для dbus. Но... ресурсов спроектировать всё на новом стеке > прямо сейчас пока не наблюдается. > > Предлагаю об этом подумать сразу после написания новых модулей. И, > главное, интерфейсов для них. В смысле бекендов. Сделать к ним > интерфейсы на varlink'е будет не сложно. И проблема необходимости dbus > перестанет быть. > -- WBR, Leonid Krivoshein.
next prev parent reply other threads:[~2024-10-14 21:23 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-10-08 13:43 [devel-distro] Тезисы " Антон Мидюков 2024-10-08 23:13 ` [devel-distro] " Leonid Krivoshein 2024-10-08 23:29 ` [devel-distro] Тезисы для инсталлятора " Leonid Krivoshein 2024-10-09 2:13 ` Evgeny Sinelnikov 2024-10-09 21:52 ` Leonid Krivoshein 2024-10-14 7:17 ` [devel-distro] " Sergey V Turchin 2024-10-14 19:57 ` [devel-distro] Интерфейсы " Evgeny Sinelnikov 2024-10-14 21:23 ` Leonid Krivoshein [this message] 2024-10-14 21:57 ` Антон Мидюков 2024-10-15 1:11 ` Leonid Krivoshein 2024-10-15 4:49 ` Anton Farygin 2024-10-15 9:44 ` Michael Shigorin 2024-10-15 15:05 ` Denis Medvedev 2024-10-16 0:25 ` Leonid Krivoshein 2024-10-17 7:22 ` [devel-distro] " Sergey V Turchin 2024-10-15 19:29 ` [devel-distro] " Leonid Krivoshein 2024-10-17 7:27 ` [devel-distro] " Sergey V Turchin 2024-10-18 9:05 ` [devel-distro] [JT] мировоззренческое по путям развития Michael Shigorin 2024-10-15 5:19 ` [devel-distro] Интерфейсы для инсталлятора на базе альтератор 2.0 Evgeny Sinelnikov 2024-10-15 23:02 ` Leonid Krivoshein 2024-10-15 10:30 ` [devel-distro] инсталятор как краеугольный камень выбора технологического пути Michael Shigorin 2024-10-09 1:40 ` [devel-distro] Installator 2.0: конфигуратор, создающий kickstart-файл Leonid Krivoshein 2024-10-09 9:06 ` [devel-distro] " Sergey V Turchin 2024-10-09 19:46 ` [devel-distro] " Leonid Krivoshein 2024-10-10 19:29 ` [devel-distro] про API и фронтэнды Leonid Krivoshein 2024-10-10 23:27 ` Антон Мидюков 2024-10-11 0:33 ` Leonid Krivoshein 2024-10-14 7:27 ` Sergey V Turchin 2024-10-15 4:59 ` [devel-distro] Веб-браузер в инсталляторе или для инсталлятора? Evgeny Sinelnikov 2024-10-15 5:53 ` Антон Мидюков 2024-10-15 20:53 ` Leonid Krivoshein 2024-10-18 9:25 ` Michael Shigorin 2024-10-14 7:22 ` [devel-distro] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Sergey V Turchin 2024-10-14 19:58 ` [devel-distro] " Leonid Krivoshein 2024-10-15 4:52 ` Anton Farygin 2024-10-15 19:30 ` Leonid Krivoshein 2024-10-15 6:33 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:32 ` [devel-distro] " Sergey V Turchin 2024-10-17 7:49 ` [devel-distro] " Антон Мидюков 2024-10-17 8:44 ` [devel-distro] " Sergey V Turchin 2024-10-18 8:56 ` [devel-distro] qtbrowser vs wasm Michael Shigorin 2024-10-15 10:03 ` [devel-distro] [JT] Re: Installator 2.0: конфигуратор, создающий kickstart-файл Michael Shigorin 2024-10-15 23:49 ` Leonid Krivoshein 2024-10-16 8:52 ` Michael Shigorin 2024-10-14 7:43 ` [devel-distro] " Sergey V Turchin 2024-10-14 10:54 ` [devel-distro] " Sergey V Turchin 2024-10-09 9:49 ` [devel-distro] " Alexey Gladkov 2024-10-09 19:54 ` Leonid Krivoshein 2024-10-10 9:10 ` Alexey Gladkov 2024-10-10 12:21 ` Leonid Krivoshein 2024-10-10 14:31 ` Alexey Gladkov 2024-10-09 6:19 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Ivan A. Melnikov 2024-10-09 7:21 ` Антон Мидюков 2024-10-09 9:21 ` [devel-distro] " Sergey V Turchin 2024-10-09 13:08 ` [devel-distro] " Leonid Krivoshein 2024-10-09 13:56 ` [devel-distro] о голосовом управлении (was: Тезисы для инст, альтератор 2.0) Arseny Maslennikov 2024-10-10 8:11 ` [devel-distro] о голосовом управлении Антон Мидюков 2024-10-14 7:33 ` [devel-distro] Re: Тезисы для инсталлятора на базе альтератор 2.0 Sergey V Turchin 2024-10-09 22:08 ` [devel-distro] " Leonid Krivoshein 2024-10-10 1:01 ` [devel-distro] Пример файла разметки и описания Leonid Krivoshein 2024-10-10 8:54 ` Антон Мидюков 2024-10-10 5:26 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 Антон Мидюков 2024-10-10 10:29 ` Leonid Krivoshein 2024-10-14 4:58 ` [devel-distro] Тезисы для инсталлятора на базе альтератор 2.0 (промежуточный итог) Антон Мидюков 2024-10-14 18:59 ` Leonid Krivoshein
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bce5158b-9bb0-40e4-988c-0453c08327ac@gmail.com \ --to=klark.devel@gmail.com \ --cc=devel-distro@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Distributions development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \ devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com public-inbox-index devel-distro Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-distro AGPL code for this site: git clone https://public-inbox.org/public-inbox.git