Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification

[Paul Sopka <psopka@sopka.ch>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 8242 bytes --]


> 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.

Extremely relying on specific functionality of an external program, 
forces the maintainer to tightly monitor the programs development and 
extensively test all its releases, in practice: forcing the possible 
Turnstile package on Gentoo to have the same maintainer(maintaining 
group) as the possible s6/s6-rc profile. 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. 
Running the backend as root could just be added as a config option to 
Turnstile.

But I think we are approaching philosophical/subjective grounds here.

It is good that we develop our own interpretations of "the best" 
solution, learning from and criticizing each other.


> 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.


> See `/run/service/s6rc-fdholder-filler/run` on your machine for
> another solution: have 'ready' be only
>
> ```
> s6-rc -l "$string" -up change default
> ```
>
> and 'run' be
>
> ```
> ... fdmove -c 3 1 pipeline -dw { if -nt { s6-rc-init } s6-svscanctl -t
> ... } fdswap 3 1 s6-svscan -d3 ...
> ```
>
> Instead of just s6-svscan (i. e. feed the readiness notification to
> another step instead directly sending s6-svscan's notification to
> turnstile).
Thanks, will test!


> 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


> Turnstile already answers item b: `/etc/turnstile/backend/*.conf` and
> argument #4 of the run script. For a, nothing stops a backend from
> sourcing one itself, and the runit backend is a precedent.
Yet again needing tight integration with Turnstile. I do not think this 
is inherently bad, I just do not personally like such tight integration 
if I can do it differently.


> 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?


> For instance, I once tried to make my equivalent set of scripts
> "username-agnostic" and use s6's (the supervision suite's) built-in
> instancing feature — with the username as the parameter — to spawn
> user supervision trees. This was enough to make execline painful to
> use correctly, and I had to switch to a shell script.
I will try that too, because I think this would be the most elegant way 
to start user service trees, if one doesn't want to rely on Turnstile.


> I'm currently writing a turnstile backend [1] that has a catch-all
> logger and does s6-rc-init in the `run` step; it's refreshing to be
> able to reasonably write it in execline.
>
> [1]https://paste.artixlinux.org/view/6308e776
Wow, I will look into that in more detail for sure!


> I don't think "low number of config files" is a metric worth
> optimizing for, especially when the tradeoff is encoding desktop
> assumptions in low-level policy.
I need to be careful to not have two or more important config files that 
contain the same setting parsed by different essential software. This 
would require the sysadmin to keep them in sync.

Additionally I do think that "low number of config files" is an 
important metric when it comes to /related/ settings, since that makes 
life easier for users and sysadmins.


> See s6-svscan's -X option. This can be done entirely within the user's
> supervision tree, and relies on the same foundation as the catch-all
> logging in s6-linux-init; it just requires the scan directory to be
> initialized with a catch-all logger before s6-svscan is run.
Thank you, I will take a look!


> 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)


> I'm not aware of any Turnstile replacements, and given your design
> goals, I think you're better off creating a small single-job PAM
> module like pam_rundir [1]. Make it invoke
> s6-rc/s6-instance-{create,delete}/whatever when logging in/out instead
> of managing a runtime directory.
>
> I don't think writing such a module is worth it, though. Turnstile
> allows your system policy to only worry about core machine management;
> your proposal will instead muddle that with stuff that's only relevant
> for the desktop services.
>
> [1]https://gitea.artixlinux.org/artix/pam_rundir
Thanks for the heads up and the link.


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,...


This allows the following:

1) Solving all of Bercots cases 
(https://skarnet.org/lists/supervision/3114.html) A), B) and C) with 
"just" 2 user-service-trees, one being nested inside the other.

2) Not relying on external tools to do basic work.

3) Being uniform (everything based on s6-tools) and thus (hopefully) 
relatively easy to maintain.


Do you see any issues with that proposal?


Thank you for your critique!


Paul


[-- Attachment #1.1.1.2: Type: text/html, Size: 11526 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]