Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Postgres not recognizing the user #1678

Closed
sconetto opened this issue Jun 7, 2018 · 24 comments
Closed

Postgres not recognizing the user #1678

sconetto opened this issue Jun 7, 2018 · 24 comments

Comments

@sconetto
Copy link

sconetto commented Jun 7, 2018

What happened?

On the production environment the postgre container can't connect to the DB saying that the user that is configured in the .env file can't connect to the DB

Some log:

postgres_1      | 2018-06-07 19:11:22.906 UTC [80] FATAL:  password authentication failed for user "drdown"
postgres_1      | 2018-06-07 19:11:22.906 UTC [80] DETAIL:  Password does not match for user "drdown".
postgres_1      | 	Connection matched pg_hba.conf line 95: "host all all all md5"
postgres_1      | 2018-06-07 19:11:23.963 UTC [81] FATAL:  password authentication failed for user "drdown"
postgres_1      | 2018-06-07 19:11:23.963 UTC [81] DETAIL:  Password does not match for user "drdown".
postgres_1      | 	Connection matched pg_hba.conf line 95: "host all all all md5"

What should've happened instead?

Connect to the DB and run the application

Steps to reproduce

Don't know to reproduce and don't which files can help figure this out (new on this)

Host system configuration:

uname -a
Linux ubuntu-drdown 4.4.0-127-generic #153-Ubuntu SMP Sat May 19 10:58:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.4 LTS
Release:	16.04
Codename:	xenial
docker --version
Docker version 18.03.1-ce, build 9ee9f40
docker-compose --version
docker-compose version 1.21.0, build 5920eb0

p.s.: apologizes for my english, I'm actually Brazilian.

@sconetto
Copy link
Author

sconetto commented Jun 7, 2018

If I run the command docker-compose -f production.yml exec postgres psql -d <db_name> -U <db_user> with the db and the user that are on my env file it connects without issues.

Edit: Also tried change the user password in the DB that the user must have access
ALTER USER drdown WITH PASSWORD '<the password equal env file>'; and when try to connect:
django.db.utils.OperationalError: FATAL: password authentication failed for user "drdown"

@emilepetrone
Copy link
Contributor

Are you running the eval command first? I had something similar, and I only solved it after realizing I need to run eval... each time I open a terminal.

@sconetto
Copy link
Author

sconetto commented Jun 9, 2018

@emilepetrone eval what? mind helping me out?

@emilepetrone
Copy link
Contributor

https://cookiecutter-django.readthedocs.io/en/latest/developing-locally-docker.html?highlight=Eval

eval "$(docker-machine env <name of machine>)"

This way you are sending commands to the right machine.

@sconetto
Copy link
Author

@emilepetrone I don't have docker-machine installed, it would make a difference if I install and try to use the eval?

@sconetto
Copy link
Author

I've tried to alter the user password on all of the databases, still getting the same error.

@emilepetrone
Copy link
Contributor

@sconetto The issue is most likely that you think you are working with your production machine - but actually are working with the production settings locally (at least that is what I did). To work with your production machine you need to run:

eval "$(docker-machine env <name of machine>)"

https://cookiecutter-django.readthedocs.io/en/latest/developing-locally-docker.html?highlight=eval#activate-a-docker-machine

@sconetto
Copy link
Author

@emilepetrone what is strange to me is that I don't configured any docker-machine on my host, I just configured the .env files and built the containers with production.yml, after a series of errors (mostly about the mailgun domain) now I'm getting this error on the postgre container, I know that the user I configured on the .env file isn't the one created at the bootstrap of the project (I have some hardware issues and lost this initial user) but I need this running, any idea how can I go from here? create I docker-machine?

@browniebroke
Copy link
Member

This issue might be related: docker-library/postgres#203

@sconetto
Copy link
Author

sconetto commented Jun 21, 2018

I've tried to change my DB_NAME to be the same as my DB_USER, now when I run docker-compose -f production.yml exec postgres psql -U <db_user> it didn't ask me the password and I don't get any errors but with the application running still getting:

postgres_1      | 2018-06-21T17:05:20.394067049Z 2018-06-21 17:05:20.393 UTC [164] FATAL:  password authentication failed for user "drdown"
postgres_1      | 2018-06-21T17:05:20.394205209Z 2018-06-21 17:05:20.393 UTC [164] DETAIL:  Password does not match for user "drdown".
postgres_1      | 2018-06-21T17:05:20.405545257Z 	Connection matched pg_hba.conf line 95: "host all all all md5"
postgres_1      | 2018-06-21T17:05:21.658483913Z 2018-06-21 17:05:21.658 UTC [165] FATAL:  password authentication failed for user "drdown"
postgres_1      | 2018-06-21T17:05:21.658531473Z 2018-06-21 17:05:21.658 UTC [165] DETAIL:  Password does not match for user "drdown".
postgres_1      | 2018-06-21T17:05:21.658538458Z 	Connection matched pg_hba.conf line 95: "host all all all md5"

any workaround guys? I need to deliver the project next week 😞

Edit 1: I've tried now to add the environment variables into the production.yml and then recreate the containers, same error 😢

@demestav
Copy link
Contributor

demestav commented Jul 10, 2018

@sconetto Is it possible that you generate the project more than once? In this scenario you get the error that you mention in your first post here. Here is what happens:

  1. You generate the project the first time. The .env postgres file is populated with the random password
  2. You run the docker-compose and the containers are created. The postgres container creates the database based on the .env file credentials
  3. You "regenerate" the project with the same name, so the postgres .env file is populated with a new random password
  4. You run docker-compose. Since the names of the containers are the same, docker will try to start them (not create them from scratch i.e. it won't execute the Dockerfile to recreate the database). When this happens, it tries to start the database based on the new credentials which do not match the ones that the database was created with, and you get the error message mentioned in your first post.

If that is the case, and your object is to start a fresh production environment then you can delete the postgres volume.

@sconetto
Copy link
Author

@demestav That was not the case, I've only generated the project one time, when I was configuring I removed all the volumes and containers, so for me, I think, this shouldn't happen, still having the issue but now the project is on a pause.

Although thank you for trying to help!

@kwkelly
Copy link

kwkelly commented Feb 8, 2019

@demestav That's my issue, but killing all docker containers and deleting all images didn't fix it.

Edit: Had to delete the docker volumes

docker volume ls to find them then docker volume rm {{project_name}}_local_postgres_data and docker volume rm {{project_name}}_local_postgres_data_backups

@browniebroke
Copy link
Member

I think a lot of people (my past self included) are hitting this issue because of a gotcha of how Docker works and cache resources. It's not obvious that if you re-generate the same project from scratch with the same name, Docker will re-use pre-existing resources, it took me some deeper understanding of Docker to get that.

Because of the nature of this project, I think it's expected to be used by people with little experience with Docker. We could add some documentation or link to external docs regarding how Docker caching may have cross-projects side effects. It's pretty common for people to generate the same project multiple times when they realise they messed up something and want to start over...

What do folks think of a disclaimer at the top of the Docker documentation?

PS: if you want to clear your ENTIRE Docker cache/volumes/networks, you can do so with docker system prune -a --volumes --force. Be careful, that drops EVERYTHING. Don't do it on Prod!

@sconetto
Copy link
Author

sconetto commented Feb 8, 2019

@browniebroke This project I was working on is now over, but I think you may be right, the nature of cookie cutter is to help people with little, maybe none, experience with Docker or Django, to get started.
And I can't agree more with you when you said that people generate the same project multiple times. If I recall this project was generated two times because of a problem with some machines on my team.

So, at least, I'm on board with the disclaimer to aim this issue and help people!

@demestav
Copy link
Contributor

demestav commented Feb 8, 2019

@browniebroke Yes I also agree with the addition of a disclaimer. On a related note, I was thinking that having few shortcut commands about docker, could benefit both new and experienced docker users. For example, docker-compose -f local.yml run --rm django makemigrations or ... createsuperuser or ... shell_plus etc. Same with this issue, we could have a command /docker_commands/clear.sh that would run docker-compose -f local.yml down --volumes --rmi that would allow you to start you project over by deleting the volumes, containers, images and network of the existing project.

@svleeuwen
Copy link
Contributor

svleeuwen commented Apr 11, 2019

@demestav That's my issue, but killing all docker containers and deleting all images didn't fix it.

Edit: Had to delete the docker volumes

docker volume ls to find them then docker volume rm {{project_name}}_local_postgres_data and docker volume rm {{project_name}}_local_postgres_data_backups

Where did your {{project_name}} come from in the volumes?
When I look at local.yaml it only states local_postgres_data_backups as volume.

I actually need to include the project name because I have this issue when running multiple projects.

EDIT: nvm, this is of course done through docker-compose -p [project-name]

Still, if one forgets to add the -p flag, you will end up with postgres volumes named postgres_data_local getting reused. Which causes this issue.

Maybe add a {{cookiecutter.project_slug}}_ prefix to those volumes?

@kwkelly
Copy link

kwkelly commented Apr 18, 2019

@svleeuwen it looks docker-compose should default to using the directory name for that option, which I believe is the case for me.

Docker forum thread on automatic prepending: https://forums.docker.com/t/docker-compose-prepends-directory-name-to-named-volumes/32835/7

@olivrg
Copy link

olivrg commented Mar 6, 2020

I experienced this issue after destroying a project and creating a new one with the same name and DB name at a later date. @demestav's comment from 2018 - #1678 (comment) is correct. Docker will use the same container from the previous project.
Here's how I solved the issue:

  1. List your existing containers with this command: docker container ls -a
  2. Chances are that the containers in question will have their status set to Exited
  3. So I removed all of those containers with this command: docker container prune
  4. Lastly, recreate the container with the appropriate command: docker-compose ...

@vladox
Copy link

vladox commented Aug 4, 2020

I can confirm the solution is to run: docker container prune

@shanth929
Copy link

hi,

Faced the same issue you need to recreate your existing docker network and try it once, hope it helps.

@MBARIMike
Copy link

I appreciate this thread. My scenario was a bit different. I had first brought up the containers using local.yml, shut them down, then brought up the containers using production.yml. Deleting the production volumes fixed my problem: docker volume rm {{project_name}}_production_postgres_data and docker volume rm {{project_name}}_production_postgres_data_backups.

@BloodyIron
Copy link

Not sure if it is precisely relevant to this scenario, but I've had a test environment where the password for a user got corrupted. After extensive testing I had to change the password in the postgresql database for the user to something else "adsf" or whatever, and then back to desired password. It worked, did not have to delete/recreate volumes at all.

I was pulling the whole thing from a public helm chart, so I wasn't actually making the images myself.

@WassimAbida
Copy link

I had the same issue with user being un-recognized, I managed to log in to the DB using

psql -U <POSTGRES_USER> <POSTGRES_DB> when in the postgres container !

Values are to find in ./.envs/.local/.postgres

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests