Service Not Available The GUI Service is temporarily unavailable. Refresh browser to try again. If the problem persists, contact Dell EMC support for assistance.
Punkt 1 ist selbsterklärend.
Um festzustellen, ob Punkt 2 zutrifft, rufen Sie die Liste der vertrauenswürdigen Hosts in der DD ab:
# 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 ---------------------- ---------- ------------------------ ------------------------ -----------------------------------------------------------
In diesem Fall ist „dd-upgraded-7.7.2.x“ die DD, bei der die UI fehlschlägt, und die anderen beiden sind die vertrauenswürdigen DDs (da sie über Replikationskontexte mit der lokalen DD verfügen). Wenn es nicht später erneut erzeugt wird, ist ein DD-Zertifikat, das für die Vertrauensstellung verwendet wird, ab dem Installationsdatum gültig. In der obigen Ausgabe ist der wahrscheinlichste Kandidat für die Ausführung einer alten DDOS 4.7- bis 5.4-Version „dd-trusted-1“.
Melden Sie sich bei dieser DD an und überprüfen Sie sie (oder suchen Sie nach dem Abschnitt „System Upgrade History“ in den ASUPs):
# 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 --------------- --------- ------- ----------------- ------------
Laut dieser Ausgabe erfüllt „dd-trusted-1“ Punkt 2 und verwendet wahrscheinlich ein falsches Zertifikat, was dazu führt, dass der DD-Host „dd-upgraded-7.7.2.x“ die UI nicht über die Vertrauensbeziehung laden kann.
Um Punkt 3 zu überprüfen (ob die DD-UI-Fehlerprotokolle für dieses spezifische Problem gelten), führen Sie den folgenden Befehl aus, um die „em.info“-Protokolldatei zu öffnen:
# log view debug/sm/em.info
Suchen Sie nach diesen Protokollen (verwenden Sie einen Schrägstrich):
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
Die unmittelbare Problemumgehung besteht darin, die Vertrauensbeziehung zu jedem DD-Host aufzuheben, auf dem in der Vergangenheit DDOS 4.7 bis 5.4 ausgeführt wurde, damit für den Fall, dass ein falsches Zertifikat erstellt wurde, das Laden der lokalen DD-Benutzeroberfläche nicht mehr fehlschlägt. In diesem Beispiel ist dd-trusted-1 die einzige vertrauenswürdige DD, die jemals DDOS 4.7 bis 5.4 ausgeführt hat. Um die gegenseitige Vertrauensbeziehung (diese DD vertraut dd-trusted-1 und umgekehrt) zur DD mit dem UI-Problem aufzuheben, gehen Sie wie folgt vor.
# adminaccess trust del host dd-trusted-1 type mutual
Das Aufheben der Vertrauensbeziehung führt dazu, dass die mit der jetzt nicht mehr vertrauenswürdigen DD eingerichtete Replikation fehlschlägt, bis die Vertrauensbeziehung wiederhergestellt wird. Wenn das Aufheben der Vertrauensbeziehung fehlschlägt, weil die Remote-DD nicht mehr erreichbar oder nicht mehr vorhanden ist, wiederholen Sie den Befehl ohne die Option „mutual“, um die Vertrauensbeziehung nur lokal zu entfernen. Dies reicht aus, damit die Benutzeroberfläche wieder funktioniert.
In Fällen, in denen die vertrauenswürdige DD weiterhin verwendet wird und die Vertrauensbeziehung beibehalten werden muss, muss ein neues CA-Zertifikat erstellt werden:
# adminaccess certificate generate self-signed-cert regenerate-ca
Schalten Sie anschließend den Webdienst auf den betroffenen Geräten aus und wieder ein:
# adminaccess disable https # adminaccess enable https
Wenn die DD-Benutzeroberfläche nach dem Ausführen der oben genannten Schritte immer noch nicht funktioniert, wenden Sie sich an den Dell Data Domain-Support.
Um die Vertrauensbeziehung wiederherzustellen, müssen Sie zunächst sicherstellen, dass das DD-CA-Zertifikat von „dd-trusted-1“ ohne Fehler neu erstellt wurde. Führen Sie in der Befehlszeile für diesen Host den folgenden Befehl aus und befolgen Sie die Eingabeaufforderungen, falls vorhanden:
# adminaccess certificate generate self-signed-cert regenerate-ca
Wenn für diese DD eine Vertrauensbeziehung mit anderen DDs oder Replikationen eingerichtet wurden, müssen Sie für alle diese Peers die Vertrauensbeziehung entfernen und dann wieder hinzufügen.
Um schließlich die Vertrauensbeziehung zwischen „dd-upgraded-7.7.2.x“ und „dd-trusted-1“ wiederherzustellen, haben Sie folgende Optionen: