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
Received on Wed Sep 18 2024 - 21:43:40 CEST