Wesley's Tool-Box

With marriage, I moved into the new home. This meant moving everything out, including the servers. However, I was not sure of the quality of internet connection that the new place would provide, so I relocated the KT line (fiberoptic-to-ethernet 100Mbps line) first, and along with it, the Intel Mac mini which hosts XiGL.net on early April. Hanaro line (same quality as KT line) and its accompanying G4 Mac mini which hosts Tool-Box.info would be left behind for the time being.

It turns out that KT did not provide the 100Mbps connection at the new home, but only the traditional 30Mbps VDSL line. This persisted for several months and I did not see any sign of them upgrading to 100Mbps fiberoptic, all the while the competitors Hanaro and LG Powercomm were both providing 100Mbps line services of their own since at least May. My patience ran out, leading me to call Hanaro Telecom to relocate my connection. This would also mean that Tool-Box.info server would be moved to the new home as well.

Had I simply moved the old G4 box, the relocation would have been simple. But I decided to use this opportunity to replace the server hardware outright. That's when the trouble began.

You see, the plan was to transfer the server contents out of the G4 Mac mini and into the new Core 2 Duo iMac that I got as a wedding gift last May. Not only would this boost the performance, but have the server backend get automatically upgraded.

A. The Base

I've backed up and restored the server several times before, and I also have attempted to change the server to a Windows box once, so I had the basic procedures nailed down. The easiest part was obviously backing up the contents and copying them onto the new server. It's the 'getting things up and running again' part that led me to stay up until 4:30AM last morning.

First, I had to prepare the hosting environment. The old server ran Mac OS X Tiger (10.4) client along with its integrated Apache HTTP server version 1.3. PHP 5 was installed using Mark Liyanage's package, and MySQL 5 was installed using the official binary bundle. On the other hand, the new server was running Mac OS X Leopard (10.5) client, which was preloaded with Apache 2.2 and PHP 5. So I didn't need to install those again - just MySQL 5. After installing MySQL 5 and setting up the users, I needed a couple of tweaks so the 'MAMP (Mac/Apache/MySQL/PHP)' was working.

1. In /private/etc/apache2/httpd.conf file, remove # from LoadModule php5_module libexec/apache2/libphp5.so entry

2. Make /private/etc/php.ini by duplicating /private/etc/php.ini.default, and then add /private/tmp/mysql.sock at the end of mysql.default_socket = and mysqli.default_socket = entries

3. Apply other necessary customizations to httpd.conf and php.ini files as they were applied at the old server

B. The Transfer

With this done, I installed phpMyAdmin. I use it to effortlessly move the database structure from the old server to the new, and if this is running without errors, it meant that the MAMP itself is running properly, so it's a prerequisite to any server transfer. I discovered a small hitch where exporting the database to a file using compression truncated data after a certain point, though. The solution was to not use any compression to generate the export file.

After the database was in place, I moved the files from the old server to the equivalent place at the new server via tar archiving. By using sudo tar -cpzvf (archive file) (target folder/file) parameters. the file permissions and the structure were preserved. It would then be unarchived using sudo tar -xpzvf (archive file).

Certain permissions were no longer relevant, so I checked and corrected them as needed. Serendipity Weblog System (s9y)'s main folder, as well as certain files (.htaccess and serendipity_config_local.inc.php) and folders (archives, plugins, templates, templates_c, uploads) were granted owner and read/write privilege to web server daemon (sudo chown www (folder/file) and sudo chmod 644 (file) / sudo chmod 755 (folder)) so the files could be manipulated via s9y. Other files and folders were given regular permissions.

C. The s9y Hiccups

Confident that everything was checked and ready, I activated the web server. Fortunately, s9y was running as expected. The next step was upgrading s9y to the latest version. The web server was turned off and I replaced the installed files, making sure the plugins, templates, and uploads folders were retaining my custom files during the process. Then I turned the web server back on and accessed the main page. Sure enough, upgrade guidance page popped up. Everything looked okay, so I told it to proceed to upgrading. That's when a problem arose. Apparently, the user I created for just accessing s9y's database did not have ALTER privileges that the upgrade process needed, and lots of warnings were displayed regarding how it could not perform certain upgrade actions because of that.

I restored the database and files to previous state. Remembering a similar problem hitting me before, I told MySQL something like this:

GRANT ALTER ON bankaccount.* TO 'custom'@'localhost';

Basically, it was INDEX the last time and ALTER this time, but the essence of the problem and solution was the same. I put the new files in and redid the upgrade process. This time, everything ran without a hitch. s9y was updated to the latest. The good thing about going new was that the spam protection system for the comments section became robust, so I can turn on that function again. With the old version, spam flooding was a major problem, and I had to completely kill the comments function.

Moving on, I performed some tests on creating entries, and the image uploading function was found to be a bit problematic. I don't exactly remember how I got the automatic thumbnail creation working on the old server, but this time I wanted to use ImageMagick to do that and I couldn't get it to run properly. The official OS X binaries were used and the instructions were followed to the letter, but thumbnail creation process would die with error 5.

It turned out that the environmental variables that need to be set in order for the programs to function correctly were wiped out after one session. It never remained persistent. That's why ImageMagick malfunctioned. I tried various solutions, but in the end the program worked fine only in a Terminal window. s9y couldn't use it in any case. So I ended up putting the folder at the root and used SetFile to hide it from Finder. This way, the program would find the necessary files at the first place it would look for and execute the commands properly.

D. The Virtual Hosts

Now that the blog was functioning as I required, I made some tweaks to accommodate the new features of the new version. Tool-Box.info on the new server was ready to roll. I still needed to have a separate XiGL.net page running, so I activated the Virtual Hosts function of the Apache server. This is done by removing # from the Include /private/etc/apache2/extra/httpd-vhosts.conf line in /private/etc/apache2/httpd.conf file.

Of course, the actual virtual hosts need to be set up, so I edited the /private/etc/apache2/extra/httpd-vhosts.conf file as well. The sample setup in the file could be used as is mostly, but it had some quirks. For some reason, ErrorLog and CustomLog entries need to be commented out. Otherwise, the whole website wouldn't run at all. Also, once the virtual hosts were running, the XiGL.net page would return error 403 (Forbidden), meaning that access permissions were somehow set wrong. It turns out that I needed to enable access by means of a directive. I appended something like this at the end of the file:

<Directory "/Somewhere/Somesuch/Second">
Order allow,deny
Allow from all
</Directory>

This took care of the permissions problem. Finally, both Tool-Box.info and XiGL.net websites were running on the new server as I had intended. I can now shut down the old server and recycle it for other uses. Phew.