On 05/23/19 13:28, Phil Hofer wrote:
Hi all,
I was looking at porting the init scripts for
some common daemons that I run (openssh, etc.)
to s6, and I immediately ran into the obvious
issue that many of these services have non-trivial
ordering dependencies ('net' and 'dns' targets, etc.)
The simplest transitional configuration would be
to have OpenRC still manage service/networking
dependencies as it does today, and just replace
the 'start-stop-daemon' invocations in the scripts
with the appropriate s6 equivalent. But ultimately
I'm interested in seeing if I can get everything on
my system running under s6-rc. (I don't know yet how
interesting this is to upstream Adelie, but I'm happy
to contribute whatever is interesting.)
We would be over the moon to merge in any progress towards making s6 a
first-class, whole system service manager.
Consequently, I'm looking at writing some tooling
to generate s6-rc service definition directories
and bundles for the 'net' prerequisite. In practice
I think this looks like a tool to read the system
networking configuration from a file and generating
execline scripts that do the appropriate iproute2 voodoo,
launch a supervised dhcpcd, etc.
The ideal would be to re-use the netifrc configuration file, so that you
could switch out systems 'on the fly', only requiring a single restart
and very little in the way of sysadmin work. Of course, that's probably
also very hard and not very interesting.
Instead, you *could* make up a system that works better, and then have a
script that could "convert" a netifrc configuration file to the new
system's style.
(I haven't thought too seriously about wireless/hotplug
yet, since I'd likely have to open the udev can of worms.)
Ultimately this would serve the same purpose as netifrc
or NetworkManager, albeit with somewhat narrower scope.
One obvious upside here is that s6 supports (a subset of)
socket activation, so this would open the door to cool
stuff like services that can wait for dhcp/slaac address
assignment, route configuration, etc.
That would indeed be great! Don't forget Laurent's bcnm library, which
makes wpa_supplicant a bit easier to swallow. Perhaps you could manage
to find some way to get basic WLAN working via that.
In fact, for a first release you could probably just have wpa_supplicant
+ bcnm as *the* wireless support. Then you don't have to care about
udev etc; wpa_supplicant is already taking care of that for you.
If anyone is aware of a similar effort already in
progress, let me know.
I'll probably start looking at this seriously towards
the end of next week, but I'm interested to gather some
initial feedback on the concept before I head down that path.
The concept is sound, and more than a bit exciting. :)
Thank you very much for taking the time to discuss it with us and we
look forward to helping out in any way we can.
Warm regards,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org