@Viacheslav can you see what auth modes supported by keepalive
also I think we don't need to configure both

set high-availablilty vrrp global notification_email [email protected]
set high-availablilty vrrp global notification_email_from [email protected]

or that is destination and from ?

Yes @syncer . One option is for source and other for destination.

Also I think if we add mail notification options available in keeplived, we should add all capabilities related to smtp.
From the manpage:

# Set of email To: notify
           notification_email {
               [email protected]
               ...
           }

           # email from address that will be in the header
           # (default: keepalived@<local host name>)
           notification_email_from [email protected]

           # Remote SMTP server used to send notification email.
           # IP address or domain name with optional port number.
           # (default port number: 25)
           smtp_server 127.0.0.1 [<PORT>]

           # Name to use in HELO messages.
           # (default: local host name)
           smtp_helo_name <STRING>

           # SMTP server connection timeout in seconds.
           smtp_connect_timeout 30

           # Sets default state for all smtp_alerts
           smtp_alert <BOOL>

           # Sets default state for vrrp smtp_alerts
           smtp_alert_vrrp <BOOL>

           # Sets default state for checker smtp_alerts
           smtp_alert_checker <BOOL>

           # Logs every failed real server check in syslog
           # (nevertheless, SMTP alert is only sent when all retry checks failed
           # and real server transitions to DOWN state)
           checker_log_all_failures <BOOL>

           # Don't send smtp alerts for fault conditions
           no_email_faults

In T5022#143112, @syncer wrote:

@Viacheslav can you see what auth modes supported by keepalive
also I think we don't need to configure both

set high-availablilty vrrp global notification_email [email protected]
set high-availablilty vrrp global notification_email_from [email protected]

or that is destination and from ?

@syncer It was copy-paste from the Forum. It will be changed to the correct syntax for CLI. I'll take a look at the original repo for auth. https://github.com/acassen/keepalived

PR https://github.com/vyos/vyos-1x/pull/1866

set high-availability vrrp global-parameters notification mail '[email protected]'
set high-availability vrrp global-parameters notification send-faults
set high-availability vrrp global-parameters notification smtp-server address '127.0.0.1'
set high-availability vrrp global-parameters notification smtp-server connection-timeout '30'
set high-availability vrrp global-parameters notification smtp-server port '25'
set high-availability vrrp global-parameters notification source-mail '[email protected]'
set high-availability vrrp global-parameters router-id 'MYROUTER'

Hi @Solideco,

after an internal discussion we came to the conslusion that keepalived SMTP implementation is incomplete (e.g. it lacks authentication). In order to still support your request we think we should enable support of 3rd party configurations placed in e.g. /etc/keepalived/conf.d.

Using this you can simply add your required configuration and it will be easier for your extensions.

What you think?

HI,

I agree that the Keepalivd SMTP implementation is lacking authentication.

Context: At our ISP, we have a private SMTP relay server set up for sending notification emails. Since the SMTP server is only for internal use and is not accessible from the Internet we don't bother with authentication.

I'm not totally clear regarding your suggestion of using /etc/keepalived/conf.d/.

Are you suggesting:

A) that the VyOS configuration will contain the relevant vrrp notification lines but render/store them in /etc/keepalived.conf.d?

or

B) that the VyOS keepalived configuration will be updated to include /etc/keepalived/conf.d/ and that keepalived SMTP configuration can be manually placed in /etc/keepalived/conf.d? Does this also mean that VyOS configuration will not know anything about VRRP/Keepalive SMTP notification?

Presuming you mean B), will fiels in /etc/keepalived/conf.d/ be retained after reboots and/or upgrades?

Thanks

Hi @Solideco,

it will be option b) it will be persistent accross reboots but not accross upgrades as only files in /config will be migrated to the new image version.
We could also alter the path to /config/user-data/ or make /etc/keepalived/conf.d/ a symlink to /config/user-data/ so that those files will be migrated during an upgrade.

What you think?

This sort of config should absolutely persist across both reboots and upgrades!.

I think synlinl'ing /etc/keepalived/conf.d/ to /config/user-data/etc/keepalived/conf.d/ would be the best option. Namely because a) there may be multiple .conf files in /config/user-data and b) this sort of thing might come up again for other services and having a etc/ dir in /config/user-data is probably a clean way to handle it.