With yesterday's mention of the idea of a clearinghouse, the concept that
daemon options need to be versioned has been in the back of my head. Here
is an idea: versioned definitions. A crude example:
/etc/sv/sshd/envdir/DAEMON -> /etc/sv/sshd/envdir/current/DAEMON
/etc/sv/sshd/envdir/DAEMONOPTS -> /etc/sv/sshd/envdir/current/DAEMONOPTS
/etc/sv/sshd/envdir/current-> /etc/sv/sshd/versions/v3
/etc/sv/sshd/envdir/versions/v3/DAEMON
/etc/sv/sshd/envdir/versions/v3/DAEMONOPTS
/etc/sv/sshd/envdir/versions/v2/DAEMON
/etc/sv/sshd/envdir/versions/v2/DAEMONOPTS
So this was the seed of an idea that borrowed heavily from elsewhere.
The problem:
As software daemons mature, they acquire new options and change their
behavior. Because a service definition is tied to launching a version
of a daemon, that means on any upgrade, the definition has the
possibility of breakage due to those changes.
The concept:
Settings for daemons should be versioned so that, for a given release of
a daemon, the "correct" options and settings will be used.
The proposal:
I've left the original rough idea at the top of the message for
comparison only. It is not the proposal.
The idea would be that, for a given definition, a ./version directory
would exist that would house the version-specific information. A soft
link that normally represents the settings to be used would then point
to the correct version. A sample layout appears below.
/etc/svcdef/sshd/env -> ../version/3.81
/etc/svcdef/sshd/version/3.81/
/etc/svcdef/sshd/version/3.81/DAEMON
/etc/svcdef/sshd/version/3.81/DAEMONOPTS
/etc/svcdef/sshd/version/3.81/PRELAUCH
/etc/svcdef/sshd/version/3.8/
/etc/svcdef/sshd/version/3.8/DAEMON
/etc/svcdef/sshd/version/3.8/DAEMONOPTS
/etc/svcdef/sshd/version/3.8/PRELAUNCH
While the definition names are specific to supervision-scripts, the
layout is not, and could conceivably hold other files and data in them;
for instance, Toki's supervision framework could store shell script
settings there instead of envdir files, and the soft link would point to
the specific script. In this manner, we can define where and what is
stored without caring about the how.
Advantages:
* Solves the version-breakage problem.
* The format is data-content-agnostic, it only requires that storage be
in a file.
* The format can be universally supported with all existing supervision
frameworks without a naming conflict.
* The format can be installed into legacy supervision arrangements
without breaking the environment.
* The format is entirely optional. The proposal is to recognize this as
a common practice.
* Allows the administrator the possibility of creating custom settings
instead of using default or system-supplied settings.
* Allows the administrator the possibility of rolling back to a prior
version without a loss of settings.
Potential issues:
* It requires a filesystem that supports soft links.
* Storage requirements will grow with the number of versioned definitions.
* There is no guarantee that the data format will be consistent.
* For slower systems, some additional disk activity will be required.
For most modern systems this isn't an issue, but for legacy systems it
may have a slight impact.
* There may be some suite of programs that will conflict with this
arrangement.
