SMTP предупреждението не работи за keepalived

Работя върху проект, който ще създаде набор от високодостъпни балансьори на натоварването. Софтуерът за балансиране на натоварването и висока наличност изглежда работи добре (използвам Crossroads за балансиране на натоварването и Keepalived, за да направя сървърите за балансиране на натоварването много достъпни, и Conntrackd за проверка на изправността на балансиращите натоварване), но имам проблеми с настройването на конфигурацията файл за Keepalived за изпращане на имейли, когато настъпи преход на състоянието (master->backup/backup->master). Следвах инструкциите на страниците с ръководство (man keepalived.conf), които ми казват как да настроя известията за изпращане по имейл, но не успявам да получа имейли в очакваното време. Склонен съм към проверки на правописа и обикновени грешки, но след като разглеждах този проблем почти 10 часа, изглежда не мога да намеря нищо и ми свършват нещата, които да опитам.

Един от сървърите, които използвам (ще го нарека loadbalance1), понякога ще използва smtp_alert за изпращане на имейли, когато настъпи промяна, но ще ме уведоми само когато е преминал от резервен към главен (а не главен към резервен). Когато не работи, регистрационните файлове (/var/log/messages и /var/log/syslog) ме уведомяват, че възниква състояние на SMTP грешка 550. Разбирам, че тези проблеми са нещо, свързано с неправилен имейл адрес, посочен в конфигурационния файл, но те са правилни, доколкото мога да преценя. Единственото нещо, което имам, което предполага, че keepalived или моят конфигурационен файл е грешен, е че sysadmin изпраща имейли на хората със съобщения за това, че „{“ е неподходящ получател на поща. Имам отворен smtp порт на компютъра. Друго странно нещо, което се случва, е, че понякога, когато keepalived се опитва да се свърже с пощенския сървър, той иска да погледне локалната машина, когато тя не е там. Посочвам пощенския сървър като другаде, но той иска да търси локално по някаква причина.

Другият сървър, loadbalance2, никога няма да изпрати smtp_alert за изпращане на имейли, независимо от прехода на състоянието, който прави. Виждам в регистрационните файлове за keepalived (/var/log/messages и /var/log/syslog), че сървърът за архивиране, loadbalance2, прави преход към състояние MASTER, но никога не изпраща имейла. Дава същата грешка като loadbalance1, но просто никога не работи тук. Има същия конфигурационен файл като loadbalance1.

Следва конфигурационният файл, keepalived.conf

    global_defs 
    {
        notification_email 
        {
    [email protected]
        }
       notification_email_from [email protected]
        ##Mail server below##
       smtp_server www.xxx.yyy.zzz
       smtp_connect_timeout 30
       lvs_id NLB_MASTER
    vrrp_sync_group
    {
        group
        {
            loadbalance1
            loadbalance2
        }
        ##The following scripts don't seem to work properly either##
        ##The scripts are not executed at expected times        ##
        notify_master "/path/to/script.sh master"
        notify_backup "/path/to/script.sh backup"
        notify_fault  "/path/to/script.sh fault"
        notify  "/path/to/script.sh"
        smtp_alert
    }
    vrrp_instance loadbalance1
    {
        state MASTER
        interface eth0
        virtual_router_id 20
        priority 100
        #In some examples online smtp_alert is here
        virtual_ipaddress
        {
            www.xxx.yyy.zzz/24 brd www.xxx.yyy.255 dev eth0
        }
        ##Not entirely sure if this is correct##
        notify_master "/path/to/script.sh master"
        notify_backup "/path/to/script.sh backup"
        notify_fault  "/path/to/script.sh fault"
        notify  "/path/to/script.sh"
        smtp_alert
    }
    vrrp_instance loadbalance2
    {
        state MASTER
        interface eth0
        virtual_router_id 30
        priority 100
        #In some examples online smpt_alert is here
        virtual_ipaddress
        {
            www.xxx.yyy.zzz/24 brd www.xxx.yyy.255 dev eth1
        }
        ##Not entirely sure if this is correct##
        notify_master "/path/to/script.sh master"
        notify_backup "/path/to/script.sh backup"
        notify_fault  "/path/to/script.sh fault"
        notify  "/path/to/script.sh"
        smtp_alert
      }

Ако има няколко несъответствия в конфигурационния файл, се извинявам. Всички предложения, помощ или мнения се оценяват. Ако имате нужда от повече информация, ще се радвам да ви помогна.


person Stephen    schedule 24.06.2011    source източник
comment
някакъв модел кога имейлите излизат и кога не?   -  person dawebber    schedule 25.06.2011


Отговори (2)


За тези, които може да са изправени пред същия проблем, успях да отстраня проблема. Не съм сигурен дали това е решението, но може да е допринесло.

-Трябваше да променя датата и часа на машините към текущото време (една от тях беше изключена с няколко години, тъй като беше клонинг). Имейл сървърът може да е блокирал имейлите на бекенд сървъра поради празнина в системното време?

-Дата -s чч:мм:сс

-Дата -s година-месец-ден

- Трябваше да коригирам проблем с едно и също име на хост и на двете машини. Както казах беше клонинг на другия и никога не съм го сменял случайно. Може да съм получавал известия от бекенд сървъра през цялото време, но никога не съм правил разлика между двете, защото получавах имейли от едно и също име на хост

-Направена малка промяна в конфигурационния файл, която трябва да е незначителна

    global_defs
    {
          notification_email {
              [email protected]
          }
    }

Не съм сигурен дали това направи разликата, но о, добре... сега работи

person Stephen    schedule 27.06.2011

Успях да разреша подобен проблем, който виждах в keepalived.log:

SMTP connection ERROR to [0.0.0.0]:25

Къде изглеждаше моят keepalived.conf:

global_defs {
  notification_email {
    ....
  }
  notification_email_from [email protected]
  smtp_server smtp.somehwere.com
  smtp_connect_timeout 30
  ...
}

Актуализирах моята smtp конфигурация, за да използвам IP адрес вместо име на хост за моя smtp сървър:

smtp_server xxx.xxx.xxx.xxx

Резултатът е нов резултат и успешни имейл известия след рестартиране на keepalived:

Remote SMTP server [xxx.xxx.xxx.xxx]:25 connected.
person mike    schedule 13.08.2015