Steve wrote: > On Sat, 14 Feb 2009 20:57:52 -0800 > Dennis Peterson <denni...@inetnw.com> wrote: > >> Steve wrote: >>> On Sat, 14 Feb 2009 16:50:44 -0800 >>> Dennis Peterson <denni...@inetnw.com> wrote: >>> >>>> Steve wrote: >>>>> On Sat, 14 Feb 2009 23:21:16 +0100 >>>>> aCaB <aca...@digitalfuture.it> wrote: >>>>> >>>>>> Steve wrote: >>>>>>> Unfortunately, no change. >>>>>> That's likely because you didn't update the svn checkout or recompiled, >>>>>> or reinstalled, or restarted the daemons. >>>>>> _______________________________________________ >>>>>> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net >>>>>> http://www.clamav.net/support/ml >>>>> Did you not check the version number in the clamd log, or the timestamps? >>>>> >>>> Are all vestiges of previous versions of ClamAV gone? Specifically, >>>> libraries. >>>> What do you get when running ldd against the ClamAV binaries? I suggest >>>> this >>>> only to eliminate a common and recurring problem with ClamAV installations >>>> and >>>> that is left-overs from earlier versions. >>>> >>>> dp >>>> _______________________________________________ >>>> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net >>>> http://www.clamav.net/support/ml >>> I shut everything down, ran the uninstall for 0.94.2, then the install from >>> svn, with no change ): >> >> Ok -- looks good so far. But... One thing I forgot to mention in the earlier >> note is to never ever trust the uninstall tool nor the rpm tool dejur to >> actually completely uninstall anything. They can fail with mysterious >> results. > I've had no problems with the uninstall/install method when building clamav > from source so far... and debian doesn't use rpm (: >> The other issue is any tests you do with ldd can be account-sensitive. Some >> accounts for example may have LD_LIBRARY_PATH defined, others not. Some >> systems >> admins set that as a global, some don't. Some systems (Solaris, for example) >> have global library paths set using crle, others use ldconfig. It's a crazy >> world. Then there are the hard-coded path dependencies built into the build >> process of specific applications. You absolutely cannot depend on version >> x.xx.x >> to uninstall version x.xx, so if you no longer have the earlier version >> source >> to do the uninstall you should expect to manually review the debris left >> behind. >> This is especially true of rpm's that come from different sources - the >> builders >> don't connect with each other to ensure one builder's package is compatible >> in >> any way with that of another builder. > I am the sysadm, installs/startups/tests are all run as root. I never use > LD_LIBRARY_PATH unless absolutely necessary, it's too much of a security > liability. This is all running on a 32 bit debian stable VPS. As I said > before, I uninstalled using 0.94.2 and installed the current subversion > install. I can find no fault with this, the developers of clamav have been > exemplary in this. > > All of this is built from source, I have never, ever mentioned rpms. >> What this means is don't trust anything, scan your environment to see if >> there >> are legacy bits laying about and get rid of them. You may not find them but >> if >> you do you certainly would not be the first. > Look, I'm a systems administrator, so I'm paid to be a pessimist (: >> dp >> _______________________________________________ >> Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net >> http://www.clamav.net/support/ml > My main frustration is that the only way I can get more information from the > applications is to rewrite the > code itself... at least it's written in a real language (runs for cover!). > but it would be great to be able to change the log level to get more detailed > info out. Then I would be able to take a more proactive approach in debugging > this problem. > > Cheers, > > Steve
Ok - I'm just a guy sitting here in Bellevue, Washington sharing experiences while having no specific information about your environment. Not everything (and often nothing) will apply. But you and I agree about LD_LIBRARY_PATH and other things. But I've been doing this for 30 years so when we get to this point and it still doesn't work I fall back on my favorite piece of advice. If you have a problem that is uncommon then very often something you are sure of is wrong. Best of luck getting it sorted out - pessimism is your friend :) dp _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
