Reputation: 41929
I deployed a sample Rails app to a remote server with postgres hosted on the same server. The database.yml file was like this.
production:
adapter: postgresql
encoding: unicode
database: remotepg_production
pool: 5
host: localhost
username: mrmann
password: secret
Everything worked fine. I then went into the database.yml file and replaced host: localhost
with the ip address of a postgres database on another server host: 178.XXX.XXX
like this
production:
adapter: postgresql
encoding: unicode
database: remotepg_production
pool: 5
host: 178.XXX.XXX.XXX #ip address of server with other postgres database
username: mrmann
password: secret
When I restarted postgres on the server with the Rails app, the sample application now gave me the 'something went wrong' page for Rails.
The username and the password for the username are the same on both dbs. Can you suggest what the problem might be? Thanks
Update
These are the settings in pg_hba.conf on the server with the database that I want to connect to.
local all postgres peer
local all all peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
Fake Rails app IP: 192.241.XXX.X
Fake Database IP: 192.34.XX.XXX
Upvotes: 1
Views: 3225
Reputation: 9756
Do you have access to the database logs? If your connection got as far as attempting to connect to the database, there should be some messages there. My WAG is that you need to add that IP to server's pg_hba.conf file and reload Postgres.
To be more clear, the IP to add to the server's pg_hba.conf is the IP that your application is connecting from, and you should also check the value of the database's listen_addresses
setting. If the latter is not set to '*' or to the IP of your application, you'll need to change it in the postgresql.conf and restart the db cluster.
[edit, new information provided]
The line in your pg_hba.conf should be
host all all 192.241.XXX.X md5
Reload (not restart) postgres (eg. pg_ctl reload
) and then try connecting again. If it fails, find the db log and see what it shows. If there is no message, then it might be a firewall problem. If the latter is suspected, look for any rules relating to port 5432 in the output of iptables -nvL
Upvotes: 1