web-dev-qa-db-fra.com

Impossible d'accéder à collabora après une nouvelle installation

J'ai une installation existante d'Ubuntu 16.04 avec nextcloud installée dans /var/www/cloud (wordpress se trouve à la racine). Cela fonctionne bien depuis un moment maintenant, mais j'ai récemment découvert collabora comme une alternative à Google Docs et je veux VRAIMENT que cela fonctionne. Lorsque j'essaie d'ouvrir un document, le message d'erreur "Accès interdit" s'affiche. J'ai installé collabora conformément aux instructions trouvées ici

J'ai vérifié la sortie de lsof -i et je peux voir que le docker écoute sur 9980, a configuré l'URL dans Nextcloud et sans que je sache vraiment comment procéder pour résoudre ce problème. Si quelqu'un de la communauté pouvait me donner des conseils, ce serait génial. Quelques informations supplémentaires sont ci-dessous.

Entrées de Apache error.log situé dans/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

Version assainie de My Apache config pour le collabora vhost :

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

L'adresse de mon instance nextcloud est domain.com/cloud

sortie de lsof -i | grep docker Je pense que cela montre que le conteneur docker écoute le trafic de l'hôte local sur 9980 à envoyer au conteneur

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

Théorie : J'ai une théorie que je devrai probablement configurer nextcloud à nouveau cette fois-ci avec nextcloud dans la racine Web et mon blog dans un dossier du webroot parce que la documentation me donne l'impression que nextcloud devrait se trouver sur sa propre machine avec son propre nom de domaine et que ce service se connecte à un sous-domaine de ce nom de domaine racine. donc le domain.com/cloud jette le tout pour une boucle

si quelqu'un pouvait me donner des conseils, j'apprécierais beaucoup, car nextcloud est un produit qui m'intéresse vraiment.

16.04apache2configurationdockernextcloud
16
user502301

Cet article de Mike Griffen traite uniquement de cette question et semble être une solution simple.

Authz_core:error Client Denied by Server Configuration

... mod_authz_core a été introduit dans Apache2.3. Cela change la façon dont le contrôle d'accès est déclaré

de:

Order allow, deny
Allow from all

à:

Require all granted

Cela signifie que la configuration totale pour un répertoire est maintenant quelque chose comme:

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

Redémarrez Apache et tout fonctionnera correctement.

1
Steve Hope