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@brama.com
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.
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@brama.com
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@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@brama.com -- [ Drupal support list | http://lists.drupal.org/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
On Thu, 26 May 2011 18:45:19 -0400 (EDT) "Max Pyziur" pyz@brama.com wrote:
I changed some settings in /pathtopgsql/data/pg_hba.conf
I'd go with a:
local yourdbname yourusername md5
hostssl yourdbname yourusername 0.0.0.0 0.0.0.0 md5
Beware that when the connection string contains host=localhost php drivers may try to connect through tcp/ip not unix sockets and the first login method won't work. This required some tweaking of core in D5/D6. I'm not sure if this problem has been solved in D7.
The second entry is for remote encrypted connection over tcp/ip. If you want an encrypted connection you'll have to do some extra work to set up certificates. DON'T use unencrypted connection over public/semi public connection, no matter if you restrict the range of accepted IP.
If you can't succede to use unix sockets you can use tcp/ip on localhost at some performance cost.
#ipv4 host yourdbname yourusername 127.0.0.1/32 md5 #ipv6 host yourdbname yourusername ::1/128 md5
On Fri, 27 May 2011, Ivan Sergio Borgonovo wrote:
On Thu, 26 May 2011 18:45:19 -0400 (EDT) "Max Pyziur" pyz@brama.com wrote:
I changed some settings in /pathtopgsql/data/pg_hba.conf
I'd go with a:
local yourdbname yourusername md5
hostssl yourdbname yourusername 0.0.0.0 0.0.0.0 md5
Beware that when the connection string contains host=localhost php drivers may try to connect through tcp/ip not unix sockets and the first login method won't work. This required some tweaking of core in D5/D6. I'm not sure if this problem has been solved in D7.
The second entry is for remote encrypted connection over tcp/ip. If you want an encrypted connection you'll have to do some extra work to set up certificates. DON'T use unencrypted connection over public/semi public connection, no matter if you restrict the range of accepted IP.
If you can't succede to use unix sockets you can use tcp/ip on localhost at some performance cost.
#ipv4 host yourdbname yourusername 127.0.0.1/32 md5 #ipv6 host yourdbname yourusername ::1/128 md5
Much thanks for your reply. Thoroughly understanding the setup of pg_hba.conf is important.
I found this item which might be useful in learning about postgresql security: http://www.ibm.com/developerworks/opensource/library/os-postgresecurity/inde...
Max Pyziur pyz@brama.com
Max Pyziur wrote:
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.
Did you restore the database users and privileges with the same passwords as before?
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. ..."
At least you didn't get redirected to the install page. It finds settings.php but can't get logged into the DB.
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.
Make sure to truncate cache* tables and the session table.
-
Earnie Boyd -
Ivan Sergio Borgonovo -
Joel Willers -
Max Pyziur