Diggers Nonformal Group

К огромному сожалению, данная линейка ИБП оказалась совершенно "неуправляемой" с помощью NUT. Только мониторинг.
В чем фича управляемых ИБП - так это в том, что, в отличие от неуправляемого, управляемый ИБП получет от nut_upsmon, запущенного на nut-сервере, сигнал FSD (forced shutdown), ждёт некоторое время, давая nut-серверу возможность послать сигнал шатдауниться slave-машинам и корректно зашатдауниться самому, а потом ИБП выключается сам, дабы в случае появления напряжения в электросети включиться, в результате подключенные машины автоматически включаются сами.
Наш же красавец на FSD реагирует вот так:

Aug 19 10:47:43 dune megatec[1980]: UPS refuses to turn the load off indefinitely. Will turn off for 9999 minutes instead.

Причем, эту строку удалось получить в лог, посылая команду "Turn off load and stay off" из веб-cgi-интерфейса NUT.

Примеры настройки nut-netserver и nut-client (пригодится с "нормальным" ИБП)

Вначале, смотрим сюда: http://dng.kiev.ua/node/10 . Откомментирую пару моментов:
1. Файл hosts.conf нужен для работы того самого cgi-web-интерфейса, больше - ни для чего.
2. В файле upsmon.conf смотрим на строки
MONITOR mustek@127.0.0.1 1 monmaster mustekpass master
MINSUPPLIES 1
в которых единички означают, что ИБП подключен к одному блоку питания у данной машины. Если же обе единички заненить на 0, то это будет означать, что данная машина не "питается" от мониторимого ИБП, посему, по сигналу FSD эта машина НЕ выключится. Очень удобно для тестирования, для чего данные параметры и рекомендуются.
А теперь, приведу новый вариант upsmon.conf для nut-сервера, а также пояснения, и конфигурацию upssched.conf и содержание скрипта NOTIFYCMD.

root@server# grep -v # /usr/local/etc/nut/upsmon.conf | grep -v ^\$

#RUN_AS_USER root
MONITOR mustek@127.0.0.1 1 monmaster mustekpass master
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown -h +0"
NOTIFYCMD /usr/local/sbin/upssched
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /usr/local/etc/nut/killpower
NOTIFYFLAG ONLINE SYSLOG+EXEC
NOTIFYFLAG ONBATT SYSLOG+EXEC
NOTIFYFLAG LOWBATT SYSLOG+EXEC
NOTIFYFLAG FSD SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK SYSLOG
NOTIFYFLAG COMMBAD SYSLOG
NOTIFYFLAG SHUTDOWN SYSLOG+WALL
NOTIFYFLAG REPLBATT SYSLOG+WALL
NOTIFYFLAG NOCOMM SYSLOG
NOTIFYFLAG NOPARENT SYSLOG
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

RUN_AS_USER - директива нужна, если какие-либо команды не работают от "умолчального" юзера uucp (или выставляем в root, чтоб не париться, или разрешаем в sudoers выбранному юзеру исполнение команд upsmon *, upscmd * и т.д. без пароля).
По поводу SHUTDOWNCMD так и не было достигнуто истины - что лучше, halt или powerdown, для того, чтоб машины потом гарантированно поднялись? Будет вменяемый управляемый ИБП - тогда проверим.
POWERDOWNFLAG был перемещен в директорию /usr/local/etc/nut/ , т.к. владельцем этой директории должен быть юзер uucp, и, соответственно, у этого пользователя есть право писать в свою директорию.
FINALDELAY был возвращен к дефолтовому значению, т.к. с 0 есть возможность не успеть отправить slave-машинам сигнал гаситься.
Далее, NOTIFYCMD и появившиеся в листинге добавочные действия EXEC для некоторых флагов. Это означает, для для флагов с действием EXEC выполняются действия, описанные в скрипте /usr/local/sbin/upssched, согласно прописанному в файле upssched.conf соответствию флагов и действий.

root@server# grep -v # /usr/local/etc/nut/upssched.conf | grep -v ^\$

CMDSCRIPT /usr/local/bin/upssched-cmd
PIPEFN /var/db/nut/upssched/upssched.pipe
LOCKFN /var/db/nut/upssched/upssched.lock
AT LOWBATT mustek@127.0.0.1 START-TIMER early-shutdown 90
AT ONLINE * CANCEL-TIMER early-shutdown resume
AT ONLINE * EXECUTE resume
AT FSD * EXECUTE forced-shutdown

Формат: AT ИМЯ_ФЛАГА НАШ_ИБП ДЕЙСТВИЕ
ИМЯ_ФЛАГА - должно соответствовать NOTIFYFLAG, НАШ_ИБП - задается в форме имя_ИБП@адрес_ИБП, либо * - любой ИБП.
ДЕЙСТВИЕ - если задается таймер, то пишем "START-TIMER имя_таймера время_в_секундах", начинается отсчет таймера, по окончании которого выполняется пункт с именем имя_таймера в скрипте CMDSCRIPT; для действия отмены таймера пишем "CANCEL-TIMER имя_таймера действие_отмены", причем действие_отмены тоже должно быть описано в CMDSCRIPT. С действием EXECUTE должно быть ясно интуитивно, если нет - читаем комментарии в конфиге upssched.conf и документацию по NUT.

