coturn certificate renewal about bigbluebutton-docker HOT 6 OPEN

ah, good point!
currently certificate renewals are not handled. It currently requires a restart of the coturn container once in a while.

A way I could imagine would be, that mod/coturn/entrypoint.sh stays active, repeats the # extract cert lines every x days and reloads/restarts coturn

from bigbluebutton-docker.

Hi @alangecker
Thanks for this great work!
I'm also interested in loading my own long term ssl certificate into nginx server. Is there some easy way to do so?
Or would be easier to setup a nginx server and use the HOWTO on how to integrate with a existing web server?
Regards

from bigbluebutton-docker.

Are you looking to integrate an external certificate only for the coturn server, as this issue refers to the coturn certificates?

In my setup, I'm using jwilder's docker proxy to handle letsencrypt certificates and ended up passing them to the coturn container in docker-compose.coturn.yml via:

volumes:
    #- ssl_data:/etc/resty-auto-ssl <- replace this with:
    - ./../nginx-proxy/certs/your.domain.tld:/etc/proxy-cert

and changing file paths in mod/coturn/entrypoint.sh to:

while [ ! -f /etc/proxy-cert/fullchain.pem ]
[...]
cat /etc/proxy-cert/fullchain.pem > /tmp/cert.pem
cat /etc/proxy-cert/key.pem > /tmp/key.pem

Unfortunately these changes need to be reapplied after pulling updates, but maybe there is a way to add a more general support (via the setup.sh) for common external reverse proxy images like traefik and nginx-proxy? (pinging @alangecker) This would greatly improve the ease of integration for servers with multiple services. Specifically thinking of NGOs on a tight budget with single server solutions.

For instance: The only other changes required to support jwilder's nginx-proxy for the entire bbb installations are in docker-compose.yml

• adding to the nginx service:

    expose:
      - "8080"
    environment:
      - VIRTUAL_HOST=${DOMAIN}
      - VIRTUAL_PORT=8080
      - LETSENCRYPT_HOST=${DOMAIN}
      - [email protected]
    #network_mode: host
    networks:
      nginx-proxy:
      bbb-net:

• and referencing the external network:

nginx-proxy:
    external: true

With these changes I can disable onboard https support via setup.sh and integrate this BBB setup into an existing nginx-proxy environment with multiple other services.

EDIT: Thinking about it .. maybe an easier way would have been just to enable the onboard letsencrypt service, disable the external letsencrypt service (from jwilder's proxy) for the bbb-domain and just pass the traffic through. Although I don't know whether the triple proxying might cause other issues. And in that case the service in docker-compose.https.yml must not run on "host" networking and host ports 80/443.

from bigbluebutton-docker.

@momenezes
If you want a customized setup I would strongly recommend to not use the included https_proxy & coturn containers. They are included for a nice fast way to setup everything ("plug&play feeling") , but not handy at all to customize.

Rather use a common nginx & certbot setup without docker. Instructions for that are all over the web. In the docs here you can find then how you add bbb-docker to it.
(Note there are still unmerged upates to the instructions https://github.com/alangecker/bigbluebutton-docker/pull/88/files)

@cjhille
Including traefik and nginx-proxy in the project bring up way more complexity and work to be maintained.
Including a https proxy at all was just for the mentioned "plug&play feeling", but I think this is now already provided with the current valian/docker-nginx-auto-ssl

For any customized setup in different environments I would always recommend not running the web server in docker and see no advantage worth the increase in complexity.

Same for coturn, which is also quite easy to setup outside docker including letsencrypt without any modifications.
https://docs.bigbluebutton.org/2.2/setup-turn-server.html might be a good source of hints (Note that these instructions there are meant for a clean server without any other services, port 443 is usually used by https)

from bigbluebutton-docker.

Tks @cjhille for your answer; you're right, I put my question on the wrong issue. Sorry for that.
Tks @alangecker. I'll try to follow your suggestion. My problem with a pure bbb-install was the old ubuntu dependency. I'll see another way to do that.
Regards

from bigbluebutton-docker.

@alangecker Thank you for you elaborate reply 🙏
While I agree with your assertion that supporting 3rd party proxies would cause more complexity for maintaining the repo, it would reduce complexity for setup and integration for users. After all this seems to be the reason why you decided to include a plug and play https proxy in the first place. But for that reasoning to hold up, the majority of people would need to use a dedicated host for bbb. And my guess is that people who have the resources for a dedicated host tend to simply go with the regular bbb install script (with the performance benefits that it brings), albeit being limited to an older Ubuntu LTS release. People who have a single production server with existing dockerized services can not go the Ubuntu route and will look for an alternative setup mechanism. For the latter your repo is the only viable option to run bbb and I'm guessing at least a big portion of this repo's users belong to that group.
Their primary hurdle is to integrate your docker services with their existing proxy solution and they would benefit greatly from a wider proxy support, be it by technical means or a better documentation.

IMHO low hanging fruits could be:

1. Using a more common docker proxy (with auto-ssl) as default -> it would work for more people right off the bat. See: usage of nginx-proxy vs valien Technically they are not that different, but nginx-proxy is probably the easiest and most common docker proxy with auto-ssl AFAICT.

2. More detailed documentation (with sample configuration) on how to alter bbb-docker configuration to run behind common dockerized proxies as well as non-dockerized nginx and apache webservers.

And once there are clear instructions on what exactly needs to be customized to enable proxy integration, why not add those steps to setup.sh? You're currently supporting orthogonal third party solutions like prometheus in exactly the same way (which I find to be a good idea).

I'd be happy to have a go at a PR, if you decide that this argument is reasonable.

Lastly I consider this to be a fantastic all in one bbb repo with well chosen customization options and great technical support and is on track to soon be the default way to install dockerized bbb services. In that regard user's expectations won’t be much different to those of other major dockerized repos like nextcloud, wordpress, jitsi, rocketchat and so on. And for those - if I’m not mistaken - the general approach is not to include an auto-ssl-proxy (rather give an example on how to add one if need be) and allow for good integration with existing proxies and external ssl or auto-ssl solutions via configuration, as the majority of users already has something in place.

from bigbluebutton-docker.