Submitted by Brook on Wed, 07/15/2015 - 13:12
After going through the post install I get the error in the attached screen grab , I have tried it twice with CentOS 7 and I get the same error - however with Ubuntu 14.04 there is no error.
It is a clean CentOS 7 minimal install, and once after a yum upgrade and another time without.
It happens when I select 'Yes'.
Status:
Active
Comments
Submitted by andreychek on Wed, 07/15/2015 - 13:21 Comment #1
Howdy -- hmm, that is an unusual error! You can continue with the post-install process if you like though, then we can troubleshoot what the problem you're seeing is.
I'd be curious to see the contents of your scan.conf file that it's referring to... could you copy and paste the contents of that file into here? Thanks!
Submitted by Brook on Wed, 07/15/2015 - 17:17 Comment #2
Sure, here you go:
Submitted by andreychek on Wed, 07/15/2015 - 17:45 Comment #3
Ah, I think I see the issue -- it's this line here:
# Comment or remove the line below.
Example
If you comment out the line beginning with "Example", are you then able to start ClamAV?
Also, what is the output of this command:
rpm -qa | grep -i clam
Submitted by Brook on Wed, 07/15/2015 - 19:55 Comment #4
Doh, I should have seen that lol.
I won't actually be using it myself, just thought I'd post it as it was a new install and I figured you would want to fix it.
Submitted by andreychek on Thu, 07/16/2015 - 14:34 Comment #5
Gotcha, thanks for letting us know! I'm looking into this more now, as we certainly don't want that to occur on new systems.
And yeah, those look like the standard packages, so they may have changed the config so that it requires a tweak prior to working.
After commenting that out, does ClamAV appear to launch as expected?
Submitted by Brook on Sun, 07/19/2015 - 06:38 Comment #6
Hi Eric, yeah, it started up fine after that :)
Submitted by andreychek on Sun, 07/19/2015 - 19:30 Comment #7
I was just working with another user in IRC who saw this same problem with CentOS 7.
It just so happened that he had EPEL enabled as well.
He reinstalled, and this time around, disabled the EPEL repo -- and that resolved his issue.
It looks like having EPEL enabled will cause this problem -- the Virtualmin packages and EPEL packages are similar enough, that yum will pull in EPEL packages to replace those in the Virtualmin repository.
To fix his issue, but keep EPEL enabled, what we had him do was edit this file:
/etc/yum.repos.d/epel.repo
And in there, add this line:
exclude=clamav*
That line prevents the ClamAV packages from being pulled in from EPEL.
However, it would also work to disable it entirely.
Submitted by Brook on Sun, 07/19/2015 - 21:06 Comment #8
Thanks Eric :)
Submitted by Miker1029 on Tue, 11/22/2016 - 15:40 Comment #9
Hey All,
There is still a ClamAV error going one, Even With "
exclude=clamav*"
I started a comp0lete re-install of OS, and V-Min, It's still locking on ClamAv, Last time (the one before this) I was trying to Install PHP 7, Which Required /etc/yum.repos.d/epel.repo for the php 7 install it froze, Now I re-did the whole thing again without epel (or php7 attempt to install), running the base RHEL and virtualmin Repo's It's still freezing on it, this time I cloned the SDD before ANY updates to the system, And Now forced, again, to re-install Centos 7 Server and try to install vmin again....
EDIT:
Also After I had to CTRL-C the 1st install, and the 2nd, the 1st one I couldn't connect via https://site:10000 main reason for the re-install....
What's up with this, as I've been running V-min (GPL) for awhile now, and don't understand WHY this issue is still here..... It's been 2 or 3 Updates to vmin.....
Mike
Submitted by andreychek on Tue, 11/22/2016 - 16:24 Comment #10
Sorry to hear you're having some problems there! We unfortunately don't seem to be able to reproduce those though.
You may want to ensure that you have enough RAM; we've noticed that especially with newer 64 bit distros, that having 1GB or more can really help.
You can review the "dmesg | tail -30" output to see if there's any resources issues showing up there.
You appear to be seeing a different issue that the original poster here though... and it also looks like you're using Virtualmin GPL. The area here is for folks using Virtualmin Pro.
My suggestion would be to create a new Forum post, and there, post some details about the problem you're seeing, including whether this is a dedicated server or VPS, how much RAM and swap it has, along with the above "dmesg" output.
We monitor the Forums, along with lots of wonderful folks in the community, and hopefully we'll be able to sort out there what's going on with your server. Thanks!