Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-20 Thread Jan Braun
Paul Sopka schrob:
> I do not think that providing only this option this is a good idea,
> since names are unique and dependencies are declared in the dependent
> service.

"It simplifies dependencies" sounds like a good reason to go with the
tryexec approach.

Cheers,
Jan


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-20 Thread Paul Sopka
 Overrides? No, this would make things confusing and error-prone. The 
behaviour
of a set of source definition directories should not be influenced by 
whether or not

you're compiling it with another set.

Thanks for letting me know!

Regards,

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-20 Thread Paul Sopka

I think there's a misunderstanding here, I'll try again:
What I proposed is putting the service definitions into /usr, never copy
or link them to /etc, never modify them (except by package updates), and
let s6 execute them directly from there.

If the local admin wants something other than the service as you ship
it, they create a completely new, independent local service and disable
the one shipped by you.

Thus you can update the definitions in /usr as you see fit, and the
admin can override things as they see fit. No machinery needed inside
the actual run scripts.

I do not think that providing only this option this is a good idea,
since names are unique and dependencies are declared in the dependent 
service.


Consider the example of "seatd-srv":

The sysadmin disables it and creates "seatd-new-srv",
now he has to create a "${SERVICE}-new-srv" for every "${SERVICE}-srv" 
depending on "seatd-srv"
to adjust their dependencies, do the same for every 
"${SERVICE}-new-srv", ...


Of course, this can easily be solved by only ever depending on bundles,
thus, one creates "seatd-new-srv" adds it to the bundle 
"seat-management"(everyone depends on),
removes "seatd-srv" from "seat-management" and has exactly what you 
envisioned.


Thus, a policy of "only ever depend on a bundle", which I already 
employ, is needed.
Anyway, I am not sure if all if this additionally requirement is really 
worth saving one line per service script.


A point for your approach is, of course, that the user gains full control
over the service he changed, as he is able to change the logging 
behavior, dependencies, ...


That however, requires way more insight into the entire service system, 
s6 and s6-rc
as opposed to "read the script, understand the script, adapt the script, 
put it in the right place".


Regards,

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-19 Thread Jan Braun
Paul Sopka schrob:
> > > ... then begs the question: what's the advantage of having the
> > > ${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
> > > does this save the admin over creating their own my_seatd service and
> > > disabling the one you provide?
> > > (Honest question, I don't fully grok s6.)
> > 
> > It doesn’t save any effort at all.
> I disagree, because it allows original service scripts to sit at
> /usr/lib/s6-rc/{user,system}/src/service
> and be recklessly updated by the package manager.

I think there's a misunderstanding here, I'll try again:
What I proposed is putting the service definitions into /usr, never copy
or link them to /etc, never modify them (except by package updates), and
let s6 execute them directly from there.

If the local admin wants something other than the service as you ship
it, they create a completely new, independent local service and disable
the one shipped by you.

Thus you can update the definitions in /usr as you see fit, and the
admin can override things as they see fit. No machinery needed inside
the actual run scripts.

Cheers,
Jan


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-19 Thread Paul Sopka

... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
does this save the admin over creating their own my_seatd service and
disabling the one you provide?
(Honest question, I don't fully grok s6.)


It doesn’t save any effort at all. 
I disagree, because it allows original service scripts to sit at 
/usr/lib/s6-rc/{user,system}/src/service

and be recklessly updated by the package manager.

For the record, I’m also in favor of this: the simpler the service 
scripts, the better in my opinion. They’re easier to understand, 
simpler to adapt. A short and direct script can be as descriptive as 
descriptive configuration files sometimes, but better because you 
actually know everything that takes place. :D 
I wholeheartedly agree, this is pretty exactly my mindset too. 
Additionally they are probably faster, since they are smaller and do not 
need to parse configs.


Regards,

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-19 Thread Paul Sopka

From Jan:


That's a more reasonable size than your first example. Although this ...


Allowing the sysadmin to completely override the service.
Unfortunately this also forces the sysadmin to override the service for
every so little change,

... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
does this save the admin over creating their own my_seatd service and
disabling the one you provide?
(Honest question, I don't fully grok s6.)

It does not have anything to do with s6 itself,
it just allows original service scripts to sit at 
/usr/lib/s6-rc/{user,system}/src/service

and be recklessly updated by the package manager.

Installing them initially to /etc/s6-rc/{user,system}/src/service and 
editing them in place

will not allow that. This is in part mitigated by:


I am not sure if I understand correctly, the files under
/usr/share/s6-rc/{user,system}
are to be there only as a reference, not to be edited.
Are you trying to say that the non-edited files should be symlinked rather
than copied?

I was indeed trying to say that.
But on second thought: you should do whatever Gentoo usually does with
such configuration files. Consistency trumps any minor advantages any
particular approach might have.

But this introduces needless complexity just to save one line in every 
script.


The best would probably be for s6-rc-compile to allow for multiple 
definitions of a service,

letting later definitions override earlier ones, e.g.

s6-rc-compile ${OUTPUT_DB} ${SOURCE_1} ${SOURCE_2}

where seatd-srv in ${SOURCE_2} overrides seatd-srv in ${SOURCE_1}.

Would this be realizable Laurent?

Regards,

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-19 Thread Hoël Bézier

Am Do, Sep 19, 2024 am 07:51:50 +0200 schrieb Jan Braun:

Allowing the sysadmin to completely override the service.
Unfortunately this also forces the sysadmin to override the service for
every so little change,


... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
does this save the admin over creating their own my_seatd service and
disabling the one you provide?
(Honest question, I don't fully grok s6.)


It doesn’t save any effort at all.


Being able to easily add custom services is a necessity anyway.

So maybe don't allow any customization (besides disabling) at all, ship

| #!/bin/execlineb -P
| fdmove -c 2 1
| seatd -n3 -u root -g seatd

and teach users to create new services with the 3rd line changed to
whatever they need.


For the record, I’m also in favor of this: the simpler the service scripts, the 
better in my opinion. They’re easier to understand, simpler to adapt. A short 
and direct script can be as descriptive as descriptive configuration files 
sometimes, but better because you actually know everything that takes place. :D


Hoël


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-19 Thread Jan Braun
Paul Sopka schrob:
> I am not sure if I understand correctly, the files under
> /usr/share/s6-rc/{user,system}
> are to be there only as a reference, not to be edited.
> Are you trying to say that the non-edited files should be symlinked rather
> than copied?

I was indeed trying to say that.
But on second thought: you should do whatever Gentoo usually does with
such configuration files. Consistency trumps any minor advantages any
particular approach might have.

> Although it has to be done a bit differently when using execline
> [...]
> Would turn into:
> 
> | #!/bin/execlineb -P
> | fdmove -c 2 1
> | importas -SD /etc/s6-rc S6CONFIGDIR
> | tryexec ${S6CONFIGDIR}/system/config/seatd
> | seatd -n3 -u root -g seatd

That's a more reasonable size than your first example. Although this ...

> Allowing the sysadmin to completely override the service.
> Unfortunately this also forces the sysadmin to override the service for
> every so little change,

... then begs the question: what's the advantage of having the
${S6CONFIGDIR}/system/config/seatd entry point at all? How much effort
does this save the admin over creating their own my_seatd service and
disabling the one you provide?
(Honest question, I don't fully grok s6.)

Being able to easily add custom services is a necessity anyway.

So maybe don't allow any customization (besides disabling) at all, ship

| #!/bin/execlineb -P
| fdmove -c 2 1
| seatd -n3 -u root -g seatd

and teach users to create new services with the 3rd line changed to
whatever they need.

HTH,
Jan


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-19 Thread Paul Sopka

A skeleton is not config data, and should thus be in /usr/
Possibly /usr/.../examples/...
I agree, the reason i put it there ist that /etc/s6-linux-init/skel/ 
exists (at least on Gentoo Linux), thus for consistency.



- The package manager puts service source directories and an initial
set of bundles for system services to
/etc/s6-rc/system/src/{services,bundles}.

- The package manager puts service source directories and an initial
set of bundles for both user and system services to
/usr/share/s6-rc/{user,system} as a reference of the defaults.

If you put defaults in /usr, then prefer symlinking them into /etc,
rather than creating a copy. That'll automatically handle changing
defaults, and make it obvious what is locally customized.


I am not sure if I understand correctly, the files under 
/usr/share/s6-rc/{user,system}

are to be there only as a reference, not to be edited.
Are you trying to say that the non-edited files should be symlinked 
rather than copied?



Void has a nice idiom in their run scripts:

| #!/bin/sh
| exec 2>&1
| [ -r conf ] && . ./conf
| exec acpid -f ${OPTS:=-l}

That achieves 3 things:
1) It works out of the box (without a conf file).
2) The user can create a conf file containing
 OPTS='-l -d -S'
to customize the daemon options.
3) The user can create a conf file containing
 if [ $((`date +%s` % 100)) -eq 0 ] ; then poweroff ; fi
 exec /usr/local/bin/notreallyacpid --foo
to completely¹ override the run file.

Note how the KEY=value pair in 2) is actually shell, hopefully
eliminating any worries about config file format.

HTH,
 Jan

¹)
The "exec 2>&1" is an artifact of how runit does logging, and should
always be done. Hence it comes before the conf entry point. If there was
a valid use for stderr, lines 2 and 3 could be switched, of course.

Glorious.
Although it has to be done a bit differently when using execline (which 
I intend to use):


Take my current version of the seatd-srv:

| #!/bin/execlineb -P
|
| fdmove -c 2 1
|
| multisubstitute
| {
| define SRV seatd
| importas -SD /etc/s6-rc S6CONFIGDIR
| }
|
| envfile -I ${S6CONFIGDIR}/system/config/${SRV}.conf
|
| multisubstitute
| {
| importas -SD "root" SEATD_USER
| importas -SD "seat" SEATD_GROUP
| importas -SD "seatd" SRV_EXEC
| importas -sSD "" SRV_OPTS
| }
|
|
| ${SRV_EXEC}    -n3
| -u ${SEATD_USER}
| -g ${SEATD_GROUP}
| ${SRV_OPTS}

Would turn into:

| #!/bin/execlineb -P
|
| fdmove -c 2 1
|
| importas -SD /etc/s6-rc S6CONFIGDIR
|
| tryexec ${S6CONFIGDIR}/system/config/seatd
|
| seatd -n3 -u root -g seatd

Allowing the sysadmin to completely override the service.
Unfortunately this also forces the sysadmin to override the service for 
every so little change,

so your


2) The user can create a conf file containing
 OPTS='-l -d -S'
