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… 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.
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.
In apache, I only set 001-nextcloud.conf and 999-catchall.conf because I don’t have plan to use collabora.
Somehow 999-catchall.conf that Karl provide didn’t work. I had to add:
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.
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.
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>"
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.
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.
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?
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.