shpool should support system-wide config
ethanpailes opened this issue · comments
Currently, we only support config in a user's home directory (~/.config/shpool/config.toml). We should also support a system wide location so that settings can be applied globally on a machine or by an orginization. I think /etc/shpool/config.toml would be a good path for system wide settings.
Any user-level settings should override system-wide settings. To do this we will need to write some merge logic for the config struct.
I see this being the most applicable when it comes to the motd settings. Individual users probably want them off or on dump by default, but organizations which make importaint announcements via the motd may wish to set a different setting.
Let me take this one.
IMHO the config paths etc could come from xdg using crates like https://github.com/dirs-dev/directories-rs, and we can use something like https://docs.rs/figment/latest/figment/ or https://github.com/mehcode/config-rs to handle layered configs.
directories-rs does seem pretty useful, but the configuration frameworks seem a bit heavy to me (and I'm worried about compability if we switch to one of them). If we just program directly, there will be a single config merge routine, and each new top level field in the config will require probably a single field: higher.field.or_else(lower.field) line wich is not much maintenance burden. Since we need to vendor deps internally, I'm not sure avoiding that is worth the import toil.
That makes sense. Let me just code the merge directly.
And hope it would work as a system service
@qaqland do you mean you want it to run as a non-user systemd service?
@qaqland do you mean you want it to run as a non-user systemd service?
yes, i use openrc
@qaqland that seems like a different feature request. Currently, shpool can't run as a system wide service because it assumes itself to be running as the user. In order to run as a system service, we would need a mode for the daemon to be running as root and know how to drop privileges. This seems like a major vector for security issues that I would rather avoid thinking about, so for the moment you'll need to run the daemon as your own user via a helper script of some kind. For your particular case, it looks like the command_user OpenRC option will let you write a service that launches the daemon as your normal user.
I made #56 to track work on autodaemonization in order to make life easier for people who don't use systemd.