Running Panther Server: Setting up a blogging system

Posted by Pierre Igot in: Macintosh
May 25th, 2004 • 7:41 am

On the Xserve that I administer, we have a web site that we want to redesign and improve so that it can have more dynamic content that can be easily authored by people with little experience in web page design.

The idea is to set up a blogging system that will be used to handle the dynamic portion of the site, without presenting it as a completely separate entity. In other words, we want to try and integrate the dynamic content with the regular static content as much as possible.

Obviously, in the past year and a half, I personally have acquired a certain amount of experience with blogging tools, and I figured that I should be able to take things to the next level and try setting up a blogging system myself. The blog that you are reading now is hosted by a third party, whose hosting service includes PHP and MySQL support. In other words, until this past week-end, I had never had to install and configure PHP and MySQL myself on any kind of server. But I knew that Mac OS X Server 10.3 came with the required tools, and my own blogging adventures of the past year had given me at least some experience with MySQL. (In addition, I have experience with using FileMaker Pro Unlimited to serve dynamic content on a Mac server. CDML scripting and FileMaker database management are definitely not in the same league as PHP and MySQL, but I had some idea of the mechanisms involved.)

First, however, there was the issue of that MySQL bug in the early versions of Panther Server that I had read about while I was planning for this new blogging system. I knew that the bug had been fixed in 10.3.3, but my Xserve was running 10.3.1, so I had to update it. This was my first real system update on the Xserve, and I obviously needed to take a number of precautions: creating a complete bootable backup of the startup volume with 10.3.1 on the other hard drive module in the Xserve, just in case; and then making sure that the update would take place at a time when the Xserve’s various services (web and mail mostly at this point) would not be in heavy demand. Yesterday (Victoria Day here in Canada) was the perfect opportunity, and the whole process was pretty quick and went very smoothly. It even had the added benefit of fixing the automatic login bug that had plagued my system since Day 1!

Next up was PHP. That part was easy. A recent flavour of PHP is included in Mac OS X Server 10.3, and it’s just a matter of turning it on using the Server Admin application.

MySQL was a different matter entirely. I did some reading before taking the plunge, but it mostly added to my existing confusion.

Apple’s own documentation is sorely lacking. MySQL is barely mentioned in the Panther Server manuals. The MySQL Manager utility included with Panther Server and referred to in the manuals is a bare-bones tool with a single “Start/Stop” button and gives you absolutely no clues in terms of additional configuration. And then the web page about “MySQL on Mac OS X” in Apple’s Developer Connection is badly out of date. The fact that the page doesn’t have a date (already a bad thing in itself) can’t hide the fact that all the screen shots included are from Jaguar Server. And most of the page is devoted to creating the appropriate mysql user and group — when in fact these already exist in Panther Server. In other words, it’s pretty much useless.

Then I referred to Marc Liyanage’s page on MySQL, which provides a link to the appropriate download at and some installation instructions. But here again, these instructions refer to “MacOS version 10.2[sic]. And MySQL was supposed to be already installed on my machine, so I was mostly interested in what to do next. Marc Liyanage also provided links to the instructions on the web site.

That’s when I discovered that, yes, MySQL is already installed in Panther Server, but it’s not installed in the expected location! Instead of being in /usr/local/mysql, it’s actually in some other place in the system. So all the instructions on Marc Liyanage’s page and on the web site were wrong for this existing version of MySQL! Given that I am really not that familiar with Unix, I figured that trying to adapt these instructions to my configuration was a recipe for trouble. I tried for a while, but couldn’t get things to work properly, and couldn’t find some of the things that I needed, such as an easy way to configure MySQL so that it would start up automatically every time I had to restart the server.

In addition, the Marc Liyanage web site promised a smooth, package-based installation with the version downloaded from the web site. And it was a more recent version than the one already installed on my machine (4.0.20 versus 4.0.18). Based on what I was reading on these web sites, having an existing version of MySQL installed wasn’t really a problem. So, in light of the fact that Apple provided no documentation, I decided to follow their instructions and install the 4.0.20 version from the package downloaded from the web site.

The first sign that I had made the right choice was that the installer disk image actually included two installers, one for MySQL itself and one for the MySQL Startupitem that I needed to make sure that MySQL would start up automatically when restarting the server. I installed both, and using the Terminal I finally found things in the expected place, i.e. in /usr/local/mysql. (I haven’t tested the Startupitem yet though, so I hope it works. I haven’t checked that.)

Then came the first difficulty, which was to configure MySQL to run properly. The web site warns you that the default installation is not secure and that you need to do a number of very Unix things first, such as changing the privileges for some directories, and defining passwords, etc. I must admit that I found the instructions for this somewhat confusing. They probably aren’t that confusing for someone who’s more comfortable in Unix, but being a relative novice, I struggled for a while — especially since I had to master not only the Unix syntax of the commands I needed, but also the MySQL syntax needed to manage and use MySQL. (And it doesn’t help that there are often several different ways of doing the same thing — which is good in a graphic UI environment, but not so good in a text-based command-line environment.)

In addition, the only real way to find whether things were working fine was to install the blogging system and try to get it running. I elected to install WordPress 1.2, because I had just read some positive stuff about it, including the fact that it was entirely free and would remain free, unlike some other well-known systems. I could have elected to install the relatively cheap pMachine system that I am using for my own blog — and I might still do that, depending on whether we are satisfied with WordPress’s features or not — but WordPress seemed to be an interesting alternative, especially with its support of more user-friendly URLs for permanent links, which might be important in light of our need to integrate our dynamic content with our static content as seamlessly as possible.

After it looked like I had MySQL up and running, I followed the 5-minute installation instructions for WordPress 1.2. I had created a database in MySQL and thought I could just use the default user (root) as the user that WordPress would use to access the database. But when I entered that information in the WordPress config file and loaded it, I hit the first major snag. The WordPress installation process (a PHP script) would report either that it couldn’t find my database or that it thought that the database had the name “wpblogs”, which was indeed the name that I had chosen — but still it couldn’t actually access it and proceed with the creation of the required fields for WordPress.

The WordPress project is still fairly new, as far as I can tell, and since it’s entirely open source, its documentation is still very much a work in progress. There was no mention of my problem on the “Common Installation Problems” page, so I headed to the forums and tried a search. I did find a number of users reporting the same problem, and they did get some responses — but not exactly responses that were explicit enough. I ended up half-guessing that maybe “root” couldn’t be used to access the database — even though I had granted it the required privileges in MySQL. (I tried using the “mysql” user as well, but that didn’t work either.)

But how was I supposed to create a new user specifically for the blogging system? I knew that there were web-based tools that could be used to manage MySQL through a web-based interface rather than through the command line, and I had already used phpMyAdmin for my own blog, so I decided to install that. Of course, I had never actually installed phpMyAdmin myself before either. (It was already installed and configured on my host’s server.) Here again, I had to learn as I went. At that stage there were quite a few new things that my brain had had to process during the day, and I was getting dangerously close to overloading it. I couldn’t figure out the installation instructions for phpMyAdmin right away, so I just gave up and went back to the web site, hoping to find the required information in this enormous set of web pages with tons of instructions for all kinds of things that didn’t apply to me or that I didn’t need.

I finally found out how to “grant” privileges to another user in MySQL, did that, and tried loading the WordPress config page again. Still no cigar. I am starting to get used to this requirement that server config instructions often omit to mention, which is that you need to quit and relaunch processes and services to get them to actually “take” the change you’ve just made. Nobody tells you that. (It applies to a number of things in Panther Server’s own Server Admin application, even though the UI never gives any indication that a restart of the service is needed.) So I shut down MySQL and started it up again. (After several tries, I had finally learned how to do that properly and had recorded the exact commands in a safe place.)

