[Avcheck] avcheck+drweb over NFS

Michael Tokarev mjt@tls.msk.ru
Sat, 27 Jul 2002 15:34:54 +0400


adi wrote:
> 
> I put drwebd on separate machine, make it listen at port 3000,
> and make drwebd 'working' directory mounted on my postfix+avcheck
> machine over nfs.
> 
> On postfix+avcheck machine, this nfs mounted partition is use
> for avcheck operation. avcheck contact drwebd daemon over tcp...
> etc... etc...
> 
> The above scenarion failed on the first try. On very rare
> occasion drweb barfing about 'error reading input'. Then I think
> that there are some trouble with drwebd to read temp file that
> already written by avcheck on nfs mounted partition.

So now what drweb can't read?  A message or a command?  I
suspect it's a message.

> Looking at the code (avcheck-0.9pre for an example), avcheck
> doesn't call fsync() after writing the tempfile.

Yes.  If there was fsync(), things will be much slower.  Most
of a time, temporary message keept solely in memory (in filesystem
cache) and not gets written to disk at all.

>    Then I change
> the code a little bit like this:

[fsync() added and message file closed]

So does it works now?  If it is, I think there may be an option
added for this (to sync a file before calling a virusscanner).
But I'm afraid this will be even more slower on nfs compared to
local disk, since fsync() should return only after *remote*
system comitted a file to disk, not after local system sent a
file over the network.

[]
> I wonder if there are several alternatives to make avcheck+drweb
> operation more reliable over NFS (?)

DrWeb is able to accept a message (whole message) over it's control
socket.  This method maybe used here, but drweb's docs states that
this may work much slower (I personally don't know what's the problem
except of the unknown amount of memory needed for this mode).

I thought about this - keeping a message only in memory - for messages
smaller than a configurable size.  This does not work with avp - at
all, since it may use shared memory only and it's shared memory usage
is seriously broken (basically, only one client may talk with avp
at a time via shared memory, or some non-trivial work should be done
in the client to work around this brokeness).  And avp does not work
via TCP (read: if it's on another machine).  This last "issue" applies
to sophie as well, and in fact to most virusscanners (btw, I think it's
more "correct" for a virusscanner to listen on local unix socket instead
of to the network).

Another (relatively small) issue is that e.g. with postfix, message
passed via pipe, so there is no way to know it's size before reading
it all.  Postfix provides $size macro that can be used in command line,
but unfortunately, it is an estimation only, and it's "non-portable"
feature (I don't know if other MTAs provides similar macro, but avcheck
currently works with postfix only anyway).

Concerning using another machine for virusscanning - there are several
questions.  First of all, this is - *why* ;).  I just don't know a
reason why this may be needed (not to say there is no such reason,
but that just *I* don't know it yet).  If this question popped up,
there should be some reason...

If that should be done, I think avcheck should have an SMTP server
implementation - the best one IMHO: only standard postfix's SMTP
daemon will be used on "sending" side (no additional forks etc),
file may be stored in memory (or in filesystem cache) just like
it currently stored, minimal overhead.  And this may be implemented
(by the means of another program like avcheckd, with parts from
avcheck).

> I should say thanks to Sergey Akhapkin for his patient :-)

Oh yes.  It seems he is very nice person.  I just like all the
drweb folks for their support.

/mjt