Nie można uzyskać dostępu do collabora po nowej instalacji

16

Mam istniejącą instalację Ubuntu 16.04 z zainstalowaną aplikacją nextcloud /var/www/cloud (wordpress znajduje się w katalogu głównym). Od jakiegoś czasu działa dobrze, ale niedawno odkryłem collabora jako alternatywę dla dokumentów Google i NAPRAWDĘ chcę, żeby to działało. Kiedy próbuję otworzyć dokument, pojawia się błąd „Zabroniony dostęp”. Zainstalowałem collabora zgodnie z instrukcjami tutaj

Sprawdziłem dane wyjściowe lsof -i i widzę, że doker nasłuchuje na 9980, skonfigurowałem adres URL w Nextcloud, i nie mam pojęcia, jak zacząć rozwiązywać ten problem. Gdyby ktokolwiek ze społeczności mógł udzielić mi wskazówek, które byłyby niesamowite. Niektóre dodatkowe informacje są poniżej.

Wpisy z pliku Apache error.log znajdującego się w katalogu / 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

Odkażona wersja konfiguracji My Apache dla hosta 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/$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>

Adres mojej instancji nextcloud to domain.com/cloud

wyjście lsof -i | grep docker Myślę, że to pokazuje, że kontener docker nasłuchuje ruchu z hosta lokalnego na 9980, aby wysłać do kontenera

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

Teoria : Mam teorię, że prawdopodobnie będę musiał ponownie skonfigurować nextcloud tym razem, gdy nextcloud jest w katalogu głównym, a mój blog znajduje się w folderze wewnątrz katalogu głównego, ponieważ wibracje, które czerpię z dokumentacji, są takie, że oczekuje się, że nextcloud będzie na własnej maszynie z własną nazwą domeny i ta usługa łączy się z subdomeną tej nazwy domeny głównej. więc domena.com/cloud rzuca wszystko na pętlę

jeśli ktoś mógłby dać mi jakieś wskazówki, byłbym bardzo wdzięczny, ponieważ nextcloud to produkt, w który naprawdę jestem zainteresowany inwestowaniem.

16.04 apache2 configuration docker nextcloud użytkownik502301
źródło

Odpowiedzi:

1

Ten post autorstwa Mike'a Griffena dotyczy właśnie tego problemu i wydaje się, że jest to proste rozwiązanie.

Authz_core:error Client Denied by Server Configuration

... mod_authz_core zostało wprowadzone w Apache 2.3. Zmienia to sposób deklarowania kontroli dostępu

od:

Order allow, deny
Allow from all

do:

Require all granted

Oznacza to, że całkowita konfiguracja katalogu jest teraz podobna do:

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

Uruchom ponownie apache, a wszystko będzie ładnie działać.

Steve Hope
źródło
poprawiona odpowiedź z rozszerzonym wyjaśnieniem, próbowała również zilustrować googlowanie (lub w tym przypadku kaczkę-kaczkę) rzeczywisty komunikat o błędzie „authz_core: error” jeden raz, a wybranie pierwszego wyniku często zapisuje odpowiedź na pytanie pętla tutaj
Steve Hope
Ludzie nie wiedzą, czy losowy artykuł jest poprawny ... przynajmniej na stronach SE mamy system głosowania (co prawda głosy nie zawsze są wiarygodne!) I zezwalamy wszystkim użytkownikom na edycję w celu wdrożenia pewnego poziomu recenzji, konserwacji itp. Tutaj znajdują się również posty wyszukiwarek. Zapewniając dobre odpowiedzi, zapewniamy dobre wyniki wyszukiwania.
Zanna,