[s6-svperms] Handling service permissions at creation time.
Hi there, The s6-svperms is a great feature but it only handle permissions control of a service at runtime. That means that we need to change the permissions of the service everytime that a reboot occurs. For a server, this is not really a big deal but for a desktop machine this can be really hard to handle as far as the runtime services can be different at each boot (user can activate or disactivate service for his purpose). Obviously, a script launched at some point of the boot (or after) can change the permissions on the necessary services. However, i think this is not easier and not flexible. I thought about a practical solution. S6-supervise create the control, status and event directory with the uid:gid of the owner of the process (correct me if i'm wrong). So, If we have a e.g /data/perms/rules/uid//allow file and if s6-supervise check this directory at the creation time and create the necessary file/directory with the respective uid/gid found at that directory, we can configure a service permissions permanently. What's your thought about that? -- eric vidal
Re: s6-supervise: use of nosetsid
On Thu, 03 Dec 2020 16:46:58 + "Laurent Bercot" wrote: > > Hello, > > The next version of s6 will be a major bump, with a few long-awaited > QoL changes - mainly a thorough cleanup of how s6-svscan handles > signals and the various commands sent by s6-svscanctl, but also some > goodies that you should like. :) > > One issue that has been often reported by users is that when they > try running s6-svscan in a terminal, and then ^C to kill it, the > services remain running. This is intentional, because supervision > suites are designed to isolate processes from anything accidental that > could bring them down, and in particular services should normally > survive supervisor death - but so far there has been many more > instances of people having trouble with that behaviour than instances > of s6-supervise accidentally dying. > > I have previously added the "nosetsid" feature to s6-supervise, to > address the issue: having a "nosetsid" file in a service directory > prevents the service from being started as a session leader, it starts > in the same session as the supervision tree (and, if the nosetsid file > is empty, in the same process group). So when people want to manually > test a supervision tree, they can have nosetsid files in their test > service directories, and ^C will send a SIGINT to all the processes > including the services, so everything will die, which is what they > want. > > There are two problems with the nosetsid approach: > > - Oftentimes, users are not aware of the existence of nosetsid, and > still experience the issue. It's almost an s6 FAQ at this point. > - The nosetsid functionality is inherently a risk: it puts the > whole supervision tree at the mercy of a misbehaved service that would > send a signal to its whole process group. There is a reason why > s6-supervise normally starts services in a different session, and > nosetsid bypasses that safety measure. > > So I am thinking of another approach to make s6 friendlier to users > who would - despite it not being recommended behaviour - test a > supervision tree in a terminal: have s6-supervise handle SIGINT and > make it kill its service before exiting. That would ensure that ^C > cleans up everything. > > This approach has the drawback of making services a little less > resilient, but s6-supervise getting a SIGINT should *only* happen in > the case of someone running a supervision tree in a terminal, which > is absolutely not something that should exist in production, so it's > probably not a big concern. However, it comes with a major advantage: > it removes the original reason for the addition of nosetsid. > So, with the change to ^C handling, I am considering removing the > dangerous nosetsid functionality entirely. > > Hence, my question to users: do you have a *valid* reason to use > nosetsid files in your service directories? Are there use cases for > nosetsid that I have not thought about, and that would make using s6 > impractical if the functionality were to be removed? > > Thanks in advance for your input. > > -- > Laurent > I never used the nosetsid file. Even for people who want to test a service with a fresh scandir from a terminal, i provide the necessary tools to properly start and stop the scandir without the need to hit the ^C key. So no valid reason from my part to use this files. Your commit https://github.com/skarnet/s6/commit/bdef68e12278ddfc5080732bd3b28dd5135c9d3a simplify a lot the s6-svscan interface which is a great thing. -- eric vidal
Re: Ready to pass or crash
On Wed, 21 Oct 2020 16:37:47 +1100 eric vidal wrote: > hi :) > > https://framagit.org/pkg/obextra/obnews/-/commit/20ce8822d15a38784d9ba3ca8bfcd7d80e431d71 > > > > -- > eric vidal I'm really sorry, this mail was not intended to be send here :/. Please skarnet, destroy it -- eric vidal
Ready to pass or crash
hi :) https://framagit.org/pkg/obextra/obnews/-/commit/20ce8822d15a38784d9ba3ca8bfcd7d80e431d71 -- eric vidal
Re: [request for review] Port of s6 documentation to mdoc(7)
On Sun, 30 Aug 2020 18:30:16 +1000 Alexis wrote: > > Hi all, > > i recently started using 66 instead of runit on Void - thanks to > @Obarun, @mobinmob and @teldra for their work and help! You're welcome. Thank at you to use 66. > Consequently, and further to > https://www.mail-archive.com/supervision@list.skarnet.org/msg02278.html > : > > > if people like man pages, they should have man pages, so it's > > been a > > few years that I have appealed to the community for this ... I > > want > > s6 to be accessible, but I figure that if people really wanted > > man > > pages, they'd write man pages > > i've spent the last couple of weeks porting the s6 documentation > to mdoc(7) format: > > https://github.com/flexibeast/s6-man-pages > > since i really want man pages, and much prefer them to HTML for > system-level software. :-) > > i don't consider the current state of the repo to be 'ready' in a > general sense, but i do feel it's mostly done, and certainly > amenable to review. i think this might be a good time to give > myself a short break from working on it, so i can then come back > and do a review pass with fresher eyes. > > The porting has been done manually, with no automation involved; > this has allowed me to use semantic markup as much as possible, > which of course also facilitates searching for content with > `apropos(1)`. > > Several things to note: > > * i've changed page layouts to fit mdoc(7) conventions. > > * During the porting process, i developed ideas about what might > be the best way to do things, so documentation ported earlier > might not follow the same style as the documentation ported more > recently. This is something i hope to check in my review pass. > > * There are currently no cross-references to the execline suite or > skalibs. However, i'm willing to port that documentation as > well, together with the s6-rc documentation. > > * Inline links to things such as djb's software are not yet > included. The `Lk` macro allows one to supply link text as well > as the URL, but the resulting output would require changes to > the text to make it read satisfactorily. Regardless, i can add > the relevant links in "SEE ALSO" sections. > > * i've corrected a number of typos and grammatical issues, and > discovered what i believe might be couple of errors: > > * s6-softlimit: The "Options" section refers to "-r allmem" > rather than "-r res". > > * s6-ftrig-listen: The "Options" section says: "By default, > s6-ftrig-listen1 waits indefinitely for a matching series of > events." Given the context, i presume this should be > "s6-ftrig-listen"? > > That said, although i've tried to be careful, i might have > introduced new errors, or made mistakes in my choice of macros, so > proofreading would be appreciated. :-) > > > Alexis. This is really a hard job to do. Many thanks to make it. A lot of user will appreciate it. Well, i'm not really good at English, so my help will not be usefull about grammatical issues. But i will do some publicizes about your work that be visible by user. -- eric vidal
Re: State of skarnet.org projects
On Mon, 3 Feb 2020 11:42:57 -0500 Steve Litt wrote: > On Mon, 3 Feb 2020 11:40:07 +0200 > fungal-net wrote: > > > Steve Litt: > > > On Sun, 2 Feb 2020 12:34:05 +0200 > > > fungal-net wrote: > > > > > >> Void is also > > >> very close, I for one use it with s6 and 66 for a while now and in > > >> many ways being more carefree than obarun having fast balls thrown > > >> by arch daily. > > > > > > Have you, or are you going to, write documentation on how to install > > > and maintain s6 (and presumably s6-rc) on Void? Are you using Void's > > > s6* packages, or do you compile the stuff yourself? If you install > > > Void's s6* packages, does that remove runit? I'd like to have both, > > > to a/b them against each other and to more quickly learn s6*. > > > > All s6 related packages are available on the repository (I believe all > > current). I think this work begun and was carried out by Duncaen (a > > void main member) and he didn't give up, he just realized I think that > > it would take fundamental void changes to incorporate it as an > > official alternative. > > Mobinmob stepped in and brought 66 and libs into void and is > > maintaining them (currently 1 version behind obarun). The official > > documentation for 66 is https://web.obarun.org/software as well as > > https://wiki.obarun.org/ and due to cross-distribution rules and > > requests Eric caved into the pressure and provides both html and man > > pages in the 66 pkg and tools. > > What is missing from void are the ready made service files that are > > available to copy/paste from https://framagit.org/pkg/observice > > and place them into /usr/share/66/service (instead of obarun's > > /usr/lib/66/service). The most important is the boot bundle enabled > > in the boot tree. > > https://web.obarun.org/software/66/frontend.html --> Prototype > > template of a service file. Use only the fields that pertain to your > > service > > If I read between the lines, it sounds like you're saying the > best way to learn s6 is to install and run Obarun. I have a spare > machine on which I could do that. > > Do you think the best and easiest way of learning s6 and the best way > to use s6 is to install Obarun? Surely not, a various wrapper for s6/s6-rc program exist e.g https://gitea.com/CasperVector/slew. Also, some good wiki about s6/s6-rc exist e.g. https://wiki.gentoo.org/wiki/S6. Furthermore, you can create your own wrapper to suit your exact needs. Actually, 66 works out of the box on many distros, debian spin included like Antix or Devuan. The main advantage of Obarun is that it provide all packages skalibs/execline/s6/s6-rc/.../66 without the needs to change anything to properly works. 66 works on mechanisms, not on policies and highly configurable at compile time. As being said, you can simply download an ISO(maybe the minimal one, no X session) from Obarun web site and test directly on the ISO the 66 tools. You can use docker too. A docker image is provide with 66 into it. > Thanks, > > SteveT > > Steve Litt > February 2020 featured book: Thriving in Tough Times > http://www.troubleshooters.com/thrive -- eric vidal
Re: State of skarnet.org projects
On Sun, 02 Feb 2020 15:58:12 + "Laurent Bercot" wrote: > >Do you mean they don't like editing files and creating symlinks? Do > >they want a GUI interface to the service directory tree and the symlink > >tree? > > No, it's about service startup with s6-rc. They don't want to dive into > the unpalatable blobs that are the set of systemd unit files or the set > of openrc init scripts (and I can undertand their reluctance); and > they don't want to make the effort of understanding the s6-rc syntax and > creating s6-rc source directories (and that's something I'm sure you can > relate with ;)). They want a service startup configuration format that's > close to what they are used to, typically text files that are easy for > a human to read. Already done. A set of service portable and hackable easily is already operationnal. One file to deal with all services format for s6 and s6-rc which can be written with every language that they prefer. > Ideally, they'd want systemd unit files. Which is not gonna happen, > because the format of these files maps the systemd architecture too > closely and there are lots of things that would be expressed differently > under a s6-linux-init/s6/s6-rc system; but a text-based configuration > engine is totally doable, it's just a long project. Done. INI format what's not invented by systemd. This format is easy to understand, easy to write/read. > They also want high-level commands like "service" or "openrc" to control > the machine state without having to undertand the nitty-gritty of > "s6-rc change", or the difference between "s6-rc -d change foo" and > "s6-svc -d /run/service/foo". Which makes sense: can *you* tell me what > this difference is? :) Done, a set of command wrapper with consistent options between command with deal with pure s6 services and s6-rc compiled database are already operationnal > All of this will be solved by s6-frontend, but that's not something I > can work on in the evenings. > > > >What is UX? > > User experience. > -- > Laurent > They can make test easily to see if s6 suit their needs even if your s6-frontend is used in the future. And maybe after a few POC they can realize the advantage of s6 and finance you correctly to allow you of make rapid progress on the s6 development and s6-frontend -- eric vidal
Re: The "Unix Philosophy 2020" document
On Sat, 28 Dec 2019 16:04:53 +0200 Alex Suykov wrote: > Sat, Dec 28, 2019 at 01:57:25PM +1100, eric vidal wrote: > > > Well, for me, cgroups is clearly a lack to s6. Using it for every > > process like systemd do have no sense, but in some case it can be > > useful to protect e.g an "over-eat" allocation memory by a program > > (in particular over a server). > > Minor note on this. Resource limiting with cgroups does not require > any explicit support from s6, or any external tools for that matter. > Literally just `echo $$ > $cg/cgroup.procs` in the startup script > is enough, assuming the group has been created (mkdir) and the limits > have been set (bunch of echo's). You're right, i will see what i can do to uniform the preparation/creation of the cgroups for a process. -- eric vidal
Re: The "Unix Philosophy 2020" document
> I definitly have to correct you: cgroups are *NOT* designed to catch > wild forking processes. This is just a side-effect ot them. I'm totally agreed. Systemd use it in the wrong way. It should not be used to track processes. > The purpose is to control resource limits, like CPU, RAM, Disk I/O and > so on. So for linux it would definitly make sense to have an interface > to the full feature set. agreed again -- eric vidal
Re: The "Unix Philosophy 2020" document
> https://github.com/arsv/minibase/blob/master/src/misc/runcg.c > > It's really simple. > > I don't think a tool like this has any actual uses, other than in > arguments with systemd fans, but I guess that alone could justify > its existance. Thanks for this link this is really interesting. Well, for me, cgroups is clearly a lack to s6. Using it for every process like systemd do have no sense, but in some case it can be useful to protect e.g an "over-eat" allocation memory by a program (in particular over a server). As cgroups is a linux specific feature, s6-supervise should not take care about it even if the code is modified at compile time. This will increase the code of s6-supervise only for an "optional" features. But laurent you do what you need to do. I would prefer an extra layer of supervision and independent from s6 uniquely used when it necessary. I think about it from a while for 66. Adding a section like [cgroups] containing all @key field needed to configure the future cgroups environment is not a big deal and allow user to quickly define what it need. In such case the "extra supervision layer" is added to the run scripts which execs the e.g runcg program. But maybe i'm totally wrong with my thought... -- eric vidal
66 tools
Hi there, I'm really happy to announce you the new fresh release (v0.1.0.0) of the 66-suite tools. This suite of tools written in C aims to offer a easy way to integrate init system and provide interface around the s6 and s6-rc software. These tools can used on any linux system (BSD was not tested yet).Some tools are wrapper around the s6/s6-rc software, some other are original one. You can find the code source of the 66 tools here : https://framagit.org/Obarun/66. It was designed to simplify and to unify services configuration files for a sysadmin and provide an easy way to user to manipulate and deal with services. These tools comes with a concept of tree (see http://web.obarun.org/software/66-tree.html). A tree is a set of any kind of services (pure s6 service or s6-rc service). The main advantage is the ability to separate a set of service (e.g. boot time service and running time service) from another which can be started/stopped in one command line or enabled/disabled at boot time procedure. A frontend service file (http://web.obarun.org/software/frontend.html) is also provided with a format of INI with a specific syntax on the key field. This frontend allow to declare any kind of service and it really easy to write and understand. You can find a prototype of the frontend here https://web.obarun.org/software/frontend.html#proto. The main features are of the 66 tools are: - Frontend service file. - Creation and manipulation of a scandir with one command line (see 66-scandir tool). - Instance service file. - Multiple service file declaration (packager,sysadmin,user directories) with precedence. - Easy change and handles environment configuration file for a service (e.g /etc/66/conf). - Automatic creation and highly configurable logger for a service. - Supports of nested supervision tree. Any valid user on the system can create a scandir and deal with it own services. - Automatic resolution of service dependencies chain for any command procedure e.g start/stop/enable/disable. - Unsupervision of a complete set of service with one command line (see 66-tree tool). - Quick view of the entire service system (see 66-info tool) - Easy view of dependencies for a specific service (see 66-info tool). Can be reversed too. - ... These tools can be configured at the compilation time to suits your needs (see https://framagit.org/Obarun/66/blob/master/configure file). A complete set of service to properly boot a machine can be found here https://framagit.org/obarun-pkgbuild/boot-66serv and works out of the box. This set of service is easily hackable and can be adapted on any linux system. This set of service provide e.g a 66.conf file which allow user to easily configure their system at boot time. (https://framagit.org/obarun-pkgbuild/boot-66serv/blob/master/66.conf).Also, it separate the boot procedure from the running time procedure, a secure way to avoid destroying a boot procedure. These tools are officially used on the Obarun system (web.obarun.org), an Arch linux based system totally free of systemd. Obarun use s6/s6-rc ecosystem from two years now. If you want to test the 66 tools, you can find two kind of ISO containing these tools here : - minimal (no X server): https://repo.obarun.org/iso/2019-04/Obarun_x86_64-2019-04.iso - desktop builded around JWM: https://repo.obarun.org/iso/2019-04-JWM/Obarun-JWM_x86_64-2019-04.iso - download page: https://web.obarun.org/index.php?id=74 Hope you will find these programs usefull. If you have any questions you can contact me by email at e...@obarun.org -- eric vidal
