Data Domain : après une mise à niveau vers DDOS ou DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x ou une version supérieure, l’interface utilisateur n’est pas accessible

Après avoir effectué une mise à niveau de DDOS ou de DDMC vers la version 7.7.2.x, 7.7.3.x, 7.8.x ou 7.9.x, l’utilisateur s’aperçoit qu’il ne peut plus accéder à l’interface utilisateur. Un redémarrage des services HTTP ou HTTPS à partir de la ligne de commande ne permet pas de résoudre le problème. Lorsqu’il utilise un navigateur pour accéder à l’interface utilisateur, il obtient la page d’erreur suivante : 

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

Le back-end de l’interface utilisateur s’exécute sur une application Java. Le back-end de l’interface utilisateur n’est pas en cours d’exécution. Si le serveur DD a été mis à niveau vers l’une des versions mentionnées et que l’interface utilisateur ne parvient pas à s’exécuter, le problème de démarrage de l’interface utilisateur DD est peut-être lié au fait que le serveur DD possède une relation de confiance avec d’autres serveurs DD et que l’un d’eux dispose d’un certificat incorrect. Une vérification plus stricte dans le plus récent JDK fourni échoue pour certains hôtes DD de confiance.

Pour obtenir de l’aide pour vérifier si une DLm est rattachée, reportez-vous à l’article 207823 de la base de connaissances Dell : 
Data Domain + DLM : après une mise à niveau vers DDOS ou DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x ou une version supérieure, l’interface utilisateur n’est pas accessible.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain + DLM : après une mise à niveau vers DDOS ou DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x ou une version supérieure, l’interface utilisateur n’est pas accessible

 
Il est nécessaire de vérifier s’il s’agit exactement du problème rencontré. Pour le confirmer, toutes les conditions ci-dessous doivent être vraies :

1. DD dont l’interface utilisateur ne démarre pas et rencontre des problèmes uniquement depuis la mise à niveau vers :
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Ce DD possède une relation de confiance avec d’autres DD, dont un ou plusieurs disposent d’une version DDOS 4.7 à 5.4.
3. Ce DD dispose d’un ensemble particulier de logs pour l’échec du démarrage du back-end de l’interface utilisateur.

L’élément 1 est explicite.

Pour déterminer si l’élément 2 s’applique, récupérez la liste des hôtes de confiance dans le 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
----------------------   ----------   ------------------------   ------------------------   -----------------------------------------------------------

Dans ce cas, « dd-upgraded-7.7.2.x » est celui dont l’interface utilisateur pose problème et les deux autres sont les DD de confiance (car ils ont des contextes de réplication définis avec le DD local). Sauf s’il est régénéré ultérieurement, un certificat DD utilisé pour la relation de confiance est valide à partir de sa date d’installation. Dans la sortie ci-dessus, « dd-trusted-1 » est probablement l’instance qui exécute une ancienne version de DDOS (4.7 à 5.4).

Connectez-vous à ce DD et vérifiez-le (ou consultez la section « System Upgrade History » dans les 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
---------------   ---------   -------   -----------------   ------------

Dans cette sortie, « dd-trusted-1 » correspond à l’élément 2 et est susceptible de posséder un certificat incorrect qui empêche l’hôte DD « dd-upgraded-7.7.2.x » de charger l’interface utilisateur via leur relation de confiance.

Pour confirmer l’élément 3 (si les journaux d’échec de l’interface utilisateur DD concernent ce problème spécifique), exécutez la commande suivante pour ouvrir le fichier journal « em. info » :

# log view debug/sm/em.info

Recherchez (en utilisant une barre oblique) les logs suivants :

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 solution de contournement la plus immédiate consiste à supprimer la relation de confiance avec n’importe quel hôte DD qui exécutait auparavant une version 4.7 à 5.4 de DDOS. Si un certificat incorrect a été créé, l’interface utilisateur DD locale ne se charge plus. Pour poursuivre sur cet exemple, imaginons que dd-trusted-1 est le seul DD de confiance qui exécute DDOS version 4.7 à 5.4. Pour supprimer la confiance mutuelle (confiance du DD à dd-trusted-1, et inversement), procédez comme suit à partir du DD qui rencontre le problème d’interface utilisateur.
 

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

La suppression de la relation de confiance entraîne l’échec de la réplication avec le DD qui n’est plus approuvé, et cela jusqu’à ce que la relation de confiance soit rétablie. Si la suppression de la relation de confiance échoue parce que le DD distant n’est plus accessible ou n’existe pas, répétez la commande sans l’option « mutual » pour supprimer uniquement la relation de confiance en local, car cela suffit pour permettre à l’interface utilisateur de fonctionner à nouveau.

Dans les cas où le DD de confiance est toujours utilisé et qu’il est nécessaire de maintenir la relation de confiance, un nouveau certificat CA doit être créé :

1. À partir de la CLI, générez un nouveau certificat CA auto-signé sur le système en cause :

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

 

2. Corrigez la relation de confiance que ce système DD entretient avec tous les autres systèmes DD ou DDMC (« mutual adminaccess trust del », suivi de « adminaccess trust add » à partir de chaque périphérique).

3. Enfin, effectuez un cycle de service Web sur l’un des périphériques concernés :

   # adminaccess disable https
   # adminaccess enable https

Si, après avoir effectué les opérations ci-dessus, l’interface utilisateur DD ne fonctionne toujours pas, contactez le support Dell Data Domain.

Pour rétablir la relation de confiance, vous devez d’abord vous assurer que le certificat CA de DD est recréé sans erreur dans « dd-trusted-1 ». À partir de cette ligne de commande de l’hôte, exécutez la commande ci-dessous et suivez les invites, le cas échéant : 

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

Si ce DD a établi une relation de confiance avec d’autres DD ou avec la réplication, vous devez supprimer, puis rajouter la relation de confiance pour tous ces homologues.

Enfin, pour rajouter la relation de confiance entre « dd-upgraded-7.7.2.x » et « dd-trusted-1 », procédez de l’une des manières suivantes :

• exécutez « adminaccess trust add host dd-trusted-1 type mutual » à partir de « dd-upgraded-7.7.2.x » ; ou 
• exécutez « adminaccess trust add host dd-upgraded-7.7.2.x type mutual » à partir de « dd-trusted-1 ».