This issue was resolved once I analyzed the 'behavior' of the download method,
and the person performing the 'testing' and 'debugging' of the process (me)...
The nightly download script, performs a WGET from db.local.clamav.net which I
assumed would update (only if there were a newer version of the file) the
individual DB files ('daily.cvd' being the most common one).
When the scheduled job executed, there was always an existing file to
overwrite, but when the 'tester' was debugging the process (to identify why the
downloaded file was 'corrupt') he would move the exiting file aside, to retain
it for comparison to the one manually downloaded, such that there wasn't a
file to 'overwrite'.
Once this difference was isolated, the WGET option of --continue became the
obvious suspect. Executing the 'strings' command on both the 'scheduled' file
and the manually downloaded version showed that the embedded 'date' values were
different, with the 'corrupt' version showing the date from a previous day (or
days). Its apparent that the --continue option to WGET attempts to 'append'
to the existing file, rather than replace a completed version.
The --continue option has since been removed from the command string within
the script, and every 'download' has since been successful...
--- On Wed, 8/8/12, Steve Brazill yu...@sbcglobal.net wrote:
From: Steve Brazill yu...@sbcglobal.net
Subject: Re: [clamav-users] Corrupt ClamAV virus DB files
To: ClamAV users ML clamav-users@lists.clamav.net
Date: Wednesday, August 8, 2012, 2:22 PM
--- On Wed, 8/8/12, Al Varnell alvarn...@mac.com wrote:
From: Al Varnell alvarn...@mac.com
Subject: Re: [clamav-users] Corrupt ClamAV virus DB files
To: ClamAV users ML clamav-users@lists.clamav.net
Date: Wednesday, August 8, 2012, 1:18 PM
On Aug 8, 2012, at 12:59 PM, Steve Brazill yu...@sbcglobal.net wrote:
Our firm has a scheduled replication of the ClamAV database files, which mor
e often than not, appear to be corrupt upon receipt.
Though this error message has been posted by others previously, I have not
seen a definitive answer/solution, and is usually discounted as an issue with 'b
ad memory'.
clamscan:
LibClamAV Error: Can't load /var/clamav/daily.cvd: Can't verify database i
ntegrity
ERROR: Can't verify database integrity
ERROR: Can't verify database integrity
The most recent example occurred today, with the daily version 15231 (3:45AM
aprox) being corrupt, but the subsequent release of 15232 (9AM aprox) being su
ccessful.
The replication process, which only retrieves updated files, is obtaining th
e daily file from:
http://db.local.clamav.net/daily.cvd
Are the multiple releases of the daily file due to actual updates to virus i
nstances, or identification of corrupt source files on the website ?
There are normally several incremental updates daily.
Since there are over 140 mirror servers world-wide and you would normally be r
otating to a different one of maybe half a dozen servers in your area, it could
be that the two databases came from different servers. It's important to identif
y the IP address of any server that is consistently corrupt.
Sent from Janet's iPad
-Al-
--
Al Varnell
Mountain View, CA, USA
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
That's an excellent point...
Looking at our SQUID proxy access logs, I have found the following:
194.47.250.218 soyuz.df.lth.se - did not work
78.46.84.244 mx02.akxnet.de - did not work
69.163.100.14 clamav.theshell.com - worked
168.143.19.95 clamav-du.viaverio.com - did not work
209.198.147.20 clamav.io-tx.com - worked
At first glance, it appears that 'non-Americas' servers have been selected from
the mirror pool which resulted in non-functioning DB files, except for the
instance using clamav-du which I cannot identify its geographic location.
I'll monitor the next couple of replications, to see if there is a pattern...
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
