Data Domain: Efter uppgradering till DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller senare kan användargränssnittet inte nås

En användare uppgraderar antingen DDOS eller DDMC till version 7.7.2.x, 7.7.3.x, 7.8.x eller 7.9.x och när uppgraderingen är klar kan du upptäcka att det inte går att öppna användargränssnittet. Det fungerar inte heller att starta om HTTP- eller HTTPS-tjänsterna från kommandoraden. När du använder en webbläsare för att öppna användargränssnittet visas följande felsida: 

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

Användargränssnittets serverdel körs i ett Java-baserat program. Användargränssnittets backend körs inte. Om DD har uppgraderats till någon av de nämnda versionerna och användargränssnittet misslyckas kan det bero på att DD har en förtroenderelation med andra DD och någon av dem har ett felaktigt certifikat, kan det vara orsaken till att DD-användargränssnittet inte startar. En strängare kontroll i den nyare JDK-paketet lyckas inte för vissa av de betrodda DD-värdarna.

Hjälp med att kontrollera om ett DLm är anslutet finns i Dells kunskapsartikel 207823: 
Data Domain + DLM: Efter uppgradering till DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller senare går det inte att öppna användargränssnittet.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain + DLM: Efter uppgradering till DDOS eller DDMC 6.2.1.90, 7.2.0.95 eller 7.7.2.x eller senare kan användargränssnittet inte nås

 
Det är nödvändigt att bekräfta om det är exakt det här problemet som uppstår. För att detta ska vara fallet måste alla villkor nedan vara uppfyllda:

1. DD där användargränssnittet inte startar har bara problem med användargränssnittet sedan du uppgraderade till något av följande:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Denna DD har en förtroenderelation med andra DD, varav en eller flera har en DDOS 4.7-5.4-version tidigare.
3. Denna DD har en viss uppsättning loggar för att det inte går att starta användargränssnittets serverdel.

Punkt ett är självförklarande.

Om du vill ta reda på om objekt två gäller får du en lista över betrodda värdar 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 det här fallet är "dd-upgraded-7.7.2.x" den som har användargränssnittet som misslyckas och de andra två är betrodda DD (eftersom de har replikeringskontexter inställda med den lokala DD). Om det inte återskapas senare är ett DD-certifikat som används för förtroende "giltigt från" installationsdatumet. I ovanstående utdata är den mest sannolika kandidat för att köra en gammal DDOS 4.7-5.4-version "dd-trusted-1".

Logga in på DD och kontrollera det (eller leta efter avsnittet "System Upgrade History" i 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
---------------   ---------   -------   -----------------   ------------

I de här utdata är "dd-trusted-1" en matchning för objekt två och har troligen ett felaktigt certifikat som gör att DD-värden "dd-upgraded-7.7.2.x" inte kan läsa in användargränssnittet via sitt förtroendeförhållande.

För att bekräfta objekt tre (om DD-gränssnittsfelloggarna är för det här specifika problemet) kör du följande kommando för att öppna "em.info"-loggfil:

# log view debug/sm/em.info

Sök (använd ett snedstreck) för dessa loggar:

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 omedelbara lösningen är att ta bort förtroendet hos alla DD-värdar som kört DDOS 4.7–5.4 tidigare, så att det lokala DD-användargränssnittet inte längre kan läsas in om det har skapats ett fel certifikat. Vi fortsätter med exemplet och säger att dd-trusted-1 är den enda betrodda DD som någonsin kör DDOS 5.7–5.4. Om du vill ta bort ömsesidigt förtroende (DD som litar på dd-trusted-1 och tvärtom) gör du följande för att ta bort ömsesidigt förtroende från DD med användargränssnittsproblemet.
 

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

Borttagning av förtroende gör att replikeringskonfigurationen med den nu icke-betrodda DD misslyckas tills förtroende har återupprättats. Om det inte går att ta bort förtroende eftersom fjärr-DD inte längre kan nås eller inte ens finns upprepar du kommandot utan alternativet "ömsesidigt" för att bara ta bort förtroendet lokalt, eftersom det räcker för att användargränssnittet ska fungera igen.

I de fall där betrodd DD fortfarande används och vi måste behålla förtroenderelationen måste ett nytt CA-certifikat skapas:

1. Generera ett nytt självsignerat CA-certifikat på det felande systemet från CLI:

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

 

2. Åtgärda det förtroende som detta DD-system upprätthåller med alla andra DD- eller DDMC-system (ömsesidigt "adminaccess trust del" följt av "adminaccess trust add" från varje enhet)

3. Slutligen, starta om webbtjänsten på någon av de enheter som påverkas:

   # adminaccess disable https
   # adminaccess enable https

Om DD-användargränssnittet inte fungerar ännu kontaktar du DELL Data Domain-supporten.

För att återupprätta förtroendet måste du först se till att DD CA-certifikatet i "dd-trusted-1" återskapas utan fel. Från den här värdkommandoraden gör du det genom att köra kommandot nedan och följ anvisningarna om det finns några: 

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

Om denna DD har upprättat förtroende med andra DD eller replikering måste du ta bort och sedan läsa förtroende för alla sådana peers.

Slutligen, för att läsa förtroende mellan "dd-upgraded-7.7.2.x" och "dd-trusted-1", gör du något av följande:

• Kör "adminaccess trust add host dd-trusted-1 type mutual" från "dd-upgraded-7.7.2.x" eller 
• Kör "adminaccess trust add host dd-upgraded-7.7.2.x type mutual" från "dd-trusted-1"