Munin SSH transport

This entry is part [part not set] of 1 in the series munin

Решил настроить munin сервер для опроса порядка 500 нод.
В штатном режиме сервер опрашивает ноду по дефолтному порту 4949. Это прекрасно и замечательно, когда этот порт доступен “напрямую”. В моём случае большинство серверов сидят за чужим NAT-ом и наружу проброшен только ssh, причём ещё на какой-нибудь высокий порт. Или есть второй распространённый вариант – проброшен порт от одного сервера, а остальные доступны только по внутренней сети.
Доступ по ssh открыт, так как это является нашим основным требованием к сети заказчика.
В официальной документации как-то не сильно рекламируют возможность работы через ssh, но, как оказалось, в munin 2.x она есть. О её существовании помог узнать большой брат, который вывел на ссылку http://munin-monitoring.org/wiki/Native_ssh.
В принципе всё понятно, за исключением конфигурации с нестандартным ssh портом, но об этом чуть позже.
Тестовый сервер у меня был поднят на OpenBSD и серверная часть munin запускалась с правами пользователя _munin, который по умолчанию вместо shell имеет /sbin/nologin. Продакшн настраивал на Scientific Linux, в котором munin запускается от пользователя munin. Соответственно для возможности подключения по ssh к нодам надо было в обоих случаях этому пользователю прописать рабочий шелл, например /bin/sh, создать домашнюю директорию, сгенерировать ключи при помощи ssh-keygen (ключ должен быть без passphrase) и переслать публичный ключ на ноду для той учётной записи, под которой планируется на неё заходить. Пусть учётка на ноде зовётся user. Соответственно в домашней директории пользователя user в .ssh/autorized_keys должен быть прописан публичный ключ пользователя munin с сервера.
На машине с munin-node должен быть установлен netcat (nc), который позволит обращаться к munin-node через:

nc localhost 4949
# munin node at ms13090624.domain
list
df mssversion uptime

То есть для подобного режима работы ноде достаточно слушать только на 127.0.0.1 и отвечать на запросы тоже только с локалхоста. Одним сервисом “глядящим” наружу будет меньше.
Значимые строки в munin-node.conf для подключения к ней при помощи nc с localhost:

host_name ms13090624.domain
allow ^127\.0\.0\.1$
host 127.0.0.1

Вручную ноду можно проверить запустив с сервера через ssh nc на ноде:
sudo -u munin ssh user@xxx.xxx.xxx.xxx nc localhost 4949
В ответ должны получить приглашение munin-node, как и при локальном подключении.
Кусок конфига munin.conf для опроса ноды по 22 порту (описан в документации к munin):

[ms13090624.domain]
use_node_name no
address ssh://user@xxx.xxx.xxx.xxx/usr/bin/nc localhost 4949

Про использование альтернативного порта ssh я в документации не увидел ни слова, но просмотр кода и дальейшие тесты на стенде показали, что в конфиге сервера порт указывается вот в таком формате:

[ms13090622.domain]
use_node_name no
address ssh://user@xxx.xxx.xxx.xxx:2022/usr/bin/nc localhost 4949

то есть через двоеточие сразу после IP.

Про усложнённый вариант подключения через ssh туннель в оригинальной документации впринципе ничего не говорят. Подозреваю, что это не самый распространённый вариант доступа к ноде. Но особенности топологии сетей заказчиков подтолкнули к внимательному изучению конфига и кода, этот конфиг парсящему. В результате оказалось, что всё довольно просто:

[ms13090625.domain]
use_node_name no
address ssh://user@zzz.zzz.zzz.zzz:2022/usr/bin/ssh user1@192.168.xxx.yyy /usr/bin/nc localhost 4949

ms13090625.domain – имя внутренней машины, прописанное в конфиге ноды
192.168.xxx.yyy – IP ноды, которая находится во внутренней сети
zzz.zzz.zzz.zzz:2022 ИП и порт машины к которой мы имеем доступ по ssh извне и с которй по ssh можно попасть на машину во внутренней сети, т.е. на ноду.

