supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Paul Sopka <psopka@sopka.ch>
To: supervision@list.skarnet.org
Subject: s6/s6-rc policy for Gentoo: config files for service scripts
Date: Wed, 18 Sep 2024 21:43:40 +0200	[thread overview]
Message-ID: <442f0112-3120-4609-8a87-c4d9f7119868@sopka.ch> (raw)


[-- Attachment #1.1.1: Type: text/plain, Size: 3917 bytes --]

Hey everybody,

yes this project is still alive and making progress - but real life is 
taking its time toll.

I want to spark another discussion to collect some arguments and 
perspectives:

As of now I have had the following structure:

- The package manager puts service source directories for both user and 
system services to /usr/lib/s6-rc/{user,system}/src/service.

- The package manager puts initial bundles to 
/etc/s6-rc/{user,system}/src/bundles;
    those can be changed by the sysadmin to decide whatever is startet when.

- Custom services can be created at /etc/s6-rc/{user,system}/src.

- The package manager puts initial per-service config files to 
/etc/s6-rc/{user,system}/config,
    those can the be changed by the sysadmin to configure system 
services and set global defaults for user services.

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

That is the current state I have been running on my Desktop for ~2 Months.

After reading through Nosh (https://jdebp.uk/Softwares/nosh/), its ideas 
and its documentation,
as well as reading through some forums of both BSD and Linux, I have 
encountered an alternative idea,
which is, as far as I know, the old standard anyway:

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

- 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 configuring 
existing and custom user services.

- The idea of config files is completely dropped and the "editing the 
config" part is shifted to "editing the run-script"

Following are my current thoughts about this:

Advantages:

- Simplicity: I have realized that parsing and importing the KEY=value 
pairs from the config files makes up about 80% of each service script.
                    Removing config reduces the amount of files and 
directories enormously and makes the scripts very small, hence easy to 
understand and customize.

- Flexibility: A sysadmin has way more options in changing the script 
than in changing the KEY=value pairs.

Apparent disadvantages:

- "Beginner friendliness" is way higher for simple KEY=value config files
    Counter argument: From my experience, people that would be able to 
edit configs but not scripts, do not edit service files anyways,
                                   whilst those who do are profiting 
from the finer control the script editing offers.

Disadvantages:

- User services that first source a config file at 
/etc/s6-rc/user/config and after that another one at 
${HOME}/.config/s6-rc/config
   can have global defaults set by the sysadmin from the former, this is 
not possible with a non-config approach.

- Config allow to group and expose the most relevant options in self 
explaining variable names requiring less insight by the sysadmin.
   Counter argument: The sysadmin is most likely pretty invested in the 
program the service file he is editing belongs to anyway,
                                   hence he wants to deviate from the 
default.


What do you think is better and why?

Do you suggest any alterations or even a completely different approach?


Regards,

Paul


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

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

             reply	other threads:[~2024-09-18 19:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-18 19:43 Paul Sopka [this message]
2024-09-19  3:33 ` Jan Braun
2024-09-19 14:40   ` Paul Sopka
2024-09-19 17:51     ` Jan Braun
2024-09-19 18:28       ` Hoël Bézier
2024-09-19 19:11         ` Paul Sopka
2024-09-19 20:26           ` Jan Braun
2024-09-20 10:19             ` Paul Sopka
2024-09-20 11:10               ` Jan Braun
2024-09-19 19:07       ` Paul Sopka
2024-09-19 20:47         ` Re[2]: " Laurent Bercot
2024-09-20 10:21           ` Paul Sopka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=442f0112-3120-4609-8a87-c4d9f7119868@sopka.ch \
    --to=psopka@sopka.ch \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).