Napraw pusty ekran Zimbra Webmail po wprowadzeniu danych uwierzytelniających

Jeśli Zimbra Webmail zaakceptuje nazwę użytkownika i hasło, ale następnie wyświetli pustą stronę, ekran ładowania lub pustą ramkę skrzynki pocztowej, potraktuj to jako błąd ładowania po zalogowaniu, dopóki nie potwierdzisz, że jest inaczej. Dane uwierzytelniające mogły zostać zaakceptowane, gdy klient webowy nie załadował interfejsu lub nie pobrał danych skrzynki pocztowej. Sam pusty ekran nie identyfikuje przyczyny i nie dowodzi uszkodzenia skrzynki pocztowej.

Przydatnym rezultatem jest powtarzalna diagnoza: określ, czy awaria dotyczy jednej przeglądarki, jednego użytkownika, jednego serwera pocztowego, czy wszystkich użytkowników; zidentyfikuj pierwsze nieudane żądanie lub wpis w dzienniku serwera; a następnie wprowadź najmniejszą zmianę, która pasuje do dowodów. Poniższe kroki oddzielają sprawdzanie przeglądarki od pracy administratora, dzięki czemu możesz ocenić, czy dostęp został faktycznie przywrócony przed zmianą konfiguracji serwera.

Najpierw sprawdź, co oznacza „puste po zalogowaniu”

Zanotuj, co dzieje się bezpośrednio po kliknięciu przycisku Zaloguj. Czy adres zmienia się na adres URL skrzynki pocztowej? Czy strona pozostaje biała, wyświetla się ikona, błąd usługi sieciowej lub wyświetla menu z pustą listą wiadomości? Czy inny użytkownik może zalogować się w tym samym czasie? Czy ten sam użytkownik nie loguje się w oknie przeglądarki prywatnej lub na innym urządzeniu?

Te szczegóły zawężają zakres błędu. Jeśli tylko jedna przeglądarka ulegnie awarii, lokalny stan przeglądarki lub rozszerzenie stają się bardziej prawdopodobne. Jeśli jedno konto ulegnie awarii w różnych przeglądarkach, podczas gdy inne konta działają, sprawdź skrzynkę pocztową, preferencje, udziały i dzienniki skrzynki pocztowej tego użytkownika. Jeśli wielu użytkowników jednocześnie ulegnie awarii, sprawdź usługę klienta internetowego, serwer proxy, mailboxd i ostatnie zmiany na serwerze. Są to wskazówki diagnostyczne, a nie dowód sam w sobie. Działanie: zapisz godzinę, konto lub konta, których dotyczy problem, przeglądarkę, dokładny ekran i informację, czy adres URL został zmieniony; nie uwzględniaj haseł ani plików cookie sesji.

Co użytkownik może bezpiecznie wypróbować?

1. Przetestuj okno prywatne lub inną obsługiwaną przeglądarkę

Otwórz adres URL Zimbra w oknie prywatnym lub incognito i zaloguj się raz. Jeśli to zadziała, tymczasowo wyłącz rozszerzenia przeglądarki, które modyfikują strony, skrypty, pliki cookie lub ustawienia prywatności, a następnie ponownie przetestuj profil standardowy. Wypróbuj drugą, bieżącą przeglądarkę dla porównania. Może to ujawnić problemy specyficzne dla profilu, ale nie rozwiązuje problemu po stronie serwera, który dotyczy wszystkich przeglądarek.

Działanie: porównaj to samo konto i sieć w oknie prywatnym i standardowej przeglądarce. Jeśli oba zawiodą w tym samym momencie, przerwij cykliczne przełączanie przeglądarek i wyślij administratorowi znacznik czasu i wynik.

2. Wyczyść tylko dane witryny Zimbra, jeśli test okna prywatnego zadziała

Nieaktualny plik cookie lub zasób klienta internetowego w pamięci podręcznej może spowodować niespójną sesję przeglądarki po aktualizacji serwera lub zmianie logowania. Jeśli okno prywatne działa, wyczyść pliki cookie i dane witryny z pamięci podręcznej tylko dla nazwy hosta Zimbra, a następnie ponownie otwórz witrynę i zaloguj się. Spowoduje to wylogowanie i może usunąć lokalne preferencje witryny, dlatego unikaj czyszczenia wszystkich danych przeglądarki, chyba że administrator Cię o to poprosi.

Działanie: sprawdź, czy znasz prawidłowy adres poczty internetowej i czy możesz wykonać wymagane logowanie wieloskładnikowe przed wyczyszczeniem danych. Jeśli pusta strona pojawi się ponownie w czystej sesji, zbierz dokładny czas i wersję przeglądarki; wielokrotne czyszczenie pamięci podręcznej prawdopodobnie nie pomoże.

3. Sprawdź, czy awaria jest związana z jednym kontem

Jeśli inni użytkownicy mogą otworzyć Zimbrę, ale jedno konto nie, zgłoś ten problem administratorowi. Strona rozwiązywania problemów Zimbry dotycząca zablokowanego ekranu po zalogowaniu omawia sprawdzanie logów skrzynki pocztowej i, w starszych przypadkach, sprawdzanie, czy początkowe przeszukanie skrzynki pocztowej w Skrzynce odbiorczej jest przyczyną problemu. Strona jest oznaczona jako „w trakcie realizacji”, a jej przykłady są nieaktualne; zmiana preferencji skrzynki pocztowej lub przeniesienie wiadomości nie jest uniwersalnym rozwiązaniem.

Działanie: poproś administratora o sprawdzenie błędów specyficznych dla konta przed zmianą preferencji, udziałów lub wiadomości. Nie usuwaj wiadomości e-mail ani folderów współdzielonych jako pierwszej odpowiedzi. Starszą procedurę można rozważyć tylko wtedy, gdy dzienniki i kontrolowany test wskazują na problem z ładowaniem skrzynki pocztowej, a administrator zarejestruje sposób przywrócenia pierwotnego ustawienia.

Co administrator Zimbra powinien sprawdzić w pierwszej kolejności?

Zacznij od czasu zdarzenia i zakresu, którego dotyczy problem, a następnie porównaj logowanie z logami Zimbra. Oficjalna strona Zimbra dotycząca rozwiązywania problemów z logowaniem, które się zacina, zaleca rozpoczęcie od logów mailbox.logi sprawdzenie innych istotnych logów. Lista odniesień do logów Zimbra zawiera /opt/zimbra/log/mailbox.log, audit.log, nginx.access.log, nginx.logi zmmailboxd.out, ostrzegając jednocześnie, że lokalizacja logów zależy od wdrożenia.

Na serwerze obsługującym problematyczne żądanie administrator może obserwować odpowiednie logi podczas odtwarzania problemu:

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

Używaj tylko ścieżek istniejących w Twoim wdrożeniu; w instalacji wieloserwerowej logi serwera proxy i skrzynki pocztowej mogą znajdować się na różnych hostach. Zatrzymaj śledzenie ruchu za pomocą Ctrl+C po jednym kontrolowanym odtworzeniu. Działanie: skoreluj jeden znacznik czasu z żądaniem klienta i sprawdź, czy uwierzytelnienie zakończyło się sukcesem, a następnie czy nastąpiło niepowodzenie żądania skrzynki pocztowej, serwera proxy lub klienta internetowego. Udostępniaj krótki, zredagowany fragment zamiast pełnego dziennika zawierającego dane osobowe.

Źródła: artykuł Zimbra dotyczący rozwiązywania problemów po zalogowaniu i odniesienie do pliku dziennika Zimbra .

Jak błędy serwera proxy i skrzynki pocztowej zmieniają diagnozę?

Jeśli użytkownicy łączą się z serwerem Zimbra za pośrednictwem serwera proxy Zimbra, należy sprawdzić logi serwera proxy oraz logi serwera pocztowego. W podręczniku rozwiązywania problemów z serwerem proxy Zimbra identyfikuje on nginx.logi nginx.access.logjako logi serwera proxy. Opisuje on odpowiedzi 502 i 503 jako awarie nadrzędne lub awarie usług; zgodnie z wytycznymi błąd 503 występuje zazwyczaj, gdy proces Jetty mailboxd jest niedostępny. Odpowiedź 5xx jest silniejszą wskazówką niż sama pusta strona, ale dokładne żądanie i host nadal mają znaczenie.

Działanie: znajdź pierwsze nieudane żądanie i jego kod odpowiedzi w dzienniku dostępu, a następnie dopasuj je jednocześnie do błędu serwera proxy i dziennika skrzynki pocztowej. Sprawdź rozpoznawanie nazw, dostępność sieci i stan konkretnego hosta skrzynki pocztowej tylko wtedy, gdy dzienniki wskazują na awarię routingu lub upstream. Unikaj ponownego uruchamiania każdej usługi Zimbra tylko dlatego, że jeden użytkownik zgłasza pustą stronę.

Aby sprawdzić stan usługi, administrator może skorzystać z narzędzia sterującego Zimbra:

su - zimbra
zmcontrol status

