CentOS - Mar 2013 - PHP Questions on move from CentOS 5.x to CentOS 6.x

Greetings,

A malfunctioning disk this past week accelerated a lingering decision to 
move to CentOS 6.x from CentOS 5.x.

Most of our content is functioning and being presented as it should be.

However, there appear to be php-related issues.

Basic squirrelmail (a php-dependent package) works correctly.

However, drupal, and other php-dependent parts that call postgresql and 
mysql databases  of our site are not being presented.

Apache's log files show a 503 (for postgresql) and 500 (for mysql) errors

I'm troubleshooting this through obvious channels (looking at logfiles, 
searching google, sdiff'ing configuration files).

However, if someone has suggestions or answers, please do speak up!

Much thanks,

Max Pyziur
pyz at brama.com

On 03/24/2013 10:45 AM, Max Pyziur wrote:
> Greetings,
>
> A malfunctioning disk this past week accelerated a lingering decision to 
> move to CentOS 6.x from CentOS 5.x.
>
> Most of our content is functioning and being presented as it should be.
>
> However, there appear to be php-related issues.
>
> Basic squirrelmail (a php-dependent package) works correctly.
>
> However, drupal, and other php-dependent parts that call postgresql and 
> mysql databases  of our site are not being presented.
>
> Apache's log files show a 503 (for postgresql) and 500 (for mysql)
errors
>
> I'm troubleshooting this through obvious channels (looking at logfiles,
> searching google, sdiff'ing configuration files).
>
> However, if someone has suggestions or answers, please do speak up!
The php versions in CentOS-5 and CentOS-6 are different.  You don't say
what version you are using and what version you moved to WRT php.

However, if you were running the default, the versions of software that
run on CentOS-5 might have to be upgraded to run on the newer php in
CentOS-6. (from php-5.1.6 to php-5.3.3)

You might also need to follow the upgrade procedures when moving from
the older version of mysql and postgresql in CentOS-5 to the newer
versions in CentOS-6.  (mysql-5.0.95 to mysql-5.1.67, postgresql-8.1.23
to postgresql-8.4.13)

Upgrading for major versions (ie, from CentOS-5.x to CentOS-6.x) is a
major undertaking and data/configuration files usually have to upgraded. 

This is unlike moving between point releases within the same major
version (ie, moving from 5.8 to 5.9 or 6.3 to 6.4).  This is because
"minor version" upgrades are designed to just work because of
backporting and freezing ABI/API changes inside the Major version ...
whereas changing Major versions is a major upgrade and should be planned
and testing accordingly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20130324/40355858/attachment-0001.sig>

On Sun, 24 Mar 2013, Johnny Hughes wrote:
> On 03/24/2013 10:45 AM, Max Pyziur wrote:
>> Greetings,
>>
[...]
>> However, drupal, and other php-dependent parts that call postgresql and
>> mysql databases  of our site are not being presented.
>>
>> Apache's log files show a 503 (for postgresql) and 500 (for mysql)
errors
>>
>> I'm troubleshooting this through obvious channels (looking at
logfiles,
>> searching google, sdiff'ing configuration files).
>>
>> However, if someone has suggestions or answers, please do speak up!
>
> The php versions in CentOS-5 and CentOS-6 are different.  You don't say
> what version you are using and what version you moved to WRT php.
>
> However, if you were running the default, the versions of software that
> run on CentOS-5 might have to be upgraded to run on the newer php in
> CentOS-6. (from php-5.1.6 to php-5.3.3)
>
> You might also need to follow the upgrade procedures when moving from
> the older version of mysql and postgresql in CentOS-5 to the newer
> versions in CentOS-6.  (mysql-5.0.95 to mysql-5.1.67, postgresql-8.1.23
> to postgresql-8.4.13)
>
> Upgrading for major versions (ie, from CentOS-5.x to CentOS-6.x) is a
> major undertaking and data/configuration files usually have to upgraded.
>
> This is unlike moving between point releases within the same major
> version (ie, moving from 5.8 to 5.9 or 6.3 to 6.4).  This is because
> "minor version" upgrades are designed to just work because of
> backporting and freezing ABI/API changes inside the Major version ...
> whereas changing Major versions is a major upgrade and should be planned
> and testing accordingly.
Thank you.

I'm basically on a stock CentOS 6 system; for clarification, here's what
rpm returns:
rpm -q php postgresql mysql
php-5.3.3-22.el6.x86_64
postgresql-8.4.13-1.el6_3.x86_64
mysql-5.1.67-1.el6_3.x86_64

One correction that took place is to add .php in the Apache directive like 
this (for a mysql-enabled website); it's a virtual host:
AddHandler server-parsed .html .php

Now at least somethings shows, but the screen is also littered with all of 
the variable settings (sometimes typical with mysql/php 
misconfigurations).

I know of upgrading database issues when moving to postgres 9.1; I also 
know of *major* issues when moving from postgis 1.5.x to 2.0.x


MP

On Sun, 24 Mar 2013, Johnny Hughes wrote:
> On 03/24/2013 10:45 AM, Max Pyziur wrote:
>> Greetings,
>>
>> A malfunctioning disk this past week accelerated a lingering decision
to
>> move to CentOS 6.x from CentOS 5.x.
>>
>> Most of our content is functioning and being presented as it should be.
>>
>> However, there appear to be php-related issues.
>>
[...]
> However, if you were running the default, the versions of software that
> run on CentOS-5 might have to be upgraded to run on the newer php in
> CentOS-6. (from php-5.1.6 to php-5.3.3)
>
> You might also need to follow the upgrade procedures when moving from
> the older version of mysql and postgresql in CentOS-5 to the newer
> versions in CentOS-6.  (mysql-5.0.95 to mysql-5.1.67, postgresql-8.1.23
> to postgresql-8.4.13)
In both mysql and postgresql I dumped to text and restored on the new 
CentOS 6 box/server.

