How can I upgrade ClamAV?

Hi,

I have a server installed with Debian 5 with ClamAV 0.94.2. On another server, with Debian 6, I have version 0.97. Is it possible to upgrade the first one to 0.97 ? And if so, how ? If I just to apt update, it tells me I have the latest version.

Status: 
Closed (fixed)

Comments

Well; I have checked that but I am afraid I don't quite understand "enabling the debian volatile repository", and it looks even more complicated now that Debian 6 is out.

Furthermore, I have another installation with Debian 5 and the same ClamAV version, but on this one, Virtualmin does not not give me the message ".. your system is not ready for use by Virtualmin." while I check the configuration.

Here I have the following message :

The ClamAV program clamscan does not appear to be working properly :

LibClamAV Warning: *********************************************************** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *********************************************************** LibClamAV Warning: *********************************************************** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *********************************************************** LibClamAV Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life! Please upgrade to version 0.95 or later. For more information see www.clamav.net/eol-clamav-094 and www.clamav.net/download (length: 169) LibClamAV Error: Problem parsing database at line 61441 LibClamAV Error: Can't load /tmp/clamav-265907b21d6b9456482d1d539a5c9595/main.ndb: Malformed database LibClamAV Error: Can't load /var/lib/clamav//main.cvd: Malformed database ERROR: Malformed database

It may only be a database problem that can be fixed, though it is probably best to upgrade altogether.

Well; I have checked that but I am afraid I don't quite understand "enabling the debian volatile repository", and it looks even more complicated now that Debian 6 is out.

Furthermore, I have another installation with Debian 5 and the same ClamAV version, but on this one, Virtualmin does not not give me the message ".. your system is not ready for use by Virtualmin." while I check the configuration.

Here I have the following message :

The ClamAV program clamscan does not appear to be working properly :

LibClamAV Warning: *********************************************************** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *********************************************************** LibClamAV Warning: *********************************************************** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *********************************************************** LibClamAV Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life! Please upgrade to version 0.95 or later. For more information see www.clamav.net/eol-clamav-094 and www.clamav.net/download (length: 169) LibClamAV Error: Problem parsing database at line 61441 LibClamAV Error: Can't load /tmp/clamav-265907b21d6b9456482d1d539a5c9595/main.ndb: Malformed database LibClamAV Error: Can't load /var/lib/clamav//main.cvd: Malformed database ERROR: Malformed database

It may only be a database problem that can be fixed, though it is probably best to upgrade altogether.

Try adding a line like this to your /etc/apt/sources.list file on your Lenny server:

deb http://volatile.debian.org/debian-volatile lenny/volatile main

After that, try running 'apt-get update && apt-get upgrade', and see if that offers to upgrade ClamAV for you.

Thank you, I was able to update that way, but I guess I have to restart something to have the update taken in account (in the information panel, Virtualmin still says it has the old version). Is it the whole server ?

You will need to click the "Refresh system information" link in the top right for Virtualmin to detect the new version..

I started by that, but there is no change.

This is what the installation told me :

Preparing to replace clamav-docs 0.94.dfsg.2-1lenny2 (using .../clamav-docs_0.97+dfsg-2~lenny1_all.deb) ... Unpacking replacement clamav-docs ... Preparing to replace clamav-testfiles 0.94.dfsg.2-1lenny2 (using .../clamav-testfiles_0.97+dfsg-2~lenny1_all.deb) ... Unpacking replacement clamav-testfiles ... Setting up clamav-docs (0.97+dfsg-2~lenny1) ... Setting up clamav-testfiles (0.97+dfsg-2~lenny1) ...

But the Virtualmin panel doesn't want to know :

Known viruses: 859624 Engine version: 0.94.2 Scanned directories: 0 Scanned files: 0 Infected files: 0 Data scanned: 0.00 MB Time: 3.459 sec (0 m 3 s)

OK. I restarted the server on one of the installation, and that triggered the installation of additional clamAV packages. Now the version shown is the right on (0.97), but the quotas are gone! They all indicate 0% (fortunately the virtual servers are still there!). The "Refresh system information' link does not help.

Is that server by chance a VPS? Do you know what kind of VPS?

Also, what does the command "mount" output?

The outout of mount is :

/dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) afp_22Gk8M000bdk0000oM0000VU-1.2d000003 on /Volumes/jfq (afpfs, nodev, nosuid, mounted by jean-francoisquestiaux)

The server is on a cloud hosting using XEN technology.

Hmm, did you by chance run that mount command on your desktop rather than your server?

That output is what I'd expect to see in an Apple-based computer, rather than a Debian one :-)

Oups. Didn't notice the session has timed out.

Actual output is : /dev/xvda1 on / type ext3 (rw,noatime,grpquota,errors=remount-ro,usrquota) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) tmpfs on /var/gandi type tmpfs (rw,relatime,size=24k,mode=755) /dev/xvda1 on /srv/DEBIAN5_64 type ext3 (rw,nosuid,nodev,noatime)

If you run the command repquota -v -g / on your system, do quotas get shown?

The problem may be that Virtualmin just isn't picking up active quotas ..

Also, where are you seeing the 0% exactly?

Your last command gave this :

*** Report for group quotas on device /dev/xvda1 Block grace time: 7days; Inode grace time: 7days Block limits File limits

Group used soft hard grace used soft hard grace

root -- 1404020 0 0 72810 0 0
bin -- 71048 0 0 3815 0 0
adm -- 25976 0 0 200 0 0
tty -- 24 0 0 15 0 0
disk -- 0 0 0 25 0 0
mail -- 136 0 0 23 0 0
kmem -- 0 0 0 3 0 0
audio -- 0 0 0 33 0 0
www-data -- 4536 0 0 172 0 0
list -- 34368 0 0 2169 0 0
src -- 4 0 0 1 0 0
shadow -- 132 0 0 7 0 0
utmp -- 28 0 0 6 0 0
video -- 0 0 0 1 0 0
sasl -- 20 0 0 3 0 0
staff -- 112 0 0 29 0 0
nogroup -- 4 0 0 1 0 0
libuuid -- 40 0 0 3 0 0
ssh -- 104 0 0 1 0 0
admin -- 4 0 0 1 0 0
jfbetterlvingev -- 64 0 0 6 0 0
dovecot -- 12 0 0 4 0 0
ssl-cert -- 8 0 0 2 0 0
postfix -- 92 0 0 45 0 0
postdrop -- 40 0 0 9 0 0
mysql -- 21316 0 0 57 0 0
bind -- 36 0 0 9 0 0
clamav -- 33280 0 0 11 0 0
postgres -- 30080 0 0 453 0 0
eurov01 -- 728520 2097152 2097152 42929 0 0
eurov02 -- 329872 0 0 37423 0 0
eurov03 -- 465240 2097152 2097152 60417 0 0
eurov04 -- 428832 1048576 1048576 56744 0 0
eurov05 -- 177040 1048576 1048576 20453 0 0

1007 -- 0 1048576 1048576 0 0 0

Statistics: Total blocks: 9 Data blocks: 2 Entries: 35 Used average: 17.500000

but did not restore the quotas on Virtulamin panel (see picture attached).

So I presume those users like eurov01 are owners for domains like euro-vote.ch shown in your screenshot?

That's correct. It is 5 virtual servers on the main server. As a reminder, all this was working fine until I stopped and restart the server (from my hosting console). But I am quite sure I did it before without this consequence.

If you select one of those domains from the left menu and click Edit Virtual Server, what does it show for the disk quotas in the "Quotas and limits" section?

Actually, it shows a negative number! (see picture attached)

Is there any chance I could login to your system myself as root to see what is going wrong here?

That is possible. How do I proceed to communicate the details of the connexion?

I just sent you an email with the codes.

Ok, I see the issue .. and have fixed it.

Somehow the /dev/xvda1 partition was mounted on both / and /srv/DEBIAN5_64 according to the mount command, which is usually impossible! This confuses Virtualmin, as quotas are set by device rather than by mount point. When I un-mounted it from /srv/DEBIAN5_64 , all was OK.

Joe's picture
Submitted by Joe on Wed, 05/25/2011 - 14:54 Pro Licensee

It's perfectly valid to have multiple mount points for a device. Not common, but it shouldn't be a problem, either. (mount manpage says: "Since Linux 2.4 a single filesystem can be visible at multiple mount points, and multiple mounts can be stacked on the same mount point.")

Jamie, were the quota commands providing incorrect information or was Virtualmin processing them incorrectly?

Virtualmin was processing them wrong - basically, it needs to convert a device like /dev/xvda1 to a filesystem path like / , as all the quota commands work with devices. However this fails if the same device is mounted on multiple locations.

I have checked in a code fix to handle this better in the next Webmin release.. although it is surprising that multiple mounts of a disk-based filesystem are possible without using a loopback mount or something.

I must say, I am quite lost with trying to follow you guys, but thank you for fixing this issue.

Joe's picture
Submitted by Joe on Wed, 05/25/2011 - 20:36 Pro Licensee

No need to follow our little meta-discussion. We were just discussing how to avoid anyone else ever having this problem. Whenever it's possible to fix an issue by making Virtualmin (or Webmin) smarter, that's what we try to do.

Good policy. Glad I could help ... in my way.

Automatically closed -- issue fixed for 2 weeks with no activity.