Меню

Настройка ups по сети

Начальная настройка ИБП APC в Linux с точки зрения чайника

Купив источник бесперебойного питания от APC (а именно — APC Back-UPS ES 550VA ), я с удивленьем обнаружил, что «из коробки» он не может похвастаться тесной дружбою с Linux. Конечно, XFCE Power Manager, входящий в состав XFCE 4.6, подхватил и разпознал UPS, но всё, на что он оказался способен — отображение в трее уровня заряда. Какие-либо настройки отсутствовали начисто, нельзя было даже задать выключение ПК при достижении определённого уровня заряда.

Обратившись за консультацией в гугл, я узнал о существовании замечательного демона apcupsd, чья роль заключается в — никогда не поверите — управлении ИБП от APC. Но, как оказалось, практически все руководства по его начальной настройке были откровенно устаревшими — включая, как ни странно, официальный мануал. Споткнуться приходилось уже в самом начале о «cat /proc/bus/usb/devices». Поговорив с гуглом серьёзным и доверительным тоном, я добился от него ссылки на действующий мануал, художественным переводом коего с дополнениями из иных источников сия статья и является.

Итак, начнём с установки самого apcupsd:

sudo apt-get install apcupsd

Разумеется, вышесказанное справедливо для Debian и его производных, включая Ubuntu. Если в вашем дистрибутиве не используется apt-get — думаю, вы всё равно знаете, как поставить необходимый пакет. Надеюсь на это.

Теперь мы отредактируем конфигурационный файл apcupsd:

sudo gedit /etc/apcupsd/apcupsd.conf

В данном случае нас интересуют всего три параметра:

UPSCABLE — указываем тип кабеля, которым наш UPS подключён к ПК. В комментариях указаны возможные типы — simple, smart, ether, usb. Нынешние домашние модели подключаются через USB — следовательно, достаточно дописать usb
UPSTYPE — тип подключённого UPS. В комментариях перечислены возможные типы и соответствующие им значения параметра DEVICE, наш же выбор — тип usb
DEVICE — закомментируем данную строку, поставив перед ней знак # — для USB-устройств она не нужна

Сохраняем изменённый конфигурационный файл, открываем следующий:

sudo gedit /etc/default/apcupsd

Заменяем ISCONFIGURED=no на ISCONFIGURED=yes, сохраняем, закрываем. Отныне apcupsd будет знать, что мы не забыли его настроить.

Теперь достаточно запустить apcupsd:
sudo /etc/init.d/apcupsd start

Если он уже был запущен — вместо start нам, разумеется, надо будет писать restart.

Всё, ваш ПК теперь связан с новеньким ИБП прочными узами дружбы.

А теперь немножко о том, что мы можем настроить в обширном /etc/apcupsd/apcupsd.conf:

ONBATTERYDELAY — время (в секундах), определяющее задержку между обнаружением сбоя электропитания и отсылкой события onbattery. По умолчанию — 6
BATTERYLEVEL — уровень заряда батареи (в процентах), при котором инициируется выключение компьютера. По умолчанию — 5
MINUTES — расчётное время остаточной работы (в минутах), при достижении которого инициируется выключение компьютера. По умолчанию — 3
TIMEOUT — параметр актуален для старых ИБП, неспособных определять свой уровень заряда. Задаёт время (в секундах) между сбоем электропитания и отключением компьютера. Для современного ИБП параметр стоит оставить на 0, но выставление иного значения может быть удобно для тестирования работы ИБП. Например, если выставить 30 и выдернуть шнур из розетки, уже через полминуты apcupsd продемонстрирует своё умение выключать компьютер

Выполнения одного из условий (BATTERYLEVEL, MINUTES или TIMEOUT) достаточно для выключения компьютера. Более тонкая настройка не описывается, ибо её необходимость для домашнего пользователя весьма сомнительна.

Долго сказка сказывается, да недолго дело делается: полагаю, описанные действия пользователь произведёт за пару минут. Надеюсь, данная статья поможет кому-нибудь подружить его ИБП APC с Linux, сэкономив время и не завязнув в устаревших мануалах.

Источник