Then I tried the WordPress config thing one more time. Bingo! This time WordPress seemed to be able to establish the connection with my database. I went through the first couple of steps in the installation process without any problems. On the third page, however, I got an alarmingly long list of error messages, followed by a paragraph saying that WordPress was now up and running and I could start using it. Ahem. I tried it, just for fun, and quickly realized that, while the environment as a whole seemed to be working, a number of things were not, including references to categories, etc. Since I had fiddled quite a bit with permissions and wasn’t quite sure of exactly what I had done when, I decided to go over things one more time, i.e. the basic MySQL stuff first, then the user for the blogging system, then the WordPress config itself.

But for that I needed to delete the stuff that WordPress had managed to create in the MySQL database during the half-failed installation. Again, I tried to find some fairly easy instructions in the enormous documentation, but it was just too mind-boggling. Since I had done this before with phpMyAdmin, I went back to that beast, and decided to figure the installation instructions out. I finally did, and got phpMyAdmin running. I used it to select all the things created by WordPress (easy, they all start with “wp_”) and “drop” them, which is MySQL parlance for deleting them. (You just have to know those things.)

Then I redid the permissions thing for the mysql directory and mysql’s data directory. Then I granted the appropriate privileges to my new MySQL user. Then I launched the WordPress installation process all over again.

Finally, it worked. No error messages during the installation. And the blogging system was up and running. Of course, now that I was feeling more upbeat about the whole thing, I tried to configure a few things in the blogging system itself, including the use of user-friendly URLs for permanent links.

The WordPress installation process had warned me that an extra Apache module called “mod_rewrite” would be needed for some features, but I figured I would get to that in due time. Well, the time was now. The user-friendly URLs feature definitely required the mod_rewrite module. I tried to search the Panther Server documentation to see if it made any mention of it. No cigar. I searched the Mac OS X Hints database. Nothing useful. I tried Google, and of course found quite a few references to the module, but never in relation to Panther Server, except for this page, which says that Panther Server “comes with mod_rewrite built in and turned on for the default apache“. Great, I thought, and proceeded to follow that page’s instructions, using the rewrite rules provided by the WordPress settings page.

The only problem is that it didn’t work. By that time, it was getting late, and I had spent the whole day working on the thing. I figured that I had made enough progress already, and that this final step in the configuration of my blogging system could wait another day.

What all this shows, however, is that using Panther Server to run anything beyond what’s covered by the Server Admin UI is fairly challenging for a non-Unix type such as myself. It’s not extremely difficult, but there is so much new information to process, with so many different conventions depending on which tool you are using, that it takes a lot of time and patience. For example, yesterday I learned that the command to decompress a .gzip file is gzip with the -d argument (as in “decompress”), but the command to decompress a .tar file is tar with the xf argument (as in “extract file”, I think). Two different Unix commands, two different syntaxes for what appears to be the same thing (decompressing a compressed file). I am sure that there is a history behind this, but, as a Mac user, obviously, it escapes me. Oh well.

Don’t get me wrong. I love learning how to do stuff, and there’s definitely a great feeling of satisfaction when you finally get powerful tools up and running. And I don’t mind the learning process if that’s the cost to pay for such powerful tools to remain free. (I don’t mind sharing my experience with others as a form of payback either.) It certainly is much more pleasant to go through a learning curve with free software than it is when you’ve paid hundreds of dollars for a software product and find that the software company is obviously utterly unable to use the money to make the software more usable. (I don’t need to give names here.)

However, all this means that the Xserve/Panther Server combination is still far from being a “server for the rest of us” type of solution. It is probably closer to that goal than any other solution out there, but there is still a very long way to go. Indeed, my experience as an experienced Mac user with this solution seems to indicate that, in the grand project of providing a truly user-friendly server experience, Apple is really just getting started.

Comments are closed.

Leave a Reply

Comments are closed.