Getting WordPress 2.5.1 Going on RHEL3
Tuesday, May 27th, 2008
It came up amongst my fellow developers that having a simple blogging install on one of the machines would make it easier for them to maintain a list of what they do each day, and therefore make the creation of monthly reports a lot simpler. Seems reasonable, as I keep a simple HTML journal each day, and converting it to WordPress would be very nice. So I set out to do just that.
The first thing was identifying a machine. Since the requirements for WordPress are PHP 4.3 and MySQL 4.0, it would have been nice to have found an RHEL5 box that could be used, as RHEL5 has those in the standard install RPMs. But that was not to be. I did, however, have a good RHEL3 box that I could use. Unfortunately, the MySQL RPMs with RHEL3 were at 3.2.x - no good. So I had to do some searching.
I ended up finding what I needed at the MySQL web site and downloaded:
MySQL-client-standard-4.1.22-0.rhel3.i386.rpm
MySQL-devel-standard-4.1.22-0.rhel3.i386.rpm
MySQL-server-standard-4.1.22-0.rhel3.i386.rpm
MySQL-shared-compat-4.1.22-0.rhel3.i386.rpm
I also had to get the PHP RPMs from the CentOS site:
php-4.3.2-40.ent.i386.rpm
php-mysql-4.3.2-40.ent.i386.rpm
php-pgsql-4.3.2-40.ent.i386.rpm
and then I was ready to go. Or so I thought.
The default install for MySQL places the data files in /var/lib/mysql and that worked great. The problem was that I wanted to have them in a different location. Ideally, all I'd need to do was simply move them and put in a symlink back to the /var/lib/mysql directory. But it was not that simple due to where I wanted to put the files and the rules governing placement there.
Basically, I was unable to set the user/group for the files in the location I wanted to put them based on some rules in-place by the Unix engineering team. Understandable, I just needed to find another way. The simplest way to make it work was to have the MySQL server run as another user - in this case, gomer. The trick was that it wasn't that simple to figure out all the places it needed to be changed. In the end, I was able to get it by using the following file as /etc/my.cnf - the default configuration file for MySQL:
#
# Point the MySQL server to this location for the databases
#
[mysqld]
user=gomer
basedir=/home/data/rooster/
datadir=/home/data/rooster/mysql
socket=/home/data/rooster/mysql/mysql.sock
[mysql.server]
user=gomer
basedir=/home/data/rooster/
[client]
user=gomer
socket=/home/data/rooster/mysql/mysql.sock
where the location of the files is /home/data/<machine>, and in this case the machine name is rooster. I chose this to make it easy to distinguish the data files for one instance from another - put the machine name in the path and you're pretty sure to not have conflicts.
With this, I could start and run the MySQL server without error. Whew! That was an important step to take. Now we need to get PHP talking to MySQL. In order to do this we need to edit /etc/php.ini and set the MySQL socket reference to:
; Default socket name for local MySQL connects. If empty, uses the
; built-in MySQL defaults.
mysql.default_socket = /home/data/rooster/mysql/mysql.sock
and then restart the web server with:
/etc/init.d/httpd graceful
The next thing to do is to create the user and database for WordPress to hold all it's information. Interestingly, what you need to do is to make the database first, and then assign the rights to the user (thus creating a new user in the process). To do this, we first need to log into MySQL as the root MySQL user and create the database:
mysql -u root -p
and enter the root MySQL password. Then create the database:
create database wp_drbob;
I've chosen the convention wp_login so that the databases are easy to tell apart. Then you need to assign right to that database to a new user:
grant all on wp_drbob.* to drbob@localhost identified by "coder";
where the last argument is the new password for the local account. At this point you can verify the user's database is set up properly by logging out of mysql with a quit and then log in as the new user:
mysql -u drbob -p
...and enter the new password (coder), and then have a look at all the available databases:
mysql> show databases;
+------------+
| Database |
+------------+
| test |
| wp_drbob |
+------------+
2 rows in set (0.01 sec)
One little wrinkle with the PHP 4.3.2 using the MySQL 3.23.58 Client API is that the passwords in MySQL 4.1.22 are stored in a slightly different way. This means that you need to do the following in order to get the password into the old format for PHP. Log in under the root MySQL account:
mysql -u root -p
give it the root MySQL password, and then issue to following:
mysql> UPDATE mysql.user
-> SET password=OLD_PASSWORD('coder')
-> WHERE user='drbob'
-> AND host='localhost';
Query OK, 1 row affected (0.00 sec)
the flush this out to the system:
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
At this point we have a database and we're ready to install WordPress and configure it.
Assuming that the WordPress distribution is in a tgz file called wordpress-2.5.1.tar.gz then as the user gomer go to the location where the blogs are going to be stored and unpack the distribution. It'll be named wordpress - change the name to the user's login (our convention here again). This looks like:
$ cd /home/data/rooster/blogs
$ sudo su gomer
$ tar zxvf wordpress-2.5.1.tar.gz
$ mv wordpress drbob
at this point, you need to go into that directory, rename the file wp-config-sample.php to wp-config.php and then edit it and put in the correct values for the database connection:
// ** MySQL settings ** //
define('DB_NAME', 'wp_drbob');
define('DB_USER', 'drbob');
define('DB_PASSWORD', 'coder');
define('DB_HOST', 'localhost');
You can then install WordPress by going to the web page: http://server/blogs/drbob/wp-admin/install.php (assuming that you have the directory symlinked into the var/www/html/ directory of the web server). This will pull up a simple page where you can set the name of the blog and the email address of the administrator. They will receive an email with the login information which they can then use and customize as they see fit.
It's certainly no easy, and a lot of the little details took me hours to figure out. But in the end, I have something that's working and it's not too terribly hard to set up another. That was the goal, and it's achieved. Good enough.
