Thread: How to troubleshoot authentication failure?
I have two Linux servers that are pretty similar to each other, and both are running PostgreSQL servers, but in one server a certain Perl script succeeds in connecting to the localhost server whereas in the other one the same script fails. The error on the second server is of the form "fe_sendauth: no password supplied".
I have verified all the possible reasons that I can think of for why this script succeeds on one server but fails on the other. In all these respects the two set ups are absolutely identical: same pg_hba.conf files, same script parameters, same versions of Postgres, same everything.
I have run out of ideas!
How can I troubleshoot this further? Is there some way to have Postgres dump excruciatingly thorough details about every single step of the authentication sequence?
Any other suggestions would be greatly appreciated.
Thanks!
k
Kynn Jones escribió: > I have two Linux servers that are pretty similar to each other, and both are > running PostgreSQL servers, but in one server a certain Perl script succeeds > in connecting to the localhost server whereas in the other one the same > script fails. The error on the second server is of the form "fe_sendauth: > no password supplied". > I have verified all the possible reasons that I can think of for why this > script succeeds on one server but fails on the other. In all these respects > the two set ups are absolutely identical: same pg_hba.conf files, same > script parameters, same versions of Postgres, same everything. Maybe you have a .pgpass file storing a password for one of them and not the other? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, 7 Oct 2009, Kynn Jones wrote: > Is there some way to have Postgres dump excruciatingly thorough details > about every single step of the authentication sequence? There's a postgresql.conf parameter named log_min_messages that you can crank up until you see the detail level you're looking for. In general, "debug2" is usually a good place to start at when trying to nail down mysterious database issues. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Thank you all! Someone else in our team found the problem (a missing user in the failing server).
k