PostgreSQL configuration files not found

Using Django Using the ORM
1

On my local development machine (macOS), I have placed .pg_service.conf and .pgpass in the home directory of the user running gunicorn, and configured the connection on settings.py like this:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'OPTIONS': {
            'service' : 'mydb',
            'passfile' : '.pgpass',
        }
    }
}

This works as expected. On the test server (FreeBSD with jails; database running in different jail), however, the PostgreSQL configuration files are not found in the user’s home directory (/home/www). I created the home directory for www manually, referenced it in /etc/passwd, set restrictive permissions on the configuration files and tested by logging in as www; psql service=mydb gets me right into the correct database without entering a password.

When placing pg_service.conf in /usr/local/etc/postgresql and specifying an absolute path for passfile (/home/www/.pgpass) in settings.py, the connection is available for my Django app, too – but why is the placement of the configuration files in /home/www not sufficient in this case? I start gunicorn with a --chdir parameter to the project’s root directory, but this should not make a difference.

2

This is not a Django, or even a Django-related issue.

The configuration for the location of the .pgpass file is part of the libpq PostgreSQL library, linked to and used by the psycopg2 package. That passfile connection option is passed through to psycopg. (See PostgreSQL: Documentation: 18: 32.16. The Password File)

The location of this file can also be specified using the PGPASSFILE environment variable. (See PostgreSQL: Documentation: 18: 32.15. Environment Variables)

So to directly address your question:

You would need to look elsewhere for the answer. It might be something in BSD’s security model. It might be something in how libpq is built for BSD. It might be something in how psycopg is built for BSD. I guess it’s even possible that the issue is in gunicorn. But I am virtually certain that Django wouldn’t be involved here.

1 Like
3

You are right, posting the question in this forum was not the best idea.