Problems with official instalation (CODE 3.0, with docker)

ℹ️ Support 📄 Collabora
1

Hi,

I’m trying to install Collabora Online with docker collabora/code (3.0) using the official instructions of Nextcloud & Collabora Office.

I have the next infraestucture:

  • Nextcoud (12.04) in Debian 9 (LXC over Proxmox) with ip 192.168.5.14
  • collabora/code (3.0 over docker) in Linux Mint 18.3 Sylvia with ip 192.168.5.17

I have followed the next steps of instalation for collabora/code (taking into account that i already had nextcloud installed):

  1. docker pull collabora/code
  2. docker run -t -d -p 0.0.0.0:9980:9980 -e ‘domain=cloud\.mydomain\.foo’ --restart always --cap-add MKNOD collabora/code (ion this case, I said to the container to listen in all interfaces because my nextcoud other host)
  3. I create certificate with “sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt”
  4. I active the Apache required modules “sudo a2enmod proxy proxy_wstunnel proxy_http ssl”
  5. I create the Apache virtualhost for collabora with next sintax (and restart apache):

<VirtualHost *:443>
ServerName 192.168.5.14:443

ErrorLog /var/log/apache2/collabora-ssl_error.log
CustomLog /var/log/apache2/collabora-ssl_access.log combined

= # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/apache.crt
=# SSLCertificateChainFile /path/to/intermediate_certificate
SSLCertificateKeyFile /etc/apache2/ssl/apache.key
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on

=# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

=# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

=# keep the host
ProxyPreserveHost On

=# static html, js, images, etc. served from loolwsd
=# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet …127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet …127.0.0.1:9980/loleaflet

…

I know that I am using an IP as a ServerName “ServerName 192.168.5.14:443” in the virtualhost (I think it is valid), because I think it is not necessary go out from de LAN in order to communicate between nextcloud -> collabora.

In this steep I try open a file in nextcoud and I obtain the next error:

Internal Server Error
The server has encountered an error and can not complete the request.
Please contact the server administrator if this error reappears multiple times. Also include the technical details shown below.
More details can be seen in the server log.
Technical details

_ Remote address: 93.59.45.238_
_ Application ID: 6uEBzGEOBq9bCXVT3Vp6_

And in log I find this:

Error richdocuments GuzzleHttp\Exception\RequestException: cURL error 60: SSL certificate problem: self signed certificate in certificate chain

Then, I’m going to check the paths in the browser:

  • 192.168.5.17 - - [23/Dec/2017:12:19:46 +0100] “GET /loleaflet HTTP/1.1” 404 380 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0”
  • 192.168.5.17 - - [23/Dec/2017:12:25:25 +0100] “GET /lool/adminws HTTP/1.1” 500 1011 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0”
  • 192.168.5.17 - - [23/Dec/2017:12:37:43 +0100] “GET /lool HTTP/1.1” 400 337 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0”
  • 192.168.5.17 - - [23/Dec/2017:12:39:05 +0100] “GET /hosting/discovery HTTP/1.1” 200 3740 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0”

Apart from not understanding why I get these errors, I have a conclusion that I don’t know if it is correct:

If the container has a web server inside & nextcloud communicates with collabora without a public domain it is not necessary Apache as a proxy server.

Maybe the problem is in raise the container in 0.0.0.0 interfaces ?

Maybe it can be other ?

I am really overwhelmed with this topic & I would be very gratefull for your help.

Thank you,

Jon.

2

Hi guys,

When I put the https://192.168.5.17 in richdocuments configuration, I get de next error:

error-SSL-LOCAL_IP
error-SSL-LOCAL_IP1652×871 143 KB

I change from previous configuration (https://192.168.5.17) to web domain (https://office.mydomian.foo) and I configure in my Nginx reverse proxy as follows (I stop going through Apache in collabora container host because the container listen in all intercaces; 0.0.0.0:9980:9980):

server {
listen 443 ssl;
server_name office.mydomain.foo;
access_log /var/log/nginx/443.office.mydomain.foo.access.log main;
error_log /var/log/nginx/443.office.mydomain.foo.error.log error;
ssl on;
ssl_certificate /etc/letsencrypt/live/office.mydomain.foo/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/office.mydomain.foo/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
=# LetsEncrypt
location ~ /.well-known {
allow all;
}
=# static files
location / {
proxy_pass https://192.168.5.17:9980;
include /etc/nginx/proxy_params;
}
location ^~ /loleaflet {
proxy_pass https://192.168.5.17:9980;
proxy_set_header Host $http_host;
}
=# WOPI discovery URL
location ^~ /hosting/discovery {
proxy_pass https://192.168.5.17:9980;
proxy_set_header Host $http_host;
}
=# Main websocket
location ~ /lool/(.*)/ws$ {
proxy_pass https://192.168.5.17:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “Upgrade”;
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
=# Admin Console websocket
location ^~ /lool/adminws {
proxy_pass https://192.168.5.17:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “Upgrade”;
proxy_set_header Host $http_host;
proxy_read_timeout 36000s;
}
=# download, presentation and image upload
location ^~ /lool {
proxy_pass https://192.168.5.17:9980;
proxy_set_header Host $http_host;
}
}

By this manner Nextcould tries to connect to collabora but It shows:

error-interface
error-interface1922×926 23.8 KB

Now, I ask myself the next questions:

  1. Is it possible that richdocuments client communicates with collabora with autosigned cert? I don’t know if richdocument has some configuration.
  2. Is it possible that the communication of nextcloud with user-agent uses SSL (as until now) but richdocument with collabora doesn’t use SSL?

But obviously I still have the previous HTTP errors, testing via interface instead of testing with local URL (https://192.168.5.17) as I have doing before. However (I guess that for caching) when I make 2 attempts to open a doc I have different log.

I put the log of the 2 attempts:

1 attempt:

  • 93.59.45.238 - - [27/Dec/2017:20:49:46 +0000] “GET /hosting/discovery HTTP/1.1” 200 18697 “-” “Nextcloud Server Crawler” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:49:47 +0000] “POST /loleaflet/81c8935/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa&title=prueba.odt&lang=es&closebutton=1&revisionhistory=1 HTTP/1.1” 200 1606 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:49:47 +0000] “GET /loleaflet/81c8935/images/toolbar-bg.png HTTP/1.1” 200 5688 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:49:47 +0000] “GET /loleaflet/81c8935/images/lc_closedoc.svg HTTP/1.1” 200 294 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:49:47 +0000] “GET /lool/https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa%3Faccess_token%3D84pSYvq8ajtiu3QosvWhjpKU0vNGqlIT%26access_token_ttl%3D0%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa&compat=/ws HTTP/1.1” 400 0 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:49:47 +0000] “GET /loleaflet/81c8935/images/lc_save.svg HTTP/1.1” 200 1306 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • more images …
  • 93.59.45.238 - - [27/Dec/2017:20:49:47 +0000] “GET /lool/https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa%3Faccess_token%3D84pSYvq8ajtiu3QosvWhjpKU0vNGqlIT%26access_token_ttl%3D0%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa&compat=/ws HTTP/1.1” 400 0 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”

