April has shown some steady progress, but it is slowing due to personal
commitments, namely a 2nd part-time job I've taken.Life is rather hectic
right now, but I am trying to keep an eye on the mailing list and my email.
The number of target definitions has been reduced. Several non-service
definitions were found in the list that is used, and removed. This
brings the target number down to ~1,100, so technically I am approaching
the 0.1 release candidate. With luck, this will be announced next month.
PHK (a FreeBSD dev) is working on a replacment for the venerable ntpd
daemon. The initial work has appeared as ntimed-client. I was able to
build, run, and confirm it as working, despite that it is not production
ready. A definition is now available.
Lastly, there is a change in strategy. In past months, I have taken the
time to ensure that each service definition is tested as best I can, but
the shear number of them makes this time prohibitive. The existing
run.sh script has proven itself reliable and I think I can safely reduce
the amount of testing to random samples and key services. So there will
be an increase in the number of definitions made that have the
"untested" marker, but the velocity of new definitions will start to
increase. Yes, this is why there are suddenly several untested
definitions in alphabetical sequence this month. :)
Done:
- - - -
+ Added new definitions: pidentd, xtelld, NetworkManager, ntimed-client,
bcron-update, bcron-sched, bcron-spool
+ Added new untested definitions: gdm, avahi-dnsconfd, aiccu, ajaxterm,
all-knowing-dns, amavisd-new, amule-daemon, anacron, anon-proxy (aka
mix), autolog, arpalert.
+ Fixes: added a missing ./needs to console-kit-daemon.
+ Revised README, SETUP and FEATURE documents.
Contributions:
- - - - - - - -
+ Fixed a bug in the definition for bind, based on a report from
[email protected].
The following were implemented suggestions passed by [email protected]:
+ run-user-service.sh: Revamped to spawn fewer subshells.
+ run-user-service.sh: Fixed a bug that would cause the runit variant to
crash.
+ run.sh: Removed two calls to pwd, instead using the shell's
environment variable.
+ run.sh: Removed two spawned subshells, replaced with programs
Both contributors are greatly appreciated.
In Progress:
- - - - - - -
+ Held in the patch queue needing work: arpon, krb5kdc,
krb5-admin-server, dropbear, cpufreqd, rpc.nfsd, rpc.svcgssd, rpc.gssd,
rpc.idmapd, rpc.mountd
+ Conversion of bind to envdir format
+ Additional patches from [email protected] that could not be cleanly
integrated. The largest one would remove sed and awk, and use cut,
reducing the number of external dependencies.
To Do:
- - - -
+ Finish perp support. Because of how sv/.run/run works, this can
easily be done by creating a new run-perp.sh script that supports perp's
requirements. This will also involve a use-perp support script.
+ I need to think through a kernel-neutral method of handling driver
loading. There are a handful of services that require this to
succesfully launch. For example, cpufreqd requires kernel modules to
load first, but this is linux-specific. Does FreeBSD have any
requirements like this? Or are these services so tied to the kernel
platform that it doesn't really matter? (i.e. cpufreqd won't run on
FreeBSD so there is no concern about incompatible module loading)
+ Re-think instance support. Attempting to encode a sane default isn't
possible because the naming conventions aren't consistent, so the
systems administrator needs to intervene. For example, there are a
number of services that want to listen to "a specific network adaptor".
Compounding this problem is that the device names of network adaptors
not only changes between kernels (think FreeBSD device names vs. Linux
device names), but also in the same kernel as well (due to systemd's new
"network device names").
+ I need to wrestle with the new crop of init-startup-oriented projects,
as well as existing ones. I've read over some of anopa and even
runit-for-lfs, but I haven't had time to really digest all of the
designs, and the init for s6 hasn't even been released - yet. While
supervision-scripts is not meant to provide startup/shutdown support, it
is meant to wedge into these environments and work within them, so
having a passing knowledge of them is essential. I've also wanted to
interject a few thoughts and notes on "towards a universal
startup/shutdown".
+ Everything else from last month.
