Version 6.0.19 of virtualmin-config is in the repos. This is a very minor release to address a regression in the default config of the clamd@scan service on CentOS. I don’t know when it happened, but the upstream ClamAV server package lost a necessary configuration file change (LocalSocket was no longer being set by default), leading to clamd refusing to start on a fresh install. This update fixes that.
As an aside, I’ll also soon be submitting a pull request way upstream to the ClamAV project to where it’ll ship with a functioning config file out of the box; I’ve been told in communications with them that they’re open to shipping a functioning configuration, by default (which may be the most exciting news I’ve heard in weeks…the ClamAV broken-by-design default config files have been a minor but persistent pain in the ass for literally the entire history of packaging Virtualmin for easy installation).
Oh, and if you’re experiencing the problem where ClamAV won’t start on CentOS 7, do this:
# virtualmin config-system --include ClamAV
# systemctl restart clamd@scan
Just for clarification.
This version not appear when I do “yum update”, so I think it is only available for new installs, not for old installations previous to 6.0… Is this correct?
If you installed with any version of install.sh before 6 (any of the 1.0.x versions), you won’t have virtualmin-config at all, yet. There will come a time when I come up with a way to roll it out for everyone, as it does have some post-install usefulness, but I need to test it in those circumstances before I unleash it on anyone.
It may be useful to know that virtualmin-config is a re-factor and re-implementation mostly from scratch of what used to be in the virtualmin-base package, to make it modular and to make it callable as a virtualmin command. So, your old system has some form of what is now virtualmin-config, it just only got called during installation and isn’t re-usable at a later time. virtualmin-config is still primarily a post-installation tool, rather than a general configuration tool. But, because it is modular and because it can be called as a command, it allows me to roll out hotfixes to configuration and other stuff in an easy-to-use way.
Now, when I find there’s a bug in, say, the ProFTPd configuration after installation, I can roll a new virtualmin-config package and tell people what command to run, and it’ll fix it for them, without having to explain what files to edit or what to do to them. Since we have so many more users without command line experience running Virtualmin now, it’s becoming more and more important to automate even simple config changes for those users.
The other benefit of virtualmin-config over the old virtualmin-base is that users can pick and choose what they want to install/configure now, while being able to add others later. So, one can do a
--minimal install today, and if you decide in a month that you actually do need local mail handling, you can install the right yum group or metapackage and then use virtualmin-config to configure the extra components in the same way it would have been configured in a newly installed system.
I’m not leaving old installs out, I just don’t want to break anything for anyone with production systems by rolling things out prematurely.