Open gilesknap opened 4 years ago
docent-net
commented
4 years ago I see, that you fixed already WantedBy=default.target. Did you systemctl --user disable service && systemctl --user daemon-reload && systemctl --user enable service afterwards?
Ligering should just work.
gilesknap
commented
4 years ago I did, but now that you mention it, I can't remember if I did that before I tried the reboot. I can't test right now because there is a Minecraft get-together in session :-)
The other issue I had to resolve was that on Ubuntu I get the following:
giles@gknuc:~$ sudo loginctl enable-linger minecraft
[sudo] password for giles:
Could not enable linger: Read-only file systemBut apparently it is OK to do this
sudo touch /var/lib/systemd/linger/minecraftAnd I then see:
giles@gknuc:~$ sudo loginctl user-status minecraft
minecraft (1004)
Since: Sun 2020-04-19 12:55:53 BST; 1 day 4h ago
State: active
Sessions: 64 *61
Linger: yes
...So it seems to have worked but there is something not quite right with loginctl on my distro.
docent-net
commented
4 years ago This is actually related to bug in systemd itself. It was fixed in SD243, while you have v240 on Ubuntu 19.10: https://github.com/systemd/systemd/issues/12401
So your workaround should also work :)
On Mon, Apr 20, 2020 at 6:04 PM Giles Knap notifications@github.com wrote:
I did, but now that you mention it, I can't remember if I did that before I tried the reboot. I can't test right now because there is a Minecraft get-together in session :-)
The other issue I had to resolve was that on Ubuntu I get the following:
giles@gknuc:~$ sudo loginctl enable-linger minecraft [sudo] password for giles: Could not enable linger: Read-only file system
But apparently it is OK to do this
sudo touch /var/lib/systemd/linger/minecraft
And I then see:
giles@gknuc:~$ sudo loginctl user-status minecraft minecraft (1004) Since: Sun 2020-04-19 12:55:53 BST; 1 day 4h ago State: active Sessions: 64 *61 Linger: yes ...
So it seems to have worked but there is something not quite right with loginctl on my distro.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gilesknap/minecraft-control/issues/1#issuecomment-616650275, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAUFGSN7F3IKVGC5YAGXIDDRNRXCJANCNFSM4MMQFGKQ .
gilesknap
commented
4 years ago You were correct, auto start is working!
One more thing I'm going to look at is which of the following from @agowa338 's system unit template are applicable to a user service.
PrivateUsers=true # Users Database is not available for within the unit, only root and minecraft is available, everybody else is nobody
User=minecraft
Group=minecraft
ProtectSystem=full # Read only mapping of /usr /boot and /etc
ProtectHome=true # /home, /root and /run/user seem to be empty from within the unit. It is recommended to enable this setting for all long-running services (in particular network-facing ones).
ProtectKernelTunables=true # /proc/sys, /sys, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq will be read-only within the unit. It is recommended to turn this on for most services.
# Implies MountFlags=slave
ProtectKernelModules=true # Block module system calls, also /usr/lib/modules. It is recommended to turn this on for most services that do not need special file systems or extra kernel modules to work
# Implies NoNewPrivileges=yes
ProtectControlGroups=true # It is hence recommended to turn this on for most services.
# Implies MountAPIVFS=yes
The Problem
This project currently runs minecraft servers under a templated systemd user service.
There are two downsides this:
I chose to switch to a user service because the alternative was that minecraft-control needed to run with elevated privileges (using the elevate python library) all of the time.
I see this as the worse of two evils.
The positives of user service are:
The Correct Answer
In fact there is a mechanism to get the best of both worlds. You can use Policy Kit to give systemd control permissions to an ordinary account for a specific system service.
This would be great but the feature is part of polkit 0.106 which was out in 2012 but for some reason Debian and hence Ubuntu are stuck on the previous version. The previous version did allow granting of service permissions but not in a manner useful to this project.
See https://unix.stackexchange.com/questions/507975/systemd-service-management-using-pkla-equivalents-to-polkits-rules-on-debian/522843 for a useful discussion on the subject.
I await the release of polkit 0.106 in order to do this right (and its not coming in 20.04)