Migrating the database using pg_dump and pg_restore does not guarantee the migration of the database user. Is it possible that you've got the database migrated but not the database user?
I would leave drupal out for a minute and make sure that you can connect to the database using the pg_admin tool or something like it using the user that you connect with for drupal. (Us psql -h hostname or something) to make sure you are not using a local user, but rather a remote one.
What does this test yield?
FYI: civicrm is a drupal distribution/module. You'd know if you had it. Sorry for the red herring.
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Max Pyziur Sent: Monday, March 25, 2013 3:45 PM To: support@drupal.org Subject: [support] Authentication problem, was Re: Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
It's beginning to look like an authentication problem.
I added the following lines to ~/index.php, error_reporting(E_ALL); ini_set('display_errors', TRUE); ini_set('display_startup_errors', TRUE);
and found the following: The pgsql error was: pg_connect(): Unable to connect to PostgreSQL server: fe_sendauth: no password supplied.
I've tried adjusting the following line: pgsql://username:password@localhost/databasename
By adding a password (the one that I have on record).
It returns a 'FATAL'
Any pointers on debugging this? I is in the data tables? Or elsewhere?
Earnie
Max Pyziur pyz@brama.com
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur pyz@brama.com wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
Apache doesn't have anything to do with the database. That's PHP and Drupal. Since you're getting the site offline error, there's a problem within the database. Check your PHP/Apache error logs and see what's being reported there.
I did four fresh installs of Drupal (6.14, 6.16, 6.22, and 6.28), each with a different user on the CentOS 6 system (PHP5.3, Postgresql 8.4). Each system works correctly.
None of the existing Drupal sites (about eight) (all updated to Drupal 6.22 on CentOS 5) that were migrated from CentOS 5 (PHP 5.1, Postgresql 8.1) (that means pg_dump and restore) are working. Looking at the overal database structure, there are 47 tables. My sense is that there is a data point somewhere in the database that is governing all of this, and making the sites report 503 errors in Apache (meaning that the site is temporarily unavailable).
I'm not familiar with the Drupal database topology; would anyone know into which table to look?
Much thanks,
Jamie Holly http://www.intoxination.net http://www.hollyit.net
Max Pyziur pyz@brama.com
On 3/24/2013 4:29 PM, Max Pyziur wrote:
Are you running Varnish? If so, is the new server configured properly in terms of Varnish listening on 80 and the vhosts on 8080, and 8080 being a configured port?
No.
As a test, I did a fresh install of Drupal 6.28 for a test user. The site runs. The sites that were restored from a pg_dump do not.
I'm checking a variety of configuration settings: e.g. 47 Tables in the new database, 47 in an existing site.
Perhaps it is an Apache configuration?
fyi,
MP pyz@brama.com
On Mar 24, 2013, at 2:18 PM, Max Pyziur pyz@brama.com wrote:
Greetings,
Due an emergency (failing disk) we moved our whole server from a CentOS 5 machine to a CentOS 6.
In the process, newer software versions were installed by default; relevant to Drupal CentOS 5 had PHP 5.1; CentOS 6 now has PHP 5.3 CentOS 5 had Postgresql 8.1.x; CentOS 6 has Postgresql 8.4.x
The way I restored the Postgresql databases was through pg_dumpall to a huge text file, and then psql postgres < AllPostgresDatabases.out on the PG 8.4 system.
Our Drupal installations were local from tarballs, not from RPMs. In most cases they are Drupal 6.22
The sites all show Drupal's blue page - site offline.
The Apache logs show that the page returns a 503 Error.
I'm in the process of trying to debug and in a bit of a rush. Usually, I try and research this in detail before posting.
Much thanks for any advice on returning these sites to status quo.
Max Pyziur pyz@brama.com -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- Earnie
-- https://sites.google.com/site/earnieboyd
[ Drupal support list | http://lists.drupal.org/ ]