Лохматим СХД HPE 3PAR 7200. Часть 4. Получаем доступ к сервисному меню 3PAR Console Menu для выполнения процедуры OOTB в контексте пользователя "console" или как обойти Time-based Passwords

В данной заметке мы рассмотрим вариант реализации последнего, четвёртого, пункта ранее намеченного плана по приведению двух-контроллерной HP 3PAR StoreServ 7200 в работоспособное состояние для возможности последующей эксплуатации. То есть, мы поговорим о том, каким образом можно получить доступ к сервисному меню ноды 3PAR Console Menu при прямом подключении к консольному порту, но с отсутствием пароля от встроенной учётной записи "console".

Итак, добравшись до процедуры сброса настроек "Out Of The Box" (OOTB), ранее описанным способом мы подключились к консольному порту одной из нод СХД и попытались выполнить вход из под имени учётной записи пользователя "console" с ранее известным предопределённым паролем "cmp43pd". Однако все попытки входа, в том числе и при подключении к консольному порты соседней ноды, завершались ошибкой "RtP_sE: error string is: access denied". Понимая то, что на СХД ранее никто из коллег не мог сменить пароль для данного служебного пользователя (тем более в штатных интерфейсах управления СХД для этого нет никакой возможности), возникло подозрение, что в актуальных версиях 3PAR OS что-то изменилось.

---

Изменение режима управления паролями в 3PAR OS

После чтения профильных форумов, онлайн-документации на сайте HPE, заметок к выпускам 3PAR OS и руководств к СХД, выяснилось то, что начиная с версии 3PAR OS 3.2.2 изменён подход к управлению сервисными учётными записями. Вместо ранее используемых статических паролей для таких пользователей, как "console" и "root", было введено динамическое управление паролями. При этом новый тип управления может выполняться в одном из двух режимов:

1) Time-based Passwords. Пароли меняются 1 раз в час на случайно сгенерированные и, как я понял, фактически такими паролями воспользоваться не получится. Данный режим является режимом по умолчанию и в этот режим автоматически переходит СХД в ходе обновления 3PAR OS до версии 3.2.2 и выше. 

2) Encrypted Ciphertext Passwords. При переключении в данный режим пароль также генерируется на временной основе и случайным образом, но уже использует обратимые механизмы шифрования. Этот режим может использоваться для взаимодействия со службой тех.поддержки HPE.

Например, в актуальной версии документа HPE 3PAR StoreServ Storage Concepts Guide упоминается об этих двух режимах и описывается способ получения временного пароля для пользователя "console". Предполагается, что если нам потребовался пароль "console", то мы специальной командой переключаем СХД во второй режим управления паролями, генерируем ciphertext пароля пользователя, передаём в HPE этот ciphertext и в ответ получаем временно действующий пароль. Ниже приведён пример ряда команд, которые потребуется выполнить.

Подключаемся по SSH к СХД от имени учётной записи "3paradm" и для начала запрашиваем текущий режим управления паролями:

3PAR02 cli% controlrecoveryauth status

Recovery authentication method is Time-based One-Time Passwords.

Как видим, на данный момент включен режим Time-based Passwords. Меняем режим управления на Encrypted Ciphertext Passwords. Обратите внимание на то, что при выполнении этой команды мы получим ошибку (ошибка воспроизводилась у меня как на 3PAR OS 3.2.2 так и на 3.3.1), но фактически режим должен переключиться.

3PAR02 cli% controlrecoveryauth setmethod ciphertext

Error changing authentication method: callers update returned failure

3PAR02 cli% controlrecoveryauth status

Recovery authentication method is Ciphertext.

Чтобы заново сгенерировать случайный пароль и получить его ciphertext для пользователя "console", можно выполнить последовательно команды:

3PAR02 cli% controlrecoveryauth rollcred console

Changed credentials for user console

3PAR02 cli% controlrecoveryauth ciphertext console

console:
--- Begin tpd blob ---
0100
92xb5bfe...
вывод усечён
...7b09a8c852f61
 --- End tpd blob ---

Сгенерировать таким образом ciphertext можно не только для пользователя "console", но и для пользователя "root". Хотя смысла в этом особого для нас нет, так как тех.поддержка HPE, скорее всего, не захочет выдавать пароль супер-пользователя (пусть даже и временный). Сгенерированный ciphertext (BLOB) передаём в тех.поддержку HPE и получаем от них в ответ временно действующий пароль пользователя "console".

Ситуация справедлива не только к линейке 3PAR 7000, но и к 3PAR StoreServ 8000: HP 3PAR StoreServ 8000 Storage - Using Strong Passwords 

При этом следует учесть пару важных моментов:

1) Ответит тех.поддержка HPE на запрос получения пароля по ciphertext только в том случае, если вы имеете действующий сервисный контракт на поддержку СХД.

2) Получаемый пароль является временным. После окончания работы в сервисном меню ноды и завершению сессии может оказаться так, что повторно с полученным от HPE паролем вы туда уже не зайдёте (есть непроверенная гипотеза, что пароль заново сбрасывается на этапе выхода).

---

Что же делать, если нет сервисного контракта с HPE?

Если оценить всю происходящую ситуацию в целом, то складывается впечатление, что компания HPE в очередной раз повела себя, как "закадычный друг". Нет, не как лучший друг,… а как тот самый "друг", который всё время "берёт за кадык". Ведь, посудите сами, ваша компания уже заплатила довольно серьёзные деньги при покупке СХД и вы, как технический специалист этой компании, предполагаете иметь полный административный доступ к своему оборудованию (пусть даже после окончания срока базовой гарантии или сервисного контракта, когда все риски по поддержке перекладываются с вендора на собственника оборудования). Но тут вдруг выясняется, что "предприимчивые" ребята из HPE под прикрытием лозунгов о повышении уровня безопасности вшили в ваше собственное оборудование такую вот Time-Bomb-фичу, которая "выстрелит" именно тогда, когда вы окажетесь вне рамок платной технической поддержки.

Если честно, я до последнего не хотел верить в такое и всё же открыл обращение в тех.поддержку HPE с запросом на получение пароля по сгенерированному ciphertext для СХД, по которой буквально пол-года назад закончился платный контракт поддержки. К моему большому разочарованию я получил от первой линии тех.поддержки HPE ответ о том, что они не будут передавать мой запрос на вторую техническую линию, ибо серийный номер СХД не связан ни с каким действующим сервисным контрактом. Моё последующее возмущение ситуацией и попытки воззвать к совести результата не дали.

В сухом остатке мы получаем ситуацию, в которой по окончании срока платной поддержки вендор блокирует доступ к таким сервисным стандартным процедурам с СХД, как System Wipe, OOTB, Node-to-Node rescue, SP-to-Node rescue. Вишенкой на торте во всей этой ситуации является то, что в Октябре следующего 2022 года HPE полностью прекращает поддержку СХД 3PAR 7000, так как наступает End of Service/Support Life (EOSL) для данной линейки оборудования. И можно предположить, что в дальнейшем на вторичном рынке железа появится приток подобных СХД и вопрос о таких сервисных процедурах, как OOTB, станет ещё более актуален.

В интернете можно найти не одно свидетельство того, как люди, оказавшись в такой ситуации, при поиске решения проблемы с отсутствующим доступом задумываются о даунгрейде 3PAR OS до версии ниже 3.2.2, где ещё использовались предопределённые статические пароли, с последующим возможным повторным поднятием версии 3PAR OS/VSP. Но мне такой вариант из-за своей сложности и меньшей предсказуемости не очень нравится, поэтому дальше мы рассмотрим альтернативный метод решения вопроса.

---

Выбор методики получения доступа к 3PAR OS

Если получить доступ к сервисному меню 3PAR Console Menu очень хочется, а контракта сервисной поддержки на СХД нет и не предвидится, то можно попробовать проработать вариант с получением доступа супер-пользователя по аналогии с тем, как мы уже делали ранее с виртуальной машиной Virtual Service Processor 4.3. Ведь 3PAR OS это ни что иное, как обычная по своей сути Linux-система (например, Debian Linux 9.4 в случае с 3PAR OS 3.3.1), которая, не смотря на кастомизированное ядро Linux и множество специализированных 3PAR-ориентированных утилит, имеет уже знакомую нам структуру файлов. В частности, на этапе процесса консольного входа в систему управляющий код 3PAR OS использует такие системные файлы, как /etc/passwd и /etc/shadow. Вот с этими файлами мы и будем работать.

В ходе первичного эксперимента на 3PAR OS 3.2.2 MU6 было выяснено, что пароли пользователей "root" и "console" хранятся в виде SHA-512 хеша в файле /etc/shadow и подмена этих хешей на хеш от заведомо известного нам пароля позволяет получить доступ к системе непосредственно из под этих пользователей. Однако после окончания пользовательской сессии (после выполнения logoff), пароли этих пользователей снова автоматически заменялись системой. То есть, повторно использовать ранее установленный пароль в случае необходимости не получится и такая методика не очень эффективна и удобна.

После обновления до версии 3PAR OS 3.3.1 MU5 описанное выше поведение системы снова изменилось. Теперь уже система не хранит хеши паролей пользователей в файле /etc/shadow (но всё также читает этот файл) и в случае подмены всё так же автоматически возвращает всё в исходную конфигурацию. В ходе дополнительных экспериментов стало очевидно, что трогать предопределённые учётные записи пользователей "root" и "console" вообще не стоит, так как система бдительно за ними наблюдает и вносит свои корректировки. Вместо этого, более действенным решением оказалось добавление отдельного нового пользователя с root-привилегиями. Далее последовательно опишем процедуру добавления такого пользователя с последующим получением доступа к сервисному меню 3PAR Console Menu.

---

Получаем доступ к сервисному меню 3PAR Console Menu

Для снижения вероятности нештатного поведения нод 3PAR, перед началом процедуры произведём полное выключение СХД. Выключить СХД можем либо через интерфейсы управления VSP, либо при подключении по SSH к СХД от имени учётной записи "3paradm" командой:

3PAR02 cli% shutdownsys halt

Подождав ~ 5 минут после выполнения команды выключения, в правильной последовательности отключаем блоки питания СХД (сначала отключаем питание головной СХД, затем отключаем питание дополнительных корзин расширения).

После того, как СХД обесточена, извлекаем первую ноду (например Node 0) из СХД, открываем крышку корпуса и отключаем от SATA-коннектора встроенный SSD-накопитель (в нашем случае это SanDisk X110 64GB). На этом накопителе и размещена интересующая нас операционная система 3PAR OS.

Далее, нам потребуется компьютер с Linux-системой, в которой мы смонтируем разделы снятого SSD-накопителя и выполним offline-редактирование нужных нам системных файлов 3PAR OS. В нашем примере в качестве такого компьютера выступил старенький ноутбук c ОС Linux Mint 19 (с графическим окружением Cinnamon), к которому SSD-накопитель с 3PAR OS был подключен через SATA-to-USB переходник во внешнем 2,5" корпусе Kingston SNA-DC/U.

При этом важно аккуратно подключать и правильно извлекать SSD-накопитель с 3PAR OS в Linux-системах, где настроено автоматическое монтирование USB-накопителей. Обращаю на это отдельное внимание, так как в ходе моих экспериментов было замечено, что некорректное размонтирование накопителя (извлечение без предварительного использования функции "безопасного отключения" USB-накопителя) может оставить в метаданных разделов 3PAR OS некоторый "мусор", который в дальнейшем может привести к невозможности загрузки этих разделов при запуске ноды в СХД.

В нашем примере при подключении SSD-накопителя к USB-порту ноутбука ОС Linux Mint автоматически смонтировала 3 раздела c метками root0, root1 и log:

Откроем в Linux системе консоль, перейдём в root-режим и более внимательно изучим информацию о разделах на SSD-накопителе, используя для этого такие команды, как:

$ sudo su -
# lsblk -o TYPE,VENDOR,MODEL,NAME,LABEL,FSTYPE,SIZE,MOUNTPOINT
# df -h

Здесь мы увидим, что все три появившихся в графической оболочке раздела автоматически смонтированы с файловой системой ext3 и имеют в нашем примере точки монтирования в подкаталоге /media/{username}.

---

Прежде, чем приступать к редактированию каких-либо файлов, мы можем на всякий случай сделать полный дамп всего содержимого SSD-накопителя. Сделать в Linux это можно разными способами, но мы выберем самый простой и доступный - с помощью утилиты dd. Не смотря на то, что объем занимаемого данными места на разделах 3PAR OS не особо велик, при создании дампа будет выполнено сохранение всех секторов SSD-накопителя (в том числе и пустых). Поэтому для сохранения одного такого дампа нам потребуется 64GB дисковой ёмкости на другом накопителе. В нашем случае у ноутбука не оказалось нужного объема свободного места под дампы (128GB для снятия дампа с накопителей обоих нод 3PAR), поэтому через другой SATA-to-USB переходник был подключен дополнительный временный SSD-диск большого объема с NTFS-разделом (с точкой монтирования раздела в подкаталог /media/aleksey/986E7A...). В итоге в нашем примере команда снятия дампа будет выглядеть следующим образом:

# dd if=/dev/sdb of=/media/aleksey/986E7A1B6E79F27C/Backup-3PAR02-Node0.img status=progress

Здесь в опции "if" указываем путь к устройству, с которого снимаем дамп, в опции "of" указываем путь к файлу, в который сохраняем дамп, а опция "status" пригодится для включения отображения хода снятия дампа. Важно не перепутать местами опции "if" и "of", иначе мы можем потерять данные с важного для нас накопителя.

Учитывая ограниченную скорость интерфейса USB, процесс снятия дампа может занять длительное время и следует дождаться его штатного окончания, не делая резкий движений. При этом, если под данную задачу будет использоваться, как и в нашем примере, ноутбук, то лучше заблаговременно озадачиться полной зарядкой его батареи с подключением к постоянному источнику электропитания (батарея может не выдержать многочасового активного использования нескольких USB-интерфейсов).

---

После того, как мы подстраховались и сделали резервную копию содержимого SSD-накопителя, переходим к работе с файлами в разделе с меткой root0, смонтированном в нашем примере в подкаталог /media/aleksey/root0.

Для того, чтобы просмотреть текущий список системных пользователей 3PAR OS воспользуемся командой типа:

# cat /media/aleksey/root0/etc/passwd

Как видим из вывода по второму параметру "x" в строках о пользователях "root" и "console", данные о паролях этих пользователей хранятся в файле /etc/shadow. Каждый из этих пользователей имеет свою кастомизированную оболочку в подкаталоге /opt/tpd/bin. Также характерной особенностью является то, что для пользователя "console" в качестве домашнего каталога указан подкаталог /home/console, которого на самом деле не существует в файловой системе. 

Откроем на редактирование файл passwd:

# nano /media/aleksey/root0/etc/passwd

По аналогии с пользователем "root" в любом месте файла добавим новую строку, в которой опишем собственного пользователя, например с именем "custroot". В качестве 3 и 4 параметра строки укажем "0", чтобы у нас были права супер-пользователя. В 6 параметре (по аналогии с пользователем "console") можем указать несуществующий домашний каталог /home/custroot. А в 7 параметре в качестве оболочки укажем тот же исполняемый файл, что и у пользователя "root", то есть /opt/tpd/bin/shellwrapper. В итоге получим запись примерно следующего вида: 

Последовательным сочетанием клавиш Ctrl-O, Enter затем Ctrl-X, сохраним изменения и закроем файл.

Затем откроем на редактирование файл shadow:

# nano /media/aleksey/root0/etc/shadow

Добавим в файл дополнительную строку, описывающую пароль нашего нового супер-пользователя по аналогии со строкой "root" с одним лишь отличием. У пользователя "root" в качестве второго параметра указана звёздочка "*", что означает то, что прямой вход для данного пользователя по паролю запрещён. В отличие от этого, для нашего нового пользователя "custroot" мы в этом месте укажем SHA-512 хеш известного нам пароля.  

На скриншоте хеш пароля немного усечён (для читаемости скриншота), поэтому приведу отдельно готовую запись, которую можно использовать с другим, заведомо рабочим хешем для пароля "P@ssw0rd":

custroot:$6$5wdct.rr$U7jffLhmKqPZZdf4gHD80wEYBVvOsYYx3zMFkx7F5B3dlwtuXfgsc.le4xKaj7JL2ZzjhDK.CYXv7Wpn7b4q20:17714:0:99999:7:::

Сохраняем изменения в файле и закрываем текстовый редактор.

Кстати, есть мнение, что сгенерировать работающий для файла shadow SHA-512 хеш пароля можно с помощью актуальной версии утилиты openssl, выполнив команду вида:

openssl passwd -6 MyPa$sw0rd

---

Теперь, как я и говорил ранее, нам необходимо убедиться в том, что никакие другие файлы с разделов root0/root1/log не открыты нами на редактирование и безопасно извлечь носитель, подключенный через USB.

Отключаем SSD-накопитель от нашего Linux-компьютера и подключаем его обратно к SATA-коннектору в ноде 3PAR.

---

Всю описанную процедуру повторяем для второй ноды СХД (Node 1), то есть извлекаем из ноды SSD-накопитель и подключаем его к сторонней Linux-системе, при желании снимаем дамп SSD-накопителя и редактируем файлы /etc/passwd и /etc/shadow на разделе с меткой root0, затем безопасно извлекаем SSD-накопитель и возвращаем его в ноду.

Практика показала, что ни в версии 3PAR OS 3.2.2 MU6, ни в версии 3.3.1 MU5, в СХД не проявляется механизм, который бы как-то оперативно синхронизировал данные о дополнительно созданных Linux-пользователях, поэтому процедуру корректировки файлов нужно выполнять на обоих нодах. Конечно, это даёт возможность вообще сделать разных пользователях с разными паролями на двух нодах, но для меньшей путаницы лучше сделать одинакового пользователя с одинаковым паролем на обеих нодах. Наличие одинакового логина/пароля на обеих нодах может оказаться полезным, когда в дальнейшем мы захотим подключаться с этими учётными данными к СХД по SSH (в этом случае управляющий код СХД может подключать нас то к одной ноде кластера, то к другой, в зависимости от обстоятельств).

---

После того, как обе ноды откорректированы, вставляем их обратно в СХД, подключаем при необходимости дисковые корзины и выполняем запуск с правильной последовательностью включения компонент. То есть сначала подаём питание на дополнительные дисковые корзины, ждём 1-2 минуты, затем включаем блоки питания на самой СХД.

После нашей корректировки накопителей с 3PAR OS, лучше дополнительно удостовериться в том, что ноды стартуют без явных проблем. Наблюдать за процессом запуска нод можем с помощью ранее упомянутого прямого подключения на консольный порт любой из нод. По крайней мере здесь мы должны увидеть, что мы не повредили своими действиями разделы накопителя и 3PAR OS стартует успешно и загрузка доходит до приглашения ввода учётных данных.

По окончанию успешной загрузки 3PAR OS попытаемся войти в систему с именем пользователя и паролем, который мы добавили в систему ранее ("custroot").

Как видим, вход с правами супер-пользователя выполнен успешно.

В данном примере мы проверили вход на нулевую ноду (Node 0). Переключим консольный кабель на порт управления соседней ноды (Node 1) и повторим проверку успешного входа на этой ноде.

Если в ходе добавления пользователя мы использовали простой словарный пароль, то после первого успешного входа в систему самое время сменить этот пароль на более серьёзный уже используя стандартную Linux-утилиту составе 3PAR OS – passwd. Ну и как уже оговаривалось выше, данную процедуру необходимо выполнить (повторить) на каждой ноде СХД по отдельности.

После этого мы можем проверить то, что с настроенной нами учётной записью супер-пользователя мы можем подключаться не только при прямом консольном подключении на любую из нод СХД, но и при удалённом доступе по протоколу SSH. Разумеется, при этом стоит понимать, что излишнее злоупотребление данной возможностью – не самая лучшая идея. К тому же, следует вспомнить о том, что изначальной целью в нашем случае был всё же не root-доступ, а получение доступа к сервисному меню 3PAR Console Menu.

Само собой разумеется, что обладая полными привилегиями в системе, мы беспрепятственно можем запустить оболочку сервисного меню (вспомним про исполняемый файл /opt/tpd/bin/console_menu, который указан в качестве шелл-оболочки для служебного пользователя "console" в файле /etc/passwd). Однако следует воздерживаться от подобных шагов и помнить о том, что запуск той или иной сервисной задачи 3PAR должен выполняться в контексте правильного пользователя, то есть того пользователя на которого ориентировались разработчики сервисного меню. Поэтому более правильным способом получения конечного доступа к сервисному меню будет переход в контекст служебного пользователя "console" с помощью команды "su"следующим образом:

# su - console

Как видим, мы успешно переключились в контекст пользователя "console", и, согласно стандартным настройкам 3PAR OS, для данного пользователя автоматически при входе в систему было вызвано сервисное меню 3PAR Console Menu (вызов того самого /opt/tpd/bin/console_menu).

На данном этапе поставленную задачу по получению доступа к сервисному меню можно считать выполненной.

---

Нюансы использования сервисного меню 3PAR Console Menu

В дальнейшем мы сможем использовать все функции сервисного меню 3PAR Console Menu по их прямому назначению. Однако, при этом следует помнить про некоторые не совсем очевидные нюансы:

1) Не следует пытаться выполнять задачи сервисного меню, используя SSH-подключение к СХД, не смотря на то, что теперь такая возможность у  нас появилась. Подумайте, например о том, что будет, когда вы попытаетесь выполнить процедуру System Wipe/OOTB, используя удалённое подключение к СХД. Помните про то, что всё таки сервисное меню следует рассматривать, как инструмент с прямым консольным подключением к какой-либо из нод СХД.  

2) Некоторые типы задач сервисного меню при штатном вызове (без использования трюка с root-входом с последующим переключением в нужный контекст с помощью "su") работают по принципу пошагового рабочего процесса с автоматическим запуском одной задачи из другой задачи. Например, тот же пункт "6. Set up the system to wipe and rerun ootb" при штатном вызове сначала выполняет небольшую подготовку СХД к очистке, затем автоматически перезагружает ноду СХД, а после перезапуска автоматически запускает мастер процесса OOTB (то есть задачу из 1 пункта меню). Но если мы вызовем этот же 6 пункт меню с помощью предварительного root-доступа с переключением в контекст пользователя "console", то после отработки первого шага и автоматической перезагрузки ноды мы снова вернёмся к стандартному приглашению входа в 3PAR OS. В этом случае нам следует снова добраться до сервисного меню и вручную запустить продолжение начатого процесса сброса настроек (запустить процедуру OOTB из пункта меню "1. Out Of The Box Procedure").

Здесь, также стоит отметить то, что довольно полезный пункт меню "10. Check system health (checkhealth)" на любом этапе поможет нам понять то, что сейчас происходит с СХД и то, что 3PAR OS от нас ждёт в данный момент времени. В общем-то этот пункт мне и помог отловить ситуацию с 6 пунктом меню, выполняющимся в несколько этапов. Ну и думаю, не лишним будет напомнить про то, что любая сервисная задача должна начинаться с предварительной проверки состояния СХД с помощью checkhealth.

---

Замеченные особенности OOTB

Если ранее СХД была подключена к действующему серверу управления Virtual Service Processor, то перед выполнением процедуры OOTB желательно отключить СХД от VSP.

Перед запуском таких процедур, ка System Wipe/OOTB желательно сохранить информацию о всех активированных на СХД лицензиях, чтобы в случае её стирания у нас была возможность восстановления функциональности СХД. О том, как это можно сделать, мы писали ранее в заметке Вики - Как сохранить и восстановить лицензионные ключи в 3PAR OS на СХД HP ЗPAR 7200.

Сама по себе процедура OOTB в версии 3PAR OS 3.3.1 в целом схожа с ранее описанной на примере 3PAR OS 3.1.3. И, наверно, единственным непонятным шагом в этой процедуре может оказаться дополнительный вопрос, который задаётся в самом конце мастера OOTB относительно того, какой механизм для управления паролями сервисных пользователей 3PAR OS мы хотим выбрать – totp или cipher. Про оба эти механизма мы уже упомянули в начале данной заметки. Замечено то, что если выбрать chiper, то мы можем получить внутреннюю ошибку, похожую на ту, что мы обозначили выше после выполнения команды "controlrecoveryauth setmethod ciphertext". И после этой ошибки работа мастера OOTB будет завершена как-то не совсем понятным образом (не до конца ясно то, как это влияет на финальную работу OOTB). Поэтому на данном этапе я рекомендую выбирать вариант totp, который не вызывает подобной ошибки и, как следствие, мастер OOTB завершается штатно.

К тому же, теперь, когда мы уже имеем полноценный административный доступ к своей СХД, нам, по большому счёту индифферентно то, какие там костыли будет использовать 3PAR OS для управления своими горячо-любимыми пользователями "root"/"console".

В версии 3PAR OS 3.2.2 было замечено странное поведение системной задачи "OOTB_stress" (двух часовой стресс-тест всех накопителей, запускающийся в ходе OOTB). Задача сначала висела длительное время (больше суток), как выполняющаяся, а при попытке её отмены по ID процесса мы получали сообщение о том, что такого процесса не существует. После обновления 3PAR OS до версии 3.3.1 и проверочного повторения процедуры OOTB такой проблемы замечено уже не было и в ходе OOTB аналогичная задача отработала в предсказуемом режиме.

Отследить статус системной задачи "OOTB_stress" можно либо командой "showtask", либо в графической консоли управления HP 3PAR Management Console.

И пока задача первичного стресс-теста дисков, запущенная из процедуры OOTB не будет завершена, лучше не браться за такие операции, как конфигурирование CPG/Virtual Volumes.

Стоит помнить также и про то, что в ходе процедуры OOTB, происходит регенерация цифровых сертификатов, хранимых в СХД и используемых для защиты протоколов управления. То есть, в ходе сброса настроек сертификат заменяется в нодах на само-подписанный. Поэтому перед тем, как вновь подключать СХД к серверу управления VSP, мы можем заменить этот сертификат методом, описанным ранее в статье Вики - Замена само-подписанного SSL-сертификата на СХД HPE ЗPAR 7200.