10.6. Shared Database Among MetaDefender Core Instances

Starting with MetaDefender 4.20.0 or newer, a centralized database deployment could be setup for all MetaDefender Core instances to share with.

That helps auto-sync all product configurations (except Single-Sign-On that requires unique settings for each Core), processing histories, live/on-going scan result query, audit, statistics data.

images/download/attachments/5279808/image-20210205-062431.png

This article demonstrates how to install and setup MetaDefender Core 4.20.0 or newer with shared database mode.

Important notes & current limitatons:

  • The central remote PostgreSQL server (for shared database) could be utilized with a built-in (native) PostgreSQL database server installed with one of the MetaDefender Core instances in the network. Or using a dedicated existing PostgreSQL database server (version 12.3 or newer is recommended).

  • Before setting up, make sure to follow steps at Open Connection On PostgreSQL Server so that all MetaDefender Core instances could connect to the central remote PostgreSQL server.

  • All MetaDefender Core instances must be installed on the same Operating System (Windows / Linux).

  • The first MetaDefender Core instance connects to the shared database must be ready first (license activated, users/groups/roles created, SSO is enabled if using) before setting up other MetaDefender Core instances to connect and use that shared database.

  • Do not support to switch from shared database mode back to standalone database mode.

  • Do not support to change instance_name of MetaDefender Core in shared database deployment model after installed.

  • Engine update:

    • If selected to command update engines from Folder source, all MetaDefender Core instances must be able to access to the configured update folder, and the option DELETE FILES AFTER IMPORT will be unchecked and prevented for modification.

  • Authentication:

    • Single-Sign-On (SSO) authentication settings (if using) cannot be shared among MetaDefender Core instances because SSO requires an unique login URL for every different Core.

    • If an user is locked for login on a certain MetaDefender Core instance(e.g. exceeded the number of failed login times), that user is not prevented for logging in on any other instances.

    • If an user is locked for sign-in on a certain MetaDefender Core instance (e.g. exceeded the number of failed login times), if the admin releases lockout on that user on that MetaDefender Core instance, that user is still not able to login on other MetaDefender Core instances.

  • Sanitized / DLP / Quarantined location changed after MetaDefender Core install:

    • Windows:

      • Shared storaged path will be stored in 3 strings under key global in registry: quarantinepath, dlppath, sanitizepath as below

      • images/download/attachments/5279808/image-20210128-085556.png
      • You can set either 1, 2 or 3 different paths for 3 strings above (means that quarantined, DLP and sanitized files will be stored in same or different storages corresponding). In case shared storage is not set in installation, values of 3 strings above will be empty.

      • Restart MetaDefender Core service after changed.

    • Linux:

      • Open file /etc/ometascan/ometascan.conf and set shared storage path for 3 keys quarantinepath, dlppath, sanitizepath under section [global]

      • Restart ometacan service after changed.