Open OkJaybird opened 6 years ago
Thanks for the report @OkJaybird!
I'm actually seeing some pretty interesting behaviour in the studio. I'm wondering if this is expected or not. I was trying to confirm that loading config changes before the service works as expected, and was going to suggest this option to you.
If you don't want to load config before the service, I would highly recommend creating a configuration plan, that basically declares a dependency on core/postgresql, and puts in configuration changes that you want. The core plan should remain as simple / default as possible.
# echo "[superuser]
> password = 'test'" | hab config apply postgresql.default $(date +%s)
» Setting new configuration version 1531809928 for postgresql.default
Ω Creating service configuration
↑ Applying via peer 127.0.0.1:9632
★ Applied configuration
[2][default:/src:0]# hab svc load core/postgresql
» Installing core/postgresql
☁ Determining latest version of core/postgresql in the 'stable' channel
☛ Verifying core/postgresql/9.6.9/20180716151728
.... snipped ....
★ Install of core/postgresql/9.6.9/20180716151728 complete with 26 new packages installed.
The core/postgresql service was successfully loaded
pwfile
[3][default:/src:0]# cat /hab/svc/postgresql/config/pwfile
test
[4][default:/src:127]# hab pkg binlink core/postgresql
» Binlinking pg_test_timing from core/postgresql into /hab/bin
.... snipped ....
admin / test -> Success
[5][default:/src:0]# psql postgresql://admin:test@localhost:5432/postgres
psql (9.6.9)
Type "help" for help.
postgres=#
admin / admin -> success
[6][default:/src:0]# psql postgresql://admin:admin@localhost:5432/postgres
psql (9.6.9)
Type "help" for help.
postgres=#
admin / foo -> success
[7][default:/src:0]# psql postgresql://admin:foo@localhost:5432/postgres
psql (9.6.9)
Type "help" for help.
postgres=#
fancy / pants -> FAIL
[8][default:/src:0]# psql postgresql://fancy:pants@localhost:5432/postgres
psql: FATAL: role "fancy" does not exist
admin / pants -> success
[9][default:/src:2]# psql postgresql://admin:pants@localhost:5432/postgres
psql (9.6.9)
Type "help" for help.
postgres=#
For me it looks like password cannot be changed via PGPASSFILE after service had started... I had the same issue:
I can confirm that PGPASSFILE environment variable propagated correctly, postgres process sees it, content is valid (new password), but you cannot connect.
Just ran into this this morning when rotating DB passwords. I'll see if I can come up with a solution, so that when you change the superuser password, it actually changes it in the DB.
I'm trying to understand a way to use the core/postgresql service in a more secure way. I'm able to change the superuser password via
hab apply
and see it reflected in the config files Habitat regenerates, but the password doesn't actually change as far as connecting to postgres is concerned.Steps to reproduce:
Trying to connect using the new password doesn't work, but
admin
still works.Expected behavior:
I should be able to login with credentials
admin/test
and unable to login withadmin/admin
.Also, if there are other ways to get a more secure password out of the box without ever needing to create superuser creds that are
admin/admin
, I'd love to see an example if someone has one. Ideally, secure random creds could be generated on the fly during init, etc.Additional info: