Noel Jones wrote:
> At 12:59 PM 7/12/2007, John Rudd wrote:
> 
>>  From past discussion on this list, it was discussed "how easy" it would
>> be to throw together a script to check validity before putting a message
>> into production.  But I don't recall anyone ever actually offering up
>> their script.   Earlier today, someone had posted something to the
>> SpamAssassin list that showed they weren't properly handling downloaded
>> signature databases, and it just so happens that I just got around to
>> writing such a script the other day.
> 
> You must not be following the list very closely.  Such scripts have 
> been posted frequently and several good ones are available from 
> http://sanesecurity.co.uk/clamav/usage.htm

The last time I saw it come up on this list, I didn't see a script come 
back within a few days.  If it took longer than that, I probably was 
only skimming the list by then (my degree of "intently reading" vs 
"skimming" the list varies over time, but when there's a thread I 
consider important I try to keep up with it until it looks like the 
thread has petered out ... and the "download script with verification 
that the database is usable by clamav" is an important topic to me).

I saw the supporting material on sanesecurity's downloads page, but it 
looked like it was almost all windows oriented (ie. useless to me). 
Plus, I want one thing that I can apply to all 3rd parties, and I 
(perhaps incorrectly) assumed sanesecurity's stuff would be oriented 
just around their own stuff.


> Also, if you check the Sanesecurity usage page, you will note 
> "download signatures only when there have been changes", which your 
> script seems to ignore.   Use the wget -N option.
> 
> Also, it looks as if you are removing your tmp files every time the 
> script runs.  This causes rsync to download the whole file rather 
> than checking for changes, and makes it impossible for wget -N to work.

Yes, I am/was aware that I'm undermining rsync's bandwidth savings.  I 
just hadn't figured out the best way to address that.  I don't think 
that leaving it in /tmp/{something} works well for that.  I had been 
thinking about doing the scratch space in 
/usr/local/share/{something}/tmp, but wasn't sure if that would be 
standard enough.

I suppose I could put it under {clamavdbdir}/{source}/tmp


And, it was this types of reason I wanted to open it up for public scrutiny.


_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html

Reply via email to