postgresql — настроить конфигурации pg_hba.conf и postgresql.conf
Чтобы разрешить другим компьютерам соединяться с вашим PostgreSQL сервером, замените ‘localhost’ на IP адрес вашего сервера или в качестве альтернативы на 0.0.0.0, чтобы подключить все интерфейсы.
Настраиваем pg_hba.conf
- Для начала нам нужно создать своего пользователя с паролем. Возможно для этого потребуется сначала открыть доступ главному пользователю базы, postgres. Заходим в pg_hba.conf:
sudo nano /etc/postgresql/9.x/main/pg_hba.conf
и меняем вот эту строку:
Database administrative login by Unix domain socket
local all postgres md5
Database administrative login by Unix domain socket
local all postgres trust
Перезапускаем сервер postgreSQL:
sudo service postgresql restart
Database administrative login by Unix domain socket
local all postgres md5
Database administrative login by Unix domain socket
local all username md5
И перезапускаем сервер:
sudo service postgresql restart
Pg hba conf как применить изменения
PgAdmin — это инструмент управления с открытым исходным кодом для баз данных, входящий в загрузку PostgreSQL. Этот инструмент предлагает полную поддержку Юникода, быструю, многопоточную обработку запросов и инструменты редактирования, а также поддержку всех типов объектов PostgreSQL.
4. Создание нового пользователя.
a. Щелкните правой кнопкой мыши PostgreSQLx.x (
b. Выберите New Object > New Login Role . На вкладке Properties в поле Role name введите наименование роли пользователя PostgreSQL для администрирования PostgreSQL.
c. На вкладке Definition введите в поле Password уникальный и надежный пароль для администрирования PostgreSQL (появится подсказка, что нужно ввести его дважды).
Пароль, который не должен легко угадываться или узнаваться, общий пароль, должен иметь длину не менее 14 символов и состоять из смеси прописных и строчных букв, цифр и специальных символов. Необходимо будет повторно ввести этот пароль на последующих шагах.
5. Нажмите кнопку ОК . Запомните наименование роли пользователя, созданное на этом шаге, для дальнейшего использования.
Конфигурирование базы данных PostgreSQL, расположенной на отдельном сервере, а не на сервере ThingWorx
Этот раздел является необязательным для среды разработки, но должен быть реализован во всех производственных средах.
По умолчанию сервер PostgreSQL устанавливается в заблокированном состоянии. Сервер будет прослушивать соединения только с локального компьютера. Чтобы ThingWorx взаимодействовал с сервером PostgreSQL, необходимо внести некоторые изменения в конфигурацию так, чтобы PostgreSQL знал о прослушивании соединений от других пользователей (пользователь ThingWorx, значение по умолчанию: twadmin) и/или от других компьютеров (ThingWorx, установленный на отдельном сервер).
Для выполнения этих шагов необходимо знать, где находится каталог данных PostgreSQL. Для Windows папка данных по умолчанию: C:\Program Files\PostgreSQL\x.x\data .
Измените файл pg_hba.conf и добавьте в зависимости от нужной конфигурации следующие строки:
Если нужно разрешить соединение со всех адресов IPv4:
host all all 0.0.0.0/0 md5
Если нужно разрешить подключение только с определенного адреса IPv4 (замените < ipAddress >IP-адресом компьютера, осуществляющего подключение):
host all all
Если нужно разрешить подключение со всех адресов IPv6:
host all all ::0/0 md5
Если нужно разрешить подключение только с определенного адреса IPv6 (замените
host all all
Возможна любая другая комбинация, если использовать дополнительные строки разрешений (для отдельных IP-адресов или их диапазонов) или маски подсети, соответствующие компьютерам, которым требуется доступ к базе данных PostgreSQL.
После любого изменения этого файла требуется перезапуск сервиса базы данных.
Конфигурирование и выполнение сценария базы данных PostgreSQL
Чтобы настроить базу данных и область таблицы PostgreSQL, необходимо сконфигурировать и выполнить сценарий thingworxPostgresDBSetup .
1. Добавьте папку <папка-установки-postgres>/bin в системную переменную PATH .
2. Создайте папку с наименованием ThingworxPostgresqlStorage на диске, на котором находится папка ThingworxStorage (по умолчанию — в корневом каталоге). Обратите внимание на следующее.
◦ При создании папки с помощью команды -d
◦ Необходимо указать для опции -l существующий путь. Например, -l D:\ThingworxPostgresqlStorage . В этом сценарии ваша папка не создается.
◦ Для этой папки должен существовать владелец и должны быть заданы соответствующие права доступа. Владельцем этой папки должен быть тот же пользователь, который запускает сервис PostgreSQL, и которому назначены права Full Control; обычно это пользователь NETWORK_SERVICE, но в вашей среде он может быть другим.
4. Если необходимо, сконфигурируйте сценарий. Используйте опции из приведенной ниже таблицы.
Опции сценария thingworxPostgresDBSetup
По умолчанию
tablespace
Наименование области таблицы
-t thingworx
Номер порта PostgreSQL
Наименование создаваемой базы данных PostgreSQL
-d thingworx
Имя хост-компьютера.
-h localhost
tablespace_location
/ThingworxPostgresqlStorage
Требуется. Расположение в файловой системе, где хранятся файлы, представляющие объекты базы данных.
adminusername
Имя администратора
-a postgres
thingworxusername
Имя пользователя, имеющего разрешения на запись в базу данных.
5. Выполните сценарий.
Конфигурирование и выполнение сценария схемы поставщика моделей/данных
Чтобы настроить схему поставщика моделей/данных PostgreSQL, необходимо сконфигурировать и выполнить сценарий thingworxPostgresSchemaSetup . Это позволит настроить общедоступную схему в вашей базе данных для экземпляра PostgreSQL, установленного на локальном компьютере localhost.
2. Если необходимо, сконфигурируйте сценарий. Используйте опции из приведенной ниже таблицы.
Опции сценария thingworxPostgresSchemaSetup
По умолчанию
IP-адрес или наименование хост-компьютера базы данных.
-h localhost
Номер порта PostgreSQL.
Наименование базы данных, которую необходимо использовать.
-d thingworx
Наименование схемы, которую необходимо использовать.
-s mySchema
Имя пользователя для обновления схемы базы данных
Имеются три опции.
• all — настройка схем поставщиков моделей и данных в указанной базе данных.
• model — настройка схемы поставщика моделей в указанной базе данных.
• data — настройка схемы поставщика данных в указанной базе данных.
3. Выполните сценарий.
Конфигурирование файла platform-settings.json
1. Создайте папку ThingworxPlatform в корневом каталоге диска, на котором была установлена Tomcat, или задайте системную переменную среды, которая указывает на эту папку. Обратите внимание на следующее.
◦ Чтобы указать расположение, в котором хранятся настройки ThingWorx, задайте необходимое расположение как значение переменной среды THINGWORX_PLATFORM_SETTINGS . Убедитесь, что папка, на которую ссылается переменная THINGWORX_PLATFORM_SETTINGS , существует и доступна для записи пользователю Tomcat. Эта переменная среды должна быть сконфигурирована в наборе системных переменных среды.
◦ Невозможно будет запустить сервер ThingWorx, если он не будет иметь права на чтение и запись в этой папке.
2. Поместите файл platform-settings.json в папку ThingworxPlatform . Этот файл доступен на сайте загрузки программного обеспечения.
Если сервер PostgreSQL не совпадает с сервером ThingWorx, то при возникновении проблем, связанных с установкой ThingWorx, просмотрите журналы Tomcat и файл platform-settings.json . При стандартной установке предполагается, что оба сервера находятся на одном и том же компьютере.
(Необязательно) Шифрование пароля PostgreSQL
(Необязательно) Установка пакета клиента PostgreSQL и пользователя PostgreSQL
Чтобы выполнить команды PostgreSQL на компьютере клиента для сервера PostgreSQL, выполняйте их от имени пользователя PostgreSQL. Пакет postgresql-client-x.x можно установить на клиентском компьютере. Инструкции по установке см. в документации по дистрибутиву PostgreSQL. Этот пакет содержит некоторые инструменты администрирования, такие как psql .
Как настроить репликацию в PostgreSQL
Настраиваем репликацию данных в PostgreSQL на двух виртуальных серверах.
Эта инструкция — часть курса «PostgreSQL для новичков».
Смотреть весь курс
Введение
В статье мы расскажем, что такое репликация и где она применяется. Также на примере двух виртуальных серверов настроим репликацию данных в PostgreSQL и проверим, что она работает.
Что такое репликация
Репликация — это дублирование данных, когда данные с одного сервера полностью повторяются на других. Приложения пишут данные в одну базу данных PostgreSQL, а изменения автоматически синхронизируются на другие базы.
Репликация используется для достижения двух целей:
- Повышение отказоустойчивости. Если один из серверов выйдет из строя, то остальные продолжат работу.
- Повышение производительности. Распределение данных по серверам в разных частях страны или мира повышает скорость доступа к данным для местных пользователей.
Виды репликации в PostgreSQL
Существует несколько видов репликаций, у каждого из них свои особенности. Но прежде чем рассказывать о видах, нужно хотя бы поверхностно познакомиться с WAL — журналом предзаписи транзакций.
Когда PostgreSQL получает команду на изменение данных, она не сразу изменяет их на диске. Сначала она записывает изменения в WAL. Этот журнал нужен для того, чтобы в случае сбоя сервера можно было восстановить незафиксированные данные. Также WAL используется и для репликации данных.
Итак, в PostgreSQL есть несколько видов репликации:
Потоковая репликация (Streaming Replication). Это репликация, при которой от основного сервера PostgreSQL на реплики передается WAL. И каждая реплика затем по этому журналу изменяет свои данные. Для настройки такой репликации все серверы должны быть одной версии, работать на одной ОС и архитектуре. Потоковая репликация в Postgres бывает двух видов — асинхронная и синхронная.
- Асинхронная репликация. В этом случае PostgreSQL сначала применит изменения на основном узле и только потом отправит записи из WAL на реплики. Преимущество такого способа — быстрое подтверждение транзакции, т.к. не нужно ждать пока все реплики применят изменения. Недостаток в том, что при падении основного сервера часть данных на репликах может потеряться, так как изменения не успели продублироваться.
- Синхронная репликация. В этом случае изменения сначала записываются в WAL хотя бы одной реплики и только после этого фиксируются на основном сервере. Преимущество — более надежный способ, при котором сложнее потерять данные. Недостаток — операции выполняются медленнее, потому что прежде чем подтвердить транзакцию, нужно сначала продублировать ее на реплике.
Логическая репликация (Logical Replication). Логическая репликация оперирует записями в таблицах PostgreSQL. Этим она отличается от потоковой репликации, которая оперирует физическим уровнем данных: биты, байты, и адреса блоков на диске. Возможность настройки логической репликации появилась в PostgreSQL 10.
Этот вид репликации построен на механизме публикации/подписки: один сервер публикует изменения, другой подписывается на них. При этом подписываться можно не на все изменения, а выборочно. Например, на основном сервере 50 таблиц: 25 из них могут копироваться на одну реплику, а 25 — на другую.
Также есть несколько ограничений, главное из которых — нельзя реплицировать изменения структуры БД. То есть если на основном сервере добавится новая таблица или столбец — эти изменения не попадут в реплики автоматически, их нужно применять отдельно.
В отличие от потоковой репликации, логическая может работать между разными версиями PostgreSQL, ОС и архитектурами.
Облачные базы данных
Готовые к работе управляемые базы данных MySQL с встроенной репликацией.
Установить PostgreSQL
Перейдем к практике: настроим потоковую асинхронную репликацию в режиме Master-Replica: один сервер — основной, в него можно писать данные, другой — реплика, из него можно только читать.
На примере платформы Selectel создадим два отдельных сервера PostgreSQL, один из которых будет основным (Master), а второй — репликой (Replica).
В панели управления платформой заходим в раздел Облачная платформа — Серверы, нажимаем кнопку Создать сервер.
Укажем имя сервера — Master. Так нам будет проще ориентироваться в серверах. Выберем ОС — Ubuntu 22.04, конфигурацию — 2 vCPU, 8 ГБ оперативной памяти и 10 ГБ диска.
В разделе Сеть нужно выбрать подсеть с публичным адресом, чтобы к виртуальной машине можно было подключаться из интернета. В разделе Доступ нужно проверить, что вы либо записали пароль root-пользователя, либо указали правильный SSH-ключ для подключения к машине.
По такому же принципу создаем второй сервер, только укажем другое имя — Replica. Остальные параметры оставим такими же.
В итоге у нас получилось два сервера. Обратите внимание, что у них есть публичные и приватные IP-адреса.
Публичные адреса мы будем использовать для подключения к машинам, а приватные — для настройки репликации.
Теперь нужно подключиться к каждому серверу по SSH. Рекомендуем открыть 2 окна терминала и держать их открытыми, потому что мы будем часто переключаться между серверами.
Итак, подключаемся к серверам и устанавливаем PostgreSQL на каждом из них:
apt-get update apt-get install postgresql Все, сервера готовы к настройке репликации. Сейчас они ничем не отличаются друг от друга, кроме названия. Перейдем к настройке каждого из них.
Настроить Master-сервер
Репликацию будем выполнять под пользователем postgres, который автоматически создается после установки PostgreSQL. Установим ему пароль, он нам понадобится позже:
su - postgres psql -c "ALTER ROLE postgres PASSWORD 'ВАШ_ПАРОЛЬ'" exit Далее нужно разрешить этому пользователю подключаться из Replica-сервера в Master. Для этого мы отредактируем файл /etc/postgresql/12/main/pg_hba.conf.
Обратите внимание, что мы показываем настройку репликации на примере PostgreSQL 12, поэтому в пути к файлу есть номер — 12. Если у вас другая версия PostgreSQL, то вам нужно поменять путь к файлу.
Итак, откроем файл:
nano /etc/postgresql/12/main/pg_hba.conf Найдем в нем строчку «If you want to allow non-local connections, you need to add more» и впишем после нее такую строчку:
host replication postgres REPLICA_ВНУТРЕННИЙ_IP/32 md5Так мы разрешаем пользователю postgres подключаться к этому серверу из Replica.
# If you want to allow non-local connections, you need to add more # “host” records. In that case you will also need to make PostgreSQL # listen on a non-local interface via the listen_address # configuration parameter, or via the -i or -h command line switches. host replication postgres 192.168.0.3/32 md5 Обратите внимание, что мы используем приватные адреса, потому что виртуальные машины находятся в одной сети. При этом нам не нужно открывать порты, настраивать Firewall и так далее. Если ваши машины будут находиться в разных сетях или вы хотите, чтобы они общались друг с другом по публичным адресам — скорее всего вам придется настроить Firewall.
Далее нужно указать настройки репликации. Открываем конфигурационный файл PostgreSQL:
nano /etc/postgresql/12/main/postgresql.conf Находим в нем эти параметры, раскомментируем их и подставляем указанные значения.
listen_addresses = 'localhost, MASTER_ВНУТРЕННИЙ_IP' wal_level = hot_standby archive_mode = on archive_command = 'cd .' max_wal_senders = 8 hot_standby = on Все, Master настроен. Чтобы применить настройки, перезапускаем сервер:
service postgresql restart Настроить Replica-сервер
Переключаемся в окно терминала Replica-сервера. Перед началом настройки нужно остановить PostgreSQL-сервер:
service postgresql stop Аналогично Master-серверу отредактируем файл pg_hba.conf. В то же самое место вставим ту же самую строчку, но только теперь укажем IP-адрес мастера.
nano /etc/postgresql/12/main/pg_hba.conf Добавляем в него строчку:
host replication postgres MASTER_ВНУТРЕННИЙ_IP/32 md5 Затем правим файл postgresql.conf. Настройки те же самые, как и у Master, только нужно поменять IP-адрес. Открываем файл на редактирование:
nano /etc/postgresql/12/main/postgresql.conf Находим в нем эти параметры, раскомментируем их и подставляем указанные значения:
listen_addresses = 'localhost, REPLICA_ВНУТРЕННИЙ_IP' wal_level = hot_standby archive_mode = on archive_command = 'cd .' max_wal_senders = 8 hot_standby = on Сейчас настройки обоих серверов одинаковые, отличаются только IP-адреса. Это потому, что при необходимости реплики могут становиться мастером, а вся разница будет в наличии одного лишь файла. О нем расскажем далее.
Прежде чем Replica-сервер сможет начать реплицировать данные, нужно создать новую БД, идентичную Master-серверу. Для этого воспользуемся утилитой pg_basebackup. Она создаст бэкап с Master-сервера и скачает его на Replica-сервер. Эту операцию нужно выполнять от имени пользователя postgres, поэтому логинимся от него:
su - postgres Далее переходим в каталог с базой данных:
cd /var/lib/postgresql/12/ Удалим каталог с дефолтной БД и снова его создадим, но уже пустой:
rm -rf main; mkdir main; chmod go-rwx main Теперь выгрузим БД с мастера. Для выполнения этой команды нужно будет ввести пароль от пользователя postgres, который мы задавали в самом начале настройки Master-сервера.
pg_basebackup -P -R -X stream -c fast -h MASTER_ВНУТРЕННИЙ_IP -U postgres -D ./main В этой команде есть важный параметр -R. Он означает, что PostgreSQL-сервер также создаст пустой файл standby.signal. Несмотря на то, что файл пустой, само наличие этого файла означает, что этот сервер — реплика.
Файл standby.signal появился только в PostgreSQL версии 12. Раньше вместо него создавался файл recovery.conf, в котором хранились настройки для подключения к Master-серверу. Имейте это ввиду, если вы используете более ранние версии PostgreSQL.
Возвращаемся в root-пользователя и запускаем PostgreSQL-сервер:
exit service postgresql start Проверить репликацию
Теперь нужно протестировать репликацию и убедиться, что мы все правильно настроили. На Master-сервере создадим таблицу и вставим в нее одну строчку:
su - postgres psql -c "CREATE TABLE test_table (id INT, name TEXT);" psql -c "INSERT INTO test_table (id, name) VALUES (1, 'test');" Переключимся в терминал Replica-сервера и проверим, что таблица с данными появилась:
su - postgres psql -c "SELECT * FROM test_table;" id | name ----+------ 1 | test (1 row)
Еще одна проверка — попробуем создать новую таблицу на сервере Replica. Если мы все сделали правильно, то сервер не должен позволить нам этого сделать, потому что он настроен только на репликацию с основной БД.
На Replica-сервере выполняем команду:
psql -c "CREATE TABLE test_table2 (id INT, name TEXT);" ERROR: cannot execute CREATE TABLE in a read-only transaction Значит репликация настроена правильно.
Теперь покажем, как можно из Replica-сервера сделать Master. Сымитируем ситуацию, что основной сервер вышел из строя. Для этого в консоли управления платформой Selectel просто выключим сервер Master.
Чтобы перевести Replica-сервер в режим записи, выполните команду:
/usr/lib/postgresql/12/bin/pg_ctl promote -D /var/lib/postgresql/12/main Проверяем, снова пробуем создать новую таблицу:
psql -c "CREATE TABLE test_table2 (id INT, name TEXT);" На этот раз таблица создастся. Значит, мы перевели сервер из режима чтения в режим записи.
Но нужно понимать, что запросы от приложений не начнут автоматически направляться на этот сервер. Если сервисы и приложения подключались к «старому» Master-серверу напрямую, они так и будут пытаться подключаться к нему.
Обычно в такой ситуации используется балансировщик нагрузки. Он сам следит за состоянием серверов и распределяет нагрузку между всеми рабочими инстансами. При этом приложения отправляют запросы не напрямую в СУБД, а в балансировщик нагрузки.
Заключение
В статье мы показали, как настроить репликацию в PostgreSQL и проверить ее. Это не сложно, но требует некоторой подготовки. Есть и другой способ — использовать managed-решения.
На нашей платформе есть управляемая PostgreSQL, которая создается в несколько кликов мыши. Вам не придется настраивать и сопровождать СУБД, а репликация и балансировщик нагрузки есть «из коробки». Если Master-сервер выйдет из строя, платформа автоматически переключит одну из реплик в режим записи и перенаправить на нее все запросы.
Установка и использование PostgreSQL в Ubuntu 22.04
Резервное копирование и восстановление PostgreSQL: pg_dump, pg_restore, wal-g
Зарегистрируйтесь в панели управления
И уже через пару минут сможете арендовать сервер, развернуть базы данных или обеспечить быструю доставку контента.
19.1. Файл pg_hba.conf#
Вход в систему клиента контролируется конфигурационным файлом, который традиционно называется pg_hba.conf и хранится в каталоге данных кластера базы данных. ( HBA означает аутентификацию на основе хоста). При инициализации каталога данных с помощью initdb устанавливается файл pg_hba.conf по умолчанию. Однако возможно размещение файла конфигурации аутентификации в другом месте; см. параметр конфигурации hba_file.
Общий формат файла pg_hba.conf состоит из набора записей, по одной на строку. Пустые строки игнорируются, а также любой текст после символа комментария # . Запись может продолжаться на следующей строке, если строка заканчивается обратной косой чертой. (Обратные косые черты не имеют специального значения, кроме случаев, когда они находятся в конце строки). Запись состоит из нескольких полей, разделенных пробелами и/или табуляцией. Поля могут содержать пробелы, если значение поля заключено в двойные кавычки. Если одно из ключевых слов в поле базы данных, пользователя или адреса (например, all или replication ) заключено в кавычки, то это слово теряет свое специальное значение и просто соответствует базе данных, пользователю или хосту с таким именем. Продолжение строки с помощью обратной косой черты применяется даже внутри текста в кавычках или комментариев.
Каждая запись определяет тип соединения, диапазон IP-адресов клиента (если применимо для данного типа соединения), имя базы данных, имя пользователя и метод аутентификации, который будет использоваться для соединений, соответствующих этим параметрам. Первая запись с совпадающим типом соединения, адресом клиента, запрошенной базой данных и именем пользователя используется для аутентификации. Нет «перехода» или «резервного варианта»: если выбрана одна запись и аутентификация не удалась, последующие записи не рассматриваются. Если нет совпадающей записи, доступ запрещен.
Запись может иметь несколько форматов:
localdatabaseuserauth-method[auth-options] hostdatabaseuseraddressauth-method[auth-options] hostssldatabaseuseraddressauth-method[auth-options] hostnossldatabaseuseraddressauth-method[auth-options] hostgssencdatabaseuseraddressauth-method[auth-options] hostnogssencdatabaseuseraddressauth-method[auth-options] hostdatabaseuserIP-addressIP-maskauth-method[auth-options] hostssldatabaseuserIP-addressIP-maskauth-method[auth-options] hostnossldatabaseuserIP-addressIP-maskauth-method[auth-options] hostgssencdatabaseuserIP-addressIP-maskauth-method[auth-options] hostnogssencdatabaseuserIP-addressIP-maskauth-method[auth-options]
Значение полей следующее:
Эта запись соответствует попыткам подключения с использованием Unix-доменных сокетов. Без такой записи подключения через Unix-доменные сокеты запрещены.
Эта запись соответствует попыткам подключения, сделанным с использованием TCP/IP. Записи host соответствуют попыткам подключения с использованием SSL или без SSL , а также попыткам подключения с использованием зашифровки GSSAPI или без GSSAPI .
Примечание
Возможность удаленных TCP/IP-соединений не будет доступна, если сервер не запущен с соответствующим значением параметра конфигурации listen_addresses, так как поведение по умолчанию заключается в прослушивании TCP/IP-соединений только на локальном адресе цикла обратной связи localhost .
Эта запись соответствует попыткам подключения, сделанным с использованием TCP/IP, но только когда подключение осуществляется с использованием шифрования SSL .
Для использования этой опции сервер должен быть построен с поддержкой SSL . Кроме того, SSL должен быть включен путем установки параметра конфигурации ssl (см. Раздел 17.9 для получения дополнительной информации). В противном случае запись hostssl игнорируется, за исключением записи предупреждения о том, что она не может соответствовать никаким соединениям.
Этот тип записи имеет противоположное поведение по сравнению с hostssl ; он соответствует только попыткам подключения, сделанным через TCP/IP, которые не используют SSL .
Эта запись соответствует попыткам подключения, сделанным с использованием TCP/IP, но только когда подключение осуществляется с использованием шифрования GSSAPI .
Для использования этой опции сервер должен быть собран с поддержкой GSSAPI . В противном случае запись hostgssenc игнорируется, за исключением записи предупреждения о том, что она не может соответствовать никаким соединениям.
Этот тип записи имеет противоположное поведение по сравнению с hostgssenc ; он соответствует только попыткам подключения, сделанным через TCP/IP, не использующим шифрование GSSAPI .
Указывает, с какими именами баз данных соответствует данная запись. Значение all указывает, что оно соответствует всем базам данных. Значение sameuser указывает, что запись соответствует, если запрашиваемая база данных имеет то же имя, что и запрашиваемый пользователь. Значение samerole указывает, что запрашиваемый пользователь должен быть членом роли с тем же именем, что и запрашиваемая база данных. ( samegroup — это устаревшее, но все еще принимаемое написание samerole ). Суперпользователи не считаются членами роли для целей samerole , если они явно не указаны членами роли, непосредственно или косвенно, а не только потому что они являются суперпользователями. Значение replication указывает, что запись соответствует, если запрашивается физическое соединение репликации, однако оно не соответствует логическим соединениям репликации. Обратите внимание, что физические соединения репликации не указывают на конкретную базу данных, в то время как логические соединения репликации указывают на нее. В противном случае это имя конкретной базы данных Tantor SE-1C . Можно указать несколько имен баз данных, разделив их запятыми. Отдельный файл, содержащий имена баз данных, может быть указан, поставив символ @ перед именем файла.
Определяет, с какими именами пользователей базы данных соответствует данная запись. Значение all указывает, что оно соответствует всем пользователям. В противном случае, это либо имя конкретного пользователя базы данных, либо имя группы, предшествующее символу + . (Напомним, что в Tantor SE-1C нет реального различия между пользователями и группами; символ + означает «соответствует любой из ролей, которые являются прямыми или косвенными членами этой роли», в то время как имя без символа + соответствует только этой конкретной роли). В этом контексте суперпользователь считается членом роли только в том случае, если он явно является членом роли, прямо или косвенно, а не только по причине того, что он является суперпользователем. Можно указать несколько имен пользователей, разделяя их запятыми. Отдельный файл с именами пользователей можно указать, предшествуя имени файла символом @ .
Указывает адрес(а) клиентской машины, с которыми соответствует данная запись. Это поле может содержать имя хоста, диапазон IP-адресов или одно из специальных ключевых слов, упомянутых ниже.
Диапазон IP-адресов указывается с использованием стандартной числовой нотации для начального адреса диапазона, затем символа слэш ( / ) и длины маски CIDR . Длина маски указывает количество старших битов IP-адреса клиента, которые должны совпадать. Биты справа от этого должны быть нулевыми в заданном IP-адресе. Между IP-адресом, символом слэш ( / ) и длиной маски CIDR не должно быть пробелов.
Примеры типичного задания диапазона IPv4-адресов в этом формате: 172.20.143.89/32 для одного хоста, или 172.20.143.0/24 для небольшой сети, или 10.6.0.0/16 для более крупной сети. Диапазон IPv6-адресов может выглядеть так: ::1/128 для одного хоста (в данном случае это адрес петли IPv6), или fe80::7a31:c1ff:0000:0000/96 для небольшой сети. 0.0.0.0/0 представляет все IPv4-адреса, а ::0/0 представляет все IPv6-адреса. Для указания одного хоста используйте длину маски 32 для IPv4 или 128 для IPv6. В сетевом адресе не пропускайте конечные нули.
Запись, указанная в формате IPv4, будет соответствовать только IPv4-соединениям, а запись, указанная в формате IPv6, будет соответствовать только IPv6-соединениям, даже если представленный адрес находится в диапазоне IPv4-in-IPv6. Обратите внимание, что записи в формате IPv6 будут отклонены, если библиотека C системы не поддерживает адреса IPv6.
Вы также можете написать all , чтобы сопоставить любой IP-адрес, samehost , чтобы сопоставить любой из собственных IP-адресов сервера, или samenet , чтобы сопоставить любой адрес в любой подсети, с которой сервер напрямую связан.
Если указано имя хоста (любое, что не является диапазоном IP-адресов или специальным ключевым словом, рассматривается как имя хоста), это имя сравнивается с результатом обратного разрешения имени IP-адреса клиента (например, обратного DNS-поиска, если используется DNS). Сравнение имен хостов не чувствительно к регистру. Если есть совпадение, то выполняется прямое разрешение имени (например, прямой DNS-поиск) для проверки, совпадает ли какой-либо из адресов, к которым разрешается имя хоста, с IP-адресом клиента. Если оба направления совпадают, то запись считается совпадающей. (Имя хоста, которое используется в pg_hba.conf , должно быть тем, которое возвращает разрешение имени адреса IP клиента, в противном случае строка не будет сопоставлена. Некоторые базы данных имен хостов позволяют связывать IP-адрес с несколькими именами хостов, но операционная система вернет только одно имя хоста при запросе разрешения IP-адреса).
Спецификация имени хоста, начинающаяся с точки ( . ), соответствует суффиксу фактического имени хоста. Таким образом, .example.com будет соответствовать foo.example.com (но не просто example.com ).
Когда имена хостов указываются в файле pg_hba.conf , убедитесь, что разрешение имен происходит достаточно быстро. Может быть полезно настроить локальный кэш разрешения имен, такой как nscd . Также вы можете захотеть включить параметр конфигурации log_hostname , чтобы видеть имя хоста клиента вместо IP-адреса в журнале.
Эти поля не применимы к local записям.
Примечание
Пользователи иногда задаются вопросом, почему имена хостов обрабатываются таким сложным образом, с двумя разрешениями имени, включая обратный запрос IP-адреса клиента. Это усложняет использование функции в случае, если обратная запись DNS клиента не настроена или возвращает нежелательное имя хоста. Это делается прежде всего для повышения эффективности: таким образом, попытка подключения требует не более двух запросов разрешения, одного обратного и одного прямого. Если возникает проблема с разрешением для некоторого адреса, это становится проблемой только этого клиента. Гипотетическая альтернативная реализация, которая выполняла бы только прямые запросы, должна была бы разрешать каждое имя хоста, указанное в файле CPU , при каждой попытке подключения. Это могло бы быть довольно медленным, если перечислено много имен. И если возникает проблема с разрешением для одного из имен хостов, это становится проблемой для всех.
Также, для реализации функции сопоставления суффиксов необходимо выполнить обратный поиск, поскольку фактическое имя клиентского хоста должно быть известно для его сопоставления с шаблоном.
Обратите внимание, что такое поведение согласуется с другими популярными реализациями контроля доступа на основе имени хоста, такими как Apache HTTP Server и TCP Wrappers.
IP-address
IP-mask
Эти два поля могут быть использованы в качестве альтернативы для IP-адреса / mask-length обозначения. Вместо указания длины маски, фактическая маска указывается в отдельном столбце. Например, 255.0.0.0 представляет собой IPv4 длину маски CIDR 8, а 255.255.255.255 представляет собой длину маски CIDR 32.
Эти поля не применимы к local записям.
Определяет метод аутентификации, который будет использоваться при соединении, соответствующем данной записи. Возможные варианты кратко описаны здесь; подробности приведены в разделе Раздел 19.3. Все варианты указываются в нижнем регистре и учитывают регистр, поэтому даже аббревиатуры, такие как ldap , должны быть указаны в нижнем регистре.
Разрешить подключение без ограничений. Этот метод позволяет любому, кто может подключиться к серверу базы данных Tantor SE-1C , войти в систему от имени любого пользователя Tantor SE-1C , без необходимости вводить пароль или проходить аутентификацию. Подробности см. в разделе Раздел 19.4.
Отклонить соединение безусловно. Это полезно для “ фильтрации ” определенных хостов из группы, например, строка reject может блокировать подключение определенного хоста, в то время как позднее строка позволяет остальным хостам в определенной сети подключаться.
Выполнить аутентификацию SCRAM-SHA-256 для проверки пароля пользователя. См. Раздел 19.5 для получения подробной информации.
Выполнить аутентификацию SCRAM-SHA-256 или MD5, чтобы проверить пароль пользователя. См. Раздел 19.5 для получения подробной информации.
Требовать от клиента предоставить незашифрованный пароль для аутентификации. Поскольку пароль отправляется в открытом виде по сети, это не следует использовать в ненадежных сетях. См. Раздел 19.5 для получения подробной информации.
Использовать GSSAPI для аутентификации пользователя. Это доступно только для TCP/IP соединений. См. Раздел 19.6 для получения подробной информации. Он может использоваться совместно с шифрованием GSSAPI.
Использовать SSPI для аутентификации пользователя. Это доступно только в Windows. См. Раздел 19.7 для получения подробной информации.
Получить имя пользователя операционной системы клиента, связавшись с сервером идентификации на клиенте и проверьте, совпадает ли оно с запрошенным именем пользователя базы данных. Аутентификация идентификации может использоваться только для соединений TCP/IP. При указании для локальных соединений будет использоваться аутентификация по пиру. См. Раздел 19.8 для получения подробной информации.
Получить имя пользователя операционной системы клиента из операционной системы и проверьте, совпадает ли оно с запрошенным именем пользователя базы данных. Это доступно только для локальных подключений. См. Раздел 19.9 для получения дополнительной информации.
Аутентификация с использованием сервера LDAP . См. Раздел 19.10 для получения подробной информации.
Аутентификация с использованием сервера RADIUS. См. Раздел 19.11 для получения подробной информации.
Аутентификация с использованием клиентских сертификатов SSL. См. Раздел 19.12 для получения подробной информации.
Аутентификация с использованием сервиса Pluggable Authentication Modules (PAM), предоставляемого операционной системой. См. Раздел 19.13 для получения подробной информации.
Аутентификация с использованием службы аутентификации BSD, предоставляемой операционной системой. См. Раздел 19.14 для получения подробной информации.
После поля auth-method может следовать поле(я) в формате name = value , которые указывают параметры для метода аутентификации. Подробности о доступных параметрах для каждого метода аутентификации приведены ниже.
В дополнение к указанным ниже специфическим для метода параметрам, существует метод-независимый параметр аутентификации clientcert , который может быть указан в любой записи hostssl . Этот параметр может быть установлен в значение verify-ca или verify-full . Оба варианта требуют от клиента предоставления действительного (доверенного) SSL-сертификата, в то время как verify-full также требует, чтобы cn (общее имя) в сертификате совпадало с именем пользователя или применимым отображением. Это поведение аналогично методу аутентификации cert (см. Раздел 19.12), но позволяет совместно использовать проверку клиентских сертификатов с любым методом аутентификации, поддерживающим записи hostssl .
На любой записи, использующей аутентификацию с клиентским сертификатом (т.е. использующей метод аутентификации cert или опцию clientcert ), вы можете указать, какую часть учетных данных клиентского сертификата сопоставить, используя опцию clientname . Эта опция может иметь одно из двух значений. Если вы указываете clientname=CN , что является значением по умолчанию, имя пользователя сопоставляется с Common Name (CN) сертификата. Если вместо этого вы указываете clientname=DN , имя пользователя сопоставляется со всем Distinguished Name (DN) сертификата. Эта опция, вероятно, лучше всего используется в сочетании с картой имен пользователей. Сравнение выполняется с DN в формате RFC 2253. Чтобы увидеть DN клиентского сертификата в этом формате, выполните
openssl x509 -in myclient.crt -noout --subject -nameopt RFC2253 | sed "s/^subject=//"
Необходимо быть осторожным при использовании этой опции, особенно при использовании регулярных выражений для сопоставления с DN .
Файлы, включенные с помощью конструкций @ , считываются как списки имен, которые могут быть разделены пробелами или запятыми. Комментарии вводятся с помощью символа # , так же, как в файле pg_hba.conf , и разрешены вложенные конструкции @ . Если имя файла, следующее за @ , не является абсолютным путем, оно считается относительным путем к каталогу, содержащему ссылочный файл.
Поскольку записи pg_hba.conf рассматриваются последовательно для каждой попытки подключения, порядок записей имеет значение. Обычно, более ранние записи будут иметь более строгие параметры соединения и слабые методы аутентификации, в то время как более поздние записи будут иметь более свободные параметры соединения и более сильные методы аутентификации. Например, можно захотеть использовать аутентификацию trust для локальных TCP/IP-соединений, но требовать пароль для удаленных TCP/IP-соединений. В этом случае запись, указывающая аутентификацию trust для соединений с 127.0.0.1, будет появляться перед записью, указывающей аутентификацию с паролем для более широкого диапазона разрешенных IP-адресов клиентов.
Файл pg_hba.conf считывается при запуске и когда основной процесс сервера получает сигнал SIGHUP signal. Если вы редактируете файл на активной системе, вам потребуется отправить сигнал постмастеру (используя pg_ctl reload , вызывая SQL-функцию pg_reload_conf() или используя kill -HUP ), чтобы он перечитал файл.
Примечание
Предыдущее утверждение не является верным в операционной системе Microsoft Windows: там любые изменения в файле pg_hba.conf немедленно применяются при последующих новых подключениях.
Системное представление pg_hba_file_rules может быть полезным для предварительного тестирования изменений в файле pg_hba.conf или для диагностики проблем, если загрузка файла не дала желаемого эффекта. Строки в представлении с ненулевыми полями error указывают на проблемы в соответствующих строках файла.
Подсказка
Для подключения к определенной базе данных пользователь должен пройти проверку файла pg_hba.conf и иметь привилегию CONNECT для этой базы данных. Если вы хотите ограничить, какие пользователи могут подключаться к каким базам данных, обычно проще контролировать это, предоставляя/отзывая привилегию CONNECT , чем указывать правила в записях файла pg_hba.conf .
Некоторые примеры записей pg_hba.conf показаны в Пример 19.1. См. следующий раздел для получения подробной информации о различных методах аутентификации.
Пример 19.1. Пример записей pg_hba.conf
# Allow any user on the local system to connect to any database with # any database user name using Unix-domain sockets (the default for local # connections). # # TYPE DATABASE USER ADDRESS METHOD local all all trust # The same using local loopback TCP/IP connections. # # TYPE DATABASE USER ADDRESS METHOD host all all 127.0.0.1/32 trust # The same as the previous line, but using a separate netmask column # # TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD host all all 127.0.0.1 255.255.255.255 trust # The same over IPv6. # # TYPE DATABASE USER ADDRESS METHOD host all all ::1/128 trust # The same using a host name (would typically cover both IPv4 and IPv6). # # TYPE DATABASE USER ADDRESS METHOD host all all localhost trust # Allow any user from any host with IP address 192.168.93.x to connect # to database "postgres" as the same user name that ident reports for # the connection (typically the operating system user name). # # TYPE DATABASE USER ADDRESS METHOD host postgres all 192.168.93.0/24 ident # Allow any user from host 192.168.12.10 to connect to database # "postgres" if the user's password is correctly supplied. # # TYPE DATABASE USER ADDRESS METHOD host postgres all 192.168.12.10/32 scram-sha-256 # Allow any user from hosts in the example.com domain to connect to # any database if the user's password is correctly supplied. # # Require SCRAM authentication for most users, but make an exception # for user 'mike', who uses an older client that doesn't support SCRAM # authentication. # # TYPE DATABASE USER ADDRESS METHOD host all mike .example.com md5 host all all .example.com scram-sha-256 # In the absence of preceding "host" lines, these three lines will # reject all connections from 192.168.54.1 (since that entry will be # matched first), but allow GSSAPI-encrypted connections from anywhere else # on the Internet. The zero mask causes no bits of the host IP address to # be considered, so it matches any host. Unencrypted GSSAPI connections # (which "fall through" to the third line since "hostgssenc" only matches # encrypted GSSAPI connections) are allowed, but only from 192.168.12.10. # # TYPE DATABASE USER ADDRESS METHOD host all all 192.168.54.1/32 reject hostgssenc all all 0.0.0.0/0 gss host all all 192.168.12.10/32 gss # Allow users from 192.168.x.x hosts to connect to any database, if # they pass the ident check. If, for example, ident says the user is # "bryanh" and he requests to connect as PostgreSQL user "guest1", the # connection is allowed if there is an entry in pg_ident.conf for map # "omicron" that says "bryanh" is allowed to connect as "guest1". # # TYPE DATABASE USER ADDRESS METHOD host all all 192.168.0.0/16 ident map=omicron # If these are the only three lines for local connections, they will # allow local users to connect only to their own databases (databases # with the same name as their database user name) except for administrators # and members of role "support", who can connect to all databases. The file # $PGDATA/admins contains a list of names of administrators. Passwords # are required in all cases. # # TYPE DATABASE USER ADDRESS METHOD local sameuser all md5 local all @admins md5 local all +support md5 # The last two lines above can be combined into a single line: local all @admins,+support md5 # The database column can also use lists and file names: local db1,db2,@demodbs all md5
| Назад | Наверх | Далее |
| Глава 19. Аутентификация клиента | Начало | 19.2. Сопоставление имен пользователей |