-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 17, 2007 at 10:54:53AM -0500, Edward Dam wrote:
>Tue Jan 16 22:40:09 2007 -> SelfCheck: Database status OK. Reloading
>anyway.
>Tue Jan 16 22:40:09 2007 -> Reading databases from /var/clamav
>Tue Jan 16 22:40:09 2007 ->
>/var/spool/qmails
On 1/17/07, Stephen Gran <[EMAIL PROTECTED]> wrote:
On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam said:
> On 1/2/07, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >On 20/12/06 16:49, Edward Dam wrote:
> >> On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >>>
> >>> #if 0 /* original */
> >>>
On Wed, 17 Jan 2007 08:49:14 -0500
"Edward Dam" <[EMAIL PROTECTED]> wrote:
> Thanks everyone, for the replies and help.
>
> At this point, I am doing the only thing I can - removing clamav from the
> system, and using a mail security hardware device in front of the mail
> server.
>
> ClamAV is t
On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam said:
> On 1/2/07, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >On 20/12/06 16:49, Edward Dam wrote:
> >> On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
> >>>
> >>> #if 0 /* original */
> >>> logg("SelfCheck: Database status OK.\n");
On 1/17/07, Todd Lyons <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam wrote:
>Thanks again for all your help. Maybe once clamAV matures, it will be a
>better fit for my needs, but until then I need to remove it, as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 17, 2007 at 08:49:14AM -0500, Edward Dam wrote:
>Thanks again for all your help. Maybe once clamAV matures, it will be a
>better fit for my needs, but until then I need to remove it, as it's the
>cause of my headaches.
I would disagree on
On 1/2/07, Ian Abbott <[EMAIL PROTECTED]> wrote:
On 20/12/06 16:49, Edward Dam wrote:
> On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
>>
>> On 13/12/06 14:28, Edward Dam wrote:
>> > Hi Ian,
>> >
>> > Thanks for the help.
>> >
>> > I've only got the main.cvd and daily.cvd databases in use ri
On 20/12/06 16:49, Edward Dam wrote:
On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
On 13/12/06 14:28, Edward Dam wrote:
> Hi Ian,
>
> Thanks for the help.
>
> I've only got the main.cvd and daily.cvd databases in use right now,
> until I
> get this sorted out - so it's not a 3rd party db o
On Wednesday 13 December 2006 11:37 am, Bill Landry wrote:
> > To avoid these problems, freshclam and the third party update scripts
> > could be run sequentially from a single cron job, rather than running
> > freshclam as a daemon.
>
> This is exactly what I do. Via cron.hourly (rather than fre
On 12/13/06, Ian Abbott <[EMAIL PROTECTED]> wrote:
On 13/12/06 14:28, Edward Dam wrote:
> Hi Ian,
>
> Thanks for the help.
>
> I've only got the main.cvd and daily.cvd databases in use right now,
> until I
> get this sorted out - so it's not a 3rd party db or script issue.
>
> Here's basically w
Hi Ian,
Thanks again. I will make the modifications to the server-th.c file and let
you know.
As far as the HD cable goes, this is a server with 3 x 36GB 10,000 RPM SCSI
drives in RAID 5 on an adaptec 2120s raid controller. (at the latest bios
revision.. yep, tried that as well).
The thing tha
On 13/12/06 14:28, Edward Dam wrote:
Hi Ian,
Thanks for the help.
I've only got the main.cvd and daily.cvd databases in use right now,
until I
get this sorted out - so it's not a 3rd party db or script issue.
Here's basically what happens.
Freshclam downloads the updates, then notifes clamd
Ian Abbott wrote the following on 12/13/2006 2:42 AM -0800:
On 12/12/2006 19:44, Edward Dam wrote:
Just to expand on this thought a bit.
Shouldn't something like this be the default behaviour? To download
the CVD
files to a temp location, and run the MD5 there before moving it into
the
live
Edward Dam wrote:
Thanks for the pointer.
It's similar, but not quite the same, in that the problems I have are with
the main and daily cvd files. I am not a scripter by any stretch of the
imagination, but..
Is there someway I could do the same with main.cvd and daily.cvd? What I
mean is, woul
Hi Ian,
Thanks for the help.
I've only got the main.cvd and daily.cvd databases in use right now, until I
get this sorted out - so it's not a 3rd party db or script issue.
Here's basically what happens.
Freshclam downloads the updates, then notifes clamd to re-read the
databases. Then my log l
Thanks again for the replies.
Disc I/0 and access are trouble free. They also have a samba file share on
this server and it shows no errors with read/writes either (both are on the
same RAID5 array). The only errors in any of the logs I can find (maillog,
messages, clamd, freshclam, dmesg, etc)
Hi there,
On Tue-Wed, 12-13 Dec 2006 Edward Dam wrote:
> > > Intermittently, freshclam would die with an MD5 verification error
> >
> > Does this very recent thread help at all?
> > Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect:...
>
> It's similar, but not quite the same,
On 12/12/2006 19:44, Edward Dam wrote:
Just to expand on this thought a bit.
Shouldn't something like this be the default behaviour? To download the CVD
files to a temp location, and run the MD5 there before moving it into the
live database directory?
This way a corrupt/bad database could be pr
Just to expand on this thought a bit.
Shouldn't something like this be the default behaviour? To download the CVD
files to a temp location, and run the MD5 there before moving it into the
live database directory?
This way a corrupt/bad database could be prevented from going live, and
hanging the
Thanks for the pointer.
It's similar, but not quite the same, in that the problems I have are with
the main and daily cvd files. I am not a scripter by any stretch of the
imagination, but..
Is there someway I could do the same with main.cvd and daily.cvd? What I
mean is, would it be possible to
Hi there,
On Tue, 12 Dec 2006 Edward Dam wrote:
> Intermittently, freshclam would die with an MD5 verification error
Does this very recent thread help at all?
Error (Cannot connect to 'localhost:3310': IO::Socket::INET: connect:
Connection refused )
--
73,
Ged.
__
21 matches
Mail list logo