HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora

Just in case anybody else is having the same problem with Nextcloud 23 and Collabora (Collabora not opening any document):

It seems that the developers of Collabora have changed some directory names, which makes the original 011-collabora.conf invalid.

Here is a fixed version of that file:

<VirtualHost *:80>
  ServerName office.domain.name
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  AllowEncodedSlashes NoDecode
  SSLProxyEngine On
  SSLProxyVerify None
  SSLProxyCheckPeerCN Off
  SSLProxyCheckPeerName Off
  ProxyPreserveHost On
  # static html, js, images, etc. served from coolwsd
  # browser is the client part of Collabora Online
  ProxyPass           /browser https://127.0.0.1:9980/browser retry=0
  ProxyPassReverse    /browser https://127.0.0.1:9980/browser
  # WOPI discovery URL
  ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
  ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery
  # Capabilities
  ProxyPass           /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
  ProxyPassReverse    /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
  # Main websocket
  ProxyPassMatch      "/cool/(.*)/ws$"      wss://127.0.0.1:9980/cool/$1/ws nocanon
  # Admin Console websocket
  ProxyPass           /cool/adminws wss://127.0.0.1:9980/cool/adminws
  # Download as, Fullscreen presentation and Image upload operations
  ProxyPass           /cool https://127.0.0.1:9980/cool
  ProxyPassReverse    /cool https://127.0.0.1:9980/cool
  # Compatibility with integrations that use the /lool/convert-to endpoint
  ProxyPass           /lool https://127.0.0.1:9980/cool
  ProxyPassReverse    /lool https://127.0.0.1:9980/cool
</VirtualHost>

<VirtualHost *:443>
  ServerName office.domain.name
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  SSLEngine on
  AllowEncodedSlashes NoDecode
  SSLProxyEngine On
  SSLProxyVerify None
  SSLProxyCheckPeerCN Off
  SSLProxyCheckPeerName Off
  ProxyPreserveHost On
  # static html, js, images, etc. served from coolwsd
  # browser is the client part of Collabora Online
  ProxyPass           /browser https://127.0.0.1:9980/browser retry=0
  ProxyPassReverse    /browser https://127.0.0.1:9980/browser
  # WOPI discovery URL
  ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
  ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery
  # Capabilities
  ProxyPass           /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
  ProxyPassReverse    /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
  # Main websocket
  ProxyPassMatch      "/cool/(.*)/ws$"      wss://127.0.0.1:9980/cool/$1/ws nocanon
  # Admin Console websocket
  ProxyPass           /cool/adminws wss://127.0.0.1:9980/cool/adminws
  # Download as, Fullscreen presentation and Image upload operations
  ProxyPass           /cool https://127.0.0.1:9980/cool
  ProxyPassReverse    /cool https://127.0.0.1:9980/cool
  # Compatibility with integrations that use the /lool/convert-to endpoint
  ProxyPass           /lool https://127.0.0.1:9980/cool
  ProxyPassReverse    /lool https://127.0.0.1:9980/cool
  SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
  SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>

Cheers!

3 Likes

With 1 remark only, I would completely disable http and move to https only with e.g. following config:

<VirtualHost *:80>

  ServerName office.domain.name
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  Redirect permanent / https://office.domain.name/

</VirtualHost>
1 Like

If you disable HTTP rather than use a redirect, keep in mind that not all browsers will automatically go to HTTPS. It’s likely to cause confusing among your users when they just type in the FQDN and hit enter.

You have to keep the port open anyway if you use certbot, even if you take away the redirect.

@gas85 did not use exactly the correct word there… :wink: HTTP is of course not really disabled on the web server, if you use a VirtualHost on port 80. But with the permanent redirect he added, all HTTP requests are redirected / rewritten directly to HTTPS. And yes, you are right, port 80 has to be left open for this to work. :slight_smile:

1 Like

lool was changed to cool so it’s safe to replace. a working config is posted just 3 posts above!

Hi Martin, nobody knows how your system is build and you should check if there is some special setting you have now or if it’s safe to start from scratch using template provided… I would just compare both files and decide which path to follow…

First of all, I want to say thank you to @KarlF12 for making this guide. You’re my saviour because this guide is so thorough. Of course for you guys who joined in this discussion too, thank you. Now I have my nextcloud runs perfectly! (except for svg support)

Okay, now I want to share my experience following this guide. I use Ubuntu 20.04, with split horizon dns using pi hole.

  1. In apache, I only set 001-nextcloud.conf and 999-catchall.conf because I don’t have plan to use collabora.

  2. Somehow 999-catchall.conf that Karl provide didn’t work. I had to add:

<VirtualHost *:80>
  ServerName localhost
  ServerAlias *
  ...
</VirtualHost>

