Представляем вашему вниманию очередной небольшой обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере за прошедший месяц, а также информацию об обновлениях нашего Вики-сайта. За помощь в подготовке выпуска благодарю Евгения Лейтана.   Информационная безопасность Найдена крупнейшая БД украденных паролей: что следует знать. В статье описывается один из крупнейших за последнее время источников скомпрометированных учётных данных. Приводятся ссылки на такие интересные инструменты, как Have i been pwned?, где Вы можете самостоятельно проверить наличие своих учётных записей и e-mail адресов среди массива скомпрометированных учётных записей, соблюдая при этом разумную аккуратность. Найдена уязвимость во всех версиях Windows, которую не закрывает ни один антивирус. После конференции Black Hat Europe 2017 заговорили о методике, получившей название "Process Doppelgänging", позволяющей вредительскому ПО через особенности механизмов транзакций в NTFS скрывать следы своего присутствия в Windows-системе прямо "под носом" у любого из современных антивирусных продуктов. Ждём реакции со стороны вендоров антивирусного ПО. В Project Zero провели атаку на Windows 10 через WPAD. Стоит отметить, что механизм авто-конфигурации прокси WPAD, как вектор атаки, уже использовался и ранее. Поэтому если Вы используете на своих Windows-системах WPAD, тогда не забывайте про своевременную установку обновлений безопасности, выпускаемых Microsoft. Если же WPAD Вы не используете, то, возможно, не будет лишним задуматься об отключении службы авто-обнаружения прокси (WinHttpAutoProxySvc). Скрытый майнер продолжает работать после закрытия браузера. Новые методы скрытого майнинга через браузер порой удивляют своей изощрённостью. Очень меня повеселила идея сокрытия в графическом интерфейсе пользователя всплывающего окна браузера (с майнинговой нагрузкой) за панелью задач Windows. Учитывая нынешнюю тенденцию с аномальным распространением веб-майнинга (это касается, как сайтов с паразитирующими администраторами, так и тысяч взломанных сайтов, куда после взлома внедряется код вызова веб-майнинга), полезными могут оказаться любые дополнительные меры безопасности, например простейший блек-листинг сайтов, представляющих конечные скрипты веб-майнинга, на стороне прокси-сервера организации.   OC Linux Шифровальщик StorageCrypt - опасная угроза для NAS. Эксплуатирующим Linux-системы

Сообщение ИТ Вестник №12.2017 появились сначала на Блог IT-KB.

Несколько дней назад компания Hewlett Packard Enterprise опубликовала бюллетень безопасности HPESBHF03797 с информацией о наличии множественных удалённо эксплуатируемых уязвимостей в контроллерах управления HP Integrated Lights-Out 2 (iLO2) с прошивкой версии 2.29. Контроллеры iLO2 используются на серверных платформах HP пятого (G5) и шестого (G6) поколений в линейке 300-тых моделей, например ProLiant DL360/380, а также в некоторых других моделях, например ProLiant DL320s Gen1. Для закрытия уязвимостей необходимо выполнить установку прошивки версии 2.31 (7 Dec 2017). И если в локальной сети развёрнут репозиторий VCRM, то исполняемый файл прошивки можно добавить в этот репозиторий ранее описанным способом (для возможности установки прошивки на Windows Server 2012/2012 R2). Также прошивку можно обновить подключившись напрямую к веб-интерфейсу, встроенному в iLO2. Но в этой заметке речь пойдёт не о самой процедуре обновления, а о том, как провести аудит используемых версий iLO на всех серверах локальной сети. Такой аудит может быть полезен, с одной стороны - для того, чтобы предварительно оценить необходимый объем контроллеров, требующих обновления, и с другой стороны – в контрольных целях, в случае, если в организации между администраторами есть разделение на зоны обслуживания серверного оборудования.   Вариант удалённого определения версий iLO Одним из методов проведения аудита версионности контроллеров iLO, может быть метод прямого опроса контроллера по протоколу HTTP. Такой опрос возможен без необходимости аутентификации на встроенном в iLO веб-сервере в том случае, если в настройках контроллера в разделе Administration > Management (для iLO2) включен параметр Level of Data Returned. Здесь же можно найти и ссылку на возвращаемый в результате HTTP запроса XML документ. Ссылка эта выглядит следующим образом: http://iLO-IP-Address/xmldata?item=all Вывод будет иметь примерно следующий вид: Как видим, здесь есть интересующая нас информация о версии контроллера iLO и даже больше. Как вы понимаете, если вдруг по каким-то невероятным причинам обновление контроллера до актуальной версии всё-таки не планируется, то можно, как минимум, отключить вывод этих полезных XML-данных в

Сообщение Опрос сети на предмет используемых версий контроллеров HP iLO появились сначала на Блог IT-KB.

Сама по себе процедура установки Debian GNU/Linux 9, на мой взгляд, не должна вызывать особых затруднений даже у начинающих Linux-администраторов. Однако могут возникнуть вопросы в тех случаях, когда установка выполняется на некотором серверном оборудовании, имеющем ребрендинговые модели тех или иных адаптеров и контроллеров. Так, например, при установке Debian на сервер HP ProLiant DL380 старого поколения Gen5 можно столкнуться с проблемой отсутствия в базовом инсталляторе ОС микрокода firmware для встроенных сетевых адаптеров Broadcom NetXtreme II BCM5708 (HP NC373i Multifunction Gigabit Server Adapter в маркировке HP). В процессе установки Debian 9 на шаге Detect network hardware мы получим сообщение о том, что обнаружено оборудование, требующее для своей работы загрузки non-free микрокода. Это можно связать с тем, что Debian позиционирует себя как свободная ОС, и поэтому изначально поставляется только с теми микрокодами, которые являются свободными с точки зрения лицензионных барьеров. Таким образом предполагается, что администратор, эксплуатирующий такую Linux-систему должен самостоятельно устанавливать необходимый недостающий микрокод. Фактически нам нужен пакет firmware-bnx2_20161130-3_all.deb, доступный в non-free репозиториях Debian. Мы можем скачать файл firmware-bnx2_20161130-3_all.deb и разместить его, например, на USB-накопителе. Программа установки подхватит этот пакет c накопителя в случае выбора "Yes". В том случае, если накопитель с firmware не был подключен, в последующем при попытке настроить сетевое подключение мы получим ошибку. Если по какой-то причине нет возможности подключить соответствующий микрокод в процессе установки, - ничего страшного, ибо установку ОС можно продолжить и с ненастроенной сетью. А произвести доустановку недостающего микрокода можно уже после окончания установки ОС.  При этом стоит помнить про то, что с учётом неработающей сети, установку лучше производить с полного дистрибутива Debian, а не с урезанного дистрибутива NetInstall, который для завершения установки ОС может потребовать загрузки по сети каких-то недостающих пакетов. Итак, предположим, что мы установили систему и не подключили микрокод на этапе установки. После загрузки системы мы увидим неработающую сеть и ошибки в dmesg, свидетельствующие

Сообщение Особенность установки Debian GNU/Linux 9.3 "Stretch" на сервер HP ProLiant DL380 G5 с подключением firmware из non-free репозиториев (на примере bnx2) появились сначала на Блог IT-KB.

В этой заметке мы рассмотрим пример того, как установить утилиты управления HPE System Management Tools на сервер HP ProLiant DL380 G5 с установленной ОС Debian GNU/Linux 9.3 'Stretch'. В целом процесс схож с рассмотренным ранее примером для CentOS Linux 7, но имеет свои особенности. Подключаем репозиторий HPE MCP (Management Component Pack) Страница базовой информации о Linux-репозиториях для распространения программного обеспечения HPE расположена здесь: Software Delivery Repository - Getting Started. Там же есть ссылка на sh-скрипт, который способен автоматически добавить в нашу серверную систему на базе Linux информацию о репозиториях HPE. Создаём в профиле текущего пользователя временный каталог, скачиваем в него скрипт add_repo.sh и делаем его исполняемым: # mkdir ~/HPE # wget http://downloads.linux.hpe.com/SDR/add_repo.sh -P ~/HPE # chmod +x ~/HPE/add_repo.sh Запускаем скрипт в "холостом" режиме с указанием имени интересующего нас репозитория HPE MCP (Management Component Pack) ("mcp") и опцией -n (опция покажет планируемые изменения в системе, без их фактического применения) # ~/HPE/add_repo.sh "mcp" -n Как видим, в рабочем режиме работы скрипт создаст файл /etc/apt/sources.list.d/HP-mcp.list и добавит в него информацию о соответствующем репозитории для нашей версии Debian Linux: # HP Software Delivery Repository for mcp deb http://downloads.linux.hpe.com/SDR/repo/mcp stretch/current non-free Выполняем скрипт в рабочем режиме (убираем опцию -n) # ~/HPE/add_repo.sh "mcp" В таком режиме работы скрипт предложит нам прочитать и принять лицензионное соглашение HP EULA Проверяем созданный файл /etc/apt/sources.list.d/HP-mcp.list Чтобы в дальнейшем с установкой пакетов не было проблем по причине того, что локальный менеджер пакетов не доверяет ключам, которыми подписаны пакеты из репозиториев HPE, добавим эти ключи в систему, воспользовавшись рекомендацией из Package Signature Verification: # wget -O- http://downloads.linux.hpe.com/SDR/hpPublicKey1024.pub | apt-key add - # wget -O- http://downloads.linux.hpe.com/SDR/hpPublicKey2048.pub | apt-key add - # wget -O- http://downloads.linux.hpe.com/SDR/hpPublicKey2048_key1.pub | apt-key add - # wget -O- http://downloads.linux.hpe.com/SDR/hpePublicKey2048_key1.pub | apt-key add - Просмотреть ключи, которые были добавлены с сайта HPE в наш менеджер пакетов можно так: # apt-key list

Сообщение Установка HPE System Management Tools на сервер HP ProLiant DL380 G5 с ОС Debian GNU/Linux 9.3 'Stretch' появились сначала на Блог IT-KB.

При использовании ОС Debian GNU/Linux 9 на платформе HP ProLiant в некоторых случаях может возникнуть необходимость в управлении устаревшими контроллерами HP Smart Array, например контроллером SCSI U320 HP Smart Array 6400. В этом случае актуальная версия ранее описанных инструментов Smart Storage Administrator (ssa) и Smart Storage Administrator CLI (ssacli) нам не поможет, так как в современных версиях этих утилит исключена поддержка старых контроллеров. Собственно говоря, с Debian Linux 9 ситуация аналогична той, что ранее описывалась относительно CentOS Linux 7. В таких случаях нам может помочь установка старых версий утилит HP Array Configuration Utility (cpqacuxe) и HP Array Configuration Utility CLI (hpacucli), совместимых со древностями линейки Smart Array. Установить на Debian Stretch утилиты cpqacuxe и hpacucli можно двумя путями. Вариант 1. Можно напрямую выкачать нужные deb-пакеты из репозиториев HPE MCP и установить их с помощью dpkg: # cd ~/HPE # wget http://downloads.linux.hpe.com/SDR/repo/mcp/debian/pool/non-free/cpqacuxe_9.40.2-2._amd64.deb # wget http://downloads.linux.hpe.com/SDR/repo/mcp/debian/pool/non-free/hpacucli_9.40.1-1._amd64.deb # dpkg -i ~/HPE/cpqacuxe_9.40.2-2._amd64.deb # dpkg -i ~/HPE/hpacucli_9.40.1-1._amd64.deb Вариант 2. Можно на время подключить старый репозиторий jessie/9.5, добавив его в ранее созданный конфигурационный файл /etc/apt/sources.list.d/HP-mcp.list: # ... # HP Software Delivery Repository for mcp deb http://downloads.linux.hpe.com/SDR/repo/mcp stretch/current non-free # HP Software Delivery Repository for mcp (old packages) deb http://downloads.linux.hpe.com/SDR/repo/mcp jessie/9.50 non-free После правки информации о репозиториях MCP, выполним обновление кеша менеджера пакетов apt и запросим информацию о доступности соответствующих пакетов # apt-get update # apt-cache search ^cpqacuxe # apt-cache search ^hpacucli Как видим, пакеты доступны. Устанавливаем пакеты командой: # apt-get install cpqacuxe hpacucli Вне зависимости от того, какой вариант установки был выбран, утилиты cpqacuxe и hpacucli без проблем должны установиться на системе, где уже установлены более "модерновые" утилиты ssa и ssacli. Проверим возможность работы с утилитой командной строки HP Array Configuration Utility CLI (hpacucli) (синтаксис команд работы с утилитой схож с ранее описанной утилитой ssacli):   Что касается веб-утилиты HP Array Config Utility (cpqacuxe), то стандартным

Сообщение Debian GNU/Linux 9.3 'Stretch' и HP Array Configuration Utility (ACU) для управления устаревшими контроллерами HP Smart Array появились сначала на Блог IT-KB.

Представляем вашему вниманию очередной небольшой обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере за прошедшие два месяца, а также информацию об обновлениях нашего Вики-сайта. За помощь в подготовке выпуска благодарю Алексея Максимова. Также будем рады видеть Вас участниками групп https://vk.com/blogitkb и https://www.fb.com/blog.it.kb Информационная безопасность Внимание! Очень важная информация, которая касается всех клиентских, серверных вычислительных машин, облачных сервисов, планшетов, смартфонов. Компания Google опубликовала отчеты о двух уязвимостях под названиями Meltdown (CVE-2017-5753 и CVE-2017-5715) и Spectre (CVE-2017-5754), которые по оценке компании “затрагивают все процессоры, выпущенные с 1995 года”. Подробности по ссылке: https://www.comss.ru/page.php?id=4743 Общая информация на сайте Meltdown and Spectre Новогодние подарки, часть первая: Meltdown и Как именно работает Meltdown Новогодние подарки, часть вторая: Spectre Ох и нелегкий вышел прошлый год на ИТ риски в сегменте безопасноcти. Как раз повод пройти программу БЕСПЛАТНОЙ оценки кибербезопасности. https://www.microsoft.com/cyberassessment/ru/cee С 1 января этого года вступил в силу Федеральный закон от 26.07.2017 №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», а вместе с ним начали действовать изменения в Уголовный кодекс РФ. Про сам закон вышла интересная статья, с которой полезно ознакомиться всем причастным: Преступление и наказание для владельцев критической информационной инфраструктуры РФ. Общий смысл в том, что за нарушения в работе критической инфраструктуры РФ, к которой в частности относятся технологические каналы связи, серверы и программные комплексы АСУТП вводится уголовная отвественность (части 3,4,5 ст. 274.1 УК РФ) для владельцев/эксплуатантов. При этом объективная сторона преступления может рассматриваться, как активное действие, так и бездействие. Представители Positive Technologies наглядно раскрыли некоторые особенности нового закона в своей презентации:Безопасность КИИ: что нас ждет в 2018 году Эксперт в области кибербезопасности Набил Ахмед (Nabeel Ahmed) нашел уязвимость, которая позволяет отказать хозяину техники в обслуживании.Найденная уязвимость позволяет злоумышленнику одним действием вызвать BSOD (Blue Screen of Death, так называемый «синий экран смерти») — сообщение о критической системной ошибке в системах Microsoft Windows. Под

Сообщение ИТ Вестник №13/14.2018 появились сначала на Блог IT-KB.

Имеем удалённую площадку с одним хостом виртуализации на базе гипервизора Hyper-V (Windows Server 2012 R2) и пачкой виртуальных машин, запущенных на этом хосте. Всё работает, но есть желание хоть как-то повысить доступность виртуальных машин, так как в периоды обслуживания хоста возникает необходимость выключения всех ВМ, что в некоторых ситуациях приводит к нежелательным последствиям. Логичным решением здесь выступает построение, как минимум, двух-узлового кластера высоко-доступных виртуальных машин Hyper-V на базе Windows Failover Cluster. В таком кластере виртуальные машины должны размещаться на общем дисковом томе Cluster Shared Volumes (CSV), который должен быть доступен обоим хостам виртуализации. То есть, предполагается, что для построения кластера нам потребуется какое-то внешнее дисковое хранилище (СХД), к которому могут быть подключены хосты виртуализации. Однако в нашем случае СХД на удалённой площадке нет, но есть свободные серверы. В этой заметке мы рассмотрим пример того, как с помощью Debian GNU/Linux 9.3 и свободно-распространяемого ПО Generic SCSI Target Subsystem for Linux (SCST) из обычного сервера сделать СХД. В результате у нас появится возможность создать двух-узловой кластер высоко-доступных виртуальных машин Hyper-V с подключением к третьему серверу, который будет использоваться в качестве СХД для организации общего тома CSV. Конфигурация серверов Для построения выше обозначенной конфигурации нами будут использоваться три сервера линейки HP ProLiant DL380 старого поколения Gen5. В серверы, помимо их базовой комплектации, дополнительно установлены старые оптические контролеры FC HBA 4G (сейчас такие можно купить "по рублю за чемодан"). Кстати, организовать точку подключения к СХД (Target) в ПО SCST можно и на базе более дешёвых сетевых адаптеров GigEthernet (iSCSI Target), но в данной заметке мы будем строить конфигурацию именно Fibre Channel Target на базе оптического адаптера FC HBA фирмы QLogic и SCST будет настраиваться соответствующим образом. 1) Сервер под роль СХД (KOM-AD01-FS03) В сервер установлен двух-портовый адаптер FC 4Gb HP QLogic QLE2462 Dual-Port PCI-Express HBA (407621-001 FC1242SR AE312-60001) (каждый порт используется для подключения к

Сообщение Использование сервера с FC HBA QLogic на базе Debian GNU/Linux 9.3 и SCST в качестве СХД для томов CSV в кластере высоко-доступных виртуальных машин Hyper-V появились сначала на Блог IT-KB.

В одной из прошлых заметок мы рассматривали процедуру обновления экземпляра HPE B-series SAN Network Advisor 12.4.1 до более новой версии 12.4.2 методом in-place upgrade. Принципиальных отличий процедура обновлений не претерпела и до текущих релизов 14 версии продукта. Однако между под-версиями 14.2 и 14.3 произошли некоторые изменения уровня безопасности, в результате которых процесс обновления может завершиться ошибкой. В частности, когда мы попытались произвести обновление имеющейся у нас версии 14.2.2 на версию 14.4.1 или 14.4.2, на заключительном этапе работы мастера конфигурации новой версии в момент, когда фактически уже миграция данных выполнена и производится попытка запуска службы HPE B-series SAN Network Advisor (dcm-service), возникла ошибка "Server failed to start. HPE B-series SAN Network Advisor will be rolled back to previous version" В результате эта ошибка приводит к полному откату процедуры обновления с автоматическим восстановлением старой версии и удалением новой версии продукта. По окончании процедуры отката будет выведено сообщение с информацией о размещении диагностического пакета, в который завёрнуты логи старой и новой версии продукта. Например, в нашем случае сообщение говорит о том, что архив с логами сохранён в каталоге текущей старой версии C:\Program Files\HPE B-series SAN Network Advisor 14.2.2\support Распакуем этот архив и в структуре каталогов перейдём в подкаталог новой версии и найдём там лог сервера Network Advisor. В нашем случае путь к файлу лога будет таким: ..\Migration_Failure_Logs\HPE B-series SAN Network Advisor 14.4.2\server\server.log Если изучить содержимое лога, то можно обнаружить то, что есть проблема с шифрованием, так как фигурируют ошибки вида "…javax.net.ssl.SSLHandshakeException: General SSLEngine problem" Если повнимательней посмотреть документ Release Notes к новой версии, то сможем обнаружить, что начиная с версии 14.3.1 в Network Advisor выключены устаревший алгоритм хеширования SHA1 и поддержка ключей RSA менее 2048 бит. Соответственно, если ранее мы заменили само-подписанный цифровой сертификат Network Advisor на собственный, например, выпущенный доменным Центром Сертификации (ЦС), и этот сертификат не соответствует требованиям новых версий Network

Сообщение Ошибка "Server failed to start. HPE B-series SAN Network Advisor will be rolled back to previous version" при обновлении с версии 14.2 на версию 14.4 появились сначала на Блог IT-KB.

Практическая работа с серверами HP ProLiant DL320s G1 Storage Server (AG651A) каждый раз приводит меня к мысли в том, что одним из наиболее проблемных узлов этой модели является RAID-контроллер. При этом стоит отметить тот факт, что сам по себе RAID-контроллер этой модели, то есть HP Smart Array P400, никаких особых нареканий не вызывает при работе на других серверных платформах, например на HP ProLiant DL380 G5. Однако на серверах DL320s с этим контроллером не редко возникают какие-то странные проблемы. Бывало такое, что на контроллере отказывает модуль кеш-памяти. Меняем модуль и контроллер возобновляет свою штатную работу. Снятый и, якобы неисправный, модуль для проверки ставим на другой аналогичный контроллер в другом сервере, и этот модуль … работает. Иногда установка заведомо рабочего модуля не даёт желаемого результата и приходится менять сам RAID-контроллер. В некоторых случаях бывает даже так, что установка заведомо рабочего контроллера с новым модулем памяти не решает проблемы. На одном из таких "мутных" серверов в попытке выявить и ликвидировать причину возникновения подобных "глюков" в своё время даже поочерёдно менялись платы дисковой корзины Backplane Board, но это тоже не дало вменяемого результата. На фоне такого безрадостного опыта мне в руки снова попался очередной аналогичный сервер DL320s с отваливающимся кеш-модулем на RAID-контроллере и мне подумалось, что нужно попробовать найти какой-то кардинальный способ решения этой проблемы. Экспериментальным образом было выяснено, что сервер ProLiant DL320s G1 можно превратить из самостоятельного NAS-сервера со своей хостовой ОС в обычную дисковую полку с внешним подключением через интерфейс SAS, то есть в дисковый массив DAS (Direct-attached storage), который можно будет в дальнейшем подключить к любому другому серверу в качестве расширения дисковой ёмкости. В ходе такого преобразования дисковую корзину сервера можно напрямую подключить к адаптеру типа Internal SAS – External SAS, полностью исключив таким образом RAID-контроллер Smart Array P400, как сущность, сопряжённую с проблемами. В нашем случае для преобразования используется SAS-адаптер:

Сообщение Конвертируем NAS-сервер HP ProLiant DL320s G1 в дисковый массив DAS появились сначала на Блог IT-KB.

Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP. В качестве аппаратной платформы для тонкого клиента мы будем использовать устройства HP t610, хотя в рамках нашей задачи эти устройства имеют более чем избыточную конфигурацию. По сути минимальные системные требования для тонкого клиента с Thinstation – любой "аппаратный хлам" начиная с уровня Pentium-II с 128MB RAM и выше. Мы будем использовать бездисковую конфигурацию тонких клиентов, то есть загрузка системы будет выполняться по сети с использованием PXE (приоритетно) или с локальных загрузочных USB-накопителей (для клиентов без поддержки PXE и в отдалённых участках со слабым каналом передачи данных). Когда я изучал доступные в открытых источниках статьи на тему подобного развёртывания, то среди множества материалов выделил для себя статью Пети Хинчли "Use Thinstation to build a network-bootable RDP-enabled thin client image", от наработок которой я и буду отталкиваться. Также в качестве полезного источника информации стоит отметить такие русскоязычные ресурсы, как Thinstation по русски и Thinstation Доработка тонкого клиента. В рассматриваемом примере имеется несколько исходных условий, от которых нам придётся отталкиваться: Все тонкие клиенты должны быть изолированы в рамках одной сети и должны маршрутизироваться только до своего RDS-сервера. RDS-сервер, помимо предоставления сессий удалённых рабочих столов, по совместительству должен выполнять все функции управления тонкими клиентами (раздача IP адресов, раздача загрузочных образов ОС, раздача настроек каждого конечного клиента и т.д.). Загрузка конечной рабочей среды тонкого клиента должна происходить автоматически без участия пользователя/оператора (авто-логон RDP-сессии и запуск необходимой оболочки – конечного бизнес-приложения) Цикличная работа тонких клиентов должна быть автоматизирована, то есть клиенты должны автоматически включаться по расписанию утром каждого рабочего дня и выключаться в конце рабочего дня.     Начнём

Сообщение Разворачиваем сеть тонких клиентов Thinstation с подключением к серверу Windows Server 2012 R2 Remote Desktop Services появились сначала на Блог IT-KB.

При создании RAID-массивов на контроллерах HPE Smart Array не допускается комбинированное использование дисков с разными интерфейсами (SAS и SATA) в рамках одного массива. Поэтому, в случае, если ранее операционная система сервера была установлена на RAID-массив, состоящий из дисков одного типа (например SAS HDD), то в случае необходимости переноса ОС на диски другого типа (например SATA SSD), нам потребуется создать отдельный RAID-массив из дисков такого типа. Здесь мы рассмотрим пример подобного переноса ОС Windows Server 2012 R2, развёрнутой на сервере HPE ProLiant Gen9, без необходимости переустановки ОС, то есть с минимальным временем простоя сервера. Исходные данные, используемые в нашем примере: В сервере установлен RAID-контроллер HPE Smart Array P440ar и включена загрузка UEFI; Загружаемая ОС сервера установлена на массив RAID-1 из пары дисков SAS HDD 72GB; Необходимо перенести ОС сервера на массив RAID-1 из пары дисков SATA SSD 150GB; Минимальные условия: В дисковой корзине сервера имеется хотя бы один свободный слот для установки дополнительного диска (только на время переноса ОС); На сервере установлена утилита HPE Smart Storage Administrator (SSA). Загрузить актуальную версию можно здесь; Имеются загрузочные образы: HPE Smart Storage Administrator Offline MiniTool Partition Wizard (Free Edition) Используемый в нашем случае вариант плана действий по переносу ОС: Делаем резервные копии всего, что можно сделать; Снимаем с сервера продуктивную нагрузку и переводим сервер в режим обслуживания в системах управления, таких как SCVMM и SCOM; Выключаем сервер, штатно завершая работу ОС; Извлекаем из дисковой корзины сервера один из дисков SAS HDD из текущего массива RAID-1; Включаем сервер и, игнорируя сообщения об аварии в RAID, дожидаемся успешной загрузки Windows Server; В свободный слот дисковой корзины сервера устанавливаем первый диск SATA SSD; Заходим в утилиту HPE SSA и создаём с установленным в п.6 SSD-диском новый массив RAID-0; Выключаем сервер, штатно завершая работу ОС; (Опционально) Отсоединяем сервер от SAN; Загружаем сервер с образа MiniTool Partition Wizard; В

Сообщение Перенос ОС Windows Server 2012 R2 с массива RAID-1 SAS HDD на массив RAID-1 SATA SSD на RAID-контроллере HPE Smart Array P440ar сервера HPE ProLiant Gen9 (без переустановки ОС) появились сначала на Блог IT-KB.

В конфигурации по умолчанию у контроллеров управления системы хранения данных HP MSA P2000 G3 имеется несколько встроенных учётных записей. Пароли этих учётных записей любой вменяемый администратор сменит при первой же настройке контроллеров управления. Однако, даже много лет проработав с подобной железкой, и предполагая, что в этой области нет никаких "белых пятен", в один прекрасный день можно открыть для себя совершенно удивительные и неизвестные ранее подробности, от которых на голове могут зашевелиться волосы. Так произошло в моём случае, когда колупаясь в документе "HP P2000 G3 MSA System CLI Reference Guide" в разделе описания команд управления учётными записями (команды "create user"), было замечено подозрительное примечание: NOTE:The user name admin is reserved for internal use Но для каких таких задач может понадобиться такая учётная запись, да и как вообще её можно использовать, если в перечне созданных на контроллере учётных записей её попросту нет? Развивая логику настроек учётных записей, имеющихся на контроллере по умолчанию и доступных администратору в веб-интерфейсе и CLI-оболочке … Пользователь "manage" с паролем "!manage" Пользователь "monitor" с паролем "!monitor" Пользователь "ftp" с паролем "!ftp" … можно конечно предположить, что если учётная запись "admin" действительно есть на контроллере, то пароль по умолчанию у неё вероятно будет "!admin". Мысль в голове конечно проскочила, но я её отбросил, так как и предположить не мог, что такое возможно на самом деле на железке от такого, казалось бы, серьёзного производителя. В конечном итоге выяснилось то, что, действительно, на самом деле такое возможно. Более того, в Интернете можно найти свидетельства (и здесь позже), подтверждающие это, которые на сегодня могут смело называться "жутким баяном", но актуальности от этого в моём конкретном случае они не потеряли. На двух, имеющихся у меня под руками СХД с самой последней прошивкой версии TS252P005 (9 Feb 2017) и прошивкой предыдущей версии TS252P001 (1 Mar 2016), удалось успешно подключиться к контроллерам СХД с административными

Сообщение СХД HP MSA P2000 G3 Modular Smart Array и учётные данные по умолчанию появились сначала на Блог IT-KB.

Продолжая тему мониторинга сетевых устройств по протоколу SNMP в Icinga на примере модулей управления источников бесперебойного питания (ИБП), можно в очередной раз отметить тот факт, что рассмотренная ранее схема с использованием плагина check_snmp дает нам лишь базовые возможности обработки получаемых по SNMP данных. Когда описанным базовым методом мы начали мониторить входное напряжение ИБП разных производителей и разных моделей, со временем пришли к выводу, что использование статически заданных границ (верхней и нижней) для входного напряжения – не очень приемлемый вариант. Проблема заключалась в том, что даже в рамках одной марки ИБП в нашем окружении присутствует множество разных моделей, каждая из которых имеет свои допустимые рабочие диапазоны входного напряжения. При этом на некоторых моделях ИБП эти диапазоны могут регулироваться администратором, как в сторону сужения, так и в сторону расширения. По началу возникла идея попросту персонализировать Службы Icinga, связанные с мониторингом входного напряжения для устройств, выбивающихся из общих, заданных для всех однотипных ИБП, границ. Но со временем стало понятно, что такой вариант настройки Служб Icinga неудобен и трудозатратен пропорционально расширению модельного ряда ИБП. При этом нам известно, что практически все марки и модели ИБП наряду с текущим значением входного напряжения по протоколу SNMP могут возвращать и значения нижней/верхней границы рабочего напряжения, заданные на каждом отдельно взятом ИБП. Например, для ИБП марки APC мониторить входное напряжение можно, используя следующие OID: 1.3.6.1.4.1.318.1.1.1.3.2.1.0 – Текущее входное напряжение (VAC) 1.3.6.1.4.1.318.1.1.1.5.2.2.0 – Верхняя допустимая граница (VAC) 1.3.6.1.4.1.318.1.1.1.5.2.3.0 – Нижняя допустимая граница (VAC) В Вики можно найти соответствующие OID для других марок ИБП, например для Eaton Powerware и Hewlett-Packard. Учитывая возможности представленных OID, был создан отдельный плагин мониторинга к Icinga - check_snmp_value_from_range. Данный плагин работает по аналогии с плагином check_snmp, но имеет иную структуру входных параметров и отдельный принцип обработки полученных по SNMP данных. Проще говоря, используя утилиту snmpget плагин получает с сетевого устройства данные сразу трех OID (текущего

Сообщение Icinga плагин check_snmp_value_from_range для отслеживания вхождения значения в допустимый диапазон значений, извлекаемых по протоколу SNMP (на примере мониторинга входного напряжения ИБП) появились сначала на Блог IT-KB.

С тех пор, как мы в одной из прошлых заметок рассматривали процесс развёртывания HP Product Bulletin, прошло немало времени. За это время продукт успел побывать в фазе активной поддержки, после чего был "заморожен" со стороны HP и его обновления какое-то время не выпускались, затем уже в HPE провели его ребрендинг и снова вернули к жизни. Поэтому для тех, кто активно работает с оборудованием HP/HPE, на сегодняшний день этот продукт может быть всё ещё полезен. В этой заметке мы сделаем акцент на то, как развернуть актуальную версию HPE Product Bulletin Gateway таким образом, чтобы она выполнялась в контексте сервисной учётной записи Group Managed Service Account (gMSA). Как я понял, в актуальной версии Product Bulletin в целях ребрендинга HP –> HPE была обновлена лишь графическая оболочка инсталлятора и самого приложения. При этом Backend приложения, судя по всему, изменён не был, так как у Product Bulletin Gateway остались все прежние "детские болезни", типа того, что служба HPPB_Gateway не приспособлена для работы в более или менее новых серверных ОС Windows Server и по прежнему требует интерактивного режима работы. Например, попытка запуска службы в Windows Server 2012 R2 приведёт к ошибке типа: Log Name: System Source: Service Control Manager Event ID: 7030 Level: Error Description: The HPPB_Gateway service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly. При этом, даже если включить в ОС поддержку старых интерактивных служб и пытаться запустить службу от имени сервисной учётной записи, результат будет неутешительным. Поэтому автоматизацию запуска процесса PB Gateway мы будем достигать путём создания задачи в планировщике задач (Task Scheduler), но уже не в контексте обычной доменной учётной записи, как это было рассмотрено ранее, а в контексте сервисной учётной записи gMSA. Примеры основных приёмов работы с gMSA можно найти в соответствующем разделе Вики. Создаём в

Сообщение Запуск HPE Product Bulletin Gateway в контексте учётной записи gMSA появились сначала на Блог IT-KB.

В конце Ноября и начале Декабря компания Hewlett Packard Enterprise опубликовала пару сервисных бюллетеней, описывающих критическую проблему с некоторыми моделями накопителей SSD, произведённых в Samsung и поставляемых в рамках комплектации серверных платформ и СХД от HPE. В накопителях HPE SAS SSD с версией микрокода ниже, чем HPD8, проявляется ошибка, приводящая к выходу из строя накопителя с потерей всех данных после работы накопителя в течении 32768 часов (3 года, 270 дней и 8 часов). Усугубить проблему может ситуация, в которой из однотипных дисков, подверженных описанной проблеме, построен RAID массив и одновременный выход из строя сразу нескольких таких дисков может привести к потере данных всего RAID массива. Обновлённая версия микрокода HPD8 позволяет избежать описанной поломки SSD накопителей, поэтому рекомендуется безотлагательно произвести обновление микрокода накопителей, используемых в таких системах как HPE ProLiant, Synergy, Apollo, Synergy D3940 Storage Module, D3000/D6000/D6020 Disk Enclosures, MSA Storage, StoreEasy 1000 Storage, StoreVirtual 4335 Hybrid Storage and StoreVirtual 3000 Storage. При этом, согласно бюллетеней, проблема не распространяется накопители, используемые в составе таких систем, как HPE 3PAR StoreServ Storage, D8000 Disk Enclosure, Nimble Storage, Primera Storage, StoreOnce Systems, XP Storage, HPE StoreEasy 5000 Storage and SimpliVity Какие модели накопителей должны быть обновлены на серверах HPE Таблица моделей SSD накопителей, используемых в серверных продуктах HPE накопителей HPE и входящих в группу риска (требующих обновления до версии микрокода HPD8) и на данный момент времени выглядит так: HPE Model Number HPE SKU HPE SKU DESCRIPTION Spare SKU FW Fix Date VO0480JFDGT 816562-B21 HP 480GB 12Gb SAS 2.5 RI PLP SC SSD 817047-001 22.11.2019 VO0960JFDGU 816568-B21 HP 960GB 12Gb SAS 2.5 RI PLP SC SSD 817049-001 22.11.2019 VO1920JFDGV 816572-B21 HP 1.92TB 12Gb SAS 2.5 RI PLP SC SSD 817051-001 22.11.2019 VO3840JFDHA 816576-B21 HP 3.84TB 12Gb SAS 2.5 RI PLP SC SSD 817053-001 22.11.2019 MO0400JFFCF 822555-B21 HP 400GB 12Gb SAS 2.5 MU PLP SC SSD

Сообщение Важное обновление микрокода накопителей HPE SAS SSD появились сначала на Блог IT-KB.

Для систем хранения данных HPE 3PAR, находящихся на действующем контракте сервисного обслуживания обычно замена вышедших из строя комплектующих не представляет каких-либо сложностей и сопровождается пошаговыми инструкциями специалистов тех.поддержки HPE. Однако, если на руках оказывается СХД без такого контракта, то все задачи по обслуживанию превращаются в интереснейший квест. В этой и нескольких последующих заметках я попробую описать несколько приёмов по решению таких задач своими силами. Начнём с описания исходных данных, от которых в нашем примере мы будем отталкиваться. Итак, имеется "не первой свежести" двух-контроллерная СХД HP 3PAR StoreServ 7200 2-Node Storage (QR482A), которая ранее эксплуатировалась и вроде-как даже была живой, но до меня доехала в не очень хорошем состоянии. Первичный осмотр СХД показал наличие нескольких неприятных моментов: 1) Одна из нод (Node, контроллер СХД) не запускается, выдавая цвето-музыку всеми индикаторами коммуникационной панели. Фактически СХД стартует, но стартует только на одной ноде. При этом запустившаяся нода в упор не видит вторую ноду. Консольный порт проблемной ноды не отвечает. Требуется замена неисправной ноды. 2) Не самая актуальная версия прошивки нод 3PAR OS с учётом того, что сервер управления Virtual Service Processor (VSP), с которого можно провести обновление, для данной СХД недоступен (то есть отсутствует). Необходимо развернуть старую версию VSP и поэтапно поднять уровень версий 3PAR OS/VSP. 3) В инструментах управления СХД, например в консоли HP 3PAR Management Console, видно, что у СХД есть два проблемных 1GB-чанклета в состоянии "Failed". Возможно потребуется замена дисковых накопителей. 4) Для возможности дальнейшего использования СХД (с учётом исправления пунктов 1-3) потребуется выполнить процедуру сброса настроек "Out Of The Box" (OOTB). Однако, отсутствует пароль сервисной учётной записи пользователя "console", который необходим для выполнения процедуры OOTB, доступной через прямое подключение на консольном порту ноды. Попробуем последовательно решить все описанные проблемы. Если говорить о замене ноды, то в целом процедура описана с наглядными картинками в онлайн-документе: HPE 3PAR StoreServ 7000 Storage

Сообщение Лохматим СХД HPE 3PAR 7200. Часть 1. Замена ноды и сообщение "Cages not on current firmware" появились сначала на Блог IT-KB.

В этой части мы рассмотрим процедуру повышения уровня прошивки 3PAR OS у контроллеров (нод) СХД HPE 3PAR 7200 до крайней версии 3.3.1 (MU5), поддерживаемой HPE для данной модели. Для выполнения данной задачи нам потребуется параллельно поднять версию системы управления Virtual Service Processor (VSP), с помощью которой мы и будем обновлять 3PAR OS. В качестве начальной конфигурации мы имеем двух-контроллерную СХД HP 3PAR StoreServ 7200 2-Node Storage (QR482A) с прошивкой 3PAR OS версии 3.2.2.709 (MU6) и наложенными патчами P99, P119, P131, P135, P138, P139, P149. Как отмечалось в предыдущей заметке, сервера VSP у нас нет, поэтому нам потребуется развернуть новый экземпляр виртуальной машины с VSP и "подружить" его у нашей СХД. Но прежде, чем начать, сделаем небольшое отступление относительно выбора версии 3PAR OS. Возможно, найдутся коллеги, которые, поправив пенсне, заявят, что версию 3PAR OS 3.3.1 для 7000 линейки СХД 3PAR использовать нельзя, так как она рекомендуема только для более новых моделей и вообще "когда 3.3.1 вышла … в ней было много изменений для новых линеек СХД и её нельзя было ставить на 7200/7400". На это я могу сказать, что, во-первых, 3.3.1 вышла уже достаточно давно и к текущему моменту претерпела множество изменений, в том числе касающихся и работы на 7000 линейке. А во вторых, уже давно доступен документ a00008513en_us - HPE 3PAR StoreServ 7000 and 7000c Storage Systems - End of Life Announcement, обозначающий крайнюю протестированную и поддерживаемую версию 3PAR OS – 3.3.1. Кроме того, на веб-узле HPE SPOCK (Single Point of Connectivity Knowledge for HPE Storage Products) можно найти документ HPE 3PAR StoreServ Support Matrix for 3PAR OS 3.3.1 (текущая актуальная версия документа 2.1 от 27.07.2021). В этом документе оговаривается наличие крайней актуальной версии 3.3.1 MU5 и нет никаких оговорок о том, что эта версия не может быть использована на СХД 7000 серии. Разумеется, при этом нельзя скидывать со счетов

Сообщение Лохматим СХД HPE 3PAR 7200. Часть 2. Обновление 3PAR OS до 3.3.1 (MU5) и Virtual Service Processor до 5.0.8.1 появились сначала на Блог IT-KB.

Продолжая ранее начатый квест по взбадриванию двух-контроллерной СХД HP 3PAR StoreServ 7200, напомню, что получена эта система в нашем случае была с небольшой частью дисковой ёмкости, которая была помечена как неисправная. В этой заметке мы поговорим о том, как выяснить то, к каким дисковым накопителям в СХД относится неисправная ёмкость и что в такой ситуации можно сделать. Итак, при поверхностном осмотре состояния компонент СХД в консоли управления HP 3PAR Management Console было обнаружено 2GiB ёмкости в состоянии "Failed". А насколько нам известно, в 3PAR OS 3.2/3.3 на самом нижнем уровне СХД оперирует физическими блоками (chanklets) размером 1GiB. Получается, что у нас есть 2 неисправных чанклета и нам в первую очередь потребуется выяснить, к каким дисковым накопителям относятся эти блоки. Для этого подключимся по SSH к СХД от имени учётной записи "3paradm" и выполним команду вывода информации о всех проблемных чанклетах: 3PAR02 cli% showpdch -fail Pdid Chnk LdName LdCh State Usage Media Sp Cl From To 3 239 ---- --- none available failed N N --- --- 12 296 ---- --- none available failed N N --- --- ----------------------------------------------------------- Total chunklets: 2 Как видим, проблемные чанклеты физически находятся на дисках 3 и 12. Теперь возникают резонные вопросы – насколько это опасно для данных и что делать с дисками, имеющими проблемные чанклеты? Наличие некоторого количества неисправных чанклетов в 3PAR на самом деле не является для СХД какой-то критической проблемой и такие чанклеты попросту не будут использоваться для размещения данных. По некоторой неофициальной информации дисковый накопитель в актуальных версиях 3PAR OS будет считаться работоспособным, пока на нём не будет зафиксировано 10 неисправных чанклетов (или 6 чанклетов для более старых версий 3PAR OS). При превышении указанной границы диск помечается как неисправный и обязательно должен быть заменён. Процедуру стандартной замены неисправного накопителя с помощью утилиты "servicemag" мы уже рассматривали ранее в заметке Вики IT-KB -

Сообщение Лохматим СХД HPE 3PAR 7200. Часть 3. Избавляемся от чанклетов в состоянии "Failed" появились сначала на Блог IT-KB.

В данной заметке мы рассмотрим вариант реализации последнего, четвёртого, пункта ранее намеченного плана по приведению двух-контроллерной 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 3PAR 7200. Часть 4. Получаем доступ к сервисному меню 3PAR Console Menu для выполнения процедуры OOTB в контексте пользователя "console" или как обойти Time-based Passwords появились сначала на Блог IT-KB.

При использовании СХД начального уровня из последней линейки HPE, например HPE MSA 2062, можно столкнуться с ситуацией, когда новомодный веб-интерфейс управления Storage Management Utility не позволит выполнить некоторые простейшие операции, которые были доступны и работали в веб-интерфейсе управления СХД предыдущих поколений. Рассмотрим одну из таких ситуаций и метод выполнения необходимой задачи конфигурирования СХД. Перед презентацией дисковых томов (Volume) с СХД на какой либо сервер, мы предварительно должны описать этот сервер на СХД как Host, указав, относящиеся к нему порты (Initiator). Если сервер физический и порты его оптического адаптера FC HBA уже проброшены к СХД с помощью зонирования на оптических коммутаторах FC SAN, то эти порты в автоматическом режиме будут обнаружены на СХД и станут доступны для добавления в качестве Initiator. Однако, если в фабрике зонирование к нужному нам серверу с СХД ещё не настроено, или же мы просто хотим руками добавить WWPN портов сервера, то сделать это через текущую реализацию веб-интерфейса Storage Management Utility просто не получится. По крайней мере, сколько я не искал возможность ручного добавления Initiator в запутанной схеме вкладок и меню, так и не нашёл. Ручное добавление идентификаторов Initiator может потребоваться не только тогда, когда в фабрике ещё не настроено зонирование, но и тогда когда в качестве Host выступает виртуальная машина Hyper-V. Те, кто использует прямое подключение ВМ Hyper-V к дисковым томам СХД с помощью N_Port ID Virtualization (NPIV), знают, что каждый виртуальный FC-адаптер имеет единственный виртуальный FC-порт. И этот FC-порт имеет не один WWPN, а пару. В этой паре WWPN-идентификаторов в FC-фабрике всегда активен только один. Переключение же между этими WWPN происходит в тот момент, когда виртуальная машина мигрирует с одного физического хоста виртуализации на другой через механизм Live Migration. Таким образом, при описании таких сущностей, как Host, на СХД MSA мы должны в качестве Initiator указать оба WWPN для каждого из виртуальных FC-адаптеров нашей виртуальной

Сообщение СХД HPE MSA 2062 и добавление неактивных WWPN для Host Initiator появились сначала на Блог IT-KB.