Установка и базовая настройка PostgreSQL. Подключение к серверу
25.03.2019
Связка сервера 1С:Предприятие и PostgreSQL вторая по популярности среди установок 1С и самое используемое решение на платформе Linux. В отличии внедрений на базе Windows и MSSQL, где трудно сделать так, чтобы не заработало, внедрения на базе Linux таят множество подводных камней для неопытного администратора. Часто бывает так, что вроде бы все сделано правильно, но ошибка следует за ошибкой. Сегодня мы рассмотрим самые типовые из них.
Общая информация
Перед тем, как начинать искать ошибки установки и, вообще, приступать к внедрению серверной версии 1С:Предприятия было бы неплохо освежить представление как это работает:
Сервер 1С Предприятия. Часть 1 - Общие вопросы.
В небольших внедрениях сервер 1С и сервер СУБД обычно совмещают на одном физическом сервере, что немного сужает круг возможных ошибок. В нашем случае будет рассматриваться ситуация, когда сервера разнесены по разным машинам. В нашей тестовой лаборатории мы развернули следующую схему:
В нашем распоряжении имеются два сервера под управлением Ubuntu 12.04 x64, на одном из них установлен сервер 1С:Предприятие версии 8.3, на другом PostgreSQL 9.04 от Ethersoft, а также клиент под управлением Windows. Напоминаем, что клиент работает только с сервером 1С, который, в свою очередь, формирует необходимые запросы к серверу СУДБ. Никаких запросов от клиента к серверу управления базами данных не происходит.
Сервер баз данных не обнаруженВАЖНО: пользователь "postgres" не прошёл проверку подлинности (Ident)
Данная ошибка возникает при разнесении серверов по разным ПК из-за неправильно настроеной проверки подлинности в локальной сети. Для устранения откройте /var/lib/pgsql/data/pg_hba.conf, найдите строку:
Host all all 192.168.31.0/24 ident
и приведите ее к виду:
Host all all 192.168.31.0/24 md5
где 192.168.31.0/24 - диапазон вашей локальной сети. Если такой строки нет, ее следует создать в секции IPv4 local connections.
Сервер баз данных не обнаруженcould not translate host name "NAME" to address: Temporary failure in name resolution
На первый взгляд ошибка понятна: клиент не может разрешить имя сервера СУБД, типичная ошибка для небольших сетей, где отсутствует локальный DNS-сервер. В качестве решения добавляют запись в файлhosts на клиенте, что не дает никакого результата...
А теперь вспоминаем, о чем было сказано несколько раньше. Клиентом сервера СУБД является сервер 1С, но никак не клиентский ПК, следовательно запись нужно добавлять на сервере 1С:Предприятие в файл/etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows.
Аналогичная ошибка будет возникать, если вы забыли добавить запись типа A для сервера СУБД на локальном DNS-сервере.
Ошибка при выполнении операции с информационной базойserver_addr=NAME descr=11001(0x00002AF9): Этот хост неизвестен.
Как и прошлая, эта ошибка связана с неправильным разрешением клиентом имени сервера. На этот раз именно клиентским ПК. В качестве решения добавляем в файл /etc/hosts на платформе Linux или в C:\Windows\System32\drivers\etc\hosts на платформе Windows запись вида:
192.168.31.83SRV-1C-1204
где указываете адрес и имя вашего сервера 1С:Предприятия. В случае использования локального DNS следует добавить A-запись для сервера 1С.
Ошибка СУБД: DATABASE не пригоден для использования
Гораздо более серьезная ошибка, которая говорит о том, что вы установили несовместимую с 1С:Предприятие версию PostgreSQL или допустили грубые ошибки при установке, например не установили все необходимые зависимости, в частности библиотеку libICU.
Если вы имеете достаточный опыт администрирования Linux систем, то можете попробовать доустановить необходимые библиотеки и заново инициализировать кластер СУБД. В противном случае PostgreSQL лучше переустановить, не забыв удалить содержимое папки /var/lib/pgsql.
Также данная ошибка может возникать при использовании сборок 9.1.x и 9.2.x Postgre@Etersoft, подробности смотрите ниже.
Ошибка СУБД: ERROR: could not load library "/usr/lib/x86_64-linux-gnu/postgresql/fasttrun.so"
Довольно специфичная ошибка, характерная для сборок 9.1.x и 9.2.x Postgre@Etersoft, также может приводить предыдущей ошибке. Причина кроется в неисправленной ошибке в библиотеке fasttrun.so. Решение - откатиться на сборку 9.0.x Postgre@Etersoft.
Ошибка СУБДERROR: type "mvarchar" does not exist at character 31
Возникает если база данных была создана без помощи системы 1С:Предприятия. Помните, для работы с 1С базы данных следует создавать только с использованием инструментов платформы 1С: через консоль Администрирование серверов 1С Предприятия
или через средство запуска 1С.
Сервер баз данных не обнаруженВАЖНО: пользователь "postgres" не прошёл проверку подлинности (по паролю)
Очень простая ошибка. Неправильно указан пароль суперпользователя СУБД postgres. Вариантов решения два: вспомнить пароль или изменить его. Во втором случае вам нужно будет изменить пароль в свойствах всех существующих информационных баз через оснастку Администрирование серверов 1С Предприятия.
Сервер баз данных не обнаруженFATAL: database "NAME" does not exist
Еще одна очень простая ошибка. Смысл ее сводится к тому, что указанная БД не существует. Чаще всего возникает из-за ошибки в указании имени базы. Следует помнить, что информационная база 1С в кластере и база данных СУБД - две разные сущности и могут иметь различные имена. Также следует помнить, что Linux системы чувствительны к регистру и для них unf83 и UNF83 два разных имени.
Вопрос: как заставить postgres принимать подключения по сети
здравствуйте. у меня тут проблема: постгресс работает на сервера, я обычно по сети не конекчусь, но сегодня понадобилось кое-что сделать, потом опять отрубить.. как настроить чтобы принимал подключения?
в /etc/postgresql/9.4/main/postgresql.conf написанно listen_addresses = "*"
# what IP address
(es)
to
listen on
;
# comma-
separated list of
addresses;
# defaults to
"localhost"
;
use
"*"
for
all
# (change requires restart
)
port = 5433 # (change requires restart
)
max_connections = 100 # (change requires restart
)
когда делаю psql --dbname=postresql://ip:5433 fleonis_t
psql: ВАЖНО: пользователь "fleonis_t" не прошёл проверку подлинности (Peer)
что не так?
Ответ:
alexy_black,
стало быть закрыто. и это, скорее всего, правильно.
Теперь идем на ту машинку, где крутится сайт (по ssh) и проверяем всё то же с неё. -- вот если и с неё не пускают -- напрягаем одмина.
Вопрос: почему local postgres должен всегда быть peer ?
всем приветы хочу всё-таки разобраться... у меня одна-единственная запись: local all postgres md5 но с такой записью СЕРВЕР НЕ ЗАПУСКАЕТСЯ
вот так он спамит в логах.
пароль выставил в системе: passwd postgres (123) и внутри: ALTER USER postgres PASSWORD "123"; (также пробовал ENCRYPTED PASSWORD и md5 менял на password) ну казалось бы - возьми ты пароль из системы и юзай, но нет! чего ему надо? почему я должен держать там обязательно peer или trust ? пусть для сокета, а что если злоумышленник получил доступ к консоли, а команда "sudo -u postgres psql" - даёт полный доступ ко всем БД так должно быть?
Ответ:
ну вот это 9.6 из Debian 9.1 не знаю, что они могли там изменить (у вас же старее версия?) по идее каждое "Пароль не подходит для пользователя "postgres"." - означает попытку какого-то действия, которое обламывается но они и у вас есть. ладно, йух с ним, peer так peer
Вопрос: Как узнать пароль postgres
я установил postgresql на ubuntu из консоли. Никто меня про пароли не спрашивал. После этого под супер пользователем я захожу с sudo, то есть sudo -u postgres psql при этом ввожу пароль от пользователя в никс (совсем не постгрес). Я хочу открыть доступ к базе постгрепс извне (с других компов в интернете). По инструкции мне надо создать второго супер юзера # Переключаемся в системного пользователя postgres
su postgres
# Создаем нового суперпользователя
createuser -P -s postgreadmin
# вводим пароль по запросу
Проблема в том, что я не знаю пароля от postgres. Как его узнать? Также по этой инструкции предлагают в pg_hba.conf сделать следующие изменения: hostssl all postgreadmin 0.0.0.0/0 md5 Мне бы хотелось как минимум использовать другого пользователя (реального владельца базы), а лучше всего создать отдельного пользователя test_mir, который в базе данных test_baza будет иметь доступ только на чтение таблицы test_tablica. Такое возможно или надо давать доступ только супер пользователю?
Ответ:
В pg_hba.conf делаете метод доступа trust для postgres. При необходимости перезапустите демон. Подключаетесь к БД от имени postgres уже без пароля. Меняете пароль в БД. Отключаетесь от БД. В pg_hba.conf меняете на метод доступа md5.
SQL> create
public
database
link PG_LINK connect
to
"postgres" identified by
"postgres" using "PG_LINK"
;
SQL> select
*
from
dual@PG_LINK;
select
*
from
dual@PG_LINK
*
ERROR at
line 1:
ORA-
28546: connection
initialization failed,
probable Net8 admin error
ORA-
02063: preceding line from
PG_LINK
Ответ:
SQL> select
*
from
pg_tables@PG_LINK;
select
*
from
pg_tables@PG_LINK
*
ERROR at
line 1:
ORA-
28500: connection
from
ORACLE to
a non-
Oracle system
returned this message:
ОШИБКА: отношение "PG_TABLES" не существует;
No
query has been executed with
that handle {
42P01,
NativeErr = 1}
ORA-
02063: preceding 3 lines from
PG_LINK
А вот скажите, нет ли там файла типа phsql.ini где нужно открыть - кто-куда может ходить? ощущение что в postgres прав не хватает
Вопрос: Переход на Postgres (Postgres vs ANSI)
Всем привет в этом чате!
Задумался о переходе на Postgres. В связи с этим прошу разъяснений по некоторым пунктам (без некоторых не проживу), а именно:
a) platforms OSX, IOS, Android b) portable/embedded version c) universal triggers with inserting/updating/deleting keywords d) triggers on connect/disconnect e) gtt f) cte g) computed columns h) insert returning clause i) command line interface j) table-level constraint name as create
table
(constraint primary key/foreign key/unique
/check
);
k) utf-8 support l) 2-phase locking m) sql editor with sintax
Ответ:
Ролг Хупин,
Firebird - первая любовь. Postgres - возможно, будет брак по расчету.)))
Вопрос: Получить через Postgres файлы хранящиеся на диске
Всем привет. Есть такая простая задача: вернуть пользователю в браузер файл для загрузки, но проблема в том, что файлы хранятся на сервере с БД в каталоге и имеют название id из БД (без расширения и исходного названия), исходное название и расширение хранится в бд в отдельной таблице. Эти файлы в данный каталог загружаются из другого приложения через postgres, а мне надо получать их в своем приложении как минимум с расширением файлов. Вот и решил попробовать достать эти файлы через lo_import, а затем просто возвращать из запроса в приложение на сервере, а дальше уже возвращать клиенту, но вот проблема: lo_import загружает файл в бд, возвращает oid, как теперь получить эти данные? по факту после загрузки они попали в pg_largeobject, но вот собрать их так, чтобы файл открылся (после объединения всех частей и добавления нужного расширения) как надо не получается.
собирать пробовал так SELECT array_to_string(array(select data from pg_largeobject where loid = 135422 order by pageno),"");
Ответ:
Вариант 2 Написать свою хранимую процедуру на языке, ну например Perl установив предварительно расширение PlPerlU, которое позволяет забирать данные из любого каталога на диске где установлен PG.
Пример функции которая забирает требуемый файл: -- Function: read_file_as_hex(text)
DROP FUNCTION read_file_as_hex(text);
CREATE OR REPLACE FUNCTION read_file_as_hex(name text) RETURNS text AS $BODY$ my $s = ""; my $buff = ""; my $read_buff = ""; my $file_name = $_; my $name_size = length($file_name); $file_name = pack("H$name_size", $file_name); unless (open(READING_FILE, $file_name)) { return ($buff); } else { binmode(READING_FILE); my $file_size = -s($file_name); read(READING_FILE, $read_buff, $file_size); close(READING_FILE); $s = 2*$file_size; $buff = unpack("H$s", $read_buff); return ($buff); }
$BODY$ LANGUAGE plperlu VOLATILE COST 100; ALTER FUNCTION read_file_as_hex(text) OWNER TO postgres;
Файл передается как HEX последовательность, в Browser(е) на Java собрать как должно быть.
Вопрос: Ошибка СУБД, SQL Server не принимает подключений, помогает только перезапуск SQL сервера.
Server 2008R2 + SQL 2012 + Сервер 1С Помогите советом, с MSSQL не очень много приходилось общаться. Суть вот в чем: пользователи 1С разом повисают, Ошибка СУБД, перезайти не могут. Перезапускаю службы SQL Server и SQL Agent - заходят. В журнале приложений:
Сведения 21.03.2016 10:03:58 MSSQL$MSSQL2012 17052 Сервер Не удается найти описание для идентификатора события 17052 из источника MSSQL$MSSQL2012. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере. Если событие возникло на другом компьютере, возможно, потребуется сохранить отображаемые сведения вместе с событием. К событию были добавлены следующие сведения: Монитор SQLServerAgent: SQLServerAgent был закрыт. ресурс сообщения существует, но сообщение не найдено в таблице строк и таблице сообщений
Сведения 21.03.2016 10:04:04 MSSQL$MSSQL2012 17144 Сервер SQL Server не разрешает новые соединения, поскольку диспетчер управления службами запросил паузу. Для возобновления работы службы используйте диспетчер вычислительных ресурсов SQL или приложение "Службы" на панели управления.
Ошибка 21.03.2016 10:04:09 MSSQL$MSSQL2012 17120 Сервер SQL Server не удалось создать поток incrementsignal. Просмотрите журнал ошибок SQL Server и журналы событий Windows и попытайтесь найти сведения о похожих проблемах.
Сведения 21.03.2016 10:04:09 MSSQL$MSSQL2012 19032 Сервер Трассировка SQL остановлена вследствие завершения работы сервера. Идентификатор трассировки = "1". Это информационное сообщение; вмешательство пользователя не требуется.
На сколько я понимаю, сервер кладет ошибка 17120, а что она значит толковых описаний найти не могу, ровно как и причину ее возникновения. Лог SQL во вложении. Пытался сам вчитаться, но мало что понял. Взываю к мудрости гуру!
К сообщению приложен файл (журналы.rar
- 17Kb)
Ответ:
invm,
Самое первое событие по этому отрезку времени - это запись в журнале агента: 03/21/2016 10:03:51,Сведения, Остановка службы SQLAgent$MSSQL2012 по запросу на остановку полученному от пользователя процесса или ОС... И дальше по таймлайну происходят все остальные события. И вот как отследить-то, кто этот запрос отправляет? В планировщике никаких задач на этот период не стоит. Бэкапы все ночью делаются. В журналах нет повторяющихся событий, предшествующих крашам. Тем более, краши происходят в разное время и не каждый день. Последний раз было 15.03.16.
Вопрос: Как вызывать процедуру Postgres с OUT-параметрами
Добрый день!
Для одного проекта у нас выбрали Postgres. С непривычки у меня не получается реализовать простейшую, казалось бы, вещь.
Если на SQL Server я создавал, процедуры с OUT-параметрами и вызывал их из внешней программы таким образом (2 OUT-параметра и 2 обычных) EXEC
процедура ?
@m.
par1,
?
@m.
par2,
?
m.
par3,
?
m.
par4
при этом мои переменные m.par1 и m.par2 после выполнения процедуры принимали значения соответствующих параметров, то Postgres, по моим наблюдениям, вообще не требует передачи в процедуру OUT-параметров. То есть, в моём случае в процедуру, вроде, надо передавать два параметра. Да и в DBeaver она отображается не с четырьмя, а с двумя параметрами (OUT-параметры игнорируются) Подскажите, пожалуйста, как, создать и вызвать из программы, для примера, простейшую процедуру получения нового уникального кода с использованием OUT-параметра типа SQL SERVERовской
CREATE
PROCEDURE
dbo.
new_id
@nRetVal int
OUTPUT
AS
BEGIN
UPDATE
id_counter SET
@nRetVal = id_counter.
id
,
id_counter.
id
= id_counter.
id
+
1
Надо использовать команду EXECUTE процедура или конструкцию select <моя переменная> from процедура(параметр)?
Необходимо, чтобы я из своей программы передал переменную нужного типа, но с произвольным именем, в процедуру Postgres, и после выполнения этой процедуры переменная приняла бы значение, которое присвоилось в процедуре соответствующему параметру.
37.4.1. Аргументы SQL-функций
37.4.4. Функции SQL с выходными параметрами
4.3.1. Позиционная передача
4.3.2. Именная передача
4.3.3. Смешанная передача
VARCHAR
(255))
as
NAME
FROM
"SC_Wonder".
t_page T1 WHERE
T1.
p_parent IS
NULL
union
select
T2.
p_id,
T2.
p_parent,
T2.
p_title,
CAST
( temp1.
PATH ||
"->"
||
T2.
p_id AS
VARCHAR
(50))
,
LEVEL
+
1 ,
CAST
( " "
||
temp1.
NAME
AS
VARCHAR
(255))
FROM
"SC_Wonder".
t_page T2 INNER
JOIN
temp1 ON
( temp1.
p_id= T2.
p_parent))
select
*
from
temp1 ORDER
BY
PATH LIMIT 100
он выдает в поле NAME _10 ___10 и прочее. причем 1 - это имя первой записи. как победить и заставить выводить имя текущей записи
Ответ:
то что нужно. спасибо. правда я сделал так CAST
( lpad
(""
,
(LEVEL
+
1)*
3,
" "
)
||
T2.
p_title AS
VARCHAR
(255))
Вопрос: Помогите с настройкой Oracle - Postgres DBLINK
Здравствуйте. Мне нужно подключиться из oracle в postgres. На данный момент oracle и postgres крутятся на моем локальном компьютере.
Я установил, как написано файл caths.sql
Затем вписал в nsnames.ora WMS= (DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)
(HOST=localhost)
(PORT=5432
))
(CONNECT_DATA = (SERVICE_NAME=map))
(HS = OK))
И создал DBLINK CREATE
DATABASE
LINK MAP USING "WMS"
При запросе Select
name from
cities@MAP
Получаю ошибку ERROR at
line 1
:
ORA-28545
: error diagnosed by
Net8 when
connecting to
an agent
Unable to
retrieve text of
NETWORK
/NCR message 65535
ORA-02063
: preceding 2
lines from
MAP
Что я не правильно сделал и как настроить подключение?
Следующие подразделы содержат более детальную информацию о методах аутентификации.
19.3.1. Аутентификация trust
Когда указан способ аутентификации trust , Postgres Pro
предполагает, что любой подключающийся к серверу авторизован для доступа к базе данных вне зависимости от указанного имени пользователя базы данных (даже если это имя суперпользователя). Конечно, ограничения, прописанные в столбцах база и пользователь, продолжают работать. Этот метод должен применяться только в том случае, когда на уровне операционной системы обеспечена адекватная защита от подключений к серверу.
Аутентификация trust очень удобна для локальных подключений на однопользовательской рабочей станции. Но сам по себе этот метод обычно не
подходит для машин с несколькими пользователями. Однако вы можете использовать trust даже на многопользовательской машине, если ограничите доступ к файлу Unix-сокета сервера на уровне файловой системы. Для этого установите конфигурационные параметры unix_socket_permissions (и, возможно, unix_socket_group) как описано в Разделе 18.3 . Либо вы можете установить конфигурационный параметр unix_socket_directories , чтобы разместить файл сокета в должным образом защищённом каталоге.
Установка разрешений на уровне файловой системы помогает только в случае подключений через Unix-сокеты. На локальные подключения по TCP/IP ограничения файловой системы не влияют. Поэтому, если вы хотите использовать разрешения файловой системы для обеспечения локальной безопасности, уберите строку host ... 127.0.0.1 ... из pg_hba.conf или смените метод аутентификации.
Метод аутентификации trust для подключений по TCP/IP допустим только в случае, если вы доверяете каждому пользователю компьютера, получившему разрешение на подключение к серверу строками файла pg_hba.conf , указывающими метод trust . Не стоит использовать trust для любых подключений по TCP/IP, отличных от localhost
(127.0.0.1).
19.3.2. Аутентификация password
Методы аутентификации с помощью пароля - md5 и password . Эти методы действуют похожим образом; отличие состоит только в том, как передаётся пароль по каналу связи, а именно: в виде хеша MD5, или открытым текстом, соответственно.
Если вас беспокоит возможность перехвата трафика, предпочтительнее использовать метод md5 . Простого метода password следует избегать всегда, если возможно. Однако, md5 не может быть использован с параметром db_user_namespace . Если подключение зашифровано по SSL, тогда password тоже может быть использован без опасений (хотя аутентификация через SSL сертификат будет наилучшим выбором для тех, кто зависит от использования SSL).
База данных паролей Postgres Pro
отделена от паролей пользователей операционной системы. Пароль для каждого пользователя базы данных хранится в системном каталоге pg_authid . Работать с паролями можно через команды SQL CREATE USER
и ALTER ROLE
, например, CREATE USER foo WITH PASSWORD "secret"
. Если для пользователя не было установлено пароля, пароль сохраняется как null, и аутентификация через пароль для данного пользователя будет невозможна.
19.3.3. Аутентификация GSSAPI
GSSAPI
является протоколом отраслевого стандарта для безопасной авторизации, определённым в RFC 2743. Postgres Pro
поддерживает GSSAPI
с Kerberos
аутентификацией с соответствии с RFC 1964. GSSAPI
обеспечивает автоматическую аутентификацию (single sign-on), для систем, которые её поддерживают. Сама по себе аутентификация безопасна, но данные, отсылаемые в ходе подключения к базе данных, не защищены, если не используется SSL .
Поддержка GSSAPI должна быть включена при сборке Postgres Pro Standard
.
При работе с Kerberos
GSSAPI
использует стандартные учётные записи в формате servicename
/ hostname
@ realm
. Сервер Postgres Pro примет любого принципала, включённого в используемый сервером файл таблицы ключей, но необходимо проявить осторожность в указании корректных деталей принципала в ходе соединения с клиентом, применяющим параметр подключения krbsrvname . (См. также Подраздел 31.1.2 .) Значение имени сервиса по умолчанию postgres может быть изменено во время сборки с помощью./configure --with-krb-srvnam= whatever
. В большинстве сред изменять данный параметр не требуется. Однако некоторые реализации Kerberos могут потребовать иного имени сервиса, например, Microsoft Active Directory требует, чтобы имя сервиса было набрано заглавными буквами (POSTGRES).
hostname
здесь - это полное доменное имя компьютера, где работает сервер. Областью субъекта-службы является предпочитаемая область данного компьютера.
Принципалы клиентов могут быть сопоставлены с различными именами пользователей баз данных Postgres Pro
в pg_ident.conf . Например, принципалу pgusername@realm может быть сопоставлено просто pgusername . Так же возможно использовать в качестве имени роли в Postgres Pro
полное имя принципала username@realm без какого-либо сопоставления.
Postgres Pro
также поддерживает возможность убирать область из имени принципала. Эта возможность оставлена для обратной совместимости и использовать её крайне нежелательно, так как при этом оказывается невозможно различить разных пользователей, имеющих одинаковые имена, но приходящих из разных областей. Чтобы включить её, установите для include_realm значение 0. В простых конфигурациях с одной областью исключение области в сочетании с параметром krb_realm (который позволяет ограничить область пользователя одним значением, заданным в krb_realm parameter) будет безопасным, но менее гибким вариантом по сравнению с явным описанием сопоставлений в pg_ident.conf .
Убедитесь, что файл ключей вашего сервера доступен для чтения (и желательно недоступен для записи) учётной записи сервера Postgres Pro
. (См. также Раздел 17.1 .) Расположение этого файла ключей указывается параметром krb_server_keyfile . По умолчанию это /usr/local/pgsql/etc/krb5.keytab (каталог может быть другим, в зависимости от значения sysconfdir при сборке). Из соображений безопасности рекомендуется использовать отдельный файл keytab для сервера Postgres Pro
, а не открывать доступ к общесистемному файлу.
Файл таблицы ключей генерируется программным обеспечением Kerberos; подробнее это описано в документации Kerberos. Следующий пример для MIT-совместимых реализаций Kerberos 5:
При подключении к базе данных убедитесь, что у вас есть разрешение на сопоставление принципала с именем пользователя базы данных. Например, для имени пользователя базы данных fred , принципал [email protected] сможет подключиться. Чтобы дать разрешение на подключение принципалу fred/[email protected] , используйте файл сопоставления имён пользователей, как описано в Разделе 19.2 .
Для метода GSSAPI
доступны следующие параметры конфигурации:
Include_realm
Раздел 19.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm . Более предпочтительный вариант - оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей Postgres Pro
. map
Разрешает сопоставление имён пользователей системы и пользователей баз данных. За подробностями обратитесь к Разделу 19.2 . Для принципала GSSAPI/Kerberos, такого как [email protected] (или более редкого username/[email protected]), именем пользователя в сопоставлении будет [email protected] (или username/[email protected] , соответственно), если include_realm не равно 0; в противном случае именем системного пользователя в сопоставлении будет username (или username/hostbased). krb_realm
19.3.4. Аутентификация SSPI
SSPI
- технология Windows
для защищённой аутентификации с единственным входом. Postgres Pro
использует SSPI в режиме negotiate , который применяет Kerberos
, когда это возможно, и автоматически возвращается к NTLM
в других случаях. Аутентификация SSPI
работает только, когда и сервер, и клиент работают на платформе Windows
, или, на не-Windows платформах, если доступен GSSAPI
.
Для SSPI
доступны следующие параметры конфигурации:
Include_realm
Когда этот параметр равен 0, из принципала аутентифицированного пользователя убирается область, и оставшееся имя проходит сопоставление имён (см. Раздел 19.2). Этот вариант не рекомендуется и поддерживается в основном для обратной совместимости, так как он небезопасен в окружениях с несколькими областями, если только дополнительно не задаётся krb_realm . Более предпочтительный вариант - оставить значение include_realm по умолчанию (1) и задать в pg_ident.conf явное сопоставление для преобразования имён принципалов в имена пользователей Postgres Pro
. compat_realm
Если равен 1, для параметра include_realm применяется имя домена, совместимое с SAM (также известное как имя NetBIOS). Это вариант по умолчанию. Если он равен 0, для имени принципала Kerberos применяется действительное имя области.
Этот параметр можно отключить, только если ваш сервер работает под именем доменного пользователя (в том числе, виртуального пользователя службы на компьютере, включённом в домен) и все клиенты, проходящие проверку подлинности через SSPI, также используют доменные учётные записи; в противном случае аутентификация не будет выполнена. upn_username
Если этот параметр включён вместе с compat_realm , для аутентификации применяется имя Kerberos UPN. Если он отключён (по умолчанию), применяется SAM-совместимое имя пользователя. По умолчанию у новых учётных записей эти два имени совпадают.
Заметьте, что libpq
использует имя, совместимое с SAM, если имя не задано явно. Если вы применяете libpq
или драйвер на его базе, этот параметр следует оставить отключённым, либо явно задавать имя пользователя в строке подключения. map
Позволяет сопоставить пользователей системы с пользователями баз данных. За подробностями обратитесь к Разделу 19.2 . Для принципала SSPI/Kerberos, такого как [email protected] (или более редкого username/[email protected]), именем пользователя в сопоставлении будет [email protected] (или username/[email protected] , соответственно), если include_realm не равно 0; в противном случае именем системного пользователя в сопоставлении будет username (или username/hostbased). krb_realm
Устанавливает область, с которой будут сверяться имена принципалов пользователей. Если этот параметр задан, подключаться смогут только пользователи из этой области. Если не задан, подключаться смогут пользователи из любой области, в зависимости от установленного сопоставления имён пользователей.
19.3.5. Аутентификация Ident
Метод аутентификации ident работает, получая имя пользователя операционной системы клиента от сервера Ident и используя его в качестве разрешённого имени пользователя базы данных (с возможным сопоставлением имён пользователя). Способ доступен только для подключений по TCP/IP.
Примечание
Когда для локального подключения (не TCP/IP) указан ident, вместо него используется метод аутентификации peer (см. Подраздел 19.3.6).
Для метода ident
доступны следующие параметры конфигурации:
Map
Разделу 19.2 .
Протокол «Identification
»
(Ident) описан в RFC 1413. Практически каждая Unix-подобная операционная система поставляется с сервером Ident, по умолчанию слушающим TCP-порт 113. Базовая функция этого сервера - отвечать на вопросы, вроде «Какой пользователь инициировал подключение, которое идет через твой порт X
и подключается к моему порту Y
?
»
. Поскольку после установления физического подключения Postgres Pro
знает и X
, и Y
, он может опрашивать сервер Ident на компьютере клиента и теоретически может определять пользователя операционной системы при каждом подключении.
Недостатком этой процедуры является то, что она зависит от интеграции с клиентом: если клиентская машина не вызывает доверия или скомпрометирована, злоумышленник может запустить любую программу на порту 113 и вернуть любое имя пользователя на свой выбор. Поэтому этот метод аутентификации подходит только для закрытых сетей, где каждая клиентская машина находится под жёстким контролем и где администраторы операционных систем и баз данных работают в тесном контакте. Другими словами, вы должны доверять машине, на которой работает сервер Ident. Помните предупреждение:
У некоторых серверов Ident есть нестандартная возможность, позволяющая зашифровать возвращаемое имя пользователя, используя ключ, который известен только администратору исходного компьютера. Эту возможность нельзя
использовать с Postgres Pro
, поскольку Postgres Pro
не сможет расшифровать возвращаемую строку и получить фактическое имя пользователя.
19.3.6. Аутентификация peer
Метод аутентификации peer работает, получая имя пользователя операционной системы клиента из ядра и используя его в качестве разрешённого имени пользователя базы данных (с возможностью сопоставления имён пользователя). Этот метод поддерживается только для локальных подключений.
Для метода peer
доступны следующие параметры конфигурации:
Map
Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 19.2 .
Аутентификация peer доступна только на операционных системах, поддерживающих функцию getpeereid() , параметр сокета SO_PEERCRED или сходные механизмы. В настоящее время это Linux
, большая часть разновидностей BSD
, включая OS X
, и Solaris
.
19.3.7. Аутентификация LDAP
Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует LDAP как метод подтверждения пароля. LDAP используется только для подтверждения пары "имя пользователя/пароль". Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован LDAP.
Аутентификация LDAP может работать в двух режимах. Первый режим называется простое связывание. В ходе аутентификации сервер связывается с характерным именем, составленным следующим образом: prefix
username
suffix
. Обычно, параметр prefix
используется для указания cn= или DOMAIN
\ в среде Active Directory. suffix
используется для указания оставшейся части DN или в среде, отличной от Active Directory.
Во втором режиме, который мы называем поиск+связывание, сервер сначала связывается с каталогом LDAP с предопределённым именем пользователя и паролем, указанным в ldapbinddn
и ldapbindpasswd
, и выполняет поиск пользователя, пытающегося подключиться к базе данных. Если имя пользователя и пароль не определены, сервер пытается связаться с каталогом анонимно. Поиск выполняется в поддереве ldapbasedn
, при этом проверятся точное соответствие имени пользователя атрибуту ldapsearchattribute
. Как только при поиске находится пользователь, сервер отключается и заново связывается с каталогом уже как этот пользователь, с паролем, переданным клиентом, чтобы удостовериться, что учётная запись корректна. Этот же режим используется в схемах LDAP-аутентификации в другом программном обеспечении, например, в pam_ldap и mod_authnz_ldap в Apache. Данный вариант даёт больше гибкости в выборе расположения объектов пользователей, но при этом требует дважды подключаться к серверу LDAP.
Следующие параметры конфигурации доступны при аутентификации в обоих режимах:
Ldapserver
Имена и IP-адреса LDAP-серверов для связи. Можно указать несколько серверов, разделяя их пробелами. ldapport
Номер порта для связи с LDAP-сервером. Если порт не указан, используется установленный по умолчанию порт библиотеки LDAP. ldaptls
Равен 1 для установки соединения между Postgres Pro и LDAP-сервером с использованием TLS-шифрования. Имейте в виду, что так шифруется только обмен данными с LDAP-сервером, а клиентское подключение остаётся незашифрованным, если только не применяется SSL.
Следующие параметры конфигурации доступны только при аутентификации в режиме простого связывания:
Ldapprefix
Эта строка подставляется перед именем пользователя во время формирования DN для связывания при аутентификации в режиме простого связывания. ldapsuffix
Эта строка размещается после имени пользователя во время формирования DN для связывания, при аутентификации в режиме простого связывания.
Следующие параметры конфигурации доступны только при аутентификации поиск+связывание:
Ldapbasedn
Корневая папка DN для начала поиска пользователя при аутентификации в режиме поиск+связывание. ldapbinddn
DN пользователя для связи с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание. ldapbindpasswd
Пароль пользователя для связывания с каталогом при выполнении поиска в ходе аутентификации в режиме поиск+связывание. ldapsearchattribute
Атрибут для соотнесения с именем пользователя в ходе аутентификации поиск+связывание. Если атрибут не указан, будет использован атрибут uid . ldapurl
Адрес RFC 4516 LDAP. Это альтернативный путь для написания некоторых функций LDAP в более компактной и стандартной форме. Формат записи таков:
scope
должен быть представлен или base , или one , или sub , обычно последним. Используется один атрибут, некоторые компоненты стандартных LDAP-адресов, такие, как фильтры и расширения, не поддерживаются.
Для неанонимного связывания ldapbinddn и ldapbindpasswd должны быть указаны как раздельные параметры.
Для применения зашифрованных LDAP-подключений, в дополнение к параметру ldapurl необходимо использовать параметр ldaptls . URL-схема ldaps (прямое SSL-подключение) не поддерживается.
В настоящее время URL-адреса LDAP поддерживаются только с OpenLDAP, не в Windows.
Нельзя путать параметры конфигурации для режима простого связывания с параметрами для режима поиск+связывание, это ошибка.
Это пример конфигурации LDAP для простого связывания:
Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser , Postgres Pro пытается связаться с LDAP-сервером, используя DN cn=someuser, dc=example, dc=net и пароль, предоставленный клиентом. Если это подключение удалось, то доступ к базе данных будет открыт.
Когда запрашивается подключение к серверу базы данных в качестве пользователя базы данных someuser , Postgres Pro пытается связаться с сервером LDAP анонимно (поскольку ldapbinddn не был указан), выполняет поиск для (uid=someuser) под указанной базой DN. Если запись найдена, проводится попытка связывание с использованием найденной информации и паролем, предоставленным клиентом. Если вторая попытка подключения проходит успешно, предоставляется доступ к базе данных.
Пример той же конфигурации для режима поиск+связывание, но записанной в виде URL:
Такой URL-формат используется и другим программным обеспечением, поддерживающим аутентификацию по протоколу LDAP, поэтому распространять такую конфигурацию будет легче.
Подсказка
Поскольку LDAP часто применяет запятые и пробелы для разделения различных частей DN, необходимо использовать кавычки при определении значения параметров, как показано в наших примерах.
19.3.8. Аутентификация RADIUS
Данный метод аутентификации работает сходным с методом password образом, за исключением того, что он использует RADIUS как метод проверки пароля. RADIUS используется только для подтверждения пары имя пользователя/пароль. Поэтому пользователь должен уже существовать в базе данных до того, как для аутентификации будет использован RADIUS.
В ходе аутентификации RADIUS настроенному RADIUS-серверу посылается запрос доступа. Это сообщение типа Только Аутентификация, которое включает в себя параметры имя пользователя, пароль (зашифрованный) и идентификатор NAS . Запрос зашифровывается с использованием общего с сервером секрета. RADIUS-сервер отвечает на запрос сервера либо Доступ принят, либо Доступ отклонён. Система ведения учёта RADIUS не поддерживается.
Для метода RADIUS доступны следующие параметры конфигурации:
Radiusserver
Имя или IP-адрес сервера RADIUS, с которым будет проходить соединение. Это обязательный параметр. radiussecret
Общий секрет, используемый при контактах с сервером RADIUS. Он должен иметь одинаковое значение на серверах Postgres Pro и RADIUS. Рекомендуется использовать строку как минимум из 16 символов. Это обязательный параметр.
Примечание
Шифровальный вектор будет достаточно эффективен только в том случае, если Postgres Pro
собран с поддержкой OpenSSL
. В противном случае, передача данных серверу RADIUS будет лишь замаскированной, но не защищённой, поэтому необходимо принять дополнительные меры безопасности.
radiusport
Номер порта для связи с сервером RADIUS. Если порт не указан, по умолчанию используется порт 1812 . radiusidentifier
Строка, используемая в запросах сервера RADIUS как Идентификатор NAS . Этот параметр может использоваться как второй параметр, выявляющий, например, какой пользователь пытается подключиться под каким пользователем базы данных, что может быть использовано для формирования соответствий на сервере RADIUS. Если не указан идентификатор, по умолчанию используется postgresql .
19.3.9. Аутентификация по сертификату
Для аутентификации в рамках этого метода используется клиентский сертификат SSL, поэтому данный способ применим только для SSL-подключений. Когда используется этот метод, сервер потребует от клиента предъявления действительного и доверенного сертификата. Пароль у клиента не запрашивается. Атрибут cn (Обычное имя) сертификата сравнивается с запрашиваемым именем пользователя базы данных, и если они соответствуют, вход разрешается. Если cn отличается от имени пользователя базы данных, то может быть использовано сопоставление имён пользователей.
Для аутентификации по SSL сертификату доступны следующие параметры конфигурации:
Map
Позволяет сопоставить имена пользователей системы и базы данных. За подробностями обратитесь к Разделу 19.2 .
В записи pg_hba.conf , описывающей аутентификацию по сертификату, параметр clientcert предполагается равным 1 , и его нельзя отключить, так как для этого метода клиентский сертификат является обязательным. Метод cert отличается от простой проверки пригодности сертификата clientcert только тем, что также проверяет, соответствует ли атрибут cn имени пользователя базы данных.
19.3.10. Аутентификация PAM
Данный метод аутентификации работает подобно методу password , но использует в качестве механизма проверки подлинности PAM (Pluggable Authentication Modules, Подключаемые модули аутентификации). По умолчанию имя службы PAM - postgresql . PAM используется только для проверки пар "имя пользователя/пароль" и может дополнительно проверять имя или IP-адрес удалённого компьютера. Поэтому пользователь должен уже существовать в базе данных, чтобы PAM можно было использовать для аутентификации. За дополнительной информацией о PAM обратитесь к Странице описания Linux-PAM
.
Для аутентификации PAM доступны следующие параметры конфигурации:
Pamservice
Имя службы PAM pam_use_hostname
Указывает, предоставляется ли модулям PAM через поле PAM_RHOST IP-адрес либо имя удалённого компьютера. По умолчанию выдаётся IP-адрес. Установите в этом параметре 1, чтобы использовать имя узла. Разрешение имени узла может приводить к задержкам при подключении. (Обычно конфигурации PAM не задействуют эту информацию, так что этот параметр следует учитывать, только если создана специальная конфигурация, в которой он используется.)
Примечание
Если PAM настроен для чтения /etc/shadow , произойдёт сбой аутентификации, потому что сервер Postgres Pro запущен не пользователем root. Однако это не имеет значения, когда PAM настроен для использования LDAP или других методов аутентификации.
19.3.11. Аутентификация BSD
Данный метод аутентификации работает подобно методу password , но использует для проверки пароля механизм аутентификации BSD. Аутентификация BSD используется только для проверки пар "имя пользователя/пароль". Поэтому роль пользователя должна уже существовать в базе данных, чтобы эта аутентификация была успешной. Механизм аутентификации BSD в настоящее время может применяться только в OpenBSD.
Для аутентификации BSD в Postgres Pro
применяется тип входа auth-postgresql и класс postgresql , если он определён в login.conf . По умолчанию этот класс входа не существует и Postgres Pro
использует класс входа по умолчанию.
Примечание
Для использования аутентификации BSD необходимо сначала добавить учётную запись пользователя Postgres Pro (то есть, пользователя ОС, запускающего сервер) в группу auth . Группа auth существует в системах OpenBSD по умолчанию.