to customize the daemon options.
wont work anymore but I do not see how one could work around this in 
execline.


What do you think?


Regards,

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: config files for service scripts

2024-09-18 Thread Jan Braun
Paul Sopka schrob:
> - The sysadmin or the user can copy a skeleton from
> /etc/s6-rc/skel/{config,src} (which is populated by the package
> manager with configs and initial bundles) to ${HOME}/.config/s6-rc/,
> this folder shall be used for configuration and custom user services.

A skeleton is not config data, and should thus be in /usr/
Possibly /usr/.../examples/...

> - The package manager puts service source directories and an initial
> set of bundles for system services to
> /etc/s6-rc/system/src/{services,bundles}.
> 
> - The package manager puts service source directories and an initial
> set of bundles for both user and system services to
> /usr/share/s6-rc/{user,system} as a reference of the defaults.

If you put defaults in /usr, then prefer symlinking them into /etc,
rather than creating a copy. That'll automatically handle changing
defaults, and make it obvious what is locally customized.


> - The idea of config files is completely dropped and the "editing the
> config" part is shifted to "editing the run-script"
> [...]
> Do you suggest any alterations or even a completely different approach?

Void has a nice idiom in their run scripts:

| #!/bin/sh
| exec 2>&1
| [ -r conf ] && . ./conf
| exec acpid -f ${OPTS:=-l}

That achieves 3 things:
1) It works out of the box (without a conf file).
2) The user can create a conf file containing
OPTS='-l -d -S'
   to customize the daemon options.
3) The user can create a conf file containing
if [ $((`date +%s` % 100)) -eq 0 ] ; then poweroff ; fi
exec /usr/local/bin/notreallyacpid --foo
   to completely¹ override the run file.

Note how the KEY=value pair in 2) is actually shell, hopefully
eliminating any worries about config file format.

HTH,
Jan

¹)
The "exec 2>&1" is an artifact of how runit does logging, and should
always be done. Hence it comes before the conf entry point. If there was
a valid use for stderr, lines 2 and 3 could be switched, of course.


signature.asc
Description: PGP signature


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

2024-07-17 Thread Laurent Bercot




Is there an equivalent chainloader ("envfile"-style) that can be plugged
into the instanced user service directories' command line?

Having the same configuration file be read by tools with different
behaviors (for instance, it appears the pam_env's quoting support is far
more limited than envfile's) may not lead to the same results.


 I wanted envfile to be compatible with intuitive and expected
behaviour. If you write your files conservatively wrt what other tools
accept, you should be able to read them with envfile.

--
 Laurent



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

2024-07-17 Thread Carlos Eduardo
Is there an equivalent chainloader ("envfile"-style) that can be plugged
into the instanced user service directories' command line?

Having the same configuration file be read by tools with different
behaviors (for instance, it appears the pam_env's quoting support is far
more limited than envfile's) may not lead to the same results.

Em seg., 15 de jul. de 2024 06:35, Paul Sopka  escreveu:

> > There's already pam_env to set environment variables. And from
> > pam_env.conf it can expand @{HOME} and presumably ${USER}, which should
> > be all you need to accomodate desktop stuff that expects XDG_* and
>
> Thank you, this looks great!
>
> Since it can also source a plain key=value file, it can source the same
> "config file" I source in the script setting up the user-service tree.
> Thus not creating the need to synchronize two config files.
>
>
> Have a nice Monday!
>
> Paul
>
>


Re: s6/s6-rc policy for Gentoo: user session tracking

2024-07-15 Thread Laurent Bercot

That said, it might be of interest to you, that s6-setlock does not appear 
here: https://skarnet.org/software/s6/index.html.


 Whoops. And nobody noticed that in 13 years? Shame on all of you. :P
 Fixed, thanks!

--
 Laurent



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

2024-07-15 Thread Paul Sopka

There's already pam_env to set environment variables. And from
pam_env.conf it can expand @{HOME} and presumably ${USER}, which should
be all you need to accomodate desktop stuff that expects XDG_* and


Thank you, this looks great!

Since it can also source a plain key=value file, it can source the same 
"config file" I source in the script setting up the user-service tree. 
Thus not creating the need to synchronize two config files.



Have a nice Monday!

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


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

2024-07-15 Thread Jan Braun
Hey,
I don't want to pick a side in the turnstile-or-not fight, so I
found something you seemed to agree on, to disagree with:

Paul Sopka schrob:
> > [...] 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.
> [...]
> My proposal [...]
> by a potential pam module that exports it's content to the users shell.

There's already pam_env to set environment variables. And from
pam_env.conf it can expand @{HOME} and presumably ${USER}, which should
be all you need to accomodate desktop stuff that expects XDG_* and
DBUS_SESSION_BUS_ADDRESS.
Everything else can and should be done via conventional places in the
file system, the way DJB intended. ;)

cheers,
Jan


signature.asc
Description: PGP signature


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

2024-07-14 Thread Paul Sopka

I am resending this unsigned, since the message is too large otherwise.



- `/run/turnstiled/sessions` exposes similar data as your proposal's
`/run/session` folder (including being able to query the session type).
Take a closer look at the prior art before writing it off.
Thank you for pointing that out. To my defense, this is neither 
mentioned on the Github page 
(https://github.com/chimera-linux/turnstile) nor in the manpage. Sorry 
if I have overlooked something. Anyway this is not what made me start 
creating this alternative.


My main reason is that the way my solution currently handles it, allows:

a) for different bundles to be started for different types of logins.

b) integrates better with my approach of handling the user service trees 
with instantiated s6/s6-rc services.


c) for less overhead and is way simpler e.g. not having to have a daemon 
running all the time.




- Just the session data isn't enough, as you need to patch third party
software that relies on it [3]. Turnstile (or, really, any proposal that
doesn't assume a specific setup of the underlying system) allows sharing
this load with other distributions.
[3]https://github.com/void-linux/void-packages/pull/44676


Those are mostly patches to Turnstile, and changes to files in 
/etc/pam.d which, as config files, are distribution/system specific 
anyway. There is one patch that is not about the above is a patch to 
polikit. I need to investigate whether this is needed for my solution 
too, since my knowledge about polkit is limited.


I still need to test all the greeters, but agetty and ssh work like a 
charm. On a sidenote: I run everything that I am seriously proposing on 
my daily system. This includes the proposed session management script.




- Expecting the user to directly edit scripts if they want different
behavior, instead providing some degree of built-in configurability, is not
reasonable for a packaged solution, as even the smallest user tweaks would
be in constant attrition with package upgrades.
I completely agree, I have stated (twice) that this is a very crude 
version. I only posted this to see whether there are any fundamental 
flaws with the idea. The statements about extensibility, e.g.


- Possibly create a /run/session/${USER} directory. 
Were more about what I am considering to add. Of course I will refine 
the script and add configurability. I am also thinking about turning it 
into a little PAM module itself to allow it to export environment 
variables to the user's shell.




- Without a daemon's mediation, processes writing to the database have to
coordinate themselves with locks¹. This introduces risks and limitations
you don't want to have when said writes are happening without human
oversight [1] [2]. Turnstile is a daemon for a good reason.
[1]https://skarnet.org/software/s6-rc/s6-rc.html  (-b option).
That's why the option -b is here, the example of nested invocations 
should not be able to happen here, if I understood correctly.

[2]https://skarnet.org/lists/supervision/0391.html

Doesn't s6-rc -b perfectly solve that for this situation? If not, why?



- I won't repeat myself on why a system that relies on calling the current
generation of s6-rc upon receiving events, or processes meant to be running
in different contexts sharing the same supervision tree, especially one
with only a boot-time environment, are a bad idea.


Go ahead and actually explain, please. You will not repeat yourself, 
since, up until now, you really only stated that you are considering it 
a bad idea.



I've already explained why this is not true unless you want to force the
project out of its scope, and how it's an infinitely more accurate
description for your proposal.

Neither did you actually explain that. Please do.

I will go into detail on why I think the opposite is true:

If we have a group of maintainers responsible for the s6/s6-rc profile, 
they need to monitor s6/s6-rc closely. In addition to writing and fixing 
service scripts that is their job. My proposal, in it's current form, 
adds 4 additional scripts to that, which is not exactly "out of scope".


Relying on Turnstile, which to my standards is tightly integrated, 
requires quite a few things to be done in "the Turnstile way". I am not 
saying that the latter is bad! This on the other hand naturally requires 
synchronization between the Turnstile package and whatever provides the 
user service tree defaults. Which will result in either the Turnstile 
package having the same maintainers as the s6/s6-rc profile or at least 
requiring both maintaining groups to have a good connection.


I am not saying that any of this is necessarily bad, but it is causing 
more expenditure.


That said, even if it took a bit more effort to maintain my solution, 
this could be justified by the expanded functionality of per login type 
bundles and boot time user services.




Instead of reducing scope and relying on a loosely coupled third party
solution, you're making

Re: s6/s6-rc policy for Gentoo: user session tracking

2024-07-14 Thread Paul Sopka

 Yes - but since you're using s6 anyway, you also have s6-setlock,
which features more options than flock. ;)

I will happily use s6-setlock!

That said, it might be of interest to you, that s6-setlock does not 
appear here: https://skarnet.org/software/s6/index.html.



I wish you a nice week!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-14 Thread Paul Sopka

Besides consistency, putting those below $HOME would also break in NFS
setups where $HOME is shared among several machines.

Good point. I will keep the user logs at /var/log/s6/user/${USER} for now.

Please don't. There's already 2 different standards for dotfiles (XDG
and ~/.nameofprogram), inventing a third one is a case of
https://xkcd.com/927/
(But per the above, ~/ is not apropriate anyway, so the point is moot.)


I am not planning that, don't worry. I am only thinking about the idea. 
Generally, I think sometimes the 15th standard is needed if the other 
fourteen are terrible enough. People made the same joke about pipewire 
when it was started xD.



