Data Domain: Der kan ikke opnås adgang til brugergrænsefladen efter opgradering til DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller nyere.

En bruger opgraderer enten DDOS eller DDMC til version 7.7.2.x, 7.7.3.x, 7.8.x eller 7.9.x, og når opgraderingen er fuldført, skal du opdage, at det ikke er muligt at få adgang til brugergrænsefladen. En genstart af HTTP- eller HTTPS-tjenester fra kommandolinjen får den heller ikke til at fungere. Når du bruger en browser til at få adgang til brugergrænsefladen, viser følgende fejlside: 

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

UI-backend kører på et Java-baseret program. UI-backend kører ikke. Hvis DD blev opgraderet til en af de nævnte udgivelser, og brugergrænsefladen fejler, hvis DD har et tillidsforhold til andre DD'er, og nogen af dem har et forkert certifikat, kan det være årsagen til, hvorfor DD-brugergrænsefladen ikke starter op. En strammere kontrol i den nyere bundtede JDK kan ikke bestå for nogle af de betroede DD-værter.

Du kan få hjælp til at kontrollere, om der er vedhæftet en DLm, i Dell KB-artikel 207823: 
DataDomain + DLM: Der kan ikke opnås adgang til brugergrænsefladen efter opgradering til DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller nyere.
https://www.dell.com/support/kbdoc/en-us/000207823 DataDomain + DLM: Der kan ikke opnås adgang til brugergrænsefladen efter opgradering til DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller nyere.

 
Det er nødvendigt at fastslå, om det er nøjagtigt det problem, der opleves. For at dette kan være tilfældet, skal alle nedenstående betingelser være opfyldt:

1. DD, hvor brugergrænsefladen ikke starter op, oplever kun problemer med brugergrænsefladen efter opgraderingen til enten:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Dette DD har et tillidsforhold til andre DD'er, hvoraf en eller flere tidligere har en DDOS 4.7-5.4-version.
3. Denne DD har et bestemt sæt logfiler, som skyldes, at ui-backend ikke startes.

Punkt et er selvforklarende.

For at afgøre, om punkt to gælder, skal du hente listen over betroede værter i 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
----------------------   ----------   ------------------------   ------------------------   -----------------------------------------------------------

I dette tilfælde er "dd-upgraded-7.7.2.x" den, der fejler på brugergrænsefladen, og de to andre er de betroede DD'er (fordi de har replikeringskontekster indstillet med den lokale DD). Medmindre der gendannes senere, er et DD-certifikat, der bruges til tillid, "gyldigt fra" installationsdatoen. I ovenstående output er den mest sandsynlige kandidat til at køre en gammel DDOS 4.7 - 5.4-udgivelse "dd-trusted-1".

Log på den pågældende DD, og kontroller den (eller se efter afsnittet "Systemopgraderingshistorik" i ASUP'er):

# 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
---------------   ---------   -------   -----------------   ------------

I dette output er "dd-trusted-1" et match for element to og har sandsynligvis et forkert certifikat, hvilket medfører, at DD-værten "dd-upgraded-7.7.2.x" ikke indlæser brugergrænsefladen via deres tillidsforhold.

For at bekræfte punkt tre (hvis DD UI-fejllogfilerne er for dette specifikke problem), skal du køre følgende kommando for at åbne "em.info"-logfil:

# log view debug/sm/em.info

Søg (brug en skråstreg) til disse logfiler:

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

Den mest umiddelbare løsning er at fjerne tillid til enhver DD-vært, der har kørt DDOS 4.7 - 5.4 tidligere, så i tilfælde af, at der er oprettet et forkert certifikat, medfører det ikke, at den lokale DD-brugergrænseflade ikke længere indlæses. Som et yderligere eksempel kan vi sige, at dd-trusted-1 er den eneste af de DD, der nogensinde har kørt DDOS 5.7 - 5.4. For at fjerne gensidig tillid (dette DD, som har tillid til dd-trusted-1, og omvendt), fra DD med brugergrænsefladen skal du udføre følgende trin.
 

# adminaccess trust del host dd-trusted-1 type mutual

Fjernelse af tillid forårsager, at replikering konfigureres med den nu upålidelige DD til at mislykkes, indtil tillid er genetableret. Hvis fjernelse af tillid mislykkes, fordi den eksterne DD ikke længere kan nås eller slet ikke findes, skal du gentage kommandoen uden den "gensidige" mulighed for kun at fjerne tillid lokalt, da det er tilstrækkeligt for at få brugergrænsefladen til at fungere igen.

I tilfælde, hvor den betroede DD stadig er i brug, og vi skal bevare tillidsforholdet, skal der oprettes et nyt nøglecentercertifikat:

1. Generer et nyt selvsigneret CA-certifikat på det system, der er årsag til problemet, fra CLI:

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

 

2. Rettelse af den tillid, som dette DD-system opretholder med alle andre DD- eller DDMC-systemer (gensidig "adminaccess trust del" efterfulgt af "adminaccess trust add" fra hver enhed)

3. Til sidst skal ducyklussere webtjenesten på en af de berørte enheder:

   # adminaccess disable https
   # adminaccess enable https

Hvis DD-brugergrænsefladen endnu ikke virker efter at have udført ovenstående, skal du kontakte DELL Data Domain Support.

For at genetablere forbindelsen skal du først sikre, at DD CA-certifikatet i "dd-trusted-1" genoprettes uden fejl. Fra denne værtskommandolinje skal du gøre det ved at køre kommandoen nedenfor og følge anvisningerne, hvis der er: 

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

Hvis denne DD har oprettet tillid til andre DD'er eller replikering, skal du slette og derefter læse tillid til alle sådanne peers.

Endelig skal du, for at læse tillid mellem "dd-upgraded-7.7.2.x" og "dd-trusted-1", enten:

• Kør "adminaccess trust add host dd-trusted-1 type gensidig" fra "dd-upgraded-7.7.2.x", eller 
• Kør "adminaccess trust add host dd-upgraded-7.7.2.x type gensidig" fra "dd-trusted-1"