Managing go-sbot with systemd #75

New Issue

2022-01-19T09:10:50Z

glyph commented

2022-01-19 09:10:50 +00:00

Various notes and thoughts

go-sbot will be managed by systemd, as defined by a unit file.

stop, start, disable, enable and restart 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 specific sudo 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, no sudo 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.

**Various notes and thoughts** `go-sbot` will be managed by systemd, as defined by a unit file. `stop`, `start`, `disable`, `enable` and `restart` 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 specific `sudo` 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, no `sudo` 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](https://unix.stackexchange.com/questions/496982/restarting-systemd-service-only-as-a-specific-user). ----- 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.

glyph added the peach-web label 2022-01-19 09:11:01 +00:00

notplants commented

2022-01-20 20:17:38 +00:00

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.

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 https://git.coopcloud.tech/PeachCloud/peach-workspace/issues/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.

👍 1

glyph commented

2022-01-24 09:38:17 +00:00

Thanks for your thoughts on deployment in some of the other contexts. I agree that combining peach-config and peach-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"):

Write a bash script to setup go-sbot as a systemd 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:

# enable lingering for the given <user> (`glyph` in this example)
# this is needed to startup the user service on boot
sudo loginctl enable-linger glyph

# create the systemd user directory if it doesn't already exist
mkdir -p ~/.config/systemd/user

# write the go-sbot unit file
cat > ~/.config/systemd/user/go-sbot.service << UNIT
[Unit]
Description=go-sbot startup script

[Service]
ExecStart=/usr/bin/go-sbot
Environment="LIBRARIAN_WRITEALL=0"

[Install]
WantedBy=default.target
UNIT

# reload the configuration and enable the service
systemctl --user daemon-reload
systemctl --user enable go-sbot.service
systemctl --user start go-sbot.service

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.

Thanks for your thoughts on deployment in some of the other contexts. I agree that combining `peach-config` and `peach-web` into a single binary will be great for portability (see [issue #57](https://git.coopcloud.tech/PeachCloud/peach-workspace/issues/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"): - Write a bash script to setup go-sbot as a systemd `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: ```bash # enable lingering for the given <user> (`glyph` in this example) # this is needed to startup the user service on boot sudo loginctl enable-linger glyph # create the systemd user directory if it doesn't already exist mkdir -p ~/.config/systemd/user # write the go-sbot unit file cat > ~/.config/systemd/user/go-sbot.service << UNIT [Unit] Description=go-sbot startup script [Service] ExecStart=/usr/bin/go-sbot Environment="LIBRARIAN_WRITEALL=0" [Install] WantedBy=default.target UNIT # reload the configuration and enable the service systemctl --user daemon-reload systemctl --user enable go-sbot.service systemctl --user start go-sbot.service ``` 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.

👍 1

glyph closed this issue

2022-03-25 12:49:56 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: PeachCloud/peach-workspace#75