Operating Principles

In this section

Connection types

Operation modes

Services

Dr.Web MeshD mediates interaction between a host with Dr.Web for UNIX Mail Servers installed and other cloud hosts.

Connection types

Dr.Web MeshD uses the following connection types:

Client (service)—used by Dr.Web MeshD to connect to other cloud hosts. These hosts are clients of services provided by the given host.

Components of Dr.Web for UNIX Mail Servers operating on the host and accessing services provided by the cloud through Dr.Web MeshD operating on the same host connect to it via a local UNIX socket. At that, a client connection is not used.

Partner (peer to peer)—used by Dr.Web MeshD for interaction with peer (within a service) partner cloud hosts. Usually such horizontal connections are used for scaling and distributing the load when interacting with the cloud, as well as for synchronization of cloud hosts.

Uplink—used by Dr.Web MeshD to connect this host (client) to cloud hosts (service providers) (for example, distribution of virus databases updates, file transmission for scanning, and so on).

The use of all three types of connections is configured independently for different cloud services. At that, the same host can be configured as a server for processing client requests within a service (for example, providing fresh updates) and as a client within another service (for example, remote file scanning).

Within cloud, hosts perform authorized interaction via a secure SSH protocol, that is, all sides of interhost communication are always mutually authenticated. For the authentication, host keys are used according to RFC 4251. The client connection from the local component is always considered as trusted.

Operation Modes

Dr.Web MeshD can work both in the daemon mode and run on requests from other Dr.Web for UNIX Mail Servers components, located on the local host. If Dr.Web MeshD is configured to serve client connections (i.e. the ListenAddress parameter is not empty) and at least one of the services is activated, Dr.Web MeshD starts as a daemon and waits for connections from clients. Besides, Dr.Web MeshD can be activated on the local host upon request, for example, when executing the command:

$ drweb-ctl update --local-cloud

If Dr.Web MeshD is not set to process client connections (the ListenAddress parameter is empty) and there is no request to Dr.Web MeshD during the period specified in the IdleTimeLimit parameter, the component exits automatically.

Services

Exchanging updates (Update)

The service allows the host to subscribe to updates of virus and other databases, send notifications on the updates, upload and share the update files between cloud hosts. The service settings can be configured using the Update* parameters.

The standard service usage assumes that Dr.Web MeshD is installed with the enabled feature of obtaining updates on several machines (clients of the service) in the local network of the company. The typical client settings are:


[MeshD]
UpdateChannel = On
UpdateUplink = <server address>
ListenAddress =

[Update]
UseLocalCloud = Yes

On the local server for distributing updates, the following settings are specified:

UpdateChannel = On
UpdateUplink =
ListenAddress = <address>:<port>

Here, <server address> in the uplink connection of the client must refer to the <address> and <port> that are used by the server host for managing client connections.

When one of the hosts is being updated from the update servers (external to the local cloud—Dr.Web GUS update servers or the centralized protection server), the host sends a notification to all necessary clients (if the host is set as an update exchange server) and sends to the server host a new list of files available for distribution from the host. Upon receiving the notification, client hosts can request the update download from the server, that in turn can request the files from the client to save them locally or to send them to the other client that has the requested the files from the server.

The scenario decreases the update delay because clients send requests to Dr.Web GUS at different times, at thus the first updated client immediately distributes the fresh update files to all necessary cloud hosts. It also decreases amount of traffic and Dr.Web GUS load.

Note that when using the local cloud for update distribution, in addition to Dr.Web MeshD, hosts must contain the Dr.Web Updater component.

Remote file scanning (Engine)

The service allows to use Dr.Web Scanning Engine for scanning remote files: client hosts send files for scanning to the server host and server hosts provide a service for file scanning. The typical client settings are:


[MeshD]
EngineChannel = On
EngineUplink = <server address>
ListenAddress =

On the local scanning server, the following settings are specified:

EngineChannel = On
EngineUplink =
ListenAddress = <address>:<port>

Here, <server address> in the uplink connection of the client must refer to the <address> and <port> that are used by the server host for managing client connections.

Transmitting files for scanning (File)

The feature is not used (remote scanning is provided within the Engine service).

URL check

The service allows to use the server hosts to check URL for belonging to potentially dangerous and non-recommended categories: client hosts send URL to be checked to the server host. The typical client settings are:


[MeshD]
UrlChannel = On
UrlUplink = <server address>
ListenAddress =

On the local server used for URL check, the following settings are specified:

UrlChannel = On
UrlUplink =
ListenAddress = <address>:<port>

Here, <server address> in the uplink connection of the client must refer to the <address> and <port> that are used by the server host for managing client connections.