8.0 Beta3 worked, RC1 didn't!
Hi all,
I'm using psql 8.0.0 on a client's site who's running win server 2003.
We've had him on beta 3 for some time, and no problems at all (yes, in a
sense, he is a beta tester as well, but doesn't know it!). Today I tried to
upgrade the db to RC1 and had some problems.
Remote clients connect to this database, so I have to set listen_addresses =
'*' in the posrgresql.conf file. This is the only change to the config
file. Doing this with RC1 and trying to connect locally with through psql
resulted in the following error message:
"could not receive server response to SSL negotiation packet; connection
reset by peer (0x00002746/10054)"
Removing the modified line in the config file resolved the problem
(locally), however, no clients can connect! Beta 3 does not seem to have
this issue, so we had to revert back to it for now.
I would appreciate any ideas that some of you may have. Much thanks,
-Peter
A. Mous wrote:
Hi all,
I'm using psql 8.0.0 on a client's site who's running win server 2003.
We've had him on beta 3 for some time, and no problems at all (yes, in a
sense, he is a beta tester as well, but doesn't know it!). Today I tried to
upgrade the db to RC1 and had some problems.Remote clients connect to this database, so I have to set listen_addresses =
'*' in the posrgresql.conf file. This is the only change to the config
file. Doing this with RC1 and trying to connect locally with through psql
resulted in the following error message:"could not receive server response to SSL negotiation packet; connection
reset by peer (0x00002746/10054)"
The clients connecting remotely... do they support SSL? It looks
like to me that you have ssl enabled. I would check the pg_hba.conf
and the postgresql.conf for your ssl configuration.
Sincerely,
Joshua D. Drake
Removing the modified line in the config file resolved the problem
(locally), however, no clients can connect! Beta 3 does not seem to have
this issue, so we had to revert back to it for now.I would appreciate any ideas that some of you may have. Much thanks,
-Peter
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
On Tue, Dec 21, 2004 at 07:06:00PM -0800, Joshua D. Drake wrote:
The clients connecting remotely... do they support SSL? It looks
like to me that you have ssl enabled. I would check the pg_hba.conf
and the postgresql.conf for your ssl configuration.
Was there a change affecting client certificate handling a couple
of months ago? I recall SSL connections not working after one of
the updates I did. I could be misremembering, but I think the
problem was that the presence of $PGDATA/root.crt caused the backend
to require a client certificate, whereas before the update that
wasn't happening -- a client without a certificate could connect
as long as it spoke SSL and otherwise satisfied pg_hba.conf. The
solution was either to create a client certificate or to remove
$PGDATA/root.crt.
Hmmm...let's do a little test...
I have a server running 7.4.6 and 8.0.0rc2. Both have root.crt,
server.crt, and server.key; both have "ssl = true" in postgresql.conf;
and both have a "hostssl" line in pg_hba.conf to force SSL for
remote clients.
I have a remote client running 8.0.0rc2. I'll connect to each
server twice, once with a client certificate and once without
(the certificate is in $HOME/.postgresql/postgresql.{crt,key}):
1. Connect to 7.4.6 with certificate: success
2. Connect to 8.0.0rc2 with certificate: success
Now I'll remove the certificate files and attempt the connections
again:
3. Connect to 7.4.6 without certificate: success
4. Connect to 8.0.0rc2 without certificate: failure
For the failure in (4), the client gave the following error:
psql: could not open certificate file "/.../.postgresql/postgresql.crt": No such file or directory
The 8.0.0rc2 server logged the following:
could not accept SSL connection: peer did not return a certificate
The backend's behavior regarding client certificates when root.crt
exists appears to have changed between the 7.4 branch and the latest
8.0 release candidate. If I remember correctly, 8.0 behaved as 7.4
does (client certificates not required even when root.crt exists)
until a couple of months ago. Was that change intentional or
accidental?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
The SSL line in postgresql.conf has not been touched. By default it should
be set to false. Also, the pg_hba file is set to allow all clients in, no
authentication (TRUST).
I have not seen this problem in any other installation. Note as well, the
only way to access the server in question is via a remote connection (Remote
Administrator). I do remember, however, that even before attempting remote
connections to the database, the same error message would also occur
'locally' (through remote administrator, but I don't see how this interface
would factor into the problem.
I can't see how this would be a result of a configuration setting. If I
install RC1 and attempt a connection locally (before modifying any configs)
it fails with the aforementioned error message. Uninstall RC1 and install
beta 3 and it works (this is repeatable).
One more thing...I may be wrong on this one because I was not paying
attention as well as I should have, but I seem to remember that following
one of my RC1 installation attempts, I was able to log into psql locally,
but only once. After that I was denied every time. Again, I *think* this
is what happened!
Thanks,
Peter
-----Original Message-----
From: Joshua D. Drake [mailto:jd@commandprompt.com]
Sent: December 21, 2004 8:06 PM
To: A. Mous
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] 8.0 Beta3 worked, RC1 didn't!
A. Mous wrote:
Hi all,
I'm using psql 8.0.0 on a client's site who's running win server 2003.
We've had him on beta 3 for some time, and no problems at all (yes, in a
sense, he is a beta tester as well, but doesn't know it!). Today I tried
to
upgrade the db to RC1 and had some problems.
Remote clients connect to this database, so I have to set listen_addresses
=
'*' in the posrgresql.conf file. This is the only change to the config
file. Doing this with RC1 and trying to connect locally with through psql
resulted in the following error message:"could not receive server response to SSL negotiation packet; connection
reset by peer (0x00002746/10054)"
The clients connecting remotely... do they support SSL? It looks
like to me that you have ssl enabled. I would check the pg_hba.conf
and the postgresql.conf for your ssl configuration.
Sincerely,
Joshua D. Drake
Removing the modified line in the config file resolved the problem
(locally), however, no clients can connect! Beta 3 does not seem to have
this issue, so we had to revert back to it for now.I would appreciate any ideas that some of you may have. Much thanks,
-Peter
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL
Hi all,
I'm using psql 8.0.0 on a client's site who's running win server 2003.
We've had him on beta 3 for some time, and no problems at all
(yes, in a sense, he is a beta tester as well, but doesn't
know it!). Today I tried to upgrade the db to RC1 and had
some problems.Remote clients connect to this database, so I have to set
listen_addresses = '*' in the posrgresql.conf file. This is
the only change to the config file. Doing this with RC1 and
trying to connect locally with through psql resulted in the
following error message:"could not receive server response to SSL negotiation packet;
connection reset by peer (0x00002746/10054)"Removing the modified line in the config file resolved the
problem (locally), however, no clients can connect! Beta 3
does not seem to have this issue, so we had to revert back to
it for now.I would appreciate any ideas that some of you may have. Much thanks,
If you installed from the MSI installer - the RC1 installer was
accidentally built without SSL support. Please try the RC2 installer
available now. If you are using SSL, that is.
That said, could you let us know what you have in your logfiles?
(data\pg_log\<latest file> if you haven't changed it) ALso, check if you
have something in the eventlog around the time of either service start
or client connection.
//Magnus
Import Notes
Resolved by subject fallback
Michael Fuhr <mike@fuhr.org> writes:
Was there a change affecting client certificate handling a couple
of months ago?
Yes, but it was pre-beta3.
However, this being on Windows ... I don't think the SSL code was
enabled at all in the Windows port as of beta3. I find this post-beta3
CVS log entry:
2004-10-06 05:35 momjian
* configure, configure.in, src/backend/libpq/be-secure.c,
src/backend/port/win32/socket.c,
src/backend/postmaster/postmaster.c, src/include/pg_config.h.in,
src/include/port/win32.h: Here is a patch to fix win32 ssl builds.
Summary of changes:
* Links with -leay32 and -lssleay32 instead of crypto and ssl. On
win32, "crypto and ssl" is only used for static linking.
* Initializes SSL in the backend and not just in the postmaster. We
cannot pass the SSL context from the postmaster through the
parameter file, because it contains function pointers.
* Split one error check in be-secure.c. Previously we could not
tell which of three calls actually failed. The previous code also
returned incorrect error messages if SSL_accept() failed - that
function needs to use SSL_get_error() on the return value, can't
just use the error queue.
* Since the win32 implementation uses non-blocking sockets "behind
the scenes" in order to deliver signals correctly, implements a
version of SSL_accept() that can handle this. Also, add a wait
function in case SSL_read or SSL_write() needs more data.
Magnus Hagander
It seems likely to me that the Windows SSL code may still be a brick or
two shy of a load ...
regards, tom lane
Yes, all versions were installed through the win installer.
I didn't change the SSL settings from default, so I believe it should not be
using it. In my haste, I did not keep a copy of the logs generated during
the RC1 installation. I can try RC2 this evening (outside of business
hours) and let you know how it went.
Also, Beta5 exhibited the same behaviour as RC1!
-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: December 22, 2004 3:05 AM
To: A. Mous; pgsql-general@postgresql.org
Subject: RE: [GENERAL] 8.0 Beta3 worked, RC1 didn't!
Hi all,
I'm using psql 8.0.0 on a client's site who's running win server 2003.
We've had him on beta 3 for some time, and no problems at all
(yes, in a sense, he is a beta tester as well, but doesn't
know it!). Today I tried to upgrade the db to RC1 and had
some problems.Remote clients connect to this database, so I have to set
listen_addresses = '*' in the posrgresql.conf file. This is
the only change to the config file. Doing this with RC1 and
trying to connect locally with through psql resulted in the
following error message:"could not receive server response to SSL negotiation packet;
connection reset by peer (0x00002746/10054)"Removing the modified line in the config file resolved the
problem (locally), however, no clients can connect! Beta 3
does not seem to have this issue, so we had to revert back to
it for now.I would appreciate any ideas that some of you may have. Much thanks,
If you installed from the MSI installer - the RC1 installer was
accidentally built without SSL support. Please try the RC2 installer
available now. If you are using SSL, that is.
That said, could you let us know what you have in your logfiles?
(data\pg_log\<latest file> if you haven't changed it) ALso, check if you
have something in the eventlog around the time of either service start
or client connection.
//Magnus
"A. Mous" <a.mous@shaw.ca> writes:
I didn't change the SSL settings from default, so I believe it should not be
using it.
Nope, the default libpq behavior is "prefer SSL", so it will try an SSL
connection first ... if it is compiled to support SSL, which I believe
was not true in the beta3 windows release but is true in later releases.
Right at the moment I'm not convinced this is an SSL issue at all, it's
just that the connection failure occurs while we're asking the server if
it wants to do SSL. You can try
export PGSSLMODE=disable
before running psql and see how the behavior changes, but I suspect it
will still fail.
regards, tom lane
Ok, then the problem has nothing to do with SSL. IIRC, you get this
error message if you have SSL support compiled in (which the MSI version
does) and get a failure really early (typical example: connection is
accepted and then dropped right away). It has nothing to do with SSL.
The output of your server log should point at what the actual issue is.
//Magnus
Show quoted text
-----Original Message-----
From: A. Mous [mailto:a.mous@shaw.ca]
Sent: Wednesday, December 22, 2004 5:41 PM
To: Magnus Hagander; pgsql-general@postgresql.org
Subject: RE: [GENERAL] 8.0 Beta3 worked, RC1 didn't!Yes, all versions were installed through the win installer.
I didn't change the SSL settings from default, so I believe
it should not be using it. In my haste, I did not keep a
copy of the logs generated during the RC1 installation. I
can try RC2 this evening (outside of business
hours) and let you know how it went.Also, Beta5 exhibited the same behaviour as RC1!
-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: December 22, 2004 3:05 AM
To: A. Mous; pgsql-general@postgresql.org
Subject: RE: [GENERAL] 8.0 Beta3 worked, RC1 didn't!Hi all,
I'm using psql 8.0.0 on a client's site who's running win
server 2003.
We've had him on beta 3 for some time, and no problems at
all (yes, in
a sense, he is a beta tester as well, but doesn't know
it!). Today I
tried to upgrade the db to RC1 and had some problems.
Remote clients connect to this database, so I have to set
listen_addresses = '*' in the posrgresql.conf file. Thisis the only
change to the config file. Doing this with RC1 and trying
to connect
locally with through psql resulted in the following error message:
"could not receive server response to SSL negotiation packet;
connection reset by peer (0x00002746/10054)"Removing the modified line in the config file resolved the problem
(locally), however, no clients can connect! Beta 3 doesnot seem to
have this issue, so we had to revert back to it for now.
I would appreciate any ideas that some of you may have.
Much thanks,
If you installed from the MSI installer - the RC1 installer
was accidentally built without SSL support. Please try the
RC2 installer available now. If you are using SSL, that is.That said, could you let us know what you have in your logfiles?
(data\pg_log\<latest file> if you haven't changed it) ALso,
check if you have something in the eventlog around the time
of either service start or client connection.//Magnus
Import Notes
Resolved by subject fallback
Thanks. I'll have to wait until after business hours to try RC2 and play a
bit more. Right now it's happily running Beta3. I'll be more diligent in
collecting log data with my next attempt.
Much thanks,
-Peter
-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: December 22, 2004 10:50 AM
To: A. Mous; pgsql-general@postgresql.org
Subject: RE: [GENERAL] 8.0 Beta3 worked, RC1 didn't!
Ok, then the problem has nothing to do with SSL. IIRC, you get this
error message if you have SSL support compiled in (which the MSI version
does) and get a failure really early (typical example: connection is
accepted and then dropped right away). It has nothing to do with SSL.
The output of your server log should point at what the actual issue is.
//Magnus
Show quoted text
-----Original Message-----
From: A. Mous [mailto:a.mous@shaw.ca]
Sent: Wednesday, December 22, 2004 5:41 PM
To: Magnus Hagander; pgsql-general@postgresql.org
Subject: RE: [GENERAL] 8.0 Beta3 worked, RC1 didn't!Yes, all versions were installed through the win installer.
I didn't change the SSL settings from default, so I believe
it should not be using it. In my haste, I did not keep a
copy of the logs generated during the RC1 installation. I
can try RC2 this evening (outside of business
hours) and let you know how it went.Also, Beta5 exhibited the same behaviour as RC1!
-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: December 22, 2004 3:05 AM
To: A. Mous; pgsql-general@postgresql.org
Subject: RE: [GENERAL] 8.0 Beta3 worked, RC1 didn't!Hi all,
I'm using psql 8.0.0 on a client's site who's running win
server 2003.
We've had him on beta 3 for some time, and no problems at
all (yes, in
a sense, he is a beta tester as well, but doesn't know
it!). Today I
tried to upgrade the db to RC1 and had some problems.
Remote clients connect to this database, so I have to set
listen_addresses = '*' in the posrgresql.conf file. Thisis the only
change to the config file. Doing this with RC1 and trying
to connect
locally with through psql resulted in the following error message:
"could not receive server response to SSL negotiation packet;
connection reset by peer (0x00002746/10054)"Removing the modified line in the config file resolved the problem
(locally), however, no clients can connect! Beta 3 doesnot seem to
have this issue, so we had to revert back to it for now.
I would appreciate any ideas that some of you may have.
Much thanks,
If you installed from the MSI installer - the RC1 installer
was accidentally built without SSL support. Please try the
RC2 installer available now. If you are using SSL, that is.That said, could you let us know what you have in your logfiles?
(data\pg_log\<latest file> if you haven't changed it) ALso,
check if you have something in the eventlog around the time
of either service start or client connection.//Magnus