After reboot of server Nextcloud doesn't find collabora anymore


#1

Hi,

i’m a bit frustrated at the moment. I’ve restarted the server because of maintanence and collabora within nextcloud doesn’t work anymore. The container runs and apache2 proxy is working as usual but the nextcloud doesn’t connect to it. Here is the log. Do you find the cause of it? I couldn’t

    Error	richdocuments	GuzzleHttp\Exception\ConnectException: cURL error 7: Failed to connect to office.steingaesser.net port 443: Connection timed out
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 103: GuzzleHttp\Exception\RequestException wrapException(Object(GuzzleHttp\Message\Request), Object(GuzzleHttp\Ring\Exception\ConnectException))
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 132: GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
/var/www/owncloud/3rdparty/react/promise/src/FulfilledPromise.php - line 25: GuzzleHttp\RequestFsm->GuzzleHttp\{closure}(Array)
/var/www/owncloud/3rdparty/guzzlehttp/ringphp/src/Future/CompletedFutureValue.php - line 55: React\Promise\FulfilledPromise->then(Object(Closure), NULL, NULL)
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Message/FutureResponse.php - line 43: GuzzleHttp\Ring\Future\CompletedFutureValue->then(Object(Closure), NULL, NULL)
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/RequestFsm.php - line 134: GuzzleHttp\Message\FutureResponse proxy(Object(GuzzleHttp\Ring\Future\CompletedFutureArray), Object(Closure))
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php - line 165: GuzzleHttp\RequestFsm->__invoke(Object(GuzzleHttp\Transaction))
/var/www/owncloud/3rdparty/guzzlehttp/guzzle/src/Client.php - line 125: GuzzleHttp\Client->send(Object(GuzzleHttp\Message\Request))
/var/www/owncloud/lib/private/Http/Client/Client.php - line 138: GuzzleHttp\Client->get('https //office....', Array)
/var/www/owncloud/apps/richdocuments/lib/WOPI/DiscoveryManager.php - line 84: OC\Http\Client\Client->get('https //office....')
/var/www/owncloud/apps/richdocuments/lib/WOPI/Parser.php - line 41: OCA\Richdocuments\WOPI\DiscoveryManager->get()
/var/www/owncloud/apps/richdocuments/lib/TokenManager.php - line 122: OCA\Richdocuments\WOPI\Parser->getUrlSrc('application/vnd...')
/var/www/owncloud/apps/richdocuments/lib/Controller/DocumentController.php - line 168: OCA\Richdocuments\TokenManager->getToken(*** sensitive parameters replaced ***)
[internal function] OCA\Richdocuments\Controller\DocumentController->index('108669')
/var/www/owncloud/lib/private/AppFramework/Http/Dispatcher.php - line 160: call_user_func_array(Array, Array)
/var/www/owncloud/lib/private/AppFramework/Http/Dispatcher.php - line 90: OC\AppFramework\Http\Dispatcher->executeController(Object(OCA\Richdocuments\Controller\DocumentController), 'index')
/var/www/owncloud/lib/private/AppFramework/App.php - line 114: OC\AppFramework\Http\Dispatcher->dispatch(Object(OCA\Richdocuments\Controller\DocumentController), 'index')
/var/www/owncloud/lib/private/AppFramework/Routing/RouteActionHandler.php - line 47: OC\AppFramework\App main('OCA\\Richdocumen...', 'index', Object(OC\AppFramework\DependencyInjection\DIContainer), Array)
[internal function] OC\AppFramework\Routing\RouteActionHandler->__invoke(Array)
/var/www/owncloud/lib/private/Route/Router.php - line 299: call_user_func(Object(OC\AppFramework\Routing\RouteActionHandler), Array)
/var/www/owncloud/lib/base.php - line 1004: OC\Route\Router->match('/apps/richdocum...')
/var/www/owncloud/index.php - line 48: OC handleRequest()
{main}

#2

Could you please provide some more information? What setup are you running, what are your server configs and so on. The apache config would be interesting to see and how the apache forwards the requests to the docker image.

On which port does your Collabora docker listen? Could you check that it is listening there right now?

What kind of maintenance was it, that lead to the reboot? What have you changed on the server and what have you tried to solve the problem?


#3

Hi, thanks for your reply.

Sorry for too less information, so here are some more:

Apache2 proxy conf:
<VirtualHost *:443>
ServerName office.mydomain.net

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/office.mydomain.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/office.mydomain.net/privkey.pem
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


AllowEncodedSlashes NoDecode


SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off


ProxyPreserveHost On

ProxyPass           /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse    /loleaflet https://127.0.0.1:9980/loleaflet

ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery

ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon

ProxyPass   /lool/adminws wss://127.0.0.1:9980/lool/adminws

ProxyPass           /lool https://127.0.0.1:9980/lool
ProxyPassReverse    /lool https://127.0.0.1:9980/lool

</VirtualHost>

It is a Debian Stretch server, i’ve changed the CPU. To solve the problem i just reinstalled the docker container but without any effect.

php -v
PHP 7.0.27-0+deb9u1 (cli) (built: Jan  5 2018 13:51:52) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.27-0+deb9u1, Copyright (c) 1999-2017, by Zend Technologies

#4

Please execute
netstat -an | grep ":9980"

Do you have a firewall running (or iptables defined) which might block the ports required for Collabora?

I don’t have Collabora running in my environment, so I don’t know how everything should look like. When I access your domain I only see the “Apache2 Debian Default Page”. Don’t know if this is usually the case with a Collabora docker image or if there should be some other content, maybe like “Collabora is running”.

Maybe someone else with more Collabora experience can spread some light on this.


#5

Hi, yes it is listening on that port:

netstat -an | grep ":9980"
tcp 0 0 127.0.0.1:9980 0.0.0.0:* LISTEN

As it was working i also had the Apache2 Default Page by accessing the domain directly. So since the collabora does not directly provide a webservice it seems to be right.


#6

Hi together

I have a two server setup:
Nextcloud
Collabora

Both listen on 127.0.0.1:9980.

But i did a Ping from Nextcloud server to Collabora domain server on port 9980 with no resultat. Port 80 was Okay.

I look to open the door and give feedback later.


#7

Okay, ping and ports isnt possible.

Sorry, i am still on learning stage.


#8

I also see similar problems actually. It used to work in the past (several months ago by now). I’m using Nextcloud 14.0.3 and Collabora Online app v3.0.1.

And I use Collabora Docker (often called Collabora CODE) from:

docker pull collabora/code
docker run -t -d -p 127.0.0.1:9980:9980 -e "domain=cloud\\.melroy\\.org" -e "username=admin" -e "password=secret_password" --restart always --cap-add MKNOD collabora/code

Nginx reverse proxy setup:

upstream office {
    server 127.0.0.1:9980;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    listen 80;
    server_name office.melroy.org;
    server_tokens off;
    
    return 301 https://$host$request_uri; # managed by Certbot
}

server {
    listen 443 ssl http2;
    server_name office.melroy.org;
    server_tokens off;
    
    ssl on;
    # Certificate & key
    ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem; # managed by Certbot
    
    # Increase security (using the Diffie-Hellman Group file)
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
    
    ssl_protocols TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES265-SHA:!aNULL;
    ssl_prefer_server_ciphers on;
    ssl_ecdh_curve secp521r1:secp384r1:secp256k1;
    
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_stapling on;
    ssl_stapling_verify on;
    
    #  Feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    # Don't allow the browser to render the page inside an frame or iframe and avoid clickjacking
    add_header X-Frame-Options SAMEORIGIN;
    # When serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,
    # to disable content-type sniffing on some browsers.
    add_header X-Content-Type-Options nosniff;
    # Enable the Cross-site scripting (XSS) filter built into most recent web browsers.
    add_header X-XSS-Protection "1; mode=block";
    # With CSP tell the browser that it can only download content from the domains you explicitly allow (without 'unsafe-inline' 'unsafe-eval')
    # No CSP too complicated
    # Referrer Policy will allow a site to control the value of the referer header in links away from their pages.
    add_header Referrer-Policy "no-referrer";
    
    location / {
        proxy_read_timeout      300;
        proxy_connect_timeout   300;
        proxy_redirect          off;
        proxy_set_header    Host $http_host;
        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto   $scheme; 
        proxy_pass https://office;
    }
        
    # static files
    location ^~ /loleaflet {
        proxy_pass https://localhost:9980;
        proxy_set_header Host $http_host;
    }

    # WOPI discovery URL
    location ^~ /hosting/discovery {
        proxy_pass https://localhost:9980;
        proxy_set_header Host $http_host;
    }

    # main websocket
    location ~ ^/lool/(.*)/ws$ {
        proxy_pass https://localhost: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://localhost:9980;
        proxy_set_header Host $http_host;
    }

    # Admin Console websocket
    location ^~ /lool/adminws {
        proxy_pass https://localhost:9980;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $http_host;
        proxy_read_timeout 36000s;
    }
}

Correctly configured in Nextcloud:

Collabora CODE is running fine:

netstat -an | grep ":9980"
tcp        0      0 127.0.0.1:9980          0.0.0.0:*               LISTEN

office.melroy.org stats ‘OK’ (it is running fine).

But opening a document in my browser results in all kind of errors showed above from GuzzleHttp.

Could some internal certificate be expired?