My setup is as follows: I have a web server which handles all HTTP(S) traffic and handles as a reverse proxy for both Nextcloud and Collabora. Both those services are installed on separate KVMs and I run Collabora itself as docker container.
Nextcloud itself runs without any problems and I can do everything except using Collabora.
Hi – can I ask you a question – are you trying to access collabora going through two reverse proxies??? – What I mean is the connection route you are using – is (Nextcloud machine using apache) --> to (Collarbora machine running apache reverse proxy) -> to docker?
The outputs should look like this: {"convert-to":{"available":true},"hasMobileSupport":true,"hasTemplateSaveAs":true,"productName":"Collabora Online Development Edition"}
If the second command’s output has {“available”:false} in it, you should follow the thread I linked to above and wait for a solution. Frustrating as hell, but as of now I have no idea where exactly the issue lies.
Ok can you post your section and the options you used when you start the docker container?
Why do you have two virtual host sections above? I don’t understand? Are Collabora and Nextcloud running on the same machine with same IP address or are they different?
The odd thing is that if I run that on localhost I get {“available”:false} but if I run it from another IP in the same network I get {“available”:true}. Running it against my public domain didn’t work but I guess that is because I don’t forward /hosting/discovery in my apache2 config if I’m not mistaken.
Running the command from a docker container on another domain that I can access without any problems on localhost also yields a {“available”:false}. While running it against the domain name returns the following:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /hosting/capabilities was not found on this server.</p>
<hr>
<address>Apache/2.4.25 (Debian) Server at myotherdomain.com Port 443</address>
</body></html>
My setup is as follows: I have a web server which handles all HTTP(S) traffic and handles as a reverse proxy for both Nextcloud and Collabora. Both those services are installed on separate KVMs and I run Collabora itself as docker container. All those KVMs are behind a NAT. The router simply redirects all HTTP(S) traffic to my web server which then splits up the traffic accordingly.
Accessing my Collabora instance from another domain (myotherdomain.com) is also impossible.
Yesterday I tried the alternative, OnlyOffice without any major luck. I am not able to access it with my Nextcloud server on mydomain.com but I can access it from myotherdomain.com without any problems and create, edit and save files.
Yea, but you have two reverse proxies right – Webserver / Nextcloud /Apache 1 on one machine – and Collabora Docker/Apache 2 on other machine right?
I know they are virtual machines (KVM) however I think of them as two separate “boxes”.
Also if Collabora is running on its own machine (separate than nextcloud) – you don’t technically need apache running on that machine). You can check this by doing the following:
I’m assuming a linux machine so something like this:
sudo ss -lntu
and if using ubuntu as the host double check firewall rules:
sudo ufw status
I have the main webserver on one machine which redirects all the traffic to Nextcloud / Collabora. Then I have an additional webserver(integrated in nextcloud-snap) on the machine that runs Nextcloud. I don’t have an additional webserver running on the machine that runs Collabora, instead I forward the traffic to the port that the docker container is using (9980). My main reason for not having a webserver on the machine is that I want all my custom configuration at a centralized place.
Honestly I didn’t pass variables for SSL to docker because I didn’t use any in my old, running setup and I haven’t seen them being used for the docker container by anyone.
Yea but you have two reverse proxies in your setup – or two instances of apache right?
The problem with two reverse proxies (as I painfully spent days trying to figure this out – is it won’t proxy the ws or websockets – websockets can be proxied once (at least I think this is the case)) That means your first reverse proxy has to have everything setup to work from there. HTTP traffic can be proxied a lot – like through multiple hops – but not websocket traffic. Thats why you are able to access html pages…
You might still be able to use two reverse proxies (I say might because I haven’t tried it) – if you just handle the websocket traffic at the first proxy. Also you need to make a decision if you are going to terminate https traffic at the first proxy since if you do the wss lines become ws (websocket secure vs websocket). Thats why I’m bothering you about the SSL crap.
I’ve never used nextcloud-snap.
I still might not understand your setup totally I admit – but when I see you posting two virtual hosts files from two different apaches (at least I think thats what they are), I’m suspicious.
Nothing at all? You say it does not work so somewhere a different thing appears then you expect.
If nextcloud/apache or collabora do not show anything in their logs it might be that your browser refuses to request something. What do you see in your browser window and in the web console when you try to open a document?
I have only one apache that does reverse proxying in my setup. The websockets are only being proxied once - from my apache to the port that runs the docker container. The reverse proxy is however behind a NAT router. Maybe that causes the problem?
Everything works with nextcloud right?
You’re entering http://collabora.mydomain.com into the nextcloud setup right?
Since you are not using encryption for collabora (which I still think you have to pass parameters to your docker that says ssl.enable=false and ssl.termination=true .
The Proxy Pass parameters would be http and ws — Here take a look at this page – Option #2 - https://www.collaboraoffice.com/code/apache-reverse-proxy/
Ok – great – I dont know if the sysctl options are needed (I’m letting you know that since I found this on another post in these forums, but everything else looks good.
After the change did you change your virtual hosts file for collabora to reflect http and ws rather than https or ws?
And yes collabora generates dummy certificates if you pass the option ssl.enable = true however this is an easy change later. These certs they issue are kind of bogus since they apache config disables any validity check on them which kind of defeats the purpose of SSL anyway.
Make sure you restart apache after making the Virtual Hosts change. If things dont work see if you can debug by reaching that admin web page again, or use wget with the websocket option or post your virtual host file