how to change daily cron emails to go to user account instead of root
Ernie Luzar
How do I change the daily cron emails to go to user account instead of
root? I don't want any cron email going to root any more.
man 5 crontab says the cron environment variable MAILTO = "account user
name" is way to change the cron email from the default of "root" to the
"account user name" you want.
The part that is not clear is where do I place this MAILTO environment
variable? Do I edit /etc/crontab and pace it next to the PATH variable
or maybe in /etc/periodic.conf or /etc/csh.cshrc or /boot/loader.conf?
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
Matthew Seaman
> How do I change the daily cron emails to go to user account instead of
> root? I don't want any cron email going to root any more.
>
> man 5 crontab says the cron environment variable MAILTO = "account user
> name" is way to change the cron email from the default of "root" to the
> "account user name" you want.
>
> The part that is not clear is where do I place this MAILTO environment
> variable? Do I edit /etc/crontab and pace it next to the PATH variable
> or maybe in /etc/periodic.conf or /etc/csh.cshrc or /boot/loader.conf?
daily_output="em...@addr.ess"
to /etc/periodic.conf
Or you can give it a file name and it will write the output there --
/var/log/daily.log is recommended as it's already set up to be rotated
by newsyslog(8)
Matthew
Alexander Moisseev
> The part that is not clear is where do I place this MAILTO environment variable?
EXAMPLE CRON FILE
# use /bin/sh to run commands, overriding the default set by cron
SHELL=/bin/sh
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
Matthew Seaman
> On 27.08.2015 15:41, Ernie Luzar wrote:
>> The part that is not clear is where do I place this MAILTO environment
>> variable?
>
> Have you seen the EXAMPLE CRON FILE section of the man 5 crontab?
>
> EXAMPLE CRON FILE
> # use /bin/sh to run commands, overriding the default set by cron
> SHELL=/bin/sh
> # mail any output to `paul', no matter whose crontab this is
> MAILTO=paul
> #
> # run five minutes after midnight, every day
> 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
from any commands it runs. However, it doesn't answer the OP's specific
question about periodic scripts -- those handle e-mailing their results
out themselves, which is controlled by setting the
{daily,weekly,monthly}_output variable in periodic.conf
Cheers,
Matthew
Arthur Chance
> On 27/08/2015 13:41, Ernie Luzar wrote:
>> Hello list;
>> How do I change the daily cron emails to go to user account instead of
>> root? I don't want any cron email going to root any more.
>>
>> man 5 crontab says the cron environment variable MAILTO = "account user
>> name" is way to change the cron email from the default of "root" to the
>> "account user name" you want.
>>
>> or maybe in /etc/periodic.conf or /etc/csh.cshrc or /boot/loader.conf?
>
>
> to go to another user.
Ack, misread because I was in the middle of dealing with periodic.conf.
Ignore the following. The setting goes at the top of the crontab, on a
line by itself.
> If you just want periodic output to go to a different place, you need to
> change the periodic.conf variables {daily,weekly,monthly}_output and
> {daily,weekly,monthly}_security_output. Probably the best way of doing
> that is to add the following to /etc/periodic.conf
>
> # set this next line to whatever mail address you want
> daily_output="us...@dom.ain"
> weekly_output="$daily_output"
> monthly_output="$daily_output"
> daily_security_output="$daily_output"
> weekly_security_output="$daily_output"
> monthly_security_output="$daily_output"
>
> If you do it that way you only have to change one mail address in the
> future if you want to change the target address.
>
--
Those who do not learn from computing history are doomed to
GOTO 1
Руслан Бурханов
-m mailto
Overrides the default recipient for cron mail. Each crontab(5)
without MAILTO explicitly set will send mail to the mailto
mail‐
box. Sending mail will be disabled by default if mailto set
to a
null string, usually specified in a shell as '' or "".
So you just can add this option on cron flags from rc.conf, like:
cron_flags="-m 'ro...@mymail.com'"
and restart cron daemon.
Arthur Chance
> Hello list;
>
> How do I change the daily cron emails to go to user account instead of
> root? I don't want any cron email going to root any more.
>
> man 5 crontab says the cron environment variable MAILTO = "account user
> name" is way to change the cron email from the default of "root" to the
> "account user name" you want.
>
> The part that is not clear is where do I place this MAILTO environment
> variable? Do I edit /etc/crontab and pace it next to the PATH variable
> or maybe in /etc/periodic.conf or /etc/csh.cshrc or /boot/loader.conf?
Only change MAILTO in the crontab if you wish *all* root's cron output
to go to another user.
Chad J. Milios
see the first few lines of /etc/mail/aliases (or if you don’t use the sendmail in base, maybe /usr/local/etc/postfix/aliases or the equivalent for your mail system):
# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.
# root: m...@my.domain
you uncomment that "root:" line there and obviously replace "m...@my.domain" with something along the lines of "y...@your.domain” to mail off-system or just “you" to redirect to a different on-system user. (root account shouldn’t be running any mail reader software that’s any more complex than `cat /var/mail/root` and even that I wouldn’t get into the habit of doing)
THEN after you change that file you MUST run the `newaliases` command (or `postalias /usr/local/etc/postfix/aliases` in the case of postfix) because a database file is actually what handles lookups after it is [re-]generated from that text file.
see also:
man 5 aliases
man 1 newaliases
> On Aug 27, 2015, at 8:41 AM, Ernie Luzar <luza...@gmail.com> wrote:
>
> Hello list;
>
> How do I change the daily cron emails to go to user account instead of root? I don't want any cron email going to root any more.
>
> man 5 crontab says the cron environment variable MAILTO = "account user name" is way to change the cron email from the default of "root" to the "account user name" you want.
>
> The part that is not clear is where do I place this MAILTO environment variable? Do I edit /etc/crontab and pace it next to the PATH variable or maybe in /etc/periodic.conf or /etc/csh.cshrc or /boot/loader.conf?
>
Shane Ambler
> On 27.08.2015 15:41, Ernie Luzar wrote:
>> variable?
>
>
> EXAMPLE CRON FILE
> # use /bin/sh to run commands, overriding the default set by cron
> SHELL=/bin/sh
> # mail any output to `paul', no matter whose crontab this is
> MAILTO=paul
> #
> # run five minutes after midnight, every day
> 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
echo "\paul" >> /root/.forward
see man forward
--
FreeBSD - the place to B...Software Developing
Shane Ambler
Bernt Hansson
> This thread has many good answers to more finely control things like periodic’s output or cron’s output or one cron entry’s output but I have not seen the simplest and most general answer.
>
> see the first few lines of /etc/mail/aliases (or if you don’t use the sendmail in base, maybe /usr/local/etc/postfix/aliases or the equivalent for your mail system):
>
> # Pretty much everything else in this file points to "root", so
> # you would do well in either reading root's mailbox or forwarding
> # root's email from here.
>
> # root: m...@my.domain
>
> you uncomment that "root:" line there and obviously replace "m...@my.domain" with something along the lines of "y...@your.domain” to mail off-system or just “you" to redirect to a different on-system user. (root account shouldn’t be running any mail reader software that’s any more complex than `cat /var/mail/root` and even that I wouldn’t get into the habit of doing)
>
> THEN after you change that file you MUST run the `newaliases` command (or `postalias /usr/local/etc/postfix/aliases` in the case of postfix) because a database file is actually what handles lookups after it is [re-]generated from that text file.
>
Just run make install && make restart, and off you go.
> see also:
>
> man 5 aliases
> man 1 newaliases
Ernie Luzar
> man cron
>
> -m mailto
> Overrides the default recipient for cron mail. Each
> crontab(5)
> without MAILTO explicitly set will send mail to the
> mailto mail‐
> box. Sending mail will be disabled by default if mailto
> set to a
> null string, usually specified in a shell as '' or "".
>
> So you just can add this option on cron flags from rc.conf, like:
>
>
> and restart cron daemon.
>
snip
This method seemed the simplest so I gave it a try.
The host has a user account called bob. I want all cron email to go to
bob and not root.
I use postfix and sendmail is disabled.
I put cron_flags="-m bob" in /etc/rc.conf and rebooted the host.
Next morning the daily cron email still went to root.
1. Is there a way to scan rc.conf to verify all the included options are
valid and accepted?
2. Since root and bob are on the same host is @mydomain really required?
3. Any ideas why it did not work and no errors were generated?
Arthur Chance
The periodic script does its own output using this:
output_pipe()
{
# Where's our output going ?
eval output=\$${1##*/}_output
case "$output" in
/*) pipe="cat >>$output";;
"") pipe=cat;;
*) pipe="mail -E -s '$host ${2}${2:+ }${1##*/} run output' $output";;
esac
eval $pipe
}
You need to override the various *_output variables periodic uses in
/etc/periodic.conf. See my earlier mail on the subject.
--
Those who do not learn from computing history are doomed to
GOTO 1
Руслан Бурханов
Open you rc.conf, copy string and modify flags for cron daemon:
cron_flags="-j 60 -m 'YOU@MAIL'"
Then, restart cron daemon (it is not necessary reboot system):
/etc/rc.d/cron restart
Then take a look on cron process:
ps auxww | grep cron
If you doing all okey, it will be something like:
root 561 0.0 0.1 7984 1528 ?? Is 3:16PM 0:00.01
/usr/sbin/cron -j 60 -m YOU@MAIL -s
Ernie Luzar
> Ernie, look:
>
> Open you rc.conf, copy string and modify flags for cron daemon:
>
> cron_flags="-j 60 -m 'YOU@MAIL'"
>
> Then, restart cron daemon (it is not necessary reboot system):
>
> /etc/rc.d/cron restart
>
> Then take a look on cron process:
>
> ps auxww | grep cron
>
> If you doing all okey, it will be something like:
>
> root 561 0.0 0.1 7984 1528 ?? Is 3:16PM 0:00.01
> /usr/sbin/cron -j 60 -m YOU@MAIL -s
>
I did as you said and still the cron email went to root.instead of to bob.
I edited rc.conf and added this cron_flags="-m 'bob@mydomain'"
followed by "service cron restart" console command.
ps auxww console command showed
root 1953 0,0 0.2 10184 1940 - Is 1:05PM 0:00.30 /usr/sbin/cron -m
bob@mydomain -s
I am running version 10.2 on the host. In the /var/log/maillog file I
can see postfix messages showing root receiving the emails.
rc.conf hostname= option value is the same as the mydomain value in the
cron_flags= option.
Looks and acts like cron is not processing the over ride destination at
daily cron security check time.
Other than this problem of over ridding the cron email destination every
thing seems to be working as one would expect.
Is this enough to declare this a bug and submit a bug report?
Can you suggest other tests I can do to help debug this problem?
Thanks
Ernie
Arthur Chance
In the case of mail from periodic (the usual source of mail to root)
there is no bug. I've already explained to you that periodic reroutes
its output independent of cron's settings, and I've shown you how to
deal with that.
You've also had the suggestion of using aliases to ensure that any mail
to root *whatever its origins* goes to some other user.
Have you tried either of those techniques?
--
Those who do not learn from computing history are doomed to
GOTO 1
Ernie Luzar
Hello Arthur Chance;
Thank you for your reply.
To answer your questions. I have not tried the techniques of postfix
alias and periodic.conf that you have been so good as to point out.
Lets step back and look at the big cron picture. Cron is designed as per
the cron manual pages to use rc.conf cron_flags= option to over ride
the default "root" destination. Now you state and tests prove that the
cron periodic routines reroutes its output independent of cron's
settings. To my way of thinking this is the definition of the bug I am
experiencing. The periodic routines are in error by not adhering to the
cron design standard. The periodic routines need code added to them to
comply with the cron design and check for or use the value in the flags
option to over ride the destination.
Adding the statements you previous posted to periodic.conf is a
work-a-round, not a fix or the correct method as per man cron. The goal
here is not to just get things working by a secondary method, but more
to the point of getting bugs corrected.
Thank you for pointing out the cause of this bug. I am going to post a
bug report on this.
Arthur Chance
No, cron mails output to the user but periodic is specifically designed
to handle its own output because you can make it send all output to log
files rather than mail. (There's even a default set of files handled by
newsyslog to enable this - the whole thing is very well thought out.)
This is necessary on servers which do not run a mailer and is a design
feature not a bug. Output would simply be lost otherwise.
If you had read the manual page for periodic you'd know this. If you
really insist that periodic must route its output via cron, look at the
option of setting the output variables to an empty string.
> Adding the statements you previous posted to periodic.conf is a
> work-a-round, not a fix or the correct method as per man cron. The goal
> here is not to just get things working by a secondary method, but more
> to the point of getting bugs corrected.
Periodic is a different program from cron with a different set of
requirements. Setting the output variables is not a work round or
secondary method, it's the way periodic works. RTFM is always good advice.
> Thank you for pointing out the cause of this bug. I am going to post a
> bug report on this.
I predict it will be rejected because there is no bug, just the way
things have worked for a long time.
--
Those who do not learn from computing history are doomed to
GOTO 1