Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 1 subscriber
  • Views 2561 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Various failures, one success. Windows and Linux

johnthesoftware

Hi,

I've used the standard EICAR anti-virus test file to check the operation of SophosAV on the following:

Windows XP Home 2002 SP2 Pentium
Windows 7 Enterprise 2009 SP1 Xeon E5430
RedHat Enterprise 5.1 - 2.6.15-53.el5 - gcc 4.1.2 -
Centos (CNServer) - 2.6.18-53.el5 - gcc 4.1.1

The only one that worked as expected was the RedHat installation, detecting the test file both on access and demand.  The XP and Windows 7 installations detected the test file on access. The Centos installation failed on both access and demand.

I was unable to test the on-demand operation of the Windows installations because although I explicitly selected a USB stick to be scanned, both Windows installations insisted on scanning the entire C: drive and I hadn't got the time to see what happened when they had completed.


The XP installation identified a legitimate (I think) file as a piece of 'malware' and refused to complete the scan until it was dealt with (which, because it was legit I didn't want to do).

The Centos installation indicates a problem in its log file 'Unable to load Talpa modules' though both the AV and Web services are running.

It's likely to be as much my ignorance as any shortcoming in the software but I'm running out of ideas.

All the installations are standalone. 

Linux: sav-linux-7-i386.tgz

Windows: savw_97_sa_sfx.exe

Thanks

J

:15199


This thread was automatically locked due to age.
Parents
  • 0

    In the case of a stripped down non-supported distribution the following are possible:

    a) Install gcc,make,kernel-headers - chmod make and gcc so only root can run them.

    b) Chained updating with addition TBP (Talpa Binary Pack): Basically run one machine will build environment updating,

    copy Local Cache Directory to exported location, use addtbp.sh to add a TBP to the exported location (CID); then configure stripped down machine to update from CID. Rember to update TBP every time a new kernel is released, and when Talpa is updated. TBP is located on build machine under <installation>/talpa/compiled/. Support may be able to help you if you want to do this.

    c) Manually copy TBP onto stripped down machine in the <installation>/talpa/override/ directory. Rember to update TBP every time a new kernel is released, and when Talpa is updated. TBP is located on build machine under <installation>/talpa/compiled/ . This is not a supported thing to do long term.

    Option a) is by far the easiest, and most used.

    :15257
Reply
  • 0

    In the case of a stripped down non-supported distribution the following are possible:

    a) Install gcc,make,kernel-headers - chmod make and gcc so only root can run them.

    b) Chained updating with addition TBP (Talpa Binary Pack): Basically run one machine will build environment updating,

    copy Local Cache Directory to exported location, use addtbp.sh to add a TBP to the exported location (CID); then configure stripped down machine to update from CID. Rember to update TBP every time a new kernel is released, and when Talpa is updated. TBP is located on build machine under <installation>/talpa/compiled/. Support may be able to help you if you want to do this.

    c) Manually copy TBP onto stripped down machine in the <installation>/talpa/override/ directory. Rember to update TBP every time a new kernel is released, and when Talpa is updated. TBP is located on build machine under <installation>/talpa/compiled/ . This is not a supported thing to do long term.

    Option a) is by far the easiest, and most used.

    :15257
Children
No Data