Have a nice week!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-14 Thread Jan Braun
Hey,

Paul Sopka schrob:
> [ user services have service dir in /run and logs in /var ]
> What do you think about that reasoning?

Agree.
Besides consistency, putting those below $HOME would also break in NFS
setups where $HOME is shared among several machines.

> I do not *want* to adhere to the XDG spec, it just seemed sensible to me and
> nobody has provided any reason against it so far.

See reason above. ;) But otherwise the correct sentiment.

> Anyway,  [1] made me think about why not to use a "/"-like structure under
> "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point me to any
> thread/list discussing that?

Please don't. There's already 2 different standards for dotfiles (XDG
and ~/.nameofprogram), inventing a third one is a case of
https://xkcd.com/927/
(But per the above, ~/ is not apropriate anyway, so the point is moot.)

cheers,
Jan


signature.asc
Description: PGP signature


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

2024-07-14 Thread Carlos Eduardo
Em qui., 11 de jul. de 2024 às 11:55, Paul Sopka  escreveu:
> I will try and summarize what we have now.
>
> I hope you are fine with this.

Sure. Long e-mails get tiring to read and reply to, for both of us.

> https://skarnet.org/lists/supervision/3139.html

Frankly, your priorities when designing a replacement were very misguided.

- `/run/turnstiled/sessions` exposes similar data as your proposal's
`/run/session` folder (including being able to query the session type).
Take a closer look at the prior art before writing it off.
- Just the session data isn't enough, as you need to patch third party
software that relies on it [3]. Turnstile (or, really, any proposal that
doesn't assume a specific setup of the underlying system) allows sharing
this load with other distributions.
- Without a daemon's mediation, processes writing to the database have to
coordinate themselves with locks¹. This introduces risks and limitations
you don't want to have when said writes are happening without human
oversight [1] [2]. Turnstile is a daemon for a good reason.
- Expecting the user to directly edit scripts if they want different
behavior, instead providing some degree of built-in configurability, is not
reasonable for a packaged solution, as even the smallest user tweaks would
be in constant attrition with package upgrades.
- I won't repeat myself on why a system that relies on calling the current
generation of s6-rc upon receiving events, or processes meant to be running
in different contexts sharing the same supervision tree, especially one
with only a boot-time environment, are a bad idea.

¹Which are missing from your script entirely, which is dangerous when you
have in-place editing such as the counter and newline files.

[1] https://skarnet.org/software/s6-rc/s6-rc.html (-b option).
[2] https://skarnet.org/lists/supervision/0391.html
[3] https://github.com/void-linux/void-packages/pull/44676

> Turnstile
>
> - Forks the user-tree off the turnstile process, directly related to the
> login session.

Not to _the_, but to _a_ login session. Whenever turnstiled is informed of
a log-in, it loads the PAM modules in /etc/pam.d/turnstiled, and runs
`backend run ...` as the shell. You can confirm that with a pstree;
dinit/s6-svscan are children of an intermediate "turnstiled" process, not
`login`/your display manager (see [1] for why replicating this directly on
top of a supervision suite is more trouble than it's worth).

[1] https://jdebp.uk/FGA/dont-abuse-su-for-dropping-privileges.html,
section "PAM changed everything".

> - Needs close monitoring by the people responsible for the s6/s6-rc
> overlay/profile or at least good connection between them and the
> maintainer of the Turnstile ebuild, due to its tight integration.

I've already explained why this is not true unless you want to force the
project out of its scope, and how it's an infinitely more accurate
description for your proposal.

Instead of reducing scope and relying on a loosely coupled third party
solution, you're making a solution that marries session tracking to a
specific policy for a specific init system. I wonder where I've seen that
before.

> Did I miss anything important?

I believe you're correct on the other points.

Since I've made my points here also regarding the "user session tracking"
thread, I won't make a standalone reply to it.

> Have a nice Thursday!

Have a nice Saturday :D


Re: s6/s6-rc policy for Gentoo: user session tracking

2024-07-14 Thread Laurent Bercot

Good point. If I understood everything correctly, this can be easily solved by the 
"flock" command, right?


 Yes - but since you're using s6 anyway, you also have s6-setlock,
which features more options than flock. ;)

--
 Laurent



Re: s6/s6-rc policy for Gentoo: user session tracking

2024-07-14 Thread Paul Sopka

These two last points, if you really decide to implement them like that in
the final version, may require some synchronization, e.g. via file locking.
It is not impossible (I mean, it is quite unlikely, but especially with
automated CI systems not impossible *at all*) for two SSH sessions to
come in practically at once, and I have indeed seen shell startup scripts
run the same program at the same time.
Good point. If I understood everything correctly, this can be easily 
solved by the "flock" command, right?



It would be... interesting to have one login session write the first line,
then another session immediately write the second one, and then neither of
them will find exactly one line in the file 🙂 And same for logout.

Indeed.


Have a nice weekend!

Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-14 Thread Paul Sopka

On my setup, logs are stored under a dot-directory in my home directory,
which avoids needing any cooperation from root when setting up user
services (and the mentioned risk of overlap between user and system
services).
Since I have a system service setting up the user service tree, this is 
a non-issue for me. As of now, this service just creates a user owned 
subdir /var/log/s6/user/${USER}, where all logs from ${USER} go. Thus 
the main thing probably ends up weighing "having all logs at one 
place"(at /var/log/s6) against "having all user-stuff as well as the 
logs in one place" (at ~/).


If I now compare this to ${XDG_RUNTIME_DIR} and the service dir of the 
s6 user-tree, it follows that, should I have the logs at "~/...", why do 
I have "${XDG_RUNTIME_DIR} as well as the service dir of the user" at 
/run/...


It is clear that those should reside in tmpfs for speed and the elegance 
of self clean up on boot, should something go wrong. I would consider 
mounting an tmpfs for every user having set up user-services at "~/" 
needlessly complicated and overkill.


For consistency reasons it then follows that the user tree logs should 
be in a dir at /var/log/s6/users/${USER} or something comparable, as the 
"${XDG_RUNTIME_DIR} and service dir of the user" are at 
/run/user/${USER} or comparable. With the nice bonus of having all the 
logs in one place.


What do you think about that reasoning?



Due to /var == ~/.local/state according to the XDG spec (which, from your
other threads, you seem to want to follow closely), you might want to use
"${HOME}/.local/state/log/${daemon}" [1].


I do not *want* to adhere to the XDG spec, it just seemed sensible to me 
and nobody has provided any reason against it so far.


Anyway,  [1] made me think about why not to use a "/"-like structure 
under "~/" (e.g. ~/.var, ~/.etc) instead of the XDG spec. Can you point 
me to any thread/list discussing that?



[1]https://forum.artixlinux.org/index.php/topic,6918.msg41919.html#msg41919



I wish you a very nice weekend!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: user session tracking

2024-07-14 Thread Peter Pentchev
On Thu, Jul 11, 2024 at 04:53:51PM +0200, Paul Sopka wrote:
> Since I was not 100% convinced by Turnstile, I made an attempt on a very
> simple alternative way to handle user session tracking.
> 
> The (currently very crude) script only runs once on each login and logout
> and does the following:
> 
> On login:
> 
> - Possibly create a /run/session/${USER} directory.
> 
> - Possibly start the user supervision tree (from S6/s6-rc or OpenRC, or
> anything but itself).
> 
> - If it does not exist, create a file named after the login type (e.g. sshd)
> at /run/session/${USER}/${LOGIN_TYPE}.
> 
> - Write a line (any content, but just one line) to
> /run/session/${USER}/${LOGIN_TYPE}.
> 
> - If the line count in /run/session/${USER}/${LOGIN_TYPE} is 1, start the
> bundle corresponding to ${LOGIN_TYPE} e.g. sshd.

These two last points, if you really decide to implement them like that in
the final version, may require some synchronization, e.g. via file locking.
It is not impossible (I mean, it is quite unlikely, but especially with
automated CI systems not impossible *at all*) for two SSH sessions to
come in practically at once, and I have indeed seen shell startup scripts
run the same program at the same time.

It would be... interesting to have one login session write the first line,
then another session immediately write the second one, and then neither of
them will find exactly one line in the file :) And same for logout.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-12 Thread Carlos Eduardo
On my setup, logs are stored under a dot-directory in my home directory,
which avoids needing any cooperation from root when setting up user
services (and the mentioned risk of overlap between user and system
services).

Due to /var == ~/.local/state according to the XDG spec (which, from your
other threads, you seem to want to follow closely), you might want to use
"${HOME}/.local/state/log/${daemon}" [1].

[1] https://forum.artixlinux.org/index.php/topic,6918.msg41919.html#msg41919



Em ter., 9 de jul. de 2024 às 05:24, Paul Sopka  escreveu:
>
> > Quick question (that you may have already thought about, apologies in
> > advance): what happens if one wants to start a new daemon that has
> > the same name as an already existing system user account?
> > Also, what happens if a new system user account is created with
> > the same name as an already configured service daemon?
> Thank you for the heads up and don't apologize, you are completely right.
> > Indeed. Those should be /var/log/s6/${daemon} and
> > /var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
> > any toes.
>
> This seems sensible, but I will think a bit more about the exact naming.
>
>
> Paul
>


Re: s6/s6-rc policy for Gentoo: logging settings

2024-07-11 Thread Laurent Bercot

Should every s6-log daemon have it's own config file or shall they all share 
one?


 What kind of stuff are you putting in the config file? Is it just a
template for a logging script?



Is there any general issue with the global env's from s6-linux-init's env 
directory, which makes sourcing the same config file in every s6-log script a 
better choice for a global config?


 The global environment defined in s6-linux-init applies to *all*
processes in the system. It's not nice to pollute it with stuff that
would only apply to a pretty restricted subset of all the processes
on the machine.

 Source your config file in every logger run script you have, and
leave the global environment alone. There will be no performance issue.

 For more configurability, you could e.g. have a default logging 
template

hardcoded in your run scripts, that you could override via a service-
specific configuration file.

--
 Laurent



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

2024-07-11 Thread Paul Sopka

Thanks for the extensive answer.

Since I feel like we are more and more fighting about each others 
wording and the answers consisting of quotations of each other get 
longer and longer, I will try and summarize what we have now.


