Não é possível acessar o collabora após a nova instalação

16

Eu tenho uma instalação existente do Ubuntu 16.04 com o nextcloud instalado em /var/www/cloud (o wordpress está na raiz). Tem funcionado bem por um tempo agora, mas eu descobri recentemente collabora como uma alternativa ao google docs e realmente quero que isso funcione. Quando tento abrir um documento, recebo um erro "Acesso proibido". Eu instalei o collabora de acordo com as instruções encontradas aqui

Eu verifiquei a saída de lsof -i e posso ver a janela de encaixe ouvindo em 9980, Configurado a URL em Nextcloud e, basicamente, não tenho certeza de como começar a solucionar esse problema. Se alguém da comunidade pudesse me dar alguma orientação que seria incrível. Algumas informações adicionais estão abaixo.

Entradas de apache error.log localizadas em / 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

Versão sanitizada da Minha configuração do Apache para o vhost collabora :

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

O endereço da minha instância do nextcloud é domain.com/cloud

saída de lsof -i | grep docker Acredito que isso mostre que o contêiner docker está escutando o tráfego do host local em 9980 para enviar para o contêiner

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

Teoria : Eu tenho uma teoria que eu provavelmente precisarei configurar nextcloud novamente desta vez com nextcloud sendo na webroot e meu blog estando em uma pasta dentro da webroot porque a vibração que estou recebendo a partir da documentação, espera-se que o nextcloud esteja em sua própria máquina, com seu próprio nome de domínio, e esse serviço se conectará a um subdomínio desse nome de domínio raiz. então o domínio.com/cloud está jogando tudo por um loop

se alguém puder me dar alguma orientação, eu ficaria muito grato, já que nextcloud é um produto no qual estou realmente interessado em investir.

    
por user502301 03.01.2017 / 05:43

1 resposta

1

Este post de Mike Griffen aborda apenas esta questão e parece ser uma solução simples.

Authz_core:error Client Denied by Server Configuration
  

... mod_authz_core foi introduzido no Apache2.3. Isso muda a maneira como o controle de acesso é declarado

     

de:

Order allow, deny
Allow from all
     

para:

Require all granted
     

Isso significa que a configuração total de um diretório agora é algo como:

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

Reinicie o apache e tudo funcionará bem.

    
por Steve Hope 10.04.2017 / 15:40