Итак, я установил минимальную установку 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, чтобы узнать, упоминается ли в нем попытка подключения.