Hello List,
I hope this is not posted in an inappropriate forum, but I have searched for
a solution to this problem in both Mapserver and PostGIS forums / FAQs /
websites / docs to no avail.
I am running PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by GCC gcc
(GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7).
I am running WinNT4.0 IIS 4.0 web servers with Mapserver (have tried several
versions).
I have 2 web/mapserver servers (Intel WinNT4.0 IIS4.0) that access my
Postgresql database. One is a test server (located in the same domain / ip
range as the Postgresql server) and one is a live server (located in a
separate domain / ip range from the Postgresql server). Using the same
connection information in a mapfile the test server can access and map
the Postgresql database with no problem - as could the live server when it
was in the domain - but the live server fails to connect with an error
(msPOSTGISLayerOpen(): Query error. Error parsing POSTGIS connection
information.) now that it is outside the domain. I am stressing the domain /
ip range issue here because I can't think of any other difference in the two
servers.
Here are knowns:
- PGAdmin from the live server connects with no problem.
- ODBC connectivity from the live server works fine.
- The mapfiles on the test and live servers are identical except for
necessary directory differences.
- Checked password, hostname, connection type, socket connections enabled as
instructed in debug version of Mapserver build, but if they work on the test
server shouldn't they work on the live?
- Added live server to pg_hba.conf although test server is not listed in
pg_hba.conf and
connects successfully:
host all 216.226.17.176 255.255.255.0 trust
- Initialize postmaster with -i option to allow tcp/ip connections.
- tcpip_socket=true in postgresql.conf.
- Tried using port=5432 in the CONNECTION param for mapfile - no difference
in behaviour.
As I watch the activity in a terminal (-d option to postmaster) I never see
anything from the live webserver's attempts to connect. They aren't refused
- they aren't getting there.
Sorry for the long post and thanks in advance for any ideas or help,
David Lowther
Software Engineer
GEO Information Systems
University of Oklahoma
dlowther@ou.edu
(405) 325-3131
http://www.geo.ou.edu
