I'm honestly struggling to think of a practical use case for this,
though I may be lacking sufficient context.
The case of a daemon breaking semantics of existing options is quite
seldom seen, and just a bad practice for reasons of maintaining least
surprise and compatibility. Even when major versions are bumped, it's
rare to see such a thing.
Now when new options are added, old configurations still tend to run the
same (unless it's a scenario of this flag now needs that flag set in
unison, which again is a breaking change).
By all means just version and update the runscript. Symlink farms are
always frustrating to deal with. It didn't work well for sysvinit at all.
On 06/25/2015 02:40 PM, Avery Payne wrote:
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.
