Re: [clamav-users] My outdated Clam.
On Wed, Mar 14, 2012 at 8:12 AM, Steve Kirkby k...@today.plus.com wrote:
Shawn Bakhtiar said:
It's [Clam] not just good, it's great .
I am sure it is. But it is only for highly technically competent people. (And
there is nothing wrong in that.)
I disagree with that assertion. ClamAV in it's source form is for
any moderately competent Unix / Linux System Administrator. You do not
have to be highly technically competent to be a good Sys Admin, you
need to know some command line basics and be able to follow
instructions.
I agree that ClamAV in it's source form is NOT for the typical end
user, especially an end user who is not comfortable with the command
line user interface.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [clamav-users] Compiling and installing from an NFS mount
On Mon, Mar 12, 2012 at 5:33 PM, Forrest Aldrich for...@gmail.com wrote:
Without digging into how this works, I believe I see what's going on -- but
I wonder if there's a clever way around this. I really don't want to go
through and change the mounts to read-write -- they are read-only for a
reason -- or copy the code over and install each individually.
Why not just build it on the NFS server (for all your platforms)
and run it from the RO NFS mount instead of trying to install from
there ?
I have done a similar thing with Solaris and Non-Global Zones.
ClamAV is built in the read-write Global zone, and then all the
Non-Global zones have read-only access to the executable and database.
Freshclam is run in the Global Zone to update the database.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [clamav-users] Clarification of report needed
On Fri, Sep 2, 2011 at 11:37 AM, Anne Wilson cannewil...@googlemail.com wrote:
No. As I reported yesterday, that returns
ls: cannot access
/home/anne/.kde/share/apps/kmail/imap/.1687036093.directory/.INBOX.directory/Newsletters:
No such file or directory
Anne,
Typical troubleshooting something like this (a problem is reported
in a certain file or directory that you cannot later find) involves
walking the *entire* path, starting at the root (/) and seeing where
the trail ends. For example, start with:
cd /home/anne/.kde
ls
and see what is there, does share exist, if so then
cd share
ls
and see if apps exists, if it does then
cd apps
ls
... until you get to the point where the path component you are
looking for does NOT exist. The question then becomes why did it exist
in the past and it does not now. Perhaps you will find a similar
directory with a different number at the beginning. Perhaps the
application changes that number as part of the revision control
sequence on it's data.
Just saying that ClamAV is reporting finding things in files that do
not exist is not a terribly helpful statement.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Designer: Frankenstein, A New Musical
(http://www.facebook.com/event.php?eid=123170297765140)
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [clamav-users] Clarification of report needed
On Sat, Sep 3, 2011 at 4:50 AM, Anne Wilson cannewil...@googlemail.com wrote:
No, you are misunderstanding what I have said. If you look using a file
manager, you will see the directory the report mentions.
This is the first time I recall you mentioning use of a file manager.
On Aug. 31 you said: Those are (empty) directories, created by KMail.
referring to
/home/anne/.kde/share/apps/kmail/imap/.1687036093.directory/.INBOX.directory/Newsletters:
and one other.
Then on Sep 1 you said: ls: cannot access
/home/anne/.kde/share/apps/kmail/imap/.1687036093.directory/.INBOX.directory/Newsletters:
No such file or directory
and
Since these folders are created by KMail, I assume they act as some sort of
pointer but I can't see any clue as to exactly what they are.
Try doing that in a
terminal, and where you get beyond .kde/share/apps/kmail/imap you start
getting No such file or directory.
So you are saying that a file manager and a command line shell are
returning different information? That implies that you are running
each with different rights (as a different user or as part of
different groups).
Or that the file manager has something cached that no longer exists.
Did you try asking the file manager to refesh it's view of the
directory?
If you are logged in as root and the filesystems are all local, you
should be able to see everything via the shell.
They appear to be virtual directories and
files of some sort, related to the files in ~/Maildir.
There are a limited number of ways to have virtual directories in
Unix-like OSes, all of which will show up via a shell just as much as
via a file manager.
Interestingly, if you
look in Dolphin at the properties of first directory that bash says doesn't
exist it says that it is 101.4 MB in 529 files, 141 sub-folders. I don't
understand exactly how this is working, but once I had realised that, I could
trace the directories within Maildir - the snag being that because ClamAV is
pointing to the virtual directory it isn't indicating which mail message
contains the problem.
If KMail is using MBox format to store local copies of the IMAP
messages, then they (the messages) will not be in directories, but in
one file per IMAP folder (not one directory per folder and one message
per file, that would be MDir format). I do not know the workings of
KMail, so I do not know if this is the case, but it would explain the
path that ClamAV is reporting.
The whole explanation of this has only become apparent as I have dug deeper.
Of course I first explored using your method - that was when I first came
across
this No such file or directory statement.
And you did not share that knowledge, such as I can see directory X
but when I try to look at directory X/Y ls cannot list it would have
gone a long way to clarify what you were doing.
At no point have I intended this to be a criticism of ClamAV - apart from the
fact that it can't deal with this particular situation very well. It's
probably not fair to expect it to either. I wanted some helpful hints as to
how to find the offending messages.
Then you need to dig into how KMail manages it's local copies of IMAP messages.
There has been some useful information
about SaneSecurity which I had not previously known, but I'm still no nearer
finding the offending messages, and it doesn't look as though I will be able
to.
I'll use the weekend to consider my options here - I don't want to erase a
whole directory of messages for one that is merely spam in the eyes of
SaneSecurity, so I may have to simply ignore the two remaining messages.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Designer: Frankenstein, A New Musical
(http://www.facebook.com/event.php?eid=123170297765140)
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [clamav-users] Solaris 10 compile / unit_tests unrar problem
2011/6/27 Török Edwin ed...@clamav.net:
This will tell you the search path used by ClamAV to load unrar:
$ grep LT_DLSEARCH_PATH clamav-config.h
Thanks for the pointer.
On my box it is:
/lib:/usr/lib:/usr/local/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/lib32:/usr/lib32
On my system it is just:
#define LT_DLSEARCH_PATH /lib:/usr/lib
Is it supposed to be updated by ./configure ? I know I can just go in
and change it, but is there an automatic mechanism to update it ?
Even though the check-log says that it is looking in the right place,
it is really only looking at the locations specified here.
--
{1-2-3-4-5-6-7-}
Paul Kraus
- Senior Systems Architect, Garnet River ( http://www.garnetriver.com/ )
- Sound Coordinator, Schenectady Light Opera Company (
http://www.sloctheater.org/ )
- Technical Advisor, RPI Players
___
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
Re: [clamav-users] Solaris 10 compile / unit_tests unrar problem
2011/6/27 Török Edwin ed...@clamav.net: On 06/27/2011 11:37 PM, Paul Kraus wrote: 2011/6/27 Török Edwin ed...@clamav.net: This will tell you the search path used by ClamAV to load unrar: $ grep LT_DLSEARCH_PATH clamav-config.h Thanks for the pointer. On my box it is: /lib:/usr/lib:/usr/local/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu:/lib32:/usr/lib32 On my system it is just: #define LT_DLSEARCH_PATH /lib:/usr/lib Is it supposed to be updated by ./configure ? Yes, it is generated by configure, is it wrong? Well ... that is the default system (OS) library search path (/lib:/usr/lib), but the clamav libraries get installed in /usr/local/lib. But the actual search path used at runtime is just a subset of that, just $libdir (where libclamav.so is installed). That's what I thought, but it does not appear to be looking there for the unrar libraries. I know I can just go in and change it, but is there an automatic mechanism to update it ? Even though the check-log says that it is looking in the right place, it is really only looking at the locations specified here. I tried adding /usr/local/lib to LT_DLSEARCH_PATH, but that had no (positive) effect. more unit_tests/test-suite.log == ClamAV 0.97.1: unit_tests/test-suite.log == 2 of 7 tests failed. (6 tests were not run). .. contents:: :depth: 2 SKIP: check_unit_vg.sh (exit: 77) = *** valgrind tests skipped by default, use 'make check VG=1' to activate FAIL: check1_clamscan.sh (exit: 42) === LibClamAV debug: searching for unrar, user-searchpath: /usr/local/lib LibClamAV debug: searching for unrar: libclamunrar_iface.so.6.1.10 not found LibClamAV debug: searching for unrar: libclamunrar_iface.so.6 not found LibClamAV debug: searching for unrar: libclamunrar_iface.so not found LibClamAV debug: searching for unrar: libclamunrar_iface.a not found LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable LibClamAV debug: Initialized 0.97.1 engine ... ls -l /usr/local/lib/libclamunrar_iface* -rw-r--r-- 1 root root 29280 Jun 27 16:50 /usr/local/lib/libclamunrar_iface.a -rwxr-xr-x 1 root root 965 Jun 27 16:50 /usr/local/lib/libclamunrar_iface.la So the test log file appears to be lying ... it sys it is checking /usr/local/lib and can't find the unrar libraries, but they _are_ there. Here is my configure line: $ ./configure --disable-clamav --enable-check --disable-shared --enable-static We are NOT running clamd (so we don't need the clamav user). the code is just called as clamscan to scan individual files. Run clamscan --debug, and it'll tell you the exact searchpath and all the files it tries (try removing libclamunrar_iface.so* and see all the files it tries). Same error... $ truss -a -e -f -o truss.clamscan clamscan/clamscan --debug clamscan.debug 2clamscan.debug $ more clamscan.debug LibClamAV debug: searching for unrar, user-searchpath: /usr/local/lib LibClamAV debug: searching for unrar: libclamunrar_iface.so.6.1.10 not found LibClamAV debug: searching for unrar: libclamunrar_iface.so.6 not found LibClamAV debug: searching for unrar: libclamunrar_iface.so not found LibClamAV debug: searching for unrar: libclamunrar_iface.a not found LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable LibClamAV debug: Initialized 0.97.1 engine ... From the truss output (truss is a Solaris system call trace tool): after looking for other varients of the unrar libraries like this... 29077: access(/usr/local/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/local/ssl/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/local/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/share/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/sfw/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/openwin/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/dt/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/X11R6/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: access(/usr/lib/libclamunrar_iface.so, R_OK) Err#2 ENOENT 29077: stat(/usr/local/ssl/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2 ENOENT 29077: stat(/home/pkraus/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2 ENOENT 29077: stat(/usr/local/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2 ENOENT 29077: stat(/usr/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2 ENOENT 29077: stat(/usr/share/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2 ENOENT 29077: stat(/usr/sfw/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2 ENOENT 29077: stat(/usr/openwin/lib/libclamunrar_iface.so, 0xFFBFCBF8) Err#2
[clamav-users] Solaris 10 compile / unit_tests unrar problem
I looked through the archives and saw a number of issues related to this, but I did not see a definitive solution. I suspect that this is either a unit_tests issue -or- and issue with how the static executables get built. I am running Solaris 10 and building from source using the Oracle provided gcc (3.4.3, I know there are issues with the C++ compiler). Building 0.97.1 more config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by ClamAV configure 0.97.1, which was generated by GNU Autoconf 2.67. Invocation command line was $ ./configure --disable-clamav --enable-check --enable-static --disable-shared --prefix=/usr/local/src/test ## - ## ## Platform. ## ## - ## hostname = xxx uname -m = sun4u uname -r = 5.10 uname -s = SunOS uname -v = Generic_139555-08 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = xxx Release = 5.10 KernelID = Generic_139555-08 Machine = sun4u BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 8 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown snip and the ./configure exits cleanly the make exits cleanly (both show a couple warnings but no errors) I then do a make install to a test directory in order to get the libraries (unrar) someplace the make check will use them. I add that directory (/usr/local/src/test/lib) to LD_LIBRARY_PATH and export it (and, no, you do not have to do more than that under Solaris to add that directory to the library search path). make check reports PASS: check_clamav PASS: check_freshclam.sh PASS: check_sigtool.sh SKIP: check_unit_vg.sh FAIL: check1_clamscan.sh FAIL: check2_clamd.sh PASS: check3_clamd.sh PASS: check4_clamd.sh SKIP: check5_clamd_vg.sh SKIP: check6_clamd_vg.sh SKIP: check7_clamd_hg.sh SKIP: check8_clamd_hg.sh SKIP: check9_clamscan_vg.sh 2 of 7 tests failed (6 tests were not run) See unit_tests/test-suite.log Please report to http://bugs.clamav.net/ more unit_tests/test-suite.log == ClamAV 0.97.1: unit_tests/test-suite.log == 2 of 7 tests failed. (6 tests were not run). .. contents:: :depth: 2 SKIP: check_unit_vg.sh (exit: 77) = *** valgrind tests skipped by default, use 'make check VG=1' to activate FAIL: check1_clamscan.sh (exit: 42) === LibClamAV debug: searching for unrar, user-searchpath: /usr/local/src/test/lib LibClamAV debug: searching for unrar: libclamunrar_iface.so.6.1.10 not found LibClamAV debug: searching for unrar: libclamunrar_iface.so.6 not found LibClamAV debug: searching for unrar: libclamunrar_iface.so not found LibClamAV debug: searching for unrar: libclamunrar_iface.a not found LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar supp ort unavailable LibClamAV debug: Initialized 0.97.1 engine snip and ls -l /usr/local/src/test/lib total 10052 -rw-r--r-- 1 a b 4868060 Jun 21 16:03 libclamav.a -rwxr-xr-x 1 a b1112 Jun 21 16:03 libclamav.la -rw-r--r-- 1 a b 29280 Jun 21 16:03 libclamunrar_iface.a -rwxr-xr-x 1 a b 983 Jun 21 16:03 libclamunrar_iface.la -rw-r--r-- 1 a b 217788 Jun 21 16:03 libclamunrar.a -rwxr-xr-x 1 a b 924 Jun 21 16:03 libclamunrar.la drwxr-sr-x 2 a b 512 Jun 21 16:03 pkgconfig So the libraries are there, and the unit_tests are saying that they are looking there, but they are not finding the libraries. My next approach is going to be to try to compile with shared flags and see if I get different results. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
Re: [clamav-users] Solaris 10 compile / unit_tests unrar problem
On Tue, Jun 21, 2011 at 9:05 PM, aCaB aca...@digitalfuture.it wrote: On 06/21/11 22:54, Paul Kraus wrote: I suspect that this is either a unit_tests issue -or- and issue with how the static executables get built. [...] $ ./configure --disable-clamav --enable-check --enable-static --disable-shared Static unrar is unlikely to work since libclamav dlopen()'s it due to license restrictions and incompatibilities. That would explain why it seems to build it shared even when I --disable-shared. Thanks for the heads up. Do you really need a static build? For security reasons we want the ClamAV installation to be read only, so I build and install it in a Solaris 10 Global Zone and the Non-Global Zones all inherit the executables (and update the definitions there as well). Making it static is safer, as I can't guarantee what any user or application's library search path will be. I suppose if the code sets it's own library paths intelligently we should be OK. The shared build I tried earlier went down in flames with an odd permissions error on the bzip2 libraries. More when I am back in the office on Thursday. ___ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://www.clamav.net/support/ml
