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.
Related
Is it possible to stop postgres instance just by the port number?
I have a pgsql running on port 5433 and when I try to run:
/usr/pgsql-10/bin/pg_ctl -D /var/lib/pgsql/new_cluster/data stop
This will work when I specify the -D, but let's say I don't know where the $PGDATA is and all I know is the port number this instance running on, is it possible to stop it?
/usr/pgsql-10/bin/pg_ctl -p 5433 stop
running this command result in:
waiting for server to shut down.... done
server stopped
but when I try to enter this instance by psql -p 5433 I still can get in.
*I know it might be possible doing this with systemctl but I need doing this without root permissions.
I try to do this because: I made a pg_basebackup and I want to stop the real database and run the one I just created by the pg_basebackup on the same port. just to verify that the backup is ok.
-p is not the port number in pg_ctl. The documentation says:
-p path
Specifies the location of the postgres executable. By default the postgres executable is taken from the same directory as pg_ctl, or failing that, the hard-wired installation directory. It is not necessary to use this option unless you are doing something unusual and get errors that the postgres executable was not found.
So that does nothing for pg_ctl stop, since that finds the process ID from postmaster.pid. You stopped the cluster that the environment variable PGDATA pointed to.
If you want to stop PostgreSQL by port number, connect as superuser (or a member of the pg_read_all_settings role) and run
SHOW config_file;
Then strip postgresql.conf from the output, and you have the argument to use with -D. That can easily be scripted.
Have not been able to find an answer to this yet, but if this a duplicate, please mark accordingly!
Trying to understand how PostgreSQL can be distributed to an end-user via silent installation and the respective actions if:
PostgreSQL is already installed on the computer system
How to connect to PostgreSQL as a superuser, if it is already installed
Create a database (relating to #2, since we would not know the credentials of postgresql user when PostgreSQL was initially installed)
For #1, from my research and understanding, there are two methods:
Determining if a postgresql-[version] service is installed (per this QA)
Determining if HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\ registry exists, and if it does, seeing the versions and service names under the \Installations\ and \Services\ subs
However, I am more concerned about the connectivity part. If my application (to be written in C#) is dependent on a database name "MyProgram," how would it be possible to create a database in PostgreSQL and with what credentials?
From my understanding, the way to go would be to attempt to log in as the default superuser, postgres, to the default database, postgres, and create a new user and database from that connection. But, the password for postgres user is set during by the user/program that is initially is installing PostgreSQL.
How to go about this?
Any help is much appreciated!
IMPORTANT NOTE: This may not be the most ethical/proper way of doing this, but it appears to get the job done.
After numerous hours of digging, using the registry key on Windows is the best methodology, it seems, to determine if the version of PostgreSQL you intend to install, if it is already installed.
Assuming that I am running on the Windows system with Administrative rights, in theory, I should be able to change the login credential requirements of the pg_hba.conf file in the data directory (i.e. cluster) that already exists to allow myself to create the database(s) and user(s) I need to, before reverting the credential requirement settings to what they originally were.
So, the answer I have come to the conclusion with is:
Determine if PostgreSQL is already installed or not. Look at the HKEY_LOCAL_MACHINE\SOFTWARE\PostgreSQL\Installation\[version] registry, where [version] is formatted as postgresql-[32 or 64 bit]-[PostgreSQL version], e.g. postgresql-x64-12). If the registry exists, then data should exist for the Data Directory value... obtain that data, and that's where the cluster is located.
Step [2] and on are obviously for when PostgreSQL is already installed.
Make a copy of the pg_hba.conf file in the cluster directory provided by the Data Directory value from step [1].
This will be the file we restore to after we are done. Save file to a temporary directory, such as Desktop.
In the pg_hba.conf file in the cluster directory, change all connection types' methods to trust
Example:
# TYPE DATABASE USER ADDRESS METHOD
host all all 127.0.0.1/32 trust
Restart Postgres' Windows service with the following command: pg_ctl.exe restart -D <cluster directory>
NOTE: pg_ctl.exe is located under the \bin\ folder of Postgres' installation directory.
Example: C:\Program Files\PostgreSQL\12\bin\pg_ctl.exe restart -D "C:\Program Files\PostgreSQL\12\data\"
Connect to the cluster and issue the command to create a superuser role for your needs with the following command: psql -h 127.0.0.1 -p 5432 -d postgres -c "CREATE ROLE <role name> LOGIN SUPERUSER PASSWORD '<password>';
In the above command, I have the cluster running on the local computer (i.e. localhost, IP address 127.0.0.1) on port # 5432 (default), connecting to the default database postgres and issuing the command to create a role with whatever role name provided in place of <role name>, with SUPERUSER rights and the password provided in place of <password>.
Since one HAS to connect to a database, I am connecting to the default one postgres, otherwise template0 and template1 are default databases that could also be utilized.
Connect to the cluster and issue the command to create the needed database for your needs with the following command: psql -h 127.0.0.1 -p 5432 -d postgres -c "CREATE DATABASE <database name>;
Replace the pg_hba.conf file with the original
Restart Postgres' Windows service with the following command: pg_ctl.exe restart -D <cluster directory>
I recently installed Postgresql 11, during the installation, there's no step to put password and username for Postgres. Now in pgAdmin 4, I wanted to connect the database to server and it's asking me to input password, and I haven't put any in the first place.
Any one knows what's going on. Thank you!
The default authentication mode for PostgreSQL is set to ident.
You can access your pgpass.conf via pgAdmin -> Files -> open pgpass.conf
That will give you the path of pgpass.conf at the bottom of the window (official documentation).
After knowing the location, you can open this file and edit it to your liking.
If that doesn't work, you can:
Find your pg_hba.conf, usually located under C:\Program Files\PostgreSQL\9.1\data\pg_hba.conf
If necessary, set the permissions on it so that you can modify it. Your user account might not be able to do so until you use the security tab in the properties dialog to give yourself that right by using an admin override.
Alternately, find notepad or notepad++ in your start menu, right click, choose "Run as administrator", then use File->Open to open pg_hba.conf that way.
Edit it to set the "host" line for user "postgres" on host "127.0.0.1/32" to "trust". You can add the line if it isn't there; just insert host all postgres 127.0.0.1/32 trust before any other lines. (You can ignore comments, lines beginning with #).
Restart the PostgreSQL service from the Services control panel (start->run->services.msc)
Connect using psql or pgAdmin4 or whatever you prefer
Run ALTER USER postgres PASSWORD 'fooBarEatsBarFoodBareFoot'
Remove the line you added to pg_hba.conf or change it back
Restart PostgreSQL again to bring the changes to effect.
Here is an example of the pg_hba.conf file (METHOD is already set to trust):
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
NOTE: Remember to change the METHOD back to md5 or other auth-methods listed here after changing your password (as stated above).
For Windows variant - I too experienced this nasty bug because of pgAdmin for my Windows x64 install of version 9.2. It left my production paralyzed.
In folder C:\Program Files\PostgreSQL\9.2\data or C:\Program Files (x86)\PostgreSQL\9.x\data, you'll find the pg_hba.conf text file.
Find the following lines:
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
and change METHOD md5 to "trust" like this:
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
From Windows>Run type "services.msc" and enter find the right PostgreSQL instance and restart it.
Your DB security is now blown wide open! Heed the warning to return it back to md5 after changing the user password expiry time to say year 2099 for all the relevant users.
Change the password of default use
ALTER USER postgres WITH PASSWORD 'new_password';
Note: CREATE USER is the same as CREATE ROLE except that it implies LOGIN.
$ psql postgres
postgres=# create user postgres with superuser password 'postgres';
After successfully changing the master password
If you get the same error even after following the master password reset steps
Open your command prompt and execute
psql -U postgres
It will ask you for the password, enter the new password which you set now parallelly open SQL shell(psql) and try again with the new password
I have tried all the above mentioned solutions, trust me northing worked! I have resolved the issue by using following commands
psql -U default
\password
Enter new password:
Enter it again:
my username is : default
This worked perfectly for me.
For Linux user try this
//CHECK POSTGRES IS WORKING OR NOT
sudo systemctl status postgresql
//THIS WILL ACCEPT PORTS
sudo pg_isready
sudo su postgres
//NAVIGATE TO SQL TERMINAL / BASH
psql
//CREATE A NEW USER WITH PASSWORD
CREATE USER shayon WITH PASSWORD 'shayon';
try using psql -U postgres if have put password while installing this is command where you have to use that. Thank you :)
Option 1: If you use trust
Better change only postgres to trust in the pg_hba.conf, then access your db with postgres super user and add other users and passwords with the power of the postgres super user, then change all other peer to md5.
The steps: In the pg_hba.conf, change
local postgres to trust
do not change local all to trust,
instead change local all from peer to md5 - which means that a right password is enough to login.
See this solution in detail at the second answer of 'Getting error: Peer authentication failed for user "postgres", when trying to get pgsql working with rails'.
Option 2: Use md5, no trust needed (recommended)
This way is even easier because you will need to change the pg_hba.conf only once:
Change any local user from peer to md5, usually:
Change local postgres from peer to md5
Change local all from peer to md5
Add a postgres pw with the power of your Linux pw only:
sudo su postgres
psql (or psql -p <port> if you have more than one PostgreSQL)
\password
\q
See the accepted answer and the comments of "Getting error: Peer authentication failed for user "postgres", when trying to get pgsql working with rails".
I solved this problem by changing peer to trust in the file "pg_hba.conf" at local postgres then I restarted the postgres service with the command:
sudo service postgresql restart
That's it.
This particular situation I'm about to mention probably doesn't come up very often, but I was getting this error as well. After looking into it, it was because I had a local postgres instance listening on port 5433, and I was trying to set up a Kubernetes tunnel to a remote PG instance mapped to local port 5433 as well. It turns out the command I was running was attempting to connect to the local instance rather than the remote instance. When I temporarily stopped the local instance, I was able to connect to the remote instance through the tunnel without changing the psql command I was using.
I know this is an old question, but I had the same problem, e.g. no dialog for setting password for Postgres during installation with Postgresql 11.
Instead of doing all the file manipulations suggested in the other answers, I deleted Postgresql 11 and installed Postgresql 12, where I was prompted for setting password during installation.
Loggin to PgAdmin4
Go to
Object > Create > Login/Group Role
Create the "username" that was named in the psql terminal
Create password
Give it all the rights
Save
try the password immediately in the psql terminal.
It worked for me.
Hope this works for you.
You can use the "superuser" password for the first time.
After that you can use Object > Create > Login/Group Role to change the password for the "postgres" user.
I currently had a headhache solving this case. A friend helped me I decided to post my solution here.
Open pg_hba.conf in any text editor (you can find this file in your postgres instalation folder > data);
Change all the methods fields to trust (meaning you don't need a password for postgre);
Run in your console this comand: "alter user postgres with password '[my password]';" | psql -U postgres (meaning to alter some user password for [my password] for the user as parameter -U postgres);
Et voilà (don't forget to change back the method from trust for the one that should be best for you).
I hope this help someone someday.
For those of you who got this error and NONE of these answers helped, I may not have StackOverflow fish for you, but I'll teach you how to fish!
You likely don't have the correct order of lines in the pg_hba.conf file. If you read this PostgreSQL documentation link below, it says this error can be thrown if "no matching entry is found". However, that is NOT always true! Documentation is written by humans and humans make mistakes.
https://www.postgresql.org/docs/current/client-authentication-problems.html
The truth is that a line further up might take precedence, is qualifying and is forcing you to use a password stored in PostgreSQL rather than delegated authentication or some other method. If you are not specifying a password stored in PostgreSQL, then you do not need the LOGIN role attribute. Put a line at the very top of this list with your specific user, authentication protocol, network details and other criteria. Also, many may think that most computers use IPv4. Try IPv6 and you'll be surprised. Once you know the very specific criteria of your issue and place a line at the top, then you have established the ONLY RELIABLE WAY to troubleshoot these pg_hba.conf issues without source code debugging!
Another helpful trick is to create a crapload of Server entries in pg_admin (SQL IDE for PostgreSQL) with all of your users and authentication protocols for testing. When you test different scenarios, you'll instantly know which ones fail.
Also, whenever you change this file, restart the PostgreSQL service, before testing the user.
You're welcome my friend. :)
Follow below stepsif you are using pgAdmin4 and facing error in updating password :
1] Open file "pg_hba.conf" and find "IPv4 local connections"
2] See the value under "Method" column, it must be set to "md5" becase you selected it while installing.
3] Make "md5" value blank and save the file. Restart pgAdmin4 application.
4] Now again set the value back to "md5" and input your password in pgAdmin application.
You should be successfully able to do it.
windown 11 - postgres 14
open pgAdmin4 - click servers
right-click on your windows user name rule, e.g: MyUserName.
definition tab - enter password, click save.
open/re-open terminal
run: psql "postgres:///"
if you get "MyName database doesn't exist" you're good to go
I use Ubuntu 14.10 and installed PostgreSQL 9.2 from PostgreSQL official apt repository. (apt.postgresql.org)
When I switched user postgres and try following command, I can successfully login.
$ psql -U postgres dbname -W
Password for user postgres: (Enter Password)
psql (9.2.9)
Type "help" for help.
dbname=#
However, when I specify host value, I cannot login with following error.
$ psql -h localhost -U postgres notel -W
Password for user postgres:
psql: FATAL: password authentication failed for user "postgres"
FATAL: password authentication failed for user "postgres"
I'm trying to connect from Sequelize.js, an ORM for node.js, but I experienced almost the same error message:
Possibly unhandled Error: error: password authentication failed for user "postgres"
Does anyone know how I can solve this problem?
Edit
My pg_hba.conf is as follows:
local all postgres peer
local all all peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
I refered document about pg_hba.conf, but I don't know what's wrong...
Most likely this has to do with the client authentication file: pg_hba.conf.
It holds entries for each host/socket/user/password/database combination.
When you change your host to localhost, you have a different access route than when you connect directly over a Unix socket. You will patch yourself through TCP/IP instead of going "directly". If you open your pg_hba.conf file, you will find a bunch of rules at the end. These rules define which combinations are allowed to access the database.
In your case, look for lines that start with host, which means access through TCP/IP (and thus localhost) as opposed to local which means a Unix socket.
Probably there is a line tucked in there which prevents host connection access, or not via the credentials you think are correct (peer/md5 pitfall, read below).
As you show in your pg_hba.conf file you have local entries with peer authentication and host entries with md5 authentication. If you don't know the difference between the two authentication mechanisms, then that is your culprit at the moment and can cause some serious head-banging (not the Metal kind; the Against-a-wall kind).
Common pitfall
To avoid possible confusion, the difference between peer and md5 is ground for a common pitfall. They both use a user called postgres (when using -U postgres, that is), but the former is actual a Unix user created during installment of your PostgreSQL system, the latter is a database user created inside your PostgreSQL bookkeeping tables.
Always remember, if your setting is peer, use the credentials of the Unix user, if it is md5 use the credentials of the database user.
If no password has been set for the database user postgres, make sure you set one first. Empty passwords are not allowed either.
Extra notes
Always try to make your rules specific, avoid too many all entries for databases and users as this could put your installation wide open.
The first line that fits your access combination will be picked and any subsequent lines will be ignored. Make sure that there is no higher line that overwrites your rule.
Remember to restart your PostgreSQL daemon after changing this file, otherwise the changes won't be picked up.
If you want to do a secure "localhost" login with $ psql -U username dbname -h localhost -W
You need to make sure the user has been setup with an encrypted password and also setup your "pg_hba.conf" correctly to be "samehost".
1.) Create a Secure Login: "$ psql dbname"
ALTER USER username with encrypted password 'your_password';
2.) Modify "pg_hba.conf" as your main "postgres" user
# IPv4 local connections:
host all all samehost md5
3.) Restart your PostgreSQL server
service postgresql restart
If you have any other problems read your PostgreSQL log carefully at "/var/lib/pgsql/data/pg_log/*.log"
sudo nano /etc/postgresql/12/main/postgresql.conf
and set listening address: localhost
sudo nano /etc/postgresql/12/main/pg_hba.conf
IPv4 local connections:
host all all localhost md5
when i create a new user, but it cannot login the database.
I do that like this:
postgres#Aspire:/home/XXX$ createuser dev
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) y
then create a database:
postgres#Aspire:/home/XXX$ createdb -O dev test_development
after that, I try psql -U dev -W test_development to login, but get the error:
psql: FATAL: Peer authentication failed for user "dev"
I tried to solve the problem but failed.
Try:
psql -U user_name -h 127.0.0.1 -d db_name
where
-U is the database user name
-h is the hostname/IP of the local server, thus avoiding Unix domain sockets
-d is the database name to connect to
This is then evaluated as a "network" connection by Postgresql rather than a Unix domain socket connection, thus not evaluated as a "local" connect as you might see in pg_hba.conf:
local all all peer
Your connection failed because by default psql connects over UNIX sockets using peer authentication, that requires the current UNIX user to have the same user name as psql. So you will have to create the UNIX user dev and then login as dev or use sudo -u dev psql test_development for accessing the database (and psql should not ask for a password).
If you cannot or do not want to create the UNIX user, like if you just want to connect to your database for ad hoc queries, forcing a socket connection using psql --host=localhost --dbname=test_development --username=dev (as pointed out by #meyerson answer) will solve your immediate problem.
But if you intend to force password authentication over Unix sockets instead of the peer method, try changing the following pg_hba.conf* line:
from
# TYPE DATABASE USER ADDRESS METHOD
local all all peer
to
# TYPE DATABASE USER ADDRESS METHOD
local all all md5
peer means it will trust the identity (authenticity) of UNIX user. So not asking for a password.
md5 means it will always ask for a password, and validate it after hashing with MD5.
You can, of course, also create more specific rules for a specific database or user, with some users having peer and others requiring passwords.
After changing pg_hba.conf if PostgreSQL is running you'll need to make it re-read the configuration by reloading (pg_ctl reload) or restarting (sudo service postgresql restart).
* The file pg_hba.conf will most likely be at /etc/postgresql/9.x/main/pg_hba.conf
Edited: Remarks from #Chloe, #JavierEH, #Jonas Eicher, #fccoelho, #Joanis, #Uphill_What comments incorporated into answer.
Peer authentication means that postgres asks the operating system for your login name and uses this for authentication. To login as user "dev" using peer authentication on postgres, you must also be the user "dev" on the operating system.
You can find details to the authentication methods in the Postgresql documentation.
Hint: If no authentication method works anymore, disconnect the server from the network and use method "trust" for "localhost" (and double check that your server is not reachable through the network while method "trust" is enabled).
When you specify:
psql -U user
it connects via UNIX Socket, which by default uses peer authentication, unless specified in pg_hba.conf otherwise.
You can specify:
host database user 127.0.0.1/32 md5
host database user ::1/128 md5
to get TCP/IP connection on loopback interface (both IPv4 and IPv6) for specified database and user.
After changes you have to restart postgres or reload it's configuration.
Restart that should work in modern RHEL/Debian based distros:
service postgresql restart
Reload should work in following way:
pg_ctl reload
but the command may differ depending of PATH configuration - you may have to specify absolute path, which may be different, depending on way the postgres was installed.
Then you can use:
psql -h localhost -U user -d database
to login with that user to specified database over TCP/IP.
md5 stands for encrypted password, while you can also specify password for plain text passwords during authorisation. These 2 options shouldn't be of a great matter as long as database server is only locally accessible, with no network access.
Important note:
Definition order in pg_hba.conf matters - rules are read from top to bottom, like iptables, so you probably want to add proposed rules above the rule:
host all all 127.0.0.1/32 ident
While #flaviodesousa's answer would work, it also makes it mandatory for all users (everyone else) to enter a password.
Sometime it makes sense to keep peer authentication for everyone else, but make an exception for a service user. In that case you would want to add a line to the pg_hba.conf that looks like:
local all some_batch_user md5
I would recommend that you add this line right below the commented header line:
# TYPE DATABASE USER ADDRESS METHOD
local all some_batch_user md5
You will need to restart PostgreSQL using
sudo service postgresql restart
If you're using 9.3, your pg_hba.conf would most likely be:
/etc/postgresql/9.3/main/pg_hba.conf
This works for me when I run into it:
sudo -u username psql
I simply had to add -h localhost
The easiest solution:
CREATE USER dev WITH PASSWORD 'dev';
CREATE DATABASE test_development;
GRANT ALL PRIVILEGES ON DATABASE test_development to dev;
ALTER ROLE dev CREATEROLE CREATEDB;
In my case I was using different port. Default is 5432. I was using 5433. This worked for me:
$ psql -f update_table.sql -d db_name -U db_user_name -h 127.0.0.1 -p 5433
For people in the future seeing this, postgres is in the /usr/lib/postgresql/10/bin on my Ubuntu server.
I added it to the PATH in my .bashrc file, and add this line at the end
PATH=$PATH:/usr/lib/postgresql/10/bin
then on the command line
$> source ./.bashrc
I refreshed my bash environment. Now I can use postgres -D /wherever from any directory
pg_dump -h localhost -U postgres -F c -b -v -f mydb.backup mydb
Try in terminal:
>> psql -U role_name -d database -h hostname.<domain>.com -W