Napraw pustą stronę/biały ekran śmierci w ownCloud: Wybierz właściwą ścieżkę odzyskiwania

Zacznij od ustalenia, jaki rodzaj pustej strony faktycznie posiadasz

„Biały ekran śmierci” w ownCloud to objaw, a nie diagnoza. Najlepsze rozwiązanie zależy od tego, czy przeglądarka otrzymała błąd serwera, otrzymała prawidłowy kod HTML, ale nie załadowała JavaScriptu lub CSS, czy też połączyła się z odwrotnym serwerem proxy, który w ogóle nie mógł połączyć się z ownCloud.

To rozróżnienie ma znaczenie, ponieważ kompromisy są bardzo różne. Wyłączenie aplikacji innej firmy jest stosunkowo mało ryzykowne, gdy wyjątek PHP nadaje jej nazwę. Zmiana właściciela pliku w całej instalacji jest znacznie bardziej inwazyjna i nie powinna być pierwszą reakcją na błąd JavaScript. Podobnie, ponowne uruchomienie każdej usługi może na chwilę ukryć problem, nie informując, czy jego źródłem jest PHP, serwer proxy, aktualizacja czy aplikacja.

Ten przewodnik dotyczy ownCloud Classic. W aktualnej dokumentacji ownCloud Classic 11, wersja 11 jest obsługiwana jako wdrożenie oparte na Dockerze, z systemem operacyjnym, środowiskiem wykonawczym PHP, bazą danych i serwerem Apache w kontenerach dostarczonych przez ownCloud. Starsze instalacje 10.x mogą nadal korzystać z tradycyjnego układu serwera WWW i PHP-FPM. Użyj gałęzi poleceń odpowiedniej dla swojego wdrożenia. Zapoznaj się z wymaganiami systemowymi ownCloud Classic 11 .

1. Czy pusta strona zwraca HTTP 500, czy też przeglądarka kończy działanie po HTTP 200?

Otwórz narzędzia programistyczne przeglądarki i sprawdź karty Sieć i Konsola . Przetestuj również punkt końcowy z poziomu terminala:

curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/

Podpis: Odpowiedź 500 po stronie serwera wskazuje na ownCloud, PHP, bazę danych lub stos internetowy, a nie na prosty problem z renderowaniem w przeglądarce.

Jeśli dokument główny zwraca 500 lub 502/503 , priorytetowo potraktuj dzienniki serwera i serwera proxy. Jeśli dokument główny zwraca 200 , ale pakiety JavaScript kończą się błędem 404, 403 lub wyjątkami skryptu, priorytetowo potraktuj ścieżki zasobów, przepisywanie odwrotnego proxy, motywy, pamięć podręczną lub zgodność aplikacji. Jeśli problem dotyczy tylko jednej przeglądarki, przed zmianą serwera przetestuj okno prywatne i inną obsługiwaną przeglądarkę.

2. Czy problem zaczął się po aktualizacji ownCloud lub PHP?

To jedno z najważniejszych pytań, ponieważ pozwala natychmiast zawęzić zakres błędu. Aktualne informacje o wydaniu ownCloud wskazują, że ownCloud Classic 11 podniósł minimalną wersję PHP do PHP 8.3, a ownCloud Classic 11 jest dostępny wyłącznie w Dockerze. Starsza instalacja ownCloud 10.x podlega innym zasadom zgodności PHP, dlatego nie należy kopiować porad dotyczących PHP z innej głównej wersji.

W przypadku tradycyjnej instalacji ownCloud 10.x uruchom polecenie z katalogu ownCloud:

sudo -u www-data ./occ status
php -v

W przypadku ownCloud Classic 11 uruchom OCC za pomocą wdrożenia Compose:

docker compose exec owncloud occ status
docker compose exec owncloud php -v

Podpis: Sprawdzenie zainstalowanych wersji ownCloud i PHP jest szczególnie ważne, ponieważ bezpośrednio po aktualizacji pojawia się biały ekran.

