Домен даних: Після оновлення до 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, перегляньте статтю 207823 бази знань Dell: 
Домен даних + DLM: Після оновлення до DDOS або DDMC 6.2.1.90, 7.2.0.95 або 7.7.2.x або пізнішої версії доступ до інтерфейсу користувача неможливий.
https://www.dell.com/support/kbdoc/en-us/000207823 Домен даних + 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 має певний набір журналів для невдалого запуску модуля інтерфейсу користувача.

Пункт перший зрозумілий.

Щоб визначити, чи застосовується пункт два , отримаєте список довірених хостів в 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, який використовується для довіри, є дійсним від» дати інсталяції. У наведеному вище виході найбільш вірогідним кандидатом для запуску старого випуску DDOS 4.7 - 5.4 є "dd-trusted-1".

Увійдіть до цього DD і перевірте його (або знайдіть розділ "Історія оновлення системи" в 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
---------------   ---------   -------   -----------------   ------------

У цьому виході "dd-trusted-1" відповідає другому пункту, і, ймовірно, має неправильний сертифікат, що призводить до того, що хост DD "dd-upgraded-7.7.2.x" не завантажує інтерфейс користувача через їхні відносини довіри.

Щоб підтвердити пункт третій (якщо журнали помилок інтерфейсу DD призначені для цієї конкретної проблеми), запустіть таку команду, щоб відкрити "em.Інфо»:

# 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 більше не доступний або навіть не існує, повторіть команду без параметра "взаємний", щоб видалити довіру лише локально, оскільки цього достатньо для відновлення роботи інтерфейсу користувача.

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

1. Згенеруйте новий самопідписаний сертифікат ЦС у системі-порушнику, від CLI:

# 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.

Щоб відновити довіру, спочатку потрібно переконатися, що сертифікат 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"