I have an active gitlab Omnibus installation. I’m installing another postgres-based app (JIRA) on the same server but I can’t connect to the gitlab instance of postgres. No matter what I do, I always get
JIRA reports connection refused, and I can confirm it with nc from the command line. I was able to use psql to create the new user and new db but the connection continues to be refused on port 5432.
What’s going on? Does gitlab configure postgresql to restrict access?
You are probably using postgres installed by your package manager. GitLab uses its own bundled postgres. You can find its binaries in /opt/gitlab/embedded/bin.
The other way is to use the system postgres instead of the bundled one. In that case you will have to configure /etc/gitlab/gitlab.rbaccordingly.
Thanks for the response. It’s right on but I haven’t found the right gitlab.rb tweaks to allow me to use the db. I installed gitlab-omnibus on a fresh system, which worked nicely. Now I’m trying to allow a new app to use the gitlab embedded postgres.
I didn’t find anything in the postgres section of gitlab.rb that should lock me out. I am looking now at pg_hba.conf. I added a line in the template file as follows:
local all all trust
(It’s too insecure for production, I understand.) I reconfigured and restarted and the line showed up in the working pg_hba.conf but didn’t solve the problem.
This is the same response I get for any unattended port. Also, “lsof -i” and netstat commands don’t show anybody listening on 5432. Yet postgres is running (has a PID), and gitlab is running perfectly. Mystery to me.
Ok, I’m editing my comment as what I did write was incorrect.
Currently, using gitlab’s configuration files, I can’t make the two methods of accessing to postgresql local instance working :
It’s either gitlab normal webservice or another service.
The normal way should be to edit [ /etc/gitlab/gitlab.rb ] and find the two distinct lines
or whatever IP & IP mask you need to make it trust connections from. IP mask is mandatory or it won’t work.
But if you reconfigure & restart, you could use your other local service to access postgre, but gitlab can’t be accessed anymore.
The only way I found to circumvent this issue is to manually edit postgre conf file var/opt/gitlab/postgresql/data/pg_hba.conf
And add this line at the end of it:
host all all 127.0.0.1/32 trust
Then edit /var/opt/gitlab/postgresql/data/postgresql.conf , find the line:
listen_addresses = ''
And change it to:
listen_addresses = '*'
After that, you just have to execute in a root command line : # gitlab-ctl restart
And it should work as intended.
Just check Postgre local log to check if anything else went wrong : # tail /var/log/gitlab/postgresql/current
One refinement: These edits will be overwritten by any subsequent gitlab-ctl reconfigure.
I made the edits in the template files instead:
/opt/gitlab/embedded/cookbooks/gitlab/templates/default/postgresql.conf.erb and
/opt/gitlab/embedded/cookbooks/gitlab/templates/default/pg_hba.conf.erb.
Then, running gitlab-ctl reconfigure and gitlab-ctl restart achieves the same result but doesn’t get overwritten.
Hi @masterfoo, being late at the party, but I am applying @EricB edits with success however I can’t find the files that you are refering to. I am using the latest Omnibus version packed with Docker.
Do you know if the files postgresql.conf.erb and pg_hba.conf.erb have been renamed since your 3-y.o. reply?
I don’t see those two .erb files anymore. I also grep’d the directory for listen_address but didn’t see anything that seemed to replace those files. But you can make the same changes as suggested in /etc/gitlab/gitlab.rb . You’ll have to save a copy as your changes may get overwritten any time you run reconfigure.
