Дневник спящего админа

Слава Б-гу, я с ними больше не работаю.

Если вы настроили на устр-ве получение сетевых параметров по DHCP, то оно будет неспособно разрешать DNS имена до тех пор, пока не пройдёт половина времени аренды IP-адреса выданного устр-ву ИЛИ вы вручную не ОБНОВИТЕ сетевые параметры устр-ва. При этом на странице dnstest.htm вы будете получать следующие сообщения: «DNS server could not process query», «DNS request has timed out».
При использовании протокола BOOTP или статических параметров, всё работает нормально.

Учитывая, что это не позволяет использовать устр-во по его прямому назначению в течение нескольких часов (NetBotz не может соединиться с почтовыми серверами/системами мониторинга для оповещения о проблеме, если они указаны по DNS-имени), это можно рассматривать как гарантийный случай для возврата всех ваших устр-в производителю.
Номер запроса в поддержке, если кому пригодится (ссылаться на, например): 111117-001466.

Вот вам, например, событие:
; MM: Maximum temperature threshold violation.
E2E05=E,E[++05M+240M-1:::],T[++05M-20M-1:::::]

; - определяет строку как комментарий
MM: Maximum temperature threshold violation. - название события
E2E05 - код события (НЕ код трапа). Этот код видно и в веб-интерфейсе. Ссылка на него будет выглядеть примерно таким образом: http://192.0.2.1/eventdtl.htm?code=0x2E05
=
E - такое впечатление, что здесь указывается E, если хоть что-то хоть куда-то отправляется, и ES, если ничего никуда не отправляется
,
E - начало секции E-mail
[
+ - вкл/выкл оповещений (+/-) для конкретного получателя
+ - вкл/выкл задержки (+/-)
05 - цифра задержки
M - буква задержки (S/M/H)
+ - вкл/выкл повтора (+/-)
240 - цифра повтора
M - буква повтора (S/M/H)
-1 - кол-во повторов. «-1», если «until cleared» или двузначное число, указывающее кол-во раз
::: - разделы для конфигурации других получателей
]
,
T - начало секции SNMP-trap'ов. Формат секции аналогичен предыдущему.

Получатели указываются в строке конфигурации события слева направо, по возрастанию номеров (EmailReceiver1Address, EmailReceiver2Address и т.д.). Разделяются двоеточиями («:»). Если секцию для получателя в конфигурационной строке не заполнять, то, по умолчанию, после активации получателя, оповещения отправляться ему БУДУТ. То есть ВСЕ события, где ЯВНО не указан «-» в соответствующей секции. Да, отсутствие знака равно знаку плюса («+»).
Как же активировать получателя через конфигурационный файл? Очень просто: задать соответствующему параметру EmailReceiverXAddress, где X - цифра от 1 до 4, значение отличное от «address@example.com».

Там выше я написал, что всем получателям по умолчанию сообщения отправляются. Это действительно так, но не забывайте, что у получателя есть параметр EmailReceiverXEnable со значениями enabled/disabled соответственно. Разумеется, если вы активируете получателя, но не активируете отправку ему сообщений в этом параметре, получатель ничего получать не будет.

И ещё об умолчаниях. У меня сейчас нет каких-то внятных результатов, но, похоже, умолчание для отправки событий такое: +-05S+02M-1

А вот событие очистки, которое вызывается, когда условия, вызвавшие предыдущее событие исчезают:
; MM: Maximum temperature threshold violation cleared.
E2E06=ES,E[-:::],T[-:::::]
Как видите, тут всё просто: по умолчанию, есть только конфигурация (+/-) отправки оповещений вообще. Я не эксперементировал пока с установкой задержек и т.п. в событиях очистки, но через веб-интерфейс они не устанавливаются и настроек таких в веб-интерфейсе для них нет.

---

В этом посте я не коснулся таких подробностей, как EM и RS-события и их отличие от MM, нету тут и таблицы соответствия кодов SNMP-trap's и внутренних кодов событий NetBotz. Я планирую это всё описать в дальнейшем, как и дорабатывать, при необходимости, данный пост.

Как известно, кроме отдельных NetBotz'ов-палочек, APC выпускает ещё и платы мониторинга окружающей среды, вставляющиеся в, например, ИБП. И эти самые платы сделаны на той же самой платформе и работают под той же самой операционной системой, что и NetBotz 200. Отличаются они между собой только приложением, которое запускается на этой самой AOS. Система обновления ПО, разумеется, у них тоже общая.
Короче, выяснилось, что эта самая система обновления не производит практически никаких проверок, прежде чем начать обновлять ПО, и спокойно позволяет залить приложение на неподходящее ему устройство. Разумеется, после этого оборудование резко перестаёт нормально работать. Хорошо хоть не брикается и его можно обратно перешить в правильным приложением.
Но, всё-равно, это ж пиздец какой-то, граждане.

Сегодня с 9 утра вызванивал сотрудников APC, ответственных за доставку некоторой запчасти. Вобщем, только сейчас дозвонился. До этого их коллеги вяло отвечали «ну, наверное, ещё не подошли. Попробуйте позвонить позже».

BTW, в HP дозвонился сразу и чётко.

Общение с техподдержкой APC закончилось фразой «ебитесь дорогой кастомер как хотите или вот можете купить у нас Продукт реализующий Функционал».

Не покупайте APC NetBotz RackMonitor 200. Очень сырой продукт.