Un „ecran alb al morții” din ownCloud este un simptom, nu un diagnostic. Cea mai bună soluție depinde de faptul dacă browserul a primit o eroare de server, a primit HTML valid, dar nu a reușit să încarce JavaScript sau CSS, sau a ajuns la un proxy invers care nu a putut ajunge deloc la ownCloud.
Această distincție este importantă deoarece compromisurile sunt foarte diferite. Dezactivarea unei aplicații terțe prezintă un risc relativ scăzut atunci când o excepție PHP denumește aplicația respectivă. Schimbarea proprietarului fișierului pe întreaga instalare este mult mai invazivă și nu ar trebui să fie primul răspuns la o eroare JavaScript. De asemenea, repornirea fiecărui serviciu poate ascunde pentru scurt timp o problemă fără a vă spune dacă provine de la PHP, un proxy, o actualizare sau o aplicație.
Acest ghid prezintă ownCloud Classic. Conform documentației actuale ownCloud Classic 11, versiunea 11 este acceptată ca implementare bazată pe Docker, cu sistemul de operare, runtime-ul PHP, baza de date și Apache în containerele furnizate de ownCloud. Instalările 10.x mai vechi pot utiliza în continuare un server web tradițional și un layout PHP-FPM. Utilizați ramura de comandă care corespunde implementării dvs. Consultați cerințele de sistem pentru ownCloud Classic 11 .
Deschideți instrumentele pentru dezvoltatori din browser și inspectați ambele file, Rețea și Consolă . Testați și endpoint-ul dintr-un terminal:
curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/
Legendă: Un răspuns 500 pe partea de server indică spre ownCloud, PHP, baza de date sau stiva web, mai degrabă decât spre o simplă problemă de randare a browserului.
Dacă documentul principal returnează 500 sau 502/503 , acordați prioritate jurnalelor de server și proxy. Dacă documentul principal returnează 200 , dar pachetele JavaScript eșuează cu excepții 404, 403 sau de script, acordați prioritate căilor de resurse, rescrierea reverse-proxy, temelor, memoriei cache sau compatibilității aplicațiilor. Dacă este afectat un singur browser, testați o fereastră privată și un alt browser acceptat înainte de a schimba serverul.
Aceasta este una dintre cele mai importante întrebări, deoarece poate restrânge imediat domeniul erorilor. Notele de lansare actuale ale ownCloud precizează că ownCloud Classic 11 a ridicat versiunea minimă PHP la PHP 8.3, iar ownCloud Classic 11 este disponibil doar pentru Docker. O instalare ownCloud 10.x veche respectă reguli de compatibilitate PHP diferite, așa că nu copiați sfaturile PHP dintr-o altă versiune majoră.
Pentru o instalare tradițională ownCloud 10.x, executați comanda din directorul ownCloud:
sudo -u www-data ./occ status
php -vPentru ownCloud Classic 11, rulați OCC prin implementarea Compose:
docker compose exec owncloud occ status
docker compose exec owncloud php -v
Legendă: Verificarea versiunilor instalate de ownCloud și PHP este deosebit de importantă atunci când ecranul alb a apărut imediat după o actualizare.
Comparați rezultatul cu notele de lansare pentru versiunea pe care o utilizați efectiv. Notele oficiale de lansare de la ownCloud sunt sursa corectă pentru versiunile minime actuale și modificările importante. O versiune inferioară nu este o soluție generică sigură: documentația ownCloud avertizează că downgrade-ul nu este acceptat deoarece poate corupe datele.
Jurnalele sunt de obicei mai utile decât modificările de configurație prin încercări și erori. Manualul de administrare ownCloud recomandă jurnalul ownCloud pentru diagnosticarea problemelor; în mod implicit, jurnalul este stocat în directorul de date configurat, cu excepția cazului în care logfileeste setat un alt parametru.
Într-o instalație tradițională, exemplele includ:
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"Pe ownCloud Classic 11, inspectați în schimb serviciile Compose:
docker compose logs --tail=200 owncloud
docker compose ps
Legendă: O eroare fatală PHP sau o urmărire a stivei care denumește o aplicație sau o clasă oferă o țintă de depanare mult mai sigură decât modificarea setărilor serverului fără legătură.
Căutați prima excepție fatală în urma solicitării eșuate, nu doar cascada finală de erori. Categoriile comune includ o clasă PHP lipsă, o aplicație incompatibilă, o eroare de conexiune la baza de date, o configurație ilizibilă, fișiere de cod lipsă sau o excepție în timpul unei actualizări neterminate.
Documentația de înregistrare în jurnal a ownCloud precizează că înregistrarea în jurnal DEBUG poate fi utilă în timpul diagnosticării, dar produce un rezultat substanțial și poate afecta performanța. Dacă creșteți temporar nivelul de înregistrare în jurnal, reveniți la o valoare mai puțin detaliată după colectarea dovezilor. Consultați configurația de înregistrare în jurnal a ownCloud .
Alegeți această cale atunci când eroarea denumește o aplicație non-core, când pagina goală a început după instalarea sau actualizarea unei aplicații sau când eroarea a apărut în timpul unei actualizări ownCloud. Ghidul de depanare ownCloud recomandă în mod explicit dezactivarea aplicațiilor terțe pentru depanare și înainte de actualizări.
Enumerați aplicațiile mai întâi. Pe ownCloud 10.x:
sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_IDPe ownCloud 11:
docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID
Legendă: Dezactivarea doar a aplicației implicate de jurnale este mai puțin perturbătoare decât dezactivarea mai multor componente sau modificarea întregului web stack.
Compromisul este funcționalitatea: utilizatorii pierd aplicația respectivă până când aceasta este actualizată sau reactivată. Acest lucru este de obicei preferabil dezactivării serviciilor de bază ownCloud. Documentația OCC menționează, de asemenea, că mai multe aplicații de bază nu pot fi dezactivate, inclusiv DAV, FederatedFileSharing, Files și Files_External. Consultați ghidul oficial general de depanare și referința comenzilor OCC .
Permisiunile sunt o suspiciunea puternică atunci când jurnalul conține Permission deniedfișiere de aplicație/configurare copiate de o implementare recentă cu utilizatorul greșit sau fișiere înlocuite de un upgrade cu proprietar incorect. Sunt o suspiciunea slabă atunci când singura dovadă este o eroare JavaScript din partea browserului.
Puneți sistemul în modul de întreținere înainte de efectuarea unor reparații care nu vă permit să le reparați. Pentru ownCloud 11:
docker compose exec owncloud occ maintenance:mode --onPentru o implementare tradițională 10.x:
sudo -u www-data ./occ maintenance:mode --on
Legendă: Modul de întreținere reduce activitatea utilizatorilor în timp ce investigați erorile de proprietate sau de permisiuni ale fișierelor care sunt deja susținute de dovezile din jurnal.
Nu rulați chmod 777rețete generale de permisiuni recursive sau de copiere dintr-o versiune fără legătură. Manualul actual ownCloud 11 documentează proprietatea și modurile specifice pentru fișierele adăugate manual în directoarele montate pe Docker appsși : ownership , app files , app directores și fișierele de configurare adăugate . De asemenea, documentează și pentru cele modificate manual și . Folosiți documentația de actualizare manuală ownCloud 11 ca referință specifică versiunii.configwww-data:root0644075106440640.htaccess.user.ini
Numai atunci când jurnalele sau verificările de compatibilitate indică acolo. Această cale are o rază de declanșare mai mare decât dezactivarea unei aplicații defecte. O extensie PHP obligatorie lipsă poate împiedica rularea codului, în timp ce o configurație PHP incorectă poate afecta fiecare aplicație PHP de pe gazdă.
Pentru o stivă PHP moștenită gestionată de gazdă, verificați ce încarcă de fapt runtime-ul web:
php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable
Legendă: Verificările modulelor PHP și OPcache sunt utile atunci când jurnalele serverului denumesc extensii lipsă sau incompatibilitate la runtime, dar nu ar trebui să fie prima modificare fără dovezi.
Pentru ownCloud 11, imaginea oficială gestionează runtime-ul PHP, așadar schimbarea pachetelor PHP gazdă este, în general, stratul greșit. ownCloud documentează OPcache ca fiind activat în mod implicit în imaginea sa Docker. Consultați documentația ownCloud pentru memorarea în cache a memoriei .
Dacă suspectați existența unui OPcache învechit după înlocuirea manuală a fișierelor PHP pe o instalare veche, repornirea PHP-FPM sau a serviciului web/PHP relevant poate goli memoria cache a codului de operare local al procesului. Compromisul este o scurtă întrerupere și performanța cold-cache ulterioară. Faceți acest lucru după corectarea fișierelor subiacente, nu ca un substitut pentru identificarea erorii.
Dacă pagina albă a apărut în timpul sau imediat după o actualizare, verificați mai întâi starea actualizării. Documentația proprie de actualizare a ownCloud recomandă utilizarea OCC pentru calea de actualizare și reparare, în loc să manipulați manual baza de date.
Pentru 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-corePentru ownCloud 10.x, utilizați comenzile OCC echivalente sub utilizatorul serverului web:
sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core
Legendă: Repararea OCC este potrivită pentru o actualizare întreruptă sau inconsistentă, în timp ce verificările de integritate pot identifica fișiere de bază semnate modificate sau lipsă.
Rezultatele privind integritatea codului necesită interpretare. Documentele ownCloud INVALID_HASH, FILE_MISSING, și EXTRA_FILEca condiții distincte. Nu editați signature.jsonpentru a face avertismentele să dispară. Documentația actuală ownCloud 11 impune, de asemenea, semnarea aplicațiilor terțe pentru instalare, actualizări și activare. Consultați documentația de semnare a codului ownCloud .
O recuperare bună nu înseamnă doar „pagina nu mai este albă”. Verificați întreaga cale a solicitării:
occ statusraportează o instanță instalată și nicio cerință de upgrade neașteptată.Pentru ownCloud 11:
docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/
Legendă: Recuperarea ar trebui confirmată la ambele niveluri: interfața ownCloud se încarcă, iar starea serverului și verificările HTTP rămân sănătoase.
| Dovezi pe care le aveți | Cea mai bună primă alegere | Compromis |
|---|---|---|
| Doar un browser afișează pagina goală | Fereastră privată, al doilea browser acceptat, consolă de browser | Cel mai mic risc; nu rezolvă o eroare reală a serverului dacă toți utilizatorii sunt afectați |
| Documentul principal este HTTP 500 | jurnalele ownCloud, PHP/container, server web și bază de date | Cea mai rapidă cale către cauza principală; necesită acces la jurnalul shell-ului sau al platformei |
| Eroarea denumește o aplicație terță parte | Dezactivează doar aplicația respectivă cu OCC | De obicei, risc operațional scăzut, dar funcționalitatea aplicației respective este temporar indisponibilă |
| Problema a început imediat după actualizare | Verificați matricea versiunilor acceptate, starea actualizării, compatibilitatea aplicației, repararea OCC | Mai controlat decât revenirea la versiunea inițială; poate necesita o fereastră de întreținere |
| Jurnalele spun Permisiune refuzată după copiarea fișierelor | Corectați doar proprietatea/modurile documentate pentru versiunea afectată | Precizie atunci când există dovezi; modificările recursive generale ale permisiunilor pot crea probleme de securitate și de actualizare |
| Verificarea integrității nucleului raportează fișiere modificate/lipsă | Restaurați fișierele de lansare corecte sau urmați procedura de actualizare/restaurare acceptată | Păstrează integritatea; evită aplicarea manuală a multor fișiere de bază la locul lor |
| HTTP 200, dar JS/CSS eșuează | Rețea/Consola browserului, căi proxy, resurse temă/aplicație, memorie cache | Evită modificările inutile ale bazei de date/PHP; poate necesita acces la configurația proxy |
display_errorspe un site de producție public doar pentru a expune urmele stivei browserului; folosiți în schimb jurnalele serverului.signature.jsondoar pentru a suprima erorile de integritate.Opriți efectuarea modificărilor atunci când jurnalele indică coruperea bazei de date, probleme ale cheii de criptare, erori repetate de integritate a nucleului după o restaurare curată sau o stare de actualizare care nu poate fi finalizată cu fluxul de lucru OCC documentat. De asemenea, escaladați problema atunci când pagina goală afectează un cluster de producție și nu puteți izola un singur nod fără a risca consecvența datelor.
Înainte de a deschide un caz de asistență, ownCloud recomandă colectarea unui raport de configurare și a jurnalelor relevante. Pentru ownCloud 10.x, comanda documentată este:
sudo -u www-data ./occ configreport:generate > config_report.txtFolosește metoda de execuție OCC corespunzătoare implementării tale și examinează rezultatul pentru secrete înainte de a-l partaja în afara organizației tale. Ghidul ownCloud pentru colectarea jurnalelor și a configurației explică de ce au nevoie de obicei inginerii de asistență.
Remediați o eroare a bazei de date Nextcloud WebGUI după o actualizare prin verificarea jurnalelor, finalizarea actualizării occ, repararea problemelor schemei și verificarea stării bazei de date.
Remediați avertismentul ownCloud Apache AllowOverride All prin configurarea directorului corect, testarea Apache, reîncărcarea în siguranță și verificarea protecției .htaccess.
Aflați cum să identificați, să arhivați, să comprimați și să eliminați jurnalele de audit Zimbra vechi, când să evitați trunchierea audit.log și cum să verificați dacă spațiul pe disc și jurnalele se recuperează corect.
Remediați o pagină goală din ownCloud separând erorile de browser, PHP, aplicație, permisiuni, upgrade și proxy, apoi alegeți calea de recuperare cu cea mai puțină perturbare.
Diagnosticați vârfurile de solicitare a procesorului browserului Jitsi Meet și reduceți încărcarea clientului verificând dalele video, efectele camerei, grafica browserului și setările gazdei.
Urmărește starea de funcționare a Jitsi Videobridge, încărcarea conferințelor și traficul cu ajutorul endpoint-ului Prometheus încorporat, apoi explorează și prezintă datele în grafic în Grafana.
Configurați un domeniu personalizat pentru Jitsi Meet Docker cu DNS, PUBLIC_URL, HTTPS, Let's Encrypt, porturi firewall, setări NAT și verificare end-to-end.
Remediați erorile 404 din consola de administrare Zimbra după reînnoirea SSL verificând adresa URL și portul corecte, rutarea proxy, starea serviciului, certificatele implementate și jurnalele.
Învață cum să diagnostichezi și să remediezi avertismentul de configurare PHP OPcache din Nextcloud verificând setările SAPI PHP active, limitele de dimensionare, comentariile și revalidarea.
Depanați erorile de migrare a bazei de date Kopano după o actualizare MySQL sau MariaDB verificând copiile de rezervă, versiunile serverului, modurile SQL, setul de caractere, starea schemei și jurnalele.
