Provide a Let's Encrypt configuration out of the box

[dabruh]

I'm happy to see that there's a container for Mumble now!

There's one thing stopping me from switching over, and that is Let's Encrypt SSL cert integration which I currently have configured on my Mumble VM. Could we get this by chance?

Related: https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate

Best regards,
dabruh

[Krzmbrzl]

What exactly do you mean by that? Given that you can set the necessary config values in the Docker image, I would have thought that it should already be possible to use LE certs with it 🤔

[dabruh]

Hey @Krzmbrzl, perhaps I should elaborate a bit!

My aim is to have everything running in containers and not have dependencies to cron jobs or similar, thus live-reloading will be a problem:

/opt/certbot/certbot-auto renew --quiet --post-hook "service nginx reload ; start-stop-daemon --quiet --oknodo --stop --signal 10 --pidfile /var/run/mumble-server/mumble-server.pid"

Perhaps the server could check the modification time of the certs every minute or so and trigger the reload itself?

Additionally, I'd be happy to see a docker-compose example for integrating Mumble with Let's Encrypt.

Have a nice day ahead!
dabruh

[Krzmbrzl]

What you are looking for is probably to use the functionality from mumble-voip/mumble#2850 - though this still requires some external event. The exact functionality you seem to be looking for is not implemented in the server and therefore the Docker image can't do anything about that.

In terms of an example Docker compose that integrates LE support, I have no idea. Even though I authored parts of this Dockerfile, I actually know preciously little about the Docker world xD
Maybe @azlux has an example though...

Related to this general subject: mumble-voip/mumble#4544

[dabruh]

Yep, the USR1 signal is one part of it - but there would have to be some file watcher in the server as well which triggers this signal when the cert has been modified.

I'd be happy to hear what @azlux has to say on this matter. I don't lack the technical skills to implement this, but time is a scarce resource. Additionally, before I would start to think of how this could be implemented, I would want to talk to some of you who know the source code so that the implementation is right. Anyway, I happily take questions around containers as I'm hosting containers on an enterprise level using Kubernetes. However, Docker Compose isn't my strong side :-)

[sambirk]

The mumble docker image already provides environmental variables for SSL certs.
https://github.com/mumble-voip/mumble-docker#configuration

Why not use something like https://github.com/linuxserver/docker-swag with certs in a shared volume?

[dabruh]

@sambirk I am aware of both of these, but I've never used linuxserver/docker-swag. I think that more people than just I would benefit from having a configuration example for this.

[dabruh]

And again, there must be some change in the Mumble server code to automatically reload the SSL cert if it has changed. I am not sure how SIGUSR1 would be sent to the Mumble server from Docker Swag in case certbot renewed the cert.

[dabruh]

Alright, this is what I've come up with so far. The healthcheck+depends_on sections make sure that the certs are generated before the mumble-server container is spun up. The log output seems very quiet for this reason until the file appears. Without this check, the mumble container is in a failure loop until swag succeeds.

Anyway, we still need server code to automatically reload the cert when the file has been modified mumble-voip/mumble#5987

version: "3.0"

services:
  swag:
    container_name: swag
    image: lscr.io/linuxserver/swag:1.32.0
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    environment:
      PUID: 1000
      PGID: 1000
      TZ: Europe/London
      URL: my.domain.com
      VALIDATION: http
      STAGING: "false"
    volumes:
      - swag_config:/config
      - swag_etc:/config/etc
    ports:
      - "8088:80"
    healthcheck:
      test: ["CMD-SHELL", "[ -f /config/etc/letsencrypt/live/my.domain.com/fullchain.pem ] || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3

  mumble-server:
    container_name: mumble-server
    image: mumblevoip/mumble-server:v1.4.287-2
    restart: unless-stopped
    environment:
      MUMBLE_CONFIG_SSL_CERT: /ssl/letsencrypt/live/my.domain.com/fullchain.pem
      MUMBLE_CONFIG_SSL_KEY: /ssl/letsencrypt/live/my.domain.com/privkey.pem
    hostname: mumble-server
    volumes:
      - mumble:/data
      - swag_etc:/ssl
    ports:
      - "64738:64738"
      - "64738:64738/udp"
    depends_on:
      swag:
        condition: service_healthy

volumes:
  mumble:
  swag_config:
  swag_etc:

NOTE: If you do not intend to have another load balancer (a.k.a. reverse proxy) in front of SWAG, then change port 8088 to 80. I use 8088 because I have another Nginx server that takes care of my actual web traffic. In that Nginx I have a server rule ("block") which forwards the traffic to DOCKER_HOST:8088 if the domain is my.domain.com.

[sambirk]

And again, there must be some change in the Mumble server code to automatically reload the SSL cert if it has changed. I am not sure how SIGUSR1 would be sent to the Mumble server from Docker Swag in case certbot renewed the cert.

Does a mumble server installed directly into an OS without docker support reloading certificates on the fly?
If it doesn't, neither can the mumble docker image, it simply needs restarting.

Here's another example which uses cron to both renew a cert using the official certbot image then restart a service.
https://coderevolve.com/certbot-in-docker/

Hope that helps.

[Krzmbrzl]

Here's my understanding of the situation: you require a cron job for renewing the certificate anyway, don't you?
Then why not simply change that cron job to instead of calling certbot directly, to call a custom script. In that script you can then call certbot and once it has finished you can send SIGUSR1 to the server instance to cause a cert reload 👀

[dabruh]

Here's my understanding of the situation: you require a cron job for renewing the certificate anyway, don't you?

@Krzmbrzl No, linuxserver/docker-swag doesn't require a cron job.

Does a mumble server installed directly into an OS without docker support reloading certificates on the fly?
If it doesn't, neither can the mumble docker image, it simply needs restarting.

@sambirk I am aware that this is how Mumble works, but I am trying to help change this behavior so that it runs more natively in a container environment - where external triggers shouldn't be needed.

[Krzmbrzl]

Well, the external event in this case is the event issued via http(s). But anyway - this is nitpicking...

Our of interest: why is adding a cron job such a big issue in containers?

I think you could do something similar to the cert renewal by issuing a cert reload by using the Ice interface (essentially issuing a reload from outside the image). Not really a proper solution though. For that native support for auto-reloading is required.

[dabruh]

@Krzmbrzl Because there is no such thing as scheduling a cron job that runs on a Kubernetes node. In Kubernetes, a container should be able to run without a dependency on a particular host (ephemeral philosophy).

Cron jobs exist as a concept in Kubernetes as well, but those Cronjobs don't run code on the Kubernetes nodes, but as a container. It's possible to create a Kubernetes cronjob that would call the Kubernetes API server and kill the Mumble container, but that's really a hack and not something I'd want to do.