>i'm deploying clamscan in a RH9 box, i downloaded version 0.60,
compiled
>and installed, and i'm running freshclam periodically. Then i clamscanned
my
>virus archive. There were just four viruses not found, out of ~2200, three
>of them were Fortnight.js. I sent those to [EMAIL PROTECTED] .
>Bu
> Do you have any idea I use clamav 0.60 redhat 9 avery think is ok but
clamav
> can't register with dazuko
>
> @vorbe dazuko-1.2.1-pre2]# ./example
> registered with Dazuko successfully
> set access mask successfully
> set scan path successfully
>
> @vorbe dazuko-1.2.1-pre2]# lsmod
> Module
Hi Tomasz,
Thanks, for the clarification on how freshclam works.
Ted
--On Tuesday, July 01, 2003 7:50 PM +0200 Tomasz Kojm <[EMAIL PROTECTED]>
wrote:
Hi all,
A simple solution to the database checksum failure might be as simple as
changing the download procedure to:
* check for new databases
> Looks like freshclam hung up again today. Just noticed it now, looks
> like it hung up around 11am this morning. What is happening is that I
> have two processes that "stick". One for MailScanner's update virus
> scanners script, and the other is the freshclam program. The problem is
> that w
> Do you have any idea I use clamav 0.60 redhat 9 avery think is ok but clamav
> can't register with dazuko
>
> @vorbe dazuko-1.2.1-pre2]# ./example
> registered with Dazuko successfully
> set access mask successfully
> set scan path successfully
Probably the daemon is running as a normal user -
> Hi all,
>
> A simple solution to the database checksum failure might be as simple as
> changing the download procedure to:
>
> * check for new databases
> * if database is new, download it TO A TEMP FILE
> * perform checksum on temp file
> * Good checksum -> install
> * Bad checksum -> log pro
While having a more robust client side to downloading the databases is a
good idea, I think the server side should be more robust too.
Why doesn't the file get uploaded to a temporary filename and then moved
to the real filename? Unix file semantics guarantee this is atomic.
JE
On Tue, Jul 01, 2
Hi all,
A simple solution to the database checksum failure might be as simple as
changing the download procedure to:
* check for new databases
* if database is new, download it TO A TEMP FILE
* perform checksum on temp file
* Good checksum -> install
* Bad checksum -> log problem, continue with
ok, re-run it on my local machine and it worked fine. But it means my
customers' systems will all be a day behind, as they all download at the
same time (mmm - perhaps that is not a good idea).
I am not 100% happy with the situation that if a download catches an
upload, then we get a failure.
It seems that you tried to download new db while I was uploading new
database.
Just run fresclam again.
Best regards,
Diego d'Ambra
-Original Message-
From: Brian Read [mailto:[EMAIL PROTECTED]
Sent: 1. juli 2003 13:19
To: [EMAIL PROTECTED]
Subject: [clamav-users] checksum failure again
My daily update has just failed with this:
Current working dir is /usr/share/clamav
Checking for a new database - started at Tue Jul 1 12:00:01 2003
Connected to clamav.elektrapro.com.
Reading md5 sum (viruses.md5): OK
Reading md5 sum (viruses2.md5): OK
Downloading viruses.db
...
I had a similar problem with the latest version on Clamav when I
installed it a few days or was it a week or so ago. What I did was to
turf the DB files (both actually) and then re-download these from the
Clamav site and make sure that the sigs match with the ones provided on
the site and after th
> -Original Message-
> From: Support ePaxsys/FRWS [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 30, 2003 6:54 PM
> To: [EMAIL PROTECTED]
> Subject: [clamav-users] Semi-Newbie question about DB updating
>
>
> Hey Great Product
>
> Couple things keep me awake nights (sorta)
>
> Usi
13 matches
Mail list logo