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 -- Steve <st...@greengecko.co.nz> _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