Porównaj wynik z informacjami o wydaniu dla wersji, której faktycznie używasz. Oficjalne informacje o wydaniu ownCloud stanowią właściwe źródło informacji o aktualnych minimalnych wersjach i zmianach, które mogą mieć wpływ na bezpieczeństwo. Obniżenie wersji nie jest bezpiecznym, ogólnym rozwiązaniem: dokumentacja ownCloud ostrzega, że ​​obniżenie wersji nie jest obsługiwane, ponieważ może uszkodzić dane.

3. Który dziennik wskazuje pierwszy konkretny błąd?

Dzienniki są zazwyczaj bardziej przydatne niż wprowadzanie zmian konfiguracji metodą prób i błędów. Podręcznik administratora ownCloud zaleca korzystanie z dziennika ownCloud w celu diagnozowania problemów; domyślnie dziennik jest przechowywany w skonfigurowanym katalogu danych, chyba że logfileustawiono inaczej.

W przypadku instalacji tradycyjnej przykłady obejmują:

tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"

W przypadku ownCloud Classic 11 zamiast tego sprawdź usługi Compose:

docker compose logs --tail=200 owncloud
docker compose ps

Podpis: Krytyczny błąd PHP lub ślad stosu określający nazwę aplikacji lub klasy stanowi o wiele bezpieczniejszy cel rozwiązywania problemów niż zmiana niezwiązanych z tym ustawień serwera.

Szukaj pierwszego wyjątku krytycznego w okolicy nieudanego żądania, a nie tylko ostatniej kaskady błędów. Typowe kategorie to brak klasy PHP, niezgodna aplikacja, błąd połączenia z bazą danych, nieczytelna konfiguracja, brakujące pliki kodu lub wyjątek podczas niedokończonej aktualizacji.

Dokumentacja logowania ownCloud podaje, że logowanie DEBUG może być pomocne podczas diagnostyki, ale generuje znaczące dane wyjściowe i może wpływać na wydajność. Jeśli tymczasowo podniesiesz poziom logowania, przywróć go do mniej szczegółowej wartości po zebraniu danych. Zobacz konfigurację logowania ownCloud .

4. Czy warto wyłączyć aplikację innej firmy?

Wybierz tę ścieżkę, gdy błąd dotyczy aplikacji niebędącej aplikacją podstawową, gdy pusta strona została wyświetlona po zainstalowaniu lub zaktualizowaniu aplikacji lub gdy błąd wystąpił podczas aktualizacji ownCloud. Wskazówki dotyczące rozwiązywania problemów ownCloud wyraźnie zalecają wyłączenie aplikacji innych firm na czas rozwiązywania problemów i przed aktualizacjami.

Najpierw wyświetl listę aplikacji. Na ownCloud 10.x:

sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_ID

W ownCloud 11:

docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID

Podpis: Wyłączenie tylko aplikacji, której dotyczą dzienniki, jest mniej uciążliwe niż wyłączenie wielu komponentów lub zmiana całego stosu internetowego.

Wadą jest funkcjonalność: użytkownicy tracą daną aplikację do czasu jej aktualizacji lub ponownego włączenia. Zazwyczaj jest to lepsze rozwiązanie niż wyłączenie podstawowych usług ownCloud. W dokumentacji OCC zaznaczono również, że nie można wyłączyć kilku podstawowych aplikacji, w tym DAV, FederatedFileSharing, Files i Files_External. Zapoznaj się z oficjalnymi ogólnymi wskazówkami dotyczącymi rozwiązywania problemów oraz dokumentacją poleceń OCC .

5. Kiedy warto naprawić uprawnienia?

Uprawnienia są poważnym podejrzeniem, gdy dziennik zawiera Permission denied, np. gdy podczas ostatniego wdrożenia skopiowano pliki aplikacji/konfiguracji jako niewłaściwy użytkownik lub gdy aktualizacja zastąpiła pliki z nieprawidłową nazwą właściciela. Są one słabym podejrzeniem, gdy jedynym dowodem jest błąd JavaScript po stronie przeglądarki.

