Chuck Swiger wrote:
Bill Landry wrote:
[ ... ]
You are preaching to the choir here, as you have no argument from me. I
raised the same issue the last time this happened to me a few weeks ago
and clamd died twice on me in one day. The script work-around to check
the databases before implementing them has saved my bacon with this last
string of corrupted databases from MSRBL. However, I still agree that
clamd should be able to handle these kinds of issues gracefully, and in
the alternative, should not simply die silently.
Agreed-- it would be nice if clamd was more robust, either by continuing
to run with the other DBs (as available) and either drop the bad line or
the entire bad DB file, until a new update comes along which is OK.
However, improving how clamd responds to a bad DB is solving a
consequence or symptom rather than the original problem. Maybe we
should try to persuade the MSRBL site (and others) to use a similar
checking script when pushing new versions of the DB's out, rather than
checking upon receipt after people have used bandwidth to download and
then have to discard a bad update...?
Qual checking the db is not unreasonable given it can be done with
automation, but it doesn't protect you from delivery failures where you
get a partial db. Without a checksum you are still on the hook to qual
check the tranfer.
dp
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html
