Encrypting Nagios report mails with GnuPG fails with empty mails, why? - smtp

Question

I am trying to crytp using gpg2 the mails sent by Nagios3. For that, I have create this custom command on /etc/nagios3/commands.cfg :
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
Some points:
The e-mail is sent but it is "empty":
Sep 19 14:35:25 tutu nagios3: Finished daemonizing... (New PID=4313)
Sep 19 14:36:15 tutu nagios3: SERVICE ALERT:
tete_vm;HTTP;OK;HARD;4;HTTP OK: HTTP/1.1 200 OK - 347 bytes in 0.441
second response time Sep 19 14:36:15 tutu nagios3: SERVICE
NOTIFICATION: tata;tete_vm;HTTP;OK;notify-service-by-email;HTTP OK:
HTTP/1.1 200 OK - 347 bytes in 0.441 second response time
The command:
/usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$</code>
works very well on command line
I have tested this command:
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com >> /tmp/toto.txt
The file /tmp/toto.txt is created but "empty".
So, it seems to be a problem using /usr/bin/gpg2 on this file, but I cannot find why!

Answer 1

The most common mistake when encrypting from within services using GnuPG is that the recipient's key was imported by another (system) user than the one the service is running under, for example imported by root, but the service runs as nagios.
GnuPG maintains per-user "GnuPG home directories" (usually ~/.gnupg) with per-user keyrings in them. If you imported as root, other service accounts don't know anything about the keys in there.
The first step for debugging the issue would be to redirect gpg's stderr to a file, so you can read the error message by adding 2>>/tmp/gpg-error.log to the GnuPG call:
/usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /usr/bin/gpg2 --armor --encrypt --recipient toto#titi.com 2>>/tmp/gpg-error.log | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
If the issue is something like "key not found" or similar, you've got two possibilities to resolve the issue:
Import to the service's user account. Switch to the service's user, and import the key again.
Hard-code the GnuPG home directory to somewhere else using the --homedir [directory] option, for example in a place you also store your Nagios plugins.
Be aware of using appropriate, restrictive permissions. GnuPG is very picky if other users than the owner are allowed to read the files!