Przed przystąpieniem do prac naprawczych przełącz system w tryb konserwacyjny. W przypadku ownCloud 11:

docker compose exec owncloud occ maintenance:mode --on

W przypadku tradycyjnego wdrożenia 10.x:

sudo -u www-data ./occ maintenance:mode --on

Podpis: Tryb konserwacji ogranicza aktywność użytkowników, gdy badasz błędy dotyczące własności lub uprawnień do plików, które są już potwierdzone dowodami w dzienniku.

Nie uruchamiaj rekursywnego generowania chmod 777ani nie kopiuj przepisów uprawnień z niepowiązanej wersji. Aktualny podręcznik ownCloud 11 opisuje konkretne prawa własności i tryby ręcznie dodawanych plików w katalogach appsi configkatalogach zamontowanych w Dockerze: prawa własności www-data:root, pliki aplikacji 0644, katalogi aplikacji 0751i dodane pliki konfiguracyjne 0644. Dokumentuje również 0640ręcznie zmienione .htaccessi .user.ini. Użyj dokumentacji manual-upgrade ownCloud 11 jako odniesienia do konkretnej wersji.

6. Czy należy zmienić moduły PHP, OPcache lub ustawienia pamięci?

Tylko wtedy, gdy logi lub kontrole zgodności wskazują na to. Ta ścieżka ma szerszy zasięg niż wyłączenie jednej wadliwej aplikacji. Brak wymaganego rozszerzenia PHP może uniemożliwić uruchomienie kodu, a błędna konfiguracja PHP może wpłynąć na każdą aplikację PHP na hoście.

W przypadku starszego stosu PHP zarządzanego przez hosta sprawdź, co faktycznie ładuje środowisko wykonawcze sieci Web:

php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable

Podpis: Sprawdzanie modułów PHP i OPcache jest przydatne, gdy serwer rejestruje brakujące nazwy rozszerzeń lub niezgodność czasu wykonania, ale nie powinno być to pierwszą zmianą bez dowodów.

W przypadku ownCloud 11 oficjalny obraz zarządza środowiskiem wykonawczym PHP, więc zmiana pakietów PHP hosta zazwyczaj nie jest właściwą warstwą. Dokumentacja ownCloud wskazuje, że OPcache jest domyślnie włączony w obrazie Docker. Zobacz dokumentację dotyczącą buforowania pamięci ownCloud .

Jeśli podejrzewasz nieaktualny OPcache po ręcznej wymianie plików PHP w starszej instalacji, ponowne uruchomienie PHP-FPM lub odpowiedniej usługi webowej/PHP może wyczyścić lokalną pamięć podręczną kodu operacji. Kompromisem jest krótkotrwała przerwa i późniejsza wydajność pamięci podręcznej cold-cache. Zrób to po poprawieniu plików źródłowych, a nie jako substytut identyfikacji błędu.

7. Czy aktualizacja została przerwana lub pliki główne są niespójne?

Jeśli w trakcie aktualizacji lub zaraz po niej pojawiła się biała strona, najpierw sprawdź stan aktualizacji. Własna dokumentacja aktualizacji ownCloud zaleca korzystanie z OCC do przeprowadzenia aktualizacji i naprawy, zamiast ręcznej modyfikacji bazy danych.

Dla ownCloud 11:

docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-core

W przypadku ownCloud 10.x należy użyć odpowiednich poleceń OCC w ramach użytkownika serwera WWW:

sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core

Podpis: Naprawa OCC jest odpowiednia w przypadku przerwanej lub niespójnej aktualizacji, natomiast kontrole integralności umożliwiają identyfikację zmodyfikowanych lub brakujących podpisanych plików jądra.

Wyniki integralności kodu wymagają interpretacji. Dokumenty ownCloud INVALID_HASH, FILE_MISSING, i EXTRA_FILEjako odrębne warunki. Nie edytuj signature.json, aby ostrzeżenia zniknęły. Aktualna dokumentacja ownCloud 11 również wymaga podpisywania aplikacji innych firm w celu instalacji, aktualizacji i włączania. Zobacz dokumentację podpisywania kodu ownCloud .

8. Jak należy zweryfikować poprawkę?

Dobre odzyskiwanie to nie tylko „strona nie jest już biała”. Sprawdź całą ścieżkę żądania:

• Główna strona ownCloud zwraca oczekiwany status HTTP, a nie 500/502/503.
• Narzędzia dla programistów przeglądarek nie wykazują powtarzających się krytycznych błędów JavaScript ani brakujących pakietów podstawowych.
• Dziennik ownCloud nie rejestruje od razu nowego wyjątku krytycznego dla tego samego żądania.
• occ statusinformuje o zainstalowanej instancji i braku nieoczekiwanej konieczności uaktualnienia.
• Tryb konserwacji zostanie wyłączony po zakończeniu konserwacji.
• Użytkownik testowy może się zalogować i otworzyć stronę Pliki.

Dla ownCloud 11:

docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/

Podpis: Odzyskiwanie danych powinno zostać potwierdzone na obu warstwach: interfejs ownCloud ładuje się, a status po stronie serwera i kontrole HTTP pozostają prawidłowe.

Które rozwiązanie zapewnia najlepszy kompromis między ryzykiem a korzyściami?

Czego nie robić, gdy ownCloud wyświetla biały ekran

• Nie włączaj PHP display_errorsna publicznej stronie produkcyjnej tylko po to, aby udostępnić przeglądarce ślady stosu; zamiast tego korzystaj z dzienników serwera.
• Nie należy rekurencyjnie ustawiać całego drzewa ownCloud na uprawnienia umożliwiające zapis każdemu użytkownikowi.
• Nie należy obniżać wersji ownCloud w ramach szybkiego wycofania, chyba że przywracasz obsługiwaną kopię zapasową do kompatybilnego środowiska.
• Nie usuwaj katalogu danych, danych aplikacji, tabel bazy danych ani katalogów pamięci podręcznej w sposób losowy.
• Nie wyłączaj wszystkich aplikacji naraz, jeśli możesz odizolować tylko jedną aplikację.
• Nie edytuj podpisanych plików jądra ani nie signature.jsonedytuj ich w celu usunięcia błędów integralności.

Kiedy należy przyspieszyć proces zamiast kontynuować eksperymentowanie?

Zaprzestań wprowadzania zmian, gdy logi wskazują na uszkodzenie bazy danych, problemy z kluczem szyfrującym, powtarzające się błędy integralności rdzenia po czystym przywróceniu lub stan aktualizacji, którego nie można ukończyć za pomocą udokumentowanego przepływu pracy OCC. Należy również podjąć działania, gdy pusta strona wpływa na klaster produkcyjny i nie można wyizolować pojedynczego węzła bez narażania spójności danych.

Przed złożeniem zgłoszenia do pomocy technicznej ownCloud zaleca zebranie raportu konfiguracji i odpowiednich logów. W przypadku ownCloud 10.x udokumentowane polecenie to:

sudo -u www-data ./occ configreport:generate > config_report.txt

Użyj odpowiedniej metody wykonania OCC dla swojego wdrożenia i sprawdź dane wyjściowe pod kątem sekretów, zanim udostępnisz je poza swoją organizację. Przewodnik po zbieraniu logów i konfiguracji ownCloud wyjaśnia, czego zazwyczaj potrzebują inżynierowie wsparcia.

Oficjalne źródła

• Rozwiązywanie problemów ogólnych ownCloud Classic 11
• Wymagania systemowe ownCloud Classic 11
• Notatki o wydaniu serwera ownCloud
• Aktualizacja ręczna ownCloud Classic 11
• Konfiguracja rejestrowania ownCloud