Sorry it took me so long to come back to this. And also sorry for the lengthy reply.
On Fri, Jan 15, 2021 at 09:27:30 +0000, Chris Knadle wrote: > Is the system with this issue running systemd? Yes, the affected system does run systemd. > Which method of creating an SSL cert is being used? certbot (Let's Encrypt) > I've tested mumble-server on Debian 10.7 for this, with the default > configuration, both with and without CAPABILITIES enabled, and I'm able to > shut down mumble-server correctly on a system running systemd. […] Welp, I couldn't reproduce it on other systems either; turned out some modification to the init-script I made months ago and forgot about was causing this (I suspect it only started to cause problems after a reboot). Sorry, for wasting your time by jumping to a report to quickly. Though, I also already heard about about the same thing happening to another user before (without any modification afaik). Hearing back from this user now, the problem disappeared again for him without any apparent reason. I'm afraid I don't know what's causing this issue for him and people reporting this upstream. Again, I'm terribly sorry to not have better checked on my side before reporting this. Something (possibly related?) I noticed while investigating this: If capabilities are used and uname in /etc/mumble-server.ini is set to something else than "mumble-server", than this problem appears as long as USER inside the init-script isn't also changed. Ofc, before that happens murmur will first refuse to start at all, since it will be unable to access vital files, like: /var/lib/mumble-server /var/log/mumble-server /etc/mumble-server.ini Change ownership of those locations is perhaps more obvious than needing to edit some variable inside the init-script. Especially since after changing ownership of those files murmur will at first glance appear to start just fine as no error about the missing pid file is printed. I'm however neither sure if that really is the cause for those upstream reports, nor what's the best way to solve this. Now about the SSL-certs: > I understand the problem of needing to start as root in order to read ssl > certs, and […] I think there's an alternative; I think the SSL cert can > be copied with different ownership + permissions to a location that > mumble-server can access using a "post-hook" or "deploy-hook" call to > certbot or dehydrated […] Using --post-hook would be cleaner than my current method of just chaining certbot renewal and restarting/reloading affected services, like so: certbot renew --quiet && service mumble-server restart If the certificate should remain root-only, then --post-hook 'service mumble-server restart' seems ok to me and is comfortably short. Otherwise, if making it accessible to mumble-server is acceptable I assume calling a script similar to the following (!untested!) one in certbot's post-hook would be better and allows to utilise a reload instead of restart: #!/bin/sh set -e umask 077 mkdir -p /var/lib/mumble-server/ssl cp /etc/letsencrypt/live/mumble.example.org/fullchain.pem /var/lib/mumble-server/ssl cp /etc/letsencrypt/live/mumble.example.org/privkey.pem /var/lib/mumble-server/ssl chown -R mumble-server:mumble-server /var/lib/mumble-server/ssl service mumble-server reload > Mumble upstream also suggests […] > https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate Yes, I've seen this suggestion before, but didn't like it due to security concerns and opted for starting murmur as root instead (which then drops root privileges on its own). > I'm fairly interested in trying to find a good solution to this, because > this permission problem is a common gripe that I hear from users on the > Mumble IRC channel, so if a better solution can be found maybe I could have > upstream add it to the wiki or the website so others could take advantage of > it. > > -- Chris ~~ Nils
