Re: cron & file permissions

2012-07-20 Thread Bob Proulx
Mike McClain wrote:
> man cron says: 
> 'In general, the admin should not use /etc/cron.d/, but use the
> standard system crontab /etc/crontab.'

I can only most strongly disagree with that sentiment!  :-)

I hadn't ever seen that message before.  Considering the fact that
Paul Vixie hasn't released nor authorized a release since the early
1990's and that all development since has happened in the various
distros I don't think that comment is authoritative anymore.  And
there isn't really a single authority to say one way or the other.  In
the end you will have to use your best judgement.

> I called it /etc/cron.d/local and from reading 'man run-parts' description 
> of file names think that is not going to be a problem. True?

No Debian package would ever name their file "local".  So that avoids
any name collision.  I usually end up with several different files and
I name each of them something starting with "local" so as to make it
obvious that they are mine and not part of a package.  Using a naming
convention to avoid a file name overlap is the only concern.

Bob


signature.asc
Description: Digital signature


Re: cron & file permissions

2012-07-20 Thread Mike McClain

Hi Bob,

OK I'll try it but have a question.

On Fri, Jul 20, 2012 at 01:28:04PM -0600, Bob Proulx wrote:
> Mike McClain wrote:
> > ... and haven't seen any way to get files in /etc/cron.d/ run at
> > specific times.
>
> The format of the /etc/cron.d/ files is the same format as the
> /etc/crontab.  Whatever lines you would put into /etc/crontab you
> would simply put into a file in /etc/cron.d instead.  No difference.
 

man cron says: 
'In general,  the  admin  should  not  use  /etc/cron.d/,  but  use  the  
standard  system  crontab /etc/crontab.'

I called it /etc/cron.d/local and from reading 'man run-parts' description 
of file names think that is not going to be a problem. True?

< very clear explanation snipped > 

Thanks,
Mike
-- 
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720203141.GA3140@playground



Re: cron & file permissions

2012-07-20 Thread Bob Proulx
Bob Proulx wrote:
>   # Run mylocalscript every hour.
>   0 17 * * * root  /usr/local/bin/mylocalscript

That is what I get for constructing an example in a rush.  Obviously
that comment doesn't match.  Oh well.  You get the idea.

Bob


signature.asc
Description: Digital signature


Re: cron & file permissions

2012-07-20 Thread Bob Proulx
Mike McClain wrote:
> ... and haven't seen any way to get files in /etc/cron.d/ run at
> specific times.

The format of the /etc/cron.d/ files is the same format as the
/etc/crontab.  Whatever lines you would put into /etc/crontab you
would simply put into a file in /etc/cron.d instead.  No difference.
For example a /etc/cron.d/local-myscript file:

  # Run mylocalscript every hour.
  0 17 * * * root  /usr/local/bin/mylocalscript

> I can see how /etc/cron.d/ helps developers who want their packages
> cron jobs run but don't see how it would benefit me who have physical
> access to the hardware.

I don't see how physical access to the hardware changes things.  The
advantage is that upon system upgrades any changes to /etc/crontab
will need to be merged.  Local changes and system changes are both to
the same file.  When dpkg encounters this it will prompt you with what
to about the merge.  It is fairly easy to edit the file then and fix
things up appropriately.  But if a /etc/cron.d/local-myscript file is
used instead then there is never a conflict and no merging is
needed.  It is completely automatic and hands-off in that case.

So in summary the advantage is that it avoids manual interaction.  It
avoids needing to merge local changes with system changes.  It is
simply easier that way.

Bob


signature.asc
Description: Digital signature


Re: cron & file permissions

2012-07-20 Thread Mike McClain
Hi Bob,

On Wed, Jul 18, 2012 at 04:32:03PM -0600, Bob Proulx wrote:
> Mike McClain wrote:
> > I've a cron job run daily from /etc/crontab,
> 
> Instead of using the BSD-style interface let me strongly encourage you
> to start using the newer Vixie-cron-style interface of /etc/cron.d/
> where they can be separate and individual files.  That way the file
> can be dropped into place on a new installation or removed when
> cleaning up.  That is easier and cleaner than manually editing the
> /etc/crontab file and working around the existing entries.

I've only added 3 lines to crontab and haven't seen any way to get files
in /etc/cron.d/ run at specific times.
I can see how /etc/cron.d/ helps developers who want their packages
cron jobs run but don't see how it would benefit me who have physical
access to the hardware.

 

Thanks for your thoughts,
Mike
-- 
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720171108.GA2695@playground



Re: cron & file permissions

2012-07-19 Thread Mike McClain
Hi Chris,

On Thu, Jul 19, 2012 at 12:06:33PM +0100, Chris Davies wrote:
> Mike McClain  wrote:
> > /mc/bin/daily sets umask
> > umask 037   #   save files rw owner, group read only
> 
> > then runs a script like so:
> > [ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log
> 
> You want the output to go to the cron email as well as to the log file?

Yes. 

> > but the permissions on secure.log come out 600:
> > root@/deb60:~> ls -l sysstats/secure.log
> > -rw--- 1 root root 67832 Jul 18 02:01 sysstats/secure.log
> 
> > What do I need to do to make secure.log permissions come out 640?
> 
> The permissions from umask are only applied to files that are created. If
> sysstats/secure.log already exists they won't be changed.

This was the clue I needed!
There was a call to 'savelog -p' before the /mc/bin/secure call and
that was creating an empty secure.log with the permissions of the previous.

Thanks for the help.
Mike
-- 
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719184631.GA8174@playground



Re: cron & file permissions

2012-07-19 Thread Chris Davies
Mike McClain  wrote:
> /mc/bin/daily sets umask
> umask 037   #   save files rw owner, group read only

> then runs a script like so:
> [ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log

You want the output to go to the cron email as well as to the log file?


> but the permissions on secure.log come out 600:
> root@/deb60:~> ls -l sysstats/secure.log
> -rw--- 1 root root 67832 Jul 18 02:01 sysstats/secure.log

> What do I need to do to make secure.log permissions come out 640?

The permissions from umask are only applied to files that are created. If
sysstats/secure.log already exists they won't be changed.

Either delete the file and wait for your cron job to re-create it,
or fix up the permissions manually.

Chris


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pa6ld9xc5t@news.roaima.co.uk



Re: cron & file permissions

2012-07-18 Thread Bob Proulx
Mike McClain wrote:
> I've a cron job run daily from /etc/crontab,

Instead of using the BSD-style interface let me strongly encourage you
to start using the newer Vixie-cron-style interface of /etc/cron.d/
where they can be separate and individual files.  That way the file
can be dropped into place on a new installation or removed when
cleaning up.  That is easier and cleaner than manually editing the
/etc/crontab file and working around the existing entries.

> the entry looks like this:
> 0 2 * * *   root[ -d /mc/bin ] && /mc/bin/daily;

Okay.

> /mc/bin/daily sets umask
> umask 037   #   save files rw owner, group read only
> 
> then runs a script like so:
> [ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log ;

Okay.  But why the extra ';' at the end?  It feels like a dangling
something that should have been edited out with some previous edit.

> but the permissions on secure.log come out 600:
> root@/deb60:~> ls -l sysstats/secure.log
> -rw--- 1 root root 67832 Jul 18 02:01 sysstats/secure.log
>
> What do I need to do to make secure.log permissions come out 640?

I cannot recreate this behavior.  Works for me.  If I set up an
equivalent then I produce files with mode -rw-r-.

To debug this, I would trace the operation of your script.  First add
the printing of the current umask just before the 'tee'.  Also ensure
that the target of the tee command does not exist, since umask will
only affect the creation of new files.

  umask 037
  umask
  ls -ld /root/sysstats/secure.log
  [ -e /mc/bin/secure ] && /mc/bin/secure 2>&1 | tee /root/sysstats/secure.log

I assume it is a #!/bin/sh script?  If so then run it like this:

  sh -x /mc/bin/daily

Then look at the trace and verify that umask is actually getting set.
Seems like there is something happening that isn't known that is not
what you expect to be happening.

Bob


signature.asc
Description: Digital signature