Trying to install drupal 7.16 from CentOS packages, and am unable to set up the database connection. I keep getting the failed to connect error message trying to connect to the local database or even to a remote database known to be accepting connections:
Failed to connect to your database server. The server reports the following message: SQLSTATE[08006] [7] could not connect to server: Permission denied Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? could not connect to server: Permission denied Is the server running on host "localhost" and accepting TCP/IP connections on port 5432?.
•Is the database server running?
•Does the database exist, and have you entered the correct database name?
•Have you entered the correct username and password?
•Have you entered the correct database hostnameor:
Failed to connect to your database server. The server reports the following message: SQLSTATE[08006] [7] could not connect to server: Permission denied Is the server running on host "172.22.10.202" and accepting TCP/IP connections on port 5432?.
•Is the database server running?
•Does the database exist, and have you entered the correct database name?
•Have you entered the correct username and password?
•Have you entered the correct database hostnameNow here's the thing. I can connect to either database from this system via pgsql in an xterm:
psql -U drupal_user drupal_database
psql -U drupal_user -h localhost drupal_database
psql -U drupal_user -h 172.22.10.202 drupal_databaseAll three succeed, so the problem is not the database, but how drupal is trying to connect. I have enabled PostgreSQL connection logging and I see the three attempts above, but I never see any connection attempts by drupal. Unfortunately no one seems to have thought to include the ability to log what drupal is doing during the installation process (or at least not well enough documented to find), so I have no way to monitor what drupal is trying to do, other than search the forums and hope for an answer. But, all of the search results that I have found regarding similar issues have failed to provide a solution to my problem, and having nothing more than an error message to go on is frustrating, to say the least.
The database is running on both servers. The username I am supplying to drupal is correct in both instances. The password that I am supplying is correct in both instances. The database name and the database server is correct in both instances. The PostgreSQL socket is in the default location of /tmp/.s.PGSQL.5432. So at this point I can safely implicate drupal as the culprit, but again the lack of information provides no opportunity for a course of action.
Anybody willing to shed some light on how I can resolve this issue?
BTW, a "Check the database connection" option would be real nice. Having only the option of Save and continue assumes all is well, and offers nothing in the way of troubleshooting capabilities.
Comments
1. Installing from packages
1. Installing from packages is usually a bad idea IMO. I did not even know there was a Centos package. I have seen the Debian one. Since a manual install takes 5 minutes, the time the package potentially saves is not worth it (and in the case the Debian package, there are some disadvantages, even if it does work straight away). If you want to speed up your development install and learn drush, which can also shave a a few minutes off the installation time.
2. I never used Postgre (do you have a good reason not to use mysql?) but I notice you do not mention whether you assigned you db user the necessary privileges for installing Drupal (I usually do All Privileges, but for more detail follow the Documentation menu item at the top of this page).
Digit Professionals
Packages offer validation
Hi John,
Thanks for the reply.
1. As a general rule I install from Distro packages when the original software does not provide any trust mechanism for authenticating the download. The md5 hash that is provided with Drupal makes me reasonably confident that I downloaded a file that matches that hash, but it does not provide any assurance that the file I downloaded is the file that was uploaded by the developers. Installation from a package does offer me reasonable assurance that the package I downloaded is the one that was uploaded by the package maintainers, and in most Distros it also offers some assurance that the software in the package has been vetted and will default to a working configuration.
2. Yes, we have a good reason for not using MySQL.
In reference to your point regarding user privileges, yes the user has the proper privileges, but that is not relevant here. I am monitoring connection attempts, and the Drupal install process does not even attempt to make a connection to any server that I point it to. In addition, as I said above, I can successfully connnect to the local and the remote server from this system, using the user credentials and database name as supplied to Drupal, as long as I don't do it through Drupal. It is as if Drupal does not realize the database host entry is really the server it should talk to. This is consistent with the error that Drupal reports, which is the pgsql client's "could not find a server to talk to". If this was a permissions problem I would see an entirely different error.
So I need to know what Drupal is attempting to do, and I have not been successful in that regard. Where can I find the connection string it is using? Seeing that would likely shed some light on the situation. Heck, any information beyond the failed to connect message would be of some help
Nelson
BTW, this is completely off-topic, and a shame-less plug. I have used Debian for almost 15 years, and I have never had any issues with their packages. Other than one instance where I needed a brand new feature in BIND that had not made it into Debian Stable, I have never installed anything that did not come from a Debian package onto a Debian system. The stability and security that Debian offers far out-weighs any need for the latest bleeding edge feature, and their support is generally phenomenal. And the ISC does provide PKI verification, as does Debian.
The connection strings are
The connection strings are called by includes/install.core.php via the Drupal database API, as far as I know. The architecture of the installer is probably only well understood by some core developers, and having done (and often had to debug) dozens of Drupal installations I have never needed to get in that kind of depth to get a Drupal install working.
I am a Debian fan and I have confidence in Debian packages (not such great experience with Centos 64 bit packages). I still don't do not personally like the Debian Drupal package, and I am not aware of Drupal professionals using it (generally we all use drush) but some may. I know nothing about the Centos package. You can be sure the code the packages contain can only have been downloaded from the drupal.org servers and repackaged, so nothing is really lost by getting your code direct from http://drupal.org/project/drupal
Digit Professionals