I hope you are fine with this.


My approach(see here: https://skarnet.org/lists/supervision/3139.html):

- Forks the user-tree off the system-tree.

- Allows autostart of different bundles at different times (e.g. 
directly at boot time) / login types (e.g. on ssh login, on graphical 
login, ...).


- I still need to find/decide on a good solution for getting the env's 
to the user's shell.


- Needs direct maintenance of the people responsible for the s6/s6-rc 
overlay/profile.


- Adds the need for ~3 (when using s6-rc) system services to properly 
handle user service tree creation and instantiation.



Turnstile

- Forks the user-tree off the turnstile process, directly related to the 
login session.


- Austostarts the same user services on every login type, none on boot.

- Automatically exports env's to the user's shell.

- Needs close monitoring by the people responsible for the s6/s6-rc 
overlay/profile or at least good connection between them and the 
maintainer of the Turnstile ebuild, due to its tight integration.


- Handles user service tree creation itself.


Did I miss anything important?


Anyway, I will happily to continue this discussion, I think someone 
criticizing my ideas as strongly as you do, is the best way to bring 
their issues and flaws to light, so that I can solve them or even 
realize that I am on the wrong track alltogether.




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.

Thank you, I will look into that!



...and you're probably tired of me shilling Turnstile :P.
No, not at all, I have learned a lot from your criticisms. Seriously, 
keep going!



Have a nice Thursday!



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


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

2024-07-09 Thread Carlos Eduardo
Em seg., 8 de jul. de 2024 às 09:55, Paul Sopka  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 th

Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-09 Thread Paul Sopka

Quick question (that you may have already thought about, apologies in
advance): what happens if one wants to start a new daemon that has
the same name as an already existing system user account?
Also, what happens if a new system user account is created with
the same name as an already configured service daemon?

Thank you for the heads up and don't apologize, you are completely right.

Indeed. Those should be /var/log/s6/${daemon} and
/var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
any toes.


This seems sensible, but I will think a bit more about the exact naming.


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-08 Thread Jan Braun
Peter Pentchev schrob:
> On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> > System supervision tree logs to to /var/log/${daemon}
> > 
> > User supervision tree logs got to /var/log/${USER}/${daemon}
> 
> Quick question (that you may have already thought about, apologies in
> advance): what happens if one wants to start a new daemon that has
> the same name as an already existing system user account?
> Also, what happens if a new system user account is created with
> the same name as an already configured service daemon?

Indeed. Those should be /var/log/s6/${daemon} and
/var/log/s6-user/${USER}/${daemon} respectively, to avoid stepping on
any toes.


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-08 Thread Peter Pentchev
On Sat, Jul 06, 2024 at 01:45:42AM +0200, Paul Sopka wrote:
> The last "thread" I open for this night. I promise.
> 
> I currently have set up logging in the following way:
> 
> System supervision tree logs to to /var/log/${daemon}
> 
> User supervision tree logs got to /var/log/${USER}/${daemon}

Quick question (that you may have already thought about, apologies in
advance): what happens if one wants to start a new daemon that has
the same name as an already existing system user account?
Also, what happens if a new system user account is created with
the same name as an already configured service daemon?

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo

2024-07-08 Thread Paul Sopka

Not sure what you mean by "instantiated services". But see below.

See here: https://skarnet.org/software/s6/instances.html.



Sorry for my tone, I realize I was grumpy, possibly offensively so. You
took it well, thanks. 🙂


No worries, in my opinion the focus should be on being more resilient 
and less careful when talking anyway. I think that allows for more 
direct and efficient communication.


Also, you were right.



While I don't know why one would want to differentiate between those,
you probably can do that quite straightforwardly with pam_exec(8)
Many probably do not need pipewire, mpd or even dbus started when just 
ssh'ing into a system.


Also see Bercot's comment here: 
https://skarnet.org/lists/supervision/3121.html (paragraph 2).




And you'll need one admin action which creates the service supervising
~$USER/.foo/supervisor (if that service doesn't exist yet). To be
triggered on user account creation, or probably on login if things like
ldap are involved.
If I get it right, this is what the instantiated services are supposed 
to resolve automagically.


All that's left is the requirement of the user configuring hist 
autostarts, and if he doesn't, nothing will be instantiated and no 
overhead is generated.



calling a tiny script that tracks the number of active sessions (of type
"$1") and calls s6-rc on zeroes.


And if you want to make this machinery user-customizable, you'll need
three user entry points:
~/.foo/supervisor
 defaulting to "s6-svscan $scandir"
~/.foo/login  
 defaulting to "if $concurrent == 0 then s6-rc start $type"
~/.foo/logout  
 defaulting to "if $concurrent == 0 then s6-rc stop $type"

Amazing, thank you, I will look into that as soon as I can!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


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

2024-07-08 Thread Paul Sopka



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 sof

Re: s6/s6-rc policy for Gentoo

2024-07-08 Thread Jan Braun
Paul Sopka schrob:
> An alternative would be two main bundles per user service tree, that itself
> always starts on boot:
> 
> One to start at boot time.
> Another one to start on first login and stop on last login.
> This seems the most elegant and efficient. Am I overlooking anything?

I am not too familiar with s6 bundles (I use runit, not s6), but that
sounds reasonable.

> > This sounds unnecessarily complicated. Why not simply test for existence
> > of a well-known entry point somewhere in $HOME and let that set up the
> > user supervision tree however it sees fit (or not at all)?
> 
> If I understand correctly, this would only be possible using instantiated
> services, I like the idea and I am looking into this.

Not sure what you mean by "instantiated services". But see below.

> > Ugh. I hate this thinking. [...]
> 
> It looks like I just do not have enough experience, that's why I am asking
> you all on those points. You are right.

Sorry for my tone, I realize I was grumpy, possibly offensively so. You
took it well, thanks. :)

> Using the idea I stated above, one could use different PAM modules to start
> different bundles tho, e.g. an ssh bundle on ssh login, a getty bundle on
> getty login, a greetd bundle on greetd login.

While I don't know why one would want to differentiate between those,
you probably can do that quite straightforwardly with pam_exec(8)
calling a tiny script that tracks the number of active sessions (of type
"$1") and calls s6-rc on zeroes.


And if you want to make this machinery user-customizable, you'll need
three user entry points:
~/.foo/supervisor
defaulting to "s6-svscan $scandir"
~/.foo/login  
defaulting to "if $concurrent == 0 then s6-rc start $type"
~/.foo/logout  
defaulting to "if $concurrent == 0 then s6-rc stop $type"

And you'll need one admin action which creates the service supervising
~$USER/.foo/supervisor (if that service doesn't exist yet). To be
triggered on user account creation, or probably on login if things like
ldap are involved.

regards,
Jan


signature.asc
Description: PGP signature


Re: s6/s6-rc policy for Gentoo

2024-07-08 Thread Paul Sopka

Replacing crond with snooze, for example.
And personally, I want my ssh-agent to stay alive when I log out, so
that the key is still unlocked if/when I immediately log in again.


You have convinced me, I will see whether it is feasible to have a 
*third* user-service tree. I fear I just have to bite the bullet and 
decide upon one or two options or at least let the sysadmin decide. Yet 
another reason to not integrate extremely tight into Turnstile and 
similar, which would disallow this flexibility.


An alternative would be two main bundles per user service tree, that 
itself always starts on boot:


One to start at boot time.

Another one to start on first login and stop on last login.

This seems the most elegant and efficient. Am I overlooking anything?



This sounds unnecessarily complicated. Why not simply test for existence
of a well-known entry point somewhere in $HOME and let that set up the
user supervision tree however it sees fit (or not at all)?


If I understand correctly, this would only be possible using 
instantiated services, I like the idea and I am looking into this.




Ugh. I hate this thinking. Server/Desktop is not a binary choice. I
regularly ssh into otheruser@localhost on my main machine. Sometimes I
log in as otheruser and startx. Occasionally I start a vnc server as
otheruser. I have an mpd instance that runs as its own user.

Any desktop-only solution where people argue "you shouldn't do this on a
server" is one where I'll argue "you shouldn't do this at all".


It looks like I just do not have enough experience, that's why I am 
asking you all on those points. You are right.


Using the idea I stated above, one could use different PAM modules to 
start different bundles tho, e.g. an ssh bundle on ssh login, a getty 
bundle on getty login, a greetd bundle on greetd login.




* create a unique live dir from the "graphical" template
* start compositor
** in compositor's autostart, have something that exports the
WAYLAND_DISPLAY and calls s6-rc start
** (if possible) register s6-rc stop as an exit hook with compositor
* once the compositor exits, tear down everything.


Yes, I have suggested this too, the issues is not the starting part, but 
the proper stopping of the services. This can only be guaranteed if the 
compositor sends SIGTERM to s6-svscan upon exiting. I still need to test 
that, but to not have to rely on the compositor doing that correctly is 
why I have proposed hooking into seatd in the first place.


The finish script of the s6-svscan should then handle cleanup just fine.


Or just use X11, which properly separates Xserver from WM, avoiding any
problems caused by uncooperative compositors. 


I am planning to support an entire distro, thus I need to support them 
all: well behaved compositors, badly behaved compositors, X11, ...




If it needs a display, it goes into C, otherwise into B.
I guess writing this into a wiki article mandatory for user services 
anyway would be good enough.




Feasible, sure. Good idea, probably not. A misconfigured compositor
restarting over and over again is a pain to fix.

Agreed.



PAM. Assuming you use PAM to create the XDG_RUNTIME_DIR and start the
dbus.
Using PAM for propagating the env's seems reasonable, since we are using 
it already anyway. Will test.


On a sidenote, I still think creating XDG_RUNTIME_DIR should be the job 
of the system-service managing the user tree.



Thank you for your input!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo

2024-07-08 Thread Jan Braun
Paul Sopka schrob:
> My claim was more about a practical, applied scenario. In the terms of: If a
> user is not logged in, he simply cannot control his services. So why shall
> he have an entire user supervision tree of which the sole purpose is to
> allow the user to control the services running with his permission set,
> running at a time he is not logged in, thus not able to control his
> services?

That part seems confused. The user is able to control their services by
logging in and then invoking s6-whatever.

> Do you see any cases where this would actually be useful in real world
> applications?

Replacing crond with snooze, for example.
And personally, I want my ssh-agent to stay alive when I log out, so
that the key is still unlocked if/when I immediately log in again.

> Concerning your last point, the best I can offer for now is to have a
> script, using a template dir to create the user supervision system service.
> This can of course only be done by the system admin. The user can then add
> whatever he wants to a previously empty bundle described in the wiki, before
> invoking an "s6-user-db-update" command or similar, invoking a script that I
> supply and that does the compilation and s6-rc-update command.

This sounds unnecessarily complicated. Why not simply test for existence
of a well-known entry point somewhere in $HOME and let that set up the
user supervision tree however it sees fit (or not at all)?

> on a desktop system you rarely have someone ssh'ing in.
> On a server system no user will ever add heavy desktop scripts to the user
> service autostart, because a) he can't use them anyway and b) they shouldn't
> be there(why the heck should the sysadmin install e.g. pipewire or mpd on
> such a server? Packages which would be responsible for drawing in the
> required user services.)

Ugh. I hate this thinking. Server/Desktop is not a binary choice. I
regularly ssh into otheruser@localhost on my main machine. Sometimes I
log in as otheruser and startx. Occasionally I start a vnc server as
otheruser. I have an mpd instance that runs as its own user.

Any desktop-only solution where people argue "you shouldn't do this on a
server" is one where I'll argue "you shouldn't do this at all".

> [...]
> And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor.
> 
> I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY and
> the compositor at all.
> 
> But I argue that, in case it is ran in it's server configuration, it makes
> sense to supervise it, i.e. not starting it directly from the compositor.
> The same can be said about notification daemons, status bars, ...

You can supervise it, but the supervision tree is dependent on the
compositor. If the compositor goes away, the supervision tree needs to
die as well. If you start two compositors, you need to create two
supervision trees, one for each WAYLAND_DISPLAY.

> As you have already said this is the best example for why an additional C)
> would make sense. This is where my next problem arises, imagine we now set
> up another supervision tree for starting it up as soon as the compositor is
> there.
> 
> I can probably cleanly do this my reading from the socket seatd provides and
> using s6-fdholder-retrieve, right? How could this be stopped cleanly upon
> exiting the wayland compositor?
> 
> The issue on how to retrieve WAYLAND_DISPLAY arises again.
> 
> This could be solved by starting the "graphical" s6-svscan from the
> compositor, e.g. Hyprland, even though the compositor is not supervised,
> once it crashes it takes everything depending on it down with it anyway, so
> this doesn't matter. The biggest issue is, yet again, how to stop the
> services cleanly on exiting the compositor. Any ideas?

