psql -d my_db -U my_user -h my.com
same command works fine from other machines, but not from this particular machine.
I'm scratching my heads over many hours now and failed to google it.
Any ideas?
Try specifying the port via -p <port>. It may be that the Postgres binaries on this particular box were compiled with a different default port, or have the PGPORT environment variable set whereas the other boxes do not.
The default port is usually 5432, although that can be compiled in differently or set in the server config differently.
Since it says that the DB does not exist, as opposed to that it can't connect, I suspect that it's not a core networking issue (unless my.com happened to be rerouted via /etc/hosts to some other box that happened to also have a Postgres instance on it with the same password and access permissions, but that seems somewhat unlikely, unless perhaps it was redirected to localhost for testing, which could be the case, although that seems less likely).
Related
I installed PostgreSQL 13.2 on Windows. The service is running, but when I use psql -Upostgres to connect it always fails password authentication even though I am entering the right password. I read that if you set the METHOD to trust in pg_hba.conf then it shouldn't even ask for passwords. I did that and then restarted the service--it still asks for the password and fails.
I've run out of ideas on what to try, so I thought I'd try here. Any thoughts?
The problem was that a docker container was running that was using port 5432 so postgres was using port 5433. I had thought that the docker container was stopped, so I had put it completely out of my mind. When I used psql without specifying a port, it was attempting to connect to the db running in the docker container, which had a different password for the user postgres. (This also explained why changing METHOD to trust in pg_hba.conf didn't work: it was the wrong instance of postgres that I was connecting to.)
I'm running CentOS 7.5 and cannot setup PostgreSQL.
If I'm logged in as user postgres and type psql postgres I get the following error message:
psql: Could not connect to server: no such file or directory
does the server run locally and accepts connections on Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"
However, I changed the port to 5543 (did so in etc/systemd/system/postgresql.service by including /lib/systemd/system/postgresql.service as a [Service] and setting Environment=PGPORT=5543). Note that you shouldn't change it directly in /lib/ because that will get overwritten.
So, the server looks for the wrong UNIX-Domain-Socket and does not find one (because it does not exist), but the socket for the correct port 5543 does exist according to sudo netstat -nlp:
5486/postgres /var/run/postgresql/.s.PGSQL.5543
postgresql.service is running according to systemctl status postgresql.service
Any constructive help is appreciated.
Why are you changing it in systemd and not using PostgreSQL's config file? Is that a CentOS thing?
Anyway - you can run the server on any port you like, or run multiple server instances of the same or different versions on a variety of ports. In that case though you need to tell psql what port to use.
You can set an environment variable (PGPORT), specify it with -p on the command-line or in a .psqlrc file. See the manuals for details.
Edit in response to comments:
If you want to set the PGPORT for psql, do it in the user's shell defaults or in /etc/bash... or equivalent. You could of course replace psql with an alias using your custom port or recompile the binary itself if you wanted.
I'm not sure this is really much use from a security perspective. It seems unlikely that someone can run local processes on your machine, has gained access to your postgres user password but isn't smart enough to see what port the server is running on.
I have successfully setup replication streaming from a primary to a secondary postgres docker container, each running as tasks on separate ec2 instances.
However, I did this by leaving the replication user on the primary server as trust in its pg_hba.conf:
host replication replication 0.0.0.0/0 trust
Then, when I switched it to md5, I thought I would be able to simply set a password on the secondary for the replication user and everything would be fine. Nope.
In my initialization script on the secondary, when I call
pg_basebackup -h #{primary_ip} -p 5432 -D $PGDATA -U #{repl_user} -v -P -w --xlog-method=stream
I initially got the password prompt.
Then I added the -w. Which would give me the error:
pg_basebackup: could not connect to server: fe_sendauth: no password supplied
Then I found out there is no postgres home directory on the generic postgres 9.6 image, so I added a $PG_PASSFILE variable. That didn't work (Permissions were fine, I even put it in /tmp as well as passed the PG_PASSFILE=... right on the pg_basebackup line as in this question: .pgpass for PostgreSQL replication in Dockerized environment (see Raphael's comment))
No matter what I do, the pg_basebackup ignores the .pg_pass file.
I then tried mounting a volume as /home/postgres but with AWS, I can't seem to gosu to root inside the entry point init script I have created. Everything is as the postgres user.
Has anybody overcome this?
I am running my secondary initialization code as an entrypoint script. Like I said, it works fine as trust but adding that password is killing me.
If you set replication you dont need to run pg_basebackup any more. adding -w will always give you fe_sendauth: no password supplied if you set anything but trust or peer for local to corresponding connection - just because -w stands for --no-password.
https://www.postgresql.org/docs/current/static/libpq-envars.html
PGPASSFILE specifies the name of the password file to use for lookups.
If not set, it defaults to ~/.pgpass (see Section 32.15).
so default is .pgpass, not .pg_pass, of course you can use .pg_pass, setting export PGPASSFILE=.pg_pass , but you use PG_PASSFILE variable - right?..
So postgres ignores it, and it should.
I would first try creating right .pgpass in home directory with 600 permissions.
Also mind different primary_conninfo if you want to use password file.
https://www.postgresql.org/docs/current/static/standby-settings.html
in a separate ~/.pgpass file on the standby server (use replication as
the database name). Do not specify a database name in the
primary_conninfo string.
Doing freelance, I keep on getting on new projets.
I find postgresql config highly complicated when being used in development mode only (I totally understand that production requirements are much different).
What I want to achieve is to config my postgres so that whatever username/password/port/connexion mode is used, it has all the rights on the DB (as security is no matter here). Working with Rails, all the config is in config/database.yml and I don't want to change anything from the file itself.
I achieved having any password_less authentication for every connexion (local and TCP), but doing this:
# /etc/postgresql/9.3/main/pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
local all all trust
host all all 0.0.0.0/0 trust
And:
# /etc/postgresql/9.3/main/postgresql.conf
listen_addresses = '*'
As from this Post.
But if the user (eg. appname_dev) doesn't exists, I get:
FATAL: role "appname_dev" does not exist
This Post allows me to create the user in 1 line, which is fair enough (sudo -u postgres createuser -d -R -P appname_dev), but I would really like this to be plug and play.
How can I achieve that?
Ain't there any development installation mode on postgres where by default, credentials would be much lighter configured that the current one?
Am I missing some best practice that make this not being a problem?
I understand the port thing can be tricky, but IMHO, the rest should not!
Thanks for the help!
You may achieve this by using pgbouncer (connection pooler) with following settings:
* = host=127.0.0.1 user=postgres
auth_type = any
so when you connect to pgbouncer with any user and any password it will connect to postgres as postgres user which has all permissions.
You may also want to change pgbouncer port to 5432 (by default it works on 6432 port) and change postgres port to something different so your application will connect to pgbouncer without any modifications in configs.
I've installed postgresql 9.2 on linux (kubuntu) and the last version of pgadmin3, but when I connect them I have this error:
An error has occurred:
Error connecting to the server: fe_sendauth: no password supplied
What can I do?
I have also configured tomcat for my web application in java. In fact, postgresql was working before trying my application.
Change the password for role postgres:
sudo -u postgres psql postgres
alter user postgres with password 'postgres';
Try connect using "postgres" for both username and password.
Refer to: How to change PostgreSQL user password
Whether a password is required depends on your settings in pg_hba.conf. And there are different ways you can connect - different settings in pg_hba.conf may apply.
I quote the help shipped with pgAdmin 3 for the "Host" field in the connection ("server") settings:
The host is the IP address of the machine to contact, or the fully
qualified domain name. On Unix based systems, the address field may be
left blank to use the default PostgreSQL Unix Domain Socket on the
local machine, or be set to an alternate path containing a PostgreSQL
socket. If a path is entered, it must begin with a “/”. The port
number may also be specified.
If you connect via Unix socket the rules for "local" apply.
Whereas when connecting via TCP/IP "host" (or "hostssl") rules applies.
If you have a line like this at the top your pg_hba.conf file:
local all all peer
or:
local all all ident
.. then you can connect locally without password if your system user is "postgres" and your database user is "postgres", too.
I realize this is question is years old, but I ran into this same problem today and have a solution that uses trust in a limited but useful way.
As in many development shops, when the devs need a QA postgres password, they just yell it, message it, email it, write it on their foreheads, etc. And I'm like, "This is really bad. I need to figure out a way to use PKI here." We also use pgAdmin3.
First, add a line like this to your pg_hba.conf, where dev represents the user for the developers in your shop:
host all dev 127.0.0.1/32 trust
Drop the developers' public key in their authorized_keys folder on the database server. Now have them ssh into the server with the -L flag with a command similar to the following:
ssh -i ~/.ssh/id_rsa -L5432:127.0.0.1:5432 -vvv 101.102.103.104
This allows one to use the postgres port as if it were localhost. Of course, replace the key, server and make sure to map to an open port locally (if you have a local postgres running, it's probably bound to 5432). I use a pretty verbose flag so I can easily troubleshoot any ssh issues.
Open another terminal and issue this command:
psql -h 127.0.0.1 -U dev -p 5432
You should have access to the database and never be prompted for a password, which I think is great because otherwise, the devs will just waive the password around with little regard to security, passing it out like Halloween candy.
As of now, PgAdmin3 will still prompt you for a password, even though -- plain as day -- you do not need it. But other postgres GUIs will not. Try Postico. It's in beta but works great.
I hope this answer helps anyone like me who would rather use PKI for postgres auth rather than sharing passwords willy-nilly.
Met this problem recently.
If you're using PostgreSQL on local machine, and psql works well without logging needed, try pgadmin3's menu File - Add Server - Properties tab, fill in Name field for this connection, leave Host field and Password field empty, and click ok.
from pgadmin docs
On Unix based systems, the address field may be left blank to use the
default PostgreSQL Unix Domain Socket on the local machine, or be set
to an alternate path containing a PostgreSQL socket. If a path is
entered, it must begin with a “/”.
Worked on Debian testing (pgadmin3 1.22, PostgreSQL 11), without touching pg_hba.conf.
For me, I run pg_ctl -D /usr/local/var/postgres start, start the server, then everything is OK, it will pop out the connection host port.