Итого для работы через туннель к “обычному” конфигу доступа по ssh вида
address ssh://user@zzz.zzz.zzz.zzz:2022/usr/bin/nc localhost 4949
добавилась команда для подключения с внешнего сервера на внутреннюю ноду: /usr/bin/ssh user1@192.168.xxx.yyy

Надеюсь это понятно сразу, что user на внешнем сервере должен быть обменян ssh ключом с user1 на внутреннем (ноде) для беспарольного доступа.

Share

apcupsd и несколько UPS

Иногда возникает необходимость управлять несколькими UPS на одном сервере даже когда есть несколько серверов и все они запитаны от тех же бесперебойников. Когда-то давно на сервере под RHEL5 я уже настраивал мониторнг нескольких UPS через apcupsd. Так как времена RHEL5 давно минули, то аналогичную конфигурацию я настроил на более современном RHEL6 в виде Scientific Linux 6.4 и apcupsd-3.14.10, последней достуной версии из сторонних пакетов на текущий момент.
Имеем три бесперебойника: Smart-UPS 3000 RM XL, Smart-UPS SC1500 и Smart-UPS SMC1500I-2U.
3000 и SMC подключены через “стандартный” USB кабель, а к SC1500 в комплекте шли кабели RS232-RS232 и RS232-USB, который при проверке оказался обычным Prolific 2303 usb2serial. SC1500 была подключена через usb2serial кабель.
Основной фокус при использовании нескольких бесперебойников заключается в указании apcupsd конфига под конкретную железку. Чтобы было нагляднее, я стандартный apcupsd.conf скопировал в три конфига соответственно: apcupsd-rm3000.conf, apcupsd-cs1500.conf и apcupsd-smc1500.conf.
Из очевидных вещей в каждом каждом конфиге указываем соответствующие UPSNAME исходя из имени бесперебойника. А вот с UPSCABLE, UPSTYPE и DEVICE предстоит заняться более внимательно. С SC1500 всё просто – надо прописать обычные для подключения по последовательному порту параметры UPSCABLE smart и UPSTYPE apcsmart и DEVICE /dev/ttyUSB0. С USB подключением одного ИБП тоже всё просто – параметр DEVICE нужно закоментировать или значение оставить пустым и apcupsd сама найдёт бесперебойник. В случае с двумя ИБП параметр DEVICE надо будет использовать, чтобы “объяснить” apcupsd где какой ИБП.
dmesg в Linux всегда для меня выглядел хаосом (в сравнении с *BSD), так что “поиск” нужного устройства делался распространённым “научным” методом.
Вот что пишет ядро:
# dmesg|grep generic-usb
generic-usb 0003:0557:2221.0001: input,hidraw0: USB HID v1.00 Mouse [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-0000:00:1a.0-1.2/input0
generic-usb 0003:0557:2221.0002: input,hidraw1: USB HID v1.00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-0000:00:1a.0-1.2/input1
generic-usb 0003:051D:0002.0003: hiddev96,hidraw2: USB HID v1.10 Device [American Power Conversion Smart-UPS 3000 RM XL FW:691.19.I USB FW:7.4] on usb-0000:00:1d.0-1.5/input0
generic-usb 0003:051D:0003.0004: hiddev97,hidraw3: USB HID v1.00 Device [American Power Conversion Smart-UPS C 1500 FW:UPS 09.7 / ID=1005] on usb-0000:00:1d.0-1.4/input0

Итого на сервере 4 generic-usb устройства – мышь, клавиатура и два бесперебойника. Про оба бесперебойника ядро пишет hiddev9?,hidraw?.
Устройство /dev/hiddevXX можно не искать – его нет. Зато есть /dev/usb/hiddev?. Найти взаимосвязь между /dev/usb/hiddev? и hiddev??,hidraw? я так и не смог. Продолжая использовать “научный” метод тыка, в конфигурационные файлы для ИБП, подключенных по USB добавил DEVICE /dev/usb/hiddev?.
Помимо этого все три конфигурационных файла отличаются портом, NISPORT на котором висит демон, чтобы можно было получать статус с определённой UPS. Дефолтовый NISIP 0.0.0.0 (привет безопасности по умолчанию) поменял на 127.0.0.1, так как мониторинг apcupsd будет вестись локально. Подправил пути на файлы сообщений и статуса (EVENTSFILE и STATFILE), чтобы у каждого запущенного демона был свой собственный набор файлов.
Окинем взором различие в конфигурационных файлах:
diff3 apcupsd-smc1500.conf apcupsd-cs1500.conf apcupsd-rm3000.conf
====
1:15c
UPSNAME CS1500
2:15c
UPSNAME SMC1500I-2U
3:15c
UPSNAME RM3000
====
1:29c
UPSCABLE smart
2:29c
UPSCABLE usb
3:29c
UPSCABLE usb
====
1:79,80c
UPSTYPE apcsmart
DEVICE /dev/ttyUSB0
2:79,80c
UPSTYPE usb
DEVICE /dev/usb/hiddev1
3:79,80c
UPSTYPE usb
DEVICE /dev/usb/hiddev0
====
1:202c
NISPORT 3552
2:202c
NISPORT 3553
3:202c
NISPORT 3551
====
1:206c
EVENTSFILE /var/log/apcupsd-cs1500.events
2:206c
EVENTSFILE /var/log/apcupsd-smc1500.events
3:206c
EVENTSFILE /var/log/apcupsd-rm3000.events
====
1:241c
STATFILE /var/log/apcupsd-cs1500.status
2:241c
STATFILE /var/log/apcupsd-smc1500.status
3:241c
STATFILE /var/log/apcupsd-rm3000.status

Для мониторинга вручную всё готово. Достаточно запустить /sbin/apcupsd -f /etc/apcupsd/config_name.conf. Для проверки работоспособности запустил apcaccess:
[root@mail apcupsd]# apcaccess
APC : 001,043,1074
DATE : 2014-02-04 14:20:12 +0400
HOSTNAME : **********
VERSION : 3.14.10 (13 September 2011) redhat
UPSNAME : RM3000
CABLE : USB Cable
DRIVER : USB UPS Driver
UPSMODE : Stand Alone
STARTTIME: 2014-02-03 17:25:12 +0400
MODEL : Smart-UPS 3000 RM XL
STATUS : ONLINE
LINEV : 233.2 Volts
LOADPCT : 0.0 Percent Load Capacity
BCHARGE : 100.0 Percent
TIMELEFT : 137.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME : 0 Seconds
OUTPUTV : 233.2 Volts
SENSE : High
DWAKE : -01 Seconds
DSHUTD : 090 Seconds
LOTRANS : 208.0 Volts
HITRANS : 253.0 Volts
RETPCT : 000.0 Percent
ITEMP : 24.7 C Internal
ALARMDEL : 30 seconds
BATTV : 55.1 Volts
LINEFREQ : 50.0 Hz
LASTXFER : Automatic or explicit self test
NUMXFERS : 0
TONBATT : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
SELFTEST : NO
STESTI : 14 days
STATFLAG : 0x07000008 Status Flag
MANDATE : 2010-12-17
SERIALNO : XXXXXXXXXXX
BATTDATE : 2010-12-17
NOMOUTV : 230 Volts
NOMBATTV : 48.0 Volts
FIRMWARE : 691.19.I USB FW:7.4
END APC : 2014-02-04 14:20:56 +0400

В данном случае apcaccess выводит информацию, которую по умолчанию берёт на 127.0.0.1 и стандартном порту 3551. Для получения информации о двух других бесперебойниках надо указать соответствующие порты (3552 и 3553):
[root@mail apcupsd]# apcaccess status 127.0.0.1:3552
APC : 001,048,1181
DATE : 2014-02-04 14:23:51 +0400
HOSTNAME : **********
VERSION : 3.14.10 (13 September 2011) redhat
UPSNAME : CS1500
CABLE : Custom Cable Smart
DRIVER : APC Smart UPS (any)
UPSMODE : Stand Alone
STARTTIME: 2014-02-03 12:36:35 +0400
MODEL : Smart-UPS SC1500
STATUS : ONLINE
LINEV : 230.0 Volts
LOADPCT : 9.1 Percent Load Capacity
BCHARGE : 100.0 Percent
TIMELEFT : 121.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME : 0 Seconds
MAXLINEV : 230.0 Volts
MINLINEV : 230.0 Volts
OUTPUTV : 230.0 Volts
SENSE : High
DWAKE : 000 Seconds
DSHUTD : 060 Seconds
DLOWBATT : 02 Minutes
LOTRANS : 208.0 Volts
HITRANS : 253.0 Volts
RETPCT : 000.0 Percent
ALARMDEL : 5 seconds
BATTV : 26.9 Volts
LINEFREQ : 50.0 Hz
LASTXFER : Line voltage notch or spike
NUMXFERS : 0
TONBATT : 0 seconds
CUMONBATT: 0 seconds
XOFFBATT : N/A
SELFTEST : NO
STESTI : 336
STATFLAG : 0x07000008 Status Flag
REG1 : 0x00 Register 1
REG2 : 0x00 Register 2
REG3 : 0x00 Register 3
MANDATE : 05/31/12
SERIALNO : XXXXXXXXXXX
BATTDATE : 05/31/12
NOMOUTV : 230 Volts
NOMBATTV : 24.0 Volts
FIRMWARE : 738.3.I
END APC : 2014-02-04 14:24:07 +0400

Осталось самое весёлое – подправить rc.d скрипты чтобы все три демона стартовали автоматически при запуске системы. Идём в /etc/rc.d/init.d/, где объектом изменений будет скрипт apcupsd. Его так же копирую, в соответствии с вышеописанными именами файлов конфигурации: apcupsd-rm3000, apcupsd-smc1500 и apcupsd-cs1500, а затем редактирую новые стартовые скрипты с учётом имён файлов конфигурации и параметров в них указанных. В скриптах интересуют значения APCPID, указание корректных флагов запуска apcupsd, изменение поведения killproc, чтобы он не убивал одним махом все запущенные процессы apcupsd и имена lock-файлов. Это что касается запуска демона. Для проверки статуса необходимо указать соответствующий демону NISPORT в параметрах запуска apcaccess.
После всех необходимых изменений в стартовых скриптах, эти стартовые скрипты надо “зарегистрировать”, а стандартный скрипт apcupsd наоборот – отключить. Для этого имена новых скриптов передаём в качестве параметра chkconfig:
chkconfig --add apcupsd-rm3000
и отключаем стандартный скрипт:
chkconfig --del apcupsd
Теперь в ntsysv доступны новые скрипты и нет стандартного. Ставим на них * и радуемся результатам содеянного:
[root@mail apcupsd]# service apcupsd-rm3000 start
Starting UPS monitoring: [ OK ]

[root@mail apcupsd]# ps ax|grep apc
5750 ? Ssl 0:00 /sbin/apcupsd -f /etc/apcupsd/apcupsd-rm3000.conf -P /var/run/apcupsd-rm3000.pid
5781 ? Ssl 0:00 /sbin/apcupsd -f /etc/apcupsd/apcupsd-smc1500.conf -P /var/run/apcupsd-cs1500a.pid
5810 ? Ssl 0:00 /sbin/apcupsd -f /etc/apcupsd/apcupsd-cs1500.conf -P /var/run/apcupsd-cs1500b.pid
5851 pts/5 S+ 0:00 grep apc

Целиком файлы конфигов я выкладывать не буду ни в этот раз, ни в последующие, дабы предотвратить бездумный copy-paste. Для всех файлов максимум будут diff относительно оригинального файла.

Share