root@server# cat /usr/local/bin/upssched-cmd

#! /bin/sh
# This script should be called by upssched via the CMDSCRIPT directive.
#
# Here is a quick example to show how to handle a bunch of possible
# timer names with the help of the case structure.
#
# This script may be replaced with another program without harm.
#
# The first argument passed to your CMDSCRIPT is the name of the timer
# from your AT lines.

#MSG="The UPS is running on battery about 2 minutes, doing force shutdown"

#case $1 in
#fsd)
#/usr/bin/logger -t upssched-cmd $MSG
##/usr/local/sbin/upsmon -c fsd
#;;
#*)
#/usr/bin/logger -t upssched-cmd "Unrecognized command: $1"
#;;
#esac

# time in minutes
time=2
case "${1}" in
early-shutdown)
/usr/bin/logger -t upssched-cmd "Early Shutdown"
/sbin/shutdown -h +$time powerevent
;;
resume)
/usr/bin/logger -t upssched-cmd "Resume"
[ -f /var/run/shutdown.pid ] && /sbin/shutdown -c || exit 0
;;
forced-shutdown)
/usr/bin/logger -t upssched-cmd "Forced Shutdown"
/sbin/shutdown -h +$time powerevent-forced
#/usr/local/sbin/upsmon -c fsd
;;
*)
/usr/bin/logger -t upssched-cmd "Unknown command: ${1}"
;;
esac

В принципе, с нормальным ИБП можно б было не заморачиваться с EXEC для NOTIFYFLAG-ов и расписыванием CMDSCRIPT, эти возможности удобны при отладке либо прикручивании каких дополнительных кастомных действий перед выключением.

Ещё 1 момент - модификация стартового скрипта NUT /usr/local/etc/rc.d/nut:

nut_poststop() {
#${nut_prefix}/libexec/nut/upsdrvctl stop
if [ -r /usr/local/etc/nut/killpower ]; then
logger -t "nut_poststop" "Flag /usr/local/etc/nut/killpower detected!"
rm -f /usr/local/etc/nut/killpower
${nut_prefix}/libexec/nut/upsdrvctl shutdown
fi

${nut_prefix}/libexec/nut/upsdrvctl stop
}

для детектирования того, создается ли POWERDOWNFLAG, а также, в случае наличия оного, однозначной выдачи нашему ИБП команды FSD (что отмечается в логе), и уже потом - остановка драйвера, как для случая, когда FSD не выдан (рестарт демона или ручная остановка), так и для случая с FSD (по идее, тогда оно уже не нужно, но пусть будет).

Пора привести конфигурацию для nut-клиента.

В rc.conf добавляем строку nut_upsmon_enable="YES", этого клиенту хватит.

В /usr/loca/etc/nut/ нам нужны всего 2 конфига:

root@slave:/usr/local/etc/nut# grep -v # nut.conf | grep -v ^\$
MODE = netclient

root@slave:/usr/local/etc/nut# grep -v # upsmon.conf | grep -v ^\$

MONITOR mustek@100.100.232.8 1 monslave slavepass slave
MINSUPPLIES 1
SHUTDOWNCMD "/sbin/shutdown h +0"
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 12
DEADTIME 15
NOTIFYFLAG ONLINE SYSLOG
NOTIFYFLAG ONBATT SYSLOG
NOTIFYFLAG LOWBATT SYSLOG
NOTIFYFLAG FSD SYSLOG+WALL
NOTIFYFLAG COMMOK SYSLOG
NOTIFYFLAG COMMBAD SYSLOG
NOTIFYFLAG SHUTDOWN SYSLOG+WALL
NOTIFYFLAG REPLBATT SYSLOG
NOTIFYFLAG NOCOMM SYSLOG
NOTIFYFLAG NOPARENT SYSLOG
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 4

При этом, естественно, на NUT-сервере в upsd.conf должна быть директива
LISTEN 100.100.232.8 3493, в фаерволлах на обеих машинах - разрешены соединения на и с порта 3493,
также на NUT-сервере в upsd.users дополнительно пропишем пользователя для slave-машин:

[monslave]
password = slavepass
upsmon slave

P.S. Для тех, кто надеется завести этот ИБП через USB, вот ссылка на обломинго: http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.org/msg04367...

И пару слов о поведении slave. Мне казалось, что, если nut-клиент теряет связь с nut-сервером, upsmon даст nut-клиенту сигнал шатдауниться. На самом деле - ничего подобного. Просто в логах отмечается, что

Aug 17 13:18:57 slave upsmon[1566]: Poll UPS [mustek@100.100.232.8] failed - Server disconnected
Aug 17 13:19:02 slave upsmon[1566]: UPS [mustek@100.100.232.8]: connect failed: Connection failure: Connection refused
Aug 17 13:19:37 slave last message repeated 7 times
Aug 17 13:19:37 slave upsmon[1566]: UPS mustek@100.100.232.8 is unavailable

и ничего не происходит.