Postgresql misconfigured when not the default distrib package (ex: Centos 6 with Postgresql 9.3 from pgfoundry.org)
I was attempting to install rudder-reports to Centos 6x with Postgresql 9.3 from the pgdg repository http://svn.pgrpms.org/browser/rpm/redhat/9.3/pgdg-yum/CTOS-6/pgdg-93-centos.repo . I was met with the issue of not finding the /var/lib/pgsql/data/pg_hba.conf file or /etc/init.d/postgresql. After scratching my head a little I created a symlink from /var/lib/pgsql/9.3/data/pg_hba.conf to the expected path in order to complete the installation as well as a symlink from /etc/init.d/postgresql-9.3 to /etc/init.d/postgresql. I also had to manually configure my pg_hba.conf to change to md5 for local and localhost, create user db rudder with owner rudder and run the schema import from /opt/rudder/etc/postgresql/reportsSchema.sql . I am sure there will be some more issues going forward, just wanted to let someone be aware if they run across this same thing to look for this. Thanks with help from ncharles on irc for assisting with this.
#1 Updated by François ARMAND about 3 years ago
- Subject changed from Postgresql difficulty on Centos 6 with Postgresql 9.3 from pgfoundry.org to Postgresql misconfigured when not the default distrib package (ex: Centos 6 with Postgresql 9.3 from pgfoundry.org)
- Category set to System integration
- Assignee set to Nicolas CHARLES
- Priority changed from N/A to 3
- Target version changed from Ideas (not version specific) to 2.10.12
Thanks for reporting.Nico, could you tell us a little more on that one. For now, I can sum-up the list of problems and workarounds as:
- 1/ missing expected starting script (=> symlink provided one to /etc/init.d/postgresql)
- 2/ missing expected authz file (=> symlink provided one to /var/lib/pgsql/data/pg_hba.conf)
- 3/ initialisation not done (=> do it again, by hand)
Do you see other problems ?
For #3, there must be a easier way than playing things by hand, like running again post-installation script of the package. Do you know (or perhaps Matthieu ?) how to do that with rpm/deb ?
It seems that the first easy step for that one is to document what are the requirement for non standard pg installation (perhaps just the two symlinks ?), and how to get of the mud if needed.
#3 Updated by Nicolas CHARLES almost 3 years ago
- Assignee changed from Nicolas CHARLES to Matthieu CERDA
Paths of postgres are hardcoded in Rudder, which is a real problem (see also #6412).
The issue is if the install of postgres does not use "standart" paths, Rudder is lost, and can't properly manage database and give access
For 3/ the solution may be to rerun the rudder-init; for the first 2, i'm not sure symlink is the right solution (it is quite dirty), but rather to detect the correct paths of installation
Matthieu may know how to detet the proper path of postgres installation
#6 Updated by Matthieu CERDA almost 3 years ago
The problem is, there is no standard installation path, only possible candidates on each type of OSes, that may or may not match the currently used one (eg. if the user uses home made packages storing things in /var/lib/my-postgres-9/ so it does not conflict with system packages).
For me, the problem is not that we do not cover every possible case, it is more that we do not give the possibility to do something else (we assume defaults but do not give easily the option to the user to do something else.)
For the ACL configuration, we could try to configure automatically, and just skip and output a helpful message explaining how to do it manually if we can't.
For the postgresql service name, it is an entirely other problem, as there is also no easy way to guess the name used. We can only try to detect it, that's what I did on the Rudder 3.1 init script (get all service candidates matching "postgresql", and use the last one, like "postgresql91")