32.2. Проверки целостности
32.2.1. Обзор
В Postgres Pro Enterprise входит утилита pg_integrity_check
, предоставляющая следующие возможности для проверки целостности:
Подсчёт и проверка контрольных сумм по требованию
Встроенная проверка контрольных сумм при запуске сервера
pg_integrity_check
может отслеживать контрольные суммы неизменяемых и дополнительных файлов, а также таблиц системных каталогов.
32.2.1.1. Неизменяемые файлы
К отслеживаемым неизменяемым файлам относятся исполняемые файлы, библиотеки и другие файлы, которые никогда не должны изменяться. Контрольные суммы таких файлов определяются в файле конфигурации /opt/pgpro/ent-14/share/security/system.conf
.
Файл system.conf
включён в состав дистрибутива Postgres Pro Enterprise. Для каждого экземпляра Postgres Pro Enterprise существует один отдельный файл system.conf
. Каждая строка в system.conf
соответствует одному отслеживаемому объекту и содержит два поля: контрольную сумму, состоящую из 40 шестнадцатеричных цифр, и относительный путь к файлу. Эти значения разделяются тремя символами: пробел, минус, пробел. Контрольные суммы вычисляются и записываются в этот файл во время установки Postgres Pro Enterprise. При их расчёте учитывается и содержимое файла, и его атрибуты. Поэтому, например, при изменении прав доступа к файлу его контрольная сумма изменится.
32.2.1.2. Дополнительные файлы
Дополнительными файлами считаются файлы, которые могут быть изменены администратором баз данных. Контрольные суммы дополнительных файлов сохраняются в файлах конфигурации, находящихся в каталоге share/security
. Для каждого кластера необходимо иметь отдельный файл конфигурации для дополнительных файлов. При этом действует следующее соглашение об именовании: путь к каталогу данных кластера (PGDATA
), в котором косая черта заменяется подчёркиванием, дополняется окончанием .user.conf
. Например, для кластера с каталогом данных /var/lib/pgpro/ent-14/data
файл конфигурации будет называться _var_lib_pgpro_ent-14_data.user.conf
.
Каждая строка в файле конфигурации соответствует одному отслеживаемому объекту и содержит два поля: контрольную сумму, состоящую из 40 шестнадцатеричных цифр, и относительный путь к файлу. Поля разделяются тремя символами: пробел, минус, пробел.
При расчёте контрольных сумм учитывается и содержимое, и атрибуты файлов. Поэтому, например, при изменении прав доступа к файлу его контрольная сумма изменится.
Чтобы настроить проверку контрольных сумм дополнительных файлов, администратор баз данных должен сделать следующее:
Создать файл конфигурации для каждого кластера, согласно описанному выше соглашению об именовании.
В созданном файле конфигурации перечислить все отслеживаемые дополнительные файлы. В качестве контрольной суммы можно задать любые 40 шестнадцатеричных цифр, например нули.
Выполнить следующую команду, чтобы пересчитать контрольные суммы, указав путь к каталогу данных вашего кластера:
pg_integrity_check -u -o -D /var/lib/pgpro/ent-14/data
Примечание
Администратор также может, запустив эту команду, получить примерный файл конфигурации, а затем отредактировать его должным образом.
32.2.1.3. Таблицы системных каталогов
Таблицы системных каталогов представляют собой избранный набор данных, относящихся к экземпляру Postgres Pro Enterprise. Управление контрольными суммами таблиц системных каталогов осуществляется с помощью соответствующих файлов конфигурации для каждой базы данных в кластере. Проверку целостности таблиц системных каталогов можно настроить для нескольких баз данных путём создания отдельных файлов конфигурации с конкретными значениями контрольных сумм.
Каждая строка в файле конфигурации соответствует одному отслеживаемому объекту и содержит два поля: контрольную сумму, состоящую из 40 шестнадцатеричных цифр, и относительный путь к файлу. Поля разделяются тремя символами: пробел, минус, пробел.
Чтобы настроить проверку контрольных сумм избранных данных, для каждой БД в кластере администратор баз данных должен сделать следующее:
Создайте файл конфигурации для выбранной базы данных. Например,
.имя_базы_данных
-catalog.confВ созданном файле конфигурации перечислить SQL-запросы, которые будут возвращать отслеживаемые данные. В качестве контрольной суммы можно задать любые 40 шестнадцатеричных цифр, например нули.
Выполнить следующую команду, чтобы пересчитать контрольные суммы, указав параметры подключения к вашей базе данных:
pg_integrity_check -c -o -C полный-путь-к-файлу-конфигурации
-d postgres -h localhost -p 5432 -U postgres
Чтобы проверить таблицы системного каталога, запустите pg_integrity_check
для каждой базы данных, подлежащей проверке целостности.
Примечание
Администратор также может, запустив эту команду, получить примерный файл конфигурации, а затем отредактировать его должным образом.
32.2.2. Проверка целостности при запуске сервера
Контрольные суммы неизменяемых файлов всегда проверяются при запуске сервера Postgres Pro Enterprise. Если запуск сервера остановлен из-за несовпадения контрольных сумм, администратор должен разобраться в проблеме, разрешить её и перезапустить сервер.
Таблицы системных каталогов и дополнительные файлы при запуске сервера не проверяются. Вы можете проверить их вручную, выполнив pg_integrity_check
после запуска сервера.
32.2.3. Планирование проверок целостности
Если вы используете систему семейства Linux, вы можете запланировать периодические проверки целостности, используя демон cron
. Для этого измените файл /etc/crontab
, добавив в него строки, определяющие частоту запуска утилиты pg_integrity_check
. Файл /etc/crontab
представляет собой системный файл, содержащий все инструкции для демона cron
. Чтобы получить подробное описание формата файла crontab
в вашей системе на базе Linux, выполните команду:
man 5 crontab
Примеры
Следующий пример иллюстрирует организацию проверок целостности в операционной системе Rosa SX:
# Каталог данных кластера PGDATA = /var/lib/pgpro/ent-14/data # Файл журнала pg_integrity_check LOG = /opt/pgpro/ent-14/share/security/log # Проверять неизменяемые файлы ежедневно в 00:05 5 0 * * * root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Запускать проверки целостности в 14:15 в первый день месяца 15 14 1 * * root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Запускать проверки целостности в 22.00 по выходным 0 22 * * 1-5 root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Запускать проверки целостности ежедневно в 00:23, 2:23, 4:23 ... 23 0-23/2 * * * root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Запускать проверки целостности в 4:05 по воскресеньям 5 4 * * sun root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG
32.2. Integrity Checks
32.2.1. Overview
Postgres Pro Enterprise includes the pg_integrity_check
utility that provides the following features for integrity checks:
On-demand checksum calculation and validation
Built-in checksum validation at the server startup
pg_integrity_check
can control read-only files, additional files, and system catalog tables.
32.2.1.1. Read-Only Files
Controlled read-only files include executable files, libraries, and other files that must never be modified. Checksums for read-only files are managed by the /opt/pgpro/ent-14/share/security/system.conf
configuration file.
The system.conf
file is included into the Postgres Pro Enterprise distribution. Each Postgres Pro Enterprise instance has a single system.conf
file. Each line in system.conf
corresponds to a single controlled object and includes two fields: the checksum, consisting of 40 hexadecimal digits, and a relative path to the controlled object. These fields are separated by three symbols: space, dash, space. Checksums are calculated and written into this file at the time of Postgres Pro Enterprise installation. They control both contents and attributes of read-only files. For example, if access rights to the file have been modified, the checksum will change.
32.2.1.2. Additional Files
Additional files are controlled files that can be modified by a database administrator. Checksums for additional files are managed by configuration files stored in the share/security
directory. Each cluster must have a separate configuration file for additional files. The naming convention is as follows: the path to the data directory of the cluster (PGDATA
), with forward slashes replaced by underscores, followed by the .user.conf
postfix. For example, for a cluster with /var/lib/pgpro/ent-14/data
data directory, the configuration file is called _var_lib_pgpro_ent-14_data.user.conf
.
Each line in the configuration file corresponds to a single controlled object and includes two fields: the checksum, consisting of 40 hexadecimal digits, and a relative path to the controlled object. The fields are separated by three symbols: space, dash, space.
Checksums control both contents and attributes of additional files. For example, if access rights to the file have been modified, the checksum will change.
To set up checksum validation for additional files, database administrator needs to do the following:
Create a configuration file for each cluster, following the naming convention specified above.
In the created configuration file, specify all the additional files to be controlled. As a checksum, any 40 hexadecimal digits can be entered, for example, zeros.
Run the following command to recalculate the checksums, specifying the path to the data directory of your cluster:
pg_integrity_check -u -o -D /var/lib/pgpro/ent-14/data
Note
Alternatively, administrator can run the above command to generate a sample configuration file, and then edit this file as needed.
32.2.1.3. System Catalog Tables
System catalog tables represent a controlled data selection related to Postgres Pro Enterprise instance. Checksums for system catalog tables are managed by respective configuration files for each database in a cluster. You can setup integrity checks of system catalog tables for several databases by providing separate configuration files with specific checksum values.
Each line in the configuration file corresponds to a single controlled object and includes two fields: the checksum, consisting of 40 hexadecimal digits, and a relative path to the controlled object. The fields are separated by three symbols: space, dash, space.
To set up checksum validation for data selection, database administrator needs to do the following for each database in a cluster:
Create a configuration file for the selected database. For example,
.database-name
-catalog.confIn the created configuration file, specify SQL queries that return the controlled data. As a checksum, any 40 hexadecimal digits can be entered, for example, zeros.
Run the following command to recalculate checksums, specifying connection parameters for your database:
pg_integrity_check -c -o -C configuration-file-full-path
-d postgres -h localhost -p 5432 -U postgres
To check system catalog tables, run pg_integrity_check
for each database subject to integrity checks.
Note
Alternatively, administrator can run the above command to generate a sample configuration file, and then edit this file as needed.
32.2.2. Checking Integrity at Server Startup
Checksums for read-only files are always validated at the Postgres Pro Enterprise server startup. If the server start is blocked because of a checksum mismatch, administrator must troubleshoot and resolve the issue to restart the server.
System catalog tables and additional files are not validated at the server startup. You can validate them by running pg_integrity_check
manually once the server is started.
32.2.3. Scheduling Integrity Checks
If you are using a Linux-based system, you can schedule recurrent integrity checks using the cron
daemon. To schedule integrity checks, modify the /etc/crontab
file by adding the lines that define the frequency of pg_integrity_check
utility launches. The /etc/crontab
is a system file that contains all instructions for the cron
daemon. To get a detailed description of the crontab
file format for your Linux-based operating system, run the command:
man 5 crontab
Examples
The following example illustrates integrity checks on a Rosa SX operating system:
# Data directory of the cluster PGDATA = /var/lib/pgpro/ent-14/data # pg_integrity_check log file LOG = /opt/pgpro/ent-14/share/security/log # Validate read-only files every day at 00:05 5 0 * * * root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Run integrity checks at 14:15 on the first day of the month 15 14 1 * * root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Run integrity checks at 22.00 on weekdays 0 22 * * 1-5 root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Run integrity checks at 00:23, 2:23, 4:23 ..., every day 23 0-23/2 * * * root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG # Run integrity checks at 4:05 each Sunday 5 4 * * sun root /opt/pgpro/ent-14/bin/pg_integrity_check -s >> $LOG