Data Domain. После модернизации до DDOS или DDMC 6.2.1.90, 7.2.0.95 или 7.7.2.x или более поздней версии доступ к пользовательскому интерфейсу невозможен

Пользователь модернизирует DDOS или DDMC до версий 7.7.2.x, 7.7.3.x, 7.8.x или 7.9.x, и после завершения модернизации обнаруживает, что доступ к пользовательскому интерфейсу невозможен. Перезапуск служб HTTP или HTTPS из командной строки также не помогает. При использовании браузера для доступа к пользовательскому интерфейсу отображается следующая страница ошибки: 

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

Внутренний пользовательский интерфейс работает как приложение на базе Java. Внутренний пользовательский интерфейс не работает. Если DD был модернизирован до любого из указанных выпусков и пользовательский интерфейс не работает. Если DD имеет доверительные отношения с другими DD, а какой-либо из них имеет неверный сертификат, это может быть причиной, почему интерфейс DD не запускается. Более строгая проверка в новом пакете JDK не проходит для некоторых доверенных хостов DD.

Для получения справки по проверке подключения DLm см. статью базы знаний Dell 207823: 
Data Domain + DLM. После модернизации до DDOS или DDMC 6.2.1.90, 7.2.0.95 или 7.7.2.x или более поздней версии доступ к пользовательскому интерфейсу невозможен.
https://www.dell.com/support/kbdoc/en-us/000207823 Data Domain + DLM. После модернизации до DDOS или DDMC 6.2.1.90, 7.2.0.95 или 7.7.2.x или более поздней версии доступ к пользовательскому интерфейсу невозможен

 
Необходимо выяснить, не связана ли проблема с этим. В этом случае все перечисленные ниже условия должны соблюдаться.

1. В DD, в котором пользовательский интерфейс не запускается, возникают проблемы с пользовательским интерфейсом только после модернизации до одной из следующих версий:
   • DDOS 7.7.2.x
   • DDOS 7.7.3.x
   • DDOS 7.8.x
   • DDOS 7.9.x
2. Этот DD имеет доверительные отношения с другими DD, один или несколько из которых в прошлом работали под управлением версии DDOS 4.7–5.4.
3. В этом DD имеется определенный набор журналов для сбоя при запуске внутреннего интерфейса пользователя.

Пункт 1 не требует пояснений.

Чтобы определить, применяется ли пункт 2, получите список доверенных хостов в 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
----------------------   ----------   ------------------------   ------------------------   -----------------------------------------------------------

В этом случае «dd-upgraded-7.7.2.x» — это тот DD, где произошел сбой пользовательского интерфейса, а два других — доверенные DD (поскольку у них есть контексты репликации, установленные с локальным DD). Если он не был создан позже, будет использоваться сертификат DD, действительный с даты установки. В приведенном выше выводе наиболее вероятным кандидатом для использования старого выпуска DDOS 4.7–5.4 является «dd-trusted-1».

Войдите в этот DD и проверьте его (или найдите раздел «System Upgrade History» в 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
---------------   ---------   -------   -----------------   ------------

В этом выводе «dd-trusted-1» соответствует пункту 2 и, скорее всего, имеет неверный сертификат, что приводит к сбою загрузки пользовательского интерфейса хостом DD «dd-upgraded-7.7.2.x» через их доверительные отношения.

Чтобы подтвердить пункт 3 (если есть журналы ошибок пользовательского интерфейса DD для данной конкретной проблемы), выполните следующую команду, чтобы открыть файл журнала «em.info»:

# log view debug/sm/em.info

Выполните поиск (используйте косую черту) следующих журналов:

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

Наиболее быстрым временным решением является удаление доверия с любого хоста DD, на котором ранее была запущена DDOS 4.7–5.4, чтобы в случае создания неверного сертификата это не препятствовало запуску пользовательского интерфейса DD. Продолжим рассматривать этот пример. Предположим, что dd-trusted-1 — единственный доверенный DD, который когда-либо работал под управлением DDOS 5.7–5.4. Чтобы удалить взаимное доверие (этот DD доверяет dd-trusted-1 и наоборот), в DD с проблемой пользовательского интерфейса выполните следующие действия.
 

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

Удаление доверия приводит к сбою репликации, установленной для теперь уже не доверенного DD, до восстановления доверия. Если не удается удалить доверие из-за того, что удаленный DD недоступен или даже не существует, повторите команду без параметра «mutual», чтобы удалить доверие локально, так как этого достаточно для того, чтобы пользовательский интерфейс снова работал.

В случаях, когда доверенный DD все еще используется, и нам необходимо сохранить доверие, нужно создать новый сертификат CA:

1. Создайте новый самозаверяющий сертификат CA в системе, где есть нарушения, с помощью интерфейса командной строки:

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

 

2. Исправьте доверие, которое этот DD поддерживает с другими DD или DDMC (выполните взаимное «adminaccess trust del», а затем «adminaccess trust add» на каждом устройстве)

3. И наконец, выключите и включите веб-службу на любом из затронутых устройств:

   # adminaccess disable https
   # adminaccess enable https

Если после выполнения указанных выше действий пользовательский интерфейс DD еще не работает, обратитесь в службу поддержки DELL Data Domain.

Чтобы восстановить доверие, необходимо убедиться, что сертификат DD CA в «dd-trusted-1» повторно создан без ошибок. В командной строке этого хоста выполните следующую команду и следуйте запросам, если они появятся: 

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

Если для этого DD установлено доверие или репликация с другими DD, необходимо удалить и повторно установить доверие для всех одноранговых систем.

Наконец, чтобы снова добавить доверие между «dd-upgraded-7.7.2.x» и «dd-trusted-1», выполните одно из следующих действий.

• Выполните «adminaccess trust add host dd-trusted-1 type mutual» на «dd-upgraded-7.7.2.x» или 
• Выполните «adminaccess trust add host dd-upgraded-7.7.2.x type mutual» на «dd-trusted-1»