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