And 2 attempt:

  • 93.59.45.238 - - [27/Dec/2017:20:52:53 +0000] “POST /loleaflet/81c8935/loleaflet.html?WOPISrc=https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa&title=prueba.odt&lang=es&closebutton=1&revisionhistory=1 HTTP/1.1” 200 1607 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:52:53 +0000] “GET /lool/https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa%3Faccess_token%3DlfVzC4H6skhX4pHGt95NtF62qkSNyXwT%26access_token_ttl%3D0%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa&compat=/ws HTTP/1.1” 400 0 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”
  • 93.59.45.238 - - [27/Dec/2017:20:52:53 +0000] “GET /lool/https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa%3Faccess_token%3DlfVzC4H6skhX4pHGt95NtF62qkSNyXwT%26access_token_ttl%3D0%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2Fcloud.mydomain.foo%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F42_ociq0wuinnaa&compat=/ws HTTP/1.1” 400 0 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0” “-”

Regarding the previous situation (without domain), the log has some differences:

  1. /hosting/discovery continue in 200.
  2. /loleaflet passes from 404 to 200. I don’t know why.
  3. /lool continue in 400. Basically the service that response in /lool request considers that these requests are malformed, but I don’t know why.

Maybe I have make the collabora container without some parameters ? In ‘domain=cloud.mydomain.foo’ parameter must be passed to cloud.mydomain.foo or officle.mydomain.foo ?

I would be very gratefull for your help,

Thanks!

Jon

3

Well, I still answered myselft, since no wan response to this topic…

I think I am deducting some thinks, like the services that are behind these URLs:

  1. /hosting/discovery -> I understand that behind this URL responses the WOPI service (Libre Office Online in this case), and responses the XML scheme used by the WOPI service (of which I have to know more).
  2. /loleaflet -> As it says in de short documentation “loleaflet is the clinet part of the Libre Office Online”, so I undertand that these 2 first URLs are responsed for the Libre Office Online. I undestrand that the 404 is correct beacause the URI except a parameter, too.
  3. /lool -> I understand that this URL is in front of the loolwsd service, that is created for Collabora Team & It isused to provide the interaction funcionalities (chat, edit, notes, etc…) between multiple users. This route brings me back, 400 HTTP code (URL malformed), and analizing the URL, I see the following:

https://collabora.mydomain.foo/lool/https://cloud.mydomain.foo/index.php/apps/richdocuments/wopi/files/42_ociq0wuinnaa?access_token=84pSYvq8ajtiu3QosvWhjpKU0vNGqlIT&access_token_ttl=0&permission=edit/ws?WOPISrc=https://cloud.mydomain.foo/index.php/apps/richdocuments/wopi/files/42_ociq0wuinnaa&compat=/ws

  • I see that a value is not passed to “compat=” attribute
  • Here I see that is used “cloud” instead of “office” domain in URL, I understand that what we passed to the /lool URL or “loolwsd” service is the domain from the one we are making the request.

Can anybody bring some light to the topic ?

Thank you.

4

Hi @jonabasque,
maybe you should check the container’s log to see if anything happen/goes wrong when the container launch the loolwsd daemon or when you uses the client.
Also, the browser needs to access the collabora service (through your nginx proxy).
So if you’re self-hosted, ensure you have Natted the tcp 443 to your reverse proxy
as I guess your letsencrypt certificat point to your public ip
Best luck
Aal.

5

hi @aalaesar,

I have checked the container log and I get the following:

error-log-docker
error-log-docker1922×341 162 KB

I have been searching this error but I haven’t found neither the origin of the problem nor the solution.

I just realized that docker service only listens via IPv6 (I don’t see that it listens via IPv4) but in this case the log would not be generated, right?

tcp6 0 0 :::9980 :::* LISTEN 14655/docker-proxy off(0.00/0/0)

Here they are talking about the opposite problem Collabora Docker image with running nextcloud on IPV6 host - #5 by Brakelmann