Назад | Перейти на главную страницу

Не удается подключиться к БД PostgreSQL через pgAdmin

Итак, я установил минимальную установку Fedora 15 для создания сервера для веб-приложения. Я также установил PostgreSQL 9.1 с pgrpms.org. Установка PostgreSQL прошла успешно. Локально мне удалось запустить initdb, start и psql, чтобы изменить пароль postgres.

Теперь я установил pgAdmin в системе Windows в той же подсети. Однако я не могу подключиться.

Я редактировал /var/lib/pgsql/9.1/data/postgresql.conf установить listen_addresses = '*'. Я редактировал /var/lib/pgsql/9.1/data/pg_hba.conf позволять host all all 192.168.1.0/24 trust. Я тоже перезапустился после изменений (service postgresql-9.1 restart)

Ошибка в pgAdmin: не удалось подключиться к серверу: истекло время ожидания соединения (0x0000274C / 10060). Сервер работает на хосте «192.168.1.110» и принимает соединения TCP / IP на порту 5432?

Ответ положительный. Я не устанавливал брандмауэр и отключил его на своей рабочей станции под управлением Windows. Я могу подключиться к серверу через ping и SSH. tcpdump показывает, что попытка подключения к порту 5432 от pgAdmin действительно произошла:

[root@cobalion yum.repos.d]# tcpdump port 5432
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
07:28:44.014920 IP totodile.mcs.local.54067 > 192.168.1.110.postgres: Flags [S], seq 3554805012, w in 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
07:28:47.023859 IP totodile.mcs.local.54067 > 192.168.1.110.postgres: Flags [S], seq 3554805012, w in 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
07:28:53.019464 IP totodile.mcs.local.54067 > 192.168.1.110.postgres: Flags [S], seq 3554805012, w in 8192, options [mss 1460,nop,nop,sackOK], length 0

Я не знаю, где искать дальше? На первый взгляд кажется, что я смогу подключиться. Любые идеи? Могу ли я как-нибудь проверить "изнутри" работающего сервера postgresql, какие настройки были загружены?

Ваш tcpdump в значительной степени подтверждает, что iptables отбрасывает пакеты на стороне сервера. tcpdump проверяет пакеты до того, как их коснется брандмауэр. Если брандмауэр не отбрасывал пакеты и postgres не работал, ядро ​​выполняло RST попытку подключения:

07:39:14.878008 IP localhost.12343 > localhost.35259: Flags [R.], seq 0, ack 1980582372, win 0, length 0

и вы сразу получите отказ в соединении, а не тайм-аут.

Единственное, что я могу придумать, это установить абсурдно низкий лимит подключения на сервере, и он уже заполнен. Я никогда не пробовал это, чтобы увидеть, что произойдет, хотя мне кажется, что он будет отклонять соединения, а не отключать их по времени, в зависимости от поведения различных веб-сайтов с ошибками базы данных, с которыми я сталкиваюсь все время. Вы можете проверить журнал postgresql, чтобы узнать, упоминается ли в нем попытка подключения.