it-swarm.com.de

Kein Zugriff auf Collabora nach Neuinstallation

Ich habe eine bestehende Installation von Ubuntu 16.04 mit nextcloud in /var/www/cloud installiert (WordPress befindet sich im Stammverzeichnis). Es läuft jetzt schon eine Weile gut, aber ich habe kürzlich Collabora als Alternative zu Google Docs entdeckt und möchte, dass dies WIRKLICH funktioniert. Wenn ich versuche, ein Dokument zu öffnen, wird die Fehlermeldung "Zugriff verboten" angezeigt. Ich habe Collabora gemäß den Anweisungen installiert hier

Ich habe die Ausgabe von lsof -i überprüft und sehe, wie Docker auf 9980 lauscht, die URL in Nextcloud konfiguriert und ehrlich gesagt, ich bin mir nicht sicher, wie ich anfangen soll, dieses Problem zu beheben. Wenn mir jemand aus der Community eine Anleitung geben könnte, wäre das erstaunlich. Einige zusätzliche Informationen finden Sie weiter unten.

Einträge aus Apache error.log in/var/log/Apache2:

[Mon Jan 02 22:05:30.027625 2017] [authz_core:error] [pid 26396] [client <IPADDRESS>:54120] AH01630: client denied by server configuration: /var/www/html/cloud/data/.ocdata
[Mon Jan 02 22:05:32.314370 2017] [authz_core:error] [pid 3122] [client <IPADDRESS>:54123] AH01630: client denied by server configuration: /var/www/html/cloud/data/.ocdata

Bereinigte Version meiner Apache-Konfiguration für den Collabora-Host :

<VirtualHost *:443>
  ServerName sub.domain.com:443

  # SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/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$
  SSLHonorCipherOrder on

  # Encoded slashes need to be allowed
  AllowEncodedSlashes     On

  # 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 https://127.0.0.1:9980/loleaflet retry=0
  ProxyPassReverse           /loleaflet https://127.0.0.1:9980/loleaflet

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

  # Main websocket
  ProxyPassMatch    "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws

  # Admin Console websocket
  ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws

  # Download as, Fullscreen presentation and Image upload operations
  ProxyPass   /lool https://127.0.0.1:9980/lool
  ProxyPassReverse           /lool https://127.0.0.1:9980/lool
  ServerAlias    sub.domain.com
</VirtualHost>

Die Adresse meiner nextcloud-Instanz lautet domain.com/cloud

ausgabe von lsof -i | grep docker Ich glaube, dies zeigt, dass der Docker-Container auf Datenverkehr vom lokalen Host auf 9980 wartet, um ihn an den Container zu senden

docker-pr  1634     root    4u  IPv4  19492      0t0  TCP localhost:9980 (LISTEN)

Theorie : Ich habe eine Theorie, dass ich nextcloud wahrscheinlich dieses Mal neu einrichten muss, wobei nextcloud in der Webroot und mein Blog in einem Ordner in der Webroot ist Webroot, da die Stimmung, die ich aus der Dokumentation erhalte, darin besteht, dass nextcloud auf einem eigenen Computer mit einem eigenen Domänennamen erwartet wird und dieser Dienst eine Verbindung zu einer Unterdomäne dieses Stammdomänennamens herstellt. Die domain.com/cloud wirft also das Ganze für eine Schleife

wenn mir jemand eine Anleitung geben könnte, wäre ich sehr dankbar, da nextcloud ein Produkt ist, in das ich wirklich investieren möchte.

16
user502301

Dieser Beitrag von Mike Griffen behandelt genau dieses Problem, und es scheint eine einfache Lösung zu sein.

Authz_core:error Client Denied by Server Configuration

... mod_authz_core wurde in Apache2.3 eingeführt. Dies ändert die Art und Weise, wie die Zugriffssteuerung deklariert wird

von:

Order allow, deny
Allow from all

zu:

Require all granted

Dies bedeutet, dass die Gesamtkonfiguration für ein Verzeichnis jetzt ungefähr so ​​lautet:

<Directory /path/to/directory>
     Options FollowSymlinks
     AllowOverride none
     Require all granted
</Directory>

Starten Sie Apache neu und alles funktioniert einwandfrei.

1
Steve Hope