VCF на VxRail: Помилка попередньої перевірки оновлення домену SDDC Manager Workload на кроці "З'єднання VxRail Manager SSH"
Summary: Користувач Mystic у VxRail Manager може бути заблокований після оновлення домену робочого навантаження до випуску VxRail 7.0.410 або 7.0.411, попередня перевірка нового оновлення не вдасться в диспетчері SDDC. ...
Symptoms
Для VCF на кластері VxRail
Після оновлення до випуску VxRail 7.0.410 або 7.0.411, а потім виконання нового оновлення, попередня перевірка оновлення менеджера SDDC не вдасться на кроці "З'єднання VxRail Manager SSH" з описом помилки "Auth fail."

Find "mystic" користувач не може підключитися до VxRail Manager через SSH.
root@sddc-manager-controller [ ~ ]# ssh mystic@<VxM-IP> FIPS mode initialized Password: Account locked due to 7 failed logins
Увійдіть у VxRail Manager як користувач root за допомогою консолі віртуальної машини у vCenter Виконайте наступну команду.
pam_tally2 --user mystic
Помітив, що користувач mystic був заблокований через численні збої входу.
Для стандартного кластера VxRail
Після оновлення до 7.0.410 або 7.0.411 також може виявитися, що "містичний" користувач не може підключитися до VxRail Manager через SSH, оскільки він заблокований.
Cause
Через проблему з SUSE Linux після оновлення VxRail до 7.0.410 або 7.0.411 файл конфігурації
/etc/pam.d/common-account не оновлюється успішно. (Якщо VxRail безпосередньо розгорнуто на 7.0.410 або 7.0.411, то ця проблема не впливає на нього.)
В результаті, при встановленні з'єднання SSH від інших віртуальних машин до VxRail Manager VM через mystic user, хоча вхід успішний, кількість невдалих входів все одно збільшується. Після того, як він досягне максимально допустимої кількості невдалих входів, містичний користувач буде заблокований.
Примітка. Ця проблема не впливає на прямий SSH у VxRail Manager, наприклад, успішний вхід SSH з вашого ноутбука до віртуальної машини VxRail manager не призводить до збільшення кількості невдалих входів. VCF у середовищі VxRail стикається з цією проблемою частіше, оскільки під час попередньої перевірки оновлення встановлюється SSH-з'єднання від SDDC manager VM до VxRail manager VM.
Resolution
Цю проблему вирішено у випуску VxRail 7.0.450, тобто коли VxRail уже працює на 7.0.450, а потім виконує нове оновлення до вищої версії, попередня перевірка оновлення менеджера SDDC не торкнеться цієї проблеми.
Перегляньте наведений нижче список, щоб визначити, чи впливає ця проблема на ваші кластери:
- VxRail оновлюється до 7.0.410 або 7.0.411, а потім виконується нове оновлення до вищої версії (включаючи 7.0.450), попередня перевірка оновлення менеджера SDDC зіткнеться з цією проблемою.
- VxRail розгортається на 7.0.410 або 7.0.411 (greenfield), тоді виконання нового оновлення до більш високої версії, попередня перевірка оновлення менеджера SDDC не торкнеться цієї проблеми.
- VxRail працює на версії до 7.0.410, а потім виконує нове оновлення до вищої версії, попередня перевірка оновлення менеджера SDDC не торкнеться цієї проблеми.
- VxRail працює на версії 7.0.450, а потім, виконуючи нове оновлення до вищої версії, попередня перевірка оновлення менеджера SDDC не торкнеться цієї проблеми.
Клієнти VCF на VxRail дотримуються наведеної нижче таблиці, щоб уникнути попередньої перевірки оновлення диспетчера SDDC, яка стикається з цією проблемою:
| Джерело: версія VxRail | Цільова версія VxRail | Коли застосовувати кроки обходу бази даних |
|---|---|---|
| 7.0.400 | Патч AP до 7.0.410 | Після того, як ви завершите роботу менеджера VxRail, оновіть його до 7.0.410. |
| 7.0.400 | Патч AP до 7.0.411 | Після того, як ви закінчите роботу менеджера VxRail, оновіть його до 7.0.411. |
| 7.0.410* | Патч AP до 7.0.411 | Перш ніж увімкнути оновлення 7.0.411. |
* Якщо ви встановили VCF 4.5 з VxRail 7.0.410 у грі, то ви можете ігнорувати KB. Звертайтеся до бази знань лише в тому випадку, якщо ви оновилися до VxRail 7.0.410 з будь-якої іншої версії VxRail.
Якщо попередня перевірка оновлення диспетчера SDDC вже виявила цю проблему, також застосуйте ці кроки обхідного шляху.
Етапи обхідного шляху:
=================
1. Додайте наступний рядок до /etc/pam.d/common-account у VxRail Manager. (Використання консолі віртуальної машини в vCenter з root-аккаунтом, так як SSH з'єднання не працює)
account required pam_tally2.so
2. Розблокуйте містичного користувача, виконавши наступну команду в командній консолі VxRail Manager з обліковим записом root.
pam_tally2 --user mystic --reset
3. Після того, як mystic обліковий запис буде розблоковано, користувач повинен перевірити його та спробувати встановити сеанс SSH у VxRail Manager, використовуючи містичні облікові дані.
4. Перейдіть до попередньої перевірки оновлення домену робочого навантаження в диспетчері SDDC.
Additional Information
Користувач може шукати правильні паролі VxRail Manager з менеджера SDDC, виконавши команду lookup_passwords, як показано нижче.
root@sddc-manager-controller [ /home/vcf ]# lookup_passwords
Password lookup operation requires ADMIN user credentials. Please refer VMware Cloud Foundation Administration Guide for setting up ADMIN user.
Supported entity types: ESXI VCENTER PSC NSX_MANAGER NSX_CONTROLLER NSXT_MANAGER NSXT_EDGE VRSLCM VRLI VROPS VRA WSA BACKUP VXRAIL_MANAGER AD
Enter an entity type from above list: VXRAIL_MANAGER
Enter page number (optional):
Enter page size (optional, default=50):
Enter Username: administrator@vsphere.local
Enter Password:<password_of_administrator@vsphere.local>
VXRAIL_MANAGER
identifiers: 172.16.6.129,app01-vxrm.test.local
workload: app01-md
username: mystic
password: <passord_of_mystic>
type: SSH
account type: SYSTEM
VXRAIL_MANAGER
identifiers: 172.16.6.129,app01-vxrm.test.local
workload: app01-md
username: root
password: <passord_of_root>
type: SSH
account type: SYSTEM