Network UPS Tools (NUT) на CentOS и Windows с отправкой смс через smstools+playsms

В условиях ограниченного бюджета небольшой компании, скромный терминальный сервер 2003 получал бесперебойное электричество от Ippon Smart Winner 1500, который управлялся стандартной утилитой. Не могу чего-то сильно плохого сказать про этот ИБП и его монструозную утилиту управления с анимацией тока. Гудит вполне на свои деньги.

Со временем, windows пришлось обременить парой виртуальных машин Vmware, а парк пополнился парой небольших линуксовых серверов с АТС, Jabber и прочими офисными радостями. Соответственно, возникло желание тоже управлять их питанием от Ippon, ибо заявлена поддержка *nix.

Однако, хотя производитель «по взрослому» предусмотрел множество расширенных возможностей управления, включая клиенты под *nix и mac, смс и email оповещение и т.д., попытки практического применения всего этого болезненны, а результат непредсказуем.

Как все дороги ведут в Рим, так и проблемы с Ippon ведут к NUT. В сети масса информации об этой чудесной утилите, в т.ч. и на Хабре есть примеры настройки.
Под *nix работать с NUT одно удовольствие. Просто, понятно, логично.

Читайте также:  Настройка горячих клавиш в квике

В сервер c CentOS, непосредственно соединенный с ИБП по USB, я воткнул GSM-модем Teleofis-RX104 и подружил его с smstools3 и playsms, чтобы получился импровизированный sms-шлюз с поддержкой webservices api. В результате, получился удобный универсальный инструмент для разного рода оповещений, в т.ч. и офисной работы

Далее, установил готовый NUT из EPEL-репозитория, прописав в конфигах:

Информация о портах и vendor/product из вывода lsusb, вольтаж подобран экспериментально, чтобы всем хватило времени на корректное выключение, т.к. алгоритм завершения работы включается при остаточном напряжении батареи ниже, чем default.battery.voltage.low

В NUT есть и переменная battery.charge, в которую записывается предположительный математический остаток батареи в %. Он наглядный, но для управления не очень удобен:

Пользователи, которые могут подключаться и смотреть/управлять/управляться ИБП. admin — для управления ИБП, upsmon_local — для мониторинга состояния ИБП на локальном сервере, upsmon_remote — для управляемых клиентов. Пароли по вкусу:

Это самый интересный конфиг, в котором описывается поведение NUT при разных состояниях ИБП. MONITOR указывает, что мы подключаемся к локальной службе NUT и будем мастером, т.е., в случае чего — будем выключать ведомых, а сами умрем последними. Строка NOTIFYCMD указывает какая команда будет выполняться для уведомления. У меня — это вызов /usr/local/ups/notifyme следующего содержания:

В команду передаются те аргументы NOTIFYFLAG, где есть флаг EXEC. Все переданные аргументы помещаются в строке после «servername:» (чтобы было понятно кто пишет) и отправляются на 7903*******. То есть, при отключении тока придет смс «servername: UPS winner1500 on battery» Текст уведомлений можно менять.

Второй Centos-сервер настраивается еще проще. Фактически, нам нужен только монитор состояния мастер-сервера и ожидание вестей от него. Но раз уж у нас есть playsms, то можно и от него получать смс, например, о том есть ли связь с мастером (не умерла ли на нем служба NUT)

То есть, ставим EXEC там, где нас интересуют проблемы со связью и прошла ли команда отключения питания от мастера.
Для отправки смс, я задействовал playsms, которому curl передает текст в виде GET-url. Для этого изначально нужно в настройках пользователя playsms включить webservices и сгенерировать webservices token. После этого, в /usr/local/ups/notifyme второго сервера указываем:

То есть, все то же самое, что и в первом варианте, только заменить пробелы на + и отправить через GET-запрос.

В windows все немного обросло костылями. На сервер был установлен пакет NUT-Installer-2.6.5-3.msi Который по дефолту установился в C:\Program Files\NUT и чудесно запустился службой без особых проблем. И curl для отправки уведомлений через playsms.

Настройка NUT аналогична второму серверу-слэйву, т.е. MODE-netclient, основное в upsmon.conf и костылях.

Здесь файл уведомления notify.cmd следующего содержания (смысл от которого не меняется):

Вот собственно и весь сказ. Если нужно что-то уточнить-дополнить буду рад

msg=%* в notify.cmd делает батник относительно универсальным для разных задач. То есть, добавив в автозагрузку «notify.cmd started» получим уведомление «servername:started» на смс.

Я не преминул это использовать для мониторинга жесткой перезагрузки с BSOD 0x9, которую мне устраивал symantec. Убирать не стал. Мониторинг hard reset полезен:

Путь к батнику появился потому, что мне было желательно перед выключением сервера корректно выключить виртуальную машину с помощью vmrun из комплекта VMware VIX.

Так как машина была запущена в виде службы утилитой AlwaysUp, то команду корректного останова машины «C:\Program Files\VMware\VMware VIX\vmrun.exe» stop S:\vmachine.vmx я прописал в AlwaysUp, а в батнике уже лишь контролировал службу и писал лог, чтобы если что — таймауты прибавить. Получилось:

То есть, когда батарейка тикает — негоже ждать выключения виртуалки дольше определенного лимита, если она повисла или вообще не запущена

Источник

Настройка NUT для управления ИБП с нескольких серверов

NUT — это Network UPS Tools или набор программных компонентов, предназначенных для мониторинга силовых устройств, таких как источники бесперебойного питания (ИБП), блоки распределения питания, солнечные контроллеры и блоки питания серверов.

В среде Linux — NUT — это стандарт де-факто для управления ИБП, который позволяет производить мониторинг ИБП не только с сервера к которому подключен ИБП, но и по сети, а так же выполнят ряд действий при наступлении определенных условий. Например, в случае когда заряд батарей ИБП истощается NUT может произвести корректное завершение работы серверов и уведомить об этом системного администратора.

Исходные данные:
1. В локальной сети организации есть 2 сервера под управлением Debian 8.9 (jessie) и 1 сервер под управлением Windows Server 2012 R2;
2. Есть ИБП компании APC, модель Smart-UPS 1000. ИБП подключен по USB к одному из серверов Debian 8.9 (jessie);

Читайте также:  A4tech bloody b120 настройка макросов

Задача:
На сервере Debian 8.9 к которому подключен ИБП установить серверную часть NUT и настроить клиентскую часть NUT на этом сервере и других серверах. В случае перехода питания серверов на ИБП и истощения заряда батарей ИБП нужно произвести корректное завершение работы всех серверов.

Распределение IP адресов во внутренней сети компании между серверами:
192.168.100.1 (srv1.mycompany.ru) — Сервер Debian 8.9 (jessie) к которому подключен APC Smart-UPS 1000 по USB — на нем будет серверная часть NUT и клиентская;
192.168.100.2 (srv2.mycompany.ru) — Сервер Debian 8.9 (jessie) — на нем будет клиентская часть NUT;
192.168.100.3 (srv3.mycompany.ru) — Сервер Windows 2012 R2 — на нем будет клиентская часть NUT;

Настройка серверной части NUT.

1. Проверим факт обнаружения нашего ИБП ядром Linux с помощью утилиты lsusb:

Для ИБП марки APC Smart-UPS значения idVendor и idProduct будут 051d и 0002 соответственно.

2. Установка NUT (серверной части на хосте 192.168.100.1):

Далее отредактируем файл /etc/nut/ups.conf и приведем его к виду:

Этой минимальной конфигурации хватит для нашего ИБП.

Как Вы уже догадались в файле /etc/nut/ups.conf описываются все наши ИБП, а так же драйвер и их параметры для работы с NUT.

Нашему ИБП мы присвоили имя apc и будем использовать драйвер usbhid-ups.
Драйвер usbhid-ups гарантировано работает с ИБП Smart-UPS компании APC.
Более детально со списком драйверов и списком ИБП каких фирм может работать NUT описано на этой странице. Список параметров драйвера usbhid-ups можно посмотреть на этой странице.

3. Настройка драйвера NUT для работы с нашим ИБП.

