Database connection to a separated host

Administrators
1

Hi,
For security reasons I would like to install the database in a separated server behind the firewall. The front-end will remain in the DMZ.

According to the documentation it can be achieved using :

SQLALCHEMY_DATABASE_URI
postgresql://user:password@hostname/dbname

What kind of authentication must be placed in the pg_hba.conf???.

Thank you for your help.

David

2

This is more a postgres question than an indico question, but I think generally people use ‘md5’ there.

Note: If the connection uses an untrusted network, you need to make sure the connection is TLS-encrypted.

3

Thank you for the advice.

David

4

Hi
I’m getting authentication errors when trying to connect to a separated database server. Could you please post an example of the indico.conf file?. Your help is very appreciated.
Dave

5

Did you reload postgres after updating pg_hba.conf?

SQLALCHEMY_DATABASE_URI = 'postgresql://indico:secret@the.db.host:5432/indico'
6

Thank you for your reply,
Yes I restarted the service. Actually I’m able to connect to the database using pgAdmin and the same ID and password I’m trying for indico.
you said indico uses md5 as default method, right?
Regards,
Dave

7

It has nothing to do with Indico; it just specifies how postgres expects the password to be transmitted: https://www.postgresql.org/docs/9.6/auth-methods.html#AUTH-PASSWORD

I’m pretty sure the postgres client automatically uses the most suitable method since I never had to configure anything anywhere to connect using a password to a postgres DB besides specifying the password.

See if you can connect using the psql command line client from the same machine that’s running indico…

8

Thank you for the reply and for the reference. Very useful!.
Indico now works using simple password authentication.
Now, I’ll try to use md5 to improve security.

Regards,

DdM

9

FWIW, if you are on an untrusted network you need to use TLS for the connection - and could even use TLS client cert auth in that case.

BTW, another interesting post regarding Postgres authentication: