--On 3 October 2008 22:31:32 +0200 Tomasz Kojm [EMAIL PROTECTED] wrote:
David F. Skoll wrote:
I suspect the Clam developers do it the way they do to force users to
look at (and think about) their configuration files. This is a laudable
goal, but really interferes with usability and creates
On 2008-10-03 22:25, Charles Gregory wrote:
CONCRETE SUGGESTION FOR CLAMAV DEVELOPERS (and anyone else with
minimal script writing skills):
CLAMWATCH service.
Either as cron job, or constantly running monitor daemon.
- Checks if clamd service is running (if enabled in startup
Aecio F. Neto wrote:
I don't agree with that, but let me put another option:
1) Break on unknown options
2) Ignore obsolete options and warn OP
If any Op (or poor user) adds an option like
PleaseClamAVCleanInfectedFilesForMe yes
and expects it to work, are you really sure that the software
On Sat, Oct 4, 2008 at 9:04 AM, Sarocet [EMAIL PROTECTED] wrote:
Aecio F. Neto wrote:
I don't agree with that, but let me put another option:
1) Break on unknown options
2) Ignore obsolete options and warn OP
If any Op (or poor user) adds an option like
Quoting David F. Skoll [EMAIL PROTECTED]:
The principle of least surprise says ClamAV
should reject that. By the same token, the principle of least surprise
says that ClamAV should not break on previously-valid configuration files.
But it is a big surprise when the action that old line was
Quoting Aecio F. Neto [EMAIL PROTECTED]:
I don't agree with that, but let me put another option:
1) Break on unknown options
2) Ignore obsolete options and warn OP
Valid in many cases...
If any Op (or poor user) adds an option like
PleaseClamAVCleanInfectedFilesForMe yes
and expects it to
Quoting Charles Gregory [EMAIL PROTECTED]:
A lot of people seem to think it is 'proper' for a mis-configured server
to just die or fail to start.
Yes, a lot of people do... :)
This makes sense when the server has an
*obvious* function/effect and its failure will be noted by interruptions
Eric Rostetter wrote:
Quoting Aecio F. Neto [EMAIL PROTECTED]:
I don't agree with that, but let me put another option:
1) Break on unknown options
2) Ignore obsolete options and warn OP
Valid in many cases...
If any Op (or poor user) adds an option like
Quoting Dennis Peterson [EMAIL PROTECTED]:
Jose-Marcio's elegant J-Chkmail milter has a beautiful option. It will
create a new config file using to the extent possible all your existing
options. (That same tool can generate a clean config file that has all
defaults filled in, too.) If earlier
On Sat, Oct 4, 2008 at 12:29 PM, Eric Rostetter
[EMAIL PROTECTED]wrote:
If any Op (or poor user) adds an option like
PleaseClamAVCleanInfectedFilesForMe yes
and expects it to work, are you really sure that the software should not
ignore this?
Yes. What happens if he means to type
Eric Rostetter wrote:
The principle of least surprise says ClamAV
should reject that. By the same token, the principle of least surprise
says that ClamAV should not break on previously-valid configuration files.
But it is a big surprise when the action that old line was supposed to take
is
Colin Alston wrote:
Still, no one has managed to answer just *why* in a simple key-value
configuration file with no option dependence has to refuse to start
when it encounters an unknown option.
Well, there are two cases:
1) A completely unknown option: In this case, I agree that Clam
On Fri, Oct 3, 2008 at 4:25 PM, David F. Skoll [EMAIL PROTECTED]wrote:
Colin Alston wrote:
Still, no one has managed to answer just *why* in a simple key-value
configuration file with no option dependence has to refuse to start
when it encounters an unknown option.
Well, there are two
Aecio F. Neto wrote:
1) A completely unknown option: In this case, I agree that Clam should
abort after writing errors to stderr and syslog. A completely unknown
option indicates a serious problem; the configuration file could never
have been valid.
Why? Ignore it and move to next one.
I
On Fri, Oct 3, 2008 at 4:35 PM, David F. Skoll [EMAIL PROTECTED]wrote:
Aecio F. Neto wrote:
1) A completely unknown option: In this case, I agree that Clam should
abort after writing errors to stderr and syslog. A completely unknown
option indicates a serious problem; the configuration
CONCRETE SUGGESTION FOR CLAMAV DEVELOPERS (and anyone else with
minimal script writing skills):
CLAMWATCH service.
Either as cron job, or constantly running monitor daemon.
- Checks if clamd service is running (if enabled in startup files)
- Tests clamdscan with simple clean file
David F. Skoll wrote:
I suspect the Clam developers do it the way they do to force users to
look at (and think about) their configuration files. This is a laudable
goal, but really interferes with usability and creates problems where there
need not be any. So I ask the developers (and I'd
17 matches
Mail list logo
