Data Domain: Etter at du har oppgradert til DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller nyere, får du ikke tilgang til brukergrensesnittet

En bruker oppgraderer enten DDOS eller DDMC til versjon 7.7.2.x, 7.7.3.x, 7.8.x eller 7.9.x, og etter at oppgraderingen er fullført, oppdager du at det ikke er mulig å få tilgang til brukergrensesnittet. Omstart av HTTP- eller HTTPS-tjenestene fra kommandolinjen får det heller ikke til å fungere. Når du bruker en nettleser for å få tilgang til brukergrensesnittet, viser følgende feilside: 

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

Serverserveren for brukergrensesnittet kjører på en Java-basert applikasjon. Backend for brukergrensesnittet kjører ikke. Hvis DD ble oppgradert til noen av de nevnte utgivelsene og brukergrensesnittet mislykkes, hvis DD har et klareringsforhold til andre DD-er og noen av dem har feil sertifikat, kan det være årsaken til hvorfor DD-grensesnittet ikke starter opp. En strengere kontroll i den nyere buntede JDK-en kan ikke passere for noen av de klarerte DD-vertene.

Hvis du trenger hjelp til å sjekke om en DLm er koblet til, kan du se følgende artikkel 207823 i Dells kunnskapsbase: 
Data Domain + DLM: Du får ikke tilgang til brukergrensesnittet etter oppgradering 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 Data Domain + DLM: Etter at du har oppgradert til DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller nyere, får du ikke tilgang til brukergrensesnittet

 
Det er nødvendig å fastslå om dette er akkurat problemet som står overfor. For at dette skal være tilfelle, må alle betingelsene nedenfor være oppfylt:

1. DD der brukergrensesnittet ikke starter opp, har bare problemer med brukergrensesnittet etter oppgradering til følgende:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Denne DD-en har et tillitsforhold til andre DD-er, hvorav én eller flere har en DDOS 4.7-5.4-versjon tidligere.
3. Denne DD-en har et bestemt sett med logger for at feilen ikke kan starte grensesnittets serverserver.

Element én er selvopplysende.

Hvis du vil finne ut om element to gjelder, kan du se listen over klarerte verter 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 tilfellet er "dd-upgraded-7.7.2.x" den som får brukergrensesnittet til å svikte, og de andre to er klarerte DD-er (fordi de har replikeringskontekster angitt med den lokale DD-en). Med mindre det regenereres senere, er et DD-sertifikat som brukes for klarering, gyldig fra installasjonsdatoen. I utdataene ovenfor er den mest sannsynlige kandidat for å kjøre en gammel DDOS 4.7-5.4-versjon "dd-trusted-1".

Logg på denne DD-en, og kontroller den (eller se etter delen System Upgrade History (Systemoppgraderingshistorikk) 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 denne utdataene er "dd-trusted-1" et treff for element to, og vil sannsynligvis ha feil sertifikat som fører til at DD-oppgradert-7.7.2.x-verten ikke laster inn brukergrensesnittet gjennom klareringsforholdet.

Hvis du vil bekrefte element tre (hvis feilloggene for DD-grensesnittet er for dette spesifikke problemet), kjører du følgende kommando for å åpne «em».info» loggfil:

# log view debug/sm/em.info

Søk (bruk en skråstrek) for disse loggene:

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øsningen er å fjerne klarering med en hvilken som helst DD-vert som tidligere hadde kjørt DDOS 4.7–5.4, slik at hvis det har opprettet et feil sertifikat, fører det ikke til at det lokale DD-brukergrensesnittet ikke lastes inn lenger. Hvis du fortsetter med eksemplet, kan vi si at dd-Trusted-1 er den eneste av de klarerte DD-ene som noensinne har kjørt DDOS 5.7–5.4. Hvis du vil fjerne gjensidig tillit (denne DD Trusting dd-trusted-1 og motsatt vei), gjør du følgende fra DD med ui-problemet.
 

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

Fjerning av klarering fører til at replikering som er konfigurert med den nå ikke-klarerte DD-en, mislykkes før klarering er gjenopprettet på nytt. Hvis fjerning av klarering mislykkes fordi den eksterne DD-en ikke lenger kan nås eller ikke engang finnes, gjentar du kommandoen uten "gjensidig"-alternativet, for å bare fjerne klarering lokalt, ettersom det er tilstrekkelig for at brukergrensesnittet skal fungere igjen.

For tilfeller der den klarerte DD fortsatt er i bruk, og vi må beholde klareringsrelasjonen, må det opprettes et nytt CA-sertifikat:

1. Generer et nytt selvsignert CA-sertifikat på det avvikende systemet fra CLI:

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

 

2. Korriger klareringen som dette DD-systemet opprettholder med alle andre DD- eller DDMC-systemer (gjensidig "adminaccess trust del" etterfulgt av "adminaccess trust add" fra hver enhet)

3. Til slutt blar du gjennom netttjenesten i en av de berørte enhetene:

   # adminaccess disable https
   # adminaccess enable https

Hvis DD-brukergrensesnittet ikke fungerer ennå etter at du har gjort det ovenfor, kan du kontakte DELL Data Domain Support.

Hvis du vil gjenopprette klarering, må du først sørge for at DD CA-sertifikatet i dd-trusted-1 opprettes på nytt uten feil. Fra denne vertskommandolinjen gjør du det ved å kjøre kommandoen nedenfor, og følg instruksjonene hvis det er aktuelt: 

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

Hvis denne DD-en er opprettet med andre DD-er eller replikering, må du slette og deretter lese tillit for alle slike noder.

Til slutt, for å lese tillit mellom "dd-upgraded-7.7.2.x" og "dd-trusted-1", enten:

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