Cookiecutter-django: Postgres not recognizing the user

[sconetto]

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



md5-e3a4f71ff6443692a33fb1f936328d60



docker-compose --version
docker-compose version 1.21.0, build 5920eb0

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

[sconetto]

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]

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]

@emilepetrone eval what? mind helping me out?

[emilepetrone]

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]

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

[sconetto]

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

[emilepetrone]

@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]

@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]

This issue might be related: https://github.com/docker-library/postgres/issues/203

[sconetto]

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 :disappointed:

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

[demestav]

@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]

@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]

@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]

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]

@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]

@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]

@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]

@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]

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 - https://github.com/pydanny/cookiecutter-django/issues/1678#issuecomment-403751269- 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]

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