Here is an example of the script that has been used in the APCUPSD addon for emailing when the UPS goes on to battery support
#!/bin/sh
#
# This shell script if placed in /etc/apcupsd
# will be called by /etc/apcupsd/apccontrol when the UPS
# goes on batteries.
# We send an email message to root to notify him.
#
FROM="enter from email address"
TO="enter to email address"
HOSTNAME=`hostname`
MSG="$HOSTNAME Power Failure on UPS $1"
#
(
echo From: $FROM
echo To: $TO
echo Subject: $MSG
echo " "
echo "$MSG"
echo " "
echo -ne $(echo "\r\n"; while read line; do echo "$line\r\n"; done < <(echo "$(/sbin/apcaccess status)"))
) | sudo -u nobody /usr/sbin/sendmail -t -f $FROM
exit 0
This might help you to use it in your script.
You could also look at how the DA package has been used for the Suricata alert mailing that was added in CU198 which has been in Testing and will be released shortly.
This is not a correctly formatted email here. You will need some MIME headers, too. DMA will try to deliver it, but I don’t think you will have a good chance to get it through all sorts of filters.
I will have another look at it when I can get some time then. However it is working currently. Every time the status of my UPS changes I get the appropriate email. Maybe I have just been lucky.
Thanks for the replies! I modified the sample script for my purposes and unsurprisingly the mail was rejected by the SMTP server at my email provider, because there’s no authentication:
Oct 28 18:52:04 ipfire dma[100012]: new mail from user=nobody uid=99 envelope_from=<VALID_EMAIL_REDACTED>
Oct 28 18:52:04 ipfire dma[100012]: mail to=<VALID_EMAIL_REDACTED> queued as 100012.144fd5d0
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: <VALID_EMAIL_REDACTED> trying delivery
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: using smarthost (mail.gandi.net:587)
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: trying remote delivery to mail.gandi.net [2001:4b98:e00::9] pref 0
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: connect to mail.gandi.net [2001:4b98:e00::9] failed: Cannot assign requested address
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: trying remote delivery to mail.gandi.net [217.70.178.9] pref 0
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: Server greeting successfully completed
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: Server supports STARTTLS
Oct 28 18:52:04 ipfire dma[100012.144fd5d0]: Server supports LOGIN authentication
Oct 28 18:52:05 ipfire dma[100012.144fd5d0]: SSL initialization successful
Oct 28 18:52:05 ipfire dma[100012.144fd5d0]: Server greeting successfully completed
Oct 28 18:52:05 ipfire dma[100012.144fd5d0]: Server does not support STARTTLS
Oct 28 18:52:05 ipfire dma[100012.144fd5d0]: Server supports LOGIN authentication
Oct 28 18:52:05 ipfire dma[100012.144fd5d0]: using SMTP authentication for user VALID_EMAIL_REDACTED
Oct 28 18:52:07 ipfire dma[100012.144fd5d0]: remote delivery failed: Authentication failed: 535 5.7.8 Error: authentication failed: (reason unavailable)
Oct 28 18:52:07 ipfire dma[100012.144fd5d0]: remote delivery failed: SMTP login failed: Success
Oct 28 18:52:07 ipfire dma[100012.144fd5d0]: delivery failed, bouncing as 100470
I’m not aware of any means to provide auth credentials to sendmail when used in this way.
To use the script you have to have the Mail Service WUI page enabled and with the appropriate authentication defined for the Mail Server that you are using.
You need to get a successful email delivery from that Mail Service page when pressing the Send test mail button before you can have any scripts using it.
Aha, there’s a complication. The maximum password length is 20 characters for some reason. I use machine generated passwords of 25 characters.
I can configure my credentials on the Mail Service Configuration page, and successfully send a test email from there, but as soon as I close the dialog, the password is truncated and subsequent attempts to authenticate against the configured SMTP server will fail.
Can you relax the limit on password length, please?
Edit: oh, it’s worse than truncation based on length. The password is being truncated from the pipe symbol onwards.
I generate my passwords with this invocation of pwgen:
pwgen -sy 25 1
From the pwgen man page:
-s, --secure
Generate completely random, hard-to-memorize
passwords. These should only be used for machine
passwords, since otherwise it's almost guaranteed
that users will simply write the password on a
piece of paper taped to the monitor...
-y, --symbols
Include at least one special character in the
password.
There is no limit to the password length. I saved a 64 character password and it saved the whole 64 characters in the dma auth.conf file.
dma defines the requirement for the contents of the auth.conf file to be
user|smarthost:password
You will see that they use the pipe symbol to separate the user from the smarthost and the : to separate the smarthost from the password.
If you have a semicolon or a pipe symbol in your password then when you come back to the mail service wui page it will take the line from auth.conf and split it at the pipe symbol to extract the username and then it will split the remainder of the line at the colon to extract the smarthost and then the part that is left is the password.
However with a pipe symbol in the password the auth.conf line does not get split into 3 sections but into 4. The same is if there is a colon in the password.
The user and the smarthost always get extracted correctly but the password will be split into multiple parts depending on how many pipe or colon symbols are present in it but only the first part of the split password will be kept and put onto the screen and if the save button is pressed you will then see the same shortened password saved back into the auth.conf file.
Please raise a bug report on this issue. The following link gives details on how to do that.
I’ve regenerated a new SMTP password that doesn’t contain a pipe symbol (|) and I’ve verified that it’s retrieved in its entirety from /var/ipfire/dma/auth.confin order to be presented on the /cgi-bin/mail.cgi (Mail Service Configuration) page.
I’ve also verified that I can then send a test email from the re-opened Mail Service Configuration page, and from my shell script adapted from the first example above.