Re: [BUGS] [TESTERS] Location of certs -Windows 7 SSL mode?
On Wed, Jul 7, 2010 at 01:37, Lou Picciano wrote: > [TEST REPORT] > [Release]: 9.0Beta2 > [Test Type]: Testing connection - pgAdmin - using certificate on Windows 7 - > Specifically, what is correct default placement of certs? > [Test]: Attempt to connect - SSL required or better - using standard > AppData/Roaming location for certs, key. > [Platform]: Windows 7 Ultimate 64-bit - attempting connection using > pgAdminIII as a test of SSL connectivity. > [Parameters]: First, attempted connection, with SSL required and NO certs, > to determine default location based on error message! > [Failure]: Yes > [Results]: Installation of a pre-packaged PostgreSQL, using an installer (in > this case a b1 packaged by EnterpriseDB), did create a postgresql folder in > the expected location: C:\Users\\AppData\Roaming\postgresql. > After placement of valid certs and key in this folder, cannot connect in > any SSL mode. > Interestingly, the error message reverses the pathname delimiter, halfway > through the message, from Windows-standard to UNIX-standard (is this > relevant?)... > "Error connecting to the server: could not open certificate file > "C:\Users\\AppData\roaming/postgresql/potgresql.crt": No such file > or directory. The reversed slashes are pretty normal, and should work just fine. What is your connection string? Are you specifying the cert file there as well? Does the file actually exist in that directory? Does the permissions on the file and all the directories leading up to it let you read the file? The code itself should actually "never" do this - it specifically checks if the file doesn't exist, and should *not* show that error.. It should fail much later, when the server actually requests the cert.. And the API documentation for stat() on windows says it'll always return ENOENT on failure. Seems to me Windows is confused, but I'm not entirely sure how. Can you try specifying an explicit file say directly in c:\, just to see if that works? BTW, if you post bug reports to -bugs, it'll make a lot more people see them. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [TESTERS] Location of certs -Windows 7 SSL mode?
Magnus, Tks for your response. > What is your connection string? Are you specifying the cert file there as > well? Well, no. Specifically, the exercise was to determine default locations of certs on Windows 7, as inferred from - the expected - error message from the PG client. In this case, the client was pgAdmin. (Is pgAdmin not a valid 'default' test?) > Does the file actually exist in that directory? Does the permissions on the > file and all the directories leading up to it let you read the file? Yes, exists; and all files wer created by the 'administrator' user - the only user on the system, with the system having been installed fresh specifically to effect this test. We're trying to develop a 'recipe' for our Windows 7 users. > The code itself should actually "never" do this - it specifically checks if > the file doesn't exist, and should *not* show that error.. > It should fail much later, when the server actually requests the cert.. Oh? I didn't realize this. In fact, past experience has been consistent with my findings; that pqlib will hiccup quickly if it cannot find a cert, and that this error message would appear before ever presenting that (non-)cert to the server. If a cert is found, on the other hand, error messages would be different, assuming it's an invalid cert in the context of pg_hba.cconf. > Can you try specifying an explicit file say directly in c:\, just to see if > that works? Presumably you're proposing an environment variable approach? Sure, please propose an exact test, and we'll perform. (No one else here is using certs under Windows 7?) (BTW, specifically did not post to bugs list as, since we are testing betas, I don't know whether I'm uncovering bugs - or 'new behaviors'! Or, whether I'm uncovering a 'bug' in, uhh... 'userspace'.) Thanks again, Lou Picciano - Original Message - From: "Magnus Hagander" To: "Lou Picciano" Cc: "pgsql-testers" , "pgsql-bugs" Sent: Wednesday, July 7, 2010 4:50:03 AM Subject: Re: [TESTERS] Location of certs -Windows 7 SSL mode? On Wed, Jul 7, 2010 at 01:37, Lou Picciano wrote: > [TEST REPORT] > [Release]: 9.0Beta2 > [Test Type]: Testing connection - pgAdmin - using certificate on Windows 7 - > Specifically, what is correct default placement of certs? > [Test]: Attempt to connect - SSL required or better - using standard > AppData/Roaming location for certs, key. > [Platform]: Windows 7 Ultimate 64-bit - attempting connection using > pgAdminIII as a test of SSL connectivity. > [Parameters]: First, attempted connection, with SSL required and NO certs, > to determine default location based on error message! > [Failure]: Yes > [Results]: Installation of a pre-packaged PostgreSQL, using an installer (in > this case a b1 packaged by EnterpriseDB), did create a postgresql folder in > the expected location: C:\Users\\AppData\Roaming\postgresql. > After placement of valid certs and key in this folder, cannot connect in > any SSL mode. > Interestingly, the error message reverses the pathname delimiter, halfway > through the message, from Windows-standard to UNIX-standard (is this > relevant?)... > "Error connecting to the server: could not open certificate file > "C:\Users\\AppData\roaming/postgresql/potgresql.crt": No such file > or directory. The reversed slashes are pretty normal, and should work just fine. What is your connection string? Are you specifying the cert file there as well? Does the file actually exist in that directory? Does the permissions on the file and all the directories leading up to it let you read the file? The code itself should actually "never" do this - it specifically checks if the file doesn't exist, and should *not* show that error.. It should fail much later, when the server actually requests the cert.. And the API documentation for stat() on windows says it'll always return ENOENT on failure. Seems to me Windows is confused, but I'm not entirely sure how. Can you try specifying an explicit file say directly in c:\, just to see if that works? BTW, if you post bug reports to -bugs, it'll make a lot more people see them. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: [BUGS] Negative result with (now()-previously_inserted_timestamp)
Excerpts from Gurjeet Singh's message of mié jul 07 00:43:32 -0400 2010: > If you must know, this instance is on a low-cost, hosted, Xen virtual > machine. I think Tom diagnosed an issue affecting pgstats as being out of sync gettimeofday() results on different processes. IIRC this was on a virtualized machine of some kind. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Negative result with (now()-previously_inserted_timestamp)
Gurjeet Singh writes: > On Wed, Jul 7, 2010 at 12:18 AM, Tom Lane wrote: >> Gurjeet Singh writes: >>> I ran the following query, and got an unexpected negative value. Does >>> this imply that SELECT-transaction was able to see a row created by >>> INSERT-transaction which started after the SELECT-transaction? >> >> Was the SELECT inside a BEGIN block? > Oh, I get it. You mean read-committed transaction mode's side-effect inside > a transaction block! > No, that's not the case. Just confirmed that by issuing a syntactically > wrong statement in that session (resulting in ERROR), and then doing 'select > 1'; it did not raise the error 'Current transaction is aborted...'. Well, now() would be the time of receipt of the command message from the client. The transaction snapshot would be taken a bit later than that. It's theoretically possible for another transaction to start and commit in between. That'd be more likely if now() had been set by a separate transaction-starting command, but if your server was loaded enough then maybe it could happen anyway. We have seen at least one case where it appeared that the value of gettimeofday() was significantly different on different CPUs of a multiprocessor machine: http://archives.postgresql.org/pgsql-hackers/2010-03/msg00985.php It's possible you're dealing with something like that, too. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [TESTERS] Location of certs -Windows 7 SSL mode?
On 7/7/10 1:50 AM, Magnus Hagander wrote: > BTW, if you post bug reports to -bugs, it'll make a lot more people see them. Sure, we just want to verify that it *is* a possible bug (and not pilot error) first. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [TESTERS] Location of certs -Windows 7 SSL mode?
On 07/07/10 22:28, Lou Picciano wrote: > Well, no. Specifically, the exercise was to determine default locations of > certs on Windows 7, as inferred from - the expected - error message from the > PG client. In this case, the client was pgAdmin. (Is pgAdmin not a valid > 'default' test?) I'm coming in half-way into this conversation, so forgive any confusion, but are you referring to server certs (that live in the datadir) or client certificates to authenticate a client to the server? If server certs, the certs live in the same place on Windows as every other platform: in the data dir. IIRC on Windows client certificates live in %APPDATA%\.postgresql\ I'll verify that shortly as I have a win7 machine here now. > (No one else here is using certs under Windows 7?) I use client certificates on Windows, but only via a Java app with JDBC, so I haven't been too worried about libpq's client cert handling. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
