Установка#

Pangolin — система управления базами данных, основанная на PostgreSQL. В данном руководстве описываются аспекты Pangolin, связанные с установкой системы.

Документ предназначен для администраторов и специалистов по безопасности, отвечающих за установку и обновление продукта.

Примечание:

Перед прочтением документа рекомендуется ознакомиться с используемыми терминами и определениями.

Внимание!

Перед установкой убедитесь, что:

• local=en_US или выполните команду:

  sudo echo "LC_ALL=en_US.utf8" >> /etc/locale.conf
  

• Если FQDN (Fully Qualified Domain Name) каждого участника кластера в DNS не определены, добавьте их в /etc/hosts в формате ip fqdn на каждом сервере. Это необходимо для создания etcd-кластера.

• При использовании на серверах межсетевого экрана необходимо обеспечить сетевую связность по используемым портам.

• Нельзя менять в inventory имена узлов (master, replica, etcd). В блоке etcd_nodes указываются серверы, которые только участвуют в кластере etcd, но не являются master или replica.

Состав дистрибутива#

Единый дистрибутив PSQ-\<версия Pangolin\>-distrib.tar.gz содержит все перечисленные ниже компоненты дистрибутива для запуска установки/обновления:

Диаграмма процесса развертывания Pangolin#

Внимание!

В установке standalone-версии продукта участвуют две машины. Первая – откуда производится запуск ansible-установщика, вторая – целевая, куда разворачивается продукт.

Диаграмма процесса развертывания Pangolin:

Выбор способа установки#

В зависимости от способа развертывания сервиса воспользуйтесь одной из инструкций:

• целевая автоматизированная установка Pangolin;

• опциональная ручная установка Pangolin.

Подготовка окружения#

Рекомендуется запускать установку продукта Pangolin в виртуальной среде Python, созданной с помощью инструмента — virtualenv. Создание изолированной среды позволяет избежать конфликтов с уже предустановленными пакетами и не затрагивать существующую среду на текущей машине.

Виртуальное окружение и необходимые модули для старта можно установить следующими командами.

Пример для ОС Red Hat Enterprise Linux:

sudo yum install sshpass
sudo yum install python3-pip
sudo python3 -m pip install pip==9.0.0 # или sudo python3 -m pip install --index-url=https://testurl --trusted-host=<trusted-host> pip==9.0.0
sudo python3 -m pip install virtualenv==20.3.1 # или sudo python3 -m pip install --index-url=https://testurl --trusted-host=<trusted-host> virtualenv==20.3.1
virtualenv pg_se_venv --python=python3
source pg_se_venv/bin/activate
pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0 dnspython==2.2.0 # или pip3 install --index-url=https://pypi.org/simple --trusted-host=<trusted-host> cffi==1.15.0 cryptography==3.3.1 Jinja2==2.11.2 jmespath==0.9.4 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==20.9 pycparser==2.21 pyparsing==3.0.6 PyYAML==5.3 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0 dnspython==2.2.0

Пример для РЕД ОС:

sudo dnf reinstall python3-pip
sudo dnf install python3-virtualenv
sudo ln /usr/bin/virtualenv-3 /usr/bin/virtualenv
pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0 dnspython==2.2.0

Далее установка будет производиться в виртуальной среде pg_se_venv.

Закончив работу в виртуальной среде, можно отключить ее, выполнив консольную команду:

deactivate

Перед началом установки сформируйте единый дистрибутив Pangolin из zip-пакета:

1. Получите архив zip-пакета и выполните команду распаковки:

   unzip -q <имя zip-пакета>.zip
   

2. Перейдите в каталог с распакованным zip-пакетом и выполните запуск скрипта по формированию единого дистрибутива:

   sh PSQ-<version>-unpacker-distrib.sh
   

Результатом выполнения будет единый дистрибутив в формате tar.gz (пример: PSQ-<version>-distrib.tar.gz), предназначенный для установки Pangolin.

Ручная установка Pangolin#

Внимание!

Для полноценной установки Pangolin следует выбирать автоматическую установку с помощью Ansible, так как она является целевой.

При ручной установке не будут настроены различные параметры, в том числе присущие только Pangolin:

• настройки конфигурационных файлов (postgresql.conf, pg_hba.conf);

• настройки кластерной конфигурации;

• будут отсутствовать компоненты Pangolin (etcd, Pangolin Manager, Pangolin Pooler, и другие);

• настройки ролевой модели;

• настройки расширений;

• настройки ротации журналов;

• и другие.

Установка на ОС Альт СП 8#

1. Создайте директорию с дистрибутивом Pangolin.

   mkdir distrib
   

2. Поместите дистрибутив Pangolin в директорию distrib.

3. Распакуйте дистрибутив Pangolin.

   tar -xf docker-builds-altsp8-1638-distrib.tar.gz
   

4. Установите пакет:

   sudo apt-get install platform-v-pangolin-dbms-06.001.00-altlinux8.2.x86_64.rpm
   

5. Создайте директорию $PGDATA и /pgerrorlogs.

   sudo mkdir -p /pgdata/06/data
   sudo chown -R postgres:postgres /pgdata/06/
   sudo mkdir -p /pgerrorlogs/06
   sudo chown postgres:postgres /pgerrorlogs/06
   

6. Переключитесь на пользователя postgres (если такого нет, то создайте).

   sudo su - postgres
   

7. Добавьте строку окружения в ~/.bash_profile.

   vim ~/.bash_profile
   umask 022
   export LD_LIBRARY_PATH=/usr/pangolin-6.1.5/lib
   export PATH=$PATH:/usr/pangolin-6.1.5/bin
   export PG_PLUGINS_PATH=/usr/pangolin-6.1.5/lib
   export PGHOME=/usr/pangolin-6.1.5
   export PGDATABASE=postgres
   export PGUSER=postgres
   export PGHOST=<IP-адрес>
   export PGPORT=<Порт>
   export PGCLIENTENCODING=UTF8
   export CLNAME=clustername
   export PGSSLCERT=/pg_ssl/client.crt
   export PGSSLKEY=/pg_ssl/client.key
   export PGSSLROOTCERT=/pg_ssl/root.crt
   NOW=$(date +"%Y-%m-%d")
   export PGDATA=/pgdata/06/data
   export MANPATH=$MANPATH:$PGHOME/share/man
   
   . ~/.bash_profile
   

8. Разверните СУБД.

   initdb -k -D /pgdata/06/data/
   

9. Отредактируйте файл параметров vim $PGDATA/postgresql.conf.

   listen_addresses = '*'
   port = 5433
   max_connections = 100
   superuser_reserved_connections = 3
   
   enabled_extra_auth_methods = 'peer, trust'
   

10. Отредактируйте файл параметров vim $PGDATA/pg_hba.conf.

    local   all             all                                     peer
    host    all             all             0.0.0.0/0               trust
    

11. Запустите экземпляр Pangolin.

    pg_ctl -D /pgdata/06/data/ -l /pgerrorlogs/06/postgresql.log start
    

12. Выполните команду:

    [16:41:22  postgres@srv-0-211 ~]$ psql
    psql (13.4)
    Type "help" for help.
    
    postgres=#
    

Автоматизированная установка Pangolin#

Настоящий способ предусматривает установку Pangolin с помощью инсталлятора, поставляемого в составе дистрибутива. Установка может быть произведена как с отдельного хоста, так и с master/replica планируемого кластера. Поддерживается установка cluster и standalone конфигурации.

Примечание:

Конфигурационные файлы и сценарии, приведенные в данном руководстве, являются примерами. Может потребоваться корректировка значений параметров и переменных, указанных в них, под каждый конкретный случай установки.

Для осуществления автоматизированной установки Pangolin, выполните последовательно шаги, описанные в подразделах ниже.

Подготовка сервера к установке#

Выполните шаги:

1. Установите виртуальное окружение:

   python3 -m venv install_venv
   

   Примечание:

   install_venv здесь и далее - имя venv. Может быть любым.

2. Активируйте виртуальное окружение и установите необходимые библиотеки:

   source install_venv/bin/activate
   pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 dnspython==2.2.0 ansible==4.10.0
   

3. Скачайте дистрибутив из Nexus, распакуйте его и перейдите в каталог distrib:

   wget --user <username> --ask-password <distribuitive_url>
   tar -xvf <distriburive.tar.gz> -C ./distrib/
   cd distrib
   

Подготовка конфигурационных файлов#

Заполнение inventory-файлов#

Заполните inventory-файл в зависимости от имеющейся конфигурации.

Файл hosts.ini заполняется в соответствии с шаблоном:

• для standalone находится по пути: installer/inventories/standalone/hosts.ini;

• для cluster находится по пути: installer/inventories/cluster/hosts.ini.

Файл hosts.ini состоит из нескольких групп (имена определены в скобках), которые используются для классификации и определения того, какие хосты будут использоваться. Для установки необходимо заполнить переменные группы postgres_nodes и arbiter_nodes (для claster):

• ansible_host — в случае установки по IP-адресу, указжите ip_address, в случае установки по имени DNS укажите hostname;

• ansible_user — имя пользователя для использования при подключении к хосту. Должен иметь права для эскалации до root, то есть должен иметь возможность выполнять все команды от имени root;

• переменная ansible_password должна содержать пароль пользователя в чистом виде или имя переменной, которая будет содержать зашифрованный с помощью ansible-vault пароль.

Внимание!

Пароль пользователя следует указывать в кавычках для того, чтобы избежать конфликтов при цитировании специальных символов. Пользователь, указанный в файле hosts.ini, должен обладать правами sudo + nologin.

Если в файле hosts.ini переменная ansible_password содержит ansible-vault, то пароль необходимо зашифровать. Ниже приведен пример шифрования текста passwordtest с помощью ansible-vault:

ansible-vault encrypt_string passwordtest
New Vault password:
Confirm New Vault password:
!vault |
   $ANSIBLE_VAULT;1.1;AES256
   {хеш}
Encryption successful

В случае, когда пароли для хостов групп postgres_group и arbiter_group совпадают, достаточно вывод команды ansible-vault поместить в inventory-файл сluster.yml/standalone.yml, расположенный в каталоге inventories/(standalone/cluster)/group_vars. Аналогичным образом необходимо перешифровать пароли в файле custom_file_sample.yml пример файла тем же ключом, которым был зашифрован пароль для учетной записи в текущем шаге.

Примечание:

Узнать подробнее о Ansible inventory можно в документации Ansible.

Ниже представлены примеры файла hosts.ini для standalone и cluster архитектур.

hosts.ini для standalone:#

[standalone:children]
postgres_group

[postgres_group:children]
postgres_nodes

[postgres_group:vars]
ansible_connection=ssh

[postgres_nodes]
master  ansible_host=<IP-адрес>  ansible_user=<Имя пользователя>   ansible_password="<Пароль>"

hosts.ini для cluster:#

[cluster:children]
postgres_group
arbiter_group

[postgres_group:children]
postgres_nodes

[arbiter_group:children]
arbiter_nodes

[postgres_group:vars]
ansible_connection=ssh

[arbiter_group:vars]
ansible_connection=ssh

[postgres_nodes]
master   ansible_host=<IP-адрес>  ansible_user=<Имя пользователя>   ansible_password="<Пароль>"      
replica  ansible_host=<IP-адрес>  ansible_user=<Имя пользователя>   ansible_password="<Пароль>"

[etcd_nodes]
etcd  ansible_host=<IP-адрес>  ansible_user=<Имя пользователя>   ansible_password="<Пароль>"

Заполнение файла конфигурации custom_config_sample.yml#

Пример конфигурационного файла custom_config_sample.yml, который можно использовать для развертывания продукта со значениями по умолчанию или с минимальными корректировками, находится в каталоге installer/templates/custom_config_sample.yml.

Поскольку custom_config_sample.yml является примером и вариантом готового решения, некоторые секции и параметры были перенесены в custom_config_initial.yml - конфигурационный файл, содержащий все динамически настраиваемые параметры СУБД Pangolin. При необходимости их можно переопределить в файле custom_config_sample.yml.

Пример заполнения custom_config_sample.yml:

# для конфигурации с применением хранилища ETCD

patroni_yml:
  etcd:
    hosts: [ <IP-адрес-1>, <IP-адрес-2>, <IP-адрес-3>] # укажите IP-адреса хостов кластера. Обычно это master, replica, arbiter.                                              
    port: 2379 # укажите порт.
 
# для всех конфигураций

pip_repository:
  index_url: http://<hostname>/altlinux_trusted_repo/mirror/pypi_2/simple/
  trusted_host: <hostname>

Внимание!

Для etcd по умолчанию рекомендовано использовать порт 2379.

Сгенерируйте сертификаты, в случае, если в настраиваемом конфигурационном файле выше было выставлено значение для параметра: mtls_support: true и/или pkcs12_plugin_enable: true.

На текущий момент кластер можно развернуть с включенной аутентификацией SSL и без нее. Целью включения аутентификации является обеспечение безопасного взаимодействия компонентов внутри кластера.

Если активирован параметр pkcs12_plugin_enable: true, то сертификаты должны быть сгенерированы в формате PKCS#12 или будут получены из Secret Management System (далее – SecMan), в зависимости от заполненных значений в пользовательском конфигурационном файле. Подробнее читайте в документе «Руководстве по системному администрированию», раздел «Использование сертификатов PKCS#12 в кластере Pangolin».

Для поиска или генерации сертификата в SecMan необходимо активировать параметр use_remote_pki: true и заполнить атрибуты в разделе p12_secman: для каждого сертификата.

При включенном параметре (mtls_support: true) скрипты развертывания и обновления продукта определяют расположение сертификатов по путям из параметров соответствующего компонента (параметры из секции 3.2.SECURITY SETTINGS (SSL) - pg_certs_pwd) и проверяют их наличие.

Если сертификат отсутствует по указанному пути, то будет выведена блокирующая ошибка. Примеры ошибок:

"{{ control_name }}.FAIL__Файл сертификата 'root.crt' не найден на хосте. Проверьте наличие файла и значение в пользовательском конфигурационном файле - 'custom_config_sample.yml'__{{ control_name }}.FAIL"

Ниже приведен пример скрипта для генерации сертификатов и распространения их на указанные виртуальные машины:

#!/bin/sh
# IP/DNS-записи хостов.
hosts_list=({IP-адрес-1} {IP-адрес-2} {IP-адрес-3})
# Пароль пользователя с root правами.
ssh_password=(TestPassword!)
# Пользователь с root-правами.
ssh_user=(admin_dev)
mkdir ssl
cd ssl

openssl req -new -nodes -text -out ./root.csr -keyout ./root.key -subj "/CN=PGSEdevCA"
openssl x509 -req -in ./root.csr -text -days 3650  -extfile /etc/pki/tls/openssl.cnf -extensions v3_ca -signkey ./root.key -out ./root.crt
openssl req -new -nodes -text -out ./client.csr -keyout ./client.key -subj "/CN=postgres"
openssl x509 -req -in ./client.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./client.crt
openssl req -new -nodes -text -out ./patroni.csr -keyout ./patroni.key -subj "/CN=patroni"
openssl x509 -req -in ./patroni.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./patroni.crt
openssl req -new -nodes -text -out ./patronietcd.csr -keyout ./patronietcd.key -subj "/CN=patronietcd"
openssl x509 -req -in ./patronietcd.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./patronietcd.crt
openssl req -new -nodes -text -out ./pgbouncer.csr -keyout ./pgbouncer.key -subj "/CN=pgbouncer"
openssl x509 -req -in ./pgbouncer.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./pgbouncer.crt
rm *.csr

######Copy_certs_on_nodes_and_generate_server_cert
for host in ${hosts_list[@]}
do
sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo rm -rf /pg_ssl && sudo mkdir /pg_ssl && sudo chown $(whoami):$(whoami) /pg_ssl'
sshpass -p ${ssh_password} scp ./* ${ssh_user}@${host}:/pg_ssl
sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cat << EOT >> /pg_ssl/server.conf
[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[ ssl_client ]
extendedKeyUsage = clientAuth, serverAuth
basicConstraints = CA:FALSE
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
subjectAltName = @alt_names
[ v3_ca ]
basicConstraints = CA:TRUE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
authorityKeyIdentifier=keyid:always,issuer
[alt_names]
EOT'

sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cd /pg_ssl && echo DNS.1 = $(hostname -f) >> server.conf && echo IP.1 = $(hostname -i) >> server.conf && openssl req -new -nodes -text -out ./server.csr -keyout ./server.key -subj "/CN=$(hostname -f)" -config $(echo ./server.conf)'
sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'cd /pg_ssl && openssl x509 -req -in ./server.csr -text -days 3650 -CA ./root.crt -CAkey ./root.key -CAcreateserial -out ./server.crt -extensions ssl_client -extfile $(echo ./server.conf)'
sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo chmod 0600 /pg_ssl/*.key && sudo chmod 0644 /pg_ssl/*.crt'

###/etc/pki/ca-trust/source/anchors/ - 'RedHat' /etc/pki/tls/openssl.cnf\ - 'Altlinux' ###
sshpass -p ${ssh_password} ssh -o StrictHostKeyChecking=no -p 22 ${ssh_user}@${host} 'sudo cp /pg_ssl/root.crt /etc/pki/ca-trust/source/anchors/ && sudo update-ca-trust'
done

Данные сертификаты не будут подписаны, но будут являться минимальными требуемыми для установки. После установки продукта Pangolin необходимо подписать данные сертификаты в удостоверяющем центре (подробнее о генерации сертификатов смотрите в документе «Руководство администратора», раздел «Генерация сертификатов»).

Примечание:

Скрипты развертывания не осуществляют проверку валидности сертификатов.

Запуск сценария установки#

Выполните шаги:

1. Заполните параметры, заключенные в < >, запустите playbook_install.yaml из директории installer:

   ansible-playbook -vvv playbook_install.yaml \
   -i inventories/<cluster||standalone>/hosts.ini \
   -t always,<configuration>  \
   -e '{"as_TUZ":['tuz_1']}' \
   --flush-cache \
   --extra-vars 'local_distr_path=<path_to_distributive> \
   installation_type=<cluster||standalone> \
   PGPORT=5433 \
   PGDATA=/pgdata/<major_version>/data \
   PGLOGS=/pgerrorlogs/<major_version> \
   tag=<configuration>\
   clustername=clustername \
   custom_config=templates/custom_config_sample.yml \
   pangolin_license_path=/home/sbt_user/license_trial.json \
   nolog=true \
   

   Пример заполненной команды для запуска playbook_install.yaml в случае cluster-установки Pangolin:

   ansible-playbook -vvv playbook_install.yaml \
   -i inventories/cluster/hosts.ini \
   -t always,cluster-patroni-etcd-pgbouncer  \
   -e '{"as_admins":['admin_1', 'admin_2']}' \
   -e '{"as_TUZ":['tuz_1']}' \
   --flush-cache \
   --extra-vars 'local_distr_path=/home/pprb_dev/distrib \ #каталог, в который распакован дистрибутив.
   installation_type=cluster \
   PGPORT=5433 \
   PGDATA=/pgdata/06/data \
   PGLOGS=/pgerrorlogs/06 \
   tablespace_name=tbl_name \
   tablespace_location=/pgdata/06/tablespaces \
   schema_name=shema \
   tag=cluster-patroni-etcd-pgbouncer \
   db_name=first_db \
   clustername=clustername \
   custom_config=templates/custom_config_sample.yml \
   nolog=true \
   pangolin_license_path=/home/sbt_user/license_trial.json \ #путь к файлу редакции
   

2. Дождитесь окончания установки и деактивируйте виртуальное окружение:

   deactivate
   

Если необходимо передать лог установки для анализа — перенаправьте stdout в файл, добавив > filename в конце команды ansible_playbook:

ansible_playbook  -vvv playbook_install.yaml ... stand=${}'  > ~/ansible_log.txt

Примечание:

pangolin_license_path - полный путь к файлу редакции, например, pangolin_license_path=/home/admin/license_trial.json. Имя файла значения не имеет.

Инсталлятор будет проверять валидность редакции пяти основных типов:

• license_standard_1C;

• license_standard;

• license_enterprise_1C;

• license_enterprise;

• license_trial.

Возможные варианты развертывания Pangolin описаны в разделе «Варианты развертывания Pangolin».

Примеры сценариев возможных вариантов установки#

В разделе приведены примеры сценариев возможных вариантов установки Pangolin.

Сценарий установки кластерного решения Pangolin с Pangolin Manager, etcd, Pangolin Pooler:#

Команда запуска сценария:

ansible-playbook playbook_install.yaml \
-i inventories/cluster/hosts.ini \
-t always,cluster-patroni-etcd-pgbouncer \
-vv \
-e '{"as_admins":['admin_1', 'admin_2']}' \
-e '{"as_TUZ":['tuz_1']}' \
--extra-vars 'local_distr_path=${} \
installation_type=cluster \
tag=cluster-patroni-etcd-pgbouncer \
segment={segment} \
pangolin_license_path=/home/admin/license_trial.json \
custom_config=templates/custom_config_sample.yml \
--ask-vault-pass

Внимание!

После установки будут созданы символические ссылки для следующих директорий:

• /pgdata/data -> /pgdata/06

• /usr/pangolin -> /usr/pangolin-

• /usr/pgsql-se-06 -> /usr/pangolin-

Значения используемых в команде запуска сценария ключей:

• -i — путь к inventory-файлу;

• -t — теги для запуска;

• -vv — уровень логирования Ansible. Может быть, как пустым, так и -vvvvvv, где запуск без v - минимальное логирование;

• -e, --extra-vars — переменные, которые по приоритету важнее переменных из inventory;

• --ask-vault-pass или --vault-password-file — расшифровка зашифрованных файлов во время выполнения.

Внимание!

Для зашифровки паролей в примерах выше, использовался следующий ansible-vault пароль: postgreSQL_SE_654321.

Используемые переменные:

• as_admins — Active Directory логин или логины будущих администраторов АС. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_admins":['admin, test_admin]}';

• as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}';

• local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;

• segment — сегмент сети;

• custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml.

Внимание!

Параметр инсталлятора stand, ранее отвечавший за настройку DEV-стенда, с версии 5.5.0 исключен. Настройка DEV-стендов инсталлятором не производится.

Внимание!

В случае, если все пароли указывались в открытом виде, параметр --ask-vault-pass и --vault-password-file=название_файла_с_ключем добавлять не нужно!

Внимание!

В случае, если вам необходимо развернуть стенд с дополнительными настройками ролевой модели, пользовательской БД, схемами и расширениями необходимо отдельно запустить playbook_configure_roles.yaml или sh-скрипт run_configure.sh развертывания ролевой модели, который располагается в компоненте installer по пути scripts_external/configure_roles/configure_roles/templates/role_BASIC/run_configure.sh. Ролевая модель и скрипты ее настройки описаны в документе «Руководство администратора», раздел «Ролевая модель и права доступа».

Cценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью ansible-роли#

Команда запуска сценария:

ansible-playbook playbook_configure_roles.yaml \
-i inventories/cluster/hosts.ini \
-t always,cluster-patroni-etcd-pgbouncer \
-vv \
-e '{"as_admins":['test_admin']}' \
-e '{"as_TUZ":['test_tuz']}' \
--extra-vars 'local_distr_path=${} \
PGPORT=${} \
PGDATA=${} \
PGLOGS=${} \
tablespace_name=${} \
tablespace_location=${} \
schema_name=${} \
tag=cluster-patroni-etcd-pgbouncer \
db_name=${} \
custom_config=${}' \
--ask-vault-pass

Используемые переменные:

• as_admins — Active Directory логин или логины будущих администраторов АС. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_admins":['admin, test_admin]}';

• as_TUZ — логины ТУЗ, которые будут созданы в результате установки. Если логинов несколько, то они указываются через запятую, без пробелов. Например, -e '{"as_TUZ":['tuz, test_tuz]}';

• local_distr_path — абсолютный путь к загруженному и распакованному дистрибутиву Pangolin;

• PGPORT — порт для взаимодействия с базой данных Pangolin;

• PGDATA — полный путь к каталогу, где будет расположена инициализированная база данных;

• PGLOGS — полный путь к каталогу, где будут расположены логирующие файлы;

• pangolin_license_path — задает путь к директории, которая содержит редакции или путь к конкретному файлу редакции. Данная переменная окружения используется самим сервером и его утилитами для получения данных об используемой редакции. По умолчанию используется директория /opt/pangolin_license;

• tablespace_name — имя табличного пространства, которое будет создано в результате установки;

• tablespace_location — полный путь к каталогу, где будет расположено созданное табличное пространство;

• schema_name — имя схемы, которая будет создана в результате установки;

• db_name — имя базы данных, которая будет создана в результате установки;

• custom_config — абсолютный путь к файлу конфигурации custom_config_sample.yml;

Внимание!

В случае, если не планируется использовать custom_config, есть возможность настройки параметров запуска через файл variables.yml, расположенный в роли configure_roles (scripts_external/configure_roles/group_vars/variables.yml).

Cценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью запускаемого bash-скрипта#

Команда запуска скрипта:

sh ./role_BASIC/run_configure.sh -d First_db -s Sch1 -t Tbl_t -l /pgdata/06/tablespaces -m <IP-адрес> -r <IP-адрес> -p <Порт> -a 'user1 user2' -u 'user3 user4' -w /home/postgres/role_BASIC -c "0,30 * * * *" -g  "'as_admin_pass':{хеш} 'as_tuz_pass':{хеш}" -f "'pg_profile':True 'rotate_password':True 'psql_lockmon_is_enable':True"  -e 'infinity' -v 'TEMPORARY' -k 'backup_user' -z false -o 'en_US.UTF-8' -n 'postgres'

Используемые параметры:

• d, dbname – имя пользовательской БД;

• s, schname – имя пользовательской схемы;

• t, tsname – имя пользовательского табличного пространства;

• l, tsloc - путь к табличному пространству;

• m, mhost - ip-адрес хоста мастера (данный параметр является обязательным, так как используется для настройки расписания pg_cron);

• r, rhost ip-адрес хоста реплики (данный параметр является обязательным, так как используется для настройки расписания pg_cron);

• p, port - порт PostgreSQL;

• a, asadm – список ТУЗ as_admin;

• u, astuz - список ТУЗ as_TUZ;

• w, way - путь к папке со скриптами конфигурирования (данный параметр является обязательным);

• c, cronp - период времени для cron job pg_profile;

• g, grpas - список паролей для УЗ (передается в виде словаря, например: as_admin_pass':passwd1 'zabbix_pass':passwd2);

• f, fchlst - список включаемой функциональности при развертывании (передается в виде словаря, например: 'pg_profile':True 'rotate_password':False);

• e, expdt - параметр времени жизни УЗ (expire date);

• v, vrpas - флаг, указывающий на использование временных паролей;

• k, backusname - имя пользователя для резервного копирования (по умолчанию backup_user);

• z, tdeadm - включить/выключить TDE;

• o, locale - параметр для определения locale при создании пользовательской БД (должен совпадать с параметром, установленным при развертывании);

• n, prdbname - имя пользовательской БД, где будет создан pg_profile.

Действия, которые необходимо выполнить, в случае неудачной установки#

В случае, если установка прошла неудачно:

1. Перед началом новой установки необходимо очистить КТС. Для этого выполните команду приведенную в разделе «Удаление» текущего документа.

2. Очистите файл ./installer/cache.json, а также добавьте ключ --flush-cache при повторном запуске установки.

etcd#

В кластере Pangolin для хранения информации о состоянии кластера Pangolin Manager используется хранилище etcd версии 3.3.11 (устанавливается инсталлятором).

sudo systemctl yum install etcd

Настройка etcd#

Для настройки сервиса откройте файл параметров etcd.service и укажите в нем следующие параметры:

Sudo vi /etc/systemd/system/etcd.service

[Unit]
Description=etcd Server
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=-/etc/etcd/etcd.conf
User=etcd
### set GOMAXPROCS to number of processors
ExecStart=/bin/bash -c "GOMAXPROCS=$(nproc) /usr/bin/etcd"

Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
node-1 /etc/etcd/etcd.conf
[pprb_dev@tkle-pprb0100 ~]$ sudo cat /etc/etcd/etcd.conf | grep -v ^#
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="http://<IP-адрес>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<IP-адрес>:2379"
ETCD_NAME="node-01"
ETCD_HEARTBEAT_INTERVAL="1000"
ETCD_ELECTION_TIMEOUT="5000"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${HOST_VM1}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${HOST_VM1}:2379"
ETCD_INITIAL_CLUSTER="node-01=http://${HOST_VM1}:2380,node-02=http://${HOST_VM2}:2380,node-03=http://${HOST_VM3}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
node-02 /etc/etcd/etcd.conf
[pprb_dev@tkle-pprb0095 ~]$ sudo cat /etc/etcd/etcd.conf | grep -v ^#
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="http://<IP-адрес>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<IP-адрес>:2379"
ETCD_NAME="node-02"
`ETCD_HEARTBEAT_INTERVAL`="1000"
ETCD_ELECTION_TIMEOUT="5000"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${HOST_VM2}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${HOST_VM2}:2379"
ETCD_INITIAL_CLUSTER="node-01=http://${HOST_VM1}:2380,node-02=http://${HOST_VM2}:2380,node-03=http://${HOST_VM3}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
node-03 /etc/etcd/etcd.conf
[pprb_dev@tkle-pprb0081 ~]$ sudo cat /etc/etcd/etcd.conf | grep -v ^#
ETCD_DATA_DIR="/var/lib/etcd"
ETCD_LISTEN_PEER_URLS="http://<IP-адрес>:2380"
ETCD_LISTEN_CLIENT_URLS="http://<IP-адрес>:2379"
ETCD_NAME="node-03"
ETCD_HEARTBEAT_INTERVAL="1000"
ETCD_ELECTION_TIMEOUT="5000"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://${HOST_VM3}:2380"
ETCD_ADVERTISE_CLIENT_URLS="http://${HOST_VM3}:2379"
ETCD_INITIAL_CLUSTER="node-01=http://${HOST_VM1}:2380,node-02=http://${HOST_VM2}:2380,node-03=http://${HOST_VM3}:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"

Описание параметров etcd.service:

• ETCD_LISTEN_PEER_URLS — список ссылок, с которых собирается трафик одноранговых узлов;

• ETCD_LISTEN_CLIENT_URLS — список ссылок, с которых собирается трафик клиентов;

• ETCD_HEARTBEAT_INTERVAL — время (мс) периода проверки (heartbeat);

• ETCD_ELECTION_TIMEOUT — время (в мс) таймаута алгоритма выбора;

• ETCD_INITIAL_ADVERTISE_PEER_URLS — список ссылок пиров этого элемента кластера для передачи другим элемента кластера;

• ETCD_ADVERTISE_CLIENT_URLS — список ссылок клиентов этого элемента кластера для публичной передачи. Передаваемые ссылки клиентов будут доступны системам, взаимодействующим с кластером etcd. Клиентские библиотеки обрабатывают эти ссылки для подключения к кластеру etcd;

• ETCD_INITIAL_CLUSTER — исходная конфигурация кластера для начальной загрузки;

• ETCD_INITIAL_CLUSTER_STATE — исходное состояние кластера (new или existing);

• ETCD_INITIAL_CLUSTER_TOKEN — исходный токен кластера etcd во время начальной загрузки. При использовании нескольких кластеров позволяет избежать непреднамеренного взаимодействия между ними.

Обязательно рекурсивно смените владельца директории. Для этого выполните:

sudo chown -R etcd:etcd /var/lib/etcd/

Затем запустите на каждом узле кластера:

sudo systemctl daemon-reload
sudo systemctl start etcd.service
sudo systemctl status etcd.service
sudo journalctl -xe

Полезные функции#

Для быстрого просмотра проблем с кластером:

etcdctl cluster-health

Для просмотра структуры хранилища:

etcdctl ls --recursive --sort -p /service/clustername

где clustername - имя кластера базы.

Для просмотра всей структуры:

etcdctl ls --recursive /

Пример:

[pprb_dev@tkle-pprb0066 ~]$ etcdctl ls -r /
/service
/service/clus
/service/clus/members
/service/clus/members/pg02
/service/clus/members/pg01
/service/clus/initialize
/service/clus/config
/service/clus/optime
/service/clus/optime/leader
/service/clus/history
/service/clus/leader

Для получения значения из параметра:

etcdctl -o extended get /service/clustername/leader
etcdctl -o extended get /service/clustername/members/

Автоматическое подключение СЗИ с помощью external-скрипта#

Подключить набор СЗИ можно отдельно от общего сценария установки СУБД. Механизм подключения вынесен в независимый external-скрипт внутри общих скриптов развертывания/обновления, к которым относятся:

• playbook_configure_ist.yaml - осуществляет запуск сценария подключения СЗИ;

• custom_configure_ist.yml - пользовательский конфигурационный слой для настройки входных параметров.

Ansible-роль (configure_ist) для запуска процесса подключения СЗИ выглядит следующим образом:

• tasks:

  • check.yml - файл с задачами для проверки состояния стенда, влияющими на успешное подключение СЗИ, проверка входных параметров;

  • common_check.yml - файл с задачами для общей проверки состояния стенда. Проверки путей до конфигурационных файлов, путей до сертификатов;

  • define_current_master.yml - файл с задачами для определения текущей конфигурации. В случае со стендом с Pangolin Manager, определение текущего master;

  • install.yml - файл с задачами по подключению СЗИ;

  • main.yml - файл с задачами, включает в себя вызов всех файлов в текущем каталоге;

  • switch.yml - файл с задачами по остановке/запуску БД;

• group_vars:

  • all.yml - переменные, используемые в данной роли по умолчанию;

  • message.yml - переменные для вывода информации (INFO)/ошибок (FAIL);

• cluster:

  • hosts.ini - обеспечивает возможность передачи параметров подключения к хостам. Содержит файлы для кластерной конфигурации;

  • inventory.py - скрипт, обеспечивающий возможность заполнять inventory-файлы в автоматическом режиме;

  • standalone:

    • hosts.ini - обеспечивает возможность передачи параметров подключения к хостам. Содержит файлы для конфигурации standalone;

    • inventory.py - скрипт, обеспечивающий возможность заполнять inventory-файлы в автоматическом режиме;

    • filter_plugins:

      • common_filters.py - скрипт для обработки входных данных;

    • library:

    • yedit - скрипт для работы с конфигурационным файлом Pangolin Manager. Поставляется в скомпилированном виде;

    • pangolin_protect_init.py - скрипт для работы с утилитами setup_kms_credentials, initprotection.

Особенности логики работы некоторых параметров пользовательского конфигурационного файла:

• параметр secure_config контролирует включение защиты конфигурации. Значение по умолчанию true;

• параметр admin_protection подразумевает подключение только защиты от привилегированных пользователей. Значение по умолчанию true.

Вышеупомянутые параметры располагаются в блоке TYPE IST.

Примечание:

Утилиты initprotection/setup_kms_credentials в external-скрипте обернуты в python-модуль. Это позволяет исключить возможные зависания при передаче некорректного значения и организацией вызова утилиты initprotection от linux-пользователя администратора безопасности.

Организована возможность передать имя пользователя с привилегиями на запуск инициализации механизма защиты данных и запуск инициализации подключения к защищенному хранилищу; контролируется параметром target_linux_user, значение по умолчанию: kmadmin_pg. Располагается в блоке SETTINGS INIT PROCESS. Скрипты по подключению СЗИ не вносят изменения в файл sudoers для данного пользователя и не корректируют права владельца на запуск утилит initprotection и setup_kms_credentials. Все необходимые права на запуск должны быть выданы до старта скриптов по подключению СЗИ.

Тип объединенного параметра адреса узла и порта VAULT VAULT_HOST_PORT соответствует list. Ограничений в количестве элементов списка нет. Располагаются в блоке CONNECTION VAULT PARAMETERS.

Параметр add_connection_string_to_hba отвечает за добавление строк подключения для созданных в процессе инициализации механизма защиты данных пользователей. Значение по умолчанию true. Располагается в блоке ADMIN PROTECTION SETTINGS. В случае, если параметр будет принимать значение false, в конфигурационный файл pg_hba.conf будет добавлен следующий комментарий:

# The connection string for security administrators is formed implicitly

Внимание!

С версии 5.5.0 параметры, которые в более ранних версиях задавали правила подключения для admin_protection_users.sec_admin (sec_admin_hba_rule.connection, sec_admin_hba_rule.databases, sec_admin_hba_rule.network, sec_admin_hba_rule.auth) и параметр sec_admin_backup_networks (список хостов к подключению admin_protection_users.sec_admin_backup) были исключены.

Тип параметра sec_admin_hba_rule.network изменен с str на list.

Для каждой УЗ администратора безопасности можно задать индивидуальные правила подключения в параметре admin_protection_users. Параметры настройки располагаются в блоке ADMIN PROTECTION SETTINGS.

Параметр pg_encryption_keys_capacity задает настройку БД при подключении TDE; располагается в блоке CONFIGURATION PARAMETERS. Параметры dynamic_shared_memory_type и mkeychecker_delay в локальную конфигурацию не включены.

Запуск скрипта для подключения СЗИ#

Выполните шаги:

1. Перед запуском скрипта установите обязательные для работы скрипта пакеты:

   python3 -m venv venv
   source venv/bin/activate
   pip3 install cffi==1.15.0 cryptography==3.3.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 netaddr==0.7.19 packaging==21.3 pycparser==2.21 pyparsing==3.0.6 PyYAML==6.0 resolvelib==0.5.5 six==1.16.0 ansible==4.10.0 dnspython==2.2.0
   

2. Запустите external-скрипт подключения СЗИ, для этого выполните ansible-playbook playbook_configure_ist.yaml.

   • пример запуска для конфигурации standalone:

     ansible-playbook playbook_configure_ist.yaml -i inventories/standalone/hosts.ini --extra-vars "custom_config=<Путь к пользовательскому конфигурационному файлу> utility_path=<Путь к каталогу с утилитами; входит в состав дистрибутива>" --flush-cache -vv
     

   • пример запуска для кластерной конфигурации:

     ansible-playbook playbook_configure_ist.yaml -i inventories/cluster/hosts.ini --flush-cache -vv
     

Проверки и информационные сообщения процесса подключения СЗИ#

Проверка корректной передачи в строку запуска ansible обязательных параметров#

Для корректной работы скрипта по подключению СЗИ необходимо передать в строку запуска два обязательных параметра:

• custom_config - путь к пользовательскому конфигурационному файлу инсталлятора;

• utility_path - путь к каталогу utilities/, входящего в состав дистрибутива.

В случае ошибки выводится следующее сообщение:

"FAIL__Один из обязательных входных параметров: custom_config, utility_path не был задан при старте. Скорректируйте строку запуска ansible и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка пользователей#

Если пользователи для успешного сценария подключения СЗИ на стенде отсутствуют, то выводится блокирующая дальнейшее выполнение сценария ошибка:

"FAIL__На хосте {{ ansible_fqdn }} не был обнаружен пользователь {}. На текущий момент подключение СЗИ невозможно, необходимо выполнить проверку корректного заполнения параметра target_linux_user в пользовательском конфигурационном файле '{}' или произвести создание пользователя. После произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка актуального master-узла#

На вход скрипту передается ряд параметров, в числе которых адреса master и replica-узлов. Информация может быть неактуальной, поэтому реализована проверка актуального master-узла. В случае, если адрес master-узла отличается от переданного на вход, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Текущий мастер в СУБД не соответствует значению, полученному из SM. На текущий момент подключение СЗИ невозможно, необходимо выполнить switchover__.FAIL"

Проверка файлов сертификатов#

Если файлы сертификатов отсутствуют, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Файл сертификата {} не найден на хосте {{ ansible_fqdn }}. Проверьте наличие файла.__FAIL"

Проверка переданного пути к конфигурационному файлу инсталлятора на корректность#

В случае ошибки выводится следующее сообщение:

"FAIL__Путь к конфигурации '{}' не должен зависеть от текущего каталога. Скорректируйте значение для параметра custom_file в строке запуска ansible и произведите повторный запуск скрипта по подключению СЗИ__FAIL"

Проверка наличия конфигурационного файла на управляющем узле#

При наличии файла выводится подсказка с информацией о расположении файла:

"INFO__Файл конфигурации '{}' найден.__INFO"

В случае, когда файл не найден, выводится сообщение вида:

"FAIL__Файл конфигурации '{}' не найден. Строка запуска ansible должна содержать параметр custom_file с корректным путем к пользовательскому конфигурационному файлу custom_file. Скорректируйте строку запуска ansible и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Роль получает текущее значение следующих переменных:

Проверка наличия переменных окружения#

Переменные окружения, которые необходимо проверить:

• PGDATA;

• PGHOME;

• CLNAME;

• PGPORT.

Если нет одного из параметров, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__{PARAM} на хосте {{ ansible_fqdn }} отсутствует. Актуализируйте значение '{PARAM}' в файле /home/postgres/.bash_profile.__FAIL"

Проверка запуска СУБД#

Если СУБД Pangolin не запущена, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__СУБД Pangolin не запущена. Произведите проверку состояния СУБД Pangolin на сервере.__FAIL"

Проверка запуска Pangolin Manager#

Если служба Pangolin Manager не запущена, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Служба Patroni не запущен. Произведите проверку состояния службы Pangolin Manager на сервере.__FAIL"

Проверка установки параметров в true#

Если ни один из параметров, которые контролируют подключение СЗИ, не выставлен в true, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Не удалось сформировать список СЗИ к подключению. Скорректируйте значения в пользовательском конфигурационном слое.__FAIL"

Проверка символьных ссылок#

Если символьная ссылка до плагина, контролирующего подключение к серверу VAULT, на стенде выставлена некорректно, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Подключение СЗИ на стенде возможно только с физическим(ими) сервером(ами) VAULT. Произведите проверку символьной ссылки до плагина: {}.__FAIL"

Проверка плагинов setup_kms_credentials/initprotection#

Если на стенде не был обнаружен плагин setup_kms_credentials или initprotection, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Плагин '{}' на стенде не обнаружен.__FAIL"

Проверка доступности серверов#

Если ни один сервер из заданного списка недоступен, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"Не удалось установить успешное подключение ни к одному из сервера(ов) VAULT. Проверьте корректность переданных параметров подключения к защищенному(ым) хранилищу(щам) VAULT в конфигурационном файле' {}'. После произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка списка УЗ администраторов#

Если список УЗ администраторов безопасности был передан не в полном объеме, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Проверка входных параметров для инициализации механизма защиты данных не дала ожидаемый результат. Параметры УЗ администраторов безопасности были переданы неверно или не в полном объеме. Скорректируйте параметры в пользовательском конфигурационном файле '{}', относящиеся к конфигурированию УЗ администраторов безопасности и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка метода шифрования паролей УЗ администраторов безопасности#

Если пароли для УЗ администраторов безопасности были заданы не методом SCRAM-SHA-256, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Проверка входных параметров для инициализации механизма защиты данных не дала ожидаемый результат. Пароли УЗ администраторов безопасности не были переданы в виде SCRAM-SHA-256. Скорректируйте параметры паролей для УЗ администраторов безопасности в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ. __FAIL"

Проверка получения параметров VAULT_CLUSTER_ID, VAULT_LOGIN, VAULT_PASSWORD#

Роль получает на вход параметры:

• VAULT_CLUSTER_ID;

• VAULT_LOGIN;

• VAULT_PASSWORD;

• VAULT_HOST_PORT.

Если для одного из них было передано пустое значение, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Проверка входных параметров для инициализации подключения к защищенному(ым) хранилищу(ам) VAULT не дала ожидаемый результат. Значение для параметра '{}' не должно быть пустым. Скорректируйте параметры '{}' в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка значение параметра VAULT_HOST_PORT#

Если значение для параметра VAULT_HOST_PORT было передано в некорректном формате, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Проверка входных параметров для инициализации подключения к защищенному(ым) хранилищу(ам) VAULT не дала ожидаемый результат. Значение для параметра '{}' указано в неверном формате. Скорректируйте параметры '{}' в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка наличия VAULT_CLUSTER_ID на защищенном хранилище VAULT#

В случае отсутствия выводится ошибка вида:

"FAIL__cluster id - '{}' в защищенном хранилище VAULT '{}' не обнаружен. Дальнейшее подключение невозможно. Произведите проверку на предмет корректно сконфигурированого id на сервере VAULT и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка значение параметра VAULT_CLUSTER_ID#

Если значение для параметра VAULT_CLUSTER_ID было передано в некорректном формате, то выводится ошибка, блокирующая дальнейшее выполнение сценария:

"FAIL__Проверка входных параметров для инициализации подключения к защищенному(ым) хранилищу(ам) VAULT не дала ожидаемый результат. Значение для параметра '{}' не должно начинаться или заканчиваться кавычками. Скорректируйте параметры '{}' в пользовательском конфигурационном файле '{}' и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Получение общего списка параметров из защищенного хранилища VAULT#

При возникновении ошибок в ходе получения общего списка параметров защищенного хранилища выводится ошибка вида:

"FAIL__В процессе получения списка параметров из защищенного хранилища VAULT возникли ошибки: {}. Произведите проверку состояния VAULT сервера(ов) и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка корректного значения для параметра secure_config на защищенном хранилище VAULT#

Значение on устанавливается, если планируется подключение защиты параметров конфигурации; значение off используется, если подключение защиты параметров конфигурации не планируется.

В случае возникновения проблем выводится ошибка вида:

"FAIL__Для подключения выбранных СЗИ значение для параметра secure_config должен быть выставлено в {} на защищенном хранилище VAULT. Скорректируйте значение для параметра на защищенном хранилище VAULT и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка корректного значения для параметра is_tde_on на защищенном хранилище VAULT#

Если планируется подключение TDE, ожидается значение on/true. В случае, когда подключение TDE не планируется, устанавливается значение off/false.

При некорректном значении параметра выводится следующая ошибка:

"FAIL__Для подключения выбранных СЗИ значение для параметра is_tde_on должен быть выставлено в {} на защищенном хранилище VAULT. Скорректируйте значение для параметра на защищенном хранилище VAULT и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка идентичности значений pg_ident на защищенном хранилище VAULT и в локальном конфигурационном файле#

В случае неидентичности значений выводится ошибка вида:

"FAIL__Для подключения выбранных СЗИ значение для параметра pg_ident на защищенном хранилище VAULT должно соответствовать значению в локальном конфигурационном файле '{}/pg_ident.conf'. Синхронизируйте значения и произведите повторный запуск скрипта по подключению СЗИ.__FAIL"

Проверка готовности защищенного хранилища VAULT к последующему подключению выбранных СЗИ посредством secret_storage_client#

Утилита secret_storage_client входит в состав дистрибутива и располагается в папке utilities/secret_storage_client_bundle/bin/. На вход скрипты, использующие данную утилиту для проверки, ожидают корректно переданный путь к каталогу с утилитами utilities/ в переменную utility_path в строку запуска ansible. При отсутствии утилиты по переданному пути в лог будет выведено предупреждающее сообщение. Процесс подключения при этом не останавливается.

В случае когда по переданному пути утилита не будет найдена, выведется предупреждение:

"WARNING__По преданному пути '{}' утилита secret_storage_client не обнаружена. Проверки готовности защищенного хранилища VAULT к подключению выбранных СЗИ будет пропущена.__WARNING"

Сообщения об успешном прохождении проверок#

"INFO__Список СЗИ к подключению успешно сформирован. В процессе работы скрипта будет подключено: {}.__INFO"

"INFO__Проверка плагина подключения к защищенному(ым) хранилищу(ам) VAULT завершилась успешно.__INFO"

"INFO__Проверка доступности VAULT сервера(ов) прошла успешно.__INFO"

Проверки и информационные сообщения после подключения выбранного списка СЗИ#

Проверка наличия конфигурационного файла VAULT после работы утилиты setup_kms_credentials#

В случае, когда файл не был найден, будет выведена ошибка:

"FAIL__Конфигурационный файл VAULT '{}' не был обнаружен. Причина может быть в некорректной работе утилиты setup_kms_credentials. Лог работы утилиты: {}__FAIL"

Проверка успешного подключения#

Если после работы утилиты setup_kms_credentials не удалось установить ни одного успешного подключения, то выводится следующее сообщение в лог:

"FAIL__Не удалось установить ни одного успешного подключения. Проверьте доступность сервера(ов) VAULT и корректность переданных параметров в пользовательском конфигурационном файле.__FAIL"

Проверка работа утилиты initprotection#

Если работа утилиты initprotection завершилась неудачей, то выводится следующее сообщение в лог:

"FAIL__В процессе инициализация механизма защиты данных возникли ошибки: '{}'.__FAIL"

Проверка состояния стенда#

Если проверка состояния стенда после работы скриптов не дала ожидаемый результат, то выводятся следующие сообщения в лог:

"FAIL__В процессе работы скриптов что-то пошло не так. TDE на текущем стенде не включено. Произведите проверку параметра по включению TDE в конфигурационном файле или на сервере(ах) VAULT.__FAIL"

"FAIL__В процессе работы скриптов что-то пошло не так. Защита конфигурации на текущем стенде не включена. Произведите проверку параметра secire_config на сервере(ах) VAULT.__FAIL"

"FAIL__В процессе работы скриптов что-то пошло не так. Защита от привилегированных пользователей на текущем стенде не включена.__FAIL"

Сообщения об успешном прохождении проверок#

"INFO__Проверка наличия конфигурации VAULT прошла успешно.__INFO"

"INFO__Инициализация механизма защиты данных выполнена успешно.__INFO"

"INFO__Итоговая проверка подключения TDE завершилась успешно.__INFO"

"INFO__Итоговая проверка подключения защиты конфигурации завершилась успешно.__INFO"

"INFO__Итоговая проверка подключения защиты от привилегированных пользователей завершилась успешно.__INFO"

Ручное подключение СЗИ#

В Pangolin реализована интеграция с KMS HashiCorp Vault и с локальным файловым хранением секретов. В данном разделе рассматривается ручное подключение таких функциональностей, как защита от привилегированных пользователей, TDE и защита конфигурации.

Внимание!

Подключение СЗИ осуществляется от пользователя с правами sudo, пользователя postgres и пользователя администратора безопасности (в качестве примера взят kmadmin_pg).

Инструкция рассчитана на подключение СЗИ в СУБД Pangolin, начиная с версии 5.4.0.

Ручное подключение СЗИ с локальным файловым хранением секретов#

Общие подготовительные действия#

Выключите БД на время ручного подключения СЗИ:

• Если конфигурация standalone:

  sudo su - postgres
  /usr/pangolin/bin/pg_ctl stop -D /pgdata/05/data
  

  Ожидаемый результат:

  waiting for server to shut down....
  done
  server stopped
  

• Если конфигурация кластерная:

  sudo su - postgres
  sudo systemctl stop pangolin-manager
  

  Действие сначала производится на реплике, затем на мастере.

  Ожидаемый результат:

  sudo su - postgres
  list
  
  + Cluster: clustername (7258206222218039502) ----+---------+---------+----+-----------+
  | Member              | Host                     | Role    | State   | TL | Lag in MB |
  +---------------------+--------------------------+---------+---------+----+-----------+
  | <Адрес>         | <Адрес>:<Порт>         | Replica | stopped |    |   unknown |
  | <Адрес>          | <Адрес>:<Порт>          | Replica | stopped |    |   unknown |
  +---------------------+--------------------------+---------+---------+----+-----------+
  

Локальное конфигурирование#

Примечание:

Пропустите этот раздел, если требуется подключение только защиты от привилегированных пользователей.

Выполните шаги:

1. Создайте каталог для расширенной конфигурации, если такого нет. В кластерной конфигурации повторите это действие на реплике:

   sudo su
   mkdir /etc/postgres
   chown postgres:kmadmin_pg /etc/postgres
   chmod 0731 /etc/postgres
   

   Ожидаемый результат:

   ls -la /etc | grep postgres
   
   drwx-wx--x    2 postgres kmadmin_pg   4096 Jul 21 18:00 postgres
   

2. Создайте файлы для хранения статических и динамических параметров. В кластерной конфигурации повторите это действие на реплике:

   sudo su
   touch /etc/postgres/kms_dynamic_params.cfg
   touch /etc/postgres/kms_static_params.cfg
   chown kmadmin_pg:postgres /etc/postgres/kms_dynamic_params.cfg
   chown kmadmin_pg:postgres /etc/postgres/kms_static_params.cfg
   chmod 0640 /etc/postgres/kms_dynamic_params.cfg
   chmod 0640 /etc/postgres/kms_static_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres
   
   -rw-r-----    1 kmadmin_pg postgres   0 Jul 21 18:05 kms_dynamic_params.cfg
   -rw-r-----    1 kmadmin_pg postgres   0 Jul 21 18:06 kms_static_params.cfg
   

   Файл со статическими параметрами имеет простой текстовый формат, каждая строка содержит пару: <имя ключа> = <значение для данного ключа>. Файл может содержать следующие параметры:

• ключ actual_master_key – метка актуального мастер-ключа;

• wal_key – значение ключа шифрования WAL кластера;

• master_key_value_<timestamp> – значение мастер-ключа, <timestamp> – дата и время в формате ГГГГММДД_ЧЧммСС, где ГГГГ – год, ММ – месяц, ДД – день, ЧЧ – час в формате 24 часа, мм – минута, СС – секунда.

3. Сгенерируйте ключи с помощью утилиты generate_encryption_key. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   /usr/pangolin/bin/generate_encryption_key
   

   Ожидаемый результат:

   Key was generated successfully. Key: kqOCj08rZxZZpbUiE66G9VE8RuXZQm4uh7RzQf64Rc4=Key was generated successfully. Key: c10FIGbvsYKvP+n7qgTlqWDwCOimwQcP7+ODXsWmN4Y=
   

4. Заполните файл со статическими параметрами. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   vim /etc/postgres/kms_static_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres/kms_static_params.cfg
   
   actual_master_key = master_key_value_00000000_000000_000
   master_key_value_00000000_000000_000 = kqOCj08rZxZZpbUiE66G9VE8RuXZQm4uh7RzQf64Rc4=
   wal_key = c10FIGbvsYKvP+n7qgTlqWDwCOimwQcP7+ODXsWmN4Y=
   

5. Зашифруйте файл со статическими параметрами. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   /usr/pangolin/bin/encrypt_params_file
   

   Ожидаемый результат:

   Start to encrypt file: /etc/postgres/kms_static_params.cfg
   File /etc/postgres/kms_static_params.cfg was encrypted successfully
   

6. Создайте файл с динамическими параметрами. В кластерной конфигурации повторите это действие на реплике:

   sudo su - kmadmin_pg
   vim /etc/postgres/kms_dynamic_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres/kms_dynamic_params.cfg
   
   secure_config = off
   is_tde_on = off
   allowed_servers =
   enabled_sec_admin_extra_auth_methods = cert
   encrypt_new_tablespaces = ddl
   masking_mode = disabled
   password_encryption = scram-sha-256
   password_policies_enable = on
   password_policy.allow_hashed_password = on
   password_policy.alpha_numeric = 3
   password_policy.check_syntax = on
   password_policy.custom_function =
   password_policy.deny_default = off
   password_policy.expire_warning = 7 days
   password_policy.failure_count_interval = 0
   password_policy.grace_login_limit = 0
   password_policy.grace_login_time_limit = 3 days
   password_policy.illegal_values = on
   password_policy.in_history = 4
   password_policy.lockout = on
   password_policy.lockout_duration = 24 hours
   password_policy.max_age = 0
   password_policy.max_failure = 6
   password_policy.max_inactivity = 0
   password_policy.max_rpt_chars = 0
   password_policy.min_age = 0
   password_policy.min_alpha_chars = 0
   password_policy.min_length = 16
   password_policy.min_lowercase = 0
   password_policy.min_special_chars = 1
   password_policy.min_uppercase = 1
   password_policy.password_strength_estimator_score = 3
   password_policy.reuse_time = 365 days
   password_policy.track_login = 0
   password_policy.transport_password_life_time = 0
   password_policy.transport_password_mark_automatic = off
   password_policy.use_password_strength_estimator = on
   performance_insights.masking = on
   psql_encrypt_password = on
   ssl = on
   pg_ident_conf +=
   

7. Переопределите символьную ссылку плагина на заменитель. В кластерной конфигурации повторите это действие на реплике.

   sudo su - postgres
   ln -s /usr/pangolin/lib/plugins/libkms_substitute_plugin.so /usr/pangolin/lib/libconnection_plugin.so
   

Подключение защиты от привилегированных пользователей#

Инициализируйте механизм защиты от привилегированных пользователей только на мастер-ветке. Пароль передайте в открытом виде:

    sudo su - kmadmin_pg
    sudo -iu postgres -g kmadmin_pg /usr/pangolin/bin/initprotection
    Enter PGDATA directory [/pgdata/06/data]: /pgdata/06/data
    Enter security administrator names (comma-separated):sec_admin,sec_admin_backup
    Enter new security admin password for user "sec_admin":
    Enter it again:
    Enter new security admin password for user "sec_admin_backup":
    Enter it again:

Ожидаемый результат:

Protection mechanism is initialized.
syncing data to disk

Подключение TDE#

Внимание!

Пропустите действия в этом разделе, если не планируется подключение защиты конфигурации.

Выполните шаги:

1. Измените значение параметра is_tde_on на on в файле динамических параметров. В кластерной конфигурации действие повторите на реплике:

   sudo su - kmadmin_pg
   vim /etc/postgres/kms_dynamic_params.cfg
   

   Ожидаемый результат:

   ls -la /etc/postgres/kms_dynamic_params.cfg
   
   is_tde_on = on
   

2. Измените значение параметра is_tde_on на on в локальной конфигурации. В кластерной конфигурации действие повторите на реплике:

   sudo su - postgres
   # Для конфигурации standalone
   vim /pgdata/06/data/postgresql.conf
   # Для кластерной конфигурации
   vim /etc/pangolin-manager/postgres.yml
   

   Ожидаемый результат:

   • Для standalone-конфигурации:

   sudo su - postgres
   vim /pgdata/06/data/postgresql.conf
   

   • Для cluster-конфигурации:

   cat /pgdata/06/data/postgresql.conf | grep is_tde_on
   is_tde_on = 'on'
   

Подключение защиты конфигурации#

Чтобы подключить защиту конфигурации, измените значение параметра secure_config на on в файле динамических параметров. В кластерной конфигурации действие повторите на реплике:

sudo su - kmadmin_pg
vim /etc/postgres/kms_dynamic_params.cfg

Ожидаемый результат:

ls -la /etc/postgres/kms_dynamic_params.cfg
secure_config = on

Общие завершающие действия#

Включите БД:

• Если конфигурация standalone:

  sudo su - postgres
  /usr/pangolin/bin/pg_ctl start -D /pgdata/06/data
  

  Ожидаемый результат:

  done
  server started
  

• Если конфигурация кластерная. Действие сначала производится на мастере, затем на реплике:

  sudo su - postgres
  sudo systemctl start pangolin-manager
  

  Ожидаемый результат:

  sudo su - postgres
  list
  
  + Cluster: clustername (7258206222218039502) ----+--------------+---------+----+-----------+
  | Member              | Host                     | Role         | State   | TL | Lag in MB |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  | <IP-адрес>
  
  t | <IP-адрес>:<Порт> | Sync Standby | running |  2 |         0 |
  | <IP-адрес>  | <IP-адрес>:<Порт> | Leader       | running |  2 |           |
  +---------------------+--------------------------+--------------+---------+----+-----------+
  

  Ожидаемый результат в логе БД:

  LOG:  The initialization of KMS substitute completed successfully.
  

Ручное подключение СЗИ с KMS HashiCorp Vault#

Примечание:

В скриптах развертывания/обновления также реализован внешний скрипт по автоматическому подключению СЗИ.

Общие подготовительные действия#

Выключите БД на время ручного подключения СЗИ:

• Если конфигурация standalone:

  sudo su - postgres
  /usr/pangolin/bin/pg_ctl stop -D /pgdata/06/data
  

  Ожидаемый результат:

  waiting for server to shut down....
  done
  server stopped
  

• Если конфигурация кластерная, действие сначала производится на реплике, затем на мастере:

  sudo su - postgres
  sudo systemctl stop pangolin-manager
  

  Ожидаемый результат:

  sudo su - postgres
  list
  
  + Cluster: clustername (7258206222218039502) ----+---------+---------+----+-----------+
  | Member              | Host                     | Role    | State   | TL | Lag in MB |
  +---------------------+--------------------------+---------+---------+----+-----------+
  | <IP-адрес> | <IP-адрес>:<Порт> | Replica | stopped |    |   unknown |
  | <IP-адрес>  | <IP-адрес>:<Порт>  | Replica | stopped |    |   unknown |
  +---------------------+--------------------------+---------+---------+----+-----------+
  

Конфигурирование KMS HashiCorp Vault#

Выполните шаги:

1. Выполните аутентификацию пользователя на сервере Vault. Для аутентификации используйте клиентский токен:

   

2. Зайдите в хранилище kv и нажмите Create secret (1) для создания уникального CLUSTER_ID.

   

   Заполните следующие поля:

   1. В поле Path for this secret (2) укажите путь к параметру: postgresql/<CLUSTER_ID>/postgresql/<param>, где:

   • <CLUSTER_ID> - имя кластера. Должно быть уникальным для каждого кластера;

   • <param> - наименование параметра, например secure_config.

   2. В поле Version data (3, 4) укажите имя параметра - value, значение - off.

   3. Сохраните, нажав кнопку Save (5).

      

   4. Повторите действие по созданию остальных параметров из списка:

      is_tde_on = off
      allowed_servers =
      enabled_sec_admin_extra_auth_methods = cert
      encrypt_new_tablespaces = ddl
      masking_mode = disabled
      password_encryption = scram-sha-256
      password_policies_enable = on
      password_policy.allow_hashed_password = on
      password_policy.alpha_numeric = 3
      password_policy.check_syntax = on
      password_policy.custom_function =
      password_policy.deny_default = off
      password_policy.expire_warning = 7 days
      password_policy.failure_count_interval = 0
      password_policy.grace_login_limit = 0
      password_policy.grace_login_time_limit = 3 days
      password_policy.illegal_values = on
      password_policy.in_history = 4
      password_policy.lockout = on
      password_policy.lockout_duration = 24 hours
      password_policy.max_age = 0
      password_policy.max_failure = 6
      password_policy.max_inactivity = 0
      password_policy.max_rpt_chars = 0
      password_policy.min_age = 0
      password_policy.min_alpha_chars = 0
      password_policy.min_length = 16
      password_policy.min_lowercase = 0
      password_policy.min_special_chars = 1
      password_policy.min_uppercase = 1
      password_policy.password_strength_estimator_score = 3
      password_policy.reuse_time = 365 days
      password_policy.track_login = 0
      password_policy.transport_password_life_time = 0
      password_policy.transport_password_mark_automatic = off
      password_policy.use_password_strength_estimator = on
      performance_insights.masking = on
      psql_encrypt_password = on
      ssl = on
      pg_ident_conf +=
      

Подключение защиты от привилегированных пользователей#

Выполните команды инициализации механизма защиты от привилегированных пользователей (только на мастере). Пароль передайте в открытом виде:

sudo su - kmadmin_pg
sudo -iu postgres -g kmadmin_pg /usr/pangolin/bin/initprotection
Enter PGDATA directory [/pgdata/05/data]: /pgdata/05/data
Enter security administrator names (comma-separated):sec_admin,sec_admin_backup
Enter new security admin password for user "sec_admin":
Enter it again:
Enter new security admin password for user "sec_admin_backup":
Enter it again:

Ожидаемый результат:

Protection mechanism is initialized.
syncing data to disk

Подключение TDE#

Выполните шаги:

1. Действие необходимо пропустить, если не планируется подключение защиты конфигурации. Измените значение параметра is_tde_on на on на сервере VAULT, нажав кнопку Create new version:

   

2. Действие необходимо пропустить, если планируется подключение защиты конфигурации. Измените значение параметра is_tde_on на on в локальной конфигурации:

   • Для конфигурации standalone:

     sudo su - postgres
     vim /pgdata/05/data/postgresql.conf
     

   • Для кластерной конфигурации:

     sudo su - postgres
     vim /etc/pangolin-manager/postgres.yml
     

   Ожидаемый результат:

   • Для конфигурации standalone:

     cat /pgdata/05/data/postgresql.conf | grep is_tde_on
     is_tde_on = 'on'
     

   • Для кластерной конфигурации:

     cat /etc/pangolin-manager/postgres.yml | grep is_tde_on
     is_tde_on: on
     

Подключение защиты конфигурации#

Для подключения защиты конфигурации измените значение параметра secure_config на on на сервере VAULT, нажав кнопку Create new version:

Общие завершающие действия#

1. Включите БД:

   • Если конфигурация standalone:

     sudo su - postgres
     /usr/pangolin/bin/pg_ctl start -D /pgdata/05/data
     

     Ожидаемый результат:

     done
     server started
     

   • Если конфигурация кластерная, действие сначала производится на мастере, затем на реплике:

     sudo su - postgres
     sudo systemctl start pangolin-manager
     

     Ожидаемый результат:

     sudo su - postgres
     list
     
     + Cluster: clustername (7258206222218039502) ----+--------------+---------+----+-----------+
     | Member              | Host                     | Role         | State   | TL | Lag in MB |
     +---------------------+--------------------------+--------------+---------+----+-----------+
     | <IP-адрес> | <IP-адрес>:<Порт> | Sync Standby | running |  2 |         0 |
     | <IP-адрес>  | <IP-адрес>:<Порт>  | Leader       | running |  2 |           |
     +---------------------+--------------------------+--------------+---------+----+-----------+
     

Реализация функциональности лицензирования в продукте#

Для целей соблюдения лицензионных условий применяется файл, содержащий параметры редакции и подписанный цифровой подписью с использованием приватного ключа, хранимого в закрытом репозитории Platform V Pangolin SE. Реализация цифровой подписи основана на RSA-шифровании, предоставляемом библиотекой OpenSSL:

openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Примечание:

Для смены типа редакции на установленном кластере необходимо заменить файл редакции в директории с другими редакциями, после чего перезагрузить кластер и его компоненты. Если директория с редакциями содержит несколько файлов, автоматически будет выбрана редакция наиболее широкая по составу доступной функциональности.

Для работы с редакциями реализуется библиотека, предоставляющая возможность проверки наличия редакции, ее тип и срок действия. Данная библиотека статически подключается к продукту и его утилитам для проверки доступности лицензируемой функциональности. Файл редакции хранится и обрабатывается в формате JSON. Электронная цифровая подпись хранится в самом файле. Подписывается секция license, содержащая следующие поля:

• end_date - дата окончания в формате <year>-<month>-<day> <hour>:<minute>:<second>;

• licensee - лицо, имеющее право использования редакции;

• type - тип редакции в строковом представлении, отображающемся в перечисление LicenseType:

  typedef enum
  {
     LICTYPE_EnterpriseWith1C,
     LICTYPE_Trial,
     LICTYPE_Enterprise,
     LICTYPE_StandardWith1C,
     LICTYPE_Standard,
     LICTYPE_Undefined
  } LicenseType;
  

• features - список дополнительной функциональности в строковом представлении, отображающемся в перечисление LicensedFeature:

  typedef enum
  {
     LIC_TDE,
     LIC_AuthEncryption,
     LIC_Protection,
     LIC_SecuredConfig,
     LIC_Masking,
     LIC_CertPKCS12,
     LIC_PerformanceInsights,
     LIC_RelBlock,
     LIC_DateMotidification,
     LIC_ConnectionQuota,
     LIC_OutlineQuery,
     LIC_Support1C,
     LIC_PreparedStatements,
     LIC_NativePartitioning,
     LIC_DiagnosticTool,
     LIC_GraceAuth,
     LIC_ResourceConsumptionLimits,
     LIC_JsonTable,
     LIC_GI,
     LIC_Tracing,
     LIC_COUNT
  } LicensedFeature;
  

• total_CPUs - количество ядер процессора, которые может использовать запущенный продукт Platform V Pangolin SE (в случае отсутствия поля процессам доступны все ядра);

• total_mem - объем доступной памяти в байтах, которую могут использовать процессы запущенного продукта Platform V Pangolin SE (в случае отсутствия поля процессам доступна вся память).

Пример файла редакции:

{
   "license" : {
      "end_date" : "2023-07-01 12:00:00",
      "features" : [ ],
      "licensee" : "Pangolin internal tests", 
      "total_CPUs" : 6,
      "total_mem": 3221225472,
      "type" : "EnterpriseWith1C"
   },
   "sign" : "XvfXFnSWqws/6S1tVehdq4o5lO1s4LEYkhlkPVtINm6KLBb3xI43EYaTT2eVHqAAnSnjxtLyn0/dzCg+waLQdk5OLK2ezGGK2iFVey3H167C5hXUxFvXGMbhnXvEHZILHFnsKrF6FUlnbt3kOlKjLLX2qetpm/i280FTjeSk52CdB3JeJwzL8tEzyq8j9ZimeA9N985fKHdpwOG4kCRFjJ1dmdmNZmQjqNQyv4aF1DL5yb4OU+1jHvfSaQ7Mg/ap8Nsc4cYQ7Yj3VDB7Upr35l1FnQdXEzoL7Ln9vMTkUktka4WDWdqlxOeOdxxdt/4usMRd8vwqE6JRQ6x8SJN06A=="
}  

Внимание!

На данный момент возможность расширения типа редакции дополнительной функциональностью отключена макросом SUPPORT_FEATURE_LICENSING. Поэтому перечисление дополнительной функциональности в секции features не влияет на содержание редакции.

Ограничение по использованию ресурсов делается на базе механизма контрольных групп (cgroup). Проверка заключается в сопоставлении данных в файле редакции с ограничениями, используемыми в контрольной группе, где запущен главный процесс postmaster.

Особенности при смене редакции Enterprise (Trial) на Standard#

При изменении типа редакции:

• В случае ранее настроенного шифрования данных зашифрованные данные остаются доступны, но дальнейшее шифрование не осуществляется.

• При настроенной защите данных от привилегированных пользователей механизм защиты отключается, функции администратора безопасности становятся недоступны, а внутренние каталоги безопасности не очищаются.

• В рамках обновления продукта с использованием утилиты pg_upgrade каталоги безопасности обновлены не будут.

• Активная редакция задается в виде пути к конкретному файлу, и для ее обновления необходимо заменить файл, расположенный по пути, указанному при запуске СУБД.

• Обновление с версий до 5.3.1 возможно двумя способами:

  • обновление кластера до текущей версии с использованием редакции Trial -> отключение шифрования -> переход на регулярную версию Standard;

  • обновление кластера до версии 5.3.1 -> отключение шифрования -> обновление до текущей версии с редакцией Standard.

• В ОС РЕД ОС использование механизма контрольных групп для приведения сервера к условиям редакции в части доступных ресурсов не поддерживается.

Добавляемые утилиты#

Помимо описанных выше, реализована утилита, подписывающая редакции, а также утилита, осуществляющая проверку ранее подписанной редакции - psql_rsa_sign и psql_rsa_verify соответственно.

Утилита подписания в качестве входных параметров принимает файл с приватным ключем для формирования ЭЦП, а также файл, содержащий данные редакции. Данные на корректность утилитой не проверяются. Дополнительно может быть указан путь для сохранения подписанной редакции. Если этот параметр не указан, то подпись добавляется во входной файл.

Параметры запуска утилиты подписания:

• --key, -k  <path> - расположение файла, содержащего приватный RSA-ключ (обязательный параметр);

• --out, -o <path> - расположение подписанного файла редакции (опциональный параметр, в случае отсутствия подпись будет добавлена ко входному файлу);

• --version, -V - версия продукта, в составе которой была собрана данная утилита;

• --help, -? - вывод справки о способах запуска утилиты.

Утилита не входит в состав продукта, хранится в виде исполняемого файла в закрытом репозитории команды Platform V Pangolin SE.

Утилита проверки подписанной редакции в качестве входных параметров принимает подписанный файл редакции. Во время работы утилита проверяет корректность подписанного содержимого редакции и производит верификацию подписи с прекомпилированным публичным ключом (если ключ не задан явно через параметры запуска). Также производится печать данных файла редакции в человекочитаемом варианте.

Параметры запуска утилиты верификации:

• --json, -j - флаг, указывающий о необходимости вывода данных о верификации, а также параметров редакции в формате JSON (используется для автоматизации установки);

• --key, -k <path> - расположение файла, содержащего публичный RSA-ключ (в случае отсутствия данного параметра для верификации используется прекомпилированный ключ продукта);

• --version, -V - версия продукта, в составе которой была собрана данная утилита;

• --help, -? - вывод справки о способах запуска утилиты.

Утилита верификации входит в состав продукта (RPM) в месте расположения всех исполняемых файлов, а также отдельно дублируется в utilities для возможности проверки типа редакции перед началом установки с помощью атоматизированных скриптов.

Использование подписанного файла редакции сервером#

Загрузка редакции#

Файл подписанной редакции располагается на машине установки экземпляра продукта. Переменная окружения pangolin_license_path задает путь к директории, которая содержит редакции или путь к конкретному файлу редакции. Данная переменная окружения используется самим сервером и его утилитами для получения данных об используемой редакции. По умолчанию используется директория /opt/pangolin_license. В директории единовременно могут находиться несколько редакций. Модуль загрузки редакций выбирает редакцию с валидным сроком действия, руководствуясь следующей системой приоритетов по доступной функциональности (от высокого к низкому):

• EnterpriseWith1C;

• Trial;

• Enterprise;

• StandardWith1C;

• Standard.

При запуске сервера происходит загрузка редакции и ее верификация. Если в директории с редакциями не нашлось ни одной актуальной редакции, то сервер не будет запущен, а соответствующее сообщение появится в логе. Актуальность определяется соответствием валидному сроку действия редакции, а так же наличием подписи, проходящей верификацию предскомпилированным публичным ключом.

Ограничение лицензируемой функциональности под управлением конфигурационного параметра#

После успешной загрузки редакции осуществляется проверка ограничений функциональности, сконфигурированной для запуска, на соответствие типу загруженной редакции. Функциональность, ограниченная типом редакции, отключается через параметры конфигурации (если это предусматривает функциональность). В этом случае используется источник параметра PGC_S_OVERRIDE, чтобы параметры не могли быть переопределены после запуска. В логе указывается форсированное отключение такой функциональности, если она была предусмотрена к включению в конфигурации запуска. Предупреждение об отключении функциональности защиты параметров через защищенное хранилище пишется в лог вне зависимости от значения параметра, так как при редакции типа Standard параметры из защищенного хранилища не считываются, даже при наличии конфигурации подключения.

Ограничение лицензируемой функциональности, не имеющей управляющих параметров#

Если функциональность не может быть выключена при запуске СУБД, то проверка возможности исполнения данной функциональности осуществляется в момент исполнения. К такому типу функциональности относятся:

• нативное интервальное партиционирование;

• маскирование паролей;

• квотирование подключений;

• шифрование пользовательских данных.

Функциональность шифрования данных после включения не может быть отключена через параметр конфигурации is_tde_on из-за наличия шифрования не только пользовательских данных, но и служебной информации WAL и CHECKPOINT. Поэтому данная лицензируемая функциональность при редакции Standard и включенном параметре is_tde_on осуществляет шифрование служебной информации, но не пользовательских данных. Параметр конфигурации сервера не переопределяется на старте, однако, в лог пишется предупреждение о невозможности использования шифрованных табличных пространств. На работающем экземпляре продукта проверка доступности данной функциональности должна проверяться с помощью функции мониторинга check_tde_is_on(), а не через прямое чтение параметра конфигурации.

Проверка времени действия редакции#

При запуске основного процесса СУБД создается процесс, контролирующий время жизни редакции. Данный процесс осуществляет мониторинг текущего времени на предмет соответствия времени действия редакции. Если время действия редакции закончилось, производится попытка перечитать редакцию, чтобы загрузить новые данные при обновлении редакции, после чего процесс мониторинга продолжает штатное функционирование с новыми данными. В противном случае серверу посылается сигнал SIGINT для завершения работы продукта.

Редакция может быть перезагружена без ожидания окончания времени действия текущей редакции. Для этого необходимо выполнить перезагрузку (reload) СУБД. Если при обновлении редакции ее тип изменился на более широкую по функциональности редакцию, то процесс контролирующий время действия редакции будет использовать новое время для проверки актуальности. Ограничения функциональности будут определяться первоначальной редакцией. Это связано с тем, что большинство параметров конфигурации лицензируемой функциональности могут быть изменены только при запуске продукта. При этом в логе после загрузки новой редакции будет получено предупреждение о том, что для использования новой редакции в полном объеме необходима перезагрузка СУБД. В случае, если при обновлении редакции загружена редакция с меньшим набором функциональности, продукт будет остановлен автоматически, так как при конфигурации продукта Platform V Pangolin SE с Pangolin Manager последний автоматически перезапустит СУБД с новой редакцией.

Для предотвращения попытки остановить процесс проверки редакции сигналом SIGSTOP основной процесс отслеживает состояние процесса данной проверки и в случае остановки самостоятельно посылает ему сигнал SIGCONT для возобновления процесса.

Периодическая проверка данным процессом также позволяет отследить ситуацию изменения времени на машине после запуска сервера.

Проверка редакции в утилитах#

Утилиты, подлежащие лицензированию, проверяют данные редакции при запуске и в случае ограничений выводят соответствующие сообщения.

Агент ротации сертификатов помимо проверки редакции осуществляет проверку времени действия редакции в процессе функционирования, по аналогии с процессом проверки в СУБД. Попытка перезагрузки редакции будет осуществлена при окончании текущей редакции либо при обработке сигнала SIGHUP.