    Antivirus program Doctor Web for Linux, FreeBSD and Solaris
                         Version 4.31

             Copyright (c) 1992-2004, Igor Daniloff
    Igor Daniloff's antivirus laboratory, DialogueScience, Inc.
                                                               
                     DrWeb Daemon for Unix
                  System administrator manual


1. What is DrWeb Daemon for Unix ?
2. Setting up DrWeb Daemon
3. About the keys (key files)
4. Launching DrWeb Daemon
5. Verifying DrWeb Daemon operability
6. Checking modes realized by DrWeb Daemon (local scanning)
7. Contacts


                1. What is DrWeb Daemon for Unix ?

DrWeb Daemon is an antivirus daemon, that in point of fact is an improved
antivirus scanner. But in contrast to the scanner loading bases and the
scanning module at every new start, the daemon loads these components
only once, when starting, and is always ready in the memory awaiting the
next scanning task. Besides, the daemon can carry out a few scans
simultaneously which provides on average faster response. In other respects
DrWeb Daemon has the same facilities as the other products of the DrWeb
family:

- it uses the kernel and the virus base used by all the other scanners of
the family;
- detects and cures all the known viruses; 
- performs scanning of packed files and archives.
Besides, recently the option of mail filtering based on header analyzing
has been added in DrWeb Daemon.

The fact that the daemon is always ready to function and has a comprehensible
and accessible protocol for scanning requests makes it a suitable
component for creating antivirus filters for mail systems and file servers.
Developers of DrWeb suggest the ready solutions on integration DrWeb Daemon
with CommuniGatePro, Sendmail, Postfix, Exim, QMail and Zmailer mail
systems, and also the solution on integrating with Samba file servers.
There may obviously be other fields of application of DrWeb Daemon,
although the listed ones are by now the principal ones.


                2. Setting up DrWeb Daemon

Naturally, you can run the daemon with the default settings, but it is
better to set it so that it would conform to your requirements and
conditions of utilization. The file drweb32.ini gets read by DrWeb Daemon
from the directory /etc/drweb. To use another configuration file you should
specify the full path to it in the command line key when starting DrWeb
Daemon, e.g.:

$ /usr/local/DrWeb/drwebd -ini=/usr/local/DrWeb/drwebd.ini

The configuration file drweb32.ini is a text file (so you can edit it in
your favorite text editor) organized in the following way:

--- beginning of the file ---
[Section 1 name]
Parameter1 = value1, ..., valueK
.....
ParameterM = value1, ..., valueK

.....

[Section X name]
Parameter1 = value1, ..., valueK
.....
ParameterY = value1, ..., valueK
--- end of the file ---

The ";" character (semicolon) at the beginning of the line marks a commented
line skipped by DrWeb Daemon when reading the parameters from the .ini file.

It is extremely important to note that if a parameter determining DrWeb 
Daemon is not set, it does not mean it has no value, it means that the 
default value will be applied (a common mistake coming along with the 
procedure of setting). Only few parameters are optional or have no default 
values, which will be specially indicated below. The values may be put 
in quotes (and should be put in quotes if they contain blanks). Some 
parameters may have a few values separated by "," (comma), it will be 
clearly indicated in the description of the parameter. If values are 
enclosed into {} in the parameter value field description, the parameter 
can take only one of them.

In the section name are indicated: the platform (scanner section); DrWeb
Daemon parameter section also contains Daemon suffix.

The description of the parameters will go as follows:

ParameterName = ParameterPseudoValue
        Description of the parameter
        {Whether it can have a few values}
        Default value: { value | absent }

Parameters common for the daemon and the scanner:

EnginePath = { path to the file, usual extension is dll }
        Location of drweb32.dll module (search module). This parameter is
        also used by the updating module to update the search module. You
        may specify relational path, but it is strongly recommended to make
        it absolute.
        Default value:
                "/opt/drweb/drweb32.dll" for Linux
                "/usr/local/drweb/drweb32.dll" for FreeBSD and Solaris.