* create a unique live dir from the "graphical" template
* start compositor
** in compositor's autostart, have something that exports the
   WAYLAND_DISPLAY and calls s6-rc start
** (if possible) register s6-rc stop as an exit hook with compositor
* once the compositor exits, tear down everything.

Or just use X11, which properly separates Xserver from WM, avoiding any
problems caused by uncooperative compositors. 

> Another issue I see is that the user of the desktop system gets a third
> supervision tree he has to manage. And for most of the more casual people it
> is probably hard to correctly understand and use the differences between C)
> and B), in the little free time they can invest into linux.

If it needs a display, it goes into C, otherwise into B.

> There is another alternative I see: starting the compositor itself as a user
> service. I have to think about how feasible this is. What do you think?

Feasible, sure. Good idea, probably not. A misconfigured compositor
restarting over and over again is a pain to fix.

> This brings me to the final problem which the alternative mentioned above
> solves already: The user services manage a couple of things, namely the
> XDG_RUNTIME_DIR and DBUS_SESSION_BUS_A

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

2024-07-07 Thread Carlos Eduardo
Em dom., 7 de jul. de 2024 às 06:06, Paul Sopka  escreveu:

> Instead, I want to delegate as few functionality to them as possible. Why 
> should I e.g. delegate the creation a directory to a binary, configured 
> through its own config file, if it would just be one line in a script that 
> loads the defining variables and is ran anyway?

Because, as you noticed, this will require root privileges in the
backend. And, to make it generic, complexity will again be shifted
into the service set; the common default "/run/user/${UID}", for
instance, implies serial substitution in an execline script [1] or
eval in a shell. Which by then, it will no longer be a matter of "just
2 lines of execline".

[1] See https://skarnet.org/software/execline/multisubstitute.html
("Security" section) https://skarnet.org/lists/skaware/2049.html.

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.

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 experimented with Turnstile yesterday and hit major roadblocks.
>
> Here is what I have understood it does:
>
> once the user first logs in:
>
> a1) execute "${BACKEND} run ${notification_fd}"with an environment of 
> ${USER}, ${HOME}, ...

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

¹From my testing, XDG_RUNTIME_DIR also works.

> This does not work, since when a2) is invoked to run the "ready" part, we do 
> not have ${XDG_RUNTIME_DIR} anymore. I do not see how to solve this without a 
> workaround.
>
> A possible workaround would be doubly defining XDG_RUNTIME_DIR, once in the 
> Turnstile config and once in an env file which is sourced in the "ready" 
> "function".
>

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

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.

>
> I have two major issues here:
>
> A) ${BACKEND} is always invoked with the user's privileges, thus it can not 
> create ${XDG_RUNTIME_DIR} itself.
>
> B) a2) happens without the environment, see the issue with the script.
>
>
> I think A) is a problem, since I am planning:
>
> a)  to have a central user env file, preferably at 
> /home/${USER}/.config/s6-env (${XDG_CONFIG_HOME}/s6-env), for the user to 
> tweak his settings, e.g. ${DBUS_SESSION_BUS_ADDRESS}
>
>
> b) to have a central sysadmin env file, preferably at /etc/s6-rc/config (or 
> similar), for the system admin to tweak the settings, e.g. the 
> ${XDG_RUNTIME_DIR} general structure, the creation of which has to be 
> delegated to Turnstile, since the script does not have enough permissions. 
> This would then have to be doubly defined(once in the Turnstile config and 
> once in the env-file)
>

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.

I'd rather document that the user must edit the desktop service
daemon's settings if they want to tweak how desktop services work.

>
> Saying "this will make it easier to implement an alternative"
> overlooks the fact that the complexity will be shifted into the
> service set and the service manager. Is it really worth it to go
> through dynamic services and events (at least, one `install -d`
> oneshot per user, and a first login/last logout event source), and
> probably other things required to make this more reliable, pretty much
> just to make a folder?
>
> I agree about the complexity shift. But I think the solution of using 
> Turnstile just as a "notifications-system" is the best: ideally it should do 
> the following: if ${USER} first logs in, start the system service ${USER}, if 
> he logs out of the last instance stop the system service ${USER}.
>
> This yields the following advantages:
>
> A) The added complexity is in my opinion negligible(see

Re: s6/s6-rc policy for Gentoo

2024-07-07 Thread Paul Sopka
What I do is little different: my login shell is 
/etc/execline-startup, which after setting up a few things, execs into 
~/.execline-loginshell, which among other things execs into s6-envdir 
reading the same env dir as my supervision tree, and finally executes 
into my actual shell.


I’ll attach the files to this email so you can take a look at them.


This looks sensible, I might use this for myself.

That said, I have come to the following conclusion: Gentoo is a 
distribution based on choice and freedom of configuration. Thus I will 
probably just add a section to the user-service wiki entry I will write, 
explaining what directory has to be sourced and why as well as providing 
examples on how to do this with the most common login methods.


Thank you!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-07 Thread Paul Sopka



foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} ""
foreground install -d -o ${USER} -g ${USER} /var/log/${USER} ""
foreground install -d -o ${USER} -g ${USER} 
${XDG_RUNTIME_DIR}/service ""


foreground { install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} }
foreground { install -d -o ${USER} -g ${USER} /var/log/${USER} }
foreground { install -d -o ${USER} -g ${USER} 
${XDG_RUNTIME_DIR}/service }


This seems more idiomatic to me.


Agreed, will change.

Thank you!


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo

2024-07-07 Thread Hoël Bézier

Hi,

Am Sa, Jul 06, 2024 am 03:09:26 +0200 schrieb Paul Sopka:

This brings me to the final problem which the alternative mentioned
above solves already: The user services manage a couple of things,
namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be
propagated to the users login shell. Is there a more elegant way to do
this other then having the user source an env directory in his
.bash_profile?


What I do is little different: my login shell is /etc/execline-startup, which 
after setting up a few things, execs into ~/.execline-loginshell, which among 
other things execs into s6-envdir reading the same env dir as my supervision 
tree, and finally executes into my actual shell.


I’ll attach the files to this email so you can take a look at them.

Don’t credit me on this, I actually took it all from the lh-bootstrap stuff 
written by Laurent. :D


BISOUS
Hoël
#!/bin/execlineb -s0

/bin/multisubstitute
{
  importas -i HOME HOME
  importas -i LOGNAME LOGNAME
}
/bin/export USER ${LOGNAME}
/bin/s6-envdir /etc/env-startup
/bin/fdblock 0
/bin/fdblock 1
/bin/fdblock 2

/bin/tryexec { ${HOME}/.execline-loginshell $@ }
/etc/execline-shell $@
#!/bin/execlineb -s0
importas -i PATH PATH
importas -i HOME HOME
export PATH ${HOME}/.local/bin:${PATH}
s6-envdir ${HOME}/.config/env
${HOME}/.execline-shell $@
#!/bin/execlineb -s0
backtick -nx GPG_TTY { tty }
fish $@


signature.asc
Description: PGP signature


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

2024-07-07 Thread Paul Sopka

I don't think avoiding Turnstile (and similar projects) in favor of s6
services is reasonable, given the concerns you've raised in the first
block ofhttps://skarnet.org/lists/supervision/3122.html  (especially
"I'd like for the user supervision tree to only start on-demand").


I do not want to avoid them, they are straight up required to setup 
option B) from https://skarnet.org/lists/supervision/3114.html.


Instead, I want to delegate as few functionality to them as possible. 
Why should I e.g. delegate the creation a directory to a binary, 
configured through its own config file, if it would just be one line in 
a script that loads the defining variables and is ran anyway?




