В данной заметке мы рассмотрим вариант реализации последнего, четвёртого, пункта ранее намеченного плана по приведению двух-контроллерной HP 3PAR StoreServ 7200 в работоспособное состояние для возможности последующей эксплуатации. То есть, мы поговорим о том, каким образом можно получить доступ к сервисному меню ноды 3PAR Console Menu при прямом подключении к консольному порту, но с отсутствием пароля от встроенной учётной записи "console".
-
Лохматим СХД HPE 3PAR 7200. Часть 3. Избавляемся от чанклетов в состоянии "Failed"
Продолжая ранее начатый квест по взбадриванию двух-контроллерной СХД HP 3PAR StoreServ 7200, напомню, что получена эта система в нашем случае была с небольшой частью дисковой ёмкости, которая была помечена как неисправная. В этой заметке мы поговорим о том, как выяснить то, к каким дисковым накопителям в СХД относится неисправная ёмкость и что в такой ситуации можно сделать. -
Лохматим СХД HPE 3PAR 7200. Часть 2. Обновление 3PAR OS до 3.3.1 (MU5) и Virtual Service Processor до 5.0.8.1
В этой части мы рассмотрим процедуру повышения уровня прошивки 3PAR OS у контроллеров (нод) СХД HPE 3PAR 7200 до крайней версии 3.3.1 (MU5), поддерживаемой HPE для данной модели. Для выполнения данной задачи нам потребуется параллельно поднять версию системы управления Virtual Service Processor (VSP), с помощью которой мы и будем обновлять 3PAR OS. -
Лохматим СХД HPE 3PAR 7200. Часть 1. Замена ноды и сообщение "Cages not on current firmware"
Для систем хранения данных HPE 3PAR, находящихся на действующем контракте сервисного обслуживания обычно замена вышедших из строя комплектующих не представляет каких-либо сложностей и сопровождается пошаговыми инструкциями специалистов тех.поддержки HPE. Однако, если на руках оказывается СХД без такого контракта, то все задачи по обслуживанию превращаются в интереснейший квест. В этой и нескольких последующих заметках я попробую описать несколько приёмов по решению таких задач своими силами. -
Кеш контроллера HPE Smart Array в состоянии "Not Configured" при активном механизме SSD Smart Path
В качестве исходной конфигурации имеется сервер HPE ProLiant DL560 Gen10 с аппаратным RAID-контроллером HPE Smart Array P408i-a SR Gen10 и парой SSD-накопителей. Перед развёртыванием ОС на сервере было выполнено создание простого зеркального массива RAID-1 из этой пары SSD-накопителей с помощью утилиты Smart Storage Administrator (SSA). При создании массива утилита SSA не выдала никаких явных предупреждений или ошибок, и всё при беглом осмотре состояния массива в интерфейсе SSA выглядело вполне культурно. Однако, после того как сервер был подключен к системе мониторинга Icinga, было обнаружено, что плагину мониторинга HPE ProLiant не очень нравится состояние кеша RAID-контроллера Smart Array. -
Сообщение "We couldn't find any drives" и ошибка 0x80300001 при попытке установки Windows Server 2012 R2 на сервер HPE ProLiant Gen10 с контроллером Smart Array P408i-a
При попытке выполнить установку устаревшей операционной системы Windows Server 2012 R2 на новую серверную платформу HPE ProLiant DL560 Gen10 с RAID-контроллером HPE Smart Array P408i-a SR Gen10 можно столкнуться с тем, что инсталлятор ОС не может обнаружить диски, пригодные для установки ОС. В этой заметке рассмотрим пару простых примеров решения подобной проблемы. -
Исследование возможностей мониторинга регистраторов речевой информации STC Smart Logger BOX и плагин check_snmp_stc_slbox для базового мониторинга в Icinga
Когда, в своё время, мы начали работать с системой регистрации телефонных переговоров "Незабудка-II" и с регистраторами речевой информации "Smart Logger BOX" (далее SLBox) от компании "ЦРТ", то одним из первых логичных вопросов был вопрос мониторинга работоспособности этих самых регистраторов. Предложенная производителем на тот момент времени, так называемая, программа мониторинга "Status Monitor" (STC-S449) после развёртывания и изучения функционала показала себя, как не выдерживающее никакой критики программное решение, которое, по моим личным ощущениям, за миску супа писал какой-то голодный студент, прикованный наручниками к батарее. То, зачем это было реализовано именно в таком виде, для меня так и осталось непостижимым. -
Сканирование сети на предмет выявления модулей управления ИБП APC уязвимых к Ripple20
В прошлом году компанией JSOF была публично раскрыта информация о целом наборе уязвимостей, корни которых уходят в древнюю библиотеку компании Treck, реализующую функции стека протоколов TCP/IP. Эту библиотеку на протяжении многих лет использовали разные производители аппаратного обеспечения для обеспечения работы TCP/IP во встроенном микрокоде firmware на множестве разных типов устройств. Данный пакет уязвимостей получил общее название Ripple20.Уязвимости, входящие в состав Ripple20, имеют разные уровни критичности и среди них есть некоторые опасные уязвимости, позволяющие удалённо вызвать отказ в обслуживании или даже получать полный доступ над устройством со всеми вытекающими последствиями.
Данная проблема была освещена на множестве интернет-ресурсов, связанных с темой информационной безопасности. Вот некоторые из них:
- Блог Касперского - Ripple20: 19 уязвимостей в библиотеке TCP/IP
- SecurityLab - Уязвимости Ripple20 затрагивают миллиарды устройств по всему миру
- "Хакер" - Сотни миллионов IoT-устройств в опасности из-за уязвимостей Ripple20
Часть вендоров на протяжении нескольких месяцев после огласки Ripple20 выпустили обновления микрокода для своих продуктов, в которых закрываются данные уязвимости. Однако некоторые производители намеренно отказались от обновления микрокода некоторых своих продуктов, снятых с текущей поддержки. Таким образом, все уязвимые устройства, не имеющие обновления, но по прежнему эксплуатируемые в рамках локальных/глобальных сетей, вошли в группу повышенных рисков нарушения режима ИБ.
Проблема с уязвимостями Ripple20 заключается в том, что работа по снижению рисков в рамках больших корпоративных сетей с множеством устройств разных производителей и моделей, требует комплексного подхода с применением разных методик защиты, таких как обновление микрокода, ужесточение правил меж-узлового взаимодействия на уровне сети, использование систем обнаружения сетевых аномалий и т.д.
Применительно к вопросу обновления микрокода на эксплуатируемых сетевых устройствах, требуется отдельное планирование и немалый объём работы по устройствам каждого отдельно взятого производителя и модели. В данной заметке мы рассмотрим вариант сбора информации относительно модулей управления источников бесперебойного питания (ИБП) марки APC ("APC by Schneider Electric"), которые широко используются для защиты электропитания серверного и сетевого оборудования.
-
Важное обновление микрокода накопителей HPE SAS SSD
В конце Ноября и начале Декабря компания Hewlett Packard Enterprise опубликовала пару сервисных бюллетеней, описывающих критическую проблему с некоторыми моделями накопителей SSD, произведённых в Samsung и поставляемых в рамках комплектации серверных платформ и СХД от HPE.В накопителях HPE SAS SSD с версией микрокода ниже, чем HPD8, проявляется ошибка, приводящая к выходу из строя накопителя с потерей всех данных после работы накопителя в течении 32768 часов (3 года, 270 дней и 8 часов). Усугубить проблему может ситуация, в которой из однотипных дисков, подверженных описанной проблеме, построен RAID массив и одновременный выход из строя сразу нескольких таких дисков может привести к потере данных всего RAID массива. Читать далее...
-
Icinga плагин check_snmp_value_from_range для отслеживания вхождения значения в допустимый диапазон значений, извлекаемых по протоколу SNMP (на примере мониторинга входного напряжения ИБП)
Продолжая тему мониторинга сетевых устройств по протоколу SNMP в Icinga на примере модулей управления источников бесперебойного питания (ИБП), можно в очередной раз отметить тот факт, что рассмотренная ранее схема с использованием плагина check_snmp дает нам лишь базовые возможности обработки получаемых по SNMP данных. Когда описанным базовым методом мы начали мониторить входное напряжение ИБП разных производителей и разных моделей, со временем пришли к выводу, что использование статически заданных границ (верхней и нижней) для входного напряжения – не очень приемлемый вариант. Проблема заключалась в том, что даже в рамках одной марки ИБП в нашем окружении присутствует множество разных моделей, каждая из которых имеет свои допустимые рабочие диапазоны входного напряжения. При этом на некоторых моделях ИБП эти диапазоны могут регулироваться администратором, как в сторону сужения, так и в сторону расширения.
Онлайн-курсы Евгения Лейтана
Внедрение Microsoft System Center Operations (SCOM) 2016/201913 уроков (6 часов видео), лабораторные работы и вручение именного сертификата.
Промокод "IT-KB_60" со скидкой 60%!
