It's really pretty simple actually. But the problem seems to be that the documentation that we wrote somehow skipped this issue altogether or documented it wrongly, which I guess would have caused some really confusing experience.
The problem is when the process that accesses the database is executed as a different user from the user that has the rights to the database. For example, when running Apache, you would normally execute it as the www-data user, but the database user in PostgreSQL is different, like cheeming. What we need to do now, is to tell PostgreSQL about this mapping.
We need to edit the pg_hba.conf and the pg_ident.conf files. In the pg_hba.conf file, we add a line that looks something like this:
local my-db-name my-db-user-name ident my-map-name
Example:
local depthq cheeming ident www
Here is where I had a problem, someone wrote that the my-db-user-name is meant to be the user of the process that accesses the database, e.g. www-data. So I did that and it didn't work. Luckily, I referred to the PostgreSQL documentation. That's a RTFM lesson for me
.
And in your pg_ident.conf file, you need something like this
my-map-name some-user-name my-db-user-name
Example:
www www-data cheeming
According to PostgreSQL client authentication documentation:
... The first record with a matching connection type, client address, requested database, and user name is used to perform authentication. There is no "fall-through" or "backup": if one record is chosen and the authentication fails, subsequent records are not considered. If no record matches, access is denied. ...
So does it mean it parses the file from top to bottom? I have no idea. Putting the line right after the first local line worked fine for me.
Once you make the changes to the file, restart the PostgreSQL server and try again. You can do some debugging with the following commands:
sudo su www-data psql depthq -U cheeming
If you managed to login, then rejoice! You have conquered Ident. ![]()

Recent Comments