Recent versions seems to have broken auth when POSTGRES_PASSWORD is set

[dpnova]

I've tried 9.6 and 9.5 and alpine variants too.

Getting rid of the POSTGRES_PASSWORD fixes it so I'm generally ok, but this could trip other people up too... looks like it might be the issue at: MagicStack/asyncpg#158

compose:

        postgres_sx:
                image: postgres
                environment:
                  - POSTGRES_PASSWORD=postgres

postgres_sx_1  | FATAL:  password authentication failed for user "postgres"
postgres_sx_1  | DETAIL:  Connection matched pg_hba.conf line 95: "host all all all md5"
postgres_sx_1  | FATAL:  password authentication failed for user "postgres"
postgres_sx_1  | DETAIL:  Connection matched pg_hba.conf line 95: "host all all all md5"
postgres_sx_1  | FATAL:  password authentication failed for user "postgres"
postgres_sx_1  | DETAIL:  Connection matched pg_hba.conf line 95: "host all all all md5"
services_sx_1  | { error: password authentication failed for user "postgres"
services_sx_1  |     at Connection.parseE (/app/services/sx/node_modules/pg-promise/node_modules/pg/lib/connection.js:539:11)
services_sx_1  |     at Connection.parseMessage (/app/services/sx/node_modules/pg-promise/node_modules/pg/lib/connection.js:366:17)
services_sx_1  |     at Socket.<anonymous> (/app/services/sx/node_modules/pg-promise/node_modules/pg/lib/connection.js:105:22)
services_sx_1  |     at emitOne (events.js:115:13)
services_sx_1  |     at Socket.emit (events.js:210:7)
services_sx_1  |     at addChunk (_stream_readable.js:250:12)
services_sx_1  |     at readableAddChunk (_stream_readable.js:237:11)
services_sx_1  |     at Socket.Readable.push (_stream_readable.js:195:10)
services_sx_1  |     at TCP.onread (net.js:586:20)

[yosifkit]

Could be related to #203 (comment).

[vitaly-t]

@dpnova which version of pg-promise are you using? One of 5.x? Try 6.x, and if the problem is still there, it means the issue isn't with the driver, but elsewhere.

[dpnova]

@yosifkit I had removed the volumes between each test

@vitaly-t it seems the libs I'm using pull in 5.x. I can try 6.. thanks.

In general it just seems odd that this started happening after I removed my local postgres images and pulled in the same postgres version but latest dockerhub image..

[vitaly-t]

In general it just seems odd that this started happening after I removed my local postgres images and pulled in the same postgres version but latest dockerhub image..

In this case it is very unlikely that swapping the driver will make any difference. But you can still try.

[yosifkit]

The Postgres image itself works fine:

$ docker pull postgres:9.6
...
Digest: sha256:e92fe21f695d27be7050284229a1c8c63ac10d88cba58d779c243566e125aa34
$ docker run -d -e POSTGRES_PASSWORD=12345 --name=posty postgres:9.6
$ docker logs --tail=6 posty
PostgreSQL init process complete; ready for start up.

LOG:  database system was shut down at 2017-07-07 20:32:23 UTC
LOG:  MultiXact member wraparound protections are now enabled
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections
$ docker run -it --rm --link posty:postgres postgres:9.6 psql -h postgres -U postgres
Password for user postgres: 
psql (9.6.3)
Type "help" for help.

postgres=# 

Can you connect to your postgres container via psql?

[dpnova]

It works fine without POSTGRES_PASSWORD set in docker compose env. For some reason that's when it breaks. I'll try repro with regular docker.

…

On Sat, 8 Jul. 2017, 6:47 am yosifkit, ***@***.***> wrote: The Postgres image itself works fine: $ docker pull postgres:9.6...Digest: sha256:e92fe21f695d27be7050284229a1c8c63ac10d88cba58d779c243566e125aa34 $ docker run -d -e POSTGRES_PASSWORD=12345 --name=posty postgres:9.6 $ docker logs --tail=6 postyPostgreSQL init process complete; ready for start up. LOG: database system was shut down at 2017-07-07 20:32:23 UTCLOG: MultiXact member wraparound protections are now enabledLOG: autovacuum launcher startedLOG: database system is ready to accept connections $ docker run -it --rm --link posty:postgres postgres:9.6 psql -h postgres -U postgresPassword for user postgres: psql (9.6.3)Type "help" for help. postgres=# Can you connect to your postgres container via psql? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#308 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOCN5PDWuH-ibb3n-WnZwPpE_8UAIqOks5sLplagaJpZM4OPOEw> .

[lelit]

FYI, I distilled this minimalistic recipe that exhibits the problem, but still using docker compose. @dpnova, were you able to determine if the same happens with plain docker or not?

[dpnova]

I've only seen this in docker. Sorry travelling overseas atm pon, 24. jul 2017. 10.05 PM Emanuele Gaifas <notifications@github.com> је написао/ла:

…

FYI, I distilled this <https://github.com/lelit/asyncpg-issue158> minimalistic recipe that exhibits the problem, but still using docker compose. @dpnova <https://github.com/dpnova>, were you able to determine if the same happens with plain docker or not? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#308 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOCN8U-DWSv22uZU1KxvI7f-XuNc49Oks5sRPkZgaJpZM4OPOEw> .

[dpnova]

Sorry I mean in docker compose. uto, 25. jul 2017. 08.45 AM David P. Novakovic <dpn@dpn.name> је написао/ла:

…

I've only seen this in docker. Sorry travelling overseas atm pon, 24. jul 2017. 10.05 PM Emanuele Gaifas ***@***.***> је написао/ла: > FYI, I distilled this <https://github.com/lelit/asyncpg-issue158> > minimalistic recipe that exhibits the problem, but still using docker > compose. @dpnova <https://github.com/dpnova>, were you able to determine > if the same happens with plain docker or not? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#308 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAOCN8U-DWSv22uZU1KxvI7f-XuNc49Oks5sRPkZgaJpZM4OPOEw> > . >

[lelit]

I added an alternative recipe using plain docker and got the same problem.

[lelit]

The problem is still there in PG10b3: asyncpg folks could not replicate the problem with a local build of PostgreSQL.

[dpnova]

As noted over at MagicStack/asyncpg#158 the problem appeared around the same time the changes were made to the image build. I reckon d8abce4 looks suspect

[lelit]

FYI, current asyncpg master does not manifest the problem anymore.

[soosap]

Hi @lelit I tried to follow this discussion here but not sure how I can fix this.

I still immediately get this error when I set "POSTGRES_PASSWORD" using v10.1.
What is the current state on this? How to fix this?

2018-01-02 10:02:24.537 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2018-01-02 10:02:24.537 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2018-01-02 10:02:24.542 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2018-01-02 10:02:24.556 UTC [64] LOG:  database system was shut down at 2018-01-02 10:02:24 UTC
2018-01-02 10:02:24.561 UTC [1] LOG:  database system is ready to accept connections
2018-01-02 10:02:28.734 UTC [71] FATAL:  password authentication failed for user "prasath"
2018-01-02 10:02:28.734 UTC [71] DETAIL:  Password does not match for user "prasath".
	Connection matched pg_hba.conf line 95: "host all all all md5"
2018-01-02 10:02:28.736 UTC [72] FATAL:  password authentication failed for user "prasath"
2018-01-02 10:02:28.736 UTC [72] DETAIL:  Password does not match for user "prasath".