PHP 5.3.x from 5.1.6 on Plesk

[KrazyBob]

I am about to upgrade PHP from 5.1.6 to 5.3.x and I know of numerous horror stories. I have the Atomic installer and Plesk 9.x on these servers. Are there any hidden gotchas to consider? I will also be upgrading MySQL while I'm at it and that has always been fun even when following directions. I learned that I have to stop MySQL first, run the Plesk update, disable Berkley, restart Pleskyada, yada, yada. Again, any hidden gotchas? I don't like upgrading production servers. Seldom something goes sideways.

I'm sorry to sound like a total noob but I live out of a hospital with an ill child, I'm tired and burned out, and frankly don't want to screw with updating 25 servers.

But it has to be done.

[breun]

I am about to upgrade PHP from 5.1.6 to 5.3.x and I know of numerous horror stories. I have the Atomic installer and Plesk 9.x on these servers. Are there any hidden gotchas to consider?

Make sure that you know about the non-hidden gotchas: http://www.php.net/migration53

[Highland]

There's a wiki page on Mysql
http://www.atomicorp.com/wiki/index.php/Mysql

I've not had any issues with PHP packages and upgrading but definitely heed breun's cautions. If you use stock open source programs (like Wordpress) you shouldn't have any issues.

Hope your child gets well.

[faris]

I learned that I have to stop MySQL first

I didn't know this. I'm surprised that stopping MySQL would be required. I'd also have thought that the update would have to start mysql if it was found to be down as otherwise the tables could not be updated? But there you go - these are the many mysteries of Plesk.

Anyway, if you have ASL installed then you might need to disable psmon as well, as it might try to restart a stopped service at exactly the wrong time.

[breun]

AFAIK there is no need to stop MySQL before upgrades. The RPM scriptlet in the mysql-server package takes care of restarting the MySQL daemon:

Code: Select all

# rpm -q --scripts mysql-server
(...)
postuninstall scriptlet (using /bin/sh):
if [ $1 -ge 1 ]; then
    /sbin/service mysqld condrestart >/dev/null 2>&1 || :
fi

[KrazyBob]

AFAIK there is no need to stop MySQL before upgrades. The RPM scriptlet in the mysql-server package takes care of restarting the MySQL daemon:

Code: Select all

# rpm -q --scripts mysql-server
(...)
postuninstall scriptlet (using /bin/sh):
if [ $1 -ge 1 ]; then
    /sbin/service mysqld condrestart >/dev/null 2>&1 || :
fi

I have found on Plesk servers (all that I own) Berkley needs to be removed and MySQL restarted. It appears that the Atomic upgrade instructions have changed for PHP and MySQL. My older servers still have Plesk 8 on them and the newer have Plesk 9. I am aiming for the newest Plesk 10 and holding my breath. Plesk NEVER installs the current ANYTHING it seems. We are limited on OS to Centos 4.9 and current patches because Parallels changed their marketing of Virtuozzo licenses. After spending over $100 on HSP, Perpetual Virtuozzo licenses and Perpetual Licenses, Plesk now leases licenses and will not grandfather us older partners. It freakin' sucks.

Here are the old instructions:

Linux - Upgrading mySQL

Installation
To Upgrade to Mysql 5.1 on CentOS/RHEL/Fedora

Steps 3 and 4 only apply if you are upgrading from MySQL 5.0.x See version differences in following link http://dev.mysql.com/doc/refman/5.1/en/ ... eries.html

Step 1) Set up the atomic channel (See Getting_Started):

wget -q -O - http://www.atomicorp.com/installers/atomic | sh
Step 2) Upgrade to Mysql 5.1

yum upgrade mysql
Step 3) MySQL 5.1 removed the BERKLEY storage engine. Since it was not commonly used, to save resources it was recommended this be turned off. You must comment the following out or remove it from /etc/my.cnf or MySQL 5.1 will not start!

skip-bdb

Step 4) Update your MySQL tables

