Jeśli ownCloud wyświetla komunikat „Niepowodzenie kontroli integralności” po aktualizacji, najpierw otwórz ostrzeżenie administratora i sprawdź raport o nieprawidłowym pliku; nie edytuj signature.json, nie wyłączaj kontroli ani nie uruchamiaj aktualizacji bezmyślnie. Raport określa, czy problem dotyczy niezgodności plików głównych, brakującego lub dodatkowego pliku, czy też problemu z podpisem aplikacji. Przywróć tylko uszkodzony kod z dokładnej oficjalnej wersji lub zainstaluj kompatybilną podpisaną aplikację, a następnie ponownie przeskanuj system. To podejście dotyczy serwera ownCloud (wersja klasyczna); Infinite Scale korzysta z innej architektury i nie korzysta z tego occprzepływu pracy PHP dotyczącego integralności.
Na przykład, jeśli aktualizacja z jednej wersji punktowej 10.x do innej pozostanie index.phpi version.phpzostanie oznaczona jako INVALID_HASH, problem prawdopodobnie polega na tym, że niektóre pliki podstawowe nadal należą do innej wersji lub zostały zmienione. Jeśli tylko ręcznie zainstalowana aplikacja jest oznaczona jako brakująca w danych sygnatury, zastąpienie plików podstawowych nie rozwiąże problemu. Szczegóły błędu określają, która poprawka jest odpowiednia.
Przeczytaj raport przed zmianą plików
Zaloguj się jako administrator i otwórz żółty kod ostrzeżenia o integralności, a następnie wybierz link, aby wyświetlić listę nieprawidłowych plików. Dokumentacja ownCloud 10.16 opisuje ten raport i opcję ponownego skanowania strony administratora. Jeśli strona internetowa jest niedostępna, uruchom sprawdzanie w katalogu instalacyjnym ownCloud jako użytkownik serwera WWW:
sudo -u www-data ./occ integrity:check-core
sudo -u www-data ./occ integrity:check-app <appid>
Zastąp je www-datakontem używanym przez serwer WWW i <appid>identyfikatorem aplikacji widocznym w raporcie. W Dockerze wykonaj to samo occpolecenie w kontenerze ownCloud, używając standardowej metody wdrożenia. Polecenia sprawdzają pliki główne i nazwaną aplikację; w podręczniku ownCloud zaznaczono, że nie ma pojedynczego polecenia ręcznego skanującego każdą aplikację.
Użyj typu błędu, aby wybrać następną akcję:
INVALID_HASH: plik różni się od skrótu w swoim podpisie. Może to być częściowa lub mieszana aktualizacja wersji, edycja lokalna lub nieoczekiwana modyfikacja. Przed zastąpieniem pliku należy porównać go z dokładną oficjalną wersją.
FILE_MISSING: Brak podpisanego pliku. Przywróć go z odpowiedniego pakietu wydania; najpierw sprawdź, czy wdrożenie, pakowanie lub uprawnienia nie pominęły go.
EXTRA_FILE: Plik istnieje w podpisanym katalogu, ale nie jest częścią tego podpisu. Może to być pozostałość ze starszej wersji lub plik dodany lokalnie. Przed usunięciem należy zidentyfikować jego właściciela i cel.
EXCEPTION: dane podpisu mogą być nieobecne, nieprawidłowe, wykraczać poza zakres lub być powiązane z unieważnionym certyfikatem. W przypadku aplikacji sprawdź jej kod źródłowy i status wydania oraz poproś jej opiekuna o kompatybilną, podpisaną kompilację.
Ręcznie zainstalowana aplikacja innej firmy może legalnie wywołać ostrzeżenie, jeśli jest niepodpisana; ownCloud dokumentuje, że niepodpisane aplikacje zainstalowane poza Marketplace mogą pozostać oznaczone. Nie wyjaśnia to nieprawidłowego skrótu rdzenia. Podczas diagnostyki należy oddzielić wyniki aplikacji i rdzenia.
Naprawa niezgodności rdzenia z pasującym wydaniem
- Utwórz odzyskiwalną kopię zapasową. Przed wymianą plików serwera zachowaj bazę danych, konfigurację i dane zgodnie z procedurą tworzenia kopii zapasowych dla danego wdrożenia. Jeśli aktualizacja jest niekompletna lub usługa jest niestabilna, włącz tryb konserwacji i zatrzymaj ruch sieciowy przed naprawą. Nie traktuj kopii pliku jako substytutu kopii zapasowej bazy danych.
- Sprawdź, czy wersja ownCloud jest rzeczywiście uruchomiona. Sprawdź przegląd administratora i informacje o wersji na dysku. Upewnij się, że proces aktualizacji został zakończony i wszystkie węzły klastra lub kontenery działają w tej samej wersji docelowej. Przejrzyj dzienniki aktualizacji pod kątem przerwanej ekstrakcji, błędów uprawnień lub polecenia, które zostało przedwcześnie przerwane.
- Uzyskaj oficjalne archiwum dla tej konkretnej wersji. Nie używaj „najnowszego” archiwum, jeśli instancja znajduje się we wcześniejszej wersji punktowej. Wypakuj je do osobnego katalogu tymczasowego i porównaj tylko oznaczone ścieżki. Jeśli plik został zmodyfikowany przez dystrybucję lub narzędzia wdrożeniowe, zapoznaj się z tą modyfikacją przed jego zastąpieniem.
- Ostrożnie wymień uszkodzone pliki rdzenia. W przypadku potwierdzonych plików rdzenia skopiuj oficjalne wersje z odpowiedniego archiwum, zachowując konfigurację, dane i zgodne katalogi aplikacji instancji. Unikaj nakładania nowego archiwum serwera na stare drzewo bez przestrzegania instrukcji aktualizacji: resztki plików z poprzednich wersji mogą same powodować
EXTRA_FILEproblemy. Przywróć normalne prawa własności i uprawnienia, korzystając z udokumentowanej metody instalacji.
- Ponownie uruchom odpowiednie sprawdzenie. Użyj go
integrity:check-coredo ustalenia głównych ustaleń lub integrity:check-app <appid>dla jednej aplikacji. Możesz również skorzystać z funkcji ponownego skanowania na stronie administratora. Nie edytuj ani nie usuwaj ręcznie signature.json; to dane podpisu są potrzebne weryfikatorowi.
Wskazówki dotyczące podpisywania kodu ownCloud podają przykłady, takie jak przywrócenie poprawnego kodu index.phpz version.phparchiwum wydania, usunięcie zidentyfikowanego niepotrzebnego pliku dodatkowego oraz przywrócenie brakującego pliku .htaccessz oficjalnego archiwum tarball serwera. To tylko przykłady, a nie uniwersalna lista zastępstw: postępuj zgodnie z dokładnymi ścieżkami w swoim raporcie.
Obsługuj ostrzeżenia aplikacji bez ich maskowania
W przypadku aplikacji oznaczonej flagą po aktualizacji serwera, należy najpierw upewnić się, że obsługuje ona docelową wersję ownCloud. Wyłącz niekompatybilną aplikację za pomocą obsługiwanego administratora lub procedury wiersza poleceń, a następnie zainstaluj oficjalną, zgodną wersję z Marketplace lub od administratora aplikacji. Jeśli wcześniej podpisana aplikacja jest teraz niepodpisana lub jej certyfikat został uznany za unieważniony, skontaktuj się z administratorem w celu uzyskania poprawnie podpisanej wersji zastępczej. Nie kopiuj danych podpisu z innej aplikacji ani wersji; podpisy są powiązane z zawartością aplikacji i zakresem certyfikatu.
Jeśli oznaczona aplikacja jest aplikacją niestandardową, którą utrzymuje Twoja organizacja, autoryzowany opiekun aplikacji musi skompilować i podpisać wydanie, korzystając z odpowiedniego procesu i zaufanych danych uwierzytelniających. Administratorzy nie powinni tworzyć zastępczego podpisu, aby uniemożliwić dostęp do nieznanego lub zmodyfikowanego kodu. Jeśli nie możesz ustalić źródła ani integralności pliku, zachowaj raport i zbadaj go jako potencjalne zagrożenie bezpieczeństwa, zamiast pomijać ostrzeżenie.
Sprawdź naprawę
Ponownie uruchom odpowiednią kontrolę integralności i odśwież podgląd administratora. Upewnij się, że te same ścieżki nie pojawiają się już, ostrzeżenie dotyczące naprawionego komponentu zniknęło, a logi ownCloud nie wykazują żadnych nowych błędów aktualizacji ani uprawnień. Przetestuj logowanie, listę plików, przesyłanie i aplikację, której dotyczy problem. W przypadku wdrożenia wielowęzłowego sprawdź każdy węzeł; czysty wynik na jednym serwerze nie dowodzi, że wszystkie węzły używają zgodnego kodu.
Jeśli raport nadal występuje, przerwij zastępowanie plików i porównaj drzewo uruchomieniowe z dokładnym pakietem, obrazem wdrożenia lub zamontowanym woluminem dla tej wersji. Sprawdź, czy istnieje druga kopia kodu, nieaktualne podłączenia bindów, skrypt wdrożenia przywracający stare pliki lub lokalne poprawki. Zapoznaj się z instrukcjami dotyczącymi podpisywania kodu i integralności ownCloud 10.16 , instrukcjami aktualizacji ownCloud oraz dokumentacją przywracania , odpowiadającymi wersji . Strona dotyczy serwera ownCloud 10.16; wcześniejsze wersje mogą się różnić, dlatego wybierz dokumentację odpowiadającą zainstalowanej wersji.