apcupsd mail notification

Сначала нужно в целом настроить пересылку служебной почты с твоего сервера на аккаунт gmail. Для этого

1. Включи двухэтапную авторизацию и получи пароль приложения, который ты будешь использовать в майлере на своём сервере для отправки письма в свою почту gmail. https://support.google.com/accounts/answer/185833

2. Настрой майлер, я использую nullmailer

В /etc/nullmailer/adminaddr пишешь свой gmail адрес, blabla@gmail.com

В /etc/nullmailer/defaultdomain пишешь gmail.com

В /etc/nullmailer/me пишешь полное доменное имя своего хоста my_hostname.tld (это пример)

В /etc/nullmailer/remotes самое главное, как это всё будет отсылаться

smtp.gmail.com smtp user=blabla@gmail.com pass=(пароль приложения, НЕ пароль к ящику) port=587 starttls

Последний штрих: в /etc/mail/aliases раскоментируй и исправь строку root: blabla@gmail.com

Запускай демон nullmailer принятым в твоей системе способом и делай ему автоматический запуск при загрузке.

3. Тестируем

Отправляем письмо root

mail -s "Test mail" root (нажимаем Энтер)
Cc: (Нажимаем Энтер)
This is a test (пишем и нажимаем Энтер)
(нажимаем Ctrl+D)

Убеждаемся что письмо руту пришло в ящик gmail. Аналогично тестируем отправку в blabla@gmail.com, так же как и выше, только вместо root пишем имя ящика.

Теперь у нас все адресованные руту служебные письма и отчёты будут перенаправляться на gmail.

4. Настроить отправку почты как реакцию на события и содержание сообщений ты сможешь в /etc/apcupsd/scripts-server/apccontrol, с этим я думаю ты разберёшься сам, это не rocket science. Самое сложное, настройку системного майлера на gmail, ты сделал. А всё остальное в системе так или иначе использует системный майлер.

красивая инструкция, схоронил себе, спасибо

с этим я думаю ты разберёшься сам, это не rocket science

Ну ТС и про это спрашивает, не нужно ли что-то править в apccontrol в неизвестной версии CentOS, чтобы тот выполнял onbattery/offbattery (скрипты, видимо).

/etc/apcupsd/scripts-server/apccontrol

Это же, ЕМНИП, в Дебиане, а в CentOS /etc/apcupsd/apccontrol. И его, ЕМНИП, не нужно править, это не конфиг-файл и будет переписан при обновлении пакета.

Возможно тебе в целом концепция не ясна, я на всякий случай более подробно объясню. Традиционно в UNIX приложения отправляющие письма не тащат с собой собственный почтовый клиент, они пользуются системной службой, исторически это был sendmail, великий и ужасный.

В полностью настроенном виде он представляет собой полноценный почтовый сервер и средство для отправки сообщений в одном флаконе, в минимальной конфигурации он использовался для пересылки почты между пользователями самой системы (напомню что UNIXы и Linux в том числе изначально многопользовательские системы), а так же для перенаправления почты отправленной rootу (это обычно всякие системные отчёты и уведомления) юзерскому аккаунту администратора, под которым он повседневную жизнь ведёт.

Со временем появились всякие разные другие почтовые системы, и на компьютерах которые собственно почтовыми серверами не являются появились «лёгкие» локальные майлеры, которые занимаются пересылкой локальной почты между рутом и обычным юзером, а так же на какой либо «внешний» ящик. Но по традиции они продолжают поддерживать симлинки и синтаксис команд mail и sendmail.

Так что если какой нибудь демон, например тот же apcupcd, желает послать почту — он не будет сам изображать почтовый клиент и коннектиться куда то по smtp, он воспользуется локальным майлером через вызов команды mail или sendmail и передаст только текст письма, заголовок и адрес (часто это просто root, в предыдущем посте мы настроили пересылку его почты «куда надо»), надеясь на то что майлер настроен и сам разберётся что дальше делать.

Обычно это всё валяется ненастроенным и локальную почту посланную руту никто не читает, так как никто уже не помнит что такое вообще когда то было и есть. Настраивать всё это умеют аксакалы вроде меня и «настоящие» системные администраторы. Так что не пугайся если после настройки на тебя повалится годами нечитанная ругань от cron например про невозможность исполнить какой нибудь кривой скрипт в расписании и прочая «чрезвычайно важная и полезная» информация. Возможно придётся чему либо затыкать прорвавший «фонтан красноречия» и фиксить неочевидные до этого косяки в настройках.

Я думаю apccontrol он найдёт, настройка выполняется его редактированием, это и скрипт, и конфиг одновременно, там всё очевидно и глазами понятно, а если непонятно есть man и документация, где всё разжёвано. Именно его и нужно править, apcupsd немного странный, да. Переписываться при обновлениях он не должен.

Основная сложность не скрипт настроить, основная сложность настроить системный майлер так чтобы он письма на gmail слал. Знаю тех кто это так и не осилил, и до сих пор в лужу пердят что это невозможно потому что злой гуголь всё им поломал и запретил. Собсно я считаю что вот этот момент как раз и нуждался в подробном разъяснении. А сам apcupsd скрипт apccontrol — он простой как угол дома, очевидный, читаемый и понимаемый даже без инструкций.

Ок, вот ссылка на официальную документацию. В которой собсно написано то же что и я сказал: «прочитайте и настройте под себя скрипт». http://www.apcupsd.org/manual/#apcupsd-notification-and-events

настроить системный майлер так чтобы он письма на gmail слал.

ИМХО, ТС как-то странно сформулировал требование к отправке почты:

уведомления на gmail через свой почтовый сервак.

Какой «свой» почтовый сервак мне не понятно? Может у ТС уже есть отдельный почтовый сервер, через который и нужно в его конторе всю почту слать...

настройка выполняется его редактированием

Но при этом, в самом apccontrol есть такие строки:

# WARNING: the apccontrol file will be overwritten every time you update your
# apcupsd, doing `make install'. Your own customized scripts will _not_ be
# overwritten.

Понятно, что ″make install″ в дистрибутиве делать не нужно, но, по мне, логично, что rpm тоже будет переписывать apccontrol.

У меня нет центоОСи, но если смотреть apcupsd-3.14.14-18.el8.src.rpm, то в spec-файле такое:

%config(noreplace) /etc/apcupsd/apcupsd.conf
%attr(0755,root,root) /etc/apcupsd/apccontrol
%config(noreplace) /etc/apcupsd/changeme
%config(noreplace) /etc/apcupsd/commfailure
%config(noreplace) /etc/apcupsd/commok
%config(noreplace) /etc/apcupsd/offbattery

А, ну тут понятно, они тут переделали, apccontrol действительно будет переписываться, но он из себя вызывает вспомогательные скрипты-обработчики, это тоже в документации написано. И вот эти вспомогательные скрипты commfailure, commok, offbattery и нужно редактировать видимо.

In addition, another feature is that you can write your own scripts that will be automatically called by apccontrol before any of its own code is executed. Details of the events and how to program them are contained in the Advanced topics section entitled Customizing Event Handling.

Впрочем я повторюсь, там обычная развесистая баш-лапша, просто читая скрипт становится понятно что там из него вызывается и где нужно править. Там даже примеры приведены и очевидные переменные объявляются. При минимальном знакомстве с башем и наличии мозгов вполне очевидно там всё. Я просто сейчас этим не пользуюсь, но в своё время как то легко разобрался просто по логике и читая скрипты, без документации.

Какой «свой» почтовый сервак мне не понятно? Может у ТС уже есть отдельный почтовый сервер, через который и нужно в его конторе всю почту слать...

Ну даже если и так, всё равно нужно локальный майлер настроить, только почту пересылать не на smtp.gmail.com, а на «свой» почтовый сервак. Раз он у него «свой», он по аналогии уже сам разберётся как ему через smtp почту слать, он же должен тогда сам знать как к нему цепляться, по какому адресу, порту, нужна ли авторизация и starttls. А вот уже «свой» почтовый сервак тогда должен уметь гуглю письма дальше пересылать.

Вообще ТСу стоило бы версию центоси рассекретить, apcupsd действительно везде по разному фасуется и в настройке могут быть тонкости. Например переменные могут настраиваться в /etc/conf.d/apcupsd , и почту для отправки сообщений нужно там прописывать. В моём дистре всё было максимально «близко к природе» и я настраивал напрямую исправляя скрипт, как собсно и сказано в документации.

Вот собсно в /etc/apcupsd/changeme обработка уведомления о замене батареи, и там всё очевидно как мне кажется

#!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when apcupsd
# detects that the battery should be replaced.
# We send an email message to root to notify him.
#
SYSADMIN=root (тут очевидно и можно оставить как есть, если пересылка настроена)
APCUPSD_MAIL="mail" (хотим пользоваться командой mail для отправки)

HOSTNAME=`hostname` (тут имя хоста,чтобы было понятно какая машина жалуется)
MSG="$HOSTNAME UPS battery needs changing NOW."
#
(
   echo "Subject: $MSG"
   echo " "
   echo "$MSG"
   echo " "
   /sbin/apcaccess status
) | $APCUPSD_MAIL -s "$MSG" $SYSADMIN
exit 0

А дальше майлер должен это всё отослать. Пересылка почты адресованной root в моём первом посте настраивалась, либо напрямую в smtp.gmail.com согласно моей инструкции, либо через промежуточный корпоративный сервак, тут он уже сам должен разобраться по аналогии как майлер на него настроить, по идее он должен знать как к нему подключаться. Или знать как узнать.

Отвечу всем и сразу.. видимо, приходится объяснять подробнее: Centos 7. всё лежит в /etc/apcupsd почтовый сервер свой - в прямом смысле, находится в этой же сети, буквально на соседнем ip, и для apcupsd почтовый ящик я сделал. в винде например в onbattery.vbs - там всё прописывается, заработало сразу, и виндовский сервак мне уведомления шлёт от имени apcupsd@mydomain.com. в Centos мейлер - ссылается на /bin/mailx. пересылка ВСЕГО мейла от рута мне на гмейл - и даром не нужна, просто у меня в телефоне стоит оповещение от гмейловского ящика ( собссно ящик заведен специально для уведомлений от железяк), он квакает сразу, если что-то пришло, и я хочу знать сразу, что что-то случилось.

Видимо когда я распинался расписывая что такое майлер это всё мимо ушей прошло. Это нормально, я как КО обладаю суперспособностью не утомляться несколько раз разъясняя очевидные вещи.

всё лежит в /etc/apcupsd почтовый сервер свой - в прямом смысле, находится в этой же сети, буквально на соседнем ip, и для apcupsd почтовый ящик я сделал. в винде например в onbattery.vbs - там всё прописывается, заработало сразу, и виндовский сервак мне уведомления шлёт от имени apcupsd@mydomain.com.

Глубоко наплевать как и где в винде всё настраивается, ты в другой ОС, apcupsd под винду и под Linux это совершенно разные программы, в Linux apcupsd как и все системные демоны использует системный же майлер.

Centos мейлер - ссылается на /bin/mailx

Нужно почитать как в Центос настраивается майлер и настроить его!

пересылка ВСЕГО мейла от рута мне на гмейл - и даром не нужна, просто у меня в телефоне стоит оповещение от гмейловского ящика ( собссно ящик заведен специально для уведомлений от железяк), он квакает сразу, если что-то пришло, и я хочу знать сразу, что что-то случилось.

Действительно, зачем тебе знать о том что у тебя судя по smart вот вот отвалится диск, или что место на нём на исходе, лучше всё это узнать в режиме сюрприза, внезапно, а не получить уведомление заранее, на почту. Но если даже и так, и ты просто любишь сюрпризы, достаточно в /etc/mail/aliases не настраивать пересылку почты root куда либо ещё. А в apsupsd скриптах, которые выше обсуждались, в переменной SYSADMIN= написать свой gmail адрес вместо root.

Для этого нужен настроенный локальный майлер, умеющий отсылать письма через твой почтовый сервак на соседнем IP (надеюсь этот сервак умеет форвардить на gmail и gmail не отправляет всё что с него пришло в спам). Потому что apsupcd в Линукс не обладает функциональностью почтового клиента, и как видно (очевидно) из скриптов полагается в этих вопросах на локальный майлер, ожидая что он настроен.

Так что повторю ещё раз, настрой локальный майлер, инструкция тут. Инструкцию читай «творчески», вместо приведённых там уже нерабочих настроек на smtp.gmail.com настрой отправку на свой почтовый сервак «на соседнем ip».

Спасибо за участие.. ссылка «Нужно почитать как в Центос настраивается майлер и настроить его!» оказалась полезной. Эта конкретная задача решилась ГОРАЗДО ПРОЩЕ:

echo «$UPSNAME on battery» | mailx -r «apcupsd@mydom.com» -s «$HOSTNAME» -S smtp=«192.168.0.6:25» -S smtp-auth=login -S smtp-auth-user=«apcupsd@mydom.com» -S smtp-auth-password=«blablabla» -S ssl-verify=ignore mycompanyhard@gmail.com

Действительно, зачем тебе знать о том что у тебя судя по smart вот вот отвалится диск, или что место на нём на исходе, лучше всё это узнать в режиме сюрприза, внезапно, а не получить уведомление заранее, на почту.

Место на диске этого сервака не закончится, его некому забивать, там кроме apcupsd и SQUID-а никого нет :-) А о том, что отвалится хард, мне напишет IPMI этого сервака, на котором под VMWare ESXi крутится, в т.ч. и эта самая centos :-) и я почти допилил скрипты, которые будут по издыханию аккумуляторов ложить остальные виртуальные машины и саму VMWare напоследок. Собссно, если бы VMWare ESXi умела с UPS-ами работать, то и apcupsd не понадобился..

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