I have a cron job that updates antivirus software on a Mac OS X
client. I would like to load this cron job on other clients. I would
like to do this via a Bourne shell script that simply calls crontab
and enters the two lines of the job I set up into that user's cron
tab. Could anyone suggest a way of how to script that?

[ Post a follow-up to this message ]

On 10 Aug 2004 10:23:31 -0700, Christopher Forte <cforte@hamilton.edu> wrote:
> I have a cron job that updates antivirus software on a Mac OS X
> client.

OK, so you can continue to verify that all none known viruses still aren't
there?

> I would like to load this cron job on other clients. I would
> like to do this via a Bourne shell script that simply calls crontab
> and enters the two lines of the job I set up into that user's cron
> tab.

Seems like this would be for root's crontab, rather than the user's?  But
in any case, you could (pseudocode, this won't run as is) do something
like this maybe:

foreach host in (list of hosts) do
scp /tmp/cronlinetoadd user@$host:/tmp/cronlinetoadd
ssh $host "cat /tmp/cronlinetoadd >> /var/spool/crontabs/cron/root"
done

There are less ugly ways to do this I'm sure, probably combining this all
into one ssh command doing a "cat contents until you see an EOL flag into
the end of the crontab file".  You could also just use:
ssh user@$host "sudo crontab -e"
and paste the line in wherever you want in each of the files.  If I
was going to do this more than once, I'd set up something more elegant.

Then again, if I was going to do this more than once, I'd have a central
machine with one cronjob running the job on each of the remote ones using
ssh.  Just thinking out loud here, but the fewer places to change the
schedule the better, is what I'm thinking.  Depends on how you're going
to use it.

> Could anyone suggest a way of how to script that?

Well, I'd question the point of doing it at all in the first place,
but the above should give you a couple of options.  You'll want to put
your keys around on the target systems unless you like typing your
password alot.

Dave Hinz

[ Post a follow-up to this message ]

In article <2nsfjrF44saoU1@uni-berlin.de>, Dave Hinz wrote:
> On 10 Aug 2004 10:23:31 -0700, Christopher Forte <cforte@hamilton.edu> wro
te: 
>
> OK, so you can continue to verify that all none known viruses still aren't
> there?

Many people run Virus scanners on Unix/Linux systems that serve as file serv
ers
(via Samba) for Windows...
 
>
> Seems like this would be for root's crontab, rather than the user's?  But
> in any case, you could (pseudocode, this won't run as is) do something
> like this maybe:
>
> foreach host in (list of hosts) do
> 	scp /tmp/cronlinetoadd user@$host:/tmp/cronlinetoadd
> 	ssh $host "cat /tmp/cronlinetoadd >> /var/spool/crontabs/cron/root"
> 	done

And this will update cron how? Updating root's cron file does not update cro
n.

Change from this:

ssh $host "cat /tmp/cronlinetoadd >> /var/spool/crontabs/cron/root"

to

ssh $host "cat /var/spool/crontabs/cron/root /tmp/cronlinetoadd > \
/tmp/newcrontab; crontab /tmp/newcrontab"

And it should work...

> There are less ugly ways to do this I'm sure, probably combining this all
> into one ssh command doing a "cat contents until you see an EOL flag into
> the end of the crontab file".  You could also just use:
> ssh user@$host "sudo crontab -e"
> and paste the line in wherever you want in each of the files.  If I
> was going to do this more than once, I'd set up something more elegant.
>
> Then again, if I was going to do this more than once, I'd have a central
> machine with one cronjob running the job on each of the remote ones using

Definitely a better solution assuming that central machine is reliable...

> ssh.  Just thinking out loud here, but the fewer places to change the
> schedule the better, is what I'm thinking.  Depends on how you're going
> to use it.
> 
>
> Well, I'd question the point of doing it at all in the first place,
> but the above should give you a couple of options.  You'll want to put
> your keys around on the target systems unless you like typing your
> password alot.

Kevin

[ Post a follow-up to this message ]

On Tue, 10 Aug 2004 18:34:17 GMT, Kevin Collins <spamtotrash@toomuchfiction.com> wrote:[vbco
l=seagreen]
> In article <2nsfjrF44saoU1@uni-berlin.de>, Dave Hinz wrote:[/vbcol]
 
>
> Many people run Virus scanners on Unix/Linux systems that serve as file se
rvers
> (via Samba) for Windows...

Right, but you wouldn't need to do that from each of the clients, just
one central location.
 
>
> And this will update cron how? Updating root's cron file does not update cron.[/vb
col]

How so?  I assume this is why one uses crontab -e rather than vi to
update a crontab?  I knew there was syntax verification, never noticed
it re-kicking cron or anything.

(snip pseudocode / examples from both of us)
[vbcol=seagreen] 
>
> Definitely a better solution assuming that central machine is reliable...

Well yeah, if it's not then all bets are off.

Dave Hinz

[ Post a follow-up to this message ]

On 2004-08-10, Kevin Collins wrote:[vbcol=seagreen] 
>
> And this will update cron how? Updating root's cron file does not update cron.[/vb
col]

Actually, it may; it depends on the version of cron.

Some versions check every minute to see whether the crontab
directory has been modified; others only reload the files when they
are modified by crontab.

--
Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
 ========================================
===========================
My code (if any) in this post is copyright 2004, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

[ Post a follow-up to this message ]

Kevin Collins wrote:
> In article <2nsfjrF44saoU1@uni-berlin.de>, Dave Hinz wrote:
> 
>
>
> Many people run Virus scanners on Unix/Linux systems that serve as file se
rvers
> (via Samba) for Windows...
>
> 
>
>
> And this will update cron how? Updating root's cron file does not update c
ron.
>
> Change from this:
>
>  	ssh $host "cat /tmp/cronlinetoadd >> /var/spool/crontabs/cron/root"
>
> to
>
> 	ssh $host "cat /var/spool/crontabs/cron/root /tmp/cronlinetoadd > \
> 	/tmp/newcrontab; crontab /tmp/newcrontab"
>
> And it should work...
>
> 
>
>
> Definitely a better solution assuming that central machine is reliable...
>
> 
>
>
> Kevin

We run a virus scan on all our server's local file systems once a week.
During the week we run scans on all of the file systems exported to Unix
from our Network Appliance file servers (~4 TBytes). It's been a long
time since a virus was detected. However, last week it picked up a linux
virus that one of user the users downloaded. So they are still out
there. He was told to clean up his act or we would shut down his
account.

For all of this, the scan software needs to only exist in one
place. Updates are handled automatically every night by an FTP
from cron. If there is an update it's installed. If there is
no update, it just goes away.

The results of scans and updates are logged and viewable from a web
based interface. It takes a little while to get it all set up, but
once is in place, it all works behind the scenes and no one notices
until a virus turns up.

--
Martin E. Meserve
k7mem@myrealbox.com
http://www.k7mem.150m.com

[ Post a follow-up to this message ]

In article <2nsj3mF44saoU7@uni-berlin.de>, Dave Hinz wrote:
> On Tue, 10 Aug 2004 18:34:17 GMT, Kevin Collins <spamtotrash@toomuchfictio
n.com> wrote: 
> 
>
> Right, but you wouldn't need to do that from each of the clients, just
> one central location.

What? How do you know what the OP's client machines do? What if each one of
them is a Samba server - they would each need to run the virus scanner on th
eir
filesystems.
 
>
> How so?  I assume this is why one uses crontab -e rather than vi to
> update a crontab?  I knew there was syntax verification, never noticed
> it re-kicking cron or anything.

See Chris' post, but basically only cron on Linux (as far as my experience)
checks for updates to the files. That is why you do "crontab cronfile" or
"crontab -e" - they "do the right thing".

> (snip pseudocode / examples from both of us)
> 
>
> Well yeah, if it's not then all bets are off.

Kevin

[ Post a follow-up to this message ]

On Tue, 10 Aug 2004 13:23:06 -0700, K7MEM <k7mem@myrealbox.com> wrote:
>
> We run a virus scan on all our server's local file systems once a week.
> During the week we run scans on all of the file systems exported to Unix
> from our Network Appliance file servers (~4 TBytes). It's been a long
> time since a virus was detected.

What scanning package are you using, and how do you like it?

Dave Hinz

[ Post a follow-up to this message ]

On Tue, 10 Aug 2004 20:29:42 GMT, Kevin Collins <spamtotrash@toomuchfiction.com> wrote:[vbco
l=seagreen]
> In article <2nsj3mF44saoU7@uni-berlin.de>, Dave Hinz wrote: 
>
> What? How do you know what the OP's client machines do? What if each one o
f
> them is a Samba server - they would each need to run the virus scanner on 
their
> filesystems.[/vbcol]

Well, that would be an unexpected (translation: strange) way to do
things, but I suppose there might be someone doing it that way.
Besides, then they wouldn't be "each of the clients" then, they'd be
servers.
 
>
> See Chris' post, but basically only cron on Linux (as far as my experience
)
> checks for updates to the files. That is why you do "crontab cronfile" or
> "crontab -e" - they "do the right thing".

Fair enough, so ssh a "crontab -e" to each host in list if it's a one-time
shot, rather than just appending to the crontab file.  Or, append and then
re-kick cron.

Dave Hinz

[ Post a follow-up to this message ]

In article <2nsmrdF4c17lU1@uni-berlin.de>,
"Chris F.A. Johnson" <cfajohnson@gmail.com> wrote:

> On 2004-08-10, Kevin Collins wrote: 
>
>    Actually, it may; it depends on the version of cron.
>
>    Some versions check every minute to see whether the crontab
>    directory has been modified; others only reload the files when they
>    are modified by crontab.

OS X's cron does indeed do this.  It's in the cron(8) man page:

Additionally, cron checks each minute to see if its spool
directory's modtime (or the modtime on /etc/crontab) has changed,
and if it has, cron will then examine the modtime on all crontabs
and reload those which have changed.  Thus cron need not be
restarted whenever a crontab file is mod- ified.  Note that the
crontab(1) command updates the modtime of the spool directory
whenever it changes a crontab.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]