This looks all fine so far. In /home/admispconfig/ispconfig/tools/clamav/share/clamav are the antivirus databases. Maybe you should just try this: http://www.howtoforge.com/forums/showthread.php?t=12860 According to some benchmarks that I have read in the clamav mailing lists, the 0.90.x series of clamav takes much longer to scan a email and uses much more memory and resources when clamscan is used. They all recommend to switch to clamd instead until this is hopefully fixed in the next clamav releases.
I read this too, but I was curious to find out what the problem was. I just read that you released ISPConfig 2.2.13 with clamassassin 1.2.4. I will update to this release and see if the problem persists. If it does, I will switch to clamd. Thanks again for your help! Grtz, Arno.
The update to 2.2.13 went very smooth, thanks for that. I switched to clamd from debian sarge volatile repo and now everything is fine . But the "problem" with clamscan remains. Still curious, I tried a clamscan binary from debian sarge (volatile repository) on another server: server2:~# /usr/bin/clamscan --debug /tmp/ LibClamAV debug: Initializing the engine (0.90.2) LibClamAV debug: cli_loaddbdir: Acquiring dbdir lock LibClamAV debug: Loading databases from /var/lib/clamav/ LibClamAV debug: in cli_cvdload() LibClamAV debug: MD5(.tar.gz) = 3e37be3e4f9f91af1051d70e45078bb0 LibClamAV debug: cli_versig: Decoded signature: 3e37be3e4f9f91af1051d70e45078bb0 LibClamAV debug: cli_versig: Digital signature is correct. LibClamAV debug: in cli_untgz() LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/COPYING LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.db LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.hdb LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.ndb LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.zmd LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.fp LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.mdb LibClamAV debug: Unpacking /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.info LibClamAV debug: cli_loaddbdir: Acquiring dbdir lock LibClamAV debug: Loading databases from /tmp/clamav-3c4971bc57d22df681cc975030d56584 ... LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.db loaded LibClamAV debug: Initializing md5 list structure LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.hdb loaded LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.ndb loaded LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.zmd loaded LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.fp loaded LibClamAV debug: /tmp/clamav-3c4971bc57d22df681cc975030d56584/main.mdb loaded LibClamAV debug: Dynamic engine configuration settings: LibClamAV debug: -------------------------------------- ... LibClamAV debug: /var/lib/clamav//main.cvd loaded LibClamAV debug: in cli_cvdload() LibClamAV debug: MD5(.tar.gz) = aa4b063db525c529b83a795be39ccb30 LibClamAV debug: cli_versig: Decoded signature: aa4b063db525c529b83a795be39ccb30 LibClamAV debug: cli_versig: Digital signature is correct. LibClamAV debug: in cli_untgz() LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/COPYING LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.db LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.hdb LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.ndb LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.zmd LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.fp LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.mdb LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.info LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.wdb LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.pdb LibClamAV debug: Unpacking /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.cfg LibClamAV debug: cli_loaddbdir: Acquiring dbdir lock LibClamAV debug: Loading databases from /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4 LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.db loaded LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.hdb loaded LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.ndb loaded LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.zmd loaded LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.fp loaded LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.mdb loaded LibClamAV debug: /tmp/clamav-ebd415eb493caebad5796a7d8e4761d4/daily.cfg loaded ... ----------- SCAN SUMMARY ----------- Known viruses: 117716 Engine version: 0.90.2 Scanned directories: 1 Scanned files: 0 Infected files: 0 Data scanned: 0.00 MB Time: 26.755 sec (0 m 26 s) It seems to me that clamscan is always using the /tmp directory to store an unpacked version of the main clamav database. After scanning, these files are removed unless the user hasn't enough space (due to quota limits). Isn't it a good idea to use clamdscan in ISPConfig instead of clamscan? As you mentioned, it is much faster indeed. And nobody would have the quota problem anymore. Tnx, Arno
Yes, thats my idea too. The main problem is to find a way to not break any old installations and every linux distribution has its spamd in another location so we will have to deliver and run a own spamd as we currently deliver the clamscan binary. The behaviour that clamscan unpacks the files in temp instead of using a central database must have been introduced with version 0.90 as we never had these problems with the 0.88 versions.
Well, thanks again for your replies, it forced me to dig deeper and learn . Please let me know if I can help in some way. Grtz, Arno.
Mmmmm --- wish I knew this before the upgrade. At least I would have been prepared. Is there some way to exclude the files form the users usages calcs? At least it not a misconfiguration. thanks for the info.
If your /tmp directory is a separate partition, then you might disable quota for this partition.Otherweise I recommend to use clamd instaed.
I can delete clamav files in users tmp? After 2.2.21 update I've a lot of clamav files in user tmp directories. With 2.2.21 IPSConfig version the new clamav files are in /home/admispconfig/ispconfig/tools/clamav/share/clamav/ Is safe to delete clamav files in users tmp directories? Thanks! Regards.
You can safely delete them, but it won't solve your problem. As mentioned before use a separate /tmp directory without quota or switch to clamd instead. Take a look at this: http://www.howtoforge.com/forums/showthread.php?t=16204 Good luck!
