Развертывание связки 1С:Предприятие + PostgreSQL + Ubuntu Linux на виртуальной машине (например, под управлением Oracle VirtualBox) — стандартная задача для создания тестовых сред или небольших рабочих серверов. Однако на этапе первоначальной настройки системные администраторы часто сталкиваются с ситуацией, когда службы СУБД и сервера приложений успешно запускаются, но при попытке создания информационной базы возникает ошибка подключения. Выясним причины этой проблемы и разберем по шагам, как правильно настроить конфигурационные файлы для успешной работы.
Типичная ситуация выглядит следующим образом: мы установили СУБД PostgreSQL и сервер 1С на Ubuntu внутри виртуальной машины. Команда проверки статуса службы СУБД возвращает положительный результат, подтверждая, что PostgreSQL активен. Служба сервера 1С srv1cv83 (или srv1cv8-8.3@default в зависимости от версии платформы) также находится в статусе active (running).
Однако при попытке создать базу данных через консоль администрирования или клиентское приложение 1С система выдает ошибку связи. Более того, при попытке проверить занятые порты стандартными утилитами сетевой диагностики (например, netstat -tunlp) порты сервера 1С (1540, 1541) и СУБД (5432) могут не отображаться как активные, либо отображаться некорректно. Рассмотрим подробнее, почему это происходит и как провести детальную диагностику.
Первое, с чего мы начнем — это правильная проверка сетевой активности служб. Распространенной ошибкой является запуск диагностических утилит от имени обычного пользователя. В современных дистрибутивах Linux для получения полной информации о процессах, занимающих порты, утилиты необходимо вызывать с правами суперпользователя sudo.
Вместо устаревшего пакета net-tools (утилита netstat) в современных системах Ubuntu рекомендуется использовать утилиту lsof. Проанализируем ситуацию и выполним команду для проверки портов кластера 1С:
sudo lsof -i :1541
sudo lsof -i :5432
Флаг -i (обратите внимание, что используется именно строчная "i", а не прописная "I") указывает утилите вывести список сетевых сокетов, привязанных к конкретному порту. Если службы запущены корректно, мы увидим процессы ragent, rmngr или postgres, слушающие соответствующие сетевые интерфейсы.
Основная причина, по которой сервер 1С не может достучаться до PostgreSQL на одной и той же виртуальной машине — это несовпадение адресов прослушивания (binding) сетевых интерфейсов. Разберем этот механизм подробнее.
По умолчанию СУБД PostgreSQL после чистой установки настроена на прослушивание исключительно локального петлевого интерфейса (loopback) с IP-адресом 127.0.0.1 (localhost). В то же время виртуальная машина в VirtualBox, работающая в режиме сетевого адаптера NAT, получает внешний IP-адрес вида 10.0.2.15.
Когда мы пытаемся создать базу данных 1С и указываем в качестве сервера СУБД сетевое имя нашей виртуальной машины (например, linerver), сервер приложений 1С разрешает (резолвит) это имя в сетевой IP-адрес 10.0.2.15. Происходит следующая ситуация:
10.0.2.15:5432.127.0.0.1:5432.Для решения этой проблемы у нас есть два пути:
Вариант А. Настройка СУБД на прослушивание всех сетевых интерфейсов. Для этого нам необходимо отредактировать основной конфигурационный файл PostgreSQL. В зависимости от версии СУБД он находится по пути /etc/postgresql/{версия}/main/postgresql.conf или в директории Postgres Pro /var/lib/pgpro/{версия}/data/postgresql.conf.
Найдем директиву listen_addresses, раскомментируем ее и заменим значение на звездочку, что заставит СУБД принимать подключения со всех доступных сетевых интерфейсов:
listen_addresses = '*'
После изменения конфигурационного файла обязательно перезапустим службу СУБД:
sudo systemctl restart postgresql
Вариант Б. Использование локального адреса при создании базы. Если сервер приложений 1С и СУБД PostgreSQL развернуты на одном и том же физическом или виртуальном сервере, нет необходимости гонять трафик через внешние сетевые интерфейсы. При создании информационной базы в поле "Сервер баз данных" следует указывать не сетевое имя компьютера, а локальный IP-адрес 127.0.0.1 или имя localhost.
После того как мы обеспечили физическую доступность порта СУБД, нам необходимо настроить авторизацию в файле pg_hba.conf (он находится в той же директории, что и postgresql.conf). Этот файл управляет правами доступа клиентов к базам данных на основе их IP-адресов.
Часто в старых инструкциях предлагается использовать метод авторизации trust (подключение без пароля) для локальных сокетов. Однако для корректной работы платформы 1С требуется четкая авторизация пользователя СУБД (обычно это системный пользователь postgres). Выясним, как правильно прописать правила авторизации.
Откроем файл pg_hba.conf и добавим (или отредактируем) следующие строки:
# Разрешаем подключение через локальный UNIX-сокет
local all all md5
# Разрешаем локальные TCP/IP подключения по IPv4
host all all 127.0.0.1/32 md5
# Разрешаем локальные TCP/IP подключения по IPv6
host all all ::1/128 md5
Использование метода md5 (или более современного scram-sha-256) гарантирует, что 1С сможет успешно авторизоваться в СУБД, передавая пароль пользователя. Если вы используете метод trust, убедитесь, что в СУБД у пользователя postgres задан пустой пароль, однако это крайне не рекомендуется из соображений безопасности.
Не забудьте применить настройки СУБД после изменения pg_hba.conf:
sudo systemctl reload postgresql
Сервер приложений 1С (служба ragent) крайне чувствителен к корректности разрешения сетевых имен (hostname). Если операционная система сервера не может сопоставить собственное имя хоста с IP-адресом, кластер 1С может работать нестабильно, блокируя создание баз данных.
Проанализируем файл локального разрешения имен. Откроем его с помощью текстового редактора:
sudo nano /etc/hosts
Убедимся, что сетевое имя вашей виртуальной машины (вы можете узнать его с помощью команды hostname) явно сопоставлено с локальной петлей 127.0.0.1. Строка в файле должна выглядеть следующим образом:
127.0.0.1 localhost linerver
Здесь linerver — это имя вашего сервера. Сохраните изменения (в редакторе nano для этого нужно нажать Ctrl+O, затем Enter, и для выхода — Ctrl+X).
Рассмотрим продвинутый способ оптимизации взаимодействия 1С и PostgreSQL, когда они работают на одной операционной системе Ubuntu. Сетевой стек TCP/IP накладывает определенные вычислительные издержки на упаковку и распаковку сетевых пакетов, даже если эти пакеты не покидают пределы локальной машины.
Для минимизации этих издержек мы можем настроить подключение через локальные UNIX-сокеты. Для этого при создании информационной базы в поле "Сервер баз данных" вместо сетевого имени или IP-адреса мы указываем путь к каталогу, где PostgreSQL создает файл сокета (обычно это файл .s.PGSQL.5432).
По умолчанию в дистрибутивах Ubuntu этот сокет располагается по пути /var/run/postgresql или в каталоге /tmp. При создании базы данных в консоли 1С укажем в поле сервера СУБД:
/var/run/postgresql
При этом в файле pg_hba.conf обязательно должно присутствовать активное правило для типа подключения local, обеспечивающее доступ через сокет.
Даже при идеально настроенной сети создание базы данных 1С на Linux может завершиться ошибкой, если не учтены два важнейших системных требования:
sudo apt install postgresql) не содержит патчей для работы с блокировками и механизмами сравнения строк, специфичными для платформы 1С. Вам необходимо использовать сборку Postgres Pro 1C или специальный дистрибутив PostgreSQL от компании "1С". Попытка использовать ванильную версию СУБД приведет к критическим ошибкам структуры таблиц при создании базы.ru_RU.UTF-8. Если виртуальная машина Ubuntu была установлена на английском языке по умолчанию, системная локаль может отличаться.Для исправления локали выполним переконфигурацию пакетов в операционной системе:
sudo dpkg-reconfigure locales
В открывшемся псевдографическом меню найдите и отметьте пробелом пункт ru_RU.UTF-8 UTF-8, затем выберите эту локаль в качестве системной по умолчанию. После этого перезагрузите сервер. Если база данных все равно отказывается создаваться, потребуется переинициализировать кластер PostgreSQL с правильным флагом локали:
sudo /opt/pgpro/1c-15/bin/pg-setup initdb --tune=1c --locale=ru_RU.UTF-8
После выполнения этих шагов перезапустите все службы и повторите попытку создания информационной базы в консоли 1С. Связка сервера приложений и СУБД будет работать стабильно и производительно.