Em seg., 8 de jul. de 2024 às 09:55, Paul Sopka <psopka_at_sopka.ch> escreveu:
> You're making more work for yourself and the people who'd help you
> maintain the service set, and making an s6 policy with more
> assumptions.
>
> I disagree. If the most important work is delegated to the service
scripts, once it works, it works. Forever. Easy to adapt and replace by
sysadmins/users.
"Forever" is a strong word (see below), and for the latter of these to be
true, a lot of thought must go into packaging and design.
> Extremely relying on specific functionality of an external program,
forces the maintainer to tightly monitor the programs development and
extensively test all its releases.
This is the maintainer's job. Even s6 is not an unchanging foundation; it
has had commands being renamed and shifting from one package to another in
the past, and some use cases stopped being supported along the way.
One example I remember is setsid becoming mandatory for services, which
broke mine and a few people's "X server/compositor as a service" setup
under elogind+polkit back in the day.
> in practice: forcing the possible Turnstile package on Gentoo to have the
same maintainer(maintaining group) as the possible s6/s6-rc profile.
Not necessarily. Turnstile is designed in a way that makes it possible for
the people writing the s6-rc profile to focus on getting system daemons
right and have their mission regarding desktop services stop at creating a
Turnstile service, and to ensure the responsibility for a working user
services setup to fall entirely on the maintainers of latter, which can
test every backend without switching PID 1 – people from other profiles
could help test it (as is the case in Artix; there are OpenRC users who use
Turnstile despite there being only runit and dinit backends).
Turnstile's developers also seem to be cooperative in regards to having
backends upstreamed and coordinating changes to them.
Instead, your proposals heavily burden the s6/s6-rc profile developers with
a mostly desktop-specific problem, task them with developing and
maintaining not only a complex and specialized set of services but also
custom PAM modules, and the result relies heavily on using s6-rc with
dynamic event sources, which it is not yet perfectly suited for.
> It also forces more assumptions on everybody, since we need to comply to
the exact way Turnstile solves things:
> Non daemontools-style supervisors, such as dinit (which is Turnstile's
> default), also don't provide a simple "setuidgid" privilege dropper,
> so they'll have little use for this functionality unless they add more
> dependencies or become more error-prone.
>
> This shows it quite nice, as it would have me need to align more to the
limitations of dinit, even though I do have the tools for the job.
The limitation is not because of dinit. It's part of the project's goals.
(If they really wanted to, they could clone setuidgid, as many people have
since daemontools came out, or accept the risk that comes with root
privileges).
The s6-rc backend you're requesting in that issue would be a special
snowflake that ignores the XDG_RUNTIME_DIR setting present in
turnstiled.conf in favor of one in a idiosyncratic master environment file
instead, and assumes a specific system service manager with a specific set
of services (most of which duplicating what Turnstile already provides).
Remember Turnstile backends should not care about what PID 1 is running.
There are only multiple config files to worry about keeping in sync, and
unavoidable integration issues that require constant intervention from the
maintainers of the s6 system service set, because you want to force the
project in a different role from what it was designed for: a one stop shop
desktop service daemon.
Since you're bumping against core design decisions in Turnstile, your setup
is better off relying on its own PAM stuff.
> There's two additional arguments: "$srv_dir", a folder that's
> dedicated to temporary files for the service manager (which seems to
> me to be the ideal place for s6-svscan's scan directory and s6-rc's
> live folder¹), and "$confdir", which is the path to where the
> configuration files reside (which can serve as the storage place for
> an environment file).
>
> It seems less then ideal to me to use the filesystem as a temporary
storage, when all that is needed are a handful environmental variables,
which can easily be passed to the backend.
I'm not sure what environment variables you are referring to. If you mean
storing XDG_RUNTIME_DIR and s6-rc's live directory there for the ready
directive, see below for why I don't think it's a good idea.
> Given dinit has the service management and service supervision layers
> in the same executable, Turnstile's authors probably expect the
> service management layer being up and running by the time 'run' has
> notified readiness, which is possibly why they didn't bother exporting
> variables in the "ready" script.
>
> Adding the ability to pass the env's to the ready function in the form of
a config option in turnstile.conf would probably be the best way to allow
elegant integration with s6-rc. I have opened an issue for that, see here:
https://github.com/chimera-linux/turnstile/issues/15
I don't think this is elegant, as it doesn't allow Turnstile to recognize a
failure of s6-rc-init and try again in that case. Remember backends are
supposed to run _service managers_.
This is probably irrelevant now, since it's clear Turnstile isn't what
you're looking for.
> I'd rather document that the user must edit the desktop service
> daemon's settings if they want to tweak how desktop services work.
>
> I technically agree, but some configs must be global, e.g.
${DBUS_SESSION_BUS_ADDRESS}, since other services, e.g. Pipewire, rely on
them.
>
> The alternative would be a dynamically populated and sourced env
directory, I am still thinking about this, but the issue I see is how to
propagate the required (currently ${DBUS_SESSION_BUS_ADDRESS} and
${XDG_RUNTIME_DIR}) to the user's login shell now that they are dynamic and
maybe not completely set on login?
Turnstile's PAM module does that, synchronizing these in the login process
to be the same ones as in the supervision tree the daemon spawns, and
unless you want to make users replace their shell with something like
`/etc/execline-startup` as described in
https://skarnet.org/lists/supervision/3126.html, your proposal is going to
need a custom PAM module for that too.
> As Laurent said (in regards to graphical user services, but I believe
> this applies here), the tradeoff is introducing environment data
> sharing and process lifetime management across unrelated process
> trees, which is neither.
>
> This might be subjective again, but I would not consider the user (and
thus his service-tree) be unrelated to the system he uses (and thus the
system-tree)
Under your design, the process that authenticates the user and has all the
information provided by PAM (or an eventual replacement) will be unrelated
to the user supervision tree (in the sense that the supervision tree will
not be forked off from it). This is a fact.
Turnstile requires the service backend not to be a oneshot to ensure the
supervision tree is a child of an actual login session.
> This brings me to my last point, an idea I got while writing this:
https://skarnet.org/lists/supervision/3131.html.
>
> The idea is the following:
>
> - Make a user service tree on boot (preferably using instantiated
services) if the user has an appropriate dir in ${XDG_DATA_HOME} (most
likely /home/${USER}/.local/.share/s6-rc/...). This service prepares all
the basics, e.g. ${XDG_RUNTIME_DIR}, the logging dir of the user services,
...
>
> Then:
>
> - Autostart all user-services in an "autostart" bundle the user populated.
>
> - Upon first login start a "login" bundle the user populated, stop it
after last logout. This can be fine grained with a bundle for ssh login, a
bundle for getty login,..., using appropriate PAM modules.
>
> - An env directory which is also used by the user-services shall be
sourced upon login.
>
> - Upon starting a graphical session start a sub-user-tree with the
s6-svscan process being a child of the wayland compositor,X server,...
>
The "per-login-type bundle" idea would require counting each type of login
independently. You also probably don't want to stop bundles, only keep
track of the necessary ones and `-up change` as events come, in order to
handle overlap among them.
Obarun Linux's 66 service manager (which is the one mentioned in the closed
Turnstile issue you first commented on) also works with s6 user supervision
trees spawned directly off of the system tree. You might want to study it.
I'll limit my comments to that, since you clearly plan to add complexity to
the service set and the service management layer in the way I predicted in
my previous message, and make XDG policies a deep-rooted default. We'll
likely just not agree again.
...and you're probably tired of me shilling Turnstile :P.
Have a nice Tuesday.
Received on Tue Jul 09 2024 - 18:24:43 CEST