[support] SOLVED, sort of, was Recovering Drupal sites after disk failure coinciding with system upgrade - Advice?

Max Pyziur pyz at brama.com
Thu May 26 22:45:19 UTC 2011


> The ones that always seem to get me are as follows:
> After your vhost is set, restart Apache.
> Make sure that you flush privileges (mysql, though)
> Set those file permissions correctly!
> Make certain you set the correct username/pass in the settings.php file.
> See if you can get to www.example.com/install.php and see if it at least
> says that there already is a database there.

It's a postgresql issue.

I changed some settings in
/pathtopgsql/data/pg_hba.conf

in order for it to accept connections.

The key logged error message was:
LOG:  could not connect to Ident server at address "127.0.0.1", port 113:
Connection refused
FATAL:  Ident authentication failed for user "localusername"

I'm not sure that I made the correct adjustments to pg_hba.conf, but I've
got it to accept connections to some of my Drupal websites. Other issues
could be definitions of "roles." More research required here.

However, if someone has guidance on the best pg_hba.conf configuration for
Drupal usage, given the OS/technology stack described below, do tell.

Thanks.

Max Pyziur
pyz at brama.com

>
> Hope that helps!
>
> Joel
>
>
> -----Original Message-----
> Greetings,
>
> We host several Drupal-oriented websites. Recently, we experienced a major
> disk failure, causing us to move from an OS and technology stack that was
> bleeding-edge in 2004, to a mainstream OS and technology stack currently.
>
> The original OS and technology stack was:
> Fedora Core 2.4
> Apache 2.0.*
> PostgreSQL 7.4.8
> PHP 4.3.11
> Drupal 6.*
>
> Our new OS and stack is:
> CentOs 5.6
> Apache 2.2.*
> PostgreSQL 8.1
> PHP 5.1.6
> No change to the Drupal 6.* variant.
>
> Before disk failure we managed to gzip-tar the Drupal-related websites,
> and run pg_dump against the respective website's Postgres database.
>
> We've restored the Drupal-related websites to their same respective
> directories (ones that the webserver recognizes.
>
> We've restored one of the Drupal-related databases; some adjustments had
> to first be made to the contents of one of "pg_dumps;" i.e. two lines had
> to be modified from 'CREATE FUNCTION greatest ...' to 'CREATE OR REPLACE
> FUNCTION "greatest" ....' in order for the Postgres database to be
> restored.
>
> However, the website returns Drupal's "Blue Screen of Death."  (It's a
> nice shade of blue). The one that says, "Site off-line .... If you are the
> maintainer of this site, please check your database settings in the
> settings.php file and ensure that your hosting provider's database server
> is running. ..."
>
> The database server is running, since other (non-Drupal) databases are
> fully accessible.
>
> While the general plan is keep looking through log files, trying to find
> clues to the cause, suggestions from the user community would be helpful,
> especially who have encountered similar circumstances and problems.
>
> Much thanks.
>
> Max Pyziur
> pyz at brama.com
> --
> [ Drupal support list | http://lists.drupal.org/ ]
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>



More information about the support mailing list