[Clamav-users] Re: Chronic MD5 Verification Errors
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 prevented from going live, and hanging the mail system. Only verified good cvd files would be moved into the live data dir, and clam would never hang because of this failure. freshclam already downloads cvd files using a temporary name and verifies them before installing them. cdiff files on the other hand are only verified if freshclam was built to use the GNU GMP library, and cdiff updates are applied to the live incremental databases. If anything goes wrong, the incremental database is removed and the full database downloaded. The thing I'm not too sure about is what happens if clamd is told to reload the databases while freshclam is in the middle of updating them (for example, from a script that updates the third party databases from MSRBL and SaneSecurity). I think it would be possible for clamd to see the databases in an inconsistent state in that case and crap out. Conversely, freshclam could tell clamd to reload the databases while some third party database update script is updating the third party databases. But in that case it is possible to write the third party database script so that each database is replaced atomically at the file system level (by ensuring that the old database and (a copy of) the new database are on the same filesystem before the atomically moving the new one over the old one). 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. -- -=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Chronic MD5 Verification Errors
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, in that the problems I have are with the main and daily cvd files. I am not a scripter... Is there someway I could do the same with main.cvd and daily.cvd? Yes. But if you haven't already done it, first of all I would suggest that you enable LogVerbose in your freshclam.conf to see if that sheds any light on the problem. Also have a look around in your system logs, especially for things like bad disc accesses. (NB: I haven't tested the following armchair theories. :) If things didn't become clearer, I'd probably run another freshclam (perhaps from cron) which maintains a separate copy of the problem databases. These copies are simply files for your delight and aren't used by the scanner. This might help to eliminate conflicts with processes actually using the databases for scanning. Log verbosely for both real and copy databases, and inspect the logs carefully. If the copies don't suffer from the same problems, then the simplest thing might be to do something like this in the same cron job: /bin/rm -rf/var/lib/clamav_old/ /bin/mv /var/lib/clamav/ /var/lib/clamav_old/ /bin/mv /var/lib/clamav_copy/ /var/lib/clamav/ /bin/mkdir /var/lib/clamav_copy/ This moves all the files at the same instant. Any process which has files in /var/lib/clamav/ open at the time of the move will still have the same files open but they will then be in /var/lib/clamav_old. To get the processes to use the new files you have to either restart them or send them the appropriate signal. Don't forget that you'll need a full set of the files in the copy database, not just the ones you're having problems with, or the procedure will fail. You can be creative and only do the operations above if a test in a cron job or script succeeds. See the earlier thread for examples or look at a shell scripting tutorial. It's easy. Don't overlook the OnUpdateExecute and OnErrorExecute options in the config file. Of course the copy databases might suffer from the same problem, in which case I guess we'll be hearing from you again. And of course the simplest thing might not be the best thing. I think I'd want to know exactly what the problem is, and fix it. :) I agree from your description of other software that hardware is probably not to blame, but the fact that the problem has become worse is suspicious. Would it be silly to ask if you've checked that you're not running into swap? Tried adding some more ram? Did the deterioration coincide with something like installing your new kernel? -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
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) are these MD5 sum errors from clamav. The server has dual P4 Xeon 2.0 cpus, and 2 GB RAM. Load virtually never goes up over .50, except at night when the backups run (but no one is on and traffic is minimal) I did run the verbose freshclam logs for a time, but it gave me no useful information. I've just now turned it back on again, As for kernel, I'll give you the synopsis of how it went. Redhat 9.0 comes with a default kernel based on 2.4.20. This is the kernel the server was running until the mail server and backup were installed. Due to issues with the backup system, the kernel was upgraded to 2.4.31, Note: these clamav errors were happening under 2.4.20 already, although not nearly as frequently. After the upgrade to 2.4.31, the errors seem to have lessened (but not gone away.. maybe once a week instead of daily). Recently the errors were getting far more frequent (almost daily) so in an effort to resolve them, I upgraded to 2.4.33-4. Both 2.4.31 and 2.4.33-4 were compiled from vanilla sources, with the same config. Now, are there any special kernel options I should have enabled for clamav/freshclam that I can look into? Before upgrading to 2.4.33-4 I did a google search for that info, but came up with nil. Needless to say, the upgrade to 2.4.33-4 did nothing to correct the problem. Currently I've set the cron job for freshclam to only run once a day, to keep this from bringing the server down middday. Obviously this isn't a viable long term solution, but at least it will keep us running. I will try some of your suggestions below, but as you stated - I want to know *exactly* where the problem lies, and resolve it. On 12/13/06, G.W. Haywood [EMAIL PROTECTED] wrote: 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, in that the problems I have are with the main and daily cvd files. I am not a scripter... Is there someway I could do the same with main.cvd and daily.cvd? Yes. But if you haven't already done it, first of all I would suggest that you enable LogVerbose in your freshclam.conf to see if that sheds any light on the problem. Also have a look around in your system logs, especially for things like bad disc accesses. (NB: I haven't tested the following armchair theories. :) If things didn't become clearer, I'd probably run another freshclam (perhaps from cron) which maintains a separate copy of the problem databases. These copies are simply files for your delight and aren't used by the scanner. This might help to eliminate conflicts with processes actually using the databases for scanning. Log verbosely for both real and copy databases, and inspect the logs carefully. If the copies don't suffer from the same problems, then the simplest thing might be to do something like this in the same cron job: /bin/rm -rf/var/lib/clamav_old/ /bin/mv /var/lib/clamav/ /var/lib/clamav_old/ /bin/mv /var/lib/clamav_copy/ /var/lib/clamav/ /bin/mkdir /var/lib/clamav_copy/ This moves all the files at the same instant. Any process which has files in /var/lib/clamav/ open at the time of the move will still have the same files open but they will then be in /var/lib/clamav_old. To get the processes to use the new files you have to either restart them or send them the appropriate signal. Don't forget that you'll need a full set of the files in the copy database, not just the ones you're having problems with, or the procedure will fail. You can be creative and only do the operations above if a test in a cron job or script succeeds. See the earlier thread for examples or look at a shell scripting tutorial. It's easy. Don't overlook the OnUpdateExecute and OnErrorExecute options in the config file. Of course the copy databases might suffer from the same problem, in which case I guess we'll be hearing from you again. And of course the simplest thing might not be the best thing. I think I'd want to know exactly what the problem is, and fix it. :) I agree from your description of other software that hardware is probably not to blame, but the fact that the problem has become worse is suspicious. Would it be silly to ask if you've checked that you're not running into swap? Tried adding some more ram? Did the deterioration coincide with something like installing your new kernel? -- 73, Ged. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
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 looks like this: Wed Dec 13 06:05:04 2006 - SelfCheck: Database status OK. Wed Dec 13 06:28:57 2006 - Reading databases from /var/clamav Wed Dec 13 06:28:57 2006 - ERROR: reload db failed: MD5 verification error At this point mail is dead, and I have to delete the CVD files in /var/clamav and re-run freshclam to get new ones, then manually start clamav. All is well, until it happens again. The frustrating part is that it's so intermittent. It doesn't happen every time. It doesn't happen at a regular interval. It's completely random, with the exception that it will probably once a day - or once every 2nd day on the very high end. On 12/13/06, Ian Abbott [EMAIL PROTECTED] wrote: 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 prevented from going live, and hanging the mail system. Only verified good cvd files would be moved into the live data dir, and clam would never hang because of this failure. freshclam already downloads cvd files using a temporary name and verifies them before installing them. cdiff files on the other hand are only verified if freshclam was built to use the GNU GMP library, and cdiff updates are applied to the live incremental databases. If anything goes wrong, the incremental database is removed and the full database downloaded. The thing I'm not too sure about is what happens if clamd is told to reload the databases while freshclam is in the middle of updating them (for example, from a script that updates the third party databases from MSRBL and SaneSecurity). I think it would be possible for clamd to see the databases in an inconsistent state in that case and crap out. Conversely, freshclam could tell clamd to reload the databases while some third party database update script is updating the third party databases. But in that case it is possible to write the third party database script so that each database is replaced atomically at the file system level (by ensuring that the old database and (a copy of) the new database are on the same filesystem before the atomically moving the new one over the old one). 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. -- -=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Packages for Solaris 10 64-bit available.
I keep being asked for Solaris 10 packages over email, so... The 64-bit Solaris ClamAV packages site (http://clamav.citrus-it.net/) now has packages for Solaris 10 as well as Solaris 9. If you have any problems with these packages, please report them to [EMAIL PROTECTED] and not this list or the ClamAV team! Andy PS: Could a member of the ClamAV team update the Binary Packages page on clamav.net to include Solaris 10 in the link to this site? ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Forcing clamd to reload its database
On Mon, Dec 11, 2006 at 07:43:43AM -0800, Dennis Peterson wrote: Gerard Seibert wrote: What is the preferred method to force clamd to reload its databases? Try using kill -1 with the process ID of clamd. That reopens the logfile. You'll have to send it a SIGUSR2, according to the documentation. kill -USR2 `cat /path/to/clamd.pid` -- Jan-Pieter Cornet [EMAIL PROTECTED] !! Disclamer: The addressee of this email is not the intended recipient. !! !! This is only a test of the echelon and data retention systems. Please !! !! archive this message indefinitely to allow verification of the logs. !! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
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, would it be possible to modify freshclam so that when databases are downloaded, it puts them in a tmp dir, runs the MD5 check, and if it fails, NOT move them into the database directory, not notify CLAMD and deletes the files? Basically what I want to do is check to see if there are new databases if so, download to /tmp/clamtmp (for example) MD5 verify the new download in /tmp/clamtmp If good, move into the proper database dir and notify clamd (default behaviour for me). If bad, do nothing but delete the corrupt cvd. This process would then repeat itself the next time freshclam runs. This way I could ensure only GOOD .cvd files get set up, and clamav won't die on me regularly Thanks for the help... I got the same error, except Freshclam retried... main.cvd is up to date (version: 41, sigs: 73809, f-level: 10, builder: tkojm) nonblock_recv: recv timing out (30 secs) ERROR: Verification: MD5 verification error Trying again in 5 secs... ClamAV update process started at Wed Dec 13 10:51:38 2006 main.cvd is up to date (version: 41, sigs: 73809, f-level: 10, builder: tkojm) WARNING: Mirror 206.154.202.213 is not synchronized. Trying again in 5 secs... ClamAV update process started at Wed Dec 13 10:53:22 2006 main.cvd is up to date (version: 41, sigs: 73809, f-level: 10, builder: tkojm) daily.cvd updated (version: 2322, sigs: 7173, f-level: 9, builder: ccordes) Database updated (80982 signatures) from db.us.clamav.net (IP: 208.67.80.27) Clamd successfully notified about the update. Does your's try again? -- Thanks, James ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
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 database directory? This way a corrupt/bad database could be prevented from going live, and hanging the mail system. Only verified good cvd files would be moved into the live data dir, and clam would never hang because of this failure. freshclam already downloads cvd files using a temporary name and verifies them before installing them. cdiff files on the other hand are only verified if freshclam was built to use the GNU GMP library, and cdiff updates are applied to the live incremental databases. If anything goes wrong, the incremental database is removed and the full database downloaded. The thing I'm not too sure about is what happens if clamd is told to reload the databases while freshclam is in the middle of updating them (for example, from a script that updates the third party databases from MSRBL and SaneSecurity). I think it would be possible for clamd to see the databases in an inconsistent state in that case and crap out. Conversely, freshclam could tell clamd to reload the databases while some third party database update script is updating the third party databases. But in that case it is possible to write the third party database script so that each database is replaced atomically at the file system level (by ensuring that the old database and (a copy of) the new database are on the same filesystem before the atomically moving the new one over the old one). 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 freshclam daemon) I check for new files, if new then download and test the any new SaneSecurity and MSRBL signature files, then run freshclam. Work well here. Bill ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] Re: Chronic MD5 Verification Errors
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 that makes me rule out disk I/O is that this is the only error on the whole system. There is a decent amount of data (40GB or so shared via samba) on this same array, which gets a lot of traffic - but no errors in the logs, no performance issues, nada. All is well there. If this were a disk issue, I'd think we'd be having a lot more problems on that side than on the clamav side. On 12/13/06, Ian Abbott [EMAIL PROTECTED] wrote: What normally happens during the self-check is that the database directory entries are read, but the files in the database directory are not reloaded unless the directory entries have changed. This means that the SelfCheck: Database status OK. message does not mean the database files were read okay, rather they weren't read at all. May I suggest a minor code change for diagnostic purposes? In clamd/server-th.c, look for the lines: logg(SelfCheck: Database status OK.\n); return NULL; and change them to: #if 0 /* original */ logg(SelfCheck: Database status OK.\n); return NULL; #else /* temporary test */ logg(SelfCheck: Database status OK. Reloading anyway.\n); return root; #endif This will force the self-check to reload the database files even if nothing has changed. Then if you get MD5 errors randomly after this message in the logs, you'll know it has nothing to do with freshclam, and more to do with random disk read/write errors. Have you tried replacing the HD cable? You never mentioned it. Certainly for P-ATA disks, don't expect much in the way of error detection unless Ultra DMA mode is being used (and even then, CRC error checking is only performed for data packets, not for command and status packets). It's unlikely to be a problem for S-ATA disks though. -- -=( Ian Abbott @ MEV Ltd.E-mail: [EMAIL PROTECTED])=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] 0.88.7 possible error
Yesterday I installed 0.88.7 on our server running RHESL-4 using the rpms from DAG, previously using 0.88.6. Our LogWatch file this morning shows: **Unmatched Entries** clamd shutdown succeeded clamd shutdown failed clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) Bound to address 127.0.0.1 on port 3310 Portable Executable support enabled. Detection of broken executables enabled. clamd startup succeeded Mail: Recursion level limit set to 64. HTML support enabled. clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) bind() error: Address already in use Is there a problem here somewhere? Thanks ___ Robert Isaac Director/Web Admin Volvo Owners Club ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] 0.88.7 possible error
Robert Isaac wrote: Yesterday I installed 0.88.7 on our server running RHESL-4 using the rpms from DAG, previously using 0.88.6. Our LogWatch file this morning shows: **Unmatched Entries** clamd shutdown succeeded clamd shutdown failed clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) Bound to address 127.0.0.1 on port 3310 Portable Executable support enabled. Detection of broken executables enabled. clamd startup succeeded Mail: Recursion level limit set to 64. HTML support enabled. clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) bind() error: Address already in use Is there a problem here somewhere? Thanks ___ Robert Isaac Director/Web Admin Volvo Owners Club Did you stop the old clamd server before starting the new one? Steve ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] 0.88.7 possible error
[EMAIL PROTECTED] wrote: Robert Isaac wrote: Yesterday I installed 0.88.7 on our server running RHESL-4 using the rpms from DAG, previously using 0.88.6. Our LogWatch file this morning shows: **Unmatched Entries** clamd shutdown succeeded clamd shutdown failed Oops, look at that, it didnt shutdown. clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) Bound to address 127.0.0.1 on port 3310 Portable Executable support enabled. Detection of broken executables enabled. clamd startup succeeded Mail: Recursion level limit set to 64. HTML support enabled. clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) bind() error: Address already in use Of course the address is already in use. Clamd is still running. -Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
RE: [Clamav-users] 0.88.7 possible error
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 13 December 2006 18:55 To: ClamAV users ML Subject: Re: [Clamav-users] 0.88.7 possible error Robert Isaac wrote: Yesterday I installed 0.88.7 on our server running RHESL-4 using the rpms from DAG, previously using 0.88.6. Our LogWatch file this morning shows: **Unmatched Entries** clamd shutdown succeeded clamd shutdown failed clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) Bound to address 127.0.0.1 on port 3310 Portable Executable support enabled. Detection of broken executables enabled. clamd startup succeeded Mail: Recursion level limit set to 64. HTML support enabled. clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) bind() error: Address already in use Is there a problem here somewhere? Thanks Did you stop the old clamd server before starting the new one? Steve ___ No I didn't. Ooops. What should I do now? Bob ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] ClamAV error with cli_untgz
Dear all, I have a debian etch + postfix + spamassassin + clamav system, but when I run /etc/init.d/clamav-daemon start I get this error mesage and the daemon doesn't start at all: LibClamAV Error: wrote 0 instead of 512 (/tmp/clamav-67ea3a8be7a9faa9/main.ndb) cli_untgz: no space left on device LibClamAV error: cli_cvload (): can't unpack CVD file LibClamAV error: Can't load /var/lib clamav main.cvd: CVD extraction failure ERROR: CVD extarction failure My / fie system (when I suppose will be installed de CVD file) has 65MB free...is it enough ??? Or where will main.cvd file installed in order to make a new file partition and mount it in this place ??? What's wrong on my system Really thanks, Alejandro ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] 0.88.7 possible error
Robert Isaac wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 13 December 2006 18:55 To: ClamAV users ML Subject: Re: [Clamav-users] 0.88.7 possible error Robert Isaac wrote: Yesterday I installed 0.88.7 on our server running RHESL-4 using the rpms from DAG, previously using 0.88.6. Our LogWatch file this morning shows: **Unmatched Entries** clamd shutdown succeeded clamd shutdown failed clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) Bound to address 127.0.0.1 on port 3310 Portable Executable support enabled. Detection of broken executables enabled. clamd startup succeeded Mail: Recursion level limit set to 64. HTML support enabled. clamd daemon 0.88.7 (OS: linux-gnu, ARCH: i386, CPU: i386) bind() error: Address already in use Is there a problem here somewhere? Thanks Did you stop the old clamd server before starting the new one? Steve ___ No I didn't. Ooops. What should I do now? Bob Just kill all instances of clamd and then start up clamd again. Steve ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Double notification emails
Hi, I have configured Clamav to send me a email notice when it the definitions update. Yesterday I started receiving 2 of them which appear identical. Why is this happening and how can I turn it off? Using clamav-0.90RC1.1.tar.gz This from the log: I checked the FAQ but saw nothing. Thanks. Craig ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Double notification when Defs update
Hi, Sorry about the double post but I accidently hit control return before I was finished. I have configured Clamav to send me a email notice when it the definitions update. Yesterday I started receiving 2 of them which appear identical. Why is this happening and how can I turn it off? Using clamav-0.90RC1.1.tar.gz This from the log: WARNING: Your ClamAV installation is OUTDATED! WARNING: Local version: 0.90RC1.1 Recommended version: 0.88.7 I checked the FAQ but saw nothing. I don't want to upgrade anything and I don't want double notices. Thanks. Craig ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] ClamAV error with cli_untgz
On Wed, Dec 13, 2006 at 05:42:50PM -0300, Alejandro said: Dear all, I have a debian etch + postfix + spamassassin + clamav system, but when I run /etc/init.d/clamav-daemon start I get this error mesage and the daemon doesn't start at all: LibClamAV Error: wrote 0 instead of 512 (/tmp/clamav-67ea3a8be7a9faa9/main.ndb) cli_untgz: no space left on device LibClamAV error: cli_cvload (): can't unpack CVD file LibClamAV error: Can't load /var/lib clamav main.cvd: CVD extraction failure ERROR: CVD extarction failure My / fie system (when I suppose will be installed de CVD file) has 65MB free...is it enough ??? Or where will main.cvd file installed in order to make a new file partition and mount it in this place ??? What's wrong on my system Whatever partition TemporaryDirectory points to is almost full. Repoint it. -- -- | Stephen Gran | Humor in the Court: Q: Could you see| | [EMAIL PROTECTED] | him from where you were standing? A: I | | http://www.lobefin.net/~steve | could see his head. Q: And where was| || his head? A: Just above his shoulders. | -- signature.asc Description: Digital signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Protection from W32.Sality.U
hi I am getting few emails which are passing thru clamav. Norton says the email is infected with W32.Sality.U Is there an update for clamav which can protect me from W32.Sality.U? I am using 0.88.7 -- -- B.G. Mahesh http://www.greynium.com/ http://www.oneindia.in/ http://www.click.in/ - Free Indian Classifieds ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
