Re: [Clamav-users] EOL
Jim Preston wrote: Over here, if I step out into traffic and get hit it is my fault. But suppose you walk out across a crossing where the "WALK" is lit (green man over here) and the traffic has a red light - but someone screams through ignoring the red light and gets you ? That is a better analogy. The **expectation** of any sane admin isn't that some random project will push out random updates deliberately designed to stop his working system from working. And you can cut the crap about "well you should have configured your system to not stop when ClamAV stopped" - that's rubbish because it's already been made perfectly clear right at the start of one of these threads that the project team consider any configuration that doesn't break if ClamAV isn't working right to be broken. Yes, it would have been nice to be in a position to have done a distro upgrade (with all the testing required) before now, but some of us haven't been able to for a variety of reasons. That does not give ANYONE (other than my management or users) the right to set out to punish me (and my users) for it - because that is what is happened, and some of you seem proud of that. Yes, it would be better if I was running more up to date software - but I made a decision based on certain constraints and assumptions. One of those assumptions was that some third party would take it upon themselves to deliberately stop it working. Many people will now be wondering how safe it is to trust this project (and FOSS in general) - trust can take a lifetime to build up, and a moment to destroy. Like I said, I can think of several ways it could have been handled without any significant effort (certainly less that has been expended on dealing with the backlash) and without significant (or with one option, any) inconvenience to people running up to date versions. The way it's been done, and especially the way it's been defended, makes certain people come across as very arrogant people who need to be careful they don't hurt themselves - it's long way down off a high horse. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The EOL tweets
Dan wrote: Yes, some updates can be problematic. But in this case, surely, there were updates during the year that worked just fine. In most cases, tho, I'm thinking the people complaining slacked off completely - unlike you, they didn't even bother to test the releases. And cf todays thread (LibClamAV Error: Can't load), which can be summararised as : It was working fine You broke it for me I've installed an update to try and fix it and now it's even more broke The only difference had the user done the update last week would be - he had a working system, he upgraded it, it's now broken and he has downtime as a direct result of the upgrade. Those two lines look fairly clear to me. Essentially they're telling you to get moving, get the update onto your to-be-done list. OK, so it suggests an upgrade would be a good idea. I've yet to see any explanation of where in that message (or the page referenced) it sets a deadline, where it says anything will die, and that this will be a deliberate act of sabotage. Yea, I agree, the Clam team probably could have done things better. But would more announcements or warnings have really made a difference? Why would the people, that regularly ignore the Freshclam warnings, pay attention? Actually, I believe at least some of those complaining here would have done. **HAD I KNOWN** about this killer update, then I would have applied pressure on management to give me the resources to roll out the new build I have - that's all I'm waiting on in order to be running completely up to date versions of everything - and because it's more than one server, in future I'll be able to update (one at a time) with less risk. OTOH, I wonder how many of these upset admins have taken even partial responsibility - by admitting to their bosses that they failed to apply any updates to a critical piece of software, for over a YEAR? I have - that probably surprises you. Can't speak for anyone else. Dan wrote: They do not have any right to deliberately mess with a running system... Please explain this "right" that makes thy system so sacrosanct. I've never heard of that. May I suggest that you'd change your tune if your house was ransacked and the burglar defended his action on the basis that he'd kept a key from before you bought the house and he's left a note (somewhere you probably wouldn't see it) telling you to upgrade your locks or else ? My servers are my property (or that of those I manage them for). No third party has the right (legal or moral) to interfere with that unless there is a contractual agreement that they can do so - and then only in ways allowed by that arrangement. In this case, there's an implicit agreement between admins/operators and the ClamAV team that allows the ClamAV team to apply AV signature updates - this being implicit by the admin running Freshclam. In no way can pushing a poison pill designed to stop the service be considered a "normal AV signature" update. The Clam team had one and only one responsible choice: to remove the aged product from service before it became a road hazard, er a liability around their necks. No, that is NOT their responsibility, nor their right. Not only that, it's inconsistent with the attitude expressed here towards people running old software. Contrast : 1) No-one should be running old software, they deserve all they've got. 2) We can't allow people to run old software, our only option is to kill it to protect people from themselves. OK, lets suppose that a car manufacturer finds out that one of their old models, of which there are many still in use, has a defect that could potentially expose the user to a higher risk of . In this country, and in the US I believe, there is a system for a recall if it's serious enough - or the manufacturer can put adverts in appropriate places to warn the user. Have you ever heard of the manufacturer deciding that the only responsible way is to go round with a fleet of lorries (trucks), lift the old vehicles off the owners drives without even ringing the doorbell, and take them off to the crusher ? They have a right, and a responsibility to try and make as many owners/users aware of the risks - but it is still the owner/users decision on whether that risk is acceptable TO THEM. They were even nice enough to give months of warnings. The efficacy of such is subject to a certain amount of debate. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The EOL tweets
On Sun, Apr 18, 2010 at 09:50:09AM +0100, Simon Hobson said: > Dan wrote: > > >Yes, some updates can be problematic. But in this case, surely, > >there were updates during the year that worked just fine. In most > >cases, tho, I'm thinking the people complaining slacked off > >completely - unlike you, they didn't even bother to test the > >releases. > > And cf todays thread (LibClamAV Error: Can't load), which can be > summararised as : It was working fine You broke it for me You seem to be massively missing the point. In a short while, there will be signatures in the database that will have the same effect for older versions of clamd, because they will trigger the same bug. Which way would you prefer clamd to die - with a helpful error message, or with a hex string that makes no sense to you? That was the only choice. Despite the drain on their resources these older versions are, despite the fact that older versions were hampering their ability to write new signatures, they still chose the option to make it fail with a helpful message after a long lead time instead of ignoring the issue and letting it die with an incomprehensible error message. Would you have preferred them to just let this happen without a clear indication of the problem? -- -- | Stephen Gran | Your object is to save the world, while | | st...@lobefin.net | still leading a pleasant life. | | http://www.lobefin.net/~steve | | -- ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] EOL
> In response to your example, that was a DOS attack and is illegal. > Microsoft updates have causes systems including servers to fail and > crash, should you be petitioning to have Microsoft prosecuted under > this law? It happens. Anyway, the fact is that you keep comparing two different thing. The fact that an *occasional* old system in bad shape breaks because of an update is not the same as an update meant to break old systems. Microsoft of course knows that every and each update they ship is potentially going to break some old bix, but I believe they are putting every feasible effort in keeping numbers low. This is not only because of people possibly filing a law suit against them, but because every system broken by an update is a very bad return in terms of corporate image. As I already said, when 95, 98, me and 2k went at EOL, Microsoft didn't send an update meant to stop them. It could mean a big class action against Microsoft. Worse, it would surely mean a huge loss of faith in the Microsoft platforms by users. Not even to mention how competitors would have ride it. This kind of loss of image is something the clamav project now shall expect (and probably deserve). Which is not my main concern, by the way: the thing I really dislike is that the open-source community as a whole will get somehow damaged by this sole clamav action. And please keep in mind that the EOL problem could easily and inexpensively be circumvented. No excuse, then. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] Empy queue
Hi everyone, I didn't know about the update, and it has been such a mess. It's okay, now. Emails in/out going. The thing is: what about the thousands of emails still in the /var/spool/qscan/working/new and /var/spool/qscan/tmp directories? Is there a way to reinject all of them as new emails? _bertrand ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] Thanks for the weekend entertainment
I don't want to stay quiet anymore though :) I see people posting as systems administrators who are acting more like consultants in disguise. Fairly consistently they're the ones saying they've been wronged, being abusive, threatening physical harm, and appear to have no love or passion for their job past how much liability they've accumulated by taking on (paid) agreements that they weren't able to service, and how quickly they can deflect the blame somewhere else. I don't know Simon, though I can't help but see his attitude and comments as a reflection of some other consultants / systems administrators whom I intensely dislike. If it's any consolation though, some of the other posters have been worse, to the point of being almost comical. As someone who has worked with about a hundred business owners, I've never encountered a crisis situation I could not defuse by explaining what happened and getting to work on fixing it, sometimes with and sometimes without payment. I do it because I love the work and I love the businesses I work for and they know it. Everything is great. And I can see a lot of people here have likeminded work ethics and you are the ones supporting ClamAV. I applaud you. Giampaolo, you're one of us. You may have a dissenting opinion, but otherwise you're level headed and logical and seem to have some passion for your job. So, you're cool in my book. Anyway I don't think any of the complainers are going to be donating to the ClamAV project any time soon. And I don't think end-users should necessarily feel the need to donate. But for those consultants who are successfully making money off of open source products, might I suggest you consider making some donations back to the software developers whose work you rely on? Cheers everyone. This will all blow over soon. Cody ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The EOL tweets
Stephen Gran wrote: You seem to be massively missing the point. In a short while, there will be signatures in the database that will have the same effect for older versions of clamd, because they will trigger the same bug. Which way would you prefer clamd to die - with a helpful error message, or with a hex string that makes no sense to you? That was the only choice. So you haven't actually been reading these threads then. It absolutely was **NOT** the only choice, it was the one choice of several that they took. I can think of **at least two** alternatives - one would have required minimal effort (probably less than has been expended in defending the decision) and zero inconvenience for those who run all the latest updates. So it IS NOT TRUE that there were no other options. It IS NOT TRUE that the only choice was this or have it die n a few weeks with a cryptic error message. As has already been said - it's done, it's not going to get undone, trust has been severely damaged. But most of all, this constant "it was the only way, anyone affected was a complete imbecile who should be allowed near a computer" attitude really makes you sound like a bunch of people most of us wouldn't want to be associated with. It most certainly doesn't make you sound like the professional sysadmnins that you claim to be. I think you've got to go to one of a number of churches, or an Apple event, to hear such "this is the one true way" message defended any louder ! There really doesn't seem any point in debating this any more. It's been proven time and time again that the most fervent religous believers won't be for hearing any criticism of their one true way - and that is exactly what these threads have sounded like for those of us "outside the church". You may be nice people - but I speak as I find. The above is how I find. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] clamav-0.96rc1-19.1.i586.rpm;ThankYou
OK. That clearyfied most of it. I had to uninstall from YaST both clamav and database in order to manage an update with none-RC. The rpm-update from console would only receive a newer RC (from 18 to 19) and not the appearently newer none-RC clamav. And a console rpm-erase would not properly work. Could be my own insufficient howto. Maybe some trick with the /sbin/SuSEconfig(?). I did not run that. Or maybe a conflict somewhere. After having uninstalled and reinstalled the old outdated clamav from the SLED_10_SP3 DVD, I easily could update from the last none-RC "clamav27...rpm" that wouldnt go in the first place. ___ > - Original Message - > From: aCaB > To: "ClamAV users ML" > Subject: Re: [Clamav-users] clamav-0.96rc1-19.1.i586.rpm > Date: Sun, 18 Apr 2010 00:46:12 +0200 > > > Si St wrote: > > Whats the difference between: > > clamav-0.96rc1-19.1.i586.rpm > > and: > > clamav-0.96-27.1.i586.rpm > > ? > > The RC is a release canditate package. It was issued before the final > 0.96 release (the non-RC package). > > > I am thinking of the "RC" specification of the package. > > Which one should I choose for my SLED_10_SP3? > > There you go > http://software.opensuse.org/search?baseproject=SUSE%3ASLE-10&p=1&q=clamav > > ___ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://www.clamav.net/support/ml > -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Empy queue
On Sun, Apr 18, 2010 at 10:59, _beb_ wrote: > Hi everyone, > I didn't know about the update, and it has been such a mess. > It's okay, now. Emails in/out going. > The thing is: what about the thousands of emails still in the > /var/spool/qscan/working/new and /var/spool/qscan/tmp directories? > Is there a way to reinject all of them as new emails? It sounds like the answer would be specific to QMail, it's probably best to check it's documentation/lists. -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The EOL tweets
On Sun, 18 Apr 2010 10:37:19 +0100 Stephen Gran wrote: > On Sun, Apr 18, 2010 at 09:50:09AM +0100, Simon Hobson said: > > Dan wrote: > > > > >Yes, some updates can be problematic. But in this case, surely, > > >there were updates during the year that worked just fine. In most > > >cases, tho, I'm thinking the people complaining slacked off > > >completely - unlike you, they didn't even bother to test the > > >releases. > > > > And cf todays thread (LibClamAV Error: Can't load), which can be > > summararised as : It was working fine You broke it for me > > You seem to be massively missing the point. In a short while, there > will be signatures in the database that will have the same effect for > older versions of clamd, because they will trigger the same bug. Which > way would you prefer clamd to die - with a helpful error message, or > with a hex string that makes no sense to you? That was the only choice. I am sorry to intervene your discussion at this point but this argument is more or less saying that the clamav authors are incompetent in finding a way to design a signature database that knows versioning, meaning different versions of clamd can use it with differing or equal number of available signatures. Did you really mean that? If this was not your intention then you should just accept what it probably really was: unnecessarily playing god in their very own playground, giving a damn about others point of view. You may either call this fundamentalistic, "we know the sole truth and that's why _all_ others have to obey". You can find this kind of thinking in a lot of commercial software companies, but really seldomly in community driven projects. The reason for this is pretty simple, the real strength of a community is its immanent broad variety of thoughts expressed by the participants. If you deny that it means you have not accepted the community model as a whole. -- Regards, Stephan ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Thanks for the weekend entertainment
> Giampaolo, you're one of us. You may have a dissenting opinion, but > otherwise you're level headed and logical and seem to have some passion > for your job. So, you're cool in my book. Thank you, Cody, for your good words: I needed some... :) Giampaolo ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] EOL
On Sun, 18 Apr 2010, Simon Hobson wrote: > And you can cut the crap about "well you should have configured your > system to not stop when ClamAV stopped" - that's rubbish because it's > already been made perfectly clear right at the start of one of these > threads that the project team consider any configuration that doesn't > break if ClamAV isn't working right to be broken. As the originator of those comments, you have misquoted me. The project team consider any CLAMD configuration -- not any MAIL configuration -- that doesn't break CLAMD if ClamAV isn't working right to be broken. Because of this, it has been recomended, repeatedly, for years, that mail systems be configured to deliver mail unfiltered if the milter fails. == Chris Candreva -- ch...@westnet.com -- (914) 948-3162 WestNet Internet Services of Westchester http://www.westnet.com/ ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] error in make
Thanks. That did help. Now I'm getting a problem starting the daemon. The
error that I am getting is:
[r...@neidorff ~]# /etc/init.d/clamd start
Starting Clam AV daemon: ERROR: Missing argument for option at line 33
ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf
[FAILED]
I've checked the clamd.conf file. It looks fine. permissions are 644. I've
tried owner as root, clamav and qscand. No change. I've put some "echo"
statements in /etc/init.d/clamd to verify that it is running and where the
error is coming from. Here are the relavent lines:
start() {
# Find user to run as
CLAMUSER=`grep ^User /etc/clamd.conf | cut -d ' ' -f2`
if [ -z $CLAMUSER ] ; then
CLAMUSER="clamav"
fi
# Lets start up
echo -n $"Starting Clam AV daemon: "
LANG= daemon --user $CLAMUSER /usr/local/sbin/clamd
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamd
return $RETVAL
}
Line 33 is "return $RETVAL.
Can anyone please help me get my clamav working again?
Thanks,
Mark
On 4/17/10, Török Edwin wrote:
>
> On 04/17/2010 06:14 PM, neidorff wrote:
>
>> On 4/17/10, neidorff wrote:
>>
>>>
>>> On 4/17/10, Török Edwin wrote:
>>>
>>> On 04/17/2010 05:12 PM, neidorff wrote:
Help, please.
>
> My system is old--Fedora Core 3--but it has been working as a mail
> server
> (qmail from and upgraded from qmailrocks) for years without trouble.
> Now
> in
> the position of having to install new clamav. Followed the
> instructions--uninstalled old clamav. Now building new. (upgraded
> packages
> as needed, already)
> configure went fine.
> I got the output below
> CXXlibclamavcxx_la-bytecode2llvm.lo
> cc1plus: error: unrecognized command line option
> "-Wno-missing-field-initializers"
>
>
Did you specify --enable-llvm to configure?
If not it should have automatically disabled it on such an old compiler.
Try rerunning configure with --disable-llvm, and see if make works then.
>>> Many thanks. That fixed the problem. I have run configure, make and
>>> (#)make install without issue.
>>>
>>>
>> AckI skoke too soon. The clamd daemon is not running. When I try to
>> manually start it, it complains about:
>> Starting Clam AV daemon: /usr/local/sbin/clamd: error while loading shared
>> libraries: libclamav.so.6: cannot open shared object file: No such file or
>> directory
>>
>
> Run ldconfig, that'll create the appropriate symlinks.
>
>
>
> --Edwin
> ___
> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
> http://www.clamav.net/support/ml
>
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [Clamav-users] EOL
Giampaolo Tomassoni wrote: In response to your example, that was a DOS attack and is illegal. Microsoft updates have causes systems including servers to fail and crash, should you be petitioning to have Microsoft prosecuted under this law? It happens. Anyway, the fact is that you keep comparing two different thing. The fact that an *occasional* old system in bad shape breaks because of an update is not the same as an update meant to break old systems. And please keep in mind that the EOL problem could easily and inexpensively be circumvented. No excuse, then. Good Morning Giampaolo, We are never going to agree so .. I have moved on. I sincerely hope your's and your colleagues systems are back to running and that they continue to do so for a long time. Best, Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] EOL
> Giampaolo Tomassoni wrote: > >> In response to your example, that was a DOS attack and is illegal. > >> Microsoft updates have causes systems including servers to fail and > >> crash, should you be petitioning to have Microsoft prosecuted under > >> this law? > >> > > > > It happens. > > > > Anyway, the fact is that you keep comparing two different thing. The > fact > > that an *occasional* old system in bad shape breaks because of an > update is > > not the same as an update meant to break old systems. > > > > > > And please keep in mind that the EOL problem could easily and > inexpensively > > be circumvented. No excuse, then. > > > Good Morning Giampaolo, > > We are never going to agree so .. I have moved on. > I sincerely hope your's and your colleagues systems are back to running > and that they continue to do so for a long time. To me, your move doesn't seem far enough from the mudding neck you already show. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] clamav-0.96rc1-19.1.i586.rpm;ThankYou
Si St wrote: OK. That clearyfied most of it. I had to uninstall from YaST both clamav and database in order to manage an update with none-RC. The rpm-update from console would only receive a newer RC (from 18 to 19) and not the appearently newer none-RC clamav. And a console rpm-erase would not properly work. Could be my own insufficient howto. Maybe some trick with the /sbin/SuSEconfig(?). I did not run that. Or maybe a conflict somewhere. After having uninstalled and reinstalled the old outdated clamav from the SLED_10_SP3 DVD, I easily could update from the last none-RC "clamav27...rpm" that wouldnt go in the first place. Just as a note, the rpm program has a force option that should have over ridden the mistaken fact that it thought the RC was the newer version. If YaST just would not download the latest rpm, then you have to manually download it and run it from the command line with the force option. Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] error in make
neidorff wrote:
Thanks. That did help. Now I'm getting a problem starting the daemon. The
error that I am getting is:
[r...@neidorff ~]# /etc/init.d/clamd start
Starting Clam AV daemon: ERROR: Missing argument for option at line 33
ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf
[FAILED]
I've checked the clamd.conf file. It looks fine. permissions are 644. I've
tried owner as root, clamav and qscand. No change. I've put some "echo"
statements in /etc/init.d/clamd to verify that it is running and where the
error is coming from. Here are the relavent lines:
start() {
# Find user to run as
CLAMUSER=`grep ^User /etc/clamd.conf | cut -d ' ' -f2`
if [ -z $CLAMUSER ] ; then
CLAMUSER="clamav"
fi
# Lets start up
echo -n $"Starting Clam AV daemon: "
LANG= daemon --user $CLAMUSER /usr/local/sbin/clamd
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamd
return $RETVAL
}
Line 33 is "return $RETVAL.
Can anyone please help me get my clamav working again?
Thanks,
Mark
That error is not in the init script, it is being generated from the
clamd.conf file and is not a permission issue but a failure to parse the
file. The error is that it does not understand the option on line 33 of
/usr/local/etc/clamd.conf
What do you have on this line? In the default clamd.conf (new one
distributed with 0.96) it is:
# Default: no
which is not a problem. Check your clamd.conf and if you can't see what
is wrong, paste the contents (or partial contents) and I will see if I
can determine what it does not like.
Jim
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [Clamav-users] error in make
On Apr 18, 2010, at 7:14 AM, neidorff wrote: > Thanks. That did help. Now I'm getting a problem starting the daemon. The > error that I am getting is: > > [r...@neidorff ~]# /etc/init.d/clamd start > Starting Clam AV daemon: ERROR: Missing argument for option at line 33 > ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf > [FAILED] > I've checked the clamd.conf file. It looks fine. The problem isn't in your /etc/init.d/clamd startup script, although that seems to believe clamd.conf should be under /etc rather than /usr/local/etc (and they should agree). Instead do something like: emacs +33 /usr/local/etc/clamd.conf ...to check on the specific line. My guess is that it is something like "LogTime" which should be "LogTime yes" nowadays. Regards, -- -Chuck ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] error in make
Chuck Swiger wrote: On Apr 18, 2010, at 7:14 AM, neidorff wrote: Thanks. That did help. Now I'm getting a problem starting the daemon. The error that I am getting is: [r...@neidorff ~]# /etc/init.d/clamd start Starting Clam AV daemon: ERROR: Missing argument for option at line 33 ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf [FAILED] I've checked the clamd.conf file. It looks fine. The problem isn't in your /etc/init.d/clamd startup script, although that seems to believe clamd.conf should be under /etc rather than /usr/local/etc (and they should agree). Instead do something like: emacs +33 /usr/local/etc/clamd.conf ...to check on the specific line. My guess is that it is something like "LogTime" which should be "LogTime yes" nowadays. Regards, Yes, the default (if you have been upgrading for a long-time or maybe from the distro rpms???) used to be /etc/clamd.conf. It could also be... he has it symlinked to the one in the usr directory which is what I did rather than change the init script.. Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] clamav-0.96rc1-19.1.i586.rpm; ThankYou Jim Preston
I am aware of the force-option in rpm, but I did not want to use it before as a last resort. I also usually download manually the new clamav packages and install them from console, and it usually works fine except in the case of this RC without the force-argument. But that is over now as I stick to the recommended version by Acab: http://software.opensuse.org/search?baseproject=SUSE%3ASLE-10&p=1&q=clamav __ > - Original Message - > From: "Jim Preston" > To: "ClamAV users ML" > Subject: Re: [Clamav-users] clamav-0.96rc1-19.1.i586.rpm;ThankYou > Date: Sun, 18 Apr 2010 08:03:52 -0700 > > > Si St wrote: > > OK. That clearyfied most of it. > > > > I had to uninstall from YaST both clamav and database in order to > > manage an update with none-RC. The rpm-update from console would > > only receive a newer RC (from 18 to 19) and not the appearently > > newer none-RC clamav. > > And a console rpm-erase would not properly work. Could be my own > > insufficient howto. Maybe some trick with the > > /sbin/SuSEconfig(?). I did not run that. Or maybe a conflict > > somewhere. > > > > After having uninstalled and reinstalled the old outdated clamav > > from the SLED_10_SP3 DVD, I easily could update from the last > > none-RC "clamav27...rpm" that wouldnt go in the first place. > > > Just as a note, the rpm program has a force option that should have > over ridden the mistaken fact that it thought the RC was the newer > version. > If YaST just would not download the latest rpm, then you have to > manually download it and run it from the command line with the > force option. > > Jim > ___ > Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net > http://www.clamav.net/support/ml > -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] clamav-0.96rc1-19.1.i586.rpm; ThankYou Jim Preston
Si St wrote: I am aware of the force-option in rpm, but I did not want to use it before as a last resort. I also usually download manually the new clamav packages and install them from console, and it usually works fine except in the case of this RC without the force-argument. But that is over now as I stick to the recommended version by Acab: http://software.opensuse.org/search?baseproject=SUSE%3ASLE-10&p=1&q=clamav Thanks, I was just giving additional information. I agree, and I too only use force ONLY when all else fails. This usually only when the upgrade is not to my liking / needs and I need to force it to use an older version.. or over ride deps. Thanks, Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] The news keeps getting better
___ Mandriva Linux Security Advisory MDVSA-2010:082 http://www.mandriva.com/security/ ___ Package : clamav Date: April 18, 2010 Affected: 2008.0, Corporate 4.0, Enterprise Server 5.0 ___ Problem Description: Multiple vulnerabilities has been found and corrected in clamav: ClamAV before 0.96 does not properly handle the (1) CAB and (2) 7z file formats, which allows remote attackers to bypass virus detection via a crafted archive that is compatible with standard archive utilities (CVE-2010-0098). The qtm_decompress function in libclamav/mspack.c in ClamAV before 0.96 allows remote attackers to cause a denial of service (memory corruption and application crash) via a crafted CAB archive that uses the Quantum (aka .Q) compression format. NOTE: some of these details are obtained from third party information (CVE-2010-1311). Packages for 2008.0 are provided for Corporate Desktop 2008.0 customers This update provides clamav 0.96, which is not vulnerable to these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0098 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1311 ___ Updated Packages: Mandriva Linux 2008.0: 725bf0c38497087b9a3be4a8773c8cd0 2008.0/i586/clamav-0.96-0.1mdv2008.0.i586.rpm 147dc79976707ed0787f15dfc5f84f77 2008.0/i586/clamav-db-0.96-0.1mdv2008.0.i586.rpm 63c6b37df8ca4b6d3ca17ad858f622bb 2008.0/i586/clamav-milter-0.96-0.1mdv2008.0.i586.rpm b464991a0ea73562a076183a1b889d1b 2008.0/i586/clamd-0.96-0.1mdv2008.0.i586.rpm c862f6c48325f5d9c9811d9654ef6286 2008.0/i586/libclamav6-0.96-0.1mdv2008.0.i586.rpm 1345629ca340e35ae02586db29cb0df9 2008.0/i586/libclamav-devel-0.96-0.1mdv2008.0.i586.rpm a7a379222d25afc907959dab9f0c1160 2008.0/SRPMS/clamav-0.96-0.1mdv2008.0.src.rpm Mandriva Linux 2008.0/X86_64: a2294c5b9a7342c9a18be68e206e8127 2008.0/x86_64/clamav-0.96-0.1mdv2008.0.x86_64.rpm e56be5cf84c280c8d9a5ae772e069623 2008.0/x86_64/clamav-db-0.96-0.1mdv2008.0.x86_64.rpm 46ccfda86d7329ec84b4425158ce0798 2008.0/x86_64/clamav-milter-0.96-0.1mdv2008.0.x86_64.rpm 14f7a2a98a648ec77cc851f449f4d529 2008.0/x86_64/clamd-0.96-0.1mdv2008.0.x86_64.rpm f6ef52a7fc104cd163bc57229f4ce608 2008.0/x86_64/lib64clamav6-0.96-0.1mdv2008.0.x86_64.rpm a86f2486280a9593973ca00e72160421 2008.0/x86_64/lib64clamav-devel-0.96-0.1mdv2008.0.x86_64.rpm a7a379222d25afc907959dab9f0c1160 2008.0/SRPMS/clamav-0.96-0.1mdv2008.0.src.rpm Corporate 4.0: 37a73e705ddd3464013e35abc0422b2f corporate/4.0/i586/clamav-0.96-0.1.20060mlcs4.i586.rpm 4867fd02902c7e67cff8c635c069f193 corporate/4.0/i586/clamav-db-0.96-0.1.20060mlcs4.i586.rpm e0044dabbfb5b614e4e7f33dc005b9c3 corporate/4.0/i586/clamav-milter-0.96-0.1.20060mlcs4.i586.rpm 0d8b5a9c7b43bff63d205c17ae0edfdd corporate/4.0/i586/clamd-0.96-0.1.20060mlcs4.i586.rpm 216a2677193408bd94e074ed6dd041e3 corporate/4.0/i586/libclamav6-0.96-0.1.20060mlcs4.i586.rpm 126203939bdaf3a6f4539e43d3bb38b0 corporate/4.0/i586/libclamav-devel-0.96-0.1.20060mlcs4.i586.rpm da03bea8d9ee43b6a26161f915e2dcf9 corporate/4.0/SRPMS/clamav-0.96-0.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: 89a192c1ea1cdc678db652dc42df691e corporate/4.0/x86_64/clamav-0.96-0.1.20060mlcs4.x86_64.rpm 1ab9901f75ba6367905365097689c4ed corporate/4.0/x86_64/clamav-db-0.96-0.1.20060mlcs4.x86_64.rpm 5fed440379b8b58c54f6963dabe78c52 corporate/4.0/x86_64/clamav-milter-0.96-0.1.20060mlcs4.x86_64.rpm 56c4c66f35fdf0b19fd98f722a039fb8 corporate/4.0/x86_64/clamd-0.96-0.1.20060mlcs4.x86_64.rpm 1145efa3ed5032ec72228461a1d2127b corporate/4.0/x86_64/lib64clamav6-0.96-0.1.20060mlcs4.x86_64.rpm a9d60021af0aa48ea051612d1a5a77d9 corporate/4.0/x86_64/lib64clamav-devel-0.96-0.1.20060mlcs4.x86_64.rpm da03bea8d9ee43b6a26161f915e2dcf9 corporate/4.0/SRPMS/clamav-0.96-0.1.20060mlcs4.src.rpm Mandriva Enterprise Server 5: 90e36dd55953ef2ec7d474a9fe884803 mes5/i586/clamav-0.96-0.1mdvmes5.1.i586.rpm 08007813bf57f6822a0b12076ccc7927 mes5/i586/clamav-db-0.96-0.1mdvmes5.1.i586.rpm 869146c059841f726e777402adf57024 mes5/i586/clamav-milter-0.96-0.1mdvmes5.1.i586.rpm f03e3941b56ac9c669de43fa35f2e866 mes5/i586/clamd-0.96-0.1mdvmes5.1.i586.rpm d22d4a4de191942a0e66980ce9b91b85 mes5/i586/libclamav6-0.96-0.1mdvmes5.1.i586.rpm 868e1684a7e3f53876bc91ac74b6cf8f mes5/i586/libclamav-devel-0.96-0.1mdvmes5.1.i586.rpm 39710975d4a682f07f4b35a62df09daa mes5/SRPMS/clamav-0.96-0.1mdvmes5.1.src.rpm Mandriva Enterprise Server 5/X86_64: b111e1d0a7a2c7f86e4fc51ae840d7de mes5/x86_64/clamav-0.96-0.1mdvmes5.1.x86_64.rpm 30c4f7bcaff541af1c9bf1d2d4633a2b mes5/x86_64/clamav-db-0.96-0.1mdvmes5.1.x86_64.rpm 01bb253f6328f9473ffc0a167ca44a92
[Clamav-users] Lots of "pread fail" warnings during scanning
Hello all, I just compiled and installed a fresh version of clamav (0.96) from source on an Ubuntu box (8.10). Compiling and installing went well. I also ran the unit tests and they all passed. But I then did a full scan of the machine and got lots and lots of warnings like this: LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for 4096 bytes, got 5 LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for 4096 bytes, got 2 LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for 4096 bytes, got 11 I have searched the archives and the web, but I only found one old forum post where someone had this problem (and no answers). I still use the old config files from a previous clamav 0.94 installation (which was fully removed). Could this have something to do with it? Does anyone have any pointers for me as to what might be wrong? Best regards, Hauke ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] error in make
On 4/18/10, Jim Preston wrote: > > Chuck Swiger wrote: > >> On Apr 18, 2010, at 7:14 AM, neidorff wrote: >> >> >>> Thanks. That did help. Now I'm getting a problem starting the daemon. >>> The >>> error that I am getting is: >>> >>> [r...@neidorff ~]# /etc/init.d/clamd start >>> Starting Clam AV daemon: ERROR: Missing argument for option at line 33 >>> ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf >>> [FAILED] >>> I've checked the clamd.conf file. It looks fine. >>> >>> >> >> The problem isn't in your /etc/init.d/clamd startup script, although that >> seems to believe clamd.conf should be under /etc rather than /usr/local/etc >> (and they should agree). Instead do something like: >> >> emacs +33 /usr/local/etc/clamd.conf >> >> ...to check on the specific line. >> >> My guess is that it is something like "LogTime" which should be "LogTime >> yes" nowadays. >> >> Regards, >> >> > > SOLVED!!! Many thanks for all the help. I fixed the path issues. Also, I found the new syntax for clamd.conf in the man page, corrected the file, removed some deprecated stuff, replaced the old version of freshclam (which didn't get upgraded with the install of 0.96) and now the system is working happily. Mark (after 3 days without the server working, I am very releived!!!) ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Lots of "pread fail" warnings during scanning
On 2010-04-18 22:39, Hauke Duden wrote: > Hello all, > > I just compiled and installed a fresh version of clamav (0.96) from > source on an Ubuntu box (8.10). > > Compiling and installing went well. I also ran the unit tests and they > all passed. But I then did a full scan of the machine and got lots and > lots of warnings like this: > > LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for > 4096 bytes, got 5 > LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for > 4096 bytes, got 2 > LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for > 4096 bytes, got 11 This could mean that: - there was an I/O error - fmap.c thinks your file is bigger than it really is - pread got interrupted by a signal, and fmap.c didn't resume the read Either way ClamAV didn't read all that it should from the file. Can you find the file that triggers these warnings? (if you use clamscan -rvi, it'll print the filename before scanning it, so you can easily associate warning message with file). Please open a bug at bugs.clamav.net, and attach the file. Best regards, --Edwin ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The news keeps getting better
On Apr 18, 2010, at 10:56 AM, lists wrote: ___ Mandriva Linux Security Advisory MDVSA-2010:082 http://www.mandriva.com/security/ ___ Package : clamav Date: April 18, 2010 Affected: 2008.0, Corporate 4.0, Enterprise Server 5.0 ___ Problem Description: Multiple vulnerabilities has been found and corrected in clamav: ClamAV before 0.96 does not properly handle the (1) CAB and (2) 7z file formats, which allows remote attackers to bypass virus detection via a crafted archive that is compatible with standard archive utilities (CVE-2010-0098). The qtm_decompress function in libclamav/mspack.c in ClamAV before 0.96 allows remote attackers to cause a denial of service (memory corruption and application crash) via a crafted CAB archive that uses the Quantum (aka .Q) compression format. NOTE: some of these details are obtained from third party information (CVE-2010-1311). Packages for 2008.0 are provided for Corporate Desktop 2008.0 customers This update provides clamav 0.96, which is not vulnerable to these issues. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0098 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1311 ___ Updated Packages: Mandriva Linux 2008.0: 725bf0c38497087b9a3be4a8773c8cd0 2008.0/i586/clamav-0.96-0.1mdv2008.0.i586.rpm 147dc79976707ed0787f15dfc5f84f77 2008.0/i586/clamav-db-0.96-0.1mdv2008.0.i586.rpm 63c6b37df8ca4b6d3ca17ad858f622bb 2008.0/i586/clamav-milter-0.96-0.1mdv2008.0.i586.rpm b464991a0ea73562a076183a1b889d1b 2008.0/i586/clamd-0.96-0.1mdv2008.0.i586.rpm c862f6c48325f5d9c9811d9654ef6286 2008.0/i586/libclamav6-0.96-0.1mdv2008.0.i586.rpm 1345629ca340e35ae02586db29cb0df9 2008.0/i586/libclamav-devel-0.96-0.1mdv2008.0.i586.rpm a7a379222d25afc907959dab9f0c1160 2008.0/SRPMS/clamav-0.96-0.1mdv2008.0.src.rpm Mandriva Linux 2008.0/X86_64: a2294c5b9a7342c9a18be68e206e8127 2008.0/x86_64/clamav-0.96-0.1mdv2008.0.x86_64.rpm e56be5cf84c280c8d9a5ae772e069623 2008.0/x86_64/clamav-db-0.96-0.1mdv2008.0.x86_64.rpm 46ccfda86d7329ec84b4425158ce0798 2008.0/x86_64/clamav-milter-0.96-0.1mdv2008.0.x86_64.rpm 14f7a2a98a648ec77cc851f449f4d529 2008.0/x86_64/clamd-0.96-0.1mdv2008.0.x86_64.rpm f6ef52a7fc104cd163bc57229f4ce608 2008.0/x86_64/lib64clamav6-0.96-0.1mdv2008.0.x86_64.rpm a86f2486280a9593973ca00e72160421 2008.0/x86_64/lib64clamav-devel-0.96-0.1mdv2008.0.x86_64.rpm a7a379222d25afc907959dab9f0c1160 2008.0/SRPMS/clamav-0.96-0.1mdv2008.0.src.rpm Corporate 4.0: 37a73e705ddd3464013e35abc0422b2f corporate/4.0/i586/clamav-0.96-0.1.20060mlcs4.i586.rpm 4867fd02902c7e67cff8c635c069f193 corporate/4.0/i586/clamav-db-0.96-0.1.20060mlcs4.i586.rpm e0044dabbfb5b614e4e7f33dc005b9c3 corporate/4.0/i586/clamav-milter-0.96-0.1.20060mlcs4.i586.rpm 0d8b5a9c7b43bff63d205c17ae0edfdd corporate/4.0/i586/clamd-0.96-0.1.20060mlcs4.i586.rpm 216a2677193408bd94e074ed6dd041e3 corporate/4.0/i586/libclamav6-0.96-0.1.20060mlcs4.i586.rpm 126203939bdaf3a6f4539e43d3bb38b0 corporate/4.0/i586/libclamav-devel-0.96-0.1.20060mlcs4.i586.rpm da03bea8d9ee43b6a26161f915e2dcf9 corporate/4.0/SRPMS/clamav-0.96-0.1.20060mlcs4.src.rpm Corporate 4.0/X86_64: 89a192c1ea1cdc678db652dc42df691e corporate/4.0/x86_64/clamav-0.96-0.1.20060mlcs4.x86_64.rpm 1ab9901f75ba6367905365097689c4ed corporate/4.0/x86_64/clamav-db-0.96-0.1.20060mlcs4.x86_64.rpm 5fed440379b8b58c54f6963dabe78c52 corporate/4.0/x86_64/clamav-milter-0.96-0.1.20060mlcs4.x86_64.rpm 56c4c66f35fdf0b19fd98f722a039fb8 corporate/4.0/x86_64/clamd-0.96-0.1.20060mlcs4.x86_64.rpm 1145efa3ed5032ec72228461a1d2127b corporate/4.0/x86_64/lib64clamav6-0.96-0.1.20060mlcs4.x86_64.rpm a9d60021af0aa48ea051612d1a5a77d9 corporate/4.0/x86_64/lib64clamav-devel-0.96-0.1.20060mlcs4.x86_64.rpm da03bea8d9ee43b6a26161f915e2dcf9 corporate/4.0/SRPMS/clamav-0.96-0.1.20060mlcs4.src.rpm Mandriva Enterprise Server 5: 90e36dd55953ef2ec7d474a9fe884803 mes5/i586/clamav-0.96-0.1mdvmes5.1.i586.rpm 08007813bf57f6822a0b12076ccc7927 mes5/i586/clamav-db-0.96-0.1mdvmes5.1.i586.rpm 869146c059841f726e777402adf57024 mes5/i586/clamav-milter-0.96-0.1mdvmes5.1.i586.rpm f03e3941b56ac9c669de43fa35f2e866 mes5/i586/clamd-0.96-0.1mdvmes5.1.i586.rpm d22d4a4de191942a0e66980ce9b91b85 mes5/i586/libclamav6-0.96-0.1mdvmes5.1.i586.rpm 868e1684a7e3f53876bc91ac74b6cf8f mes5/i586/libclamav-devel-0.96-0.1mdvmes5.1.i586.rpm 39710975d4a682f07f4b35a62df09daa mes5/SRPMS/clamav-0.96-0.1mdvmes5.1.src.rpm Mandriva Enterprise Server 5/X86_64: b111e1d0a7a2c7f86e4fc51ae840d7de mes5/x86_64/clamav-0.96-0.1mdvmes5.1.x86_64.rpm 30c4f7bcaff541af1c9bf1d2d4633a2b mes5/x86_64/clamav-db-0.96-0.1mdvmes5.1.x86_64.rpm 01bb253f6328f9473ffc0a167ca44a92 mes5/x86_64/clamav-milte
Re: [Clamav-users] error in make
On Apr 18, 2010, at 12:46 PM, neidorff wrote: On 4/18/10, Jim Preston wrote: Chuck Swiger wrote: On Apr 18, 2010, at 7:14 AM, neidorff wrote: Thanks. That did help. Now I'm getting a problem starting the daemon. The error that I am getting is: [r...@neidorff ~]# /etc/init.d/clamd start Starting Clam AV daemon: ERROR: Missing argument for option at line 33 ERROR: Can't open/parse the config file /usr/local/etc/clamd.conf [FAILED] I've checked the clamd.conf file. It looks fine. The problem isn't in your /etc/init.d/clamd startup script, although that seems to believe clamd.conf should be under /etc rather than /usr/ local/etc (and they should agree). Instead do something like: emacs +33 /usr/local/etc/clamd.conf ...to check on the specific line. My guess is that it is something like "LogTime" which should be "LogTime yes" nowadays. Regards, SOLVED!!! Many thanks for all the help. I fixed the path issues. Also, I found the new syntax for clamd.conf in the man page, corrected the file, removed some deprecated stuff, replaced the old version of freshclam (which didn't get upgraded with the install of 0.96) and now the system is working happily. Mark (after 3 days without the server working, I am very releived!!!) Glad you got it going. Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
> Shame you haven't talked to to others - like havp for example - before > doing this. The announcement to EOL the old releases was made at the start of october last year. If people using clam as an integral part of their software don't read announcements, what fault is that of the clam developers? They had 6 months to sort it out. -- Spiro Harvey Knossos Networks Ltd 021-295-1923 www.knossos.net.nz signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
> 1) If it aint broke, don't fix it. It works, has worked reliably for > several years, and was working fine yesterday. It's uptime is And now it's broken. So you have to fix it. Life on the edge is scary for some sysadmins, eh? > currently 405 days, and then the last downtime was to physically move > the server. So for 405 days you've done no kernel patches? Awesome. I bet that server's a bunch of remote exploits waiting to happen (if they haven't already). Using massive uptimes to prove how cool your server is actually just shows that you're not doing the right maintenance. > 2) If it aint broke - don't fix it. There's no way I'd attempt a > major upgrade in-place when it's a live server used 24*7. For various > internal reasons (which I'm sure you can guess) I don't have the > resources to do anything but an in-place upgrade if I want to upgrade. Well if they don't want patches on it, and they're not prepared to give you money to have a backup server to do upgrades on, then it can't be as critical as they're telling you. > 3) I can accept that software will go out of support - but I never > expected a Miscrosoft-esque remote shutdown. You should have expected it 6 months ago when the announcement was made. signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
On 4/18/10 1:27 PM, Spiro Harvey wrote: Shame you haven't talked to to others - like havp for example - before doing this. The announcement to EOL the old releases was made at the start of october last year. If people using clam as an integral part of their software don't read announcements, what fault is that of the clam developers? They had 6 months to sort it out. The people that had problems probably download signatures straight into the signature directory that clamd uses. I drop mine into a holding directory where I can test them first. Yes, I know that is all built into freshclam, but I'd rather know ahead of time if a sig is going to be harmful. I use the exact same process for checking SaneSecurity and other third-party signatures. I didn't need it this time because I'd upgraded long ago, but it's not a bad process. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
Sh They've simmered down, I don't need the issue stirred up again Spiro Harvey wrote: Shame you haven't talked to to others - like havp for example - before doing this. The announcement to EOL the old releases was made at the start of october last year. If people using clam as an integral part of their software don't read announcements, what fault is that of the clam developers? They had 6 months to sort it out. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Big problem (Malformed database) after update to 0.96
>> >> # /usr/sbin/clamd >> LibClamAV Error: cli_cvdload: Corrupted CVD header >> LibClamAV Error: Can't load /usr/local/share/clamav/daily.cvd: >> Malformed database >> ERROR: Malformed database >> Closing the main socket. > > Did you get this resolved? Sending this off-list on purpose as it would just > be noise on the list since it is just a clarification request. > > Thanks, Jim > Hi! Solved ... Here the details: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1950 Thanks to Török Edwin, aCaB and the ClamAV Team! Upgrading zlib to 1.2.4 I've solved the problem, Regards --- Sim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
On Apr 18, 2010, at 1:40 PM, Ken Campney wrote: Sh They've simmered down, I don't need the issue stirred up again Spiro Harvey wrote: Shame you haven't talked to to others - like havp for example - before doing this. The announcement to EOL the old releases was made at the start of october last year. If people using clam as an integral part of their software don't read announcements, what fault is that of the clam developers? They had 6 months to sort it out. And you run the risk of being called the "most arrogant and ignorant person on the Internet"... Oh my Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Lots of "pread fail" warnings during scanning
On 18 Apr 2010, at 21:47, Török Edwin wrote: On 2010-04-18 22:39, Hauke Duden wrote: Compiling and installing went well. I also ran the unit tests and they all passed. But I then did a full scan of the machine and got lots and lots of warnings like this: LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for 4096 bytes, got 5 LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for 4096 bytes, got 2 LibClamAV Warning: pread fail: page 0 pages 1 map-offset 0 - asked for 4096 bytes, got 11 Can you find the file that triggers these warnings? (if you use clamscan -rvi, it'll print the filename before scanning it, so you can easily associate warning message with file). I did what you asked me to do and it seems that the problem is not in clamav. The files in question are marked as having a size of 4096, but when I open them I only get a few bytes of data. The strange thing is that they are all in /sys. Some in /sys/module, some in /sys/kernel and some in /sys/hypervisor. Have you encountered anything like this before? Are these special files that should not be scanned? If so, what directories should I exclude? Best regards, Hauke ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
yup, that's me, though in all honesty the comment was supposed to read "They've simmered down, I don't "think the issue needs stirring up again" Proof reading is a wonderful thing when not practiced in moderation :\ And you run the risk of being called the "most arrogant and ignorant person on the Internet"... Oh my ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
On Apr 18, 2010, at 2:39 PM, Ken Campney wrote: yup, that's me, though in all honesty the comment was supposed to read "They've simmered down, I don't "think the issue needs stirring up again" Proof reading is a wonderful thing when not practiced in moderation :\ And you run the risk of being called the "most arrogant and ignorant person on the Internet"... Oh my No, I was referring to personal attacks against me and my contributions to the fray Fri and Sat Jim ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Lots of "pread fail" warnings during scanning
On 4/18/2010 5:16 PM, Hauke Duden wrote: I did what you asked me to do and it seems that the problem is not in clamav. The files in question are marked as having a size of 4096, but when I open them I only get a few bytes of data. The strange thing is that they are all in /sys. Some in /sys/module, some in /sys/kernel and some in /sys/hypervisor. Have you encountered anything like this before? Are these special files that should not be scanned? If so, what directories should I exclude? I was guessing that was going to be the case when I saw your mail. Yes, exclude: /dev /proc and /sys -- Chris ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Lots of "pread fail" warnings during scanning
On 18 Apr 2010, at 23:49, Chris Meadors wrote: On 4/18/2010 5:16 PM, Hauke Duden wrote: I did what you asked me to do and it seems that the problem is not in clamav. The files in question are marked as having a size of 4096, but when I open them I only get a few bytes of data. The strange thing is that they are all in /sys. Some in /sys/module, some in /sys/kernel and some in /sys/hypervisor. Have you encountered anything like this before? Are these special files that should not be scanned? If so, what directories should I exclude? I was guessing that was going to be the case when I saw your mail. Yes, exclude: /dev /proc and /sys OK. Sorry for the confusion. Shouldn't this be in the FAQ (or was I just too blind to find it?)? I'd hate to think that I am the only one making this mistake. Best regards, Hauke ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Lots of "pread fail" warnings during scanning
On 4/18/10 3:11 PM, Hauke Duden wrote: OK. Sorry for the confusion. Shouldn't this be in the FAQ (or was I just too blind to find it?)? I'd hate to think that I am the only one making this mistake. ClamAV is an antivirus tool. It is reasonable to expect it will be used on file systems where there is a reasonable expectation of finding a virus. The file systems you scanned are pseudo file systems created at each boot up, and there is no possibility of finding a virus there, hence no reason to look. Those file systems need to be well understood by the admin as it is possible to create a lot of problems for the system if they are misused. dp ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] EOL
Christopher X. Candreva wrote: > And you can cut the crap about "well you should have configured your system to not stop when ClamAV stopped" - that's rubbish because it's already been made perfectly clear right at the start of one of these threads that the project team consider any configuration that doesn't > break if ClamAV isn't working right to be broken. As the originator of those comments, you have misquoted me. The project team consider any CLAMD configuration -- not any MAIL configuration -- that doesn't break CLAMD if ClamAV isn't working right to be broken. Because of this, it has been recomended, repeatedly, for years, that mail systems be configured to deliver mail unfiltered if the milter fails. Ah, now that is being very disingenious again - and it's logically inconsistent with the stated position. What you are saying is that ClamAV should NOT work if there is a problem because to not work would expose people to having their mail not checked when they expect it to be. But they also recommend configuring your system so that if ClamAV doesn't work, it will pass the mail unfiltered. So ClamAV as a package won't silently 'not work' for the safety of users - and this has been the justification for their approach to this issue. But at the very same time they are recommending a setup which will silently not scan mail if there's a problem with ClamAV. Interesting logic there guys. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] (no subject)
Spiro Harvey wrote: So for 405 days you've done no kernel patches? Awesome. I bet that server's a bunch of remote exploits waiting to happen (if they haven't already). Using massive uptimes to prove how cool your server is actually just shows that you're not doing the right maintenance. Or it could just be that applying a layered approach to security means that those vulnerabilities that are there, aren't exploitable. But then just running a fully up to date system is no guarantee - on a different server we did get caught by a problem, one not fixed by any kernel version available at the time from the Debian. Solution - turn off the features that exposed the vulnerability. That's the only problem I've had, in several years of running multiple public facing servers. Risk is not black and white. Trying to eliminate risk is about as fruitful as p***ing into the wind. Managing risk is a different matter. There are risks in not updating, there are risks in updating - how you weight those risks is a matter of preference, judgement, and practicality. You're entitled to your opinion - it just differs from mine. > 2) If it aint broke - don't fix it. There's no way I'd attempt a major upgrade in-place when it's a live server used 24*7. For various internal reasons (which I'm sure you can guess) I don't have the resources to do anything but an in-place upgrade if I want to upgrade. Well if they don't want patches on it, and they're not prepared to give you money to have a backup server to do upgrades on, then it can't be as critical as they're telling you. Or it could be a reflection of management priorities - the job pays the bills, it doesn't mean I like all of it. > 3) I can accept that software will go out of support - but I never expected a Miscrosoft-esque remote shutdown. You should have expected it 6 months ago when the announcement was made. Well I could have if I'd seen that - but that ground's been covered to death already. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Thanks for the weekend entertainment
Cody Konior wrote: I don't know Simon, though I can't help but see his attitude and comments as a reflection of some other consultants / systems administrators whom I intensely dislike. Then I think you have got the wrong impression of what I do and how I do it. If it's any consolation though, some of the other posters have been worse, to the point of being almost comical. Some people really don't help their own cause. Giampaolo, you're one of us. You may have a dissenting opinion That's interesting. The impression I have is that he has similar opinions to me. I believe I am also "one of you", but without the religious zeal some people have exhibited in these threads. I too try and provide value to my clients (I'm not a consultant BTW, I'm a technical specialist in a small IT services & hosting company though I guess the line is a bit blurred), I do it because I like it (mostly, and I certainly aren't in my current post for the money), and I try to do things with professional ethical standards (and I've had disagreements with managers over the years when their lack of ethics has conflicted with mine). And I do actually contribute to a number of FOSS projects - not in cash, but in things like answering users (frequently FAQ) queries on mailing lists and so on. And of course, taking every opportunity to demonstrate that it can be an alternative option. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] Lots of "pread fail" warnings during scanning
On 19 Apr 2010, at 00:22, Dennis Peterson wrote: On 4/18/10 3:11 PM, Hauke Duden wrote: OK. Sorry for the confusion. Shouldn't this be in the FAQ (or was I just too blind to find it?)? I'd hate to think that I am the only one making this mistake. ClamAV is an antivirus tool. It is reasonable to expect it will be used on file systems where there is a reasonable expectation of finding a virus. The file systems you scanned are pseudo file systems created at each boot up, and there is no possibility of finding a virus there, hence no reason to look. Those file systems need to be well understood by the admin as it is possible to create a lot of problems for the system if they are misused. Well, ok, you can say "You should have known that.". But no one knows everything they "should know". I am a little surprised that you are opposed to adding this to the FAQ. Am I really the only one who had that problem? To me it just seems like a common stumbling block. The reasoning was that every exclusion creates a new hole for a virus to hide in. And adding it to the FAQ will not only make the problem easier to solve for users, but it will also decrease the support work on the mailing list. Best regards, Hauke ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] EOL
> So ClamAV as a package won't silently 'not work' for the safety of > users - and this has been the justification for their approach to > this issue. But at the very same time they are recommending a setup > which will silently not scan mail if there's a problem with ClamAV. I guess it depends on the definition of "silent" and which point of view is pertinent. Just 30 minutes ago I was battling one of our clam installs. Being a higher usage (outgoing only) server, the upgrade from 0.95.x to 0.96 just happened after I was happy that everything was working well on the others. Long story short, the active clamav-milter.conf was pointing to the wrong directory for the socket (but it was similar enough I didn't notice on first (or fourth) glance). Sendmail couldn't connect to clamd thru the milter. Everything else worked fine, mail kept flowing, spamassassin went about its business, but nothing was clammed for 20 minutes. So from the remote point of view, mail kept flowing, and the errors were "silent." The log files, of course, were not silent. signature.asc Description: PGP signature ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] /tmp/ directory filling up
Dear people, I have seen a couple of threads related to a version upgrade of clamav. I was running clamav v0.94 and suddenly experienced a harddisk that started filling up with clamav folders with names like /tmp/clamav-63f56fc3114e9716 . This caused my mail server (and websites) to stop working. Very frustrating... I have upgraded the version to v0.95.3 . Unfortunately the problem still remains. What can I do? My Debian is v5.0.4. Kind regards, Jeroen ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The news keeps getting better
lists wrote: > Multiple vulnerabilities has been found and corrected in clamav: Guys, just a bit of generic (i.e. not specific to the above) background about such evasion advisories. How it works aka how to get fame and glory with no effort (nor skills): 1. Pick up eicar.com and pack it up with the chosen archive type 2. Fuzz it into several thousand different files 3. Run N unpacking utilities and M AV toolkits against the above fileset 4. Find any tool in N succeeding against a sample for which at least one AV in M fails 5. Get yourself a 1337 name and post your 3v4510n!!1 advisory 6. Wait for mitre to pick it up and assign a CVE id to it (don't worry no matter how crappy or inaccurate your description is, they surely will) Now this sounds quite severe, doesn't it? Since an antivirus is a security tool, if we can bypass it then we have a security bug. And that's quite correct. However (and that's what most people don't realise), is an archive handler bypass sufficient to bypass the AV as a whole? Fortunately no. ClamAV (but I'm sure this is the case with every other AV on the planet) uses archive and runtime packers handlers as mere helpers. They simply make it easier and more efficient to write signatures. But nothing stops us from publishing signatures against the raw archive. In fact, that's exactly what we do against archive formats and runtime packers that we don't currently handle. So, what's the practical impact of evasion sploits? In most cases, close to zero. How many malicious samples have we seen that actively exploit archive evasion? Zero. What happens if, in the future, we'll see malware exploiting them? We'll simply catch them with a signature (or bytecode) based on the raw archive file. What happens when we receive such advisories? We file comments to the reporter and, in the next stable version, we improve the code to handle more bastardized samples. We then notify the reporter which in no case have ever bothered to integrate our comments. Oh and one final note about the accuracy: > ClamAV before 0.96 does not properly handle the (1) CAB and (2) 7z file > formats, which allows remote attackers to bypass virus detection via It's quite funny to hear that the 7z handler is vulnerable in versions <0.96 because it was, in fact, introduced in 0.96... :) Cheers, --acab ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
[Clamav-users] v0.96 Compile error: floating constant exceeds range of 'float' on Mac OS X 10.4.11 (Intel)
I asked this question last week, but haven't got any replies. I'm re-posting it because a) it will give everyone a break from the 0.94 EOL tweet wars :-) and b) I'll try to provide more info. Any help would be much appreciated, as obviously I want to run 0.96! System is running Mac OS X 10.4.11 on an Intel-based Mac Mini. ./configure CFLAGS="-O0" checking build system type... i386-apple-darwin8.11.1 checking host system type... i386-apple-darwin8.11.1 checking target system type... i386-apple-darwin8.11.1 creating target.h - canonical system defines checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... config/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking how to create a ustar tar archive... gnutar checking for gawk... (cached) awk checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p checking the name lister (/usr/bin/nm -p) interface... BSD nm checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking for /usr/bin/ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -p output from gcc object... ok checking for dsymutil... no checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... otool64 checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common -DPIC checking if gcc PIC flag -fno-common -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.11.1 dyld checking how to hardcode library paths into programs... immediate checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking which extension is used for runtime loadable modules... .so checking which variable specifies run-time module search path... DYLD_LIBRARY_PATH checking for the default library search path... /usr/local/lib /lib /usr/lib checking for library containing dlopen... none required checking for dlerror... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dld_link in -ldld... no checking for _ prefix in compiled symbols... yes checking whether we have to add an underscore for dlsym... no checking whether deplibs are loaded by dlopen... yes checking for argz.h... no checking for error_t... no checking for argz_add... no checking for argz_append... no checking for argz_count... no checking for argz_create_sep... no checking for argz_insert... no checking for argz_next... no checking for argz_stringify... no checking whether libtool supports -dlopen/-dlpreopen... yes checking for ltdl.h... yes checking whether lt_dlinterface_register is declare
Re: [Clamav-users] The EOL tweets
Quoting Giampaolo Tomassoni : In 6 months there were many clamav updates. I would have put the Signature updates, yes, but not code updates. To make any changes, you need code updates, not signature updates. But then, we've about beat this horse to death... -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [Clamav-users] The EOL tweets
Quoting Stephan von Krawczynski : And really, the whole idea of eol'ing GPL software is really violating the moral ground. And that is what makes people upset. Almost every GPL software does a EOL system. Unless you mean EOL via kill-bit then this statement doesn't make sense... EOL is a normal part of software life-cycle, as has been as long as I've been in the business (which has been about 30 years now). Anyway, this is hopefully my last post on this thread... Been way too much already... I think everything which could possibly need to be said has been said by now. -- Regards, Stephan -- Eric Rostetter The Department of Physics The University of Texas at Austin Go Longhorns! ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
