Maybe double check and make sure you're also wiping the relevant containers completely so you're certain that you're making them fresh.
Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
First of all, make sure the PostgreSQL username matches as well.
Does your password contain any special characters such as quotes, dollar signs or backslashes? They can have special meanings in yaml, resulting in the password being different from what you'd expect.
Username definitely matches!
And yes, I have several special characters, but the password is surrounded by single quotes in docker-compose.yml
, so that should not matter, right?
At the very least, dollar signs will still matter, due to environment variable interpolation.
This makes sense, and I do have a dollar sign in my password...
However, I have confirmed that postgres does in fact parse the password correctly, as I can log in with the defined username/password combo directly using psql
So I think that disproves this theory, doesn't it?
edit: I tried getting rid of the dollar sign just in case... unfortunately I'm still getting the same error
You can try setting a different password, maybe it's got a character in it that messes with things. Or try URL-encoding the password in lemmy.hjson
.
You can also use a PostgreSQL client like the psql
command line tool or a full fat DB client like DBeaver and try connecting to it and see if it accepts your password or not.
Example with just Docker and the PostgreSQL container you're already running:
max-p@lemmy-host ~/lemmy % docker exec -it lemmy-postgres-1 /bin/bash
postgres:/# psql -h 172.16.32.5 -U lemmy -W
Password:
psql (15.3)
Type "help" for help.
lemmy=# \dt
List of relations
Schema | Name | Type | Owner
--------+----------------------------+-------+-------
public | __diesel_schema_migrations | table | lemmy
[... more tables ...]
It'll at least give you pointers as to where the issue lies: on the database side or lemmy's side.
I learned something interesting in doing some more testing...
Using the -W
option does indeed prompt for a password, but it accepts any value entered at the password prompt. In order to actually authenticate with a password when using psql
, you must modify the pg_hba.conf
file to use scram-sha-256
as the method for type local
.
When I do this, I am unable to authenticate (both while using my actual password, and also while using a password of "test".
And then I figured out the problem.
In my docker-compose.yml
, I had put single quotes around my postgres password, thinking this would be safe per my understanding of this question. However, just to check, I tried logging in to psql
using the password 'test'
. Sure enough, it worked.
I found another stack exchange with some different advice on strings in yaml: https://stackoverflow.com/questions/53082932/yaml-docker-compose-spaces-quotes
So, I tried my password again, without the single quotes... and it worked.
Perhaps this will help somebody beating their head against the wall in the future.
Thank you for enlightening me on the -W
option in psql. I have successfully logged in using the expected password for lemmy. This points to something with the connection string. According to the error log, the connection string being used is:
postgres://lemmy:<my percent-encoded password>@postgres:5432/lemmy
As far as I can tell, the percent encoding is correct. Any ideas how to troubleshoot this further?
edit: it just occurred to me that my container name is lemmy_postgres_1
, not postgres
as was entered in my lemmy.hjson
file. Let's see if changing that will work...