Napraw błąd rozruchu Zimbra „Serwer LDAP nie odpowiada”: praktyczny przewodnik odzyskiwania danych

Gdy Zimbra ulega awarii podczas uruchamiania z błędem takim jak LDAP server not responding, ważne pytanie nie brzmi po prostu, jak sprawić, by komunikat zniknął. Prawdziwym celem jest przywrócenie prawidłowej zależności LDAP, potwierdzenie, że Zimbra może ponownie odczytać swoją konfigurację i uniknięcie zmiany niezwiązanych z nią usług, dopóki przyczyna problemu pozostaje nieznana.

Niniejszy przewodnik koncentruje się na tym właśnie efekcie. Wykorzystuje polecenia udokumentowane przez Zimbra dotyczące statusu usług, sprawdzania LDAP, konfiguracji lokalnej, weryfikacji certyfikatów i adresów URL LDAP dla wielu serwerów. W przykładach użyto nazw hostów zastępczych, takich jak ldap1.example.com;, które należy zastąpić wartościami z własnego wdrożenia.

Jak powinna wyglądać udana rekonwalescencja

Zanim cokolwiek zmienisz, określ linię mety. Naprawa jest przekonująca, gdy spełnione są wszystkie poniższe warunki:

• ldap statusraportuje uruchomiony slapdproces na węźle LDAP.
• zmcontrol statusraportuje, że LDAP i zależne usługi Zimbra działają na zainfekowanym hoście.
• Nazwa hosta LDAP jest rozwiązywana na oczekiwany adres z odpowiedniego węzła Zimbra.
• Skonfigurowany port LDAP jest osiągalny.
• Jeśli w grę wchodzi protokół TLS, łańcuch certyfikatów zostaje zweryfikowany, a poprzedni błąd TLS znika.
• W przypadku wdrożenia wieloserwerowego ldap_urlzawierają ldap_master_urlprawidłowe, aktywne hosty LDAP w zamierzonej kolejności.
• Po ponownym uruchomieniu /var/log/zimbra.lognie pojawiają się już powtarzające się błędy połączenia LDAP.

Jeśli jedno z tych sprawdzeń nadal się nie powiedzie, kontynuuj rozwiązywanie problemów na tej warstwie zamiast wielokrotnego ponownego uruchamiania całego stosu Zimbra.

Krótki przewodnik: objawy i następna kontrola

1. Sprawdź, czy sam protokół LDAP jest wyłączony

Uruchom sprawdzanie statusu jako zimbraużytkownik:

su - zimbra
zmcontrol status
ldap status

Dokumentacja Zimbra dotycząca rozwiązywania problemów z LDAP zaleca sprawdzenie, czy slapdproces faktycznie działa, a następnie potwierdzenie, że Zimbra go rozpoznaje ldap status. Jeśli LDAP nie działa lokalnie, należy zbadać proces LDAP przed rozpoczęciem rozwiązywania problemów ze skrzynką pocztową, MTA, serwerem proxy lub usługami internetowymi. LDAP jest podstawową zależnością konfiguracyjną, więc usługi podrzędne mogą ulec awarii po prostu dlatego, że nie mogą odczytać danych konfiguracyjnych.

Odnośnik: Dokumentacja rozwiązywania problemów z protokołem LDAP Zimbra i odnośnik do poleceń Zimbra zmcontrol .

2. Przed zmianą usług sprawdź adresy URL LDAP

Na dotkniętym węźle sprawdź lokalne punkty końcowe LDAP:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url

W dokumentacji wieloserwerowej Zimbra 10 ldap_urlidentyfikuje serwery LDAP, do których węzeł powinien wysyłać zapytania, a także ldap_master_urlidentyfikuje główny punkt końcowy lub zestaw głównych punktów używany do zapisu. Zimbra dokumentuje również, że adresy URL replik powinny zazwyczaj pojawiać się przed głównym punktem w ldap_url, a główny punkt powinien być zachowany na liście.

To sprawdzenie jest szczególnie ważne po migracji serwera, wymianie LDAP, renumeracji adresów IP, odzyskiwaniu po awarii lub aktualizacji kroczącej. Serwer LDAP działający w idealnym stanie nie jest w stanie pomóc węzłowi Zimbra, który nadal próbuje nawiązać połączenie z nieaktywną nazwą hosta.

Sprawdź rozpoznawanie nazw i dostępność TCP

getent hosts ldap1.example.com
nc -zv ldap1.example.com 389

Jeśli DNS zwraca nieprawidłowy adres, najpierw popraw rozpoznawanie nazw. Jeśli DNS jest poprawny, ale nie można nawiązać połączenia z portem, sprawdź routing sieciowy, zapory sieciowe hosta, grupy zabezpieczeń lub nasłuchiwacz demona LDAP. Nie zmieniaj haseł LDAP tylko dlatego, że połączenie TCP przekroczyło limit czasu; limit czasu występuje, zanim możliwe będzie sprawdzenie poświadczeń powiązania.

Aktualny podręcznik Zimbra v10 dotyczący obsługi wielu serwerów wyraźnie wymaga, aby węzły inne niż LDAP kontaktowały się z serwerem głównym LDAP podczas konfiguracji i stwierdza, że ​​instalacja nie może być kontynuowana, jeśli serwer jest niedostępny. Zobacz podręcznik instalacji Zimbra Daffodil v10 dla wielu serwerów .

3. Przeczytaj dziennik, zanim zdecydujesz, co naprawić

Aby zidentyfikować kategorię awarii, skorzystaj z centralnego dziennika Zimbra:

tail -n 100 /var/log/zimbra.log

Szukaj wzorca, a nie pojedynczej linii. Typowe kategorie obejmują przekroczenie limitu czasu połączenia, odmowę połączenia, błędy nazwy hosta, błędy powiązania lub błędy walidacji TLS. Kategoria ma znaczenie, ponieważ każdy z nich wymaga innej naprawy.

• Przekroczenie limitu czasu lub brak trasy: skup się na systemie DNS, routingu, zaporze sieciowej lub niedziałającym hoście.
• Połączenie odrzucone: host jest dostępny, ale na skonfigurowanym porcie nic nie akceptuje połączeń lub lokalna zapora aktywnie je odrzuca.
• Błąd walidacji TLS/SSL: zweryfikuj certyfikaty i łańcuchy zaufania.
• Błąd uwierzytelniania lub powiązania: dopiero wtedy sprawdź hasła LDAP i dane uwierzytelniające replikacji.

Kiedy certyfikaty stanowią problem

Zimbra udokumentowała przypadki, w których komunikacja LDAP nie powiodła się z powodu wygaśnięcia głównego lub pośredniego urzędu certyfikacji. Przydatnym poleceniem weryfikacyjnym dla certyfikatu komercyjnego jest:

/opt/zimbra/bin/zmcertmgr verifycrt comm   commercial.key commercial.crt commercial_ca.crt

Uruchom go z katalogu zawierającego odpowiednie pliki certyfikatów komercyjnych, zazwyczaj w katalogu /opt/zimbra/ssl/zimbra/commercial/. Jeśli walidacja się nie powiedzie, popraw łańcuch certyfikatów zamiast wyłączać weryfikację TLS jako skrót.

Odniesienie: Wskazówki Zimbra dotyczące wygasłego głównego urzędu certyfikacji i błędów protokołu LDAP TLS .

4. Popraw nieaktualne punkty końcowe LDAP dopiero po sprawdzeniu zamiennika

Jeśli skonfigurowana nazwa hosta jest nieaktualna, a zweryfikowałeś już prawidłowy aktywny serwer LDAP, zaktualizuj konfigurację lokalną jako zimbraużytkownik. Na przykład:

zmlocalconfig -e ldap_url="ldap://ldap1.example.com:389"
zmlocalconfig -e ldap_master_url="ldap://ldap1.example.com:389"

W przypadku wdrożenia z replikami należy użyć topologii udokumentowanej dla danego środowiska, zamiast ograniczać listę do jednego serwera. Dokumentacja Zimbra v10 zawiera przykłady, w których repliki są wyświetlane jako pierwsze do odczytu, a serwer główny pozostaje uwzględniony. Środowiska z wieloma serwerami głównymi mają własne wymagania dotyczące kolejności.

Nie kopiuj tych przykładowych adresów URL dosłownie. Najpierw sprawdź protokół, nazwę hosta, port i docelową rolę master/replika. Jeśli wdrożenie korzysta z LDAPS lub StartTLS, zachowaj projekt zabezpieczeń, zamiast bezmyślnie przełączać się na zwykły LDAP, aby zapewnić pomyślne uruchomienie.

5. Uruchom ponownie raz, a następnie sprawdź cały łańcuch zależności

