Managing go-sbot with systemd #75
Labels
No Label
bug
documentation
duplicate
enhancement
help wanted
invalid
maintenance
peach-lib
peach-network
peach-oled
peach-stats
peach-web
question
refactor
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: PeachCloud/peach-workspace#75
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Various notes and thoughts
go-sbot
will be managed by systemd, as defined by a unit file.stop
,start
,disable
,enable
andrestart
commands will be exposed via the web interface.We will need a way to invoke these commands without needing to supply a password. In the past (for PeachCloud), we have added
NOPASSWD
sudoers rules to allow particular users to run specificsudo
commands without needing to supply a password (peach-network
, for example, uses this approach).Another systemd-based approach is to define the service as a
user
service. In that case, nosudo
or password is required.There is also an alternative solution using PolicyKit / PolKit, whereby rules can be added which allow a particular user(s) to run the specified service(s) without
sudo
or password.These three options are clearly and comprehensively described in this StackExchange post by Thomas.
I'm currently just thinking about this in the context of initial releases of PeachPub. We could write simple guides for early testers to setup the appropriate rules and / or we could write bash scripts to handle everything (prompting the user for
sudo
password when required - since this is needed for adding sudoers rules or policy kit rules).Right now I lean towards picking one solution and writing a script to make the setup process as simple as possible. Users with strong opinions / particular tastes can then decide not to run the script and rather setup their
systemd
workflow themselves, or tweak the provided script as required.Hmm interesting questions, some thoughts:
In the context of peachcloud: we could add these setup steps to peach-config.
In the context of yunohost: it would be fairly easiy to add these setup commands (or script) for the systemd permission as part of the yunohost install script for peachpub.
Alternatively, I wonder in the context of peachpub (on yunohost or elsewhere), if peachpub is a deb, can we include the setup commands as part of the install for the debian package?
An idea that would be perhaps particularly nice in terms of portability, although a bit more work:
if we combined peach-web and peach-config into one binary (as described here #57, with peach-web essentially now being run as an additional subcommand of peach-config... e.g. peach-config run-peach-web),
then we could still distribute everything you need as one binary. one of the options of peach-config could be to run the go-sbot systemd setup steps only (peachpub setup version). But I guess if you start with a bash script to setup peachpub, could always do this and integrate it into peach-config later.
In the spirit of peachcloud, perhaps would be nice to prioritize the usecase for users who don't want to tweak anything and just want it to install easily. I would also lean to choosing one option you described, and leaving any further documentation for other methods somewhere in "Advanced Uses" section of documentation.
Thanks for your thoughts on deployment in some of the other contexts. I agree that combining
peach-config
andpeach-web
into a single binary will be great for portability (see issue #57). I'm choosing to sidestep that convo for now to focus on the minimal amount of work required to release PeachPub (with my minimal cognitive capacity lol).Assuming that PeachPub may be run on non-Debian-based distros, I'm going with the simplest solution (following your advice of choosing one option and pointing to others in "Advanced Uses"):
user
service.That allows an easy path to later create a
.deb
for PeachCloud.Here are the commands I used to get this working locally:
So far, so good. I can stop and start the service without requiring
sudo
privileges.The unit file can be fleshed-out once @cblgh has the new go-sbot config feature merged.