Data Domain: Nach dem Upgrade auf DDOS oder DDMC 6.2.1.90, 7.2.0.95 oder 7.7.2.x oder höher kann nicht auf die UI zugegriffen werden.

Ein/e NutzerIn führt ein Upgrade von DDOS oder DDMC auf Version 7.7.2.x, 7.7.3.x, 7.8.x oder 7.9.x durch und stellt dann fest, dass nach Abschluss des Upgrades nicht auf die Benutzeroberfläche zugegriffen werden kann. Ein Neustart der HTTP- oder HTTPS-Dienste über die Befehlszeile löst das Problem nicht. Wenn über einen Browser auf die Benutzeroberfläche zugegriffen wird, wird die folgende Fehlerseite angezeigt: 

Service Not Available
The GUI Service is temporarily unavailable. Refresh browser to try again. If the problem persists, contact Dell EMC support for assistance.

Das UI-Back-end wird auf einer Java-basierten Anwendung ausgeführt. Das UI-Back-end wird nicht ausgeführt. Wenn ein Upgrade der DD auf eine der genannten Versionen durchgeführt wurde und die UI fehlschlägt, die DD eine Vertrauensbeziehung zu anderen DDs hat und eine von ihnen über ein falsches Zertifikat verfügt, kann dies die Ursache dafür sein, dass die DD-UI nicht gestartet wird. Eine strengere Prüfung im aktuellen gebündelten JDK schlägt für einige der vertrauenswürdigen DD-Hosts fehl.

Hilfe bei der Überprüfung, ob ein DLm angehängt ist, finden Sie im Dell Wissensdatenbank-Artikel 207823: 
Data Domain und DLm: Nach dem Upgrade auf DDOS oder DDMC 6.2.1.90, 7.2.0.95 oder 7.7.2.x oder höher kann nicht auf die UI zugegriffen werden.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain und DLm: Nach dem Upgrade auf DDOS oder DDMC 6.2.1.90, 7.2.0.95 oder 7.7.2.x oder höher kann nicht auf die UI zugegriffen werden.

 
Es ist wichtig, festzustellen, ob es sich tatsächlich um dieses Problem handelt. Dafür müssen alle unten aufgeführten Bedingungen erfüllt sein:

1. Auf der DD, bei der die UI nicht gestartet wird, treten die Probleme mit der Benutzeroberfläche erst seit dem Upgrade auf eine der folgenden Versionen auf:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Diese DD hat eine Vertrauensbeziehung zu anderen DDs, von denen eine oder mehrere in der Vergangenheit eine DDOS 4.7- bis 5.4-Version ausgeführt haben.
3. Diese DD verfügt über einen bestimmten Satz von Protokollen für den Fehler beim Starten des UI-Back-end.

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:

1. Über die CLI können Sie ein neues selbstsigniertes CA-Zertifikat auf dem fehlerhaften System erzeugen:

# adminaccess certificate generate self-signed-cert regenerate-ca

 

2. Korrigieren Sie die Vertrauensbeziehung dieses DD-Systems mit jedem weiteren DD- oder DDMC-System (gegenseitiger „adminaccess trust del“ gefolgt von „adminaccess trust add“ von jedem Gerät).

3. 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:

• Führen Sie „adminaccess trust add host dd-trusted-1 type mutual“ von „dd-upgraded-7.7.2.x“ aus oder 
• Führen Sie „adminaccess trust add host dd-upgraded-7.7.2.x type mutual“ von „dd-trusted-1“ aus.