<VirtualHost _default_:443>
  ServerName localhost
  ServerAlias *
  ...
</VirtualHost>

(I followed this guide: centos - Make Apache server only accept requests to domain rather than IP - Server Fault)

  1. I didn’t set COLLABORA_FQDN and NEXTCLOUD_IPADDRESS in .env file. In docker-compose.yml, I removed collabora section and also removed extra_hosts on nextcloud section.

  2. After I ran docker-compose successfully, on host, I changed the data folder ownership to www-data:www-data. Little bit confused at first whether to change ownership on the host or inside the container.

  3. Set alias occ to ~/.bashrc and resolved proxy issue. I also configured default phone region by running this command:

occ config:system:set default_phone_region --value="<Your Country Code>"

  1. For Background jobs, I chose cron and configure host’s cronjob. (I followed this guide: https://blog.mariu5.de/~/MariusBlog/the-easiest-way-to-set-up-cron-for-the-nextcloud-docker-image/).

I would be especially thrilled if you would update it up to Nextcloud 23 :slight_smile:
I am still using your guide with slight modifications for reference :smiley:

You know, I’ve thought about it a few times, but I’m debating whether it’s obsolete now with the release of Nextcloud AIO. I haven’t actually tried it yet, but it looks promising.

Something I wanted to do if I ever did a rewrite was add the two high performance backends. They have them in AIO, and it would take me a lot of time to reinvent the wheel.

At the moment AIO is not a complete replacement of self build docker(-compose). It must be the only system running e.g. you can’t add another software behind AIO reverse proxy, you can’t install AIO behind existing reverse proxy… it needs write access to docker-socket (e.g. root on the host). all this points are known but there is no roadmap.

There is a discussion to use AIO as starting point to build fully customizable docker-compose system

If this works we could have a simple “one-click” AIO and customizable docker-compose for more advanced use cases…

Hmm… Well I’m certainly open to doing an updated re-write. I would insist on integrating both files and talk high performance backends in docker-compose and making it as turn-key as possible, so I’ll have to figure all that out.

notify_push has a dockerfile for building it, and I did try it once, although it’s been some time ago. But I can work with that.

For the Talk backend, they don’t seem to have an official docker image or dockerfile to build one. I did find this which I could try to integrate. I’m just wary of telling people to use 3rd party docker images that I can’t vet, even though I did with coturn before.

https://markus-blog.de/index.php/2020/11/20/how-to-run-nextcloud-talk-high-performance-backend-with-stun-turnserver-on-ubuntu-with-docker-compose/

I’m a network engineer by trade, not a software developer, so that’s getting a bit outside my element. I don’t want to get into a situation where I’m having to maintain my own image or vet someone else’s and don’t have the time or experience to do it properly. The problem is I know basically nothing about spreed or any of its various moving parts. But maybe I’ll try this for myself when I can and see how it turns out.

Honestly, this is not true anymore. It was when we release the first version but running it behind a reverse proxy is possible since a few versions :slight_smile:
See all-in-one/reverse-proxy.md at main · nextcloud/all-in-one · GitHub

The Talk HPB and files HPB are already part of the aio containers so not sure if you need to do that research…

Here you can find the documentation of my PR: all-in-one/manual-install at enh/557/add-docker-compose · nextcloud/all-in-one · GitHub and here the current docker-compose file: all-in-one/latest.yml at enh/557/add-docker-compose · nextcloud/all-in-one · GitHub

Feedback is welcome :slight_smile:

Disclaimer: the documentation does not work completely yet because this is part of a PR and not merged, yet.

That’s interesting. Suppose I could try just integrating the AIO talk container instead of using someone else’s. I want to try AIO though and see how it is, as long as it’s reasonably production-ready. I manage my personal Nextcloud instance as a production environment.

I think the version control is something that might bother me because I tend to hold back updating the major version until the xx.0.2 release or sometimes even closer to EOL on the current one, and I do that with the official image tags, e.g. nextcloud:22-apache. Just looking at Docker hub, I don’t see those tags available. Does AIO have that sort of version control available?

1 Like

Yes, feel free to do so :+1:

That is a good point. I am not sure we will do this because of the high maintenance effort that comes with it. I can only point towards this: https://github.com/nextcloud/all-in-one#update-policy for now… Additionally, we have a beta channel for all new updates. This channel gets all the updates a bit earlier so that we can make extra sure that nothing breaks.

I’ll look into adding at least identifiers that can be used as tag for when you want to get back a version.

1 Like

I just merged the PR so the documentation should work now.

See all-in-one/manual-install at main · nextcloud/all-in-one · GitHub

I will add id’s to the container images in the coming days.


Edit: ID’s are allso now added to the container images. See e.g. Docker Hub