Hello everyone!
I was working on alpine's /init
script and started contemplating if/how it would look like if it was a set of obarun services. I thought this would be a fun experiment so I wanted to share my ideas. Currently, alpine's init script is the bane of my existence as it's a single shell script that's very hard to extend, and I thought that 66 could offer the possibility to split up everything.
It seems systemd always uses service template files for the initramfs init, so it's not that far off.
Firstly, I think the correct way to do this would be to create a module file which contains all the needed files for each specific service. The services can easily be well isolated: busybox-init
, skeleton
, keymap
, networking
, storage
, etc..
Issues
Of course, the only interesting part is to think about the known issues that could be encountered.
1. Re-usable functions
Currently, afaik, I don't think there is a way to re-use many scripts in many obarun services, expect maybe putting all the needed scripts in a file and then manually loading that file in each service module that needs it. Examples of re-usable functions in alpine's init script are: ebegin
, eend
, rc_add
, ``, etc..
OpenRC has /lib/rc/sh/functions.sh
and /lib/rc/bin/*
which is automatically added to any module's path I think
2. Shared environment
I'm not sure if this is possible that module service files can have a shared, but dynamic environment. For example, it would be nice that not each script needs to parse the kernel cmdline each time, and that task can be delegated to one service, which can then maybe update the whole environment of the whole module service.
Also useful in scenarios like this: add openssh
to pkgs_to_install
when the cmdline option ssh_key
is detected.
That would be nice, atleast I think so.
3. Extensibility
Module services are currently too isolated, and this means that we can't easily do cool stuff like these (alpine's init script suffers the same too):
- add
unlOkr
or clevis
to ease unlocking of LUKS partitions. All these services would need to do is say provides=( luks-decrypt )
(or requiredby
in case they still want to use the normal method as fallback, assuming luks-decrypt
would skip already decrypted-devices.
- add boot speed measuring using stuff like
bootchart
- Show a custom bootsplash using
pbsplash
- etc...
4. Conditional starting of services
For instance, alpine's init script only tries to do networking if it detects the apkovl
or alpine_repo
is a http(s)://*
uri. I wonder if it would be possible for services to start other services inside the module conditionally.
What do you think? would this be a good approach? I also wonder if trees wouldn't be better in this scenario: Add a tree called initrd
, add some services to it, copy it to the initramfs and start that tree when the system boots up in the initramfs, instead of using an isolated module service.