Print Download PDF Send Feedback

Previous

Next

Architecture and Processes

In This Section:

Check Point Registry

Server Architecture

Automatic Start of Multi-Domain Server Processes

Environment Variables

Check Point Registry

The Check Point registry, at $CPDIR/registry/HKLM_registry.data, contains installation and version information for the different components of Check Point products. Each Multi-Domain Server, Multi-Domain Log Server, Domain Management Server, and Log Server has its own registry. The $CPDIR environment variable points to the registry location on each platform or context.

Server Architecture

This section is an overview of the new management architecture introduced in R80, as shown in this diagram:

These are the principal processes and components:

Item

Description

1

R80.30 SmartConsole application

2

CPMI - Legacy Check Point Management Interface

3

Web Services - Handles communication with the new CPM process

4

FWM - Legacy management server process

5

CPM - R80.30 main management server process

6

PostgreSQL - Relational database system that contains the Rule Base, management objects and configuration settings

7

Solr - Query and search platform

Communication between the SmartConsole application (1) and the CPM (5) process uses Web Services (3). CPM communicates directly with the PostgreSQL (7) database to update tables or records. CPM can also use a use Solr (6) to run a query to get information or locate records in the PostgreSQL database.

SmartConsole uses the CPMI (2) protocol to communicate with the legacy FWM (4) process. This is necessary for backward compatibility with pre-R80 Security Gateways. In this case, CPM and FWM communicate directly with each other.

In a Multi-Domain Management environment, only one CPM, PostgreSQL, and Solr instance is necessary to handle transactions with all Domain Management Servers. In the backward compatibility mode, there is one FWM instance for each Domain Management Server.

Note - Because many of the processes are shared between the MDS and all the Domains, it is not possible to stop or start a Domain server independently of all the other Domains. It is only possible to stop per Domain processes, like FWM, for specific Domains.

CPM

CPM is the Check Point main management server process for this release. It is a multi-threaded, Java process that uses Web services to expose its functionality and to efficiently handle many, concurrent requests.

PostgreSQL

PostgreSQL is the relational database manager that handles all data of the Multi-Domain Management and the single Domains Management, and configuration parameters. It also manages a connection pool to support concurrent connections, where each connection is a different process. The pool size is between 10 to 50 concurrent connections.

Solr

Solr is the enterprise search platform that handles the state-of-the-art search capabilities in SmartConsole. When a user searches for data in SmartConsole, Solr handles the request and gets the data from the PostgreSQL tables. Solr stores some partial data in a cache for better search performance.

Multi-Domain Server Processes

Each Multi-Domain Server Level process has one instance on every Multi-Domain Server/Multi-Domain Log Server machine, when it is running. These processes run on the Multi-Domain Server.

Process

Description

cpd

SVN Foundation infrastructure process

cpca

The Certificate Authority management process

fwd

Audit Log server process

fwm

Legacy Check Point management server main process (R77.x and earlier)

For proper operation of the Multi-Domain Server, these processes must run together with CPM, postres, and solr. An exception to this rule is instances where cpca cannot run, such as for Domain Log Servers. cpca must always run for Domain Management Servers.

Domain Management Server Processes

Each one of these processes runs a different instance for each Domain Management Server:

Process

Description

cpd

SVN Foundation infrastructure process

cpca

The Certificate Authority manager process (Domain Servers only)

fwd

Log server process

fwm

Legacy Check Point management server main process (R77.x and earlier)

status_proxy

Status collection of SmartLSM Security Gateways

sms

Manages communication with UTM-1 Edge Security Gateways

For proper operation of the Domain Management Server, cpca, fwd and fwm must always run, except for specified configurations where cpca cannot run. Other processes are required only as necessary for applicable functionality.

Automatic Start of Multi-Domain Server Processes

The script for the automatic start of Multi-Domain Server processes upon boot is at /etc/init.d. The name of the file is firewall1. A link to this file appears in /etc/rc3.d directory under the name S95firewall1.

Environment Variables

Different Multi-Domain Server processes require standard environment variables that:

Additionally, specific environment variables control certain parameters of different functions of Multi-Domain Server.

Multi-Domain Server installation contains shell scripts for C-Shell and for Bourne Shell, which define the necessary environment variables:

Sourcing these files (or in other words, using "source" command in C-Shell or "." command in Bourne Shell) will define the environment necessary for the Multi-Domain Server processes to run.

Standard Check Point Environment Variables

Variable

Description

FWDIR
MSDIR

Location of Check Point Security Gateway binary/configuration/library files

  • In the Multi-Domain Server environment, this environment variable is equal to MDSDIR
  • In Domain Management Server environment, it contains /opt/CPmds-R80/customers/<Domain Management Server Name>/CPsuite-R80/fw1

PGDIR

Location of the PostgreSQL database - $CPDIR/database/postgresql

MDS_TEMPLATE

Location of log files and JARs

CPDIR

Location of Check Point SVN Foundation binary/configuration/library files that point to different directories in Multi-Domain Server and Domain Management Server environments

MDSDIR

Location of the Multi-Domain Server installation (/opt/CPmds-R80)

SUROOT

Points to the location of SmartUpdate packages