Re: Postgres 9.4 + unixODBC on Centos 6.5 problem connecting localhost postgres instance with isql ODBC commandline client
От | Faith, Jeremy |
---|---|
Тема | Re: Postgres 9.4 + unixODBC on Centos 6.5 problem connecting localhost postgres instance with isql ODBC commandline client |
Дата | |
Msg-id | 55BAADA01D8C504993894EAEA7517CF8124792@003FCH1MPN2-002.003f.mgd2.msft.net обсуждение исходный текст |
Ответ на | Re: Postgres 9.4 + unixODBC on Centos 6.5 problem connecting localhost postgres instance with isql ODBC commandline client ("Stefan Viljoen" <viljoens@verishare.co.za>) |
Ответы |
Re: Postgres 9.4 + unixODBC on Centos 6.5 problem connecting localhost postgres instance with isql ODBC commandline client
|
Список | pgsql-odbc |
Hi Stefan, You probably want to set ServerName back to localhost in your odbc.ini file, I had you change it to /tmp when I thought psqlwas using a unix domain socket. It is strange that tcpdump is picking up this connection, if the postgres driver is using the ServerName parameter then thereshould NOT have been a TCP connection. Have you tried doing the tcpdump on a psql connection attempt for comparison? Regards, Jeremy Faith ________________________________________ From: pgsql-odbc-owner@postgresql.org [pgsql-odbc-owner@postgresql.org] on behalf of Stefan Viljoen [viljoens@verishare.co.za] Sent: 21 July 2015 09:25 To: pgsql-odbc@postgresql.org Subject: Re: [ODBC] Postgres 9.4 + unixODBC on Centos 6.5 problem connecting localhost postgres instance with isql ODBC commandlineclient Hi List The plot thickens - I have now resorted to doing a tcpdump of the postgres port and then trying to connect via isql. The tcpdump command used was --- tcpdump -vvvvv -x -X -s 65535 -i lo 'port 5432' -w post.pcap --- This has revealed that in the post.pcap file (even just viewing the raw packet data with vi in the terminal) that the REASON postgress keeps rejecting isql login attempts is that isql apparently passes the database name only partially, or corrupts it randomly... E. g. I tried this five or six times and each time, the packets sent from unixODBC / isql binary, specifies the string asteriskcdrdb which denotes the database name to postgress (and therefore is critical to control login) as &%%@%!db *!@#drdb !@&&%$idb etc. and sometimes mixed / along with some other ASCII crud I cannot duplicate here. SSL is most definitely off so this cannot be encryption? The STRANGE thing is I can spot the username (asteriskcdruser) in the packet data and that is ALWAYS correct and uncorrupted, and is always passed as "asteriskcdruser". But the database name is -always- corrupted that is sent to port 5432 from isql to login to postgress. So if I do with isql --- isql -v pgdb-cdr asteriskcdruser pword --- In effect I try to login to postgress with *!@#drdb (as indicated by the packet data) which is of course a database that does not exist, nor is there a role that matches "asteriskcdruser" for such a database. From there the error [S1000][unixODBC]The database does not exist on the server or user authentication failed. [ISQL]ERROR: Could not SQLConnect which is completely logical as I'm trying to log into non-existent databases as passed over ODBC from isql, no? Any thoughts? How can this be fixed? ODBC connections on the same box over the lo interface to MySQL keep working 100% - wonder why unixODBC is corrupting the database name, but ONLY when passing it to Psql-odbc? Or am I completely barking up the wrong tree? Thanks Stefan -- Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-odbc Tyco Safety Products/CEM Systems Ltd. ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you arenot the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any actionin respect of any information contained in it. If you have received this e-mail in error, please notify the senderimmediately by e-mail and immediately destroy this e-mail and its attachments.
В списке pgsql-odbc по дате отправления: