Установка#

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

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

Примечание:

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

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

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

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

• Перед запуском скрипта инсталляции добавьте в файлы sudoerc основного узла, реплики и арбитра строку user_ansible ALL=(ALL:ALL) NOPASSWD: ALL.

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

Единый дистрибутив 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==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 # или 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
sudo pip3 install 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

Далее установка будет производиться в виртуальной среде 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, и другие);

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

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

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

• и другие.

Примечание:

Для развертывания Pangolin на окружении 1С выполните шаги с пометкой «для окружения 1С», вместо «»обычное окружение.

Установка на ОС РЕД ОС 7.3#

1. Создайте директорию с дистрибутивом Pangolin (в каталоге, который доступен для чтения для всех пользователей ОС, например в каталоге /tmp).

   mkdir distrib
   

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

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

   unzip docker_redos73-D-06.001.05-16-distrib.zip
    
   unzip owned-distrib.zip
    
   tar -xvf owned-distrib.tar.gz
   

   Либо самостоятельно найдите пакет в архиве:

   docker_redos73-D-06.001.05-16-distrib.zip/owned-distrib.zip/owned-distrib.tar.gz/platform-v-pangolin-dbms-06.001.05-redos7.3.2.x86_64.rpm
   

4. Установите пакет platform-v-pangolin-dbms-06.001.05-redos7.3.2.x86_64.rpm:

   sudo dnf -y install platform-v-pangolin-dbms-06.001.05-redos7.3.2.x86_64.rpm
   

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

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

6. Добавьте файл с лицензией license.json в папку /opt/pangolin_license/ с правами postgres:postgres.

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

   sudo su - postgres
   

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

   vi ~/.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=127.0.0.1
   export PGPORT=5432
   export PGCLIENTENCODING=UTF8
   export CLNAME=clustername
   export PGDATA=/pgdata/06/data
   export MANPATH=$MANPATH:$PGHOME/share/man
   export PG_LICENSE_PATH=/opt/pangolin_license/
   

9. Перечитайте переменные окружения для bash_profile:

   . ~/.bash_profile
   

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

    • обычное окружение:

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

    • окружение 1С:

      initdb --data-checksums --locale ru_RU.UTF-8 --username postgres --pgdata $PGDATA
      # для 1С крайне важно указывать локаль, в будущем она будет использоваться для инициализации БД, что создаёт 1С
      

11. Отредактируйте конфигурационный файл с помощью текстового редактора. Добавьте в конец файла $PGDATA/postgresql.conf:

    • обычное окружение:

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

    • окружение 1С:

      listen_addresses = '*'
      port = 5432
      max_connections = 200 # с учётом ожидаемого количества
      superuser_reserved_connections = 3
      
      optimize_for_1c = 'on'
      shared_preload_libraries = 'pg_stat_statements, plantuner'
      
      # Параметры памяти имеет смысл скорректировать с учетом ваших КТС
      # huge_pages = on
      # shared_buffers = 96GB # от 1/4 до 2/5 RAM, если не используются HugePages - не более 128GB
      # effective_cache_size = 288GB # 3/4 RAM
      temp_buffers = 256MB
      maintenance_work_mem = 256MB
      wal_buffers = 64MB
      work_mem = 128MB
      
      max_worker_processes = 8    # равно количеству ядер
      max_parallel_workers_per_gather = 4
      max_parallel_workers = 8    # равно количеству ядер
      max_parallel_maintenance_workers = 4
      
      fsync = 'on'
      checkpoint_completion_target = 0.9
      checkpoint_timeout = 30min
      wal_level = 'minimal'
      max_wal_senders = 0
      wal_compression = 'off'
      wal_sync_method = 'fdatasync'
      synchronous_commit = 'off'
      commit_delay = 1000
      commit_siblings = 5
      
      # min_wal_size = 100GB
      # max_wal_size = 100GB
      
      bgwriter_delay = 20ms
      bgwriter_lru_maxpages = 400
      bgwriter_lru_multiplier = 4.0
      autovacuum = 'on'
      track_counts = 'on'
      autovacuum_max_workers = 4   # 1/4 количества ядер
      autovacuum_naptime = 20s
      max_locks_per_transaction = 1000
      max_prepared_transactions = 1000
      max_files_per_process = 8000
      effective_io_concurrency = 200
      from_collapse_limit = 11
      join_collapse_limit = 11
      random_page_cost = 1.1
      geqo = 'on'
      geqo_threshold = 12
      default_statistics_target = 1000
      password_encryption = 'md5'
      logging_collector   = 'on'
      log_min_messages    = 'log'
      log_statement       = 'none'
      pgaudit.log         = 'none'
      performance_insights.enable = 'off'
      password_policies_enable = 'off'
      pg_outline.enable = 'off'
      enable_monitor_object_modification_date = 'off'
      object_modification_date_keep_interval  = '1 week'
      enabled_sec_admin_extra_auth_methods = 'md5,trust,peer,cert'
      enabled_extra_auth_methods           = 'md5,trust,peer,cert'
      ssl = 'off'
      track_io_timing = 'off'
      row_security = 'off'
      standard_conforming_strings = 'off'
      escape_string_warning = 'off'
      plantuner.fix_empty_table = on
      

12. Убедитесь в наличии записей в конфигурационном файле $PGDATA/pg_hba.conf:

    local   all             all                                     trust
    host    all             all             0.0.0.0/0               trust
    

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

    pg_ctl -D /pgdata/06/data/ -l start
    

Примечание:

По умолчанию, каталог для сохранения журналов (логов) работы СУБД — $PGDATA/log. Если указан параметр log_directory, может быть переопределен. Посмотреть текущие логи можно командой:

ls -la $PGDATA/log/*

Примечание:

Возможные ошибки:

1. Не читается файл лицензий:

   Check license file "/opt/pangolin_license/license.json" : file is not found
   

   Решение:

   Проверьте доступность под пользователем операционной системы postgres файла лицензии:

   1. Указание в переменной PG_LICENSE_PATH=/opt/pangolin_license/

      [postgres@srv ~]$ echo $PG_LICENSE_PATH
      /opt/pangolin_license/
      

      При необходимости исправьте:

      export PG_LICENSE_PATH=/opt/pangolin_license/
      

   2. Доступность файла лицензии:

      [postgres@srv ~]$ ls -la $PG_LICENSE_PATH
      total 12
      drwxr-xr-x  2 postgres postgres 4096 Apr 12 12:17 .
      drwxr-xr-x. 5 root     root     4096 Apr 12 12:14 ..
      -rw-r--r--  1 postgres postgres  500 Apr 12 12:17 license_trial_202407.json
      

2. Скопированы некорректные символы в конфигурационный файл. После запуска в логе появляется запись об ошибках чтения конфигурационного файла в $PGDATA/log/*. Например:

   2024-04-12 12:25:50.689 MSK [60403] КОНТЕКСТ:  строка 100 файла конфигурации "/pgdata/06/data/pg_hba.conf"
   2024-04-12 12:25:50.689 MSK [60403] СООБЩЕНИЕ:  неверный метод проверки подлинности " "
   

   Решение:

   Скорее всего привнесены лишние символы при копировании строк из инструкции. Необходимо либо скорректировать, либо удалить проблемные строки и ввести их с клавиатуры например через vi.

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

    postgres@srv-64-44:~$ psql
    psql (15.5)
    Type "help" for help.
    
    postgres=#
    

Установка на ОС Astra Linux 1.7#

1. Создайте директорию с дистрибутивом Pangolin (в каталоге, который доступен для чтения для всех пользователей ОС, например в каталоге /tmp):

   mkdir distrib
   

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

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

unzip docker_6_1_5_astrase17-D-06.001.05-16-distrib.zip

unzip owned-distrib.zip

tar -xvf owned-distrib.tar.gz

Либо самостоятельно найдите пакет в архиве:

docker_6_1_5_astrase17-D-06.001.05-16-distrib.zip/owned-distrib.zip/owned-distrib.tar.gz/platform-v-pangolin-dbms_6.1.5_amd64.deb

4. Установите пакет platform-v-pangolin-dbms_6.1.2_amd64.deb:

sudo apt-get install /tmp/distrib/platform-v-pangolin-dbms_6.1.5_amd64.deb

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

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

6. Добавьте файл с лицензией license.json в папку /opt/pangolin_license/.

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

sudo su - postgres

8. Добавьте строку окружения в ~/.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=127.0.0.1
export PGPORT=5432
export PGCLIENTENCODING=UTF8
export CLNAME=clustername
export PGDATA=/pgdata/06/data
export MANPATH=$MANPATH:$PGHOME/share/man

9. Перечитайте переменные окружения для bash_profile:

. ~/.bash_profile

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

    • Обычное окружение:

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

    • Окружение 1С:

      initdb --data-checksums --locale ru_RU.UTF-8 --username postgres --pgdata $PGDATA
      

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

      Примечание:

      В случае возникновении ошибки:

      initdb: error while loading shared libraries: libjsoncpp.so.1: cannot open shared object file: No such file or directory
      

      Необходимо установить пакет:

      sudo apt install libjsoncpp1
      

11. Отредактируйте конфигурационный файл $PGDATA/postgresql.conf с помощью текстового редактора. Добавьте в конец файла:

    • Обычное окружение:

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

    • Для окружения 1С рекомендуются следующие параметры:

      listen_addresses = '*'
      port = 5432
      max_connections = 200 # с учётом ожидаемого количества
      superuser_reserved_connections = 3
      
      optimize_for_1c = 'on'
      shared_preload_libraries = 'pg_stat_statements, plantuner'
      
      # Параметры памяти имеет смысл скорректировать с учетом ваших КТС
      # huge_pages = on
      # shared_buffers = 96GB # от 1/4 до 2/5 RAM, если не используются HugePages - не более 128GB
      # effective_cache_size = 288GB # 3/4 RAM
      temp_buffers = 256MB
      maintenance_work_mem = 256MB
      wal_buffers = 64MB
      work_mem = 128MB
      
      max_worker_processes = 8    # равно количеству ядер
      max_parallel_workers_per_gather = 4
      max_parallel_workers = 8    # равно количеству ядер
      max_parallel_maintenance_workers = 4
      
      fsync = 'on'
      checkpoint_completion_target = 0.9
      checkpoint_timeout = 30min
      wal_level = 'minimal'
      max_wal_senders = 0
      wal_compression = 'off'
      wal_sync_method = 'fdatasync'
      synchronous_commit = 'off'
      commit_delay = 1000
      commit_siblings = 5
      
      # min_wal_size = 100GB
      # max_wal_size = 100GB
      
      bgwriter_delay = 20ms
      bgwriter_lru_maxpages = 400
      bgwriter_lru_multiplier = 4.0
      autovacuum = 'on'
      track_counts = 'on'
      autovacuum_max_workers = 4   # 1/4 количества ядер
      autovacuum_naptime = 20s
      max_locks_per_transaction = 1000
      max_prepared_transactions = 1000
      max_files_per_process = 8000
      effective_io_concurrency = 200
      from_collapse_limit = 11
      join_collapse_limit = 11
      random_page_cost = 1.1
      geqo = 'on'
      geqo_threshold = 12
      default_statistics_target = 1000
      password_encryption = 'md5'
      logging_collector   = 'on'
      log_min_messages    = 'log'
      log_statement       = 'none'
      pgaudit.log         = 'none'
      performance_insights.enable = 'off'
      password_policies_enable = 'off'
      pg_outline.enable = 'off'
      enable_monitor_object_modification_date = 'off'
      object_modification_date_keep_interval  = '1 week'
      enabled_sec_admin_extra_auth_methods = 'md5,trust,peer,cert'
      enabled_extra_auth_methods           = 'md5,trust,peer,cert'
      ssl = 'off'
      track_io_timing = 'off'
      row_security = 'off'
      standard_conforming_strings = 'off'
      escape_string_warning = 'off'
      plantuner.fix_empty_table = on
      

12. Отредактируйте конфигурационный файл $PGDATA/pg_hba.conf:

    local   all             all                                     peer
    host    all             all             0.0.0.0/0               trust
    

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

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

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

    postgres@srv-64-44:~$ psql
    psql (15.5)
    Type "help" for help.
    
    postgres=#
    

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

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

   mkdir distrib
   

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

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

   tar -xf distrib.tar.gz
   

4. Установите пакет platform-v-pangolin-dbms.x86_64.rpm:

   sudo apt-get install platform-v-pangolin-dbms.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/lib
   export PATH=$PATH:/usr/pangolin/bin
   export PG_PLUGINS_PATH=/usr/pangolin/lib
   export PGHOME=/usr/pangolin
   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 (15.5)
    Type "help" for help.
    
    postgres=#
    

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

Установка СУБД Pangolin в автоматическом режиме осуществляется с помощью системы управления конфигурациями Ansible включает в себя:

• Развертывание Pangolin без дополнительных настроек (playbook_install.yaml).

• Развертывание ролевой модели, пользовательской БД, схем и расширений (installer/scripts_external/configure_roles/playbook_configure_roles.yaml).

  Внимание!

  В процессе установки системы автоматически создается пользователь postgres, а также, в файл sudoerc, добавляется строка с правами для управления Pangolin.

Шаги:

1. Выполните команду распаковки:

   tar -xvf <имя дистрибутива>.tar.gz
   

   Внимание!

   Установку необходимо запускать на отдельной машине, а не на одном из узлов кластера.

   Для создания окружения на машине, с которой будет производиться установка, необходимо установить:

   • linux-пакеты:

     • python3-virtualenv;

     • python39-devel;

     • python39-pip;

     • python39.

   • python-пакеты для ansible==4.10.0:

     • 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.

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

   cd /tmp/YourCatalog/installer
   

3. Перед запуском установки заполните файл hosts.ini в зависимости от конфигурационного решения (standalone/cluster). Добавьте информацию о хостах и учетных данных пользователя, которые будет использовать Ansible.

   Файл 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 для 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=host.local		ansible_user=usertest 	ansible_password=passwordtest       # в случае установки по имени DNS
   

   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=127.0.0.1		ansible_user=usertest 	ansible_password=passwordtest       # в случае установки по IP-адресу
   replica	    ansible_host=127.0.0.2		ansible_user=usertest 	ansible_password=passwordtest       # в случае установки по IP-адресу
   [arbiter_nodes]
   arbiter 		ansible_host=127.0.0.3		ansible_user=usertest 	ansible_password=passwordtest       # в случае установки по IP-адресу
   

   Внимание!

   Если в файле 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
       37336564633635636235643262336362353963363639323737643166393764623266643033353263
       3534346339646333613939333939666437346433353866370a393833346261326536396335623732
       63303438393262333038373832646136313933623735646330366435343933653537353162613835
       3230393434373439610a333533646331346163626633613362643131326531383835623030376634
       3038
   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.

4. Заполните настраиваемый конфигурационный файл 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.

   Например, чтобы переопределить порт etcd, в custom_config_sample.yml поменяйте параметр port на нужный:

   etcd:
     port: 2379   # Port for etcd host
   

   Внимание!

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

5. Сгенерируйте сертификаты, в случае, если в настраиваемом конфигурационном файле выше было выставлено значение для параметра: 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=(127.0.0.1 127.0.0.2 127.0.0.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 необходимо подписать данные сертификаты в удостоверяющем центре (подробнее о генерации сертификатов смотрите в документе «Руководство администратора», раздел «Генерация сертификатов»).

   Примечание:

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

6. Заполните параметры для виртуальных сред, в случае необходимости.

   В случае если на КТС ограничен доступ к установке пакетов из pip-репозитория, заранее подготовьте виртуальную среду python (postgres_venv_path) для последующей работы утилиты развертывания/обновления.

   Внимание!

   Данная виртуальная среда должна располагаться в каталоге установки (в случае postgres_venv_path - в $PGHOME/postgresql_venv).

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

   Чтобы указать пути к установленным виртуальным средам, в утилите развертывания/обновления отредактируйте параметры postgres_venv_path и patroni_venv_path.

   Для этого в доступной среде скачайте необходимые библиотеки, требуемые в последующем для установки/обновления, и перенесите данные виртуального окружения на целевые КТС.

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

   sudo python3 -m pip install virtualenv;
   

   Для виртуального окружения postgres_venv_path из-под пользователя postgres выполните:

   python3 -m venv /usr/testing_venv_postgresql_venv --copies
   source /usr/testing_venv_postgresql_venv/bin/activate;
   pip install -U pip;
   pip install PyYAML==5.3.1 netaddr==0.7.19 psycopg2-binary==2.8.6 flake8==3.7.9 ruamel.yaml==0.16.12 argparse==1.4.0 requests==2.23.0 python-daemon==2.2.4 pexpect==4.8.0 cryptography==3.3.1 ansible-core==2.11.5;
   deactivate;
   

   Для виртуального окружения patroni_venv_path установите:

   sudo python3 -m venv /usr/testing_venv_patroni_venv --copies
   source /usr/testing_venv_patroni_venv/bin/activate;
   pip install -U pip;
   pip install urllib3==1.25.9 PyYAML==5.3.1 six==1.15.0 kazoo==2.8.0 psycopg2-binary==2.8.6 flake8==3.7.9 python-dateutil==2.8.1 boto==2.49.0 requests==2.23.0 python-etcd==0.4.5 click==7.1.2 prettytable==0.7.2 psutil==5.7.3 cdiff==1.0 python-daemon==2.2.4 setuptools-rust==1.1.1;
   deactivate;
   

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

   postgres_venv_path: '/usr/testing_venv_postgresql_venv'
   patroni_venv_path: '/usr/testing_venv_patroni_venv'
   

   Для отключения данной функциональности достаточно не заполнять значения postgres_venv_path и patroni_venv_path.

7. Выполните ansible-сценарий. Пример:

   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=/root/nv installation_type=cluster tag=cluster-patroni-etcd-pgbouncer segment={segment} custom_config=templates/custom_config_sample.yml' --ask-vault-pass
   

   Примечание:

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

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

   • license_standard_1C

   • license_standard

   • license_enterprise_1C

   • license_enterprise

   • license_trial

   Скрипты развертывания и обновления поддерживают следующие виды конфигураций:

   • standalone-postgresql-only;

   • standalone-postgresql-pgbouncer;

   • standalone-patroni-etcd-pgbouncer;

   • cluster-patroni-etcd-pgbouncer;

   Запуск установки осуществляется из каталога installer. Ниже приведены шаблоны ansible-сценариев для установки standalone и кластерного решений:

   • Установка standalone решения Pangolin с Pangolin Pooler:

   ansible-playbook playbook_install.yaml \
   -i inventories/standalone/hosts.ini \
   -t always,standalone-postgresql-pgbouncer \
   -vv \
   -e '{"as_admins":['test_admin']}' \
   -e '{"as_TUZ":['test_tuz']}' \
   --extra-vars 'local_distr_path=${} \
   installation_type=standalone \
   tag=standalone-postgresql-pgbouncer \
   segment=${} \
   stand=${}' \
   custom_config=${} \
   --ask-vault-pass
   

   • Установка кластерного решения 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":['test_admin']}' \
   -e '{"as_TUZ":['test_tuz']}' \
   --extra-vars 'local_distr_path=${} \
   installation_type=cluster \
   tag=cluster-patroni-etcd-pgbouncer \
   segment=${} \
   pangolin_license_path=${} \
   stand=${}' \
   custom_config=${} \
   --ask-vault-pass
   

Примеры рабочих ansible-сценариев#

Далее будут рассмотрены примеры:

1. Рабочий ansible-сценарий для установки кластерного решения 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-6.2.0

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

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

   • -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. Ролевая модель и скрипты ее настройки описаны в документе «Руководство администратора», раздел «Ролевая модель и права доступа».

2. Рабочий ansible-сценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью 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).

3. Рабочий сценарий развертывания дополнительных настроек ролевой модели, пользовательской БД и расширений с помощью запускаемого 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':SCRAM-SHA-256$4096:2H6ypfV3DJP0LUZLrSnPsA==$yOIhGySEsNiY9p91PkJ5a2/kUQhxAwzUAQcjwCHov3A=:gd7X+KDJ+4GY44H9Xelan5dkhLwLLyDZLrhw4LhmDo8= 'as_tuz_pass':SCRAM-SHA-256$4096:TTysuRbQcMM3tOQAoR7LWg==$t89DzT7Y92HXMQxolmGXxG8AGQPvu/yDWV4leOAXiO0=:0vZGdq40uKFLLzfzB2JJ9SD1Ei8rxSObHUlPUcdHByM=" -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;

4. Рабочий ansible-сценарий развертывания СРК с помощью ansible-роли:

   ansible-playbook playbook_SRC.yaml \
   -i inventories/cluster/hosts.ini \
   -vv \
   --extra-vars "local_distr_path=${} \
   utility_path=${} \
   custom_config=${}' \
   --ask-vault-pass
   

   Примечание:

   utility_path – путь до каталога с утилитами. Входит в состав дистрибутива.

   Внимание!

   В случае, если необходимо развернуть стенд с дополнительными настройками rsyslog, необходимо отдельно запустить playbook_rsyslog.yaml, который располагается в компоненте installer по пути scripts_external/rsyslog.

5. Рабочий ansible-сценарий развертывания СРК с помощью ansible-роли:

   ansible-playbook playbook_rsyslog.yaml \
   -i inventories/cluster/hosts.ini \
   -vv \
   --extra-vars "local_distr_path=${} \
                installation_type=cluster \
                tag=cluster-patroni-etcd-pgbouncer \
   --ask-vault-pass
   

   Внимание!

   В случае, если необходимо развернуть стенд с дополнительными настройками monitoring, необходимо отдельно запустить playbook_monitoring.yaml, который располагается в компоненте installer по пути scripts_external/monitoring.

6. Рабочий ansible-сценарий развертывания СРК с помощью ansible-роли:

   ansible-playbook playbook_monitoring.yaml \
   -i inventories/cluster/hosts.ini \
   -vv \
   --extra-vars "local_distr_path=${} \
                installation_type=cluster \
                tag=cluster-patroni-etcd-pgbouncer \
                monitoring_zabbix = True
   --ask-vault-pass
   

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

   • monitoring_zabbix – параметр для установки стенда на мониторинг;

   • duid – уникальный идентификатор, генерируемый на портале ДИ.

Действия в случае неудачной установки#

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

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

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

Разделение клиентской и серверной частей DBMS в отдельные RPM-пакеты#

В СУБД Pangolin RPM-пакет разделен на две независимые части - клиентскую и серверную, обе из которых доступны пользователю после установки. Также пользователю доступна возможность независимого развертывания клиентской части с удаленным доступом к серверу. Такое разделение упрощает процессы обновления и модификации СУБД Pangolin.

Состав клиентского RPM-пакета#

В состав пакета включены (перенесены из серверной части) следующие утилиты, а также файлы документации и локали, сответствующие им:

• clusterdb;

• createdb;

• createuser;

• dropdb;

• dropuser;

• pangolin-linker;

• pg_amcheck;

• pg_basebackup;

• pgbench;

• pg_dump;

• pg_dumpall;

• pg_isready;

• pg_probackup;

• pg_receivewal;

• pg_recvlogical;

• pg_restore;

• pg_verifybackup;

• psql;

• reindexdb;

• vacuumdb.

libpq#

Примечание:

libpq — это интерфейс СУБД Pangolin для программирования приложений на языке C. Библиотека содержит набор функций, используя которые клиентские программы могут передавать запросы серверу СУБД Pangolin и принимать результаты этих запросов. Клиентские программы должны использовать для определения API-функций заголовочный файл libpq.h и должны компоноваться с библиотекой libpq.

В состава клиентского rpm-пакета включен libpq.h:

/usr/pangolin-dbms-libpq-6.2.0/
└── include
    └── libpq.h
 
1 directories, 1 files

Описание решения и ограничения#

Имя серверного rpm-пакета изменено с platform-v-pangolin-dbms-{версия}.00-rhel8.9.x86_64.rpm на pangolin-dbms-{версия}-rhel8.9.x86_64.rpm. Добавление суффикса -major_ver.minor_ver к имени пакета позволяет разворачивать пакет с СУБД рядом с его предыдущей версией, в том случае, если у этой версии суффикс -major_ver.minor_ver отличается (изменения, требующие миграции данных при обновлении СУБД могут быть только при изменении либо минорной, либо мажорной версии СУБД).

Имя клиентского rpm-пакета - pangolin-dbms-6.2-client-6.2.0-rhel8.9.x86_64.rpm.

После развертывания все пользователи ОС получают возможность запуска клиентской части СУБД независимо от расположения сервера БД:

• содержимое /usr/pangolin-dbms-client-{full_dbms_ver}/bin получает права доступа 0755;

• остальное содержимое в /usr/pangolin-dbms-client-{full_dbms_ver}/ получает права доступа 0444;

• владельцем директории /usr/pangolin-dbms-client-{full_dbms_ver}/ и ее содержимого является root.

Для корректной работы Pangolin Manager c клиентской частью СУБД:

• в unit-файл pangolin-manager.service службы systemd была добавлена новая переменная окружения PG_CLIENT_PLUGINS_PATH=/usr/pangolin-dbms-client/lib;

• в конфигурационный файл Pangolin Manager postgres.yml был добавлен новый параметр bin_dir_client, в котором указывается путь до исполняемых файлов клиентской части СУБД.

Так как утилита pg_upgrade использует одновременно утилиты как из серверной, так и из клиентской части для ее запуска было добавлено два дополнительных ключа:

• --old-bindirclient - путь к исполняемым файлам клиентской части обновляемой версии (по умолчанию параметру присваивается значение из ключа -b);

• --new-bindirclient - путь к исполняемым файлам клиентской части новой версии (по умолчанию параметру присваивается значение из ключа -В).

Для запуска (после установки в ОС rpm/deb-пакета) утилиты из клиентской части СУБД необходимо либо указать полный путь до утилиты, например, /usr/pangolin-dbms-client/bin/psql, либо использовать psql в командной строке.

Запуск возможен из-под любого пользователя ОС. Передавать дополнительно какие-либо environment-переменные (например, LD_LIBRARY_PATH или PG_PLUGINS_PATH) не нужно.

Имеются следующие ограничения:

• клиентская часть будет разворачиваться в отдельную директорию /usr/pangolin-dbms-client-{full_dbms_ver}, отличную от директории развертывания серверной части;

• при развертывании rpm-пакета автоматически будут создаваться следующие символические ссылки:

  • /usr/pangolin-dbms-client → /usr/pangolin-dbms-client-{full_dbms_ver};

  • /usr/pangolin-dbms-client-{major_dbms_ver} → /usr/pangolin-dbms-client-{full_dbms_ver}.

• утилиты, перенесенные в клиентскую часть (за исключением pangolin-linker) и указанные в /usr/pangolin-dbms-client/bin не должны дублироваться в /usr/pangolin/bin;

• в версии СУБД Pangolin 6.2.0 при включенной функциональности TDE клиентская часть СУБД, развернутая на отдельной от серверной части машине, работает некорректно;

• при развертывании СУБД с помощью скриптов автоматизации клиентская часть устанавливается автоматически на той же машине, что и серверная;

• утилита pg_verifybackup, входящая в состав клиентской части СУБД Pangolin, в случае развертывания последней на отдельном от серверной части узле, должна запускаться с ключем -n/--no-parse-wal.

etcd#

В кластере Pangolin для хранения информации о состоянии кластера patroni используется хранилище etcd (устанавливается инсталлятором). Поддерживаема версия пакета под разных ОС указана на странице «Системные требования».

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 /
[pprb_dev ~]$ 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:

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

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

• standalone:

  • host.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==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
   

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
     

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

Проверка работоспособности с Хранилищем секретов#

Чтобы убедиться в том, что при запуске СУБД Pangolin происходит запрос сертификатов, выполните следующие действия:

1. Запустите перехват сетевого трафика порту, где работает эмулятор SecMan:

   tshark -PV -C Custom -w outfile -i ens192 -f "tcp port <Порт>" 2>&1 | less                        
   

2. Запустите СУБД Pangolin вручную посредством pg_ctl:

   pg_ctl -D /pgdata/05/data start                                                                 
   

3. Проверьте в лог-файле сообщения о подключении к SecMan и получении сертификатов.

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

   Лог содержит сообщения:

   LOG:  Fetch certificate from SecMan.                                                          
   LOG:  certificate, private key and certificate chain are loaded from PKCS#12 specified in file
   

4. Остановите перехват трафика и проверьте наличие пакетов обмена данными с эмулятором SecMan.

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

   Также в сетевом трафике присутствуют пакеты обмена данными с эмулятором SecMan:

   Transmission Control Protocol, Src Port: 8201, Dst Port:                                      
   ...                                                                                           
   "certificate": "MIIJgQIBAzCCCUcGCSqGSIb3DQ...                                                 
   "expires": "2023-12-02T11:50:57Z",\n                                                          
   ...                                                                                           
   

Проверка корректной передачи в строку запуска 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/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 |
  +---------------------+--------------------------+---------+---------+----+-----------+
  | <Адрес>         | <Адрес>:<Порт>         | 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/patroni/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.

   

3. Выполните следующие действия:

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

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

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

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

   • Сохраните, нажав кнопку 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/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 на сервере VAULT, нажав кнопку Create new version:

   

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

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

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

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

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

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

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

     cat /pgdata/06/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/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-адрес> | <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 возможно двумя способами:

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

  • обновление кластера до версии 5.3.1 -> отключение шифрования -> обновление до 6.2.0 с лицензией 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 с оркестратором patroni последний автоматически перезапустит СУБД с новой лицензией.

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

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

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

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

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