Status „Uruchomiony” nie gwarantuje, że każde żądanie klienta internetowego zakończy się sukcesem. Należy go używać jako jednego z punktów danych, obok statusu żądania i logów skrzynki pocztowej. Zapoznaj się z informacjami dotyczącymi rozwiązywania problemów z proxy Zimbra .

Kiedy jest to problem specyficzny dla danej wersji klienta internetowego?

Wiki Zimbry dokumentuje historyczne przypadki pustych stron po aktualizacjach do niektórych starszych wersji ZCS. W jednym z artykułów napisano, że rozwiązanie problemu rejestracji usług dotyczy ZCS 8.6 i 8.7.0/8.7.1 i wyświetla komunikaty 404 od klienta webowego. W innym artykule opisano oddzielny scenariusz z poprawkami do wersji 8.8.15 i 9.0.0, w którym wystąpiły błędy uruchamiania mailboxd i komunikaty 503. Są to szczegółowe przypadki specyficzne dla danej wersji, a nie ogólne instrukcje dla obecnych systemów Zimbra.

Nie kopiuj ich poleceń ani nie usuwaj plików serwera tylko dlatego, że objaw wygląda podobnie. Najpierw sprawdź dokładną wersję Zimbry, poziom poprawki, historię aktualizacji, odpowiedź HTTP i sygnaturę błędu opisaną w odpowiednim artykule. Wpisy w Wiki dotyczą starszych stron rozwiązywania problemów, a niektóre są oznaczone jako „praca w toku”. Działanie: jeśli sygnatura błędu i wersja są zgodne, poproś administratora Zimbry lub dostawcę pomocy technicznej o sprawdzenie rozwiązania w odniesieniu do zainstalowanej kompilacji przed wprowadzeniem zmian. Przejrzyj historyczny artykuł na pustej stronie i osobną sprawę mailboxd/Jetty pod kątem ich podanego zakresu.

Narzędzi programistycznych przeglądarki należy używać tylko wtedy, gdy dzienniki serwera nie dają jednoznacznych wyników

Administrator lub technik wsparcia może sprawdzić panele Sieć i Konsola przeglądarki podczas odtwarzania problemu. Sprawdź, czy występują nieudane zasoby JavaScript lub arkusze stylów, powtarzające się przekierowania, zablokowane żądania, ostrzeżenia o mieszanej zawartości oraz nieudane wywołania API lub SOAP. Pomyślne logowanie, po którym następuje błąd 404 dla zasobów klienta internetowego, wskazuje na inną warstwę niż błąd 502/503 z usługi pocztowej. Wyjątek JavaScript może wskazywać na awarię po stronie klienta, ale pierwszy widoczny błąd nie zawsze jest przyczyną problemu.

Działanie: zapisz ścieżkę nieudanego żądania, kod statusu, znacznik czasu i zredagowany komunikat konsoli. Nie udostępniaj niefiltrowanego pliku HAR, nagłówka autoryzacji, odpowiedzi logowania, zawartości skrzynki pocztowej ani pliku cookie: mogą one ujawnić dane uwierzytelniające aktywnej sesji i prywatne wiadomości. Jeśli każde żądanie zostanie pomyślnie zakończone, ale strona nadal będzie pusta, porównaj z inną przeglądarką i sprawdź, czy nie ma dostosowań po stronie klienta lub błędu specyficznego dla danej wersji.

Jak weryfikujesz naprawę?

Przetestuj wynik na użytkowniku, którego dotyczy problem, a w razie potrzeby na drugim koncie. Po zalogowaniu sprawdź, czy interfejs skrzynki pocztowej jest renderowany, foldery się ładują i pojawia się mały zestaw ostatnich wiadomości. Otwórz jedną wiadomość, przejdź do innego folderu i wyloguj się normalnie. Następnie powtórz w przeglądarce, która pierwotnie nie działała. W przypadku wdrożenia wieloserwerowego przetestuj za pośrednictwem publicznego adresu URL poczty internetowej, a nie tylko hosta skrzynki pocztowej.

Naprawa nie jest potwierdzona tylko dlatego, że formularz logowania zniknął. Strona powinna pozostać użyteczna po początkowym załadowaniu, a logi nie powinny już pokazywać tego samego nieudanego żądania. Jeśli ekran nadal jest pusty, wróć do dowodów: jeden użytkownik czy wielu, jedna przeglądarka czy wszystkie, jeden host skrzynki pocztowej czy wszystkie hosty, oraz które żądanie jako pierwsze zakończyło się niepowodzeniem. To podpowie, kiedy przejść od czyszczenia przeglądarki do sprawdzenia skrzynki pocztowej, serwera proxy lub konkretnej wersji.