-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add documentation for manual persistence #14
Comments
Hi There are numerous distributions based on Busybox, including some embedded distributions. So I can not really provide a detailed guide in the manual for each one. I will add some basic info on how to call the -run script from a custom init script. Generally I'm open to implementing support for init systems which need it. I will gladly review your PR. The code should be tied to OpenRC because then additional potential systems using OpenRC would benefit from it. Note that the code related to init system detection and persistence implementation (and subsequent checks) is somewhat convoluted and several scripts will require changes (out the top of my head: -install, -uninstall, -lib-common, -lib-status). So to save you the trouble, I could implement this feature by myself, but I'll need you to test the implementation. |
The init system detection is done by So the first thing to do in order to implement OpenRC detection is to see the output of these commands:
Ideally both commands should produce an OpenRC-specific string which can be used for detection. If not, some more tinkering may be needed. |
Also I've been planning for some time to implement native init-based persistence support for Systemd, so I could as well use this opportunity to add a generic framework for handling init scripts installation, checks and uninstallation. Just saying this before you started your implementation (in case you want to implement this feature by yourself) because there may be an upcoming change in related code structure. |
Thanks for the quick reply and tips! Alpine's I guess one option is to re-detect busybox init and see if busybox is actually openrc, eg: case "$initsys" in
busybox) if [ "$(grep -Ec "::sysinit::/sbin/openrc sysinit" /etc/inittab 2>/dev/null)" -gt 0 ]; then initsys="openrc"; fi ;; Your existing systemd detection works for me on Debian 12. I think the systemd-native way to implement this would be a few oneshot systemd units which run the required existing scripts at the right time. Restoring existing rules without update would be ordered |
An untested first attempt on this branch: https://github.com/superjamie/geoip-shell/tree/openrc-persistence I'll test tomorrow or over the weekend. TODO: make I tried to adhere to your existing style. Any feedback welcome. |
Thank you, I'll take a look at this hopefully later today. In the meantime, it would be helpful if you could post the output of these commands
These are run by |
Never mind, just tested with an iso of Alpine - both commands indicate busybox. |
So far I've come up with this method which detects OpenRC on both Alpine and Gentoo:
Your method with /etc/inittab could work as well, with a slight modification:
Probably your method is better because the rc-service binary could be present in the system regardless of the actual init used in it. |
Yes, that was my intention. OpenRC might be installed but not necessarily the init system. |
As the script says, Busybox crond doesn't support
@reboot
.It could be helpful to advise users how they can implement persistence themselves.
I presume the main place such an environment will be encountered is Alpine Linux, which has OpenRC and its
local
service to run arbitrary scripts at startup, so instructions could be like:/etc/local.d/90-geoip-shell-restore.start
with contents:chmod +x /etc/local.d/90-geoip-shell-restore.start
rc-update add local
I thought of implementing this in the script directly but I wasn't sure if you wanted to specifically detect OpenRC init and tie the script to that.
Maybe there are other environments where Busybox cron is used but OpenRC is not present. Such a feature would not be useful in those environments.
If you would like that feature, I'm happy to write it and send a PR for your review.
The text was updated successfully, but these errors were encountered: