Hi,
One point that seems to have been missed is that it is that 'clamdscan'
is not necessarily creating the files in '/tmp'. It is most likely
'clamd' which is a separate independent program. Given this, 'clamdscan'
will not know what files to exclude form '/tmp' unless the
clamd/clamdscan
Hi Micah, all,
On Mon, 21 Oct 2019, Micah Snyder (micasnyd) wrote:
Ged, you are kind of coming off as having a really bad day.
Just criticism accepted. Apologies to all.
I think I'd better bow out of this thread.
--
73,
Ged.
___
clamav-users
Ged, Ian, all:
Do try to be nice to each other. It's very difficult to interpret tone over
email or chat. The clamav-users mailing list is generally a positive and
uplifting community and I very much want folks to feel comfortable asking
questions here. Ged, you are kind of coming off as
> On Oct 19, 2019, at 10:58 AM, G.W. Haywood via clamav-users
> wrote:
>
> Hi there,
>
> On Sat, 19 Oct 2019, Ian via clamav-users wrote:
>
>> Are you going to address why 'clamscan --tempdir /tmp /tmp' doesn't
>> produce the same behavior, that 'clamdscan /tmp' does?
>
> The clamd daemon
Hi there,
On Sat, 19 Oct 2019, Ian via clamav-users wrote:
This line of questioning is completely off-topic and unhelpful.
If you say so.
Are you going to address why 'clamscan --tempdir /tmp /tmp' doesn't
produce the same behavior, that 'clamdscan /tmp' does?
The clamd daemon has a man
> On Oct 19, 2019, at 4:40 AM, G.W. Haywood via clamav-users
> wrote:
>
> On Fri, 18 Oct 2019, Ian via clamav-users wrote:
>>> On Oct 18, 2019, at 10:10 AM, G.W. Haywood via clamav-users
>>> wrote:
>>> On Fri, 18 Oct 2019, Ian via clamav-users wrote:
>>>
Government regulations require
Hi Steve,
On Fri, 18 Oct 2019, Steve Basford wrote:
On 18 October 2019 16:19:23 Ian via clamav-users wrote:
This doesn't seem like a difficult problem for clamav to solve -- clamd is
asked to scan the file system and it creates temp files to accomplish this
I know I'm mainly a win user...
Hi there,
On Fri, 18 Oct 2019, Paul Kosinski via clamav-users wrote:
"of course you can't even really trust brand new drives any more"
Do you mean unreliability, or active insecurity? If the latter, any
examples? (Of drives per se, not hardware systems or subsystems.)
Reliability, in purely
Hi there,
On Fri, 18 Oct 2019, Ian via clamav-users wrote:
On Oct 18, 2019, at 10:10 AM, G.W. Haywood via clamav-users
wrote:
On Fri, 18 Oct 2019, Ian via clamav-users wrote:
Government regulations require that I scan the entire filesystem daily --
Which government is this, and which
On 18 October 2019 16:19:23 Ian via clamav-users
wrote:
This doesn't seem like a difficult problem for clamav to solve -- clamd is
asked to scan the file system and it creates temp files to accomplish this
I know I'm mainly a win user... So sorry in advance... but if you created a
Linux
"of course you can't even really trust brand new drives any more"
Do you mean unreliability, or active insecurity? If the latter, any
examples? (Of drives per se, not hardware systems or subsystems.)
And what can any AV do about it?
On Fri, 18 Oct 2019 18:10:17 +0100 (BST)
"G.W. Haywood via
> On Oct 18, 2019, at 10:10 AM, G.W. Haywood via clamav-users
> wrote:
>
> Hi there,
>
> On Fri, 18 Oct 2019, Ian via clamav-users wrote:
>>> On Oct 18, 2019, at 12:02 AM, G.W. Haywood via clamav-users
>>> wrote:
>>> On Thu, 17 Oct 2019, Ian via clamav-users wrote:
>>>
Hi there,
On Fri, 18 Oct 2019, Ian via clamav-users wrote:
On Oct 18, 2019, at 12:02 AM, G.W. Haywood via clamav-users
wrote:
On Thu, 17 Oct 2019, Ian via clamav-users wrote:
/usr/bin/clamdscan -m -i --no-summary /
Don't do that.
Government regulations require that I scan the entire
> On Oct 18, 2019, at 12:02 AM, G.W. Haywood via clamav-users
> wrote:
>
> Hi there,
>
> On Thu, 17 Oct 2019, Ian via clamav-users wrote:
>
>> Ubuntu 18.04.3 LTS
>> Clam 0.100.3+dfsg-0ubuntu0.18.04.1
>>
>> When I run this:
>>
>> /usr/bin/clamdscan -m -i --no-summary /
(Reinserted from
Hi there,
On Thu, 17 Oct 2019, Ian via clamav-users wrote:
Ubuntu 18.04.3 LTS
Clam 0.100.3+dfsg-0ubuntu0.18.04.1
When I run this:
/usr/bin/clamdscan -m -i --no-summary /
Don't do that.
1. Read the 'man' page for the valid options.
2. Read the list archives for more about what *not* to
Ubuntu 18.04.3 LTS
Clam 0.100.3+dfsg-0ubuntu0.18.04.1
When I run this:
/usr/bin/clamdscan -m -i --no-summary /
I get this error:
clamd: /tmp/clamav-ebbb3a980b0a96075cdf8b18191ad4a3.tmp/tar302: Access denied.
ERROR
Is clamd stepping on itself (possibly because of the multi-threading)? I
From: clamav-users-boun...@lists.clamav.net on behalf of Nathan Brink
#Charles Gregory wrote:
# More often than not, I see this kind of thinking as *policy* but without a
[...]
#
#Wouldn't this easily break threading? In this case, the respondent
[...]
Not germane to clamav - please send
Hi Guys
Please could we kill this thread.
I too have fallen victim to the changes made in the configuration files
which resulted in a serious whipping...
However, this being said, the fault lay by me for not checking up on the
changes that had been made and my assumption that the config
On Die, 2008-10-07 at 13:19 -0400, Charles Gregory wrote:
On Tue, 7 Oct 2008, Dennis Peterson wrote:
I disagree. I think this would be VERY useful. Not for the people who
don't want to RTFM, but for the people who would rather not have to wade
through the docs and changelog to figure
On Wednesday 08 October 2008, Tomasz Kojm wrote:
1. the requested functionality has been implemented in SVN
(and will be included in 0.94.1):
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1213
Can you put URL to this patch ?
--
Regards,
Sergey
On Tue, 7 Oct 2008 22:47:32 + (GMT)
reiner otto [EMAIL PROTECTED] wrote:
Unfortunately, nothing is fool proof to the properly motivated fool.
One of my customers, from a big international airline, I developed
some SW for, told me: There is nothing like users fault.
After some thinking, I
Firstly, apologies for failing to remove my spam tags ([0.0]) in some
e-mails. I know it messes up threading. I try to remember. Sorry.
On 2008/10/07 12:05 AM Jerry wrote:
Just out of morbid curiosity, who is holding a gun to your head...
Money. The 'gun' is money. Or, more precisely stated,
On 2008/10/7 Charles Gregory wrote:
We only 'demand' the right to have our suggestions heard in their proper
context, and not held up against the idealistic standards of the lucky
few.
I must say that for the disadvantaged, this has been a great debate.
However, it has missed the basic
Jerry wrote:
On Fri, 03 Oct 2008 22:12:49 -0700
John Rudd [EMAIL PROTECTED] wrote:
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
On Tue, 7 Oct 2008, John Smith wrote:
I must say that for the disadvantaged, this has been a great debate.
However, it has missed the basic premise. The Question and Issue is that
ClamAV is failing without warning.
To which the 'advantaged' respond that the warnings are in 'documentation'
Bowie Bailey wrote:
Jerry wrote:
From my experience, if an end user refuses to RTFM, adding additional
reading material is not going to solve the problem. The needed
documentation is all ready readily available. The motivation to fetch
and read it are what is sorely lacking.
I disagree.
John Smith wrote:
On 2008/10/7 Charles Gregory wrote:
We only 'demand' the right to have our suggestions heard in their proper
context, and not held up against the idealistic standards of the lucky
few.
I must say that for the disadvantaged, this has been a great debate.
However, it has
Dennis Peterson wrote:
So does Oracle, Apache, Python, Perl, MySQL, and a zillion other
products. Dead processes are widely accepted to not be chatty. Pardon my
Dennis Miller moment here, but I'm going to go ahead and blame the admin
if a critical process dies and they don't know about it.
Dennis Peterson wrote:
Bowie Bailey wrote:
Jerry wrote:
From my experience, if an end user refuses to RTFM, adding
additional reading material is not going to solve the problem.
The needed documentation is all ready readily available. The
motivation to fetch and read it are what
On Tue, 7 Oct 2008, Dennis Peterson wrote:
I disagree. I think this would be VERY useful. Not for the people who
don't want to RTFM, but for the people who would rather not have to wade
through the docs and changelog to figure out if there are config changes.
Let me help avoid prevent
On Tue, 7 Oct 2008, Dennis Peterson wrote:
However, it has missed the basic premise. The Question and Issue is that
ClamAV is failing without warning.
So does Oracle, Apache, Python, Perl, MySQL, and a zillion other
products. Dead processes are widely accepted to not be chatty.
You're a
On Tue, 7 Oct 2008, David F. Skoll wrote:
Yet you, as a non-ClamAV-developer, are ranting about sysadmin incompetence
and completely ignoring the real issue. The change DOES NOT AFFECT YOU in
the slightest. So what the HECK is your problem?
Well, now that you make me think about it, there is
David F. Skoll wrote:
Dennis Peterson wrote:
So does Oracle, Apache, Python, Perl, MySQL, and a zillion other
products. Dead processes are widely accepted to not be chatty. Pardon my
Dennis Miller moment here, but I'm going to go ahead and blame the admin
if a critical process dies and
Dennis Peterson Wrote:
And you've missed the point that some people here have claimed that
their clamd process has silently failed and was off line for days, and
other such claims. No amount of hand holding for creating config files
is going to make that problem better. That requires an
Bowie Bailey wrote:
However, doesn't this already exist with the upgrade notes? Take a look
here:
https://wiki.clamav.net/Main/UpgradeNotes093
I don't know if they are this detailed on all of the releases (the notes
for 0.94 don't say much), but this looks like exactly what John was
John Smith wrote:
Dennis Peterson Wrote:
And you've missed the point that some people here have claimed that
their clamd process has silently failed and was off line for days, and
other such claims. No amount of hand holding for creating config files
is going to make that problem
Dennis Peterson wrote:
With the tools we have available to us today there is no reason a failed
process should remain a secret.
Which does not explain the push-back on having the
applications/services/daemons provide better documentation and triggers
for helping that effort, instead of
John Rudd wrote:
Dennis Peterson wrote:
With the tools we have available to us today there is no reason a failed
process should remain a secret.
Which does not explain the push-back on having the
applications/services/daemons provide better documentation and triggers
for helping that
On Tue, 07 Oct 2008 12:07:09 -0700
John Rudd [EMAIL PROTECTED] wrote:
Bowie Bailey wrote:
However, doesn't this already exist with the upgrade notes? Take a look
here:
https://wiki.clamav.net/Main/UpgradeNotes093
I don't know if they are this detailed on all of the releases (the
On 2008/10/07 09:35 PM Tomasz Kojm wrote:
1. the requested functionality has been implemented in SVN
(and will be included in 0.94.1):
Thanks a lot Tom.
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
On Tue, 7 Oct 2008 14:01:53 -0500
John Smith [EMAIL PROTECTED] wrote:
Dennis Peterson Wrote:
And you've missed the point that some people here have claimed that
their clamd process has silently failed and was off line for days,
and other such claims. No amount of hand holding for creating
Jerry Wrote:
Seriously John if you are going to start with a new product, one that
you readily admit you have not got a working knowledge of, you have got
to RTFM. Create a jail and place your new program in it and then fire
it up. Check the logs, see what is happening under the hood. Try
On Sat, 4 Oct 2008, Dennis Peterson wrote:
Hopefully they're not running mail servers on the Internet elsewise they
could easily be considered derelict in their responsibilities.
Ah. Yes, I must be 'derelict' because there is only ONE sysadmin (me) and
I go home on weekends?
Heck, I'm not
Charles Gregory wrote:
On Sat, 4 Oct 2008, Dennis Peterson wrote:
Hopefully they're not running mail servers on the Internet elsewise they
could easily be considered derelict in their responsibilities.
Ah. Yes, I must be 'derelict' because there is only ONE sysadmin (me) and
I go home on
On Mon, 6 Oct 2008 11:37:51 -0400 (EDT)
Charles Gregory [EMAIL PROTECTED] wrote:
On Sat, 4 Oct 2008, Dennis Peterson wrote:
Hopefully they're not running mail servers on the Internet elsewise
they could easily be considered derelict in their responsibilities.
Ah. Yes, I must be 'derelict'
On Sat, 2008-10-04 at 13:30 +0200, Colin Alston wrote:
[]
I'm not all that interested if you have time for that. I don't, and
neither do most end users regardless of your opinion about their
intellect or ability.
To put it simple and direct: If you don't have time to read the
On Mon, 2008-10-06 at 11:37 -0400, Charles Gregory wrote:
On Sat, 4 Oct 2008, Dennis Peterson wrote:
Hopefully they're not running mail servers on the Internet elsewise they
could easily be considered derelict in their responsibilities.
Ah. Yes, I must be 'derelict' because there is only
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,
On Fri, 03 Oct 2008 22:12:49 -0700
John Rudd [EMAIL PROTECTED] wrote:
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,
On 2008/10/04 12:50 PM Jerry wrote:
From my experience, if an end user refuses to RTFM, adding additional
reading material is not going to solve the problem. The needed
documentation is all ready readily available. The motivation to fetch
and read it are what is sorely lacking.
You're
Hi there,
On Sat, 4 Oct 2008 John Rudd wrote:
...what they REALLY ought to do is supply a tool which reads old
config files, and does something like a lint check.
I believe there was a similar tool published by a user a while ago.
Why not put this in bugzilla as suggested by Tomasz? (I
- Original Message -
From: Colin Alston [EMAIL PROTECTED]
To: ClamAV users ML clamav-users@lists.clamav.net
Sent: Saturday, October 04, 2008 1:30 PM
Subject: Re: [Clamav-users] Stop it!
On 2008/10/04 12:50 PM Jerry wrote:
From my experience, if an end user refuses to RTFM, adding
On Fri, Oct 03, 2008 at 12:27:56PM +0200, Colin Alston said:
I've had enough now, and I want all you ClamAV people to listen up.
ClamAV has been continuously and repetitively adjusting configuration
options in such a way that breaks anything which is automatically
upgraded just stops
Colin Alston wrote:
On 2008/10/04 12:50 PM Jerry wrote:
From my experience, if an end user refuses to RTFM, adding additional
reading material is not going to solve the problem. The needed
documentation is all ready readily available. The motivation to fetch
and read it are what is sorely
On Sat, 04 Oct 2008 08:32:42 -0700
Dennis Peterson [EMAIL PROTECTED] wrote:
Colin Alston wrote:
On 2008/10/04 12:50 PM Jerry wrote:
From my experience, if an end user refuses to RTFM, adding
additional reading material is not going to solve the problem. The
needed documentation is all ready
Strange...
A boring thread whose subject is stop it, does not stop!
Tonino
Jerry ha scritto:
On Sat, 04 Oct 2008 08:32:42 -0700
Dennis Peterson [EMAIL PROTECTED] wrote:
Colin Alston wrote:
On 2008/10/04 12:50 PM Jerry wrote:
From my experience, if an end user refuses to
Tonix (Antonio Nati) wrote:
Strange...
A boring thread whose subject is stop it, does not stop!
Tonino
Thanks for playing!
dp
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
On Sat, 04 Oct 2008 18:39:08 +0200
Tonix (Antonio Nati) [EMAIL PROTECTED] wrote:
A boring thread whose subject is stop it, does not stop!
Sorry about that. Perhaps I could interest you in the:
Feature wish: Virtual POP3 folder with IMAP
Now playing on the 'Dovecot' mailing list.
--
On Fre, 2008-10-03 at 20:37 +0200, Colin Alston wrote:
On 2008/10/03 05:57 PM James Kosin wrote:
Colin Alston wrote:
I've had enough now, and I want all you ClamAV people to listen up.
Hay, maybe the packagers could write a script or something to indicate a
problem with the current
On Sat, Oct 4, 2008 at 5:15 PM, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
users could take the appropriate action ASAP instead of finding out or
having to check the logs on an hourly basis for problems.
You're (by you I mean everyone agreeing here with how ClamAV fails)
assuming
On 2008/10/04 10:15 PM Bernd Petrovitsch wrote:
users to sit and audit each change. On Ubuntu for example there can be
as many as 30 to 50 updates a week.
Using a desktop distribution on a server was *your* decision. And you
really *must* upgrade that much?
Probably not really.
It's an
Aecio F. Neto wrote:
On Sat, Oct 4, 2008 at 5:15 PM, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
users could take the appropriate action ASAP instead of finding out or
having to check the logs on an hourly basis for problems.
You're (by you I mean everyone agreeing here with how ClamAV fails)
Dennis Peterson wrote:
This seems a bit dramatic. Nobody is suffering. It takes but 10 minutes
3 or 4 times each year to visit and modify the ClamAV config files, if
at all. Somebody's inner drama queen is getting the best of them here.
If you are managing one machined or a few
David F. Skoll wrote:
Dennis Peterson wrote:
This seems a bit dramatic. Nobody is suffering. It takes but 10 minutes
3 or 4 times each year to visit and modify the ClamAV config files, if
at all. Somebody's inner drama queen is getting the best of them here.
If you are managing one
Jerry wrote:
The sad part is that they will continue to blame others for their
lackadaisical approach.
So, let me attempt to summarize your side of this here (and do correct
me if my summary is wrong, as I'm not trying to build a strawman argument).
You're justifying the laziness of the
On 2008/10/04 10:55 PM Dennis Peterson wrote:
configuration problems. You need to classify those machines and knock
off some class-based templates and be done with it. I don't see that as
a vendor problem.
Of course it's a vendor problem! :) You even just said why. We'd have
to keep
On Sam, 2008-10-04 at 17:29 -0300, Aecio F. Neto wrote:
On Sat, Oct 4, 2008 at 5:15 PM, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
users could take the appropriate action ASAP instead of finding out or
having to check the logs on an hourly basis for problems.
You're (by you I mean
On Sam, 2008-10-04 at 22:38 +0200, Colin Alston wrote:
On 2008/10/04 10:15 PM Bernd Petrovitsch wrote:
users to sit and audit each change. On Ubuntu for example there can be
as many as 30 to 50 updates a week.
Using a desktop distribution on a server was *your* decision. And you
Colin Alston wrote:
On 2008/10/04 10:55 PM Dennis Peterson wrote:
configuration problems. You need to classify those machines and knock
off some class-based templates and be done with it. I don't see that as
a vendor problem.
Of course it's a vendor problem! :) You even just said why.
On Sat, 04 Oct 2008 14:04:22 -0700
John Rudd [EMAIL PROTECTED] wrote:
Jerry wrote:
The sad part is that they will continue to blame others for their
lackadaisical approach.
So, let me attempt to summarize your side of this here (and do correct
me if my summary is wrong, as I'm not trying
Dennis Peterson wrote:
If you don't feel like you're getting your money's worth then the thing
to do is spend it somewhere else. Vote with your pocket book. That of
course begs the question: Are you getting your money's worth?
Yes, I'm getting my money's worth out of Clam. But rejecting
Jerry wrote:
1) Learn to live with it.
A very fine attitude.
2) Write a patch/utility that suits your needs.
Forking software is expensive.
3) Write your own AV program
Even more expensive.
4) Use another AV program. There are several available, both OS/Free
and commercial.
Even more
Jerry wrote:
On Sat, 04 Oct 2008 14:04:22 -0700
John Rudd [EMAIL PROTECTED] wrote:
Jerry wrote:
The sad part is that they will continue to blame others for their
lackadaisical approach.
So, let me attempt to summarize your side of this here (and do correct
me if my summary is wrong,
We are getting somewhat off-topic but:
On Fre, 2008-10-03 at 20:56 +, reiner otto wrote:
[]
Agreed. Unfortunately, this is a general problem with OpenSource.
As a programmer for already over 30 years, I am still wondering that
the terms Usability, user-friendliness,
--- Bernd Petrovitsch [EMAIL PROTECTED] schrieb am Sa, 4.10.2008:
Von: Bernd Petrovitsch [EMAIL PROTECTED]
Betreff: Re: [Clamav-users] Stop it!
An: ClamAV users ML clamav-users@lists.clamav.net
Datum: Samstag, 4. Oktober 2008, 22:09
We are getting somewhat off-topic but:
On Fre, 2008-10-03
I've had enough now, and I want all you ClamAV people to listen up.
ClamAV has been continuously and repetitively adjusting configuration
options in such a way that breaks anything which is automatically
upgraded just stops working.
This is further aggravated by the fact that Exim does not know
- Original Message
From: Colin Alston [EMAIL PROTECTED]
Sent: Friday, October 3, 2008 6:27:56 AM
I've had enough now, and I want all you ClamAV people to listen up.
ClamAV has been continuously and repetitively adjusting configuration
options in such a way that breaks anything
GESBBB wrote:
Is there any reason you cannot read the documentation prior to installing a
newer version?
Is there any reason Clam are incapable of stabilising on a configuration
format, or doing the many other things I suggested that other things
abide by?
Colin Alston wrote:
ClamAV has been continuously and repetitively adjusting configuration
options in such a way that breaks anything which is automatically
upgraded just stops working.
I agree that this is extremely hostile behaviour on the part of Clam
developers.
A friendlier approach:
Yes, I know I am about to contradict myself.
GESBBB wrote:
Is there any reason you cannot read the documentation prior to
installing a newer version?
Anyone using a package manager will have the new software installed before
they can read the documentation.
On Fri, 3 Oct 2008, Colin
Christopher X. Candreva wrote:
It IS a 0.x release. Once he hit 1.x I'll be a lot less forgiving, but as
long as we're at 0.x I expect this sort of thing -- and still think it's
better than the next best alternative.
Plenty of things have yet to go past 0.x and are many many years old.
Quoting Colin Alston [EMAIL PROTECTED]:
ClamAV has been continuously and repetitively adjusting configuration
options in such a way that breaks anything which is automatically
upgraded just stops working.
Well, maybe your automatically upgrading software needs improvment,
or just maybe you
Quoting Colin Alston [EMAIL PROTECTED]:
Is there any reason Clam are incapable of stabilising on a configuration
format
No, they are quite capable of doing this, but the choose not to. That
is their right and privilege. And doing so might slow or stop progress.
Remember, there is not even a
Quoting Christopher X. Candreva [EMAIL PROTECTED]:
Is there any reason you cannot read the documentation prior to
installing a newer version?
Anyone using a package manager will have the new software installed before
they can read the documentation.
Not true. I have a package manager
Eric Rostetter wrote:
Well, maybe your automatically upgrading software needs improvment,
or just maybe you should follow standard best practices and not do
automatic upgrades on a critical/important production system?
I partly agree with that, but I also think that ClamAV developers need
to
Quoting Colin Alston [EMAIL PROTECTED]:
Plenty of things have yet to go past 0.x and are many many years old.
So?
Considering Clam is in really abundant use I think version numbers are
little excuse, so it would be nice if sysadmins didn't get kicked in the
groin every time a release
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Eric Rostetter
Sent: Friday, October 03, 2008 12:20 PM
To: clamav-users@lists.clamav.net
Subject: Re: [Clamav-users] Stop it!
Quoting Colin Alston [EMAIL PROTECTED]:
ClamAV has
Eric Rostetter wrote:
Quoting Colin Alston [EMAIL PROTECTED]:
Is there any reason Clam are incapable of stabilising on a configuration
format
No, they are quite capable of doing this, but the choose not to. That
is their right and privilege. And doing so might slow or stop
Le Fri 3/10/2008, Aécio F. Neto disait
IMHO, this is one of the reasons free software doesn't go to the masses.
I have worked in both worlds - proprietary and free software - and this
last one lacks in many aspects that proprietary code takes care of:
being friendly.
There is a myth in
- Original Message -
I want two things out of ClamAV: (1) Security and (2) Least Surprise.
So far, it's not doing spectacularly well on either.
---snip---
team for their software and all their hard work. My comments are intended
merely to help improve the software, not as gratuitous
Erwan David wrote:
I never found comemrcial sftware being friendly to the user : bugs are rarely
acknowledged;
, licence management is a nightmare (should I se open, OEM or box licence in
this configuration ?) etc...
One more reason free / open source should be friendly.
Why not? That's
On Fri, 3 Oct 2008, Eric Rostetter wrote:
Not true. I have a package manager installed on all my machines. But they
do NOT do automatic updates... The above is only true of those who have
a package manager installed and configured to do automatic upgrades.
But you are on this mailing list,
Colin Alston wrote:
I've had enough now, and I want all you ClamAV people to listen up.
Hay, maybe the packagers could write a script or something to indicate a
problem with the current configuration when it is being installed. Then
users could take the appropriate action ASAP instead of
Quoting David F. Skoll [EMAIL PROTECTED]:
I partly agree with that, but I also think that ClamAV developers need
to make their software more admin-friendly.
I'm sure they will eventually.
The canonical situation
is one in which a small (but technically adept) company is responsible
for
Hi,
Eric Rostetter wrote:
Quoting Colin Alston [EMAIL PROTECTED]:
ClamAV has been continuously and repetitively adjusting configuration
options in such a way that breaks anything which is automatically
upgraded just stops working.
Why not have a scan for obsolete or bad parameter usage, if
Kevin W. Gagel wrote:
- Original Message -
I want two things out of ClamAV: (1) Security and (2) Least Surprise.
So far, it's not doing spectacularly well on either.
---snip---
team for their software and all their hard work. My comments are intended
merely to help improve the
Eric Rostetter wrote:
The canonical situation
is one in which a small (but technically adept) company is responsible
for hundreds of Clam installations for technically naive customers.
Maybe you should manage their installations for them?
We do! That's the point. WHEN (not IF) we have to
Quoting Rick Cooper [EMAIL PROTECTED]:
Maybe you need to talk to exim about this then?
Exim does exactly what it should when the clam daemon goes missing, it
I was going by the original posters comment that exim does not
know how to gracefully handle failures of clamav daemon. Since
exim
Quoting Aécio F. Neto [EMAIL PROTECTED]:
Is there any reason Clam are incapable of stabilising on a configuration
format
No, they are quite capable of doing this, but the choose not to. That
is their right and privilege. And doing so might slow or stop progress.
Note, I was just
Quoting Christopher X. Candreva [EMAIL PROTECTED]:
Not true. I have a package manager installed on all my machines. But they
do NOT do automatic updates... The above is only true of those who have
a package manager installed and configured to do automatic upgrades.
But you are on this
1 - 100 of 116 matches
Mail list logo
