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 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:
# adminaccess certificate generate self-signed-cert regenerate-ca
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":