Data Domain: Depois de fazer upgrade para a versão 6.2.1.90, 7.2.0.95, 7.7.2.x ou posterior do DDOS ou DDMC, não é possível acessar a IU

Um usuário faz upgrade para a versão 7.7.2.x, 7.7.3.x, 7.8.x ou 7.9.x do DDOS ou do DDMC e, depois que o upgrade é concluído, descobre que não é possível acessar a IU. Reiniciar os serviços HTTP ou HTTPS a partir da linha de comando também não faz com que a interface funcione. Ao usar um navegador para acessar a IU, a página de erro a seguir mostra: 

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

O back-end da IU está em execução em um aplicativo baseado em Java. O back-end da IU não está em execução. Se o upgrade do DD for feito para qualquer uma das versões mencionadas e a IU apresentar falha, o motivo de a IU do DD não ser inicializada pode ser proveniente de o DD ter uma relação de confiança com outros DDs, mas algum deles estar com um certificado incorreto. Em uma verificação rigorosa no JDK agrupado mais recente, alguns dos hosts confiáveis do DD não são aprovados.

Para obter ajuda para verificar se um DLm está conectado, consulte o artigo 207823 da KB Dell: 
Data Domain + DLM: Depois de fazer upgrade para o DDOS ou DDMC 6.2.1.90, 7.2.0.95, 7.7.2.x ou posterior, não é possível acessar a IU.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain + DLM: Depois de fazer upgrade para a versão 6.2.1.90, 7.2.0.95, 7.7.2.x ou posterior do DDOS ou DDMC, não é possível acessar a IU

 
É necessário verificar se o problema é exatamente esse. Para garantir que esse seja o caso, todas as condições abaixo devem ser verdadeiras:

1. O DD, no qual a IU não está sendo iniciada, apresenta problemas de IU apenas após o upgrade para o:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Esse DD tem uma relação de confiança com outros DDs, sendo que pelo menos um deles executava anteriormente uma das versões do DDOS entre a 4.7 e a 5.4.
3. Esse DD tem um conjunto específico de logs para a falha ao iniciar o back-end da IU.

O item um é autoexplicativo.

Para verificar se o item dois é aplicável, obtenha a lista de hosts confiáveis no 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
----------------------   ----------   ------------------------   ------------------------   -----------------------------------------------------------

Nesse caso, o "dd-upgraded-7.7.2.x" é o que está apresentando falha na IU, e os outros dois são os DDs confiáveis (porque eles têm contextos de replicação definidos com o DD local). A menos que seja gerado de novo posteriormente, um certificado do DD usado para a relação de confiança é "válido a partir" da data de instalação. Na saída acima, o candidato mais provável para executar uma das versões antigas do DDOS entre a 4.7 e a 5.4 é o "dd-trusted-1".

Faça login e verifique o DD (ou procure a seção "System Upgrade History" em 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
---------------   ---------   -------   -----------------   ------------

Nessa saída, "dd-trusted-1" é uma correspondência para o item dois e é provável que tenha um certificado incorreto, fazendo com que o host do DD "dd-upgraded-7.7.2.x" falhe para carregar a IU por meio de seu relacionamento de confiança.

Para confirmar o item três (se os logs de falha da IU do DD informarem esse problema específico), execute o seguinte comando para abrir o arquivo de log "em.info":

# log view debug/sm/em.info

Pesquise (use uma barra) por estes registros:

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

A solução temporária mais imediata é remover a relação de confiança com qualquer host do DD que tenha executado anteriormente uma das versões do DDOS entre a 4.7 e a 5.4. Dessa forma, caso esse host tenha criado um certificado errado, isso não causará mais a falha de carregamento da interface da IU do DD local. Continuando com o exemplo, suponhamos que o dd-trusted-1 seja o único DD confiável que já executou uma das versões do DDOS entre a 5.7 e a 5.4. Para remover a relação de confiança mútua (entre este DD e o dd-trusted-1), execute as etapas a seguir a partir do DD com o problema de IU.
 

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

A remoção da relação de confiança mútua faz com que a replicação configurada com o DD, que agora não é mais confiável, falhe até que a confiança seja restabelecida. Se a remoção da relação de confiança falhar porque o DD remoto não está mais acessível ou não existe, repita o comando sem a opção "mutual" para remover apenas a relação de confiança localmente, pois isso é suficiente para que a interface do usuário funcione de novo.

Para os casos em que o DD confiável ainda está em uso e a relação de confiança precisa ser mantida, um novo certificado da CA deverá ser criado:

1. Gere um novo certificado autoassinado da CA no sistema com problema, a partir da CLI:

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

 

2. Corrija a relação de confiança que esse sistema DD mantém com todos os outros sistemas DD ou DDMC ("adminaccess trust del" mútuo seguido por "adminaccess trust del", em cada dispositivo)

3. Por fim, reinicie o serviço Web em todos os dispositivos afetados:

   # adminaccess disable https
   # adminaccess enable https

Depois de realizar o processo acima, se a interface do usuário do DD ainda não funcionar, entre em contato com o suporte do Dell Data Domain.

Para restabelecer a relação de confiança, você precisará primeiramente garantir que o certificado da CA do DD em "dd-trusted-1" seja criado de novo, sem erros. Na linha de comando do host, execute o comando abaixo e siga os prompts, se houver: 

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

Se a relação de confiança deste DD for restabelecida com os outros DDs ou a replicação for feita, você precisará excluir a relação de confiança e, em seguida, adicioná-la novamente, em todos esses pares.

Por fim, para reestabelecer a confiança entre o "dd-upgraded-7.7.2.x" e o "dd-trusted-1":

• Execute "adminaccess trust add host dd-trusted-1 type mutual" em "dd-upgraded-7.7.2.x" ou 
• Execute "adminaccess trust add host dd-upgraded-7.7.2.x type mutual" em "dd-trusted-1"