Далее нам нужно установить права на наше USB устройство чтобы драйвер NUT смог работать с ним.

Для этого создадим правило /etc/udev/rules.d/90-nut-ups.rules для udev со следующим содержимым:

Далее нужно перечитать все правила, для этого выполним:

Для тех кто хочет понять в чем тут дело, объясняю:

При выводе информации по нашему ИБП с помощью lsusb мы можем увидеть строку «Bus 004 Device 003»:

Она говорит, что ядро Linux при подключении нашего ИБП по USB присвоило ему номер шины обмена данными 4 и id устройства 3, само наше устройство соответственно будет находится по такому пути /dev/bus/usb/004/003 а владельцем будут пользователь root и группа root с правами 664 (crw-rw-r—), но для работы драйвера NUT этого не достаточно, драйвер в таком случае не сможет управлять устройством.

С помощью файла /etc/udev/rules.d/90-nut-ups.rules и утилиты udevadm мы задали правило для сервиса udev который управляет периферией, получая от Linux ядра разного рода уведомления. По этому правилу для нового устройства с определенным idVendor и idProduct владельцем будет назначаться группа nut.

Если интересно, то запросить информацию у udev по нашему устройству можно так:

4. Теперь запустим все драйвера NUT описанные в /etc/nut/ups.conf с помощью команды:

Если в файле /etc/nut/ups.conf у Вас описаны несколько ИБП, то остановить конкретный драйвер или запустить его можно так:

5. Теперь опишем права доступа к нашему серверу NUT для доступа клиентских ОС по сети, за это отвечает файл /etc/nut/upsd.conf

Директива LISTEN задает адрес и порт на котором будет принимать соединения демон upsd (Сервер NUT).

ВНИМАНИЕ! Директивы ACL, ACCEPT, REJECT в файле /etc/nut/upsd.conf больше не используется и является устаревшей.

6. Теперь опишем пользователей и пароли для подключения клиентских устройств к серверу NUT, за это отвечает файл /etc/nut/upsd.users:

В секции [admin] мы описали пользователя для управления NUT через утилиту upscmd, а так же разрешили менять все параметры самого ИБП (строка actions = SET и instcmds = ALL).
Если нужно разрешить пользователю admin менять только определенные параметры, то их нужно описать в опции instcmds, например так:

Секции [local_mon] [srv2_mon] и [srv3_mon] описывают пользователей для клиентских ОС, на них будет стоять клиентская часть NUT.
В этих секциях мы указали индивидуальные пароли (опция password) и статус этих пользователей (опция upsmon).

Для пользователя local_mon мы указали в опции upsmon значение master, это сделано не спроста, дело в том что на том же ПК, где у нас будет работать сервер NUT мы настроим и клиентскую часть NUT и когда сервер NUT отправит всем клиентам сигнал о критическом состоянии батарей ИБП, то master должен выключиться самым последним из серверов, дождавшись выключения всех slave серверов.

ВНИМАНИЕ! Директива allowfrom в файле /etc/nut/upsd.users больше не используется и является устаревшей.

7. Настроим режим работы NUT на сервере 192.168.100.1 (работа в режиме сервера), для этого в файле /etc/nut/nut.conf напишем:

Читайте также:  Xerox 3325 настройка сканирования по сети

8. Запустим сервер NUT:

И проверим его статус:

Проверим открытые порты:

Настройка клиентской части NUT на серверах.

1. Настроим клиент мониторинга (upsmon), который будет заниматься слежением за состоянием ИБП и правильным завершением работы сервера при отсутствии электричества и полном разряде батарей. (Первый клиент у нас будет на том же хосте, что и сервер NUT, то есть на 192.168.100.1):

Для этого отредактируем файл /etc/nut/upsmon.conf и приведем его к виду:

Директиву NOTIFYCMD в которой как правило задают запуск планировщика upssched, а далее настраивают upssched.conf мы не используем. Если Вам нужно настроить уведомления на email или в мессенджеры и кастомизировать процедуру выключения, то тогда нужно настраивать планировщик. Но нам это пока не нужно.

Самое интересное здесь — это директива

