Hi all,
I'm leading the way in making runit an easy and practical choice on the
Devuan distribution. For DIY types like we on this list, the supervisor
portion of runit, as installed by the Debian runit package, already
works perfectly. My task is to make the whole thing compatible with a
packaging system. Even as we speak, I'm beginning to curate runit start
scripts for close to 100 daemons. Eventially this whole collection of
run scripts, finish scripts, log directories, and auxiliary files and
directories will be available in a single Devuan package, along with
simple programs to make daemon directory installation, within runit,
trivial.
For Devuan and Devuan alone, I'm putting both the directory containing
all available daemon directories and the directory containing symlinks
(/service in original djb daemontools) below /etc. I have asked twice
on the mailing list, and been given assertions twice, that nobody is
planning on using a read-only /etc, so for the purpose of Devuan I'll
make it below /etc, but I'll be sure to make it a variable. Please
let's not discuss the readonly /etc factor in this thread.
It's hugely important to me that all supervisors and inits be
installable and runnable without in any way clobbering each other. If
somebody plans to init with s6/s6-rc, and within it instantiate a
runit, which itself instantiates a daemontools, I want that to work
perfectly. Likewise, if someone wants several inits the way we all have
several kernels in case one starts to act funny, I want that possible.
So I've created the following terminology:
du: Daemons used. Refers to the symlink directory or its
subdirectories. /service in the original daemontools is an example
of a du directory. /etc/sv in both Void Linux and Debian and Devuan
is an example. In Devuan I'd make this directory /etc/du/runit.
There could later be an /etc/du/s6 or /etc/du/daemontools.
da: Daemons available. Refers to the directory housing the real-file
directories that are symlinked in the du directory. Material in the
da galaxie is site-modifiable to accommodate site specific needs.
In Devuan I'd make this directory /etc/da/runit. There could later
be an /etc/da/s6 or /etc/da/daemontools.
dp: Daemons packaged. Refers to a directory housing unmodified
material straight from the runit_daemons package. The dp directory
shall consist of a directory holding daemon directories for every
daemon in the collection. The daemon directories shall not contain
any supervise file, directory or symlink, nor any log files or
directories meant to hold log files, nor any other stateful
things. The intent of the dp directory is that its material is
modified ONLY by later packages, never on-site. It's therefore
entirely read-only. In Devuan I'd make this directory /etc/dp/runit.
There could later be an /etc/dp/s6 or /etc/dp/daemontools.
As far as I can tell, the preceding vocabulary and directory system
could enable all daemontools-inspired supervisor/init systems to be
installed on the hard disk, at the same time, without in any way
interfering with each other, always assuming their PD1 executables have
different names.
To me it's vitally important that people understand that the
daemontools-inspired supervisors are close cousins, each with its
subtle advantages and disadvantages, so I want to make sure that
nothing I do with runit in any way sabotages future installation or
use, even simultaneous supervision use, of its cousins.
The runit_collection package will come with the following:
* The dp directory populated with all distro-default daemon dirs
* Ability to create $da_dir, $du_dir, and $dp_dir on installation.
* The runit_tool tool.
runit_tool -i daemonname sees whether the dp version of the daemon dir
matches the da version, and if so, does nothing. If different or da
version is missing, it first backs up the existing dp version then
overwrites it. If the now backed-up dp version matches the da version,
the da version is assumed not to be custom, and the new dp version
overwrites the da version. If the backed-up dp and the da differ, it
assumes the da version is customized, and via backups and warnings,
walks the user through his/her choices.
runit_tool -e daemonname creates a symlink of the da in du. If nothing
to symlink to, issues a warning.
runit_tool -d packagename removes that symlink. If no symlink,
issues a warning.
runit_tool -u daemonname issues a warning and refuses to act if
there's currently a du->da symlink. If the da version of the daemon
doesn't match the dp version, issues a warning about it being
customized, and makes the user strenuously opt in to deleting the
daemon directory from da. Does not affect dp at all.
I specifically don't want to give runit_tool any more powers because I
want people to get used to the runit provided commands, and not depend
on some supertool that I write.
Given what I've written, does the $da_dir, $du_dir and $dp_dir
vocabulary sound reasonable?
I'd like to thank Joel Roth (copied) for first giving me the idea of
separated directories.
SteveT
Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
Received on Sat Oct 27 2018 - 19:11:57 UTC