>just take this as a data sample for what can happen when a random noob tries to use s6.
Although unpleasant (not gonna lie), it was a very useful user
experience report, thank you. Among other things, it comforts me in the
belief that a user interface layer on top of s6 + s6-rc + s6-linux-init
is the way to go - a layer that makes things Just Work even when users
don't do everything perfectly, and with friendlier behaviour in case
of an error. People will still be able to look under the hood and
tweak things manually, but they won't have to, and they won't be
exposed to the nuts and bolts unless they want to.
Also, just in case someone tries the latest s6 / s6-rc git head:
I have added "uid/self" and "gid/self" key checking in the accessrules
library, for when the client runs with the same euid / the same egid
as the server; and I have changed s6-rc-compile to use the
functionality,
removing its -u and -g options in the process. So now, the behaviour
should always be consistent: the user who can operate a s6-rc database
is always the user who owns the supervision tree. No exceptions.
root can also use s6-rc commands, but services will still run as the
user who owns the supervision tree.
A numbered release of s6 and s6-rc (and lots of other packages) will
happen some time next month.
>BTW, your explanations of why things are designed the way they are were helpful for understanding the system. I recommend copying them into the docs.
I should write a "rationale / policy recommendation" section in the
documentation pages, that is a good idea.
--
Laurent
Received on Tue Feb 05 2019 - 19:44:09 UTC