Last week my personal server was stuck with Plesk 8.6 and PHP 4.3! Having been using PHP 5 for years in commercial projects, I was in shock and couldn’t believe how long it had been since I made any updates to the underlying software in my own box. I needed to install a WordPress plugin that required PHP 5, so I decided this was as good a moment as any to do the right thing and let yum take care of the situation:
Now, it could be because I am still running CentOS 4 here, or because yum didn’t want to mess with Plesk (for good reason), but after installing 250+ updates I ended up with the most up to date possible version of PHP 4.3… ugh.
My next thought was to upgrade Plesk to its latest version in the hopes that it would require my desired updates and thus resolve any dependencies within itself. I’ve been using Plesk for a while and feel pretty comfortable using its Updater tool (except if hosting with Rackspace, you are better off asking them to get it done for you), so I went straight to Plesk 9.5.2 and waited…
No dice… if only other pieces of software had this level of backward compatibility! Well done Plesk, but this was not really what I needed. At this point, I was ready to compile PHP 5 from source, but if you know your control panels, and Plesk in particular, you understand that it is not a good idea to upgrade basic packages independently of the panel software.
Short story long, I Googled the hell out of the issue and couldn’t find a convincing solution, so I decided to go against with my instincts and against my better judgment:
$ yum --enablerepo=centosplus update
This simple command unleashed the longest chain of dependency resolution I have ever seen in my life. Could I have just updated the php and mysql packages? Sure, but if I was going to do something wrong, I had to do it right. In the end I had PHP 5 and MySQL 5 running like I wanted, my blog worked just fine and I finally got to activate that nice plugin… but Plesk was now dead:
ERROR: PleskFatalException
bad column in table: `backup_time` time NOT NULL default '00:00:00',
[...]
Fortunately, as explained here, this is a known issue related to database tables in need of update. The following solved my problem:
$ yum upgrade mysql
$ mysql_upgrade -u admin -p
$ /etc/init.d/mysqld restart
Not all systems are created equal, so be careful if you attempt something similar.