Turnstile's interface is reasonably simple and easy to implement in an
alternative: backends are effectively supervised 'run' (in the
s6/runit sense) scripts for the service manager with extra arguments,
and I believe it to be pretty much the minimum viable program for
adding XDG_RUNTIME_DIR compliance to any given service manager.

I experimented with Turnstile yesterday and hit major roadblocks.

Here is what I have understood it does:

once the user first logs in:

a1) execute "${BACKEND} run ${notification_fd}"    with an environment 
of ${USER}, ${HOME}, ...


 once ${BACKEND} writes back to ${notification_fd}:

a2) execute "${BACKEND} ready ${string}"/    without /the environment, 
but passing what was written back to ${notification_fd} beforehand as 
${string}


once the user last logs out:

b1) execute "${BACKEND} stop"

b2) kill the process started in a1) (in our case s6-svscan)

From that structure I naturally would propose the following script, 
having ${XDG_RUNTIME_DIR} managed by Turnstile:



#!/usr/bin/env execlineb

importas directive 1
importas readinessPipe 2
importas -S XDG_RUNTIME_DIR
importas -S USER

case ${directive}
{
    run
    {
    foreground {
        install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service
    }
    redirfd -w 3 ${readinessPipe} s6-svscan -d3 
${XDG_RUNTIME_DIR}/service

    }
    ready
    {
    foreground {
        s6-rc-init -c /home/${USER}/.local/share/s6-rc/compiled -l 
${XDG_RUNTIME_DIR}/s6-rc ${XDG_RUNTIME_DIR}/service

    }
    s6-rc -v2 -l ${XDG_RUNTIME_DIR}/s6-rc -up change default
    }
    stop
    {
    s6-rc -l ${XDG_RUNTIME_DIR}/s6-rc -bDa change
    }
}

exit 100


This does not work, since when a2) is invoked to run the "ready" part, 
we do not have ${XDG_RUNTIME_DIR} anymore. I do not see how to solve 
this without a workaround.


A possible workaround would be doubly defining XDG_RUNTIME_DIR, once in 
the Turnstile config and once in an env file which is sourced in the 
"ready" "function".



I have two major issues here:

A) ${BACKEND} is always invoked with the user's privileges, thus it can 
not create ${XDG_RUNTIME_DIR} itself.


B) a2) happens without the environment, see the issue with the script.


I think A) is a problem, since I am planning:

a)  to have a central user env file, preferably at 
/home/${USER}/.config/s6-env (${XDG_CONFIG_HOME}/s6-env), for the user 
to tweak his settings, e.g. ${DBUS_SESSION_BUS_ADDRESS}


b) to have a central sysadmin env file, preferably at /etc/s6-rc/config 
(or similar), for the system admin to tweak the settings, e.g. the 
${XDG_RUNTIME_DIR} general structure, the creation of which has to be 
delegated to Turnstile, since the script does not have enough 
permissions. This would then have to be doubly defined(once in the 
Turnstile config and once in the env-file)




Saying "this will make it easier to implement an alternative"
overlooks the fact that the complexity will be shifted into the
service set and the service manager. Is it really worth it to go
through dynamic services and events (at least, one `install -d`
oneshot per user, and a first login/last logout event source), and
probably other things required to make this more reliable, pretty much
just to make a folder?
I agree about the complexity shift. But I think the solution of using 
Turnstile just as a "notifications-system" is the best: ideally it 
should do the following: if ${USER} first logs in, start the system 
service ${USER}, if he logs out of the last instance stop the system 
service ${USER}.


This yields the following advantages:

A) The added complexity is in my opinion negligible(see my current 
scripts here: https://skarnet.org/lists/supervision/3123.html).


B) My idea gives the sysadmin and the user more control over their 
system (e.g. basing the location of ${XDG_RUNTIME_DIR} on a central env 
file where other settings are set too).


C) My idea allows plugging the user supervision tree directly into the 
system supervision tree, with the following advantages


    1) Allowing to directly attach a "catch all" logger separated from 
the logger of Turnstile


    2) Keeping the chain of efficient and reliable "skarware" from the 
top of the tree until the last user service, without Turnstile in betwe

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

2024-07-06 Thread Carlos Eduardo
I don't think avoiding Turnstile (and similar projects) in favor of s6
services is reasonable, given the concerns you've raised in the first
block of https://skarnet.org/lists/supervision/3122.html (especially
"I'd like for the user supervision tree to only start on-demand").

Turnstile's interface is reasonably simple and easy to implement in an
alternative: backends are effectively supervised 'run' (in the
s6/runit sense) scripts for the service manager with extra arguments,
and I believe it to be pretty much the minimum viable program for
adding XDG_RUNTIME_DIR compliance to any given service manager.

Saying "this will make it easier to implement an alternative"
overlooks the fact that the complexity will be shifted into the
service set and the service manager. Is it really worth it to go
through dynamic services and events (at least, one `install -d`
oneshot per user, and a first login/last logout event source), and
probably other things required to make this more reliable, pretty much
just to make a folder?

I believe point 3 to be moot because XDG policies are very thorough
and doing something even mildly different usually requires redoing
everything from scratch.




Em sex., 5 de jul. de 2024 às 20:35, Paul Sopka  escreveu:
>
> To keep all the stuff a bit organized, I will open another "thread" for
> this.
>
> I have read through
> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
> and to me the standards seem sensible. Most of it is the default of most
> if not all modern desktop programs anyway.
>
> Therefore I would like to completely comply with them in this policy.
> This involves, but is not limited to, putting the live dir in
> XDG_RUNTIME_DIR. Bercot warned me in
> https://skarnet.org/lists/supervision/3114.html that this might be
> dangerous since it could be removed to quickly upon logout.
>
>  From the start on, I planned to have all the XDG_* env's managed by the
> s6-rc system service which sets up the user supervision tree. This means
> setting the env's and, in the case of XDG_RUNTIME_DIR, creating and
> removing the directory on demand. By implementing this directly in the
> service with correct dependencies, this becomes completely safe and
> reliable.
>
> Another suggestion was to delegate the creation and removal of
> XDG_RUNTIME_DIR to the login monitoring program (which will most likely
> be Turnstile), see https://skarnet.org/lists/supervision/3117.html. I do
> not think this is the best idea. Instead, I want to push as much basic
> functionality as possible to the s6/s6-rc services, for the following
> reasons:
>
> 1) s6/s6-rc is simple, fast and reliable
>
> 2) this allows for an easier future substitution of external programs
> used (e.g. substituting Turnstile for an alternative)
>
> 3) This allows for more fine grained control by the
> sysadmins/distribution contributors.
>
> 4) The service setting up and supervising the user tree is perfectly
> suited for this, my current, working implementation of creating and
> deleting XDG_RUNTIME_DIR containing the live dir consists of two lines
> of execline
>
>
> Do you all have any objections/see any issues with the XDG Base
> Directory Specification and adhering to them?
>
> Do you see any issues with my idea of how to handle the XDG_RUNTIME_DIR?
>
> Any input is welcome!
>
>
> Paul
>


Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-06 Thread Paul Sopka

 Any environment variable you want to make available for a whole
supervision tree should be added via a "-e var=value" option to your
s6-linux-init-maker invocation. 

Thanks, will do!



 For user supervision trees, I suppose you're not using s6-l-i-m, so
the best place would be to put the variables in an envdir and use
"-E $envdir" (and possibly "-e $var" if you need to substitute $USER
or something) in your s6-usertree-maker invocation. 
If you're not using these tools, the best way is to do the same thing

they do: put the variables in an envdir somewhere, and source the envdir
both before running s6-svscan and before running your s6-rc-init and
s6-rc script. 
I tested s6-usertree-maker, but I does not do everything I need. Anyway, 
I based my currently working scripts on its output.


This is how it looks right now:


${USER}-sv/run:

#!/bin/execlineb -P

fdmove -c 2 1

define USER Nanderty
define XDG_RUNTIME_DIR /run/${USER}

emptyenv -p

export USER ${USER}

s6-envuidgid -i ${USER}

backtick -in HOME { homeof ${USER} }

multisubstitute
{
  importas -Si USER
  importas -Si HOME
  importas -Si UID
  importas -Si GID
  importas -Si GIDLIST
}

foreground install -d -o ${USER} -g ${USER} -m 700 ${XDG_RUNTIME_DIR} ""
foreground install -d -o ${USER} -g ${USER} /var/log/${USER} ""
foreground install -d -o ${USER} -g ${USER} ${XDG_RUNTIME_DIR}/service ""

export XDG_DATA_HOME ${HOME}/.local/share
export XDG_STATE_HOME ${HOME}/.local/state
export XDG_CACHE_HOME ${HOME}/.cache
export XDG_RUNTIME_DIR ${XDG_RUNTIME_DIR}
export DBUS_SESSION_BUS_ADDRESS unix:path=${XDG_RUNTIME_DIR}/session-bus

s6-applyuidgid -U

s6-svscan -d3 ${XDG_RUNTIME_DIR}/service


${USER}-sv/finish:

#!/bin/execlineb -P

define USER Nanderty

rm -rf /run/${USER}


${USER}-rc/up:

#!/bin/execlineb -P

fdmove -c 2 1

define USER Nanderty

s6-setuidgid ${USER}

foreground {
    s6-rc-init -c /home/${USER}/.local/share/s6-rc/compiled -l 
/run/${USER}/s6-rc /run/${USER}/service

}

s6-rc -v2 -l /run/${USER}/s6-rc -up change default


${USER}-rc/down:

#!/bin/execlineb -P

define USER Nanderty

s6-setuidgid ${USER}

s6-rc -l /run/${USER}/s6-rc -bDa change

Plus, of course, the catch all logger for the ${USER}-sv process.

I would just export the logging dir variable as I do with the XDG_* 
vars, so I do not need to source a variable dir. I would need to define 
them in this script anyway, if I do not want to use the env-dir as a 
permanent external config file.


Would you consider it a better way to utilize an env-dir as a means of a 
config and source it in ${USER}-sv/run, thus exporting the vars for all 
child processes anyway?



Thank you for your input.


Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo

2024-07-06 Thread Paul Sopka

 No, because the point is to allow users to have their own services,
and you definitely don't want them to have access to the root
supervision tree. So you basically have to have a separate subtree
for each user (a privilege-dropped s6-svscan), and there are a few more
policy questions to answer, in particular how to make sure the users
cannot flood the root logs by misconfiguring their own logging system.
It's doable, but not quite obvious, and it's also not quite obvious
how to set up the system so that you don't spawn a supervision tree for
inactive users or users who don't use the feature. So there's a little
more work involved. 
I know what you mean, and technically and in theory I fully agree with 
you. As mentioned this is my currently running workaround until I 
implement Turnstile.


My claim was more about a practical, applied scenario. In the terms of: 
If a user is not logged in, he simply cannot control his services. So 
why shall he have an entire user supervision tree of which the sole 
purpose is to allow the user to control the services running with his 
permission set, running at a time he is not logged in, thus not able to 
control his services?


I am sure there are niche cases this solves, but I do not think they are 
worth the overhead/maintenance burden of adding this on top of B).


Do you see any cases where this would actually be useful in real world 
applications?



in particular how to make sure the users
cannot flood the root logs by misconfiguring their own logging system.
I solved that by simple read/write permissions on on the root log dir, 
if you mean that.


If you are talking about flooding the uncaught logs logger of the 
system. Is this not just solved by a s6-log service attached to the user 
s6-svscan, acting as a catch all logger for the user tree. Since this is 
inherently a system service, the user does not have the power to 
sabotage this.


I am not sure whether I got you right on that.

Concerning your last point, the best I can offer for now is to have a 
script, using a template dir to create the user supervision system 
service. This can of course only be done by the system admin. The user 
can then add whatever he wants to a previously empty bundle described in 
the wiki, before invoking an "s6-user-db-update" command or similar, 
invoking a script that I supply and that does the compilation and 
s6-rc-update command.


B) shall solve the issue of not spawning needless supervision trees, 
since it only spawns them upon login.




 It really depends on your objective. B makes a lot of sense if you
want to treat remote logins the same way as seated logins, but there is
also an argument to have remote logins be as simple as possible while
not minding deploying the red carpet and a whole lot of extra services
for seated logins, where the overhead of setting everything up will be
negligible compared to the desktop stuff anyway.
I, again, technically agree fully, but this is in my opinion already 
solving itself in practice: on a desktop system you rarely have someone 
ssh'ing in. On a server system no user will ever add heavy desktop 
scripts to the user service autostart, because a) he can't use them 
anyway and b) they shouldn't be there(why the heck should the sysadmin 
install e.g. pipewire or mpd on such a server? Packages which would be 
responsible for drawing in the required user services.)


If you are actually talking about setting up s6-svscan etc., I think 
that a) your software and solutions resource consumption is negligible 
on modern hardware, b) I would consider user services to be a more 
desktop centric system anyway.




 B is entirely legit if you make it clear that's what users get. Just to
make sure users don't run xeyes when logging in remotely. 

lmao



 The format doesn't matter if you control the readers. s6-envdir reads
envdirs, envfile reads key=value shell-like files. Choose whatever
format works best for you; if you need the variables to be read from a
shell as well, the envfile format will work best. It's a question of
convenience and preference, really. 


This is why I am asking all the (more experienced) people on this list. 
So that I make the best and most informed decision.


Since the only purpose is to synchronize interactive shells like 
bash/zsh/..., this is probably the deciding point:



if you need the variables to be read from a
shell as well, the envfile format will work best.



 That means WAYLAND_DISPLAY, by design, is only be accessible to
processes that descend from Hyprland. Why do you need to subvert it so
unrelated processes can access it? 
 Apologies, I did not explain that well. It basically goes hand in hand 
with what I have written here:



One might now argue that some processes need e.g. a running wayland
compositor, but this is the exact case "socket activation" solves. Let's
take for example the "foot" terminal
emulator(https://codeberg.org/dnkl/foot), which can be run as a server
to accept "foot

Re: s6/s6-rc policy for Gentoo

2024-07-06 Thread Laurent Bercot

Wouldn't anything this does be solved by just dropping privileges of the 
corresponding daemons in their startup scripts?


 No, because the point is to allow users to have their own services,
and you definitely don't want them to have access to the root
supervision tree. So you basically have to have a separate subtree
for each user (a privilege-dropped s6-svscan), and there are a few more
policy questions to answer, in particular how to make sure the users
cannot flood the root logs by misconfiguring their own logging system.
It's doable, but not quite obvious, and it's also not quite obvious
how to set up the system so that you don't spawn a supervision tree for
inactive users or users who don't use the feature. So there's a little
more work involved.



This seems like a worse and less flexible version of B to me, I guess the only 
reason it is even considered is because the seat daemon does all the tracking 
work for you. Option B does all this does and more if I understand you 
correctly, thus I think B is straight up the better way.


 It really depends on your objective. B makes a lot of sense if you
want to treat remote logins the same way as seated logins, but there is
also an argument to have remote logins be as simple as possible while
not minding deploying the red carpet and a whole lot of extra services
for seated logins, where the overhead of setting everything up will be
negligible compared to the desktop stuff anyway.



Does anyone see any other problem arising from B?


 B is entirely legit if you make it clear that's what users get. Just to
make sure users don't run xeyes when logging in remotely.
 And you probably want an extra supervision tree just for seated stuff
anyway, see below.



A) The format, do you suggest a FILENAME=content which seems easier to handle 
with execline and other software's(e.g. dbus) ability to write specific info to 
an fd which can be redirected to a file? Or do you think a file containing 
KEY=value, probably playing more nicely with bash and other interactive shells?


 The format doesn't matter if you control the readers. s6-envdir reads
envdirs, envfile reads key=value shell-like files. Choose whatever
format works best for you; if you need the variables to be read from a
shell as well, the envfile format will work best. It's a question of
convenience and preference, really.



B) I think I need to make an example to explain this issue properly:

