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>"
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.
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.
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. 
