Earlier I’ve been working on an enterprise application running on Drupal. One of the modules required that I update to a PHP 5.2. The server I am using is CentOS release 5.5. Typically, on all my servers I run Ubuntu 10.04 (latest version is 10.10), and I have no issues when it comes to updating any of the packages. CentOS, on the other hand, works in a completely different way.

The latest PHP package in their repository is 5.0 or 5.1, and its updates aren’t as frequent as other releases. Ubuntu updates its repositories on a continuous basis, and checks to make sure that certain software packages work with their system before releasing it to the public for download.

My hurdle to get PHP updated with CentOS is to switch to a different repository. I began by installing remi and epel which are up to date.

wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

Once this was installed, I simply had to update PHP, right?

sudo yum --enablerepo=remi update php*

Unfortunately, no. It kept giving me errors with php-common dependencies and php-mhash. After 20 minutes of trying to figure this out, I promptly removed php-mhash, and did the update. This also updated the MySQL server and things went downhill from here. First problem was permission issues with mysql and the database directories. Once fixed, another issue was the two separate installs of mysql-server for x86 and i386 because of the update through remi. I removed the i386 version and restarted the database server, to no avail.

110113 02:40:09 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
110113  2:40:09 [ERROR] Error message file '/usr/share/mysql/english/errmsg.sys' had only 480 error messages,
but it should contain at least 641 error messages.
Check that the above file is the right version for this program!

Going through the log files and figuring out which errors needed fixing was a mouse hunt. Running short on time, and a meeting looming in the upcoming 30 minutes, it was abandon ship. I copied over the database records and copied it over to another server running MySQL. The current one has no issues with Apache and had the updated version of PHP. I reconfigured the settings file for Drupal so that its aware it will be referencing the dynamic data from a separate server.

Nothing.

I had skipped the step to give access permissions to the database from the external server. I promptly fixed that on the new database server.

GRANT ALL PRIVILEGES ON databasename.* to databaseuser@hostname IDENTIFIED BY "password";
FLUSH PRIVILEGES;

I switched back to the system that was running Drupal, and checked to see if I have access to the database using command line.

mysql -u username -h dbhostname -p password

The connection worked great. I was able to scan the database and view the content in the tables. I fired up the site, and nothing. Looked at the logs for the site, and no errors listed. After my meeting (where I was trying to get this nonsense to work), I came back and just looked through all this mess. The server’s primary error log file, which I never viewed, showed this pathetic term called SELinux, whose headaches I have met last summer on another CentOS server. Looking at the config SELinux and Lo and Behold! This freakin’ thing is enabled.

cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#	enforcing - SELinux security policy is enforced.
#	permissive - SELinux prints warnings instead of enforcing.
#	disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
#	targeted - Only targeted network daemons are protected.
#	strict - Full SELinux protection.
SELINUXTYPE=targeted

# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0

You simply have to change enforcing to disabled, and all of a sudden, the site works!

Back to my previous database issue on the first server. I started by blowing away the MySQL server update obtained from the Remi repository. I then installed it again, this time, without the remi repository as my initial issue was a PHP update and not a MySQL server update.

You can already imagine where this went.

Transaction Check Error:
  file /usr/lib64/mysql/libmysqlclient.so.15.0.0 from install of mysql-5.0.77-4.el5_5.4.x86_64 conflicts with file from package mysqlclient15-5.0.67-1.el5.remi.x86_64
  file /usr/lib64/mysql/libmysqlclient_r.so.15.0.0 from install of mysql-5.0.77-4.el5_5.4.x86_64 conflicts with file from package mysqlclient15-5.0.67-1.el5.remi.x86_64
  file /etc/my.cnf from install of mysql-5.0.77-4.el5_5.4.x86_64 conflicts with file from package mysql-libs-5.1.54-1.el5.remi.x86_64
  file /usr/share/mysql/charsets/Index.xml from install of mysql-5.0.77-4.el5_5.4.x86_64 conflicts with file from package mysql-libs-5.1.54-1.el5.remi.x86_64
  file /usr/share/mysql/charsets/cp1250.xml from install of mysql-5.0.77-4.el5_5.4.x86_64 conflicts with file from package mysql-libs-5.1.54-1.el5.remi.x86_64
  file /usr/share/mysql/english/errmsg.sys from install of mysql-5.0.77-4.el5_5.4.x86_64 conflicts with file from package mysql-libs-5.1.54-1.el5.remi.x86_64

Great. So we’re screwed? Not entirely. I did a check to see what exactly what version of mysql or programs using its libraries are running, which is causing the problem.

yum list installed | grep mysql

mysql-libs.x86_64                         5.1.54-1.el5.remi            installed
mysqlclient15.x86_64                      5.0.67-1.el5.remi            installed
php-mysql.x86_64                          5.3.5-1.el5.remi             installed

From here, all you have to do is remove these and install the ones that aren’t coming from remi. When you’re done this, install the MySQL server. This won’t install the MySQL library for PHP, so make sure to install that as well.

sudo yum remove mysql-libs.x86_64 mysqlclient15.x86_64 php-mysql.x86_64
sudo yum install mysql-server
sudo yum install php-mysql

When you’re done all this, test the database by reconfiguring your settings in Drupal to point to the local database and not the external. Once this works, call it a day and go home.