VirusBase = { list of the paths (masks) to the files, usual extension is vdb }
        Masks for the loaded virus bases. This parameter is also used by
        the updating module to update antivirus' bases. A few masks can be
        enumerated.
        Default value:
                "/opt/drweb/*.vdb" for Linux
                "/usr/local/drweb/*.vdb" for FreeBSD and Solaris

UpdatePath = directory
        The parameter is used by the program update module and
        is compulsory if the module is used.
        Default value: no

Key = {path to the file, usual extension is key }
        Location of the file with the registration key. You may specify
        relational path, but it is strongly recommended to make it
        absolute.
        Default value:
                "/opt/drweb/drweb32.key" for Linux
                "/usr/local/drweb/drweb32.key" for FreeBSD and Solaris

LngFileName = { path to the language resource file, usual extension - dwl }
        Localization file location.
        Default value: absent (would be used English language)

CheckPackedFiles = { Yes | No }
        Should unpacking of the executable files packed by DIET, PKLITE
        etc. utilities be performed.
        Default value: Yes

CheckArchives =  { Yes | No }
        Should unpacking of the archives of ZIP (WinZip, InfoZIP...), RAR,
        ARJ, TAR, GZIP and CAB formats be performed.
        Default value: Yes

CheckEMailFiles = { Yes | No }
        Should files in e-mail formats get scanned.
        Default value: Yes

ScanPriority = { value }
        Priority of the scanning process. This value should be in the range
        -20 (highest) to 20 (lowest).
        Default value: 0

MaxFileSizeToExtract = { value in Kb }
        The maximum size of the file extracted from an archive. If the file
        in the archive exceeds the value it will be skipped. Note: a
        message with such a file will be treated as "mail bomb".
        Default value: absent (files of any size will be extracted)

MaxCompressionRatio = { value }
        Maximum compression ratio, i.e. ratio of the unpacked file length
        to the length of the packed file in the archive. If the ratio
        exceeds the value, the file will not be extracted and therefore
        will not be checked. Note: a message with such a file will be
        treated as "mail bomb".
        Default value: absent (compression ratio will be ingored)

CompressionCheckThreshold = { value in Kb }
        Maximum file size inside archive, beginning from which the
        maximum compression ratio will be checked (if enabled by
        MaxCompressionRatio switch). 
        Default value: absent (CompressionCheckThreshold will be ingored)

ScanFiles = { All | ByType | ByFormat }
        The files that will get checked after having been extracted from
        the archive. If ByType is set the so called file extensions are
        taken into account (file extension is the last suffix after "." in
        the file name; if there is no ".", file has no extension). The file
        extension values are set either by default, or in the parameter(s)
        FilesTypes. If ByFormat is set, only the files included into the
        checkable set get checked. The aim of the check is to find out
        whether they can be virus carriers, i.e. executable files (file
        name and extension are not taken into account). And only then only
        presumably executable files will be scanned for viruses. Important
        note: the All mode is always enabled in the mail files. ByType and
        ByFormat values can be applied only in "local" scanning mode.
        Default value: All

FilesTypes = { extension list }
        Types of files that will get checked if by type scanning is
        performed, i.e. ScanFiles parameters has ByType value. "*" and "?"
        characters admissible.
        Default value:
                "EXE, COM, SYS, OV?, BAT, BIN, DRV, PRG, BOO, SCR, CMD, VXD"
                "386, DLL, FON, DO?, XL?, WIZ, RTF, CL*, HT*, VB*, JS*, INF"
                "AR?, ZIP, R??, PP?, OBJ, LIB, HLP, MD?, INI, MBR, IMG, CSC"
                "CPL, MBP, SH*, PIF, MSG, CHM, REG, XML, PRC, TBB, ASP"

FollowLinks = { Yes | No }
        Should the symbolic links be followed when scanning.
        Default value: No

LogFileName = { file name }
        Log file name. You may specify "syslog" as name, the report will be
        logged by means of syslogd system service. Using syslog, pay
        attention to SyslogFacility and SyslogPriority options. Since
        syslog has a few files to log different events and different degrees
        of their importance, you can find out where the daemon's report will
        be written to, basing on these two parameters and the contents of
        the configuration file syslog (usually /etc/syslogd.conf).
        Default value: "syslog"

SyslogFacility = { "Daemon" | "Local0" .. "Local7" | "Kern" | "User" | "Mail" }
        Logging type if syslogd system service is used.
        Default value: "Daemon"

SyslogPriority = { "Alert" | "Warning" | "Notice" | "Info" | "Error" }
        Logging priority if syslogd system service is used.
        Default value: "Info"

LogScanned = { Yes | No }
        Should the information on all the checked objects independently
        infected or not get logged in the log file.
        Default value: No

LogPacked = { Yes | No }
        Should the additional information on the files packed by the DIET,
        PKLITE etc. utilities get logged in the log file.
        Default value: Yes

LogArchived = { Yes | No }
        Should the additional information on the archiving programs get
        logged in the log file.
        Default value: Yes

LogTime = { Yes | No }
        Should the time of every record get logged. The parameter has no
        meaning if LogFileName is "syslog".
        Default value: No

OutputMode = { Terminal | Quiet }
        Mode of output information on the console, Quiet cancels
        output.
        Default value: Terminal

RecodeNonprintable = { Yes | No }
        Mode of output of unvisible for this terminal symbols into the logfile.
        Default value: Yes
        
RecodeMode = { Replace | QuotedPrintable }
        Method of recoding of unvisible symbols, if RecodeNonprintable equal to 
        "Yes". Unvisible symbols would been replaced by RecodeChar (see below),
        if this option has "Replace" value.
        Default value: Replace

RecodeChar = { "?" | "_" | ... }
        Defines a symbol that would been placed instead of unvisible symbols,
        if RecodeMode option has "Replace" value.
        DefaultValue: "?"

Below the settings that can be described only in DrWeb Daemon section are
described.

Socket port [Interfaces]
Socket file [Access]
        Description of socket, used for communication with daemon.
        The first form describes TCP-socket, parameter {port} - decimal
        port number, {interfaces} - list of listening interface names or
        IP-addresses.
        Example: Socket 3000 127.0.0.1, 192.168.0.100
        The second form describes unix-socket, {file} - socket name,
        {access} - octal value of access rights.
        Example: Socket /var/run/drwebd.socket 666 
        Number of socket keys is not limited, daemon will work with all
        correctly described sockets.
        DefaultValue: Socket 3000 127.0.0.1 

ListeningQueue = "value"
        Defines sockets queue maximum size. Value may vary from 0 to
        SOMAXCONN (depends on the OS).

PidFile = { path to file }
        File name where information on its PID and Unix socket (if
        SocketMode is Unix) or port number (if SocketMode is TCP) will be
        written when the daemon gets started.
        Default value:
               "/var/run/drwebd.pid" (Attention!!! Only the programs executed
               with the root rights have write access to /var/run).

BusyFile = { path to file }
        Daemon's busy file name: it is created by the scanning "copy" of
        the daemon if having been commanded and gets removed after
        transmitting the result of its execution. File name created by
        every "copy" of the daemon gets expanded with a point and ASCIIZ
        representation of PID (e.g., /var/run/drwebd.bsy.123456).
        Default value: absent (file does not get created)

SocketTimeout = { value, seconds }
        Time of reception/transmission of all the data via the socket
        (without considering file scanning time).
        Default value: 40

FileTimeout = { value, seconds }
        Maximum checking time of a file.
        Default value: 40

StopOnFirstInfected = { Yes | No } 
        Cancel or not message checking after first virus detection.
        Setting to {Yes} value can minimize mail-server load and 
        message check time.
        Default value: No

User = { user name }
        The user whose rights the daemon is run under. It is recommended to
        create in the system a special drweb user which will be used by the
        daemon and some filters in future. It is undesirable to use DrWeb
        Daemon with root rights although it requires much less setting
        (particularly in the case of Samba servers).
        Default value:
               absent (that means that the daemon will use the rights of the
               user which has started it)

UserID = { numeric ID }
GroupID = { numeric ID }
        Group and user ID. Daemon will work with their rights. The
        parameters get ignored if the User parameter is set.
        Default value: absent

MaxChildren = { number }
        Sets maximum amount of simultaneously working child (scanning)
        processes. If Prefork parameter is set to "No" (see below),
        then new scan process is created for each query. If Prefork is
        set to "Yes" then daemon will start number of scan processes,
        equal to MaxChildren at startup.

PreFork = { Yes | No }
        Sets type of child (scan) processes creation procedure.

As we have already noted, DrWeb Daemon has embedded capacities of e-mail
filtering based on the system of e-mail messages header analysis. The
regulations of filtration are also set in drweb32.ini, they get checked
when being set, i.e. the first set rule will be checked first. The fact of
setting filter regulations DOES NOT mean they will be automatically
applied. To enable header analysis you should set the corresponding options
in the delivered filters or specify special flags if making home decisions
on the base of DrWeb Daemon. Regulation correspondence is searched until
the first suitable regulation is found and the action set by the regulation
is taken. 

RejectCondition { Set of rules }, AcceptCondition { Set of rules }
        Description of filter rules on message headers. Rules consist of
        header name and regular expression, describing meaning of this field.
        More then one rule can be merged with () and OR and AND operations.
        Example:
        RejectCondition Subject = "money" AND "Content-Type" = "text/html" 
        Special filtering rules include conditions "No Header" (means absence
        of this field, e.g. according to the rule "RejectCondition No From"
        all messages without field From will be filtered), "Header=8bit" (field
        contains 8-bit symbols).

MissingHeader { field list }
        Describes list of header fields, absence of which in the message 
        will filter this message. For example: MissingHeader "To", "From".

ScanEncodedHeaders { Yes | No } 
        Process or not message headers before decoding. For example,
        value Yes and rule "RejectCondition Subject = "iso-8859-5", allows
        to filter all messages with Subject field in iso-8859-5 encoding.

RejectPartCondition { ruleset }, AcceptPartCondition { ruleset }
        Parameters that work similarly to RejectCondition and
        AcceptCondition, but for use with particular message parts.
        Ruleset can be defined as FileName = "mask", where "mask" is
        POSIX 1003.2 compatible regular expression. This parameter works
        only if FilterParts is set to "Yes".

FilterParts = { Yes | No }
        Allows using RejectPartCondition and AcceptPartCondition, when
        set to "Yes". Default: "No".

                3. About the keys (key files)

In the DrWeb Daemon's distributive there is a demo key, the so called
Evaluation Key. If it is used DrWeb Daemon is restricted in the following:

- "traditional" archives (such as ZIP, RAR, TAR, GZIP & etc) do not get
checked, but it DOES NOT concern "pseudoarchives" (MAIL, HTML, UUE & etc) and
packed files (packed by DIET, PKLITE and other compressing programs);
- infected files do not get cured;
- in local scanning mode all the multipart-mime messages get evaluation
banner added.

The Key parameter is described in both sections because evaluation keys for
DrWeb Daemon and the scanner differ (the scanner has more restrictions).
Having purchased a license for DrWeb Daemon you will obtain a new key file
(usually it is drweb32.key) suitable both for the daemon and the scanner.
Now you should change settings in drweb32.ini. To link up the new key file
you should replace in both sections the value of the Key parameter by the
full path to drweb32.key file:

For example, "Key = /opt/drweb/drweb32.key".

Important note: the key file IS NOT a text file. It may not be edited in
any way, neither automatically nor converted by some programs. It often
happens that a too smart mail program converts the key file from DOS format
(with CR LF line ends (in hexadecimal notation 0D 0A) into UNIX format
(with LF line ends (in hexadecimal notation 0A)).

Here is one more example of problem cases when no key (neither the
evaluation one) is loaded. It is simple to find out whether the key file
has been loaded or not from the daemon's loading log file. In the adduced
example none of the keys has been loaded:

=== cut ===
Dr.Web daemon for Linux, version 4.27 (December 28, 2001)
Fri Feb  1 14:43:33 2002 This is an EVALUATION version with limited functionality!
Fri Feb  1 14:43:33 2002 To get your registration key, call regional dealer.
Fri Feb  1 14:43:33 2002 Loading /opt/drweb/drwtoday.vdb - Ok, virus records: 56
Fri Feb  1 14:43:34 2002 Loading /opt/drweb/drw42702.vdb - Ok, virus records: 116
Fri Feb  1 14:43:34 2002 Loading /opt/drweb/drw42701.vdb - Ok, virus records: 90
Fri Feb  1 14:43:34 2002 Loading /opt/drweb/drwebase.vdb - Ok, virus records: 27860
Fri Feb  1 14:43:34 2002 Daemon is installed, TCP socket created on port 3000
=== cut ===

The words "... EVALUATION version ..." make it rather unclear because it
seems that the Evaluation key has been loaded although it is no so. When
the key gets loaded (if the console output is enabled) there should be (at
least) the following records in the log file: Key File: {path/to/file} and
Registration info. Here it is, how the loading with the Evaluation key
looks like:

=== cut ===
Dr.Web daemon for Linux, version 4.27 (December 28, 2001)
Fri Feb  1 14:45:26 2002 Key file: /opt/drweb/drwebd.key
Fri Feb  1 14:45:26 2002 Registration info:
Fri Feb  1 14:45:26 2002 0100000002
Fri Feb  1 14:45:26 2002 Evaluation Key (ID Anti-Virus Lab. Ltd, St.Petersburg)
Fri Feb  1 14:45:26 2002 This is an EVALUATION version with limited functionality!
Fri Feb  1 14:45:26 2002 To get your registration key, call regional dealer.
Fri Feb  1 14:45:26 2002 Loading /opt/drweb/drwtoday.vdb - Ok, virus records: 56
Fri Feb  1 14:45:27 2002 Loading /opt/drweb/drw42702.vdb - Ok, virus records: 116
Fri Feb  1 14:45:27 2002 Loading /opt/drweb/drw42701.vdb - Ok, virus records: 90
Fri Feb  1 14:45:27 2002 Loading /opt/drweb/drwebase.vdb - Ok, virus records: 27860
Fri Feb  1 14:45:28 2002 Daemon is installed, TCP socket created on port 3000
=== cut ===

Loading of the daemon with the full-functional registration key looks like
the following:

=== cut ===
Dr.Web daemon for Linux, version 4.27 (December 28, 2001)
Fri Feb  1 14:50:03 2002 Key file: /opt/drweb/FILENAME.key
Fri Feb  1 14:50:03 2002 Registration info:
Fri Feb  1 14:50:03 2002 XXXXXXXXXX
Fri Feb  1 14:50:03 2002 USER OR COMPANY NAME
Fri Feb  1 14:50:03 2002 Loading /opt/drweb/drwtoday.vdb - Ok, virus records: 56
Fri Feb  1 14:50:03 2002 Loading /opt/drweb/drw42702.vdb - Ok, virus records: 116
Fri Feb  1 14:50:03 2002 Loading /opt/drweb/drw42701.vdb - Ok, virus records: 90
Fri Feb  1 14:50:04 2002 Loading /opt/drweb/drwebase.vdb - Ok, virus records: 27860
Fri Feb  1 14:50:04 2002 Daemon is installed, TCP socket created on port 3000
=== cut ===
    

                4. Launching DrWeb Daemon

When loading daemon does the following:

- searches and loads the configuration file; if the file was not found,
DrWeb Daemon terminates loading. Path to the configuration file may be
specified in launching parameters with the help of the key
-ini:{path/to/your/drweb32.ini} or default value may be used
(/etc/drweb/drweb32.ini). At launching some parameters get validated. If
parameter value turns out to be inadmissible, default value is taken;

- localization file gets loaded, if fixed. If it fails, messages in
English are used;

- log file is created. Note: the user under whose rights the daemon
operates, should have write access to the directory containing the log
file;

- key file gets loaded according to the path specified in drweb32.ini.
If the key is not found the daemon continues launching but it will operate
in a very restricted mode (packed file, electronic messages etc. do not get
checked);

- if the User parameter is set (or UserID) the daemon tries to change its
rights;

- search module gets loaded (drweb32.dll). If it is not found (errors in
configuration file) or damaged loading is terminated;

- then the bases with virus descriptions get loaded. Bases are searched
according to the paths set in the configuration file, loading order is
not fixed; if a base is damaged or absent loading will continue;

- the daemon "come untied" of the terminal, that is why the further
problems will not be output to the terminal, but only logged in the log
file;

- socket gets created. In case of TCP there may be more than one of them;
if any of them failed when creating loading continues. In case of UNIX
socket make sure that the user under whose rights the daemon is run has
write and read access to the directory containing the socket. The users
whose rights are used by integrating modules should have execution access
to the directory and write and read access to the socket file;

- then the so called pid file gets created. In this file information on the
descriptor of daemon process and transport addresses at which the daemon is
available is stored. Another extremely important note: the directory with
the pid file must be accessible for writing for the user under whose rights
the daemon is run, and so if you have the User parameter specified, you
should re-specify the pid file parameter also, because the default directory
/var/run is not accessible for writing for users. If the creation of the pid
file failed loading is terminated.


                5. Verifying DrWeb Daemon operability

If no problems occurred when loading it will result in the ready-to-work
daemon - i.e. a fixed number of the scanners always ready to operate. You
can check whether the socket has been created by giving netstat -a command.
In case of TCP sockets:

--- cut ---
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 localhost:3000          *:*                     LISTEN
raw        0      0 *:icmp                  *:*                     7
raw        0      0 *:tcp                   *:*                     7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  0      [ ACC ]     STREAM     LISTENING     384    /dev/gpmctl
unix  0      [ ]         STREAM     CONNECTED     190    @0000001b
unix  1      [ ]         STREAM     CONNECTED     1091   @00000031
unix  0      [ ACC ]     STREAM     LISTENING     403    /tmp/.font-unix/fs7100
unix  4      [ ]         DGRAM                    293    /dev/log
unix  1      [ ]         STREAM     CONNECTED     1092   /dev/gpmctl
unix  0      [ ]         DGRAM                    450
unix  0      [ ]         DGRAM                    433
unix  0      [ ]         DGRAM                    416
unix  0      [ ]         DGRAM                    308
--- cut ---

In case of Unix sockets:

--- cut ---
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
raw        0      0 *:icmp                  *:*                     7
raw        0      0 *:tcp                   *:*                     7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  0      [ ACC ]     STREAM     LISTENING     384    /dev/gpmctl
unix  0      [ ]         STREAM     CONNECTED     190    @0000001b
unix  1      [ ]         STREAM     CONNECTED     1091   @00000031
unix  0      [ ACC ]     STREAM     LISTENING     1127   /opt/drweb/run/drwebd.skt
unix  0      [ ACC ]     STREAM     LISTENING     403    /tmp/.font-unix/fs7100
unix  4      [ ]         DGRAM                    293    /dev/log
unix  1      [ ]         STREAM     CONNECTED     1092   /dev/gpmctl
unix  0      [ ]         DGRAM                    450
unix  0      [ ]         DGRAM                    433
unix  0      [ ]         DGRAM                    416
unix  0      [ ]         DGRAM                    308
--- cut ---

If there are no created sockets viewed that means there have occurred
loading problems.

To check DrWeb Daemon operability you can use the console client for the
daemon (drwebdc). Run it to get the service information on daemon. For TCP
socket:

$ drwebdc -nHOSTNAME -pPORTNUM -sv -sb

For Unix socket:

$ drwebdc -uSOCKETFILE -sv -sb

The following information should appear:

--- cut ---
Dr.Web daemon version: 4.27
Virus base: /opt/drweb/drwtoday.vdb (56 records)
Virus base: /opt/drweb/drw42702.vdb (116 records)
Virus base: /opt/drweb/drw42701.vdb (90 records)
Virus base: /opt/drweb/drwebase.vdb (27860 records)
Total virusfinding records : 28467
--- cut ---

If no correspondent information has been viewed try to enable the enhanced
diagnostics. For TCP socket:

$ drwebdc -nHOSTNAME -pPORTNUM -sv -sb -w

For Unix socket:

$ drwebdc -uSOCKETFILE -sv -sb -w

The more detailed output may clear out the situation:

--- cut ---
dwlib: startup: set timeout for whole session to -1 milliseconds (-1 means infinite)
dwlib: ipc: parse address string <inet:3001@localhost>
dwlib: tcp: call resolver for localhost
dwlib: tcp: resolver return 127.0.0.1
dwlib: tcp: connecting to 127.0.0.1:3001
dwlib: fd: connect() failed - Connection refused
Results: dwclient error -2 (internal transport subsystem)
Final code 0x10.
--- cut ---

Then take the test file eicar.txt (from the distributive package), turn it
into the program eicar.com with the help of the text editor (for instructions
see the file itself) and try to check it with the daemon. For TCP socket:

$ drwebdc -w -nHOSTNAME -pPORTNUM -f eicar.com

For Unix socket:

$ drwebdc -w -uSOCKETFILE -f eicar.com

Such a command must result in the following diagnostics:

--- cut ---
dwlib: startup: set timeout for whole session to -1 milliseconds (-1 means infinite)
dwlib: ipc: parse address string <inet:3000@localhost>
dwlib: tcp: call resolver for localhost
dwlib: tcp: resolver return 127.0.0.1
dwlib: tcp: connecting to 127.0.0.1:3000
Results: daemon return code 0x20 (known virus is found)
Final code 0x1.
--- cut ---

If it did not appear you should: 
- check in the daemon's log file if there is a record about checking that file
- enable enhanced diagnostics (see above).

If the checking has been completed correctly it means that the daemon is
operable.


                6. Checking modes realized by DrWeb Daemon (local scanning)

DrWeb Daemon has two main check modes:
- checking memory fragments received from socket;
- checking files on disc.

Let's dwell on these two modes at length. The first mode enabled, DrWeb
Daemon receives check data from the socket, practically it is a certain
data fragment. It may be named or not - it will effect only form of logging
in DrWeb Daemon's log file. Example of working in the mode is adduced in
the previous chapter - client read the file and sent it to the daemon for
checking. Basically the daemon can check any data fragment, not necessarily
a file.

The mode when the daemon scans the chosen file on disc is much more
efficient. Here only path to the file is reported to the daemon by the
client (whatever it is - console client or mail filter), the file itself
does not get transmitted. Attention!!! Important note: the path should be
specified in relation to the daemon (clients may located on other computers
etc.). What are the advantages of this mode? Firstly, it is more efficient,
secondly, it makes it easier to create an operational circuitry with curing
(for example, on file servers). But this mode requires a thorough right
setting, because the daemon must have read access to such a file, and in
the case of mail files and demo key - also write access. In the skillfully
set system the daemon in most cases does not require administrator rights
(root). But you should pay special attention to it when using it with mail
servers because filters usually work under the name of mail system (which
does not use root rights neither). In the most favorable mode filter
created a file with the message (having received it from mail system) and
reports its location to the daemon. At this point the rights to access the
directory where filters will create files should be carefully allotted. We
would recommend either to enclose the user whose rights are used by the
daemon in the mail subsystem group, or to run the daemon under the mail
system user.                    

                7. Contacts

As we have already noted, Doctor Web program gets constantly developed.
For updating information please see the sites at:

http://www.dials.ru
http://drweb.ru/
http://forum.drweb.ru/unix/
http://drweb.ru/unix

===============
DialogueScience, Inc
Street address: 117786 Moscow, Vavilova st. 40, office 103.

Tel.(+7-095) 135-6253, 137-0150
Tel/fax      938-2970, 938-2855

FidoNet: 2:5020/69

WWW: http://www.dials.ru
FTP: ftp.dials.ru, ftp2.dials.ru, ftp3.dials.ru

E-mail: Antivir@dials.ru
         
ID Anti-Virus Lab. Company Limited
34 Blagodatnaja St.
St.Petersburg, 196105, RUSSIA

Tel.:     +7 (812) 387-6408, 388-8624
Tel./fax: +7 (812) 388-8624
E-mail: sald@drweb.ru
WWW: http://www.drweb.ru, http://www.sald.com, http://www.antivir.net  