I use Hyprland(https://hyprland.org/), which I start from an agetty instance. 
Hyprland, as any other wayland compositor/DE, sets env's. Most importantly 
WAYLAND_DISPLAY. It does not write those to a file. Thus I would require the 
user to add a script launch command to Hyprland's config which launches a 
script exporting the required(or all?) env's to a dir. This is unacceptable.


 That means WAYLAND_DISPLAY, by design, is only be accessible to
processes that descend from Hyprland. Why do you need to subvert it so
unrelated processes can access it?
 When Hyprland isn't running, there shouldn't be any living processes
relying on WAYLAND_DISPLAY. That suggests that you want a separate
supervision tree, launched under Hyprland, to host processes that only
make sense for a seated login - just like the C case above.

 I don't think that any hack to get the value of WAYLAND_DISPLAY and
store it for access by unrelated processes makes sense. Supervision
trees are cool, but they shouldn't be used to bypass normal process
hierarchies. Write down exactly what your services' lifetime should be
and design accordingly.



Thank you for the info, I have the greatest respect for you writing only UNIX 
compatible software(if that's how to correctly describe it?). I am looking 
forward to your alternative to PAM.


 Don't hold your breath - this is a longterm plan, and a considerable
amount of work.

--
 Laurent



Re: s6/s6-rc policy for Gentoo: The logging directory

2024-07-06 Thread Laurent Bercot




Concerning the system tree loggers, my first idea is to set an environment 
variable somewhere in the scripts s6-linux-init provides.

Is this even possible?

What would be the best place to do this?


 Any environment variable you want to make available for a whole
supervision tree should be added via a "-e var=value" option to your
s6-linux-init-maker invocation.

 For user supervision trees, I suppose you're not using s6-l-i-m, so
the best place would be to put the variables in an envdir and use
"-E $envdir" (and possibly "-e $var" if you need to substitute $USER
or something) in your s6-usertree-maker invocation.

 If you're not using these tools, the best way is to do the same thing
they do: put the variables in an envdir somewhere, and source the envdir
both before running s6-svscan and before running your s6-rc-init and
s6-rc script.

--
 Laurent



Re: s6/s6-rc policy for Gentoo

2024-07-05 Thread Paul Sopka

Thanks for your input!

As Mobin said, Turnstile from Chimera Linux answers this problem, and 
also manages the XDG_RUNTIME_DIR folder.
Since it actually has hooks to coordinate with the supervisor (unlike 
elogind, where the systemd-specific code for that in logind is just 
stubbed out), it makes XDG_RUNTIME_DIR safe to use. All that's needed 
is a s6-rc-aware backend. I'd write one, but haven't yet because I 
already have user services set up using Laurent's approach A (i.e. a 
user service tree that's always up regardless of login) and the fact 
that s6-rc uses a compiled database introduces some questions existing 
backends have no answer for (Should the the database be compiled upon 
login? Should the backend come with a wrapper around s6-rc-compile 
aware of turnstile's settings? etc.).


I am looking at Turnstile, it indeed appears to be the right tool for 
the job, until Bercot develops an alternative to PAM.


Since it actually has hooks to coordinate with the supervisor (unlike 
elogind, where the systemd-specific code for that in logind is just 
stubbed out), it makes XDG_RUNTIME_DIR safe to use.


I am planning to manage XDG_RUNTIME_DIR with s6-rc, since I am planning 
to have it hold the livedir. Even though Turnstile is looking like a 
safe option here, I want to delegate as few critical operation as 
possible to external tools, so I can easily replace e.g. Turnstile with 
a future, improved solution. I am not yet sure whether this is the best 
approach, but up until now it does seem like that. Any critique is welcome!


All that's needed is a s6-rc-aware backend. I'd write one, but haven't 
yet because I already have user services set up using Laurent's 
approach A (i.e. a user service tree that's always up regardless of login)


Regarding A), see my answer here: 
https://skarnet.org/lists/supervision/3116.html. Additionally, I'd like 
to mention that A) is the most efficient and simple solution on a single 
user system, but by no means an elegant one. Also it will will fail on a 
multi-user system, especially considering resource consumption.


I will soon test Turnstile and write a backend. If it works well, it 
will be in the repo and I am looking forward to improvements to it!



and the fact that s6-rc uses a compiled database introduces some 
questions existing backends have no answer for (Should the the 
database be compiled upon login? Should the backend come with a 
wrapper around s6-rc-compile aware of turnstile's settings? etc.).
I do not think that the backend should be involved in any compilation of 
the db. I see two ways the db/source dir changes:


A) The user adds a custom service / adds any service to autostart

In this case it is also up to the user (with an automation script 
turning it into one command) to compile and update the s6-rc-db.


B) The package manager installs software that includes a script.

In that case it is up to the package manager to invoke the script 
compile and update the s6-rc-db so the user can just start it using the 
usual commands.


A possible alternative would be a system service monitoring all source 
dirs and recompiling on change. This would exchange user control as well 
as resource usage for ease of use, which I generally do not like.



The approach I use on my machine is prepending the runscripts with 
`s6-envdir ../../../env` (assuming there's an env folder besides 
s6-rc's live dir), and touching/writing files there. I don't find this 
fundamentally inelegant; it follows the general "the filesystem is the 
database" principle, and avoids introducing an IPC endpoint in the 
supervisor.
I can't argue with your claim about elegance, I would consider it 
elegant. See https://skarnet.org/lists/supervision/3116.html for the 
issues I see with this.



Read http://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html if 
you're writing services for D-Bus stuff (like elogind/bluetoothd).


(Yes, s6-rc isn't well suited for dynamic events yet, so the second 
approach of replacing the activation program is ugly, but plenty of 
bug reports in the Artix Linux forum are related to this — I don't 
know why they haven't disabled it yet).
Thanks for the heads up, will definitely read! To be honest, I did not 
know dbus even had such capabilities and never even considered using 
dbus for such a thing. I rather consider dbus a necessary evil for 
desktop systems. As long as s6-rc does not have dynamic events I will 
simply not try to hack them in. Gentoo users will probably be fine with 
that, since most of them are probably using Open-RC which is way farther 
away from such functionality than s6-rc is.



Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo

2024-07-05 Thread Paul Sopka

Hey, thank you for your detailed answer!


 A. a permanent supervision tree, belonging to a normal user, that runs
services as the user, independent from whether the user is logged in. 
Wouldn't anything this does be solved by just dropping privileges of the 
corresponding daemons in their startup scripts? That would mean that it 
is just a needless complication. Anyway, this is the workaround I am 
using on my machine right now xD.




 B. A supervision tree that starts with the first login and ends with
the last logout. This appears to be what you're working on. 

Yes.



 C. A supervision tree that is tied to a graphical session on one seat.
That would exclude remote logins via ssh. This seems to be what the
Freedesktop people have in mind when they talk about XDG specifications. 
This seems like a worse and less flexible version of B to me, I guess 
the only reason it is even considered is because the seat daemon does 
all the tracking work for you. Option B does all this does and more if I 
understand you correctly, thus I think B is straight up the better way.


One might now argue that some processes need e.g. a running wayland 
compositor, but this is the exact case "socket activation" solves. Let's 
take for example the "foot" terminal 
emulator(https://codeberg.org/dnkl/foot), which can be run as a server 
to accept "footclient" terminal emulator instances, saving memory and 
startup time. The server can only be startet once a wayland compositor 
is up and running. Using "socket activation"(fd-holding) it can be 
configured to only be started once the first instance of "footclient" is 
invoked, which can only happen once the compositor is up thus solving 
this issue completely. This should be applicable to most if not all 
software with this limitation.


Does anyone see any other problem arising from B?



 You're not the only one working on s6-rc user services for Gentoo: see
https://skarnet.org/lists/supervision/3074.html :) You should definitely
try and coordinate with Alexis! And also with other people who hang
on the #s6 channel on oftc.net and may have more ideas to share. 

Thanks for the intel!



 Generally speaking, when I have a set of environment variables that
need to be shared between unrelated sets of processes, I put them in
an envdir, and source the envdir whenever the variables are needed.
One way or the other, the only reliable data sharing tool you have
across process trees is the filesystem. 

I thought about this, too. And I see two issues to solve:

A) The format, do you suggest a FILENAME=content which seems easier to 
handle with execline and other software's(e.g. dbus) ability to write 
specific info to an fd which can be redirected to a file? Or do you 
think a file containing KEY=value, probably playing more nicely with 
bash and other interactive shells?


B) I think I need to make an example to explain this issue properly:

I use Hyprland(https://hyprland.org/), which I start from an agetty 
instance. Hyprland, as any other wayland compositor/DE, sets env's. Most 
importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I 
would require the user to add a script launch command to Hyprland's 
config which launches a script exporting the required(or all?) env's to 
a dir. This is unacceptable.


Plan b) Poll the user env and extract on change and write it to the env 
dir, but how to extract the env? Polling is bad.


Plan c) use a notification by a seat manager(e.g. seatd) to run a script 
that extracts the env and writes it to the env dir, again, how to 
extract the env? This is also bad, since this will most likely end up 
being seatd specific, or at least bound to a set of supported seat managers.


Does anybody have a better idea?



 I'm not going to write such a program in the s6 suite, because all the
stuff around PAM and utmp is 1. very Linux-specific and 2. extremely
brittle and badly/underspecified. At some point, however, I intend to
take a good look at PAM and brainstorm about a replacement, because the
current situation is just holding with massive amounts of duct tape, good
will and headaches, and this makes me fearful for the future. 
Thank you for the info, I have the greatest respect for you writing only 
UNIX compatible software(if that's how to correctly describe it?). I am 
looking forward to your alternative to PAM.




 In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your
user supervision tree. It *looks* like the ideal place to do so, but
in case of a desktop session, it's deleted too early and you don't
have time to properly terminate your services. Other people who have
experience with running user services on a desktop will talk about this
better than me. 
I will open a separate thread on the XDG Base Directory Specification, 
since I consider this an important point. Generally I'd like to use 
XDG_RUNTIME_DIR but have it managed by the the s6-rc system service 
providing the user service tree. Thus it should be 

Re: s6/s6-rc policy for Gentoo

2024-07-05 Thread Paul Sopka
I think "turnstile" is a suitable option for this purpose. It's 
designed in three parts: a PAM module for detecting logins, a Daemon 
and some service supervisor loader scripts (backends). Currently it 
does support Dinit and Runit as backends but there should not be any 
problem around writing a backend for s6-rc. See 
https://github.com/chimera-linux/turnstile for project itself and more 
info. 
Thank you for your suggestion, this looks very promising. I will read 
into pam and write a local ebuild to install and test turnstile. This 
ebuild shall then be part of the overlay.


Anyhow, it seems this is the best solution until Bercot comes up with an 
alternative to PAM and utmp.



Paul



OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: s6/s6-rc policy for Gentoo

2024-07-05 Thread Laurent Bercot

1) A service monitoring logged in users, starting the user supervision tree on 
the first login of a user and stopping it once the user logs out from the last 
shell/display manager


 Ah, user services. They're a complicated matter, and their exact
definition varies depending on the distro. They're very much tied to
distro policies, which is why I haven't written support for them in s6,
apart from s6-usertree-maker that may or may not be useful to you.

 When you say "user services", it generally means one of these things:

 A. a permanent supervision tree, belonging to a normal user, that runs
services as the user, independent from whether the user is logged in.
 B. A supervision tree that starts with the first login and ends with
the last logout. This appears to be what you're working on.
 C. A supervision tree that is tied to a graphical session on one seat.
That would exclude remote logins via ssh. This seems to be what the
Freedesktop people have in mind when they talk about XDG specifications.

 You're not the only one working on s6-rc user services for Gentoo: see
https://skarnet.org/lists/supervision/3074.html :) You should definitely
try and coordinate with Alexis! And also with other people who hang
on the #s6 channel on oftc.net and may have more ideas to share.



2) An elegant way of synchronizing environment variables between the users 
supervision tree and its services and the users login shell/compositor/...


 Generally speaking, when I have a set of environment variables that
need to be shared between unrelated sets of processes, I put them in
an envdir, and source the envdir whenever the variables are needed.
One way or the other, the only reliable data sharing tool you have
across process trees is the filesystem.



Regarding 1) the best idea I currently is to have a daemon monitoring 
/var/run/utmp, starting an sub-process/s6-rc service for each user appearing 
there and stopping this sub-process/s6-rc service once the last login instance 
of the user vanished from that file. Since I have very little programming 
experience, I wanted to as you, Bercot, whether you consider this a good idea 
and if you do, whether this would be worth a s6 program. Can this be achieved 
in a better way?


 Since you're going with option B, indeed you'll need something to
detect logins, but relying on utmp is a risky business, and you don't
want to interface with PAM yourself. Having a third-party program
dedicated to that is probably the right approach; Mobin mentioned
turnstile, this looks like a promising option.

 I'm not going to write such a program in the s6 suite, because all the
stuff around PAM and utmp is 1. very Linux-specific and 2. extremely
brittle and badly/underspecified. At some point, however, I intend to
take a good look at PAM and brainstorm about a replacement, because the
current situation is just holding with massive amounts of duct tape, 
good

will and headaches, and this makes me fearful for the future.

 In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your
user supervision tree. It *looks* like the ideal place to do so, but
in case of a desktop session, it's deleted too early and you don't
have time to properly terminate your services. Other people who have
experience with running user services on a desktop will talk about this
better than me.

--
 Laurent



Re: s6/s6-rc policy for Gentoo

2024-07-05 Thread Mobin Aydinfar

On ۱۴۰۳/۴/۱۵ ۱۷:۳۹, Paul Sopka wrote:

Hey everybody

I am currently working on implementing boot scripts, system services, 
user services and general policy for Gentoo with s6/s6-rc.


I will soon (once I consider it acceptable) publish a github repo of my 
current state, so others can criticize, improve and suggest components. 
The plans is to, after some fleshing out, open another repo containing 
an overlay with a profile and some packages, so it can be easily 
installed for testing purposes. In the best case this shall once be 
merged into official Gentoo.





Hi!
That's really nice and I'm really excited about that repo :)


Currently I see two major things I still need to solve:

1) A service monitoring logged in users, starting the user supervision 
tree on the first login of a user and stopping it once the user logs out 
from the last shell/display manager



I think "turnstile" is a suitable option for this purpose. It's designed 
in three parts: a PAM module for detecting logins, a Daemon and some 
service supervisor loader scripts (backends). Currently it does support 
Dinit and Runit as backends but there should not be any problem around 
writing a backend for s6-rc. See 
https://github.com/chimera-linux/turnstile for project itself and more info.


Best Regards