Send email from command line or at startup in SCALE

TrueNAS General
21

Honestly i have some doubt about that, i would focus more on why the sendemail fail, and confirm that happen just due to connection lost. You should be able to intercept that, nor if Is an handled exception (enable debugging in the args) and if put some log logic into your script to intercept the output code/JSON detail.
I would expect that if connection Is slow, overall shutdown time will be just higher. But if no connection Is available or a request goes in timeout due to high latency the sendemail can’t work

I’m courios to test if in EEL i still have the same behaviour, for me was kinda odd that the direct command not work, maybe Is just my fault :smile:

22

I’m not sure what sendemail returns (or doesn’t return) to whatever calls it while the sending of email is processing. If it returns control right away with a 0 exit code, that may explain why the shutdown is proceeding as quickly as it is, before completion of the send. On the other hand, running sendemail in command line, control is not returned until it finishes. So it could be how init/shutdown COMMANDS are called.

I get the same, failed, behavior for shutdown command with midclt call mail.send function. I didn’t test to see if it would work as a script, but suspect it will. Only issue with that is I can’t pass on $(date) expansion.

In any event, since there’s a working solution in progress, I wouldn’t worry too much about it any more. I will test later this afternoon with the cell data connection to see if that too works as well as the with the VM.

23

I made some progress.

Script is the way to go, but I was still running into unsent shutdown messages. Observing the real machine with a 30s pause at the end of the script, it was definitely respecting and running the script commands.

BUT!@#, recall the email server is only accessible over the vpn (wireguard) tunnel. Aha moment! it would appear wireguard is getting torn down before the email is sent but before the network services are shutdown. Added a wg-quick up wg0 as the first command of the script and SUCCESS!

This was working in the vm because it was using the vm’s network to send the email not wireguard’s. Once blocked in the firewall (so smtp only possible via wg), it was failing too.

The cell connection is pretty bad, 100-300ms ping times between WG endpoints.

The right solution is keep wireguard alive longer, how? That would involve messing with systemd service files and priorities. Goal is not to modify the OS any more than absolutely necessary.

In the end, for me, most of the issues encountered trying send a shutdown message comes down to timing. Wireguard adds another layer of complexity.

24

This works in EE and Fangtooth.

echo "The server booted up at $(date)" | midclt call --job mail.send "{\"subject\": \"TrueNAS Bootup Notice\", \"to\": [\"someone@example.com\"], \"text\": \"$(cat)\"}"

Putting the call to midclt in a simple script would be sane.

The following script will send HTML emails with embedded Subject and To fields that were previously sent through sendmail:

#!/bin/bash

LANG="en_US.UTF-8"

html_data="$(cat)"

function parse_to() {
  echo "${html_data}" | grep "^To: " | awk '{print $2}'
}
function parse_subject() {
  echo "${html_data}" | grep "^Subject: " | sed 's/^Subject: //'
}
function parse_html() {
  local inbody=0
  while IFS= read -r line; do
      [ "${line}" == "<body>" ] && inbody=1 && continue
      [ "${line}" == "</body>" ] && inbody=0 && continue
      [ ${inbody} -eq 1 ] && echo "${line}"
  done <<< "${html_data}"
}

midclt call --job mail.send "{
  \"subject\": \"$(parse_subject)\",
  \"html\": $(parse_html | jq -Rs .),
  \"to\": [\"$(parse_to)\"]
}" 2>/dev/null >/dev/null