Data Domain: Na het upgraden naar DDOS of DDMC 6.2.1.90, 7.2.0.95 of 7.7.2.x of hoger, kan de gebruikersinterface niet worden geopend

Een gebruiker upgradet DDOS of DDMC naar versie 7.7.2.x, 7.7.3.x, 7.8.x of 7.9.x en nadat de upgrade is voltooid, ontdekt u dat het niet mogelijk is om toegang te krijgen tot de gebruikersinterface. Het opnieuw opstarten van de HTTP- of HTTPS-services vanaf de opdrachtregel zorgt er ook niet voor dat deze werken. Wanneer u een browser gebruikt om toegang te krijgen tot de gebruikersinterface, wordt de volgende foutpagina weergegeven: 

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

De UI-backend wordt uitgevoerd op een Java-applicatie. UI-backend wordt niet uitgevoerd. Als de DD is geüpgraded naar een van de genoemde releases en de gebruikersinterface mislukt, als de DD een vertrouwensrelatie heeft met andere DD's en een van deze een onjuist certificaat heeft, kan dit de oorzaak zijn waarom de DD-gebruikersinterface niet wordt opgestart. Een strengere controle in de nieuwere gebundelde JDK mislukt voor sommige van de vertrouwde DD-hosts.

Raadpleeg voor hulp bij het controleren of een DLm is aangesloten het Dell KB-artikel 207823: 
Data Domain + DLM: Na het upgraden naar DDOS of DDMC 6.2.1.90, 7.2.0.95 of 7.7.2.x of hoger, kan de gebruikersinterface niet worden geopend.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain + DLM: Na het upgraden naar DDOS of DDMC 6.2.1.90, 7.2.0.95 of 7.7.2.x of hoger, kan de gebruikersinterface niet worden geopend

 
Het is noodzakelijk om na te gaan of dit precies het probleem is waarmee dit probleem wordt geconfronteerd. Om dit te kunnen doen, moet aan alle onderstaande voorwaarden worden voldaan:

1. DD waarbij de gebruikersinterface niet wordt opgestart, ondervindt alleen problemen met de gebruikersinterface sinds een upgrade naar een van de volgende opties:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Deze DD heeft een vertrouwensrelatie met andere DD's, waarvan een of meer in het verleden een DDOS 4.7- 5.4-versie heeft.
3. Deze DD heeft een bepaalde set logboeken voor het niet starten van de UI-backend.

Item één spreekt voor zich.

Om te bepalen of item twee van toepassing is, krijgt u de lijst met vertrouwde hosts in de 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
----------------------   ----------   ------------------------   ------------------------   -----------------------------------------------------------

In dit geval is 'dd-upgraded-7.7.2.x' de gebruikersinterface die mislukt en de andere twee zijn de vertrouwde DD's (omdat ze replicatiecontexten hebben ingesteld met de lokale DD). Tenzij later opnieuw gegenereerd, is een DD-certificaat dat wordt gebruikt voor vertrouwen "geldig vanaf" de installatiedatum. In de bovenstaande uitvoer is de meest waarschijnlijke kandidaat voor het uitvoeren van een oude DDOS 4.7 - 5.4 release "dd-trusted-1".

Meld u aan bij die DD en controleer deze (of zoek het gedeelte "System Upgrade History" in ASUP's):

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

In deze uitvoer is 'dd-trusted-1' een overeenkomst voor item twee en heeft het waarschijnlijk een onjuist certificaat waardoor de DD-host 'dd-upgraded-7.7.2.x' de gebruikersinterface niet kan laden via hun vertrouwensrelatie.

Om item drie te bevestigen (als de DD UI-foutlogboeken voor dit specifieke probleem zijn), voert u de volgende opdracht uit om de "em" te openen.info"-logboekbestand:

# log view debug/sm/em.info

Zoek (gebruik een schuine streep naar voren) voor deze logboeken:

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

De meest directe tijdelijke oplossing is om het vertrouwen te verwijderen met een DD-host die in het verleden DDOS 4.7 - 5.4 had uitgevoerd, zodat in het geval dat er een verkeerd certificaat is gemaakt, de lokale DD-gebruikersinterface niet meer wordt geladen. Laten we verder gaan met het voorbeeld: dd-trusted-1 is de enige vertrouwde DD die ooit DDOS 5.7 - 5.4 uitvoert. Om wederzijds vertrouwen te verwijderen (deze DD vertrouwde dd-trusted-1 en tegenovergestelde manier), voert u de volgende stappen uit om het wederzijdse vertrouwen te verwijderen uit de DD met het UI-probleem.
 

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

Het verwijderen van vertrouwen zorgt ervoor dat replicatie die is ingesteld met de nu niet-vertrouwde DD mislukt totdat de vertrouwensrelatie opnieuw is ingesteld. Als het verwijderen van vertrouwen mislukt omdat de externe DD niet meer bereikbaar is of zelfs niet bestaat, herhaalt u de opdracht zonder de optie "mutual" om alleen de vertrouwensrelatie lokaal te verwijderen, omdat dat voldoende is om de gebruikersinterface weer te laten werken.

In gevallen waarin de vertrouwde DD nog steeds in gebruik is en we de vertrouwensrelatie moeten behouden, moet er een nieuw CA-certificaat worden gemaakt:

1. Genereer een nieuw zelfondertekend CA-certificaat op het beledigende systeem vanuit de CLI:

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

 

2. Herstel de vertrouwensrelatie die dit DD-systeem onderhoudt met elk ander DD- of DDMC-systeem (wederzijds "adminaccess trust del" gevolgd door "adminaccess trust add" van elk apparaat)

3. Schakel ten slotte de webservice in op een van de getroffen apparaten:

   # adminaccess disable https
   # adminaccess enable https

Als de DD-gebruikersinterface na het bovenstaande nog niet werkt, neemt u contact op met DELL Data Domain Support.

Om het vertrouwen te herstellen, moet u er eerst voor zorgen dat het DD CA-certificaat in 'dd-trusted-1' opnieuw wordt gemaakt zonder fouten. Voer vanaf deze hostopdrachtregel de onderstaande opdracht uit en volg de aanwijzingen indien van toepassing: 

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

Als deze DD vertrouwen heeft ingesteld met andere DD's of replicatie, moet u het vertrouwen voor al deze peers verwijderen en vervolgens lezen.

Ten slotte, om vertrouwen te lezen tussen "dd-upgraded-7.7.2.x" en "dd-trusted-1", ofwel:

• Voer "adminaccess trust add host dd-trusted-1 type mutual" uit vanuit "dd-upgraded-7.7.2.x" of 
• Voer "adminaccess trust add host dd-upgraded-7.7.2.x type mutual" uit vanuit "dd-trusted-1"