Remediați ecranul gol al Zimbra Webmail după introducerea acreditărilor

Dacă Zimbra Webmail acceptă numele de utilizator și parola dvs., dar apoi afișează o pagină goală, un ecran de încărcare sau un cadru gol în cutia poștală, tratați acest lucru ca o eroare de încărcare post-autentificare până când puteți confirma contrariul. Este posibil ca datele de autentificare să fi fost acceptate în timp ce clientul web nu reușește să încarce interfața sau să preia datele din cutia poștală. Un ecran gol în sine nu identifică cauza și nu dovedește că cutia poștală este deteriorată.

Rezultatul util este un diagnostic repetabil: se stabilește dacă eroarea afectează un browser, un utilizator, un server de cutie poștală sau fiecare utilizator; se identifică prima solicitare eșuată sau intrare în jurnalul serverului; apoi se aplică cea mai mică modificare care corespunde dovezilor. Pașii de mai jos separă verificările browserului de munca administratorului, astfel încât să puteți evalua dacă accesul a fost recuperat efectiv înainte de a modifica configurația serverului.

Mai întâi, confirmați ce înseamnă „gol după autentificare”.

Înregistrați ce se întâmplă imediat după ce selectați Conectare. Adresa se schimbă în URL-ul cutiei poștale? Pagina rămâne albă, afișează o rotiță, o eroare de serviciu de rețea sau redă meniuri cu o listă de mesaje goală? Se poate conecta un alt utilizator în același timp? Același utilizator eșuează într-o fereastră privată de browser sau pe un al doilea dispozitiv?

Aceste detalii restrâng problema. Dacă doar un browser eșuează, este mai probabil ca starea browserului local sau o extensie să apară. Dacă un cont eșuează în mai multe browsere, în timp ce alte conturi funcționează, verificați cutia poștală, preferințele, partajările și jurnalele cutiei poștale ale utilizatorului respectiv. Dacă mai mulți utilizatori eșuează simultan, investigați serviciul client web, proxy-ul, mailboxd și modificările recente ale serverului. Acestea sunt indicii de diagnosticare, nu dovezi în sine. Acțiune: notați ora, contul sau conturile afectate, browserul, ecranul exact și dacă adresa URL s-a modificat; nu includeți parole sau cookie-uri de sesiune.

Ce poate încerca un utilizator în siguranță?

1. Testați o fereastră privată sau un alt browser acceptat

Deschideți adresa URL Zimbra într-o fereastră privată sau incognito și conectați-vă o dată. Dacă funcționează acolo, dezactivați temporar extensiile de browser care modifică paginile, scripturile, cookie-urile sau comportamentul de confidențialitate, apoi testați din nou profilul normal. Încercați un al doilea browser curent ca o comparație. Acest lucru poate dezvălui probleme specifice profilului, dar nu repară o problemă la server care afectează toate browserele.

Acțiune: comparați același cont și aceeași rețea în fereastra privată și în browserul obișnuit. Dacă ambele eșuează în același moment, opriți ciclul de navigare al browserelor și trimiteți administratorului marcajul temporal și rezultatul.

2. Ștergeți doar datele site-ului Zimbra dacă testul ferestrei private funcționează

Un cookie învechit sau un element web-client memorat în cache poate lăsa un browser cu o sesiune inconsistentă după o actualizare a serverului sau o modificare a conectării. Dacă fereastra privată funcționează, ștergeți cookie-urile și datele site-ului memorate în cache doar pentru numele de gazdă Zimbra, apoi redeschideți site-ul și conectați-vă. Această acțiune vă va deconecta și poate elimina preferințele site-ului local, așadar evitați să ștergeți toate datele browserului decât dacă administratorul vă solicită acest lucru.

Acțiune: verificați dacă știți adresa de e-mail web corectă și dacă puteți finaliza orice conectare multi-factor necesară înainte de a șterge datele. Dacă pagina goală reapare într-o sesiune curată, colectați ora exactă și versiunea browserului; ștergerea repetată a memoriei cache este puțin probabil să ajute.

3. Verificați dacă eroarea este cauzată de un singur cont

Dacă alți utilizatori pot deschide Zimbra, dar un cont nu, raportați acest domeniu administratorului. Pagina de depanare a problemelor Zimbra pentru un ecran blocat după conectare discută despre verificarea jurnalelor de cutie poștală și, în cazurile mai vechi, testarea dacă căutarea inițială a cutiei poștale în Inbox este declanșatorul. Pagina este marcată ca fiind în lucru, iar exemplele sale sunt vechi; modificarea unei preferințe pentru cutia poștală sau mutarea e-mailurilor nu reprezintă o soluție universală.

Acțiune: solicitați administratorului să verifice erorile specifice contului înainte de a modifica preferințele, partajările sau mesajele. Nu ștergeți e-mailurile și nu eliminați folderele partajate ca primă intervenție. Procedura mai veche poate fi luată în considerare numai atunci când jurnalele și un test controlat indică o problemă de încărcare a cutiei poștale, iar administratorul înregistrează modul de restaurare a setării originale.

Ce ar trebui să verifice mai întâi administratorul Zimbra?

Începeți cu ora evenimentului și domeniul de aplicare afectat, apoi corelați conectarea cu jurnalele Zimbra. Pagina oficială de depanare Zimbra pentru o conectare care rămâne blocată recomandă începerea cu mailbox.logși apoi verificarea altor jurnale relevante. Referința jurnalelor Zimbra listează /opt/zimbra/log/mailbox.log, audit.log, nginx.access.log, nginx.log, și zmmailboxd.out, avertizând în același timp că locațiile jurnalelor depind de implementare.

Pe serverul care gestionează solicitarea afectată, un administrator poate urmări jurnalele relevante în timp ce reproduce problema:

su - zimbra
tail -f /opt/zimbra/log/mailbox.log /opt/zimbra/log/nginx.access.log /opt/zimbra/log/nginx.log

Folosiți doar căile existente în implementarea dvs.; într-o instalare cu mai multe servere, jurnalele proxy și ale cutiei poștale pot fi pe gazde diferite. Opriți jurnalul live cu Ctrl+C după o reproducere controlată. Acțiune: corelați o marcă temporală cu solicitarea clientului și căutați o autentificare reușită urmată de o solicitare eșuată la o cutie poștală, proxy sau client web. Partajați un extras scurt, redactat, în loc de un jurnal complet care conține date personale.

Surse: Articolul Zimbra despre depanarea după autentificare și referința fișierului jurnal Zimbra .

Cum modifică erorile proxy și ale cutiei poștale diagnosticul?

Dacă utilizatorii accesează Zimbra prin intermediul Zimbra Proxy, verificați jurnalele proxy, precum și jurnalele serverului de cutie poștală. Referința de depanare a proxy-ului de la Zimbra identifică nginx.logși nginx.access.logca jurnale proxy. Aceasta descrie răspunsurile 502 și 503 ca ​​fiind erori în amonte sau de serviciu; instrucțiunile sale spun că un răspuns 503 apare de obicei atunci când procesul Jetty mailboxd nu este disponibil. Un răspuns 5xx este un indiciu mai puternic decât o pagină goală în sine, dar solicitarea exactă și gazda contează în continuare.

Acțiune: localizați prima solicitare eșuată și codul de răspuns al acesteia în jurnalul de acces, apoi potriviți-o simultan cu jurnalul de erori proxy și cu jurnalul de cutie poștală. Verificați rezoluția numelui, accesibilitatea rețelei și starea de funcționare a gazdei specifice a cutiei poștale numai atunci când jurnalele indică o eroare de rutare sau de upstream. Evitați repornirea fiecărui serviciu Zimbra doar pentru că un utilizator raportează o pagină goală.

Pentru a verifica starea serviciului, un administrator poate utiliza utilitarul de control Zimbra:

su - zimbra
zmcontrol status

O stare „În rulare” nu garantează că fiecare solicitare a clientului web va avea succes. Folosiți-o ca un singur punct de date alături de starea solicitării și jurnalele cutiei poștale. Consultați referința de depanare a proxy-ului Zimbra .

Când este vorba de o problemă specifică versiunii clientului web?

Wiki-ul Zimbra documentează cazurile istorice de pagini goale după actualizări la anumite versiuni mai vechi de ZCS. Un articol spune că remediul său pentru înregistrarea serviciilor se aplică la ZCS 8.6 și 8.7.0/8.7.1 și arată răspunsuri 404 de la clientul web. Un altul documentează un scenariu separat de patch 8.8.15 și 9.0.0 cu erori de pornire mailboxd și răspunsuri 503. Acestea sunt cazuri specifice versiunii, nu instrucțiuni generale pentru sistemele Zimbra actuale.

Nu copiați comenzile lor și nu ștergeți fișierele serverului doar pentru că simptomul pare similar. Mai întâi confirmați versiunea exactă de Zimbra, nivelul patch-ului, istoricul actualizărilor, răspunsul HTTP și semnătura de eroare descrise în articolul relevant. Intrările wiki sunt pagini de depanare vechi, iar unele sunt marcate ca „în lucru”. Acțiune: dacă semnătura de eroare și versiunea se potrivesc, rugați un administrator Zimbra sau un furnizor de asistență să valideze remedierea în raport cu versiunea instalată înainte de a face modificări. Consultați articolul istoric cu pagina goală și cazul separat mailboxd/Jetty pentru a vedea domeniul lor de aplicare declarat.

Folosește instrumentele pentru dezvoltatori de browser doar atunci când jurnalele serverului sunt neconcludente

Un administrator sau un tehnician de asistență poate inspecta panourile Rețea și Consolă ale browserului în timp ce reproduce problema. Căutați resurse JavaScript sau foi de stil eșuate, redirecționări repetate, solicitări blocate, avertismente privind conținutul mixt și apeluri API sau SOAP eșuate. O conectare reușită urmată de o eroare 404 pentru resursele clientului web indică un strat diferit de un strat 502/503 din serviciul de cutie poștală. O excepție JavaScript poate identifica o eroare la nivelul clientului, dar prima eroare vizibilă nu este întotdeauna cauza principală.

Acțiune: înregistrați calea solicitării eșuate, codul de stare, marcajul temporal și un mesaj de consolă redactat. Nu partajați un fișier HAR nefiltrat, un antet de autorizare, un răspuns de conectare, conținutul cutiei poștale sau un cookie: acestea pot expune acreditările sesiunii active și mesajele private. Dacă fiecare solicitare returnează cu succes, dar pagina este încă goală, comparați cu un alt browser și verificați dacă există personalizări la nivelul clientului sau un defect specific versiunii clientului web.

Cum verifici reparația?

Testați rezultatul cu utilizatorul afectat și, dacă este cazul, cu un al doilea cont. După conectare, confirmați că interfața cutiei poștale se afișează, folderele se încarcă și apare un set mic de mesaje recente. Deschideți un mesaj, navigați la un alt folder și deconectați-vă normal. Apoi repetați procesul în browserul care a eșuat inițial. Pentru o implementare pe mai multe servere, testați prin adresa URL publică de webmail, nu doar de la gazda cutiei poștale.

O reparație nu este confirmată doar pentru că formularul de conectare dispare. Pagina ar trebui să rămână utilizabilă după încărcarea inițială, iar jurnalele nu ar trebui să mai afișeze aceeași solicitare eșuată. Dacă ecranul este încă gol, reveniți la dovezi: un utilizator sau mai mulți, un browser sau toți, o gazdă de cutie poștală sau fiecare gazdă și care solicitare eșuează prima. Aceasta vă va spune când să treceți de la curățarea browserului la investigarea cutiei poștale, a proxy-ului sau a versiunii.