Po usunięciu faktycznej przyczyny należy ponownie uruchomić Zimbrę:

zmcontrol restart

Następnie sprawdź:

ldap status
zmcontrol status

Ponowne uruchomienie, które jedynie zmienia komunikat o błędzie, nie wystarczy. Sprawdź ponownie /var/log/zimbra.log, czy nie występują powtarzające się awarie połączenia i przetestuj normalne operacje administracyjne lub użytkownika, odpowiednie dla roli serwera.

6. Środowiska wieloserwerowe wymagają dodatkowej kontroli replikacji

Jeśli używasz replik LDAP lub wielu serwerów głównych, serwer może być dostępny, nawet gdy replikacja jest nieprawidłowa. Zimbra dokumentuje narzędzie zmreplchkdo walidacji replikacji:

/opt/zimbra/libexec/zmreplchk

W przypadku systemów wielo-masterowych dokumentacja Zimbra opisuje prawidłowy wynik jako stan synchronizacji z kodem błędu 0. Dokładna procedura odzyskiwania danych zależy od tego, czy masz do czynienia z replikacją jedno-masterową, replikacją wielo-masterową czy też trwającą migracją.

Zobacz wskazówki dotyczące replikacji wieloserwerowej Zimbra LDAP i aktualną dokumentację wieloserwerową Zimbra 10 .

Kiedy zmienić kierunek rozwiązywania problemów

Przestań traktować to jako zwykły problem z łącznością, jeśli spełniony jest którykolwiek z poniższych warunków:

• slapdnie uruchomi się, mimo że nazwa hosta i konfiguracja portu są poprawne.
• Dziennik raportuje błędy zaplecza bazy danych lub magazynu danych LDAP, a nie błędy sieciowe.
• Replikacja nadal nie jest zsynchronizowana po przywróceniu połączenia.
• Hasła różnią się między serwerami głównymi i replikami LDAP po migracji.
• Nasłuchiwacz LDAP nie może nawiązać powiązania, ponieważ skonfigurowana nazwa hosta nie należy już do serwera.

W tym momencie problem może dotyczyć odzyskiwania bazy danych LDAP, danych uwierzytelniających replikacji, stanu migracji lub tożsamości serwera, a nie podstawowego stanu „serwer nie odpowiada”. Dokumentacja migracji Zimbry wyraźnie wskazuje, że DNS, niezgodność nazw hostów, nieprawidłowe hasła konfiguracji lokalnej i nieaktualne odwołania do starych serwerów LDAP mogą uniemożliwić uruchomienie LDAP.

Czego nie robić

• Nie usuwaj plików bazy danych LDAP na wczesnym etapie rozwiązywania problemu.
• Nie resetuj haseł LDAP dopóki nie udowodnisz, że uwierzytelnianie jest warstwą zawodną.
• Nie usuwaj adresu głównego z każdego adresu URL LDAP tylko dlatego, że odpowiada jedna replika.
• Nie wyłączaj weryfikacji TLS tylko po to, aby połączenie zostało nawiązane.
• Nie należy uruchamiać programu wielokrotnie zmcontrol restartbez przeczytania logów.

Ostateczna lista kontrolna odzyskiwania

• Nazwa hosta LDAP wskazuje na docelowego hosta.
• Port LDAP jest dostępny z poziomu węzła Zimbra, którego dotyczy problem.
• ldap_urli ldap_master_urldopasuj do bieżącej topologii.
• Łańcuch certyfikatu TLS jest ważny, jeśli używany jest szyfrowany protokół LDAP.
• ldap statusraporty slapdsą uruchamiane.
• zmcontrol statuspokazuje wymagane usługi uruchomione.
• Replikacja jest synchronizowana, gdy jest to możliwe.
• /var/log/zimbra.lognie pokazuje już powtarzających się błędów LDAP.

Głównym ograniczeniem tej procedury jest to, że „serwer LDAP nie odpowiada” jest objawem zależności, a nie pojedynczą przyczyną. Może to wynikać z niedziałającego procesu LDAP, nieaktualnych adresów URL, uszkodzonego DNS, zablokowanych portów, awarii certyfikatów, problemów z replikacją lub nieprawidłowych danych uwierzytelniających. Najbezpieczniejszym podejściem jest zatem sprawdzenie każdej warstwy po kolei i zmiana tylko tej, która uległa awarii.