#mysql_upgrade -u root -p


or for Plesk environments (and then the NOTE - this is the exact same login as the Plesk superuser e.g. use "-u admin" and then your admin password):


mysql_upgrade -u admin -p


Step 5) Restart mysql

/etc/init.d/mysqld restart
[edit] Support Packages
Mysqltuner, an excellent tool for investigating performance issues with mysql


yum install mysqltuner
[edit] Known Issues
[edit] MySQL Library Differs
When using some tools (most notably PHPMyAdmin) you may get a notice like this

Your PHP MySQL library version 5.0.90 differs from your MySQL server version 5.1.50. This may cause unpredictable behavior.
This message can be safely ignored. The reason that the library cannot be upgraded with the server is that, in Enterprise Linux, everything is compiled around the old library. Upgrading the library would break a number of programs compiled against it so, for compatibility's sake, it must remain as the one provided by the vendor directly.

If you REALLY need the latest libraries you can recompile php from the SRPMS.



Problems with MySQL databases and PLESK 9 after upgrade
If you get the following error after upgrading when you try to log into PLESK then you need to upgrade your database tables:

ERROR: PleskFatalException
bad column in table: `backup_time` time NOT NULL default '00:00:00',
[...]

Issue the following command from the shell:

mysqlcheck --check-upgrade --all-databases --auto-repair -u admin -pyouradminpassword
followed by:

cat /usr/share/mysql/mysql_fix_privilege_tables.sql | /usr/bin/mysql --no-defaults --force --user=admin --password=youradminpassword --host=localhost --database=mysql
This script updates all the mysql privilege tables to be usable by the current version of MySQL.

References:

[1] http://dev.mysql.com/doc/refman/5.0/en/ ... grade.html

[2] http://forum.parallels.com/pda/index.php/t-85461.html

[breun]

I have found on Plesk servers (all that I own) Berkley needs to be removed and MySQL restarted.

BDB was removed from MySQL. You only needed to change your configuration if you had BDB-specific settings in /etc/my.cnf. If you're going to change your MySQL version, I recommend reading the release notes of the new version first. (And testing doesn't hurt either.)

Plesk NEVER installs the current ANYTHING it seems.

Plesk just works with whatever your OS provides (or whatever you added to that using third party repositories like ART). I'm actually very glad Plesk works this way.

[faris]

Seems to me that you could comment out or remove "skip-bdb" right at the start before you do anything at all, which would avoid any problems. The config change would only come into effect when mysqld was restarted, and even if this happens at the plesk update stage rather than at the mysql upgrade stage, it should not do any harm. But obviously I'd test it first as Breun suggests.

I've not read the docs but just in case anybody is wondering, I'd assume that without the Berkeley plugin, the skip-bdb command in my.cnf would not be understood, causing mysqld not to restart due to what would effectively be a syntax error in the configuration.

Why mysqld (and apache et al) can't deal with this type of situation like certain other apps (which simply display a warning to say an unparsable line was found in the config rather than refusing to start) is a mystery to me, but no doubt there's a good reason.

[breun]

Seems to me that you could comment out or remove "skip-bdb" right at the start before you do anything at all, which would avoid any problems.

This is correct.

I've not read the docs but just in case anybody is wondering, I'd assume that without the Berkeley plugin, the skip-bdb command in my.cnf would not be understood, causing mysqld not to restart due to what would effectively be a syntax error in the configuration.

Indeed, that's exactly what happens.

Why mysqld (and apache et al) can't deal with this type of situation like certain other apps (which simply display a warning to say an unparsable line was found in the config rather than refusing to start) is a mystery to me, but no doubt there's a good reason.

Just a guess: the user might not see the warning (for instace when upgrading the RPM using some automated process) and the software might run in a way that's undesirable (no auth, wrong buffer settings, etc.). The devs probably want to avoid such scenarios.

[scott]

FYI, there are a bunch more configuration settings that are retired in 5.5 that will cause mysqld to exit 1.