Service Not Available The GUI Service is temporarily unavailable. Refresh browser to try again. If the problem persists, contact Dell EMC support for assistance.
Pierwszy element jest łatwy do wyjaśnienia.
Aby sprawdzić, czy drugi element ma zastosowanie, należy zapoznać się z listą zaufanych hostów w DD:
# adminaccess trust show Subject Type Valid From Valid Until Fingerprint ---------------------- ---------- ------------------------ ------------------------ ----------------------------------------------------------- dd-upgraded-7.7.2.x trusted-ca Tue Jul 6 15:36:35 2021 Mon Jul 5 15:36:35 2027 BA:59:F0:6E:93:47:02:7C:6C:C1:39:71:46:6D:1F:2B:81:09:E9:46 dd-trusted-1 trusted-ca Mon Feb 7 10:26:48 2011 Thu Jan 30 10:26:48 2042 7B:96:6B:06:D9:A4:6A:B1:A0:3A:4C:E7:12:28:07:AD:29:F3:8E:F2 dd-trusted-2 trusted-ca Mon Aug 21 10:18:52 2017 Thu Aug 13 10:18:52 2048 16:BC:09:02:F5:39:CB:EC:C2:A8:9E:5D:21:90:19:38:2B:36:47:EA ---------------------- ---------- ------------------------ ------------------------ -----------------------------------------------------------
W takim przypadku „dd-upgraded-7.7.2.x” to ten, który ma awarię interfejsu użytkownika, a pozostałe dwa to zaufane systemy DD (ponieważ mają ustawione konteksty replikacji z lokalnym DD). Certyfikat DD używany do zaufania jest „ważny od” daty instalacji, o ile nie zostanie odnowiony później. W powyższych danych wyjściowych najbardziej prawdopodobnym kandydatem do uruchomienia starej wersji DDOS 4.7–5.4 jest „dd-trusted-1”.
Zaloguj się do tego DD i sprawdź go (lub poszukaj sekcji „Historia aktualizacji systemu” w ASUP):
# system upgrade history Version Partition State Time Package Number --------------- --------- ------- ----------------- ------------ 5.1.0.5-269447 1 INSTALL 12/29/11 01:02:59 5.1.0.9-282511 2 UPGRADE 02/07/12 13:31:42 ddr 5.4.5.0-477080 1 UPGRADE 05/04/15 10:22:42 ddr 5.5.4.10-536339 2 UPGRADE 04/17/18 08:51:19 ddr 5.7.5.0-569395 1 UPGRADE 04/17/18 09:41:17 ddr --------------- --------- ------- ----------------- ------------
W tych danych wyjściowych „dd-trusted-1” jest zgodny z elementem 2 i prawdopodobnie ma nieprawidłowy certyfikat, co powoduje, że host DD „dd-upgraded-7.7.2.x” nie ładuje interfejsu użytkownika za pośrednictwem ich relacji zaufania.
Aby potwierdzić trzeci element (jeśli dzienniki błędów interfejsu użytkownika DD dotyczą tego konkretnego problemu), uruchom następujące polecenie, aby otworzyć plik dziennika „em.info”:
# log view debug/sm/em.info
Wyszukaj (użyj ukośnika) dla tych dzienników:
05 Jul 2022 13:57:38,737 INFO [main] Reloading the certificate stores for the system 05 Jul 2022 13:57:38,899 ERROR [main] Exception during command execution: java.security.cert.CertificateException - Invalid X.509 Certificate version., will retry, Attempt# 1 05 Jul 2022 13:57:39,001 ERROR [main] Exception during command execution: java.security.cert.CertificateException - Invalid X.509 Certificate version., will retry, Attempt# 2 05 Jul 2022 13:57:39,103 ERROR [main] Exception during command execution: java.security.cert.CertificateException - Invalid X.509 Certificate version., will retry, Attempt# 3
Najszybszym sposobem obejścia problemu jest usunięcie zaufania między wszystkimi hostami DD, które w przeszłości korzystał z DDOS w wersji 4.7–5.4, tak aby w przypadku utworzenia nieprawidłowego certyfikatu nie powodowały już awarii ładowania lokalnego interfejsu użytkownika DD. Kontynuując z tym przykładem, można powiedzieć, że dd-trusted-1 jest jedynym zaufanym systemem DD, który kiedykolwiek działał w wersji DDOS 5.7–5.4. Aby usunąć wzajemne zaufanie (ten DD ufający dd-trusted-1 i odwrotnie) z systemu DD z wadliwym interfejsem użytkownika, należy wykonać poniższe czynności.
# adminaccess trust del host dd-trusted-1 type mutual
Usunięcie zaufania powoduje awarię konfiguracji replikacji z niezaufanym DD do momentu przywrócenia zaufania. Jeśli usunięcie zaufania nie powiedzie się, ponieważ zdalny DD nie jest już osiągalny lub w ogóle nie istnieje, powtórz polecenie bez opcji „mutual”, aby usunąć zaufanie tylko lokalnie, ponieważ w takiej sytuacji to wystarczy, aby interfejs użytkownika zadziałał ponownie.
W przypadkach, w których zaufany DD jest nadal używany i musimy zachować relację zaufania, należy utworzyć nowy certyfikat CA:
# adminaccess certificate generate self-signed-cert regenerate-ca
Na koniec włącz i wyłącz usługę internetową na dowolnym z urządzeń, których dotyczy problem:
# adminaccess disable https # adminaccess enable https
Jeśli po wykonaniu powyższych czynności interfejs użytkownika DD nadal nie działa, skontaktuj się z działem pomocy technicznej DELL Data Domain.
Aby przywrócić zaufanie, należy najpierw upewnić się, że certyfikat CA DD w „dd-trusted-1” został utworzony ponownie bez żadnych błędów. W tym wierszu polecenia hosta należy wykonać poniższe polecenie i postępować zgodnie z wyświetlanymi instrukcjami:
# adminaccess certificate generate self-signed-cert regenerate-ca
Jeśli ten DD ma zaufanie ustanowione z innymi systemami DD lub replikacją, należy usunąć, a następnie ponownie dodać zaufanie dla wszystkich takich równorzędnych systemów.
Na koniec, aby ponownie dodać zaufanie między „dd-upgraded-7.7.2.x” i „dd-trusted-1”, należy wykonać jedną z poniższych czynności: