Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work
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
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? 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/ ]
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/ ]
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. Jamie Holly http://www.intoxination.net http://www.hollyit.net 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/ ]
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.
In the Apache logs, there is a 503 error; the message means "Temporarily Unavailable — the service or file that is being requested is not currently available." Is this a setting within the database? If so what table; can I do an update sql command? Where else can I look? By having done a fresh install, I see that Drupal 6.28 and PHP 5.3 can coexist.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
Thanks very much for your help. 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/ ]
You still aren't getting the PHP errors though that would be causing this. You need to configure your PHP to show the errors. Go to your php.ini file and set error handling to this: error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE display_errors = On log_errors = On Then restart Apache and try accessing the site and see what it says. Since you originally got a Drupal error page, that means PHP is executing, but there is an error hiding in there somewhere (which can also be something in the database). You need to get PHP's errors to be able to track that down. Generally the site offline error page means there is some connection issue with the database, so you might want to double check the $db_url in settings.php. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 3/24/2013 5:05 PM, Max Pyziur 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.
In the Apache logs, there is a 503 error; the message means "Temporarily Unavailable --- the service or file that is being requested is not currently available."
Is this a setting within the database? If so what table; can I do an update sql command?
Where else can I look?
By having done a fresh install, I see that Drupal 6.28 and PHP 5.3 can coexist.
Jamie Holly http://www.intoxination.net http://www.hollyit.net
Thanks very much for your help.
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/ ]
On 25/03/13 04:54, 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.
and postgresql.
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/ ]
Ensure you empty any table with cache* as well as sessions table. Earnie 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
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
I take it you mean running a script like this: DELETE FROM cache WHERE 1=1; DELETE FROM cache_block WHERE 1=1; DELETE FROM cache_filter WHERE 1=1; DELETE FROM cache_form WHERE 1=1; DELETE FROM cache_menu WHERE 1=1; DELETE FROM cache_page WHERE 1=1; DELETE FROM cache_update WHERE 1=1; DELETE FROM sessions WHERE 1=1; (1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days). Thanks. Max Pyziur pyz@brama.com
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...]
On Mon, 25 Mar 2013, Max Pyziur wrote:
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
I take it you mean running a script like this: DELETE FROM cache WHERE 1=1; DELETE FROM cache_block WHERE 1=1; DELETE FROM cache_filter WHERE 1=1; DELETE FROM cache_form WHERE 1=1; DELETE FROM cache_menu WHERE 1=1; DELETE FROM cache_page WHERE 1=1; DELETE FROM cache_update WHERE 1=1;
DELETE FROM sessions WHERE 1=1;
(1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days).
Thanks.
I tried this procedure on one site, and it still fails to remove the 503 error. However, this does seem to be the correct area (stored data) to remedy this. New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do work/function. So it isn't the software (PHP and Postgresql), it points to the data.
Max Pyziur pyz@brama.com [... recycle ...]
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...] -- [ Drupal support list | http://lists.drupal.org/ ]
Are you sure that there is no problem with your .htaccess file? They frequently don't get copied when moving between sites. On Mon, Mar 25, 2013 at 4:25 PM, Max Pyziur <pyz@brama.com> wrote:
On Mon, 25 Mar 2013, Max Pyziur wrote:
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
I take it you mean running a script like this: DELETE FROM cache WHERE 1=1; DELETE FROM cache_block WHERE 1=1; DELETE FROM cache_filter WHERE 1=1; DELETE FROM cache_form WHERE 1=1; DELETE FROM cache_menu WHERE 1=1; DELETE FROM cache_page WHERE 1=1; DELETE FROM cache_update WHERE 1=1;
DELETE FROM sessions WHERE 1=1;
(1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days).
Thanks.
I tried this procedure on one site, and it still fails to remove the 503 error.
However, this does seem to be the correct area (stored data) to remedy this.
New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do work/function.
So it isn't the software (PHP and Postgresql), it points to the data.
Max Pyziur pyz@brama.com [... recycle ...]
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...] -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
On Mon, 25 Mar 2013, Walt Daniels wrote:
Are you sure that there is no problem with your .htaccess file? They frequently don't get copied when moving between sites.
Files were restored from tarballs. So nothing changed there. MP
On Mon, Mar 25, 2013 at 4:25 PM, Max Pyziur <pyz@brama.com> wrote:
On Mon, 25 Mar 2013, Max Pyziur wrote:
> On Mon, 25 Mar 2013, Earnie Boyd wrote: > >> Ensure you empty any table with cache* as well as sessions table. > > I take it you mean running a script like this: > DELETE FROM cache WHERE 1=1; > DELETE FROM cache_block WHERE 1=1; > DELETE FROM cache_filter WHERE 1=1; > DELETE FROM cache_form WHERE 1=1; > DELETE FROM cache_menu WHERE 1=1; > DELETE FROM cache_page WHERE 1=1; > DELETE FROM cache_update WHERE 1=1; > > DELETE FROM sessions WHERE 1=1; > > (1=1 is a kluge I used when I worked on Informix databases; probably > unnecessary these days). > > Thanks.
I tried this procedure on one site, and it still fails to remove the 503 error.
However, this does seem to be the correct area (stored data) to remedy this.
New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do work/function.
So it isn't the software (PHP and Postgresql), it points to the data.
Max Pyziur pyz@brama.com [... recycle ...]
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...] -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
I have seen other threads on this error that suggest looking at the watchdog table, which might be filling up with errors ( via a select * from watchdog). You might try deleting all the records in watchdog, visiting the site then looking at watchdog again to see what info is in there. This isn't a civicrm installation is it? Looks like you've got a thorny one.... Dave -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Max Pyziur Sent: Monday, March 25, 2013 1:25 PM To: support@drupal.org Cc: Earnie Boyd Subject: Re: [support] Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing On Mon, 25 Mar 2013, Max Pyziur wrote:
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
I take it you mean running a script like this: DELETE FROM cache WHERE 1=1; DELETE FROM cache_block WHERE 1=1; DELETE FROM cache_filter WHERE 1=1; DELETE FROM cache_form WHERE 1=1; DELETE FROM cache_menu WHERE 1=1; DELETE FROM cache_page WHERE 1=1; DELETE FROM cache_update WHERE 1=1;
DELETE FROM sessions WHERE 1=1;
(1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days).
Thanks.
I tried this procedure on one site, and it still fails to remove the 503 error. However, this does seem to be the correct area (stored data) to remedy this. New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do work/function. So it isn't the software (PHP and Postgresql), it points to the data.
Max Pyziur pyz@brama.com [... recycle ...]
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...] -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
On Mon, 25 Mar 2013, Metzler, David wrote:
I have seen other threads on this error that suggest looking at the watchdog table, which might be filling up with errors ( via a select * from watchdog). You might try deleting all the records in watchdog, visiting the site then looking at watchdog again to see what info is in there.
The only thing that is showing up in watchdog is information from cron jobs running.
This isn't a civicrm installation is it?
Don't know; what's civicrm?
Looks like you've got a thorny one....
Things are starting to point to there being an authentication problem. Now, I'm wondering if it isn't PHP and one of its setting being different from CentOS 5/PHP5.1 and CentOS 6/PHP5.3. Is there a HowTo for deconstructing Drupal's authentication process? Something like, start at ~/index.php, go to includes/bootstrap.inc, etc?
Dave
Max
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Max Pyziur Sent: Monday, March 25, 2013 1:25 PM To: support@drupal.org Cc: Earnie Boyd Subject: Re: [support] Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing
On Mon, 25 Mar 2013, Max Pyziur wrote:
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
I take it you mean running a script like this: DELETE FROM cache WHERE 1=1; DELETE FROM cache_block WHERE 1=1; DELETE FROM cache_filter WHERE 1=1; DELETE FROM cache_form WHERE 1=1; DELETE FROM cache_menu WHERE 1=1; DELETE FROM cache_page WHERE 1=1; DELETE FROM cache_update WHERE 1=1;
DELETE FROM sessions WHERE 1=1;
(1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days).
Thanks.
I tried this procedure on one site, and it still fails to remove the 503 error.
However, this does seem to be the correct area (stored data) to remedy this.
New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do work/function.
So it isn't the software (PHP and Postgresql), it points to the data.
Max Pyziur pyz@brama.com [... recycle ...]
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...] -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
Watchdog won't have anything in it if Drupal can't connect to the database. Why don't you take the $db_url from the settings.php file of one of the Drupal installations you have already done and put in in the troubled installation, changing just the database name to the appropriate one (ie: keep the user:password@host the same and just change the /databasename). As long as that user has access to the database you are trying to use, everything should be fine. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 3/25/2013 6:55 PM, Max Pyziur wrote:
On Mon, 25 Mar 2013, Metzler, David wrote:
I have seen other threads on this error that suggest looking at the watchdog table, which might be filling up with errors ( via a select * from watchdog). You might try deleting all the records in watchdog, visiting the site then looking at watchdog again to see what info is in there.
The only thing that is showing up in watchdog is information from cron jobs running.
This isn't a civicrm installation is it?
Don't know; what's civicrm?
Looks like you've got a thorny one....
Things are starting to point to there being an authentication problem.
Now, I'm wondering if it isn't PHP and one of its setting being different from CentOS 5/PHP5.1 and CentOS 6/PHP5.3.
Is there a HowTo for deconstructing Drupal's authentication process?
Something like, start at ~/index.php, go to includes/bootstrap.inc, etc?
Dave
Max
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Max Pyziur Sent: Monday, March 25, 2013 1:25 PM To: support@drupal.org Cc: Earnie Boyd Subject: Re: [support] Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing
On Mon, 25 Mar 2013, Max Pyziur wrote:
On Mon, 25 Mar 2013, Earnie Boyd wrote:
Ensure you empty any table with cache* as well as sessions table.
I take it you mean running a script like this: DELETE FROM cache WHERE 1=1; DELETE FROM cache_block WHERE 1=1; DELETE FROM cache_filter WHERE 1=1; DELETE FROM cache_form WHERE 1=1; DELETE FROM cache_menu WHERE 1=1; DELETE FROM cache_page WHERE 1=1; DELETE FROM cache_update WHERE 1=1;
DELETE FROM sessions WHERE 1=1;
(1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days).
Thanks.
I tried this procedure on one site, and it still fails to remove the 503 error.
However, this does seem to be the correct area (stored data) to remedy this.
New Drupal installs of 6.14 to 6.28 on Postgresql 8.4/PHP 5.3 do work/function.
So it isn't the software (PHP and Postgresql), it points to the data.
Max Pyziur pyz@brama.com [... recycle ...]
Earnie
On Mon, Mar 25, 2013 at 1:34 PM, Max Pyziur <pyz@brama.com> wrote:
On Sun, 24 Mar 2013, Jamie Holly wrote:
[... delete for the sake of brevity ...] -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ] -- [ Drupal support list | http://lists.drupal.org/ ]
On 26/03/13 03:35, Max Pyziur wrote:
(1=1 is a kluge I used when I worked on Informix databases; probably unnecessary these days).
I spotted a truncate sql statement in my log the other day. It lead me to the discovery that something had cleaned out my ip2country table.
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/ ]
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/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
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?
If you do this on a database-by-database method, then agreed, logically you might run the risk. However, if you do a pg_dumpall into a one file, all of those roles travel. When you do the restore, you restore all users, functions, procedures, databases, tables, etc.
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.
Good suggestion. I can work with the database from the command line using Postgresql's command line monitor (very much like MySQL's).
What does this test yield?
News at 10. I'll test this; putting out other fires now.
FYI: civicrm is a drupal distribution/module. You'd know if you had it. Sorry for the red herring.
No problem. Thanks for the suggestions. Max
On Mon, 25 Mar 2013, Max Pyziur wrote:
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?
This is clearly a postgresl authentication issue. I made an adjustment to /var/lib/pgsql/data/pg_hba.conf in the IPv6 section, relaxing the constraint. That got all eight or so legacy Drupal 6.x sites running correctly. What is confusing is that the newly installed Drupal 6.x sites functioned correctly w/o this adjustment. Since security is a concern, I would appreciate advice here. I had a similar issue almost two years ago; the following URL from support@drupal.org was key: http://lists.drupal.org/pipermail/support/2011-May/018098.html Thanks to Ivan Sergio Borgonovo on that thread
Earnie
Max Pyziur pyz@brama.com [recycle]
Since you asked for advice: With postgres, How the connection string is formed makes a lot of difference to which methods are used for authentication. For example if I use psql -h mypghost@example.com I will be connecting through the servers ip, but if you say psql -h localhost it will be using the loopback interface these rules can be interpreted differently through hba.conf. I also mentioned the user/owner of the database affects privileges as well. So when you import a postgres database, the database owner makes a big difference. You might have restored the database owner with the restore, but that owner might not exist. Another thing that might account for the difference in behavior between the migrated and imported databases is what user you were logged in as when creating vs. importing the database. Each of these users/database/authentication mechanisms may have different allowed authentication types in the hba.conf. In the end it sounds like you are struggling with which authentication mechanism was chosen for the connection between drupal and postgres. In short there are a lot of variables here, so you may need to consult a postgres support list to untangle the right combination of options for it. Glad you got it working.... Dave -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Max Pyziur Sent: Monday, March 25, 2013 4:27 PM To: support@drupal.org Subject: [support] [Solved, sort of]Re: Authentication problem, was Re: Recent move Drupal 6.22, PHP5.3, PostGresql 8.4 doesn't work - continuing On Mon, 25 Mar 2013, Max Pyziur wrote:
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?
This is clearly a postgresl authentication issue. I made an adjustment to /var/lib/pgsql/data/pg_hba.conf in the IPv6 section, relaxing the constraint. That got all eight or so legacy Drupal 6.x sites running correctly. What is confusing is that the newly installed Drupal 6.x sites functioned correctly w/o this adjustment. Since security is a concern, I would appreciate advice here. I had a similar issue almost two years ago; the following URL from support@drupal.org was key: http://lists.drupal.org/pipermail/support/2011-May/018098.html Thanks to Ivan Sergio Borgonovo on that thread
Earnie
Max Pyziur pyz@brama.com [recycle] -- [ Drupal support list | http://lists.drupal.org/ ]
On 25/03/13 02:18, Max Pyziur 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.
In your position I would be most reluctant to change software versions. My recommendation is that, if possible, you to recreate your broken CentOS 5 system in a VM and run your site on that. Changing everything at once with, I suppose, no planning isn't ideal. fwiw I have D7+Postgres running in a (virtual) CentOS 6 system. There's negligible load (and never will be much), but everything functions okay. I've not tried D6 on it.
Max Pyziur pyz@brama.com
D6 runs fine on CentOS 6. There may be a few stray contrib modules out there that don't like it, but I haven't come across any. Two of my biggest clients are on CentOS 6 and never have a problem. As far as Postgresql, I really can't say. All my clients run on MySQL. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 3/25/2013 10:06 AM, John Summerfield wrote:
In your position I would be most reluctant to change software versions. My recommendation is that, if possible, you to recreate your broken CentOS 5 system in a VM and run your site on that. Changing everything at once with, I suppose, no planning isn't ideal.
fwiw I have D7+Postgres running in a (virtual) CentOS 6 system. There's negligible load (and never will be much), but everything functions okay.
I've not tried D6 on it.
Max Pyziur pyz@brama.com
participants (7)
-
Earnie Boyd -
Jamie Holly -
Jeff Greenberg -
John Summerfield -
Max Pyziur -
Metzler, David -
Walt Daniels