Data Domain: dopo l'aggiornamento a DD OS o DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x o versioni successive, non è possibile accedere all'interfaccia utente.

Un utente aggiorna DD OS o DDMC alla versione 7.7.2.x, 7.7.3.x, 7.8.x o 7.9.x e, al termine dell'aggiornamento, scopre che non è possibile accedere all'interfaccia utente. Il riavvio dei servizi HTTP o HTTPS dalla riga di comando non risolve il problema. Quando si utilizza un browser per accedere all'interfaccia utente, viene visualizzata la seguente pagina di errore: 

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

Il back-end dell'interfaccia utente è in esecuzione su un'applicazione basata su Java. Il back-end dell'interfaccia utente non è in esecuzione. Se DD è stato aggiornato a una delle versioni menzionate e si verificano errori nell'interfaccia utente, nel caso in cui DD abbia una relazione di trust con altri DD e uno di essi abbia un certificato errato, potrebbe essere questo il motivo per cui l'interfaccia utente di DD non si avvia. Un controllo più rigoroso nel JDK bundled più recente non viene superato per alcuni host DD attendibili.

Per informazioni su come verificare se è collegata una unità DLm, consultare l'articolo 207823 della Knowledge Base di Dell: 
Data Domain + DLM: dopo l'aggiornamento a DD OS o DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x o versioni successive, non è possibile accedere all'interfaccia utente.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain + DLM: dopo l'aggiornamento a DD OS o DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x o versioni successive, non è possibile accedere all'interfaccia utente.

 
È necessario verificare se si tratta esattamente del problema riscontrato. A tale scopo, è necessario rispettare tutte le condizioni riportate di seguito:

1. Il DD in cui l'interfaccia utente non si avvia riscontra i problemi dell'interfaccia utente solo dopo l'aggiornamento a:
   • DD OS 7.7.2.x
   • DD OS 7.7.3.x
   • DD OS 7.8.x
   • DD OS 7.9.x
2. Questo DD ha una relazione di trust con altri DD, uno o più dei quali ha una versione di DD OS da 4.7 a 5.4 non aggiornata.
3. Questo DD dispone di un particolare set di registri per l'errore di avvio del back-end dell'interfaccia utente.

L'elemento 1 è autoesplicativo.

Per determinare se si applica l'elemento 2, ottenere l'elenco di host attendibili in 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 questo caso, "dd-upgraded-7.7.2.x" è quello con interfaccia utente non avviata e gli altri due sono DD attendibili (perché hanno contesti di replica impostati con il DD locale). A meno che non venga rigenerato in un secondo momento, un certificato DD utilizzato per l'attendibilità è valido dalla data di installazione. Nell'output riportato sopra, il candidato più probabile per l'esecuzione di una versione precedente di DD OS da 4.7 a 5.4 è "dd-trusted-1".

Accedere a tale DD e controllarlo (o cercare la sezione "System Upgrade History" in ASUP):

# 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 questo output, "dd-trusted-1" è una corrispondenza per l'elemento 2 ed è probabile che abbia un certificato errato a causa del quale l'host DD "dd-upgraded-7.7.2.x" non carica l'interfaccia utente tramite la relazione di trust.

Per verificare l'elemento tre (se i registri degli errori dell'interfaccia utente di DD riguardano questo problema specifico), eseguire il seguente comando per aprire il file di registro "em.info":

# log view debug/sm/em.info

Cercare (utilizzare una barra) questi registri:

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

La soluzione alternativa più immediata consiste nel rimuovere l'attendibilità con qualsiasi host DD che in passato eseguiva DD OS da 4.7 a 5.4, in modo che, se include un certificato errato, non si verifichi più l'errore di caricamento dell'interfaccia utente del DD locale. Continuando con l'esempio, supponiamo che dd-trusted-1 sia l'unico DD affidabile che esegue DD OS da 5.7 a 5.4. Per rimuovere l'attendibilità reciproca (questo DD che considera attendibile dd-trusted-1 e viceversa), dal DD con il problema di caricamento dell'interfaccia utente procedere come segue.
 

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

La rimozione dell'attendibilità determina la configurazione della replica con errore del DD ora non attendibile fino a quando non viene ristabilita l'attendibilità. Se la rimozione dell'attendibilità ha esito negativo perché il DD remoto non è più raggiungibile o non esiste, ripetere il comando senza l'opzione "mutual", per rimuovere solo l'attendibilità a livello locale. È sufficiente questa operazione per ripristinare il funzionamento dell'interfaccia utente.

Per i casi in cui il DD attendibile è ancora in uso e si deve mantenere la relazione di trust, è necessario creare un nuovo certificato CA:

1. Generare un nuovo certificato CA autofirmato sul sistema che presenta l'errore dalla CLI:

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

 

2. Correggere l'attendibilità mantenuta da questo sistema DD con ogni altro sistema DD o DDMC ("adminaccess trust del" reciproco seguito da "adminaccess trust add" di ogni dispositivo)

3. Infine, disattivare e riattivare il servizio web in uno qualsiasi dei dispositivi interessati:

   # adminaccess disable https
   # adminaccess enable https

Se, dopo aver eseguito le operazioni descritte sopra, l'interfaccia utente DD continua a non avviarsi, contattare il supporto Dell Data Domain.

Per ristabilire l'attendibilità, è innanzitutto necessario assicurarsi che il certificato CA DD in "dd-trusted-1" venga ricreato senza errori. Dalla riga di comando dell'host, eseguire il comando riportato di seguito e seguire eventuali prompt: 

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

Se per questo DD è stabilita l'attendibilità con altri DD o con la configurazione di replica, è necessario eliminare e quindi riaggiungere l'attendibilità per tutti questi peer.

Infine, per riaggiungere l'attendibilità tra "dd-upgraded-7.7.2.x" e "dd-trusted-1", effettuare una delle seguenti operazioni:

• Eseguire "adminaccess trust add host dd-trusted-1 type mutual" da "dd-upgraded-7.7.2.x" oppure 
• Eseguire "adminaccess trust add host dd-upgraded-7.7.2.x type mutual" da "dd-trusted-1"