it-swarm-es.tech

/etc/cron.daily/foo: ¿Enviar correo electrónico a un usuario en particular en lugar de a root?

Estoy ejecutando CentOS 5.5.

Tenemos varios cronjobs almacenados en /etc/cron.daily/. Nos gustaría que el correo electrónico de algunos de estos cronjobs vaya a una dirección de correo electrónico en particular, mientras que el resto de los correos electrónicos en /etc/cron.daily/ deberían ir a la dirección de correo electrónico predeterminada (root @ localhost).

Cronjobs en /etc/cron.daily/ se ejecutan desde el archivo/etc/crontab./etc/crontab especifica un campo 'MAILTO'. ¿Puedo anular esto configurando MAILTO en mi cronjob /etc/cron.daily/foo?

¿Cuál es la mejor manera de manejar esto?

13
Stefan Lasiewski

Ajuste [email protected] en /etc/cron.daily/foo No funciona. La salida del script no se envía a [email protected]

La página en http://www.unixgeeks.org/security/newbie/unix/cron-1.html también sugiere una solución simple:

El archivo /etc/cron.daily/foo ahora contiene lo siguiente:

#!/bin/sh
/usr/bin/script 2>&1 | mailx -s "$0" [email protected]

Esto enviará un correo electrónico a '[email protected]' con el asunto que es igual a la ruta completa del script (por ejemplo, /etc/cron.daily/foo).

Esto es lo que dice Unixgeeks.org sobre esto:

Salida de cron

Como dije antes, la salida de cron se envía por correo al propietario del proceso, o la persona especificada en la variable MAILTO, pero ¿qué pasa si no quieres eso? Si desea enviar la salida por correo a otra persona, puede simplemente canalizar la salida al comando mail. p.ej.

cmd | mail -s usuario "Asunto del correo"

A veces, solo quiero recibir los errores de un cronjob, no del stdout, así que uso este truco. La sintaxis puede parecer incorrecta a primera vista, pero tenga la seguridad de que funciona. El siguiente cronjob enviará STDOUT a/dev/null y luego manejará STDERR a través de la canalización.

doit 2>&1 >/dev/null | mailx -s "$0" [email protected]

Lo mismo, pero envíe a syslog:

doit 2>&1 >/dev/null | /usr/bin/logger -t $ME

También vea mi respuesta en ServerFault a Cronjob stderr para archivo y correo electrónico

13
Stefan Lasiewski

Una solución más elegante sería usar /etc/cron.d Directamente. En lugar de tener su script en /etc/cron.daily, Colóquelo en algún lugar como /usr/local/sbin/myscript.sh Y luego cree el archivo /etc/cron.d/myscript Como:

MAILTO=root,[email protected]
# run myscript.sh at 4:11 every day
11 4 * * * root /usr/local/sbin/myscript.sh

Esto también le da mucho más control sobre cuándo ocurre el trabajo; por ejemplo, solo en ciertos días de la semana, etc. Consulte el hombre crontab(5) para obtener más información.

6
codebeard

Suponiendo que tiene acceso SA en esta máquina, puede crear una nueva cuenta de usuario, agregar las tareas a las tareas cron de esta cuenta. El correo para este usuario se puede reenviar usando un archivo .forward en la carpeta de inicio de esta cuenta. Es posible que deba configurar permisos para este usuario si las tareas cron requieren acceso privilegiado.

Si esta o la respuesta de Stefan es la más adecuada, realmente depende de la cantidad de problemas que desee para configurarlo y de si desea que los mensajes de error vayan al correo electrónico raíz oa las personas que normalmente monitorean la salida diaria.

Buena suerte

0
Michael Shaw