For postgresql, that's the recommendation.

So far from command line and their respective command-line monitors, the 
mysql and postgresql databases are correctly functioning.

It's the php-enabled interfaces that are the issue for me.
> Upgrading for major versions (ie, from CentOS-5.x to CentOS-6.x) is a
> major undertaking and data/configuration files usually have to upgraded.
>
Max Pyziur
pyz at brama.com

On Sun, 24 Mar 2013, Reindl Harald wrote:
>
>
> Am 24.03.2013 17:38, schrieb Max Pyziur:
>> In both mysql and postgresql I dumped to text and restored on the new
>> CentOS 6 box/server.
>>
>> For postgresql, that's the recommendation.
>>
>> So far from command line and their respective command-line monitors,
the
>> mysql and postgresql databases are correctly functioning.
>>
>> It's the php-enabled interfaces that are the issue for me
>
> and what says "php -m" or "rpm -qa | grep php"?
On CentOS 5
php-5.1.6-39.el5_8
php-cli-5.1.6-39.el5_8
php-common-5.1.6-39.el5_8
php-devel-5.1.6-39.el5_8
php-gd-5.1.6-39.el5_8
php-ldap-5.1.6-39.el5_8
php-mbstring-5.1.6-39.el5_8
php-mcrypt-5.1.6-15.el5.centos.1
phpmyadmin-2.11.11.3-2.el5.rf
php-mysql-5.1.6-39.el5_8
php-pdo-5.1.6-39.el5_8
php-pgsql-5.1.6-39.el5_8


On CentOS 6
php-5.3.3-22.el6.x86_64
php-cli-5.3.3-22.el6.x86_64
php-common-5.3.3-22.el6.x86_64
php-enchant-5.3.3-22.el6.x86_64
php-gd-5.3.3-22.el6.x86_64
php-IDNA_Convert-0.8.0-1.el6.noarch
php-ldap-5.3.3-22.el6.x86_64
php-mbstring-5.3.3-22.el6.x86_64
php-mcrypt-5.3.3-1.el6.x86_64
phpMyAdmin-3.5.7-1.el6.noarch
php-mysql-5.3.3-22.el6.x86_64
php-pdo-5.3.3-22.el6.x86_64
php-pear-1.9.4-4.el6.noarch
php-pgsql-5.3.3-22.el6.x86_64
php-php-gettext-1.0.11-3.el6.noarch
php-PHPMailer-5.2.2-1.el6.noarch
php-process-5.3.3-22.el6.x86_64
php-simplepie-1.3.1-3.el6.noarch
php-xml-5.3.3-22.el6.x86_64

Diffing php -m results:
  sdiff -s phpM-CentOS6.txt phpM-CentOS5.txt
Core							      <
dom							      |	dbase
enchant							      <
ereg							      <
fileinfo						      <
filter							      <
json							      <
 							      >	mime_magic
Phar							      <
readline						      |	pspell
sqlite3							      <
xmlreader						      <
xmlwriter						      <
xsl							      <
zip							      <
 							      >




> are the extensions installed/loaded?
Please clarify; what extensions?


MP
pyz at brama.com

On Sun, 24 Mar 2013, Johnny Hughes wrote:
> On 03/24/2013 10:45 AM, Max Pyziur wrote:
[...]
>> Apache's log files show a 503 (for postgresql) and 500 (for mysql)
errors
>>
>> I'm troubleshooting this through obvious channels (looking at
logfiles,
>> searching google, sdiff'ing configuration files).
>>
>> However, if someone has suggestions or answers, please do speak up!
>
> The php versions in CentOS-5 and CentOS-6 are different.  You don't say
> what version you are using and what version you moved to WRT php.
>
> However, if you were running the default, the versions of software that
> run on CentOS-5 might have to be upgraded to run on the newer php in
> CentOS-6. (from php-5.1.6 to php-5.3.3)
>
> You might also need to follow the upgrade procedures when moving from
> the older version of mysql and postgresql in CentOS-5 to the newer
> versions in CentOS-6.  (mysql-5.0.95 to mysql-5.1.67, postgresql-8.1.23
> to postgresql-8.4.13)
>
> Upgrading for major versions (ie, from CentOS-5.x to CentOS-6.x) is a
> major undertaking and data/configuration files usually have to upgraded.
>
> This is unlike moving between point releases within the same major
> version (ie, moving from 5.8 to 5.9 or 6.3 to 6.4).  This is because
> "minor version" upgrades are designed to just work because of
> backporting and freezing ABI/API changes inside the Major version ...
> whereas changing Major versions is a major upgrade and should be planned
> and testing accordingly.

The problems are separated here (divide and conquer). The PHP/Mysql 
websites now function.

The issue was a default directive in /etc/php.ini; the directive is 
short_open_tag. On CentOS 5 it is on; on CentOS 6 is off. Dropping the 
following into relevant .htaccess files:
php_value short_open_tag 1

fixed the problem.

On the PostgreSQL/Drupal/PHP side: I installed four minor releases of 
Drupal (6.14 -> 6.28), creating new test sites. Each works as designed.

So the PHP/PostgreSQL stack isn't the problem.

Existing websites (using Drupal releases ranging from 6.14-> 6.22) are 
where the errors are occuring. One person suggested deleting cache* 
content and session* content in relevant tables. That hasn't restored 
things; but the hunch now is that it is somewhere in the data.

fyi,

MP
pyz at brama.com