В ней описывается подключение к нашему серверу NUT, формат здесь простой:
MONITOR @

— берется с сервера NUT из файла /etc/nut/ups.conf, в нашем случае apc;
— думаю тут все понятно, для локального клиента это localhost;
— как правило это 1, если Вам нужно контролировать переход на питание от ИБП, но выключать этот сервер по сигналу NUT Вы не хотите, то установите этот параметр в 0;
и — думаю тут тоже все понятно, данные берутся с сервера NUT из файла /etc/nut/upsd.users;
— если указана опция master, то данный сервер будет выключаться после выключения всех slave серверов;

Так же нужно остановиться на директиве POWERDOWNFLAG и разъяснить как происходит отключение системы в случае когда заряд батарей ИБП истощается.
Итак, в режиме работы от батарей, перед самым их истощением, ИБП генерирует сообщение «battery low». Демон upsmon получает это сообщение от сервера NUT (от upsd) и обрабатывает этот сигнал, вызывая команду описанную в опции SHUTDOWNCMD для корректной остановки системы. Более детально данный процесс можно описать следующей последовательностью:
1. ИБП генерирует событие «battery low»;
2. upsmon получает данный сигнал от сервера NUT и инициирует выключение ПК;
3. Создается специальный файл POWERDOWNFLAG, являющийся признаком того, что система находится в режиме отключения в связи с истощением батарей ИБП;
4. Выполняется команда SHUTDOWNCMD;
5. RC-сценарий использует проверку флага POWERDOWNFLAG для предотвращения так называемой «энергетической гонки» (power race);

«Энергетической гонкой» называется ситуация, когда ИБП переходит в режим работы от сети вскоре после генерации сигнала «battery low», в процессе останова системы. В этом случае компьютер, настроенный на автоматическое включение после сбоя электропитания окажется заложником собственной «осторожности», ведь фактически никакого сбоя не произойдет. Многие современные ИБП имеют механизмы разрешения такой ситуации и дополнительного анализа POWERDOWNFLAG флага на стороне ОС как правило не нужно, но знать про это необходимо.

Теперь перезапустим клиента NUT командой

И проверим его статус:

Проверить подключение к серверу и вывести все параметры ИБП можно командой:

Посмотреть значение какого-то конкретного параметра можно указав дополнительно его имя:

Кроме того, как я писал выше есть более сложный клиент (upscmd), который позволяет не только просматривать настройки, но и выполнять команды.
Список доступных команд можно увидеть вот так:

2. Теперь настроим клиент мониторинга NUT (upsmon) на сервере под управлением Debian Linux (хост 192.168.100.2):

Отредактируем файл /etc/nut/upsmon.conf и приведем его к виду:

Отредактируем файл /etc/nut/nut.conf и приведем его к виду:

Теперь перезапустим клиента NUT командой

И проверим подключение к серверу NUT путем вывода всех параметров ИБП командой:

3. Теперь настроим клиента мониторинга NUT (upsmon) на серверe под управлением Windows Server 2012 R2 (хост 192.168.100.3):

Скачиваем инсталлятор NUT под Windows с официального сайта и устанавливаем.

Скачиваем OpenSSL 1.0.2q (x86) или новее, но обязательно x86 версию (Win32 OpenSSL v1.0.2q Light) и устанавливаем, в процессе установки когда нас спросят копировать файлы библиотеки в системную паку — отказываемся, далее копируем 3 файла (ssleay32.dll, libssl32.dll и libeay32.dll) из «C:\OpenSSL-Win32\» в «C:\Program Files (x86)\NUT\bin\»

Переименовываем файл «C:\Program Files (x86)\NUT\etc\nut.conf.sample» в «C:\Program Files (x86)\NUT\etc\nut.conf» и пишем в конце файла:

Далее переименовываем файл «C:\Program Files (x86)\NUT\etc\upsmon.conf.sample» в «C:\Program Files (x86)\NUT\etc\upsmon.conf» и приводим его к виду:

Открываем консоль cmd с правами Администратор и рестартуем службу:

И наконец там же из cmd проверяем подключение к серверу NUT путем вывода всех параметров ИБП командой:

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

Источник