• trouble with cron script.

    From Jean-David Beyer@110:300/1.1 to All on Tue Jan 15 14:38:41 2013
    I am running Red Hat Enterprise Linux 6.3 and in /etc/cron.daily I have
    a script that backs up my file system. At the end of that script, I have
    a line that sends me an e-mail indicating that it completed correctly.
    The problem is that if I run it logged inas root, even in root's home directory, it works just fine. But if cron runs it, it works fine,
    _but does not send the e-mail_. Now all the programs invoked, as far as
    I can tell, contain the full path name. So to send mail, the script says
    this:

    BACKUPDIR=/var/log/Backups
    DATE=/bin/date
    ECHO=/bin/echo
    ENDFILE="~."
    MAIL=/bin/mailx
    ME=jeandavid8
    REPORT=$BACKUPDIR/report.`$DATE +%Y%b%d%H%M`
    SLEEP=/bin/sleep
    [most of script]

    $ECHO `$DATE +%Y%b%d%R` "DellT7600: Daily backup OK for DellT7600." >>
    $REPORT
    $CHMOD 0664 $REPORT
    $CHGRP jeandavid8 $REPORT
    $ECHO $ENDFILE >> $REPORT
    $SLEEP 5

    $MAIL -s "DellT7600 find|cpio Report" -a $REPORT $ME <<EOF
    $ENDFILE
    EOF

    $SLEEP 2
    exit 0

    Note that the two $ECHO commands have worked. The $SLEEPs are in there
    in a despairate attempt to debug, so the $MAIL must have been executed.
    Right? And _it does_ get executed if I (as root) run it from a normal
    shell (bash).

    Since I use full pathnames for the commands, it seems to me that even if
    I do not know the environment that the cron script runs in, it should
    work. And since it is run by root, it surely has permission to run any
    of these.

    I am mystified.

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Scott Lurndal@110:300/1.1 to All on Tue Jan 15 15:29:04 2013
    Reply-To: slp53@pacbell.net

    Jean-David Beyer <jeandavid8@verizon.net> writes:
    I am running Red Hat Enterprise Linux 6.3 and in /etc/cron.daily I have
    a script that backs up my file system. At the end of that script, I have
    a line that sends me an e-mail indicating that it completed correctly.
    The problem is that if I run it logged inas root, even in root's home >directory, it works just fine. But if cron runs it, it works fine,
    _but does not send the e-mail_. Now all the programs invoked, as far as
    I can tell, contain the full path name. So to send mail, the script says >this:

    add "set -x" at the start of your script, and the resulting commands will
    be echoed to the cron output.

    issue the 'env' command at your interactive prompt, do the same in the cron
    job and compare the results.

    scott


    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: UseNetServer - www.usenetserver.com (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Tue Jan 15 18:29:58 2013
    On 01/15/2013 09:29 AM, Scott Lurndal wrote:
    Jean-David Beyer <jeandavid8@verizon.net> writes:
    I am running Red Hat Enterprise Linux 6.3 and in /etc/cron.daily I have
    a script that backs up my file system. At the end of that script, I have
    a line that sends me an e-mail indicating that it completed correctly.
    The problem is that if I run it logged inas root, even in root's home
    directory, it works just fine. But if cron runs it, it works fine,
    _but does not send the e-mail_. Now all the programs invoked, as far as
    I can tell, contain the full path name. So to send mail, the script says
    this:
    add "set -x" at the start of your script, and the resulting commands will
    be echoed to the cron output.

    issue the 'env' command at your interactive prompt, do the same in the cron job and compare the results.

    scott

    Thank you. I forgot all about "set -x". I could not find it in the
    O'Reilly bash book -- but it works.

    How will I get its output preserved so I can see it when cron runs it?
    If I run env inside the script, I can dump its output into the "report"
    file for later examination. I put that in and am about to try it as root
    from root's home directory.

    OK: When I run it as root from /root directory, it works, and set -x
    produced this (only the last part):

    + /bin/echo 2013Jan1511:47 'DellT7600: Daily backup OK for DellT7600.'
    + /bin/chmod 0664 /var/log/Backups/report.2013Jan151138
    + /bin/chgrp jeandavid8 /var/log/Backups/report.2013Jan151138
    + /bin/echo '~.'
    + /bin/mailx -s 'DellT7600 find|cpio Report' -a /var/log/Backups/report.2013Jan151138 jeandavid8
    + exit 0

    The /bin/env put out this:

    HOSTNAME=DellT7600.localdomain
    TERM=xterm
    SHELL=/bin/bash
    HISTSIZE=1000 PERL5LIB=/usr/local/lib64/perl5:/usr/local/share/perl5:/usr/lib64/perl5/vendor_ perl:/usr/share/perl5/vendor_perl
    QTDIR=/usr/lib64/qt-3.3
    QTINC=/usr/lib64/qt-3.3/include
    USER=root
    LS_COLORS= [huge and boring: I leave that out] PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin: /usr/bin:/root/bin
    MAIL=/bin/mailx
    PWD=/root
    LANG=en_US.UTF-8
    HISTCONTROL=ignoredups
    SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
    HOME=/root
    SHLVL=2
    LOGNAME=root
    CVS_RSH=ssh
    QTLIB=/usr/lib64/qt-3.3/lib
    LESSOPEN=|/usr/bin/lesspipe.sh %s
    DISPLAY=:0.0
    G_BROKEN_FILENAMES=1
    XAUTHORITY=/root/.xauthKkfgFg
    _=/bin/env
    [followed by the actual report]

    I am not sure how to see the cron output, since in RHEL 6, they do not
    really run _cron_ at all, but have some scheme I do not understand to
    get _at_ to do it. It does write something in /var/log/cron, so maybe it
    will appear there. I will see tomorrow.

    I guess it does log in /var/log/cron. It said this for this morning's
    daily cron job. zBackup.daily is the file that is not mailing when cron
    runs it.

    Jan 15 03:33:01 DellT7600 anacron[5540]: Job `cron.daily' started
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5638]: finished cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5645]: finished
    logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5774]: finished makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5785]: finished mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting prelink Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5797]: finished prelink Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5808]: finished readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5846]: finished
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting zBackup.daily
    Jan 15 03:40:02 DellT7600 CROND[5878]: (root) CMD (/usr/lib64/sa/sa1 1 1)
    Jan 15 03:42:15 DellT7600 run-parts(/etc/cron.daily)[5893]: finished zBackup.daily
    Jan 15 03:42:15 DellT7600 anacron[5540]: Job `cron.daily' terminated
    (mailing output)




    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Scott Lurndal@110:300/1.1 to All on Tue Jan 15 18:47:50 2013
    Reply-To: slp53@pacbell.net

    Jean-David Beyer <jeandavid8@verizon.net> writes:
    On 01/15/2013 09:29 AM, Scott Lurndal wrote:
    Jean-David Beyer <jeandavid8@verizon.net> writes:
    I am running Red Hat Enterprise Linux 6.3 and in /etc/cron.daily I have
    a script that backs up my file system. At the end of that script, I have >>> a line that sends me an e-mail indicating that it completed correctly.
    The problem is that if I run it logged inas root, even in root's home
    directory, it works just fine. But if cron runs it, it works fine,
    _but does not send the e-mail_. Now all the programs invoked, as far as
    I can tell, contain the full path name. So to send mail, the script says >>> this:
    add "set -x" at the start of your script, and the resulting commands will
    be echoed to the cron output.

    issue the 'env' command at your interactive prompt, do the same in the cron >> job and compare the results.

    scott

    Thank you. I forgot all about "set -x". I could not find it in the
    O'Reilly bash book -- but it works.

    How will I get its output preserved so I can see it when cron runs it?
    If I run env inside the script, I can dump its output into the "report"
    file for later examination. I put that in and am about to try it as root
    from root's home directory.

    cron normally mails the contents of stdout/stderr (if not empty) to the
    user for the UID the cron job was run. I'm not sure if this also
    applies to /etc/cron.daily scripts.

    In any case, you can:

    exec 2> /tmp/stderr-log-file
    exec 1> /tmp/stdout-log-file

    in your script before the 'set -x' and it should place output in the specified files.

    Check /var/spool/mail/root to see if the cron output got placed there.

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: UseNetServer - www.usenetserver.com (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Tue Jan 15 19:43:28 2013
    On 01/15/2013 12:47 PM, Scott Lurndal wrote:
    Jean-David Beyer <jeandavid8@verizon.net> writes:
    On 01/15/2013 09:29 AM, Scott Lurndal wrote:
    Jean-David Beyer <jeandavid8@verizon.net> writes:
    I am running Red Hat Enterprise Linux 6.3 and in /etc/cron.daily I have >>>> a script that backs up my file system. At the end of that script, I have >>>> a line that sends me an e-mail indicating that it completed correctly. >>>> The problem is that if I run it logged inas root, even in root's home
    directory, it works just fine. But if cron runs it, it works fine,
    _but does not send the e-mail_. Now all the programs invoked, as far as >>>> I can tell, contain the full path name. So to send mail, the script says >>>> this:
    add "set -x" at the start of your script, and the resulting commands will >>> be echoed to the cron output.

    issue the 'env' command at your interactive prompt, do the same in the cron
    job and compare the results.

    scott

    Thank you. I forgot all about "set -x". I could not find it in the
    O'Reilly bash book -- but it works.

    How will I get its output preserved so I can see it when cron runs it?
    If I run env inside the script, I can dump its output into the "report"
    file for later examination. I put that in and am about to try it as root
    from root's home directory.

    cron normally mails the contents of stdout/stderr (if not empty) to the
    user for the UID the cron job was run. I'm not sure if this also
    applies to /etc/cron.daily scripts.
    I do not know, but I added

    root: jeandavid8

    to the bottom of /etc/aliases and ran _newaliases_ so mail to root
    will now come to me without any special effort.

    In any case, you can:

    exec 2> /tmp/stderr-log-file
    exec 1> /tmp/stdout-log-file

    in your script before the 'set -x' and it should place output in the
    specified
    files.

    Check /var/spool/mail/root to see if the cron output got placed there.
    It did -- this is from last night's run that worked, although _no e-mail
    was produced_.:

    Jan 15 03:33:01 DellT7600 anacron[5540]: Job `cron.daily' started
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5638]: finished cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5645]: finished
    logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5774]: finished makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5785]: finished mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting prelink Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5797]: finished prelink Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5808]: finished readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5846]: finished
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting zBackup.daily
    Jan 15 03:40:02 DellT7600 CROND[5878]: (root) CMD (/usr/lib64/sa/sa1 1 1)
    Jan 15 03:42:15 DellT7600 run-parts(/etc/cron.daily)[5893]: finished zBackup.daily
    Jan 15 03:42:15 DellT7600 anacron[5540]: Job `cron.daily' terminated
    (mailing output)
    Jan 15 03:42:16 DellT7600 anacron[5540]: Normal exit (1 job run)

    No indication that zBackup.daily had any problem.

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Wed Jan 16 14:04:58 2013
    On 01/15/2013 01:43 PM, Jean-David Beyer wrote:
    On 01/15/2013 12:47 PM, Scott Lurndal wrote:


    cron normally mails the contents of stdout/stderr (if not empty) to the
    user for the UID the cron job was run. I'm not sure if this also
    applies to /etc/cron.daily scripts.
    I do not know, but I added

    root: jeandavid8

    to the bottom of /etc/aliases and ran _newaliases_ so mail to root
    will now come to me without any special effort.
    In any case, you can:

    exec 2> /tmp/stderr-log-file
    exec 1> /tmp/stdout-log-file

    in your script before the 'set -x' and it should place output in the specified
    files.

    Check /var/spool/mail/root to see if the cron output got placed there.
    It did -- this is from last night's run that worked, although _no e-mail
    was produced_.:

    Jan 15 03:33:01 DellT7600 anacron[5540]: Job `cron.daily' started
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5638]: finished cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5645]: finished logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5774]: finished makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5785]: finished mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting prelink Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5797]: finished prelink Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5808]: finished readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5846]: finished
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting zBackup.daily
    Jan 15 03:40:02 DellT7600 CROND[5878]: (root) CMD (/usr/lib64/sa/sa1 1 1)
    Jan 15 03:42:15 DellT7600 run-parts(/etc/cron.daily)[5893]: finished zBackup.daily
    Jan 15 03:42:15 DellT7600 anacron[5540]: Job `cron.daily' terminated
    (mailing output)
    Jan 15 03:42:16 DellT7600 anacron[5540]: Normal exit (1 job run)

    No indication that zBackup.daily had any problem.
    OK, some results from cron run.

    All the above is from when root ran the script. With the _set -x_ in the
    script and when "cron" ran it (not root), I got an e-mail from
    _Anacron_. In that e-mail was the output from the script because of the
    set -x in it. The beginning it says:

    From root@DellT7600.localdomain Wed Jan 16 03:18:27 2013
    Return-Path: <root@DellT7600.localdomain>
    Date: Wed, 16 Jan 2013 03:18:27 -0500
    From: Anacron <root@DellT7600.localdomain>
    To: root@DellT7600.localdomain
    Content-Type: text/plain; charset="ANSI_X3.4-1968"
    Subject: Anacron job 'cron.daily' on DellT7600.localdomain
    Status: R

    The end says:

    + /bin/mailx -s 'DellT7600 find|cpio Report' -a +/var/log/Backups/report.2013Jan160308 jeandavid8 /var/log/Backups/report.2013Jan160308: Permission denied
    + exit 0

    I infer that _Anacron_ (seemingly an alias for _root_) does not have
    permission to read that file. I assumed it was root that was running
    that script, not Anacron. Now if it is not me or root, there might be a
    problem reading the report (the -a option to mailx). But there should
    not be much:

    The end of the script reads:

    $CHMOD 0664 $REPORT
    $CHGRP jeandavid8 $REPORT
    $ECHO $ENDFILE >> $REPORT
    $MAIL -s "DellT7600 find|cpio Report" -a $REPORT $ME <<EOF
    $ENDFILE
    EOF

    exit 0

    and I would expect that this gives the world read-permission on that
    file. And when I check that file, it has ownership and group as I
    expect, and permissions as I expect. But apparently not???

    Since Anacron is not in /etc/passwd, who is really running that? And no
    matter who it is, why cannot he read that file?




    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Scott Lurndal@110:300/1.1 to All on Wed Jan 16 16:33:03 2013
    Reply-To: slp53@pacbell.net

    Jean-David Beyer <jeandavid8@verizon.net> writes:
    On 01/15/2013 01:43 PM, Jean-David Beyer wrote:
    On 01/15/2013 12:47 PM, Scott Lurndal wrote:


    cron normally mails the contents of stdout/stderr (if not empty) to the
    user for the UID the cron job was run. I'm not sure if this also
    applies to /etc/cron.daily scripts.
    I do not know, but I added

    root: jeandavid8

    to the bottom of /etc/aliases and ran _newaliases_ so mail to root
    will now come to me without any special effort.
    In any case, you can:

    exec 2> /tmp/stderr-log-file
    exec 1> /tmp/stdout-log-file

    in your script before the 'set -x' and it should place output in the specified
    files.

    Check /var/spool/mail/root to see if the cron output got placed there.
    It did -- this is from last night's run that worked, although _no e-mail
    was produced_.:

    Jan 15 03:33:01 DellT7600 anacron[5540]: Job `cron.daily' started
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5638]: finished cups
    Jan 15 03:33:01 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5645]: finished
    logrotate
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5774]: finished
    makewhatis.cron
    Jan 15 03:33:02 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5785]: finished
    mlocate.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting prelink
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5797]: finished prelink
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5808]: finished
    readahead.cron
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5846]: finished
    tmpwatch
    Jan 15 03:33:15 DellT7600 run-parts(/etc/cron.daily)[5630]: starting
    zBackup.daily
    Jan 15 03:40:02 DellT7600 CROND[5878]: (root) CMD (/usr/lib64/sa/sa1 1 1)
    Jan 15 03:42:15 DellT7600 run-parts(/etc/cron.daily)[5893]: finished
    zBackup.daily
    Jan 15 03:42:15 DellT7600 anacron[5540]: Job `cron.daily' terminated
    (mailing output)
    Jan 15 03:42:16 DellT7600 anacron[5540]: Normal exit (1 job run)

    No indication that zBackup.daily had any problem.
    OK, some results from cron run.

    All the above is from when root ran the script. With the _set -x_ in the >script and when "cron" ran it (not root), I got an e-mail from
    _Anacron_. In that e-mail was the output from the script because of the
    set -x in it. The beginning it says:

    From root@DellT7600.localdomain Wed Jan 16 03:18:27 2013
    Return-Path: <root@DellT7600.localdomain>
    Date: Wed, 16 Jan 2013 03:18:27 -0500
    From: Anacron <root@DellT7600.localdomain>
    To: root@DellT7600.localdomain
    Content-Type: text/plain; charset="ANSI_X3.4-1968"
    Subject: Anacron job 'cron.daily' on DellT7600.localdomain
    Status: R

    The end says:

    + /bin/mailx -s 'DellT7600 find|cpio Report' -a >+/var/log/Backups/report.2013Jan160308 jeandavid8 >/var/log/Backups/report.2013Jan160308: Permission denied
    + exit 0

    I infer that _Anacron_ (seemingly an alias for _root_) does not have >permission to read that file. I assumed it was root that was running
    that script, not Anacron. Now if it is not me or root, there might be a >problem reading the report (the -a option to mailx). But there should
    not be much:

    The end of the script reads:

    $CHMOD 0664 $REPORT
    $CHGRP jeandavid8 $REPORT
    $ECHO $ENDFILE >> $REPORT
    $MAIL -s "DellT7600 find|cpio Report" -a $REPORT $ME <<EOF
    $ENDFILE
    EOF

    exit 0

    and I would expect that this gives the world read-permission on that
    file. And when I check that file, it has ownership and group as I
    expect, and permissions as I expect. But apparently not???

    Since Anacron is not in /etc/passwd, who is really running that? And no >matter who it is, why cannot he read that file?




    add an "id -a" line to your script. This will print the credentials of the user running the script to the log file(s)/mail.

    Then determine from the ownership of the report file and the permissions of
    the /var/log/Backups directory whether that UID is allowed to write to
    the directory.

    scott

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: UseNetServer - www.usenetserver.com (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Wed Jan 16 17:25:47 2013
    On 01/16/2013 10:33 AM, Scott Lurndal wrote:

    The end says:

    + /bin/mailx -s 'DellT7600 find|cpio Report' -a +/var/log/Backups/report.2013Jan160308 jeandavid8 /var/log/Backups/report.2013Jan160308: Permission denied

    add an "id -a" line to your script. This will print the credentials of
    the user running the script to the log file(s)/mail. Then determine
    from the ownership of the report file and the permissions of the /var/log/Backups directory whether that UID is allowed to write to the directory. scott
    OK. I did that and when I run it as root, it comes out like this (boring
    stuff omitted) and it works as it always does when I run as root. I will
    see tomorrow what happens when cron or anacron runs it tonight.

    # ./zBackup.daily [me running the script as root]
    + id -a
    uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    But the thing is that _anyone should be able to read that report file_.
    In fact whoever is running that cron script _created that file correctly
    and with the correct permissions and ownership_. In particular even
    world has read permission on that file, so no matter who is running that script, since they had permission to create and write the file, it seems
    likely they have permission to read it.

    This is the permission of the directory the file is in.

    [/var/log/Backups]$ ls -ld .
    drwxrwxr-x. 2 root jeandavid8 4096 Jan 16 11:09 .

    And this is the permission of the file itself

    [/var/log/Backups]$ ls -l report.2013Jan160308
    -rw-rw-r--. 1 root jeandavid8 271 Jan 16 03:18 report.2013Jan160308




    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Scott Lurndal@110:300/1.1 to All on Wed Jan 16 22:36:47 2013
    Reply-To: slp53@pacbell.net

    Jean-David Beyer <jeandavid8@verizon.net> writes:
    On 01/16/2013 10:33 AM, Scott Lurndal wrote:

    The end says:

    + /bin/mailx -s 'DellT7600 find|cpio Report' -a >+/var/log/Backups/report.2013Jan160308 jeandavid8 >/var/log/Backups/report.2013Jan160308: Permission denied

    add an "id -a" line to your script. This will print the credentials of
    the user running the script to the log file(s)/mail. Then determine
    from the ownership of the report file and the permissions of the
    /var/log/Backups directory whether that UID is allowed to write to the
    directory. scott
    OK. I did that and when I run it as root, it comes out like this (boring >stuff omitted) and it works as it always does when I run as root. I will
    see tomorrow what happens when cron or anacron runs it tonight.

    # ./zBackup.daily [me running the script as root]
    + id -a
    uid=0(root) gid=0(root) >groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) >context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    But the thing is that _anyone should be able to read that report file_.
    In fact whoever is running that cron script _created that file correctly
    and with the correct permissions and ownership_. In particular even
    world has read permission on that file, so no matter who is running that >script, since they had permission to create and write the file, it seems >likely they have permission to read it.

    You really need to get the 'id -a' of the user running the cron job,
    not of root. You need to ensure that the security context of the
    target directory/file allows access. You can see the file security
    context with ls -Z, and as per above, id -a will show the security
    context of the user.

    Check your /var/log/messages for SELinux denied access messages
    on the relevent file.

    You can determine whether SELinux is running by looking at /etc/sysconfig/selinux.


    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: UseNetServer - www.usenetserver.com (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Thu Jan 17 01:45:59 2013
    On 01/16/2013 04:36 PM, Scott Lurndal wrote:
    Jean-David Beyer <jeandavid8@verizon.net> writes:
    On 01/16/2013 10:33 AM, Scott Lurndal wrote:

    The end says:

    + /bin/mailx -s 'DellT7600 find|cpio Report' -a
    +/var/log/Backups/report.2013Jan160308 jeandavid8
    /var/log/Backups/report.2013Jan160308: Permission denied

    add an "id -a" line to your script. This will print the credentials of
    the user running the script to the log file(s)/mail. Then determine
    from the ownership of the report file and the permissions of the
    /var/log/Backups directory whether that UID is allowed to write to the
    directory. scott
    OK. I did that and when I run it as root, it comes out like this (boring
    stuff omitted) and it works as it always does when I run as root. I will
    see tomorrow what happens when cron or anacron runs it tonight.

    # ./zBackup.daily [me running the script as root]
    + id -a
    uid=0(root) gid=0(root)
    groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
    context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    But the thing is that _anyone should be able to read that report file_.
    In fact whoever is running that cron script _created that file correctly
    and with the correct permissions and ownership_. In particular even
    world has read permission on that file, so no matter who is running that
    script, since they had permission to create and write the file, it seems
    likely they have permission to read it.
    You really need to get the 'id -a' of the user running the cron job,
    not of root.
    Sure thing. That should happen when the cron job runs tonight. When I
    run it as root, all it tells me is that that script does pretty much
    what I want it to.
    You need to ensure that the security context of the
    target directory/file allows access. You can see the file security
    context with ls -Z, and as per above, id -a will show the security
    context of the user.
    I just did that. It says:

    [/var/log/Backups]$ ls -ldZ .
    drwxrwxr-x. root jeandavid8 unconfined_u:object_r:var_log_t:s0 .

    [/var/log/Backups]$ ls -lZ report.2013Jan160308
    -rw-rw-r--. root jeandavid8 system_u:object_r:cron_log_t:s0 report.2013Jan160308


    Check your /var/log/messages for SELinux denied access messages
    on the relevent file.
    /var/log/messages us absolutely full of audit messages, and I thought I
    had SElinux turned off.
    From below, it appears as though it were on.

    Yet all those messages about _denied_ do not seem to have resulted in
    things not happening. This confuses me greatly. But you probably want to
    see this from the wee hours of this morning:

    Jan 16 03:18:27 DellT7600 kernel: type=1400 audit(1358324307.171:35790):
    avc: denied { read } for pid=12243 comm="mailx"
    name="report.2013Jan160308" dev=sdb8 ino=525322 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file
    Jan 16 03:18:27 DellT7600 run-parts(/etc/cron.daily)[12245]: finished zBackup.daily


    /dev/sdb8 16126920 1122636 14185084 8% /var


    You can determine whether SELinux is running by looking at /etc/sysconfig/selinux.

    # This file controls the state of SELinux on the system.
    # SELINUX= can take one of these three values:
    # enforcing - SELinux security policy is enforced.
    # permissive - SELinux prints warnings instead of enforcing.
    # disabled - No SELinux policy is loaded.
    SELINUX=enforcing
    # SELINUXTYPE= can take one of these two values:
    # targeted - Targeted processes are protected,
    # mls - Multi Level Security protection.
    SELINUXTYPE=targeted

    # getenforce
    Enforcing

    # sestatus
    SELinux status: enabled
    SELinuxfs mount: /selinux
    Current mode: enforcing
    Mode from config file: enforcing
    Policy version: 24
    Policy from config file: targeted

    I have never run with SElinux enabled. On the one hand it seems a good
    idea to do that, but on the other, I hate spending a week figuring out a problem like this.

    Also, the /var/log/message file is almost useless because it is full of
    these cursed messages. And they cannot mean much, since things (other
    than cron sending an e-mail) seem to be working. But if those messages
    mean nothing, I would like them off, and if they really mean something,
    I should do something about them and not turn SElinux off. Would
    changing SELINUX=enforcing to SELINUX=permissive be a good move?


    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Scott Lurndal@110:300/1.1 to All on Thu Jan 17 15:32:28 2013
    Reply-To: slp53@pacbell.net

    Jean-David Beyer <jeandavid8@verizon.net> writes:
    On 01/16/2013 04:36 PM, Scott Lurndal wrote:

    You can determine whether SELinux is running by looking at
    /etc/sysconfig/selinux.

    # This file controls the state of SELinux on the system.
    # SELINUX= can take one of these three values:
    # enforcing - SELinux security policy is enforced.
    # permissive - SELinux prints warnings instead of enforcing.
    # disabled - No SELinux policy is loaded.
    SELINUX=enforcing
    # SELINUXTYPE= can take one of these two values:
    # targeted - Targeted processes are protected,
    # mls - Multi Level Security protection.
    SELINUXTYPE=targeted

    # getenforce
    Enforcing

    # sestatus
    SELinux status: enabled
    SELinuxfs mount: /selinux
    Current mode: enforcing
    Mode from config file: enforcing
    Policy version: 24
    Policy from config file: targeted

    I have never run with SElinux enabled. On the one hand it seems a good
    idea to do that, but on the other, I hate spending a week figuring out a >problem like this.

    Also, the /var/log/message file is almost useless because it is full of
    these cursed messages. And they cannot mean much, since things (other
    than cron sending an e-mail) seem to be working. But if those messages
    mean nothing, I would like them off, and if they really mean something,
    I should do something about them and not turn SElinux off. Would
    changing SELINUX=enforcing to SELINUX=permissive be a good move?

    Generally, at least with recent vintages (e.g. Fedora Core 17), the selinux messages in /var/log/messages will include a string like:

    sealert -l b95fd640-2666-4e6a-8f9a-671b6605e61e

    If you run that command, various recommendations for correcting the issue
    will be presented (such as updating a file label and using /sbin/restorecon,
    or autorelabeling the system (touch /.autorelabel; reboot).

    Looks like RHEL5/6 both have the sealert command.

    scott

    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: UseNetServer - www.usenetserver.com (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Thu Jan 17 18:43:45 2013
    On 01/17/2013 09:32 AM, Scott Lurndal wrote:
    Generally, at least with recent vintages (e.g. Fedora Core 17), the
    selinux messages in /var/log/messages will include a string like:
    sealert -l b95fd640-2666-4e6a-8f9a-671b6605e61e If you run that
    command, various recommendations for correcting the issue will be
    presented (such as updating a file label and using /sbin/restorecon,
    or autorelabeling the system (touch /.autorelabel; reboot). Looks like RHEL5/6 both have the sealert command. scott

    The string _sealert_ does not appear in my /var/log/messages file that
    goes back to Jan 13 03:44:01
    Oh! The string _secalert_ does appear...

    Oh! Well! False alarm; this is the only one:

    Jan 14 11:17:42 DellT7600 kernel: - User ID: Red Hat Enterprise Linux
    Driver Update Program <secalert@redhat.com>

    That command does exist on my system:

    # whereis sealert
    sealert: /usr/bin/sealert /usr/share/man/man8/sealert.8.gz

    As I said, my messages file is littered with lines like these:

    Jan 17 03:28:08 DellT7600 run-parts(/etc/cron.daily)[21490]: starting zBackup.daily
    Jan 17 03:28:09 DellT7600 kernel: type=1400 audit(1358411289.585:37217):
    avc: denied { signull } for pid=2320 comm="hadcm3n_um_6.07" scontext=system_u:system_r:boinc_t:s0
    tcontext=system_u:system_r:boinc_t:s0 tclass=process

    The second line has nothing to do with the zBackup.daily program, but
    one of the BOINC jobs that runs at nice 19 to soak up otherwise unused
    CPU cycles.

    Shortly after these two, skipping a lot of messages similar to the
    second one above, I get these that actually matter to the job at hand:

    Jan 17 03:38:04 DellT7600 kernel: type=1400 audit(1358411884.560:37250):
    avc: denied { read } for pid=24503 comm="mailx"
    name="report.2013Jan170328" dev=sdb8 ino=525360 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file
    Jan 17 03:38:04 DellT7600 run-parts(/etc/cron.daily)[24507]: finished zBackup.daily
    Jan 17 03:38:04 DellT7600 anacron[21427]: Job `cron.daily' terminated
    (mailing output)
    Jan 17 03:38:04 DellT7600 anacron[21427]: Normal exit (1 job run)

    The mail command resulting from the first of these lines did not result
    in mail getting sent.

    The mail sent by anacron[21427] did get sent, as follows:

    /etc/cron.daily/zBackup.daily:

    + id -a
    uid=0(root) gid=0(root) +groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) +context=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023

    [boring stuff deleted]

    + /bin/echo 2013Jan1703:38 'DellT7600: Daily backup OK for DellT7600.'
    + /bin/echo '~.'
    + /bin/mailx -s 'DellT7600 find|cpio Report' -a +/var/log/Backups/report.2013Jan170328 jeandavid8 /var/log/Backups/report.2013Jan170328: Permission denied
    + /bin/chmod 0664 /var/log/Backups/report.2013Jan170328
    + /bin/chgrp jeandavid8 /var/log/Backups/report.2013Jan170328
    + exit 0

    Everything here is as it should be except for the line:

    /var/log/Backups/report.2013Jan170328: Permission denied


    The report included this (including the out put of the env command in the script:

    SHELL=/bin/sh
    MAILTO=root
    USER=root
    PATH=/sbin:/bin:/usr/sbin:/usr/bin
    PWD=/
    HOME=/
    SHLVL=6
    START_HOURS_RANGE=3
    LOGNAME=root
    RANDOM_DELAY=45
    _=/bin/env

    Followed by all the stuff that should be in there.

    This line from the set -x of the script:

    uid=0(root) gid=0(root) +groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) +context=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023

    And this line from messages at the same time (I guess):

    Jan 17 03:38:04 DellT7600 kernel: type=1400 audit(1358411884.560:37250):
    avc: denied { read } for pid=24503 comm="mailx"
    name="report.2013Jan170328" dev=sdb8 ino=525360 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file

    seem to say that the shell script has system_cronjob_t
    but the e-mail program has system_mail_t and that cannot read the file.

    But what do I do about that? I have Bill McCarty's 2004 book on SELINUX,
    but that is seriously out of date and I never studied it from
    cover-to-cover anyway. I have Red Hat's more up-to-date material on
    SELINUX on line, but I am just starting on that.

    https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/ Security-Enhanced_Linux/index.html

    I do not know if you can access that unless you have a contract with
    them. I have one, but it is the cheapest contract, and they usually will
    not help with problems.

    Fiddling around, I got auditd daemon running, after downloading some
    extra SElinux stuff from Red Hat. So my messages file now says:

    Jan 17 12:23:39 DellT7600 auditd[27778]: Started dispatcher:
    /sbin/audispd pid: 27780
    Jan 17 12:23:39 DellT7600 audispd: audispd initialized with q_depth=120
    and 1 active plugins
    Jan 17 12:23:39 DellT7600 auditd[27778]: Init complete, auditd 2.2
    listening for events (startup state enable)
    Jan 17 12:23:48 DellT7600 setroubleshoot: SELinux is preventing /home/boinc/projects/climateprediction.net/hadcm3n_um_6.07_i686-pc-linux-gnu from create access on the file o3nnko.daz7b60. For complete SELinux
    messages. run sealert -l 4cda66a9-9a26-4131-a3cb-810ed6379622

    So I tried that and got:

    # sealert -l 4cda66a9-9a26-4131-a3cb-810ed6379622
    SELinux is preventing /home/boinc/projects/climateprediction.net/hadcm3n_um_6.07_i686-pc-linux-gnu from create access on the file o3nnka.daz7b80.

    ***** Plugin catchall (100. confidence) suggests
    ***************************

    If you believe that hadcm3n_um_6.07_i686-pc-linux-gnu should be allowed
    create access on the o3nnka.daz7b80 file by default.
    Then you should report this as a bug.
    You can generate a local policy module to allow this access.
    Do
    allow this access for now by executing:
    # grep hadcm3n_um_6.07 /var/log/audit/audit.log | audit2allow -M mypol
    # semodule -i mypol.pp

    To whom do I report this as a bug? I betcha it is to me as sysadmin, right?

    This one is representative of a class of programs that get automatically downloaded in a trustworthy way and executed. I cannot be going in
    whenever I guess a new one has come along and diddling permissions like
    that. In RHEL5 with SElinux off, I never had a problem with this, but I
    think I should understand SElinux better and leave it on. I do not want
    to debug those right now anyway, but I will have to get to it soon. All
    the BOINC stuff seems to be working, so I do not understand these messages.

    I assume there will be something like that when cron runs that script
    tonight. And I suppose I will see it tomorrow.


    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)
  • From Jean-David Beyer@110:300/1.1 to All on Fri Jan 18 13:13:20 2013
    On 01/17/2013 12:43 PM, Jean-David Beyer wrote:
    I assume there will be something like that when cron runs that script tonight. And I suppose I will see it tomorrow.
    Well, here is what I did this morning when things failed again, as usual.
    I have my doubts, because I do not really know what I am doing. If all
    it does is allow mailx to read file

    report.2013Jan180316 file by default,

    what I did will be useless because the name of that file changes every day. Similarly with all the other similar problems, where the names of the files and the names of the programs (ever-changing) are different. And I cannot continue to put changes in like this. Furthermore, if I reboot the system, or something, all these little changes will disappear and I will have to reload them somehow.

    Jan 13 03:52:17 DellT7600 kernel: type=1400 audit(1358067137.751:38575):
    avc: denied { read } for pid=19533 comm="mailx"
    name="report.2013Jan130344" dev=sdb8 ino=525338 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file

    I tried to fix it with this:

    sealert -l b6766d24-f5e8-4db5-94eb-a153b7e0f35a
    SELinux is preventing /bin/mailx from read access on the file report.2013Jan180316.

    ***** Plugin catchall (100. confidence) suggests
    ***************************

    If you believe that mailx should be allowed read access on the report.2013Jan180316 file by default.
    Then you should report this as a bug.
    You can generate a local policy module to allow this access.
    Do
    allow this access for now by executing:
    # grep mailx /var/log/audit/audit.log | audit2allow -M mypol
    # semodule -i mypol.pp


    DellT7600:root[/var/log]# grep mailx /var/log/audit/audit.log |
    audit2allow -M mymail1
    ******************** IMPORTANT ***********************
    To make this policy package active, execute:

    semodule -i mymail1.pp

    DellT7600:root[/var/log]# semodule -i mymail1.pp

    But my guess it will fail tomorrow anyway because the file in question
    tomorrow will be a different one, named something like report.2013Jan190316.


    --- MBSE BBS v0.95.13 (GNU/Linux-x86_64)
    * Origin: NewsGuy - Unlimited Usenet $23.95 (110:300/1.1@linuxnet)