On Mon, 6 Oct 2008, Jerry wrote: > I find it hard to believe that ClamAV could be down for *weeks* and > nobody has notice.
Well, in my case, it was a couple of days, but again, it was quite disturbing that the first indication of 'trouble' was that I noticed 'error code 3' being returned in headers of all my e-mail, when I happened to check headers. Needless to say, I scripted for *that* right away. But it hasn't happened recently because that bug was specific to an old version. > There are numerous applications that can monitor and report if a > daemon has failed. Some can even restart the application. Why have you > not bothered to install one? As noted in my suggestion, a simple monitor would not suffice, if the daemon is misbehaving rather than aborted. I threw some code into procmail to notify me. > The reason we get *bots*, etc, is because of derelict SA's who try to > off load their responsibilities. If the individual does not know how to > do the job correctly, then they have no business doing it at all. And are you going to STOP them all? This issue is about the real world, and getting inept SA's, and people who wouldn't even realize they have the role, to receive simple, direct notification that there is something wrong. I can agree *heartily* with the above statement. My world and my job would be so much EASIER if there was some way of enforcing the above. But this is reality, and I'm sorry, it's not going to live up to your standards any time soon. > I am not a doctor. If I attempt surgery on someone and they die, > should I be forgiven just because I am not a doctor? Of course not. Did anyone tell you that such a thing as 'surgery' even existed? If it was required and you just didn't know it was, then who would you blame? The patient still dies. Why not give them a chance to know they are dying? You want a medical analogy? It would be more appropriate to equate this situation to 'dispensing medicine'. ClamAv is the drug manufacturer of an over-the-counter drug. And the equivalent situation here is that ClamAV has changed the formulation of their 'medicine', and issued new product literature to all the physicians. Some of them will read the new information, and advise their patients accordingly. Some of them will be too busy, and not realize that something that "does the same job" needs to be used differently. If they are reasonably competent, and monitoring the drug's effectiveness they will notice something is wrong, but not as quickly as if there was a built-in mechanism to bring this to their attention just as soon as it *starts* to be used 'wrong'. But the REAL issue is still the people who don't notice anything wrong, and so they don't go to a doctor. Or the harried physician who has to diagnose lots of patients, didn't read that product monograph and doesn't realize that he needs to review the prescription. Eventually, he will do a 'regular review', and any competent doctor/SA will find the problem at that time. But otherwise, a patient who self-medicates, or a doctor too busy to review frequently..... Well, let's call them "derelict" and not address the issue, shall we? > An individual is either qualified to do a job, or they are not. It > doesn't get much simpler that then. Ah, well, "unqualified" is less accusatory than "derelict", but for all intents and purposes, the end result is the same. Either someone *does* the required job, or someone doesn't. And this is reality, where the job is "not getting done" by way too many people. They are not necessarily lazy or incomptent. They are just busy enough that their job is to *react* rather than be proactive. Fixing instead of preventing. It's not derelict, it's just a financial reality. The suggestions offered here address that situation, giving SA's something to 'react' to, rather than saying "too bad, you didn't read the literature". > This is somewhat confusing to me. Are you saying that you update > packages automatically without any idea what package(s) you are > updating? That is absurd. No. Absurd is being so busy that I don't get around to doing the manual updates for weeks, and then we get HACKED by some script kiddie who got in there and exploited the bug of the week. Absurd is spending tons of overtime 'fixing' a problem that could have been far more easily *prevented* by regular updates. This is not hypothetical, I have been stuck doing this. Yes, it would be NICE to have the time to spend my whole day carefully and cleverly maintaining systems, but it just doesn't happen. So by running automatically, I have a *better* solution, within my financial/time contraints, than doing it manually. Most packages do not change *functionally* except at major release levels. I can think of no other package I maintain where I have to go out of my way to watch for new configuration formats/options. That is the complaint here. ClamAV is an exception to an otherwise *workable* solution for those SA's in my position. A *silent* exception, as well. Rather than constrain the developers that they 'nail down' the config format, I advocate reasonable ways to notify end users (patients! not doctors!) that changes have occured. "Please contact your doctor". > ..... If you are blindly installing products without knowing what is > being installed, then you deserve any problems that happen your way. Ah, there we are again with that arrogant assertion that the poor deserve their 'lot in life'. Well, if anyone 'deserves' anything, it is for people with *your* attitude to suddenly have their budget slashed in half, so that they can suffer a good old-fashioned reality check. Sadly, this is about as likely to happen as it is for me to suddenly get an extra hour in my work day. Though one might argue that I've wasted a good bit of one on trying to convince an (ad hominem) how utterly stupid and wrong he is to deny a need with an argument that the people who need it don't deserve it. I am thankful that the underlying spirit of providing good quality software to those who can't really afford it is not tainted by people with attitudes like yours. - Charles _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
