bit-babbler (0.8) unstable; urgency=medium
* Support hotplugging devices into libvirt guest domains which have names
containing characters that are not valid as part of a shell variable name.
Another reminder that the important part of keeping things as simple as
possible is always the "as possible" bit.
* Support reading seedd(1) options from a configuration file. The original
design plan explicitly avoided this, partly just to keep the code as
simple and easy to audit as possible, and partly because it was desirable
to make invocation as simple and foolproof as possible. The more options
that something has, the easier it is to make some mistake with running it
which could have subtle and even serious consequences. But we are at the
point now where there are enough real alternative options which are either
genuinely desirable or needed for some use case, that the balance becomes
weighted toward being able to keep persistent configuration settings in a
file rather than having to spell them out on the command line each time.
The final straw for making this change now was the inability of systemd to
sanely support the existing simplified configuration interface that was
provided in /etc/default/seedd for the SysV init script. When given the
alternative choices available to us of either adding a shell wrapper to
do what systemd could not, or forcing people to manually edit or override
the systemd unit directly to make any configuration change, this was
clearly the Lesser Evil to embrace if we were going to provide a native
systemd unit for the system daemon. The former gains us nothing over the
existing LSB init script, and the latter would require every user to first
have a solid grasp of all the non-obvious consequences which can come into
play when configuring a system which (according to systemd.directives(7))
"contains 2464 entries in 13 sections, referring to 241 individual manual
pages" - and where even package maintainers and systemd upstream still
make mistakes that can take a long time for the real consequences to be
noticed. So if we were to provide a systemd unit, it needs to be well
tested and give people few, if any, reasons to ever need to modify it.
* Preserve existing configuration on package upgrades. The new default
configuration file behaves the same way as the old defaults did. If the
settings in /etc/default/seedd have been customised, then on upgrade we
generate a custom /etc/bit-babbler/seedd.conf implementing the same set
of options. The old customised file content will be retained, and can
be found in /etc/default/seedd.dpkg-old, in case there was anything else
in it which people might also want to keep, but after checking for that
it can safely be removed by the system admin. Nothing from this package
uses files in /etc/default from this version onward.
* Two systemd unit files are now included in this package, but only one is
enabled by default.
The seedd.service unit provides the same functionality as the SysV init
script does, and will be used instead of it on systems where systemd is
running as the init process. It will start the seedd(1) daemon as soon
as possible during boot, reading its options from the new configuration
file, and if feeding entropy to the kernel it will begin doing so as soon
as the available USB devices are announced to the system by udev.
The seedd-wait.service oneshot unit is not enabled by default. It provides
a simple sequence point which may be used to ensure that QA checked seed
entropy from available BitBabbler devices can be mixed into the kernel's
pool before other ordinary services which might rely upon it are started.
This is its default behaviour if it is simply enabled, and ordinarily it
will not delay the boot for very long, only until udev announces a device
that we can read some good seed bits from. By default this will time out
after 30 seconds if good entropy cannot be obtained, which should be more
than enough time to get a good seed if that was going to be possible, but
won't completely cripple the system when it is acceptable for it to still
be running without having a working BitBabbler attached.
Additionally, the seedd-wait.service can also be used to place a harder
constraint on individual services, if there are particular things which
the local admin does not want started at all if good seed entropy was not
obtained. Or it can be configured to divert the boot to a degraded mode
(such as the single-user mode emergency.target) if the availability of
good entropy from a BitBabbler should be a hard requirement for the whole
system. For more details of its use see the BOOT SEQUENCING section of
the seedd(1) manual page.
-- Ron Lee <email address hidden> Thu, 08 Feb 2018 10:26:52 +1030
