shpool should support system-wide config #30
Assignees
Labels
enhancement
New feature or request
Comments
|
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 |
|
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? |
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 I made #56 to track work on autodaemonization in order to make life easier for people who don't use systemd. |
Aetf
added a commit
that referenced
this issue
Jun 19, 2024
- Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Aetf
added a commit
that referenced
this issue
Jun 24, 2024
- Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Aetf
added a commit
that referenced
this issue
Jun 24, 2024
- Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Aetf
added a commit
that referenced
this issue
Jun 24, 2024
- Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Aetf
added a commit
that referenced
this issue
Jun 25, 2024
- Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Aetf
added a commit
that referenced
this issue
Jun 25, 2024
- Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Aetf
added a commit
that referenced
this issue
Jun 25, 2024
* Gracefully handle missing XDG_RUNTIME_DIR env var in tests * Configuration loading overhaul - Simple merging logic for `Config` - Load config from system-wide locations (fixes #30) - Dynamically pick up changes from newly created config files (fixes #29) - Use `directories-rs` to find user level config directory path A new `ConfigWatcher` is introduced, which opportunistically watches the closest existing parent of target paths and rewatches dynamically accordingly. This way we can get notifications for new file creations in addition to modifications. `ConfigWatcher` also does debounce (100ms by default) to only trigger one config reload for multiple events in a short time period. The core idea of the watcher is as follow: Given a watching target path `/base/sub/config.toml`, a) readd watches if any segment in the path is created/removed; b) reload config only if the event is about the full target path. The actual implementation extends this idea to handle multiple targets. Please refer to `config_watcher.rs` for details and extensive test cases. A few design points: - Notify event handling is done in a separate thread, rather than in notify's internal event handler thread, because the code is more readable and calling unwatch/watch in that thread may lead to deadlock in some cases. (notify-rs/notify#410, notify-rs/notify#463) - For simplicity, `ConfigWatcher` doesn't provide infomation about which exact config file was changed, assuming a reload would need to read all config files anyway.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.tomlwould 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
dumpby default, but organizations which make importaint announcements via the motd may wish to set a different setting.The text was updated successfully, but these errors were encountered: