Behaviour change between 9.5.20 and 9.5.21?

When running docker run --rm postgres:9.5.20-alpine, the database successfully starts up, but with docker run --rm postgres:9.5.21-alpine, I get this output instead:

Error: Database is uninitialized and superuser password is not specified.
       You must specify POSTGRES_PASSWORD for the superuser. Use
       "-e POSTGRES_PASSWORD=password" to set it in "docker run".

       You may also use POSTGRES_HOST_AUTH_METHOD=trust to allow all connections
       without a password. This is *not* recommended. See PostgreSQL
       documentation about "trust":
       https://www.postgresql.org/docs/current/auth-trust.html

Is this an expected change?

Based on 42ce743 it seems like it's intentional, but I find it odd to change something like that on a minor release

I just observed the same issue when bumping 9.6.16 => 9.6.17.

See also #658, the PR that seems to have introduced this

We were convinced to make it more secure by default and were aware that this would break some users. Apologies for breaking changes. 🙇‍♂️ We felt that the increased security out-weighed the breakage. See #658 and #580.

If you know that you want to be insecure (i.e. any one can connect without a password from anywhere), then POSTGRES_HOST_AUTH_METHOD=trust is how you opt in to that.

We really recommend setting a password and it was really a bad decision by me in the beginning to continue to allow running the database without a password (#31 (comment) & #36)

I wish a breaking change was not pushed out on a Friday. This broke our CI/CD pipeline, which I had to fix on a Saturday.

Postgres is no longer starting

Where in a CI/CD pipeline does one place those lines -e POSTGRES_PASSWORD=password or POSTGRES_HOST_AUTH_METHOD=trust ?

As always emotions fly high when a breaking change is introduced, causing work for others ;)

I appreciate the effort that you put into maintaining this image!

Maybe one can put the fix to add "POSTGRES_HOST_AUTH_METHOD=trust" somewhere more prominent. I get it that its part of the docker output when you start the image, yet sadly not if you start it with "-d". Then you are just wondering why the next docker command complains that the database is not up ;)

POSTGRES_PASSWORD is now required when using postgres via docker

@CloudArchipelago

@CloudArchipelago: It depends on what pipeline you are using. The two that I'm familiar with is GitHub and BitBucket:

For GitHub, I think you put the POSTGRES_HOST_AUTH_METHOD=trust in the env section shown here: https://github.com/actions/example-services/blob/master/.github/workflows/postgres-service.yml
We use BitBucket, and it goes in the environment section shown here: https://community.atlassian.com/t5/Bitbucket-questions/How-do-I-use-Postgres-in-Bitbucket-Pipelines/qaq-p/461910

(Of course, these articles and examples will need to be updated, since they no longer work as shown.)

I don't understand exactly how these pipelines actually configure and start the Postgres service in docker. So I don't know where the -e POSTGRES_PASSWORD=password would go.

And to be honest, I don't fully understand exactly what POSTGRES_HOST_AUTH_METHOD=trust does either since it's the first time I'm seeing it. I can probably figure it out in a few hours, but y'know, it's the long weekend. I got family to take care of, out of town guests visiting, housework to do, shopping to do, don't got time to spend on this...

Was or is there consideration to switch to something like semantic versioning? If that was the case then this change, given it's intentional and a breaking changes, would cause a major revision change and everyone could deal with it accordingly. If such a change comes through not as a major, not even as a minor but merely as a patch release (z in x.y.z), then it is highly surprising and that is what trips up processes. Just putting it out there for consideration.

@bxparks

Tried @bxparks proposed workaround for our CircleCI build (we use Github) and it worked. Simply add POSTGRES_HOST_AUTH_METHOD: trust.

- image: circleci/postgres:9.6-postgis-ram
       environment:
          POSTGRES_USER: 'username'
          POSTGRES_HOST_AUTH_METHOD: trust

We were just burnt by this change and would give a big +1 to adopting semver to help mitigate this in the future.

However, I'm not posting just to pile on about semver, I have one other thing I'd like to point out. When our CI pipelines starting running with this newer container image (without POSTGRES_HOST_AUTH_METHOD or POSTGRES_PASSWORD) set the postgres container looked like it was coming up and staying up correctly. Because it wasn't clear the postgres container was the issue we spent a lot of time and effort looking in the wrong place.

In future, if a change is made where the database effectively doesn't work, the container should not just sit there happily doing nothing when it's actually broken. Had the postgres container been more noticeably broken we could have saved most of the time and effort we spent looking in the wrong place for the cause of the issue.

As a slight aside, is there an official we can monitor to know about future significant or breaking changes to this container in future?

Same here, broken our CI and local development

CI: Fix postgres configuration on Drone

Ble offer for en breaking change i postgres docker imaget

Fikset oppsettet av lokal docker

Update postgres env vars in Docker compose due to this issue.

Allow postgres container to start without password

Fix starting database without password

circle-ciのpostgresコンテナのエラーを修正した

Fix CI failure from Docker Postgres image

Works for me adding this to postgres container.

environment: POSTGRES_HOST_AUTH_METHOD: "trust"

@QuantumWaver

Not sure if this will help anyone and I apologize if this is the wrong place to post this, but here is how I solved the issue without having to set POSTGRES_HOST_AUTH_METHOD: trust (which was not recommended above)

@QuantumWaver
It works for me. Thanks!

No idea why setting POSTGRES_HOST_AUTH_METHOD=trust doesn't work for me. 🤔

I got PG::ConnectionBad: FATAL: password authentication failed for user "postgres" when I tried to rake db:migrate.
I had to set a password and added POSTGRES_PASSWORD=password to my docker-compose.yml.

@yosifkit

@yosifkit I've submitted a PR in which updated the docs and put more emphasis on how to aptly set the environment variables. Merge it as you deem fit.

Per https://www.postgresql.org/docs/current/auth-trust.html:

trust authentication is appropriate and very convenient for local connections on a single-user workstation.

Is there a way to suppress the warning about trust in this situation? As mentioned, we limit this to local workstations, we'd like to avoid showing the error unnecessarily.

I think note, that "POSTGRES_HOST_AUTH_METHOD='trust' is not recommended" only actual if you have forward postgre post from your container to outside.

If your service works only in docker network (no port forward specified in docker-compose file) I think it's pretty safe to trust anything from local docker network

I tripped up on this too. It looks like it has broken Compose getting started guides too: https://docs.docker.com/compose/django/

I solved my issue using below:
- POSTGRES_HOST_AUTH_METHOD=md5
- POSTGRES_INITDB_ARGS=--auth-host=md5

Navigation Menu

Repository navigation

Behaviour change between 9.5.20 and 9.5.21? #681

64 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Behaviour change between 9.5.20 and 9.5.21? #681

Description

Activity

vpzomtrrfrt commented on Feb 14, 2020

aengelberg commented on Feb 14, 2020

vpzomtrrfrt commented on Feb 14, 2020

yosifkit commented on Feb 14, 2020

bxparks commented on Feb 15, 2020

CloudArchipelago commented on Feb 16, 2020

chickahoona commented on Feb 16, 2020

bxparks commented on Feb 16, 2020

ManfredLange commented on Feb 17, 2020

kennethteh90 commented on Feb 17, 2020

Nadock commented on Feb 17, 2020

scaytrase commented on Feb 17, 2020

64 remaining items

cheesepaulo commented on Mar 4, 2020

khiav223577 commented on Mar 6, 2020

babakks commented on Mar 7, 2020

mikemaccana commented on Mar 13, 2020

ShockwaveNN commented on Mar 24, 2020

bfirsh commented on Apr 2, 2020

amotalles commented on Oct 15, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions