Hp ilo настройка linux

Обновлено: 06.07.2024

Случалось у каждого, что терялся доступ к iLO, менялся IP или просто забывался, но при этом нарушать работу сервера перезагрузкой не очень хочется.

Для этого случая можем воспользоваться утилитой hponconfig, непосредственно с установленной Linux системы на борту.

Установим

yum install hponcfg

apt-get install hponcfg

Импортируем текущие конфигурации в файл

hponcfg -a -w iloout.cfg

Настройки хранятся в читаемом XML формате, поэтому не составит особого труда в них разобраться.

Для того, чтобы назначить статический IP-адрес, необходимо изменить настройки:

После внесения всех изменений импортируем настройки.

hponcfg -f iloout.cfg

Добавим пользователя

Сформируем новый файл user.cfg с содержимым:

HP Lights-Out Online Configuration utility
Version 4.2.0 6/10/2013 (c) Hewlett-Packard Company, 2013
Firmware Revision = 1.22 Device type = iLO 4 Driver name = hpilo
Script succeeded

Теперь можем авторизоваться с новым логином/паролем в панели iLO.

Модификация существующего пользователя

Для модификации существующего пользователя, сфорумируем файл user_modify.cfg

По завершении редактирования также экспортируем настройки, как было выполнено на прошлом шаге.

Приветствую. Меня зовут Эдуард, и я системный администратор в небольшой компании, которая аутсорсит администрирование ИТ-инфраструктуры. Кхм… Уже похоже на клуб анонимных кого-то с проблемами? Ну да ладно, одна интересная проблема у нас действительно была, а сегодня мы расскажем, как мы с ней столкнулись, и как случайно её решили.

Для начала немного предыстории. Все же помнят, как весело было админить удалённое железо раньше, лет 5-8 назад? Пишем заявку инженерам в ДЦ, ждём, когда они подключат KVM, настраиваем BIOS/CMOS, выставляем загрузку по сети, ставим систему (это хорошо, если кто-то добрый уже написал генератор preseed/kickstart-файлов, и в ДЦ есть DHCP/PXE сервер). А потом у нас на всех серверах появился ipmi (ну со временем). Ох, как мы радовались первое время!

ipmi -U user -P password power up -H XXX ipmi -U user -P password password bootdev pxe -H XXX ipmi -U user -P password power reset -H XXX

И сервер уже вроде бы ставит ОС. Остаётся только наблюдать за этим в консоли, если скучно. Огорчало только то, что BIOS всё равно приходилось обновлять руками и настраивать (ну там HT/VT-d включить, хотя бы). В итоге все серверы были настроены по-разному, в зависимости от того, в каком квартале их ставили. Ну вы же понимаете, что серверы всегда ставил самый младший админ.

Потом мы, как обычно, ТЗ решили прочитать. Нашли там всякие интересные пункты, которые мы (ну те, кто делал задачу, а не те, кто ТЗ подписывал и пересказывал его нам) увидели впервые. Например, мониторинг температуры в обход ОС, мониторинг потребления электричества, автоматическая настройка BIOS… Начали размышлять. Сначала склонялись к мысли, что ipmi всё это может. Потом представили, как всё это будет выглядеть. Подумали про то, как обновлять настройки, про мониторинг датчиков… В общем, разошлись на выходные с задачей «изучить весь гугл на предмет альтернатив ipmi, которые могут».

Приходим в понедельник, все грустные, злые. А один админ сидит и улыбается. Логичным было пристать к нему с расспросами на тему того, зачем он читает ithappens, когда у нас такая беда. Как оказалось, радовался он по поводу того, что читал не ithappens, а Redfish server management spec v 1.0 (читать здесь). Почитали все вместе вслух, злиться перестали. Redfish оказался именно тем, что нам нужно. Взяли менеджера, заставили его обзванивать всех производителей серверов, чтобы найти железку, в которой Redfish реализован. Приходят через час и смеется, показывает пальцем на коробку у входа и говорит «всё, я нашел». Собственно, коробка оказалась коробкой от HP Proliant Gen9. Сервер мы нашли, вернули в лабораторию (и кто вообще догадался новенький неизученный сервер сразу в ДЦ везти…) и приступили к знакомству с HP REST API (которая и является реализацией Redfish в серверах HP).

Так как мы админы (это потом уже нам дали питониста и он нам всё написал и сделал красивый web-интерфейс), то первым делом мы сели писать sh-ники, которые будут делать то, что нам нужно. Конечно, мы бы не советовали ходить в Rest API консольным curl-ом и генерировать JSON через echo (ну или хотя бы потом не показывайте никому это), но вот поделиться примерами взаимодействия с HP ProLiant REST API будем рады (тем более, что сами представители HP нас об этом и попросили).

Возможностей там полно на самом деле, в документации 2 сотни страниц списка объектов и краткого их описания. Мы первым делом пытались выполнить свои основные задачи, как proof-of-concept. Конечно, часть из них можно делать и через IPMI, но мы решили использовать один инструмент, именно API.

Первым делом (ну хорошо, вторым, после подключения сервера в стойке и после того, как HP iLO получит IP-адрес), прописываем все настройки BIOS:

Научимся управлять питанием. Ребут «по кнопке»:

«Выдёргиваем кабель из розетки»:

Отправляем инженера «нажать кнопку питания»:

Спросим у сервера, кто он такой:

PATCH-запросом в эту же ручку можно изменить информацию о сервере внутри iLo.

Из предыдущего JSON-а мы вытаскивали также и количество памяти с моделью CPU, потом разработчики сделали интеграцию с 1С, сервер отправлял данные о себе и туда. Здесь же мы определяли и версию BIOS, чтобы ругаться об устаревших (или просто отличающихся по кластеру) версиях.

Ещё через REST API можно снять показания метрик питания (к сожалению, не во всех «уровнях» лицензии iLO):

А ещё нашли объект, который говорит о состоянии сервера в целом (ОК/fail) и чем он сейчас занимается (в нашем примере он загружался):

В общем, sh-ник мы в итоге написали и отдали его разработчику. Он над нами посмеялся, мы его за это поругали, пригрозили рута отобрать… Но зато он потом написал модуль в наше облачко, который умеет добавлять и управлять серверами через Redfish (и HP REST API, соответственно). Ну а заказ мы в итоге выполнили.

Наверное, пора закругляться. Расскажем про тех, кто играл главные роли во всей это истории.

В этой заметке мы рассмотрим пример того, как установить утилиты управления HPE System Management Tools на сервер HP ProLiant DL380 G5 с установленной ОС Debian GNU/Linux 9.3 'Stretch'. В целом процесс схож с рассмотренным ранее примером для CentOS Linux 7, но имеет свои особенности.

Подключаем репозиторий HPE MCP (Management Component Pack)

Создаём в профиле текущего пользователя временный каталог, скачиваем в него скрипт add_repo.sh и делаем его исполняемым:

Запускаем скрипт в "холостом" режиме с указанием имени интересующего нас репозитория HPE MCP (Management Component Pack) (" mcp ") и опцией -n (опция покажет планируемые изменения в системе, без их фактического применения)

Как видим, в рабочем режиме работы скрипт создаст файл /etc/apt/sources.list.d/HP-mcp.list и добавит в него информацию о соответствующем репозитории для нашей версии Debian Linux:

Выполняем скрипт в рабочем режиме (убираем опцию -n )

В таком режиме работы скрипт предложит нам прочитать и принять лицензионное соглашение HP EULA

Проверяем созданный файл /etc/apt/sources.list.d/HP-mcp.list

Чтобы в дальнейшем с установкой пакетов не было проблем по причине того, что локальный менеджер пакетов не доверяет ключам, которыми подписаны пакеты из репозиториев HPE,
добавим эти ключи в систему, воспользовавшись рекомендацией из Package Signature Verification :

Просмотреть ключи, которые были добавлены с сайта HPE в наш менеджер пакетов можно так:

Теперь можно приступить к установке пакетов из подключенного репозитория.

Устанавливаем пакеты HPE

Выполним обновление кеша менеджера пакетов

Посмотрим то, какие пакеты нам доступны из подключенного репозитория HPE

Обратите внимание на то, что диагностический пакет hpdiags, присутствующий в репозитории для RHEL/CentOS в репозитории для Debian отсутствует, а современная версия утилиты Smart Storage Administration Utility имеет имя пакета не hpssa, а ssa.

Выполняем установку интересующих нас пакетов:

Среди зависимостей будет установлен пакет snmpd, который запустит на нашем сервере службу snmpd.service, отвечающую на запросы по протоколу SNMP.

Настраиваем службу SNMP

После окончания установки запускаем утилиту, которая сконфигурирует службу snmpd для работы с веб-приложением HP System Management Homepage.

На первый вопрос о том, хотим ли мы использовать имеющийся конфигурационный файл snmpd.conf, отвечаем отрицательно (n), чтобы утилита сама наполнила этот файл нужным содержимым.

После этого утилита задаст ряд вопросов, касающихся настройки службы snmpd, на которые нам нужно будет ввести соответствующие данные. В частности, можно задать строку подключения SNMP для RW/RO доступа и т.п., хотя обязательным является только ввод строки для RW доступа, а остальные значения можно оставить ненастроенными и предлагаемыми по умолчанию, в том случае если служба snmpd.service будет использоваться только для нужд HPE System Management Homepage и работать только на кольцевом интерфейсе (Loopback) с адресом 127.0.0.1.

По окончанию опроса введённые данные будут записаны в конфигурационный файл /etc/snmp/snmpd.conf и служба snmpd.service будет запущена с этими параметрами.
Если мы заглянем в файл snmpd.conf , то увидим внесённые туда изменения в начале файла:

Все остальные включённые по умолчанию параметры файла snmpd.conf , которые расположены ниже секции вписанной утилитой hpsnmpconfig, насколько я понимаю, можно закомментировать.
В качестве исключения я оставил лишь строку описывающую UDP-прослушиватель (работаем и отвечаем на SNMP-запросы только на кольцевом интерфейсе) и в конце файла добавил параметр, отключающий логирование (чтобы не засорять syslog).

После внесения изменений в snmpd.conf перезапустим службу snmpd

Для того, чтобы проверить то, что на кольцевом интерфейсе snmpd успешно отвечает на запросы поставим в систему пакет с утилитами для работы с SNMP и выполним пару таких проверок:

Дополнительно проверим, включён ли автоматический запуск службы snmpd при запуске системы:

Если по какой-то причине автоматический запуск не включён, включаем:

Запускаем утилиты управления HPЕ и проверяем их работу

Теперь запускаем службы HPE и убеждаемся в том, что при их запуске нет никаких ошибок

Обратите внимание на то, что в целях безопасности утилита HPE Smart Storage Administrator (SSA) ( /usr/sbin/ssa ) по умолчанию не запущена, так как она не носит характер инструмента постоянного использования, и поэтому, в случае необходимости доступа к SSA через веб интерфейс SMH, запускать это приложение нужно отдельно c последующим перезапуском службы hpsmhd.service.

Соответственно, после того как утилита SSA уже не нужна, можно выполнить остановку её запущенного экземпляра командой:

Далее включим автоматический запуск служб при загрузке системы:

Теперь пробуем удалённо подключиться к веб-странице SMH через веб-браузер по адресу:

Для входа на SMH используем данные учёной записи с правами администратора сервера. Обратите внимание на то, что для успешной авторизации пользователь должен входить в группу root. Это подтверждается практическими экспериментами и старым документом HP System Management Homepage Software - Cannot Login as Root on Linux Server .

После успешной авторизации мы получим доступ к информации о текущем состоянии нашего сервера:

Однако здесь мы можем обратить внимание на то, что количество информационных модулей о состоянии аппаратных узлов сервера может быть ощутимо меньшим, чем например, в рассмотренном ранее примере с CentOS Linux 7. C чем это связано, мне выяснить не удалось, однако могу сказать, что для получения дополнительной информации по тем компонентам сервера, которые недоступны в веб-консоли SMH, мы можем воспользоваться утилитами командной строки, которые мы рассмотрим далее.

Если веб-приложение HPE Smart Storage Administrator (ssa) нами ранее было запущено, то в разделе Storage нам будет доступно управление дисковой подсистемой сервера, основанной на RAID контроллерах HP Smart Array

На этом польза от веб-консоли HPE SMH в Debian, пожалуй, и заканчивается.

Если возникнет желание разбираться с кастомизацией SMH, то основной конфигурационный файл можно найти здесь: /opt/hp/hpsmh/conf/smhpd.conf . Возможно будет полезна информация из логов, которые генерирует SMH. Логи access_log и error_log можно обнаружить в каталоге /var/spool/opt/hp/hpsmh/logs

Далее мы кратко рассмотрим возможности некоторых утилит командой строки, поставляемых в составе установленных нами ранее пакетов из репозитория HPE MCP.

Утилита командной строки hpasmcli

Утилита HPE management CLI for Linux (hpasmcli) позволяет нам из Linux-системы управлять некоторыми параметрами сервера, обычно задаваемыми через BIOS, а также получать разнообразную информацию, пригодную для целей инвентаризации и мониторинга состояния аппаратных компонент сервера. Утилита имеет иерархический набор встроенных команд, узнать о которых можно командами HELP , HELP SHOW , HELP SET и т.п.

Утилита умеет принимать в качестве входного параметра через опцию -s разнообразные встроенные команды (без входа в интерактивный режим работы с утилитой). Например, чтобы получить общую информацию о сервере, можно вызвать утилиту следующим образом:

Другой пример – давайте получим информацию о состоянии модулей памяти. Воспользуемся при этом фильтрацией вывода, чтобы отбросить лишнюю информацию:

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

Аналогичным образом можно получать информацию о состоянии практически всех основных узлов сервера, и даже читать встроенный аппаратный лог IML:

Утилита командной строки hplog

Утилита hplog, предназначенная в основном для работы с встроенным аппаратным логом IML, также имеет ряд опций, позволяющих использовать её в качестве средства получения информации о текущем состоянии аппаратных узлов сервера.

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

Утилита командной строки hponcfg

В некоторых ситуациях может пригодится ещё одна утилита - HP Lights-Out Online Configuration utility (hponcfg). Она может дать нам информацию о текущей версии firmware контроллера iLO, позволяет управлять всеми настройками iLO через специально подготовленные файлы (простейший пример рассматривался ранее ) и даже даёт нам возможность сброса всех настроек iLO до состояния "factory defaults" (такое иногда тоже бывает нужно):

Утилита командной строки ssacli

Помимо того, что в веб-консоли SMH нам доступно выше упомянутое веб-приложение Smart Storage Administrator (ssa), в доступном нам инструментарии имеется мощная утилита командной строки Smart Storage Administrator CLI (ssacli). Эта утилита позволяет выполнять все действия по управлению RAID-контроллерами HP Smart Array. Утилита имеет иерархический набор встроенных команд, узнать о которых можно из встроенной справки командами help , help create , help delete и т.п.

С точки зрения инвентаризации и мониторинга состояния дисковой подсистемы сервера, может быть полезен набор команд show, узнать о возможностях которого можно соответствующей командой help show.

С утилитой ssacli можно работать как в интерактивном режиме, так и путём разовых вызовов с передачей в качестве параметров набора внутренних команд. Например, чтобы, не входя в интерактивный режим работы с утилитой, получить информацию об установленных в сервере контроллерах Smart Array, а также их текущем состоянии, можно выполнить команды вида:

Другой пример – давайте получим информацию о состоянии всех аппаратных компонент, связанных с контроллером Smart Array расположенном с слоте " 1 " (из предыдущего скриншота). Воспользуемся при этом фильтрацией вывода, чтобы отбросить пустые строки:

Как видим, здесь нам доступна информация о текущем состоянии портов контроллера Smart Array, подключенных к нему дисковых корзин, физических дисков, RAID-массивов и их логических дисков. Чтобы получить максимально развёрнутую информацию об аппаратных компонентах, можно воспользоваться командой типа:

Конфигурационные возможности этой утилиты оставим "за кадром", так как описание этой функциональности - тема для отдельного разговора. К тому же встроенная в утилиту справка в большинстве случаев даёт достаточный минимум информации для того, чтобы разобраться с работой этой утилиты самостоятельно.

В том случае, если в сервер установлены устаревшие модели контроллеров HP Smart Array, утилиты ssa и ssacli нам могут не помочь, так как в них реализована поддержка далеко не всей линейки Smart Array, и старые контроллеры не будут определяться этими утилитами. О том, как быть в такой ситуации, мы поговорим в следующей заметке об использовании старых версий утилит HP Array Config Utility (cpqacuxe) и HP Array Configuration Utility CLI (hpacucli) в Debian GNU/Linux 9 'Stretch'.

10.11.2020

HP, Linux, VMWare, Windows Server 2016

Один комментарий

При наличии физического доступа к серверу HPE, вы можете перезагрузить хост и при загрузке сервера нажать клавишу F9, чтобы перейти в меню настройки RBSU.

Затем нужно выбрать System Configuration -> iLO 4 Configuration Utility.

Для управления пользователями iLO перейдите в User Management.

Затем выберите Edit/Remove User -> Edit.

По умолчанию имя встроенной учётной записи в iLO – Administrator (регистро-зависимо).

Выберите пункт меню Password и укажите новый пароль.

Сохраните изменения, нажав F10. Пароль администратора iLO изменен. Можете продолжить нормальную загрузку сервера.

Основные недостатки такого метода сброса пароля: приходится подключаться к консоли сервера (идти в серверную) и требуется полная перезагрузка операционной системы.

Утилита hponcfg позволяет из локальной командной строки на сервере изменить любые настройки iLO без перезагрузки сервера.

Далее мы покажем, как с помощью hponcfg сбросить пароль iLO из Windows, Linux и VMWare ESXi.

Сброс пароль HP ILO из Windows

Чтобы сбросить пароль администратора iLO из Windows, нужно скачать и установить пакет HP Lights-Out Configuration Utility SP70865.exe (если он еще не установлен) для вашей версии Windows.

С помощью HP Lights-Out Online Configuration Utility вы можете также сменить сетевые настройки интерфейса iLO (IP адрес, шлюз, подсеть), импортировать/экспортировать и сбросить конфигурацию.

Также можно воспользоваться утилитой командой строки hponcfg.exe.

Сначала нужно сохранить текущую конфигурацию ILO в xml файл:

hponcfg.exe /w current_config.xml

Затем создайте новый XML файл reset_admin_password.xml с текстом:

Чтобы применить к iLO конфигурацию с новым паролем, выполните:
hponcfg.exe /f reset_admin_password.xml /l hplog.txt

Сброс пароль HP ILO из Linux

Для установки hponcfg в CentSO/RHEL используется менеджер пакетов yum/dnf:

Создайте XML файл с новым паролем администратора iLO:

Затем примените новый пароль к плате управления HPE iLO:

Сброс пароль HP ILO из VMWare ESXi

Для сброса пароля iLO из VMWare ESXi также нужна утилита hponcfg. Если вы используете кастомный образ ESXi от HPE, эта утилита уже установлена (/opt/hp/tools/ hponcfg).

Если утилиты нет, скачайте HPE ESXi Utilities Offline Bundle для вашей версии ESXi:

Перезагрузите хост командой:

Создайте текстовый файл reset_ilo_password.xml (как описано выше) с новыйм паролем iLO и примените его:

Через минуту плата iLO применит новую конфигурации и сможете авторизоваться на ней с новым паролем.

Вступление от HP: эта публикация написана одним из наших заказчиков, который по долгу службы пожелал остаться анонимным. Все совпадения имён и айпишников считать случайными. Попробовать сделать то же самое можно в любое время в нашем демо-центре в Москве — желающих просим писать в комментарии.

Когда мы находили что-то критичное – мы шли и руками переключали настройки. Бардак, да и только. Но вообще всё это нас устраивало до того, как с нами случилась история, о которой я сегодня и буду рассказывать.

Стоит упомянуть, что часть клиентов мы размещаем прямо на своём железе (точнее на виртуалках на этом железе, которое рулится через <зачеркнуто печатью с большими буквами NDA>). Ну чтобы вам было легче представить – наша система сильно похожа на OpenStack. И вот, в один прекрасный день, к нам пришел заказчик и попросил «на его железе сделать систему для управления виртуальными машинами в приватном облаке». Мы обрадовались, начали ему показывать своё решение (уже после подписания контракта и ТЗ), ему всё понравилось. Всё понравилось, менеджеры уже открывают шампанское (а надо сказать, что контракт по нашим меркам был очень неплохой). И тут клиент показывает пальцем в пункт ТЗ и спрашивает – «а с этим как?». Сидят админы и недоуменно смотрят в этот пункт – «новые серверы должны автоматически добавляться в облако после инвентаризации, установки в стойку и подключения сети-питания». Мы начали показывать – вот смотрите, мы записываем сервер сюда (1c), добавляем его mac-адрес вот сюда (самописная web-морда для управления dhcp-сервером и pxe), запускаем скрипт, сервер загружается по сети, система ставится (мы с облегчением выдохнули, поняв, что хотя бы система ставится сама), потом мы ловим сервер при перезагрузке, усиленно жмем клавишу Del… В общем, представитель клиента посмотрел на это, почесал затылок, походил по переговорке, собрался с мыслями и произнес: «Да где ж тут автоматически? Вот давайте выкинем всё, кроме 1С, всё равно туда бухгалтеры сервер вносить будут, а не я, и того места, куда вы mac-адрес записывали». Ну и вскоре после этого ушел, добавив, что надеется на то, что задачу мы всё же решим.

Потом мы, как обычно, ТЗ решили прочитать. Нашли там всякие интересные пункты, которые мы (ну те, кто делал задачу, а не те, кто ТЗ подписывал и пересказывал его нам) увидели впервые. Например, мониторинг температуры в обход ОС, мониторинг потребления электричества, автоматическая настройка BIOS… Начали размышлять. Сначала склонялись к мысли, что ipmitool всё это может. Потом представили, как всё это будет выглядеть. Подумали про то, как обновлять настройки, про мониторинг датчиков… В общем, разошлись на выходные с задачей «изучить весь гугл на предмет альтернатив ipmi, которые могут».

Приходим в понедельник, все грустные, злые. А один админ сидит и улыбается. Логичным было пристать к нему с расспросами на тему того, зачем он читает ithappens, когда у нас такая беда. Как оказалось, радовался он по поводу того, что читал не ithappens, а Redfish server management spec v 1.0 (читать здесь). Почитали все вместе вслух, злиться перестали. Redfish оказался именно тем, что нам нужно. Взяли менеджера, заставили его обзванивать всех производителей серверов, чтобы найти железку, в которой Redfish реализован. Приходят через час и смеется, показывает пальцем на коробку у входа и говорит «всё, я нашел». Собственно, коробка оказалась коробкой от HP Proliant Gen9. Сервер мы нашли, вернули в лабораторию (и кто вообще догадался новенький неизученный сервер сразу в ДЦ везти…) и приступили к знакомству с HP REST API (которая и является реализацией Redfish в серверах HP).