At the very least, when the config file and options change, the ClamAV team should post a notice which explicitly lists (and only lists):
1) new config items 2) removed config items 3) config items whose syntax, semantics, or options changed, and how 4) supported but deprecated items, and what, if anything, replaced them This shouldn't just be buried in release notes, a read me file, or a change log. It should be in those places _TOO_, but it should also exist as its own stand-alone statement that any one of us can easily see and find. And what they REALLY ought to do is supply a tool which reads old config files, and does something like a lint check. With multiple verbosity level options, it should read the existing config file, and say things like "which lines have errors", "what's wrong with this line", "what parts of that line are no longer supported", and if possible give the new/current syntax for the line in question. In the most trivial case, you should be able to invoke: clamavcfgcompiler -o oldconfigfile -n newconfigfile and it will generate the new config if there are no errors, generate STDERR reports for deprecated options that aren't show-stoppers, and generate STDERR reports and not generate a new config file if there are show-stopping errors. For those who say "as a sysadmin you should follow best practice X to prevent these problems"... the same is easily leveled at the clamav developers. They have best practices they should follow as well, with regard to supplying software that is commonly, widely known to be, and intended to be, used in such critical roles. And, really, they no loner get to hide behind it being a community project, it's now owned by a company. If they want to maintain the integrity of a company image that provides software that is reliable, especially reliable in mission critical roles, then they need to address this ASAP. _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
