Re: Configuration and scripts location

[Laurent Bercot]

Tweaking my services, I have wondered where to put their configuration.


 Choose a place for configuration directories that is entirely 
independent
from your s6/s6-rc installation, typically in /etc. Put your 
configuration

there and address it via absolute paths.

 For oneshots, it's the only solution, because there's no notion of
"local data" with oneshots.
 For longruns, you could also use data/ and env/ subdirectories, but I
generally recommend only putting a small amount of information in there,
preferrably volatile information (typically what you'd get from 
instancing

or programmatically creating service directories any other way). The
reasons for it are:
 - having all your config in /etc is clearer for most people - having to
look for the service directory to find config files is what put off a 
lot

of people with daemontools. If you can't scatter *everything*, and you
most probably can't, then it's better to gather everything than to have 
a

mixed bag of config locations.
 - with s6-rc, live service directories are duplicated from the storage
copy, and they're likely stored in a tmpfs - which means every file in
the service directory is copied to RAM. This is expensive, and not
necessary for config files.


The same question goes for helper scripts (for example, the "event 
handler" of udhcpc, responsible for applying the configuration). I'm 
torn between putting them in s6-rc/scripts/the-service-that-uses-them, 
a "scripts" subdirectory in their configuration, or something like 
{/lib,/usr/share}/the-service-that-uses-them. Moreover, considering 
that the service scripts are moved around, use of absolute paths is 
required.


 Anything that doesn't need to be in a service directory should be 
outside
of it; anything that isn't related to s6/s6-rc should avoid living in 
places

typically used by s6/s6-rc.
 My udhcpc event handlers live in /etc/udhcpc for instance.

 This is intentional: s6 and s6-rc enforce as little policy as possible,
and let you store your files wherever you want. This makes it easier for
an admin/distro to support several service managers.

--
 Laurent

Re: Configuration and scripts location

[Guillermo]

Hi,

2017-02-22 7:18 GMT-03:00 Guillaume Perréal:
>
> Tweaking my services, I have wondered where to put their configuration.
>
> For longruns, one could either put the in the data/ and env/ subdirectories,
> or in a /etc subdirectory. The former allows to easily have different
> instances of the same services but the files might be harder to locate, and
> requires to update the s6-rc database to change the configuration. The
> latter allows to use a well-known location and to update the configuration
> without updating the s6-rc database.

For longruns env/ and data/ work; the current working directory for
longruns is their s6 service directory (generated by s6-rc-compile),
so env/ and data/ can be referred to in 'run' and 'finish' scripts
using relative paths, a style that aligns with daemontools-like
supervision suites usage -s6 is the underlying mechanism after all-.
And doing it that way *does* allow dynamic changes without recompiling
the services database. What happens though is that if the 'boot time'
database (i.e. the one used in the s6-rc-init invocation) is not
recompiled, those changes don't survive a machine reboot. The usage of
env/ and data/ was touched upon in an a supervision ML thread:



Quoting Laurent: "I think env/ and data/ should be used for
configuration that is mostly static, i.e. that can wait until a
database recompilation to be applied. For configuration that needs to
be applied immediately, it is best if services store their config in a
directory that is fully independent from the service directory
location, and access it via absolute paths". But, to be honest, I
still like that one is able to make such in-place changes, and like
s6-rc-bundle for the same reason.

> For oneshots, as one cannot use neither env/nor database. There is no much
> solutions.

Yup, oneshots need independent directories referenced by absolute
path; the current working directory for their 'up' and 'down' scripts
is s6rc-onsehot-runner's service directory in s6-rc's current
implementation (i.e. with s6-sudoc + s6-sudod as the underlying
mechanism).

My personal preference for anything (s6-rc-specific) that needs to be
referenced by absolute path in 'run', 'finish', 'up' or 'down' would
be /etc/s6-rc/misc/$SERVICE_NAME, with $SERVICE_NAME matching the name
in s6-rc's service database (i.e. as shown by 's6-rc-db list all').
And /etc/s6-rc/misc/$SOMETHING_REPRESENTATIVE for things that do not
'belong' to a single service, but might be shared among many (like
general enough auxiliary scripts) -implying that
$SOMETHING_REPRESENTATIVE is then unavailable as a service name, of
course-.

> The same question goes for helper scripts (for example, the "event handler"
> of udhcpc, responsible for applying the configuration). I'm torn between
> putting them in s6-rc/scripts/the-service-that-uses-them, a "scripts"
> subdirectory in their configuration, or something like
> {/lib,/usr/share}/the-service-that-uses-them.

My choice of 'misc' in /etc/s6-rc/misc also means that I think placing
scripts there is OK too :), but if I had to choose an alternative, it
would be something under /lib with 's6-rc' in the name. On my machine
it would be something like /lib/skarnet/s6-rc/$SERVICE_NAME, because I
put anything 'libexec-like' under /lib/skarnet for both s6 and s6-rc
(and s6-linux-init-maker-like stage2, stage2_finish and stage3 scripts
would be in /lib/skarnet/s6-init). I wouldn't choose anything under
/usr, because on a machine with s6-rc as part of its init system I
consider anything that might be invoked by a service 'essential'
enough to be on the rootfs.

G.

Re: Configuration and scripts location

[Casper Ti. Vector]

If you differentiate between instances by using a naming convention like
`service.instance', you can let the `run'/`finish' scripts defer the
paths to instance-specific config files/directories.  In this way, you
can orthogonalise service configs from service definitions, and have
instanced supervision at the same time.

For example, I put configs for different openvpn instances in
`/etc/openvpn', like `/etc/openvpn/sth.conf' (main config file for the
`sth' instance) and `/etc/openvpn/sth/' (auxillary config files for
`sth', referenced in `/etc/openvpn/sth.conf' by absolute paths), and
write the `run' template as
> #!/bin/rc -e
> exec >[2=1]
> . /etc/s6-rc/bin/fn.rc
> exec emptyenv -p openvpn /etc/openvpn/$name.conf
(BTW, I found the `getty' template I posted in another thread to lack an
`emptyenv -p'; it is fixed on my machines now.)

Helper scripts are just a subset of configuration files, so the solution
above applies as well.

On Wed, Feb 22, 2017 at 11:18:10AM +0100, Guillaume Perréal wrote:
> For longruns, one could either put the in the data/ and env/ 
> subdirectories, or in a /etc subdirectory. The former allows to easily 
> have different instances of the same services but the files might be 
> harder to locate, and requires to update the s6-rc database to change 
> the configuration. The latter allows to use a well-known location and to 
> update the configuration without updating the s6-rc database.
> 
> The same question goes for helper scripts (for example, the "event 
> handler" of udhcpc, responsible for applying the configuration). I'm 
> torn between putting them in s6-rc/scripts/the-service-that-uses-them, a 
> "scripts" subdirectory in their configuration, or something like 
> {/lib,/usr/share}/the-service-that-uses-them. Moreover, considering that 
> the service scripts are moved around, use of absolute paths is required.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C