Recently in Movable Type Category

Don't let anybody fool you. If you want to do anything in Movable Type, you'll be neck-deep in arcane MT tags and Javascript before you know it. These "instructions" on how to deploy threaded comments are an example of this.

If this works, I'll eat my hat. I'll have to find a hat, which I will then eat.

After Andrew Hurvitz moved Here in Van Nuys from Blogger to WordPress, something I've never done (moving a blog from one platform to another), I decided to do a test.

I made a backup of a Movable Type blog, which generates a giant text file, and then uploaded that file into WordPress.

It took a couple of passes to get all the entries (the operation timed out), but I had a huge WordPress blog in mere minutes.

Since the Movable Type blog was archived in a text file, all of the image links referred back to the old blog, and the images displayed in the WordPress blog were still on the old system.

But as far as entries, categories and tags go, everything moved over perfectly.

The ability to take your blog with you gives the user quite a bit of power. Aside from the problem with hosted images, it's extremely easy to move years' worth of blog entries between platforms like WordPress, Movable Type/Typepad and Blogger.

The whole concept of storing blog entries in database format and using protocols such as XML (I'm guessing) to enable data portability is a truly great thing.

Not that I'm an expert, because I'm far, far from it, but setting up a system to use the Movable Type blogging system ain't easy.

You need a server on which you create a database, configure Web-server software, implement PHP and somehow get all the permissions to work right.

Putting together a Movable Type installation should be easier now than ever, as I read in Matt Asay's Open Road blog, now that Movable Type parent company Six Apart has partnered with Jump Box, a virtual-machine company, to offer a fully virtualized MT bundle.

If I read this correctly, it means that through virtualization, you can have an instant Movable Type setup without having to do all that much configuration on your own.

I've had a bit of a difficult time with my OpenBSD 4.2 installation on the $15 Laptop — a Compaq Armada 7770dmt with 144 MB RAM, a 233 MHz Pentium II CPU and 3 GB hard drive. I use PCMCIA cards for networking, an Orinoco WaveLAN Silver for 802.11b wireless and a TRENDnet TE-100PCBUSR 10/100mbps for wired Ethernet.

Since I upgraded the memory from 64 MB to the 144 MB maximum for this machine, things are running much, much better.

But I'm running out of room in the /usr partition. I'm not sure whether or not OpenBSD can be installed in a single partition, but since the install FAQ tells you to set up separate partitions for everything, that's what I did.

On this drive, I set aside about 600 MB for Linux filesystems to create swap and a place to store files for Puppy Linux, leaving 2.4 GB for OpenBSD.

At the end of the OpenBSD partitioning, I had 1 GB for /usr, which is where applications are stored in the system.

For awhile things were going fine. I had our daughter's Gcompris, TuxPaint and Childsplay games on here, Firefox, the Geany text editor, plus a few console apps like nano, mc and mutt.

But it's not console apps that are taking up all the space.

I pulled the games and their libraries in order to fit the Opera Web browser and the Linux compatibility package needed to run it. That was the best thing I've done for this install since I did it. On this old hardware, the Linux build of Opera runs much faster than Firefox.

That speed really shows up when blogging with Movable Type. For some reason, even in Linux, scripts keep timing out in Firefox and the Mozilla-based Seamonkey. Now that I have Opera installed in both OpenBSD and Puppy 2.13, I'm a lot happier on this old laptop, which is about as challenged as it gets when it comes to old hardware working with modern operating systems and applications.

Anyhow, I needed to do some more "formatted" writing, and I did have the Ted word processor installed. But Ted isn't great when it comes to centering type, print previews or generating PDF output.

I needed Abiword. But I didn't have enough space.

The only thing big enough: Firefox.

Yep, I got rid of Firefox. One thing about the OpenBSD package manager that isn't helping me out here is that when you install a package, all the dependencies are checked, and the additional packages needed are downloaded and installed. But when you remove a package, the system doesn't check its dependencies for whether or not they're still needed by other applications in the system.

I'm sure there's a reason for this, and there's probably even a way around it (like the great deborphan app that I use in Debian), but I know nothing about it.

Anyhow, I managed to get Abiword installed, and I have 500 MB left in my /usr partition. Unfortunately, the spell-check in Abiword doesn't work in the OpenBSD build. Abiword spell-check doesn't work in Puppy either.
The spell-check installs and works most of the time in Debian (especially when you install it with Aptitude and get all the packages you need, rather than with apt-get, where at least sometimes you don't).

I found an old OpenBSD mailing-list hack about how to fix Abiword's spell-checking capability, but it didn't have enough information, and it didn't look like it would work anyway.

But the good news is that with this amount of memory, Abiword 2.4.5 runs extremely well in OpenBSD 4.2. Additionally, for some reason the fonts in Abiword look better in OpenBSD than then do in most other Linux/Unix systems.

So now I have Abiword, Geany, Opera and the Dillo browser as my "main" applications on this system. I don't want to forget the Rox-filer file manager. I put that on the box awhile ago. I still need space to add the Flash plugin for Abiword, and Rox is a prime target for removal so I can get that space ... or the space to install Gaim/Pidgin for IM.

But I just can't do it. I've loved the Rox-filer ever since I first used it in Puppy, and I just can't give it up.

I probably should. I removed mc (Midnight Commander) for space reasons, even though it probably doesn't take up all that much space, and since I had Rox. If mc didn't have problems with the function keys in the console (it misreads the keys for some reason), I'd be able to fit one more app in. (Note: mc works perfectly in an xterm window, just not in the console).

What I'm going to have to do eventually is reinstall OpenBSD. I need a bigger drive so I can have a big /usr partition, install everything I want on it, as well as have room for a full Linux install as well, something I could use in addition to Puppy.

So the OpenBSD install is really tight, in terms of space for applications, but it's working extremely well. I now have the ability to share files between OpenBSD and Linux via an ext2 partition, and that has added tremendous value to this laptop.

I could be using my Gateway laptop a lot more. It's got way better specs (1 GB RAM, 1.3 GHz CPU) and runs Linux way faster. But it isn't so hot with OpenBSD due to the noisy, uncontrollable-by-BSD CPU fan. And its PCMCIA slot still isn't fixed, so I can't run wireless with it.

The Compaq may be underpowered, but it has a very clear, very bright screen, an excellent keyboard, working wireless, no ACPI issues (since it has no ACPI), and there's just something about getting it to work and keeping it working that I find compelling.

And there's also something about OpenBSD that keeps me coming back to it, even on the desktop.

I've heard about Drivel, the GNOME blogging client that enables users of Linux to write blog posts offline for LiveJournal, Blogger, MovableType, Advogato, Atom, WordPress and Drupal blogs.

I haven't used it yet -- and I was hoping to find something that would work with OpenBSD and not carry the weight of GNOME along with it -- but I will.

More on Drivel from:

Techmania

And from the world of the KDE desktop environment, there's Blokkal.

My Debian Lenny system has a whole lot of KDE on it already, so I can probably add both of these.

As I say in a previous post on this very topic, there are many reasons to choose Puppy Linux as the primary OS on the nearly 10-year-old Compaq Armada 7770dmt laptop.

For one thing, Puppy is ideal — and explicitely designed — to run as a live CD or easily upgraded frugal install, the latter either on a traditional hard-disk drive or a Compact Flash memory card mounted in a CF-to-IDE adapter inside the Compaq's hard-drive caddy.

With recent versions of Puppy (2.17 onward, I believe) the ability to encrypt the pup_save file that holds all of the user's files and configurations adds both a needed measure of security to a laptop installation as well as providing an equally easy way to back up the entire system by copying a single large file to just about any storage medium, from USB flash drive to CD-RW to hard disks in formats ranging from old-school FAT to NTFS to Linux's many types of filesystems.

Also in Puppy's favor is that recent versions have heightened compatibility with Slackware 12 packages, promising a greater number of sources for additional applications, should I ever want or need to add anything beyond what Puppy and its own repositories already provide.

To recap, in the time I've had the 1999-era Compaq Armada 7770dmt laptop (again, with a 233MHz Pentium II MMX processor), I've taken it's RAM from 64MB to the maximum of 144MB, kept the original IBM-made 3GB hard drive, and run the following operating systems:

• Debian Etch "standard," with X and Fluxbox added
• Debian Etch Xfce desktop install
• Slackware 12 without KDE
• Puppy Linux 2.13
• Damn Small Linux 4.0, 4.3 and 4.4
• OpenBSD 4.2
• Wolvix Cub 1.1.0

Truth be told, I liked every one of these installs to one degree or another. While Slackware (installing without KDE but with everything else) took up too much space and offered too few applications I wanted, it still ran great.

Rolling my own X installation into Debian's "standard" install was an excellent exercise, but I just didn't have the expertise to really build it out. The Debian Xfce install was nice, but somewhat curious; all of the Debian desktop installs, even KDE, feature OpenOffice. Surprisingly, OO ran fairly well in 64MB of RAM and 233MHz of CPU. Strange, however, was the lack of GUI package management in the Xfce install. It did get me using Aptitude, so there was nothing lost there, but I got the feeling that Debian's Xfce just didn't offer what I wanted.

However, with Aptitude, Abiword actually installs the dictionary that makes spell-check work. At last look, neither Puppy nor OpenBSD do that.

I continue to enjoy Damn Small Linux, but the most recent versions just don't run as well as they should on this laptop. And little things like having Firefox renamed Bon Echo (why??) made it difficult to use Google Docs with Gears, which is one of the things I want to be doing fairly intensively, made DSL fall behind Puppy in the running.

Puppy has a great selection of apps, is fairly easy to configure, extremely familiar to me and runs great on this hardware. I find myself using this live CD more and more of the time.

Much of my feeling for 2.13 over other versions of Puppy is nostalgic. I first encountered Puppy with this very release, and most likely a simple move of the cute 2.13 desktop wallpaper to a newer version of Puppy would make me extremely happy. The fact that everything in 2.13 continues to work flawlessly, however, is a strong testament to how very well Puppy is put together. I probably will test and subsequently adopt a much newer version of Puppy for use on this laptop, if for no other reason than to use the encrypted-pup_save feature that will greatly add to the security of my data, since laptops — even ones well past their prime — have a way of falling into the wrong hands.

OpenBSD doesn't install with as anywhere near as many GUI features as ... any Linux distribution. Not that any of the BSD projects can't be configured to be as full-featured as any equivalent Linux distribution. It just takes time and effort. With a faster processor and a bit more memory, I'd really consider running OpenBSD as the primary distro on this laptop. On the other hand, hardware detection in OpenBSD excellent. It remains the only operating system to correctly auto-configure sound on this Compaq.

OpenBSD has well over 4,000 precompiled binary packages for i386 and even more software available through ports. It offers fewer packages than Debian or Ubuntu but way more than Slackware. And with the quality of the packages being so high and the tools used to manage them equally high in quality, OpenBSD remains an attractive alternative.

But again, Linux is just that much easier to use on the desktop. OpenBSD is no speed demon in X, and speed is more important when you're running ancient hardware than it is when you have, say, a PC from the past five years at your disposal.

And with OpenBSD, things like Adobe Flash are hard to deal with. And I don't think Google Gears will ever run in OpenBSD. I could be wrong on both counts (since OpenBSD can run Linux apps), but I do know that both are easier to do in Linux.

A bigger drive that could multiboot Debian, Wolvix and OpenBSD, with Puppy running either in a frugal install or as a live CD, is one way to go.

But running only one or two of these systems at a time seems to be more realistic, manageable and ... sane. Using multiple hard drives, like I do with my test box, is another way to go. That way the pain of dual-booting is avoided, as is the tedium of continual reinstalls.

Since OpenBSD offers much of the software I want and is an intriguing diversion from Linux, I could 'll probably leave it on the drive for the near future. In my 500MB or so Linux partition, I will probably grow my pup_save file and update Puppy. Now that I have Firefox 2 running on one of my other Puppy installs, I'll probably begin doing the same with this laptop, and that way I'll be able to use Google Docs with Gears. I can probably even figure out how to make Gears work with Seamonkey, but it's not imperative.

Previously:
In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
In search of the best OS for a 9-year-old laptop: Part II — OpenBSD or Debian?
In search of the best OS for a 9-year-old laptop: Part III — Browsers and wireless
In search of the best OS for a 9-year-old laptop: Part IV — Wolvix Cub is surprisingly strong

Coming up:
In search of the best OS for a 9-year-old laptop: Part VI — Younger Puppies
In search of the best OS for a 9-year-old laptop: Part VII — Debian with Xfce and Fluxbox calls
In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")

I didn't have high hopes for Wolvix on the $15 Laptop — a Compaq Armada 7770dmt built in 1999 — since previous attempts to load the live CD resulted in an X configuration that needed a little work.

Since then, I've had quite a bit more experience working in the xorg.conf file, and I was able to get a halfway decent X configuration going so I could test Wolvix Cub (the smaller of the two Wolvix distributions, with fewer packages than the larger Wolvix Hunter).

As I've written on many occasions, I consider Wolvix to be one of the best Slackware-based distributions available. Both the graphical configuration utility and the very flexible installation utility — also an X application — add considerable functionality to a solid Slackware 11 base.

And with Wolvix (and the rest of the Slackware-derived distros such as Zenwalk and Vector), all of the helpful Slackware console utilities are still there. Xwmconfig, netconfig, mouseconfig, even pkgtool can be used in any of these Slackware-based systems. You might not need them as much as you would in a standard Slackware installation, but they do come in handy.

Wolvix also includes slapt-get and Gslapt, the Debian-apt-like utilities that changed the way I look at package management in Slackware.

Before Wolvix, when running Slackware I dutifally downloaded updates from the Slackware FTP site, then used updatepkg to install them. One by one. By one.

One time I figured that using pkgtool for updates would enable me to save time and avoid all that typing of long filenames, or the almost-as-long procedure of copy/pasting them in the file manager for each and every package than needed updating.

I ended up with "doubles" of every updated package, since pkgtool didn't know I was doing an update and just installed the new packages without removing the old ones. So when you're talking about doing updates of Slackware packages with Slack's default tools, it's updatepkg or nothing.

All it means is that slapt-get and Gslapt, which are included in Wolvix and easily added to Slackware itself, are essential for the person whose life doesn't revolve around using the updatepkg utility.

Just the fact that Wolvix — which can operate as a live CD with a Knoppix-like save file, or in "frugal" or traditional hard-drive installs, can be brought up to date in minutes with Gslapt in much the same way that apt and Synaptic work in Debian continues to be a revelation.

Put it this way: How many longtime Slackware users don't have and use slapt-get/Gslapt? I bet not many.

Once I had Wolvix Cub running as a live CD with X properly configured on the 144MB/233MHz Compaq Armada 7770dmt, I used xwmconfig at the console to switch between the Xfce and Fluxbox window managers.

Not surprisingly, both WMs ran quite well, even with only 144MB in the live CD environment.

What astounded me were the extremly quick application-load times. In previous tests of Wolvix, it was quick but not so quick as to beat Debian Etch or Slackware 12 under Xfce and Fluxbox.

In Wolvix Cub running on live CD on the Compaq, a number of text editors, the lightweight Abiword and not-so-light Firefox all loaded relatively quickly. I need to do more tests, but Firefox seemed as responsive or more so than the Mozilla-based Seamonkey browser is in the ultra-fast Puppy Linux.

I wouldn't want to run Wolvix, even the Cub edition, as a live CD in the same way as Puppy or Damn Small Linux — especially in only 144MB of RAM, but when it comes to a traditional install, Wolvix Cub or the more application-rich Hunter would seemingly make an excellent candidate to permanently run on the Compaq.

In contrast to Debian and Slackware, Wolvix installs with just about every application and utility I like, from Abiword to Bluefish, Dillo to MtPaint, and with extremely well-organized menus in both Xfce and Fluxbox. In fact, the Fluxbox menus even include little icons next to each category of applications, something I've never seen before.

I'm "sure" I could replicate all of this goodness in standard Slackware of Debian, but the former's KDE focus and the latter's devotion to GNOME mean that it would take quite a bit of work on my part to have as good an experience in Xfce and Fluxbox as I already enjoy in Wolvix by simply loading the live CD and doing an easy installation from what I consider to be among the best installers of any Linux distribution.

Previously:
In search of the best OS for a 9-year-old laptop: Part I — Puppy or Damn Small Linux
In search of the best OS for a 9-year-old laptop: Part II — OpenBSD or Debian?
In search of the best OS for a 9-year-old laptop: Part III — Browsers and wireless

Coming up:
In search of the best OS for a 9-year-old laptop: Part V — Where I'm headed
In search of the best OS for a 9-year-old laptop: Part VI — Younger Puppies
In search of the best OS for a 9-year-old laptop: Part VII — Debian with Xfce and Fluxbox calls
In search of the best OS for a 9-year-old laptop: Part VIII — Final thoughts (aka "Why?")

Seriously, people, I do a lot of work on this Movable Type installation, and I never knew that the archives page for each of the L.A. Daily News blogs features a link to every single post in the blog.

It also features links to every category page, separated by months, as well as author category pages (which most blogs, including this one, really don't need because they're basically one-wo/man shows).

It basically offers a link to every static HTML page generated by Movable Type for this blog. Yep, MT builds a whole lot of pages.

I can hardly believe that I'm composing an entry in Movable Type Open Source 4.1 using Damn Small Linux.

Now that version 4.3 of the low-spec Linux distribution has added Firefox 2 to its software mix, I can use the browser -- here named Bon Echo for reasons that escape me -- for many more things than I could the Firefox 1.06 browser included in previous incarnations of DSL.

And on the $15 Laptop -- a Compaq Armada 7770dmt with a 233 MHz processor and only 64 MB of RAM -- Damn Small Linux remains the best operating system and is that much better with a browser that can do so many things FF 1 couldn't handle.

Like Movable Type.

And Google Docs, where I just had a very pleasant writing experience.

There are a few niggly things that don't work as well in DSL 4.3 as they did in DSL 4.0 on this laptop, among them the desktop background, which for some reason is absent (but shows up when I run DSL 4.3 on other PCs), and I can't for the life of me figure out how to get the menu to show up in Fluxbox. All I get is the DFM menu, not the Fluxbox application menu. Since I'm happy using the JWM window manager, that's not a big deal, but having Firefox 2 instead of 1.06 is a big, huge, game-changing deal that makes Damn Small Linux a must have for hardware at this level.

Thanks to Robert Shingledecker of DSL for continually improving his distribution and saving many an old computer (this one in its ninth year of service) from obscurity.

I burned a DSL 4.4 RC1 CD today, but I couldn't get it to boot on the Compaq. I don't know if it's a bad CD or a bug in the release candidate, but I do plan to try again as the development process continues. I'm also planning to give DSL 4.2 a try to see just where the desktop wallpaper stopped appearing on this laptop. Again, it's not a big deal because the extreme responsiveness and stability and usability of this distribution on a PC with these specs cannot be found in any other Linux distribution -- Puppy and Debian included.

When I make the leap from 64 MB of RAM to 144 MB, things could very well change. I might be able to more successfully run Puppy, Debian or OpenBSD with X, but DSL will also be that much better as well.

I've blogged a bit recently on how hard it is to install Movable Type and have it actually work on your own server. After getting and configuring Apache and MySQL (or PostgreSQL or SQlite), making sure you get the static files in the right place and the CGI/Perl files in the other right place, then making sure everything has the proper permissions ... I found it to be way beyond my capabilities.

And the instructions are rudimentary at best. I think the people at Six Apart pretty much want you to hire time to configure your Movable Type setup. In a way, I don't blame them, but they've also got to think about WordPress breathing down their necks.

To be fair, I haven't yet tried to install WordPress, but I recently found out something very interesting:

There are WordPress packages available in many of the major Linux and BSD distributions, including Debian, Ubuntu and even OpenBSD.

Luckily, the same thing is now happening for Movable Type.

So if you're using the Debian GNU/Linux distribution -- and I strongly suggest you do -- you can now install Movable Type as a Debian package.

Read about it at the Movable Type site, and find out more about the package at the Debian site.

And for those using -- or about to use -- Debian, since the Movable Type package is new, it's not in the Stable distribution, which is named Etch. Instead, you need to install or upgrade to the Testing distribution of Debian, named Lenny. I'm already using Lenny in one of my desktop installs, where it happens to work better than Etch, but my Debian server still runs with Etch, and I'm loathe to change that.

I'm not sure how either of these packages -- WordPress or Movable Type -- handles dependencies as far as Apache and MySQL are concerned (e.g. whether or not you have to install the Web server and database software before you install the blog software), but I plan to find out very soon.

After two unsuccessful attempts at rolling out my own MT installations, I'm cautiously guarded about these packages actually working without a lot of post-installation tweaking (and I hope the man pages provide considerable insight).

I decided to start from scratch with my Debian server project. Last time I was too hasty in adding the open-source version of Movable Type to my installation and intermingling files before I was ready.

This time I'm going to be a lot more methodical and make sure that Apache and MySQL are working properly -- meaning I can run CGI scripts and have a directory dedicated to same -- before I start with Movable Type.

I could've removed Apache, done some cleanup and gone from there, but since I didn't have much "invested" in the install, I wiped the drive and started over.

I did want to change a few things:

Last time I used encrypted LVM. Since I don't have any grasp about how to work with LVM partitions after the fact, and since I'm not confident enough to have an encrypted drive that I can't get to from a live CD rescue disc, I went with a standard partitioning scheme. I initially was going to roll out separate partitions for everything, but since I don't know how extensively I'm going to use /var -- and since the automatic partitioning in Debian tends to make the root partition too small for my taste (and with a 14.5 GB hard drive, I don't have a whole lot of space to waste), I went with a separate /home partition and one big partition for everything else. That way, even if I'm using /var for my Web files, I can always rsync them to the /home partition and then rebuild the whole damn thing if I need to, yet still have all the files right there.

Another thing I learned: When you check off "SQL server" during a Debian Etch install, you get PostgreSQL, not MySQL. I'll write more about this in an upcoming post, but I'm at such an early stage in my interaction with databases (i.e. smack dab at the very beginning) that I'm going to use MySQL just because of its sheer ubiquity (and because that's what Movable Type recommendseven though Movable Type supports PostgreSQL just fine -- and also allows use of SQLite).

I'm not ruling out using PostgreSQL in the future, but since this is my very first installation of a SQL database -- hell, it's the first time I've even used a SQL database and actually knew I was using it, so I'm going with the flow as much as possible.

In the last install, I also selected "file server," and ended up with a lot of stuff loading at boot that I don't need. What I really do need is an ftp server (and preferably a secure one) as well as the OpenSSH server, both of which are easy enough to install and configure (easy since I've successfully done it before).

And while I considered not installing the "Desktop environment," which brings GNOME and everything that goes with it, I didn't want to leave all that GUI goodness behind just yet; I'd rather have Synaptic, especially, at my disposal.

So right now I have the stock Debian Etch install with the desktop environment and Web server options.

And I need to add:

• Anything I'm missing to make Apache work with PHP and CGI/Perl scripts (that was my big stopper in last week's install)
• MySQL and the phpMyAdmin program to help me configure the database
• The ftp and OpenSSH server packages
• Movable Type

At this point, everything is on the local network, not right out there on the Internet, and I just want to see how hard it is to roll one's own blogging-equipped Web server. Would I rather use Drupal, WordPress ... or anything else? Sure, but since our shop makes extensive use of Movable Type, that's where I'm putting my energy.

I'm getting some help setting up Apache2 from this Debian Admin page. And Carla Schroder's "Linux Cookbook" has some good tips on rolling out Apache (look in Chapter 22 -- and if you don't have this book, you really do need it).

One thing that's screwing me up is the presence of multiple configuration files in Apache2 (apache2.conf and httpd.conf), the placement of those and other files in different directories on different systems, and general confusion of what the proper commands are between Apache 1.3, 2.0 and 2.2.

But since I'm being more deliberate this time, I won't move to the next step in the process until everything works with the previous step. That means I need to get CGI working in Apache, then add MySQL, create the database, and then add MovableType. ... and in between I'll get the FTP and SSH servers going.

Update: I installed a bunch of MySQL and PHP stuff that I saw in Synaptic. I also installed phpMyAdmin, which I already confirmed is working. I also added the proftpd ftp server, which has a MySQL-specific version (not sure what I'm getting myself into there). I also put openssh-server on the box, which worked perfectly in my last Debian Etch install.

A very good tip: This is true for most configuration files, as well as for those in Apache2, especially because there are a whole lot of them: SAVE copies of everything before you mess with it. Look at ALL of the configuration files and attempt to understand them before you mess with them.

By looking, I learned that the default Apache2 installation in Debian is already set up to use /usr/lib/cgi-bin as the CGI directory. This information wasn't in /etc/apache2.conf or /etc/httpd.conf (which is empty, with the implication -- for me at least -- being that this configuration file is no longer necessary in Apache 2.2 ... but don't quote me because I could be totally and completely wrong).

I found out about the CGI situation in /etc/apache2/sites-available/default and /etc/apache2/sites-enabled/000-default.

OK, I realize that Apache is a huge deal. It's production-ready, hugely scalable, time-tested, and all that other good stuff that makes for a bullet-hardened app. Did I throw in enough cliches?

But holy crap -- I've got FOUR configuration files in front of me.

I somehow in my previous installation was able to get the "home" of my Web server out of /apache2-default/, and now that I know where the cgi-bin area is (and presumably how to move it) ... I just might get this thing off the ground.

All I do know is that the online Apache docs led me astray (and were extremely vague about where exactly to put the various configuration lines I needed).

Here's what I'm going to do now: NOTHING. I'm going to sit on this for a day or so and think about how to proceed without screwing the whole thing up.

I'm doing considerable work in Movable Type with our big-time installation that serves up hundreds of blogs, many of which actually have more than a few readers.

So I figure I should be able to set up my own server on a local network with the open-source version of Movable Type. That way I'll have a better feel for what's going on at the server level. I've already fooled around a bit with Apache in OpenBSD and Debian. I had no problem getting a static Web site up and running.

To run Movable Type, besides Apache, you need MySQL ... and you need to configure everything. Apache must be set up to run CGI scripts. A MySQL database needs to be created. Everything has to be in a certain place, with certain permissions and certain users.

I'll just put it right out there: Movable Type doesn't have anything even remotely approaching the amount of documentation needed to get an installation up and running. The fact that they dump you off to the Apache Web site for that part of the install, then send you to MySQL for that part, and to the PHP site for that part of the installation.

I guess the implication is that you need to get your shit together as far as the server goes, then you can layer Movable Type on top of it.

And just what is Movable Type, anyway? Yes, it's a blogging application, but it's not a monolithic executable file. You don't download a different version for Linux, Unix or Windows. What?

It looks like Movable Type is a whole bunch of HTML coding and other various scripts that draw their real power from the Web server, database and other scripting languages on the system.

This isn't much of a revelation for those of you who know what you're doing, but the whole point of this blog, for me anyway, is to actually try to learn something. Lots of somethings, really.

For some reason I thought that Movable Type would be able to walk me through all the various tasks I would have to do to go from nothing to a full blogging platform. Not so much.

So how did I do? I already had Apache 2.2 on a fresh Debian Etch install. I used Synaptic to get MySQL. I downloaded the Movable Type files.

Here's my problem. I just don't know enough about Apache. And I'm not all that crazy about the documentation on the Apache site. I needed to move the DocumentRoot. I'd already done so once before, and I finally was able to do it again.

As far as setting up CGI, I had all the scripts ready to execute with chmod 755, and I tried to get Apache to let me run them. I just couldn't make it happen. I had a cgi-bin directory, and I pointed to it with ScriptAlias ... but I just couldn't get a script to run.

Part of the confusion, for me anyway, is that I don't know why there's both apache2.conf and httpd.conf. And with httpd.conf being pretty much empty, I'm wondering why both of these files exist and which one should contain which configuration information. I swapped stuff between them, starting and stopping Apache in the interim to test the cgi scripts. (I did apache2ctl stop and apache2ctl start).

I had already created a database. I barely know how I did it. I'll use phpMyAdmin next time to make it all easier.

What I really need is a good LAMP server book to walk me through all this.

I'm not giving up. I will start from scratch next week, starting with a fresh Linux install and doing things in a somewhat more methodical manner: install Apache, get CGI working, install MySQL, create database (hopefully I'll get that right), install PHP, install Movable Type files. Hopefully with CGI working I'll be able to actually set the damn thing up.

Clearly I need a book that covers Apache 2.2, PHP and MySQL.

I've made a few changes in my spam-fighting techniques for Movable Type 4. I had the spam filter set at +3, but just about every "legitimate" comment was ending up in the spam file.

I changed the spam-filter setting to +2, and now I'm getting only a few obvious spam comments per day in the "non-spam" comment area (none of them are published until I do so manually, so it's not like all the effort behind sending out this large volume of spam is doing anything for those foisting it upon me).

And I think I figured out why some legitimate comments are ending up marked as spam: fake e-mail addresses. I'm not sure why Movable Type asks you for your e-mail address and Web site (as if every one of us even has a Web site ...), but the system appears to check whether or not the e-mail address supplied by a commenter is legitimate. If it's not, you can guess what happens (the comment is marked as spam).

So all those commenters who think they're being clever by not providing their real e-mail address -- NOBODY but me sees it, by the way -- all it does is get your comment routed to the spam file, where I can usually recover it before it gets automatically deleted. But still ...

Anyhow, since I'm habitually checking the spam comments for legitimate comments that are stuck in there, I started DELETING the spam comments after I check them. I was running up 2,000 spam comments per five days (the length of time I have them set to remain in the system). Since it's so easy and quick to erase ALL spam comments (there's a button for it -- and did I forget to say it's fast?), I've been getting rid of the spam as soon as I check it. It makes it way, way easier to check the spam the next time -- and it takes a load off of the system as well.

So in a nutshell, I've "weakened" the spam filter slightly, but I'm also zapping the spam myself instead of letting the system do it automatically. Less spam means plucking your comment out of said spam, should it land there, is much easier.

So far, this is working for me. ... I'll probably have the whole thing nailed down by the time we go to Movable Type logins for commenters.

Remember yesterday (I remember it like it was yesterday, which it was) when I I thought I had the spam problem in Movable Type 4 under control? Well, today I find about five obvious spam messages -- with URLs and everything -- in the non-spam comments.

And worse, a comment from an AUTHENTICATED TYPEKEY USER was marked as spam? If anything, a Typekey comment should post immediately -- that's how I have the system set. I immediately marked the commenter as "trusted," which means his future comments should have no problem getting posted.

But how could the MT spam filter let me down that way? A Typekey comment? I repeat: A TYPEKEY COMMENT. Unbelievable.

Obviously, I'll need to keep an eye on the situation.

We currently have comments on most of the Daily News blogs set to accept both "anonymous" comments -- meaning from just about anybody -- as well as Typekey-authenticated comments. And we haven't yet made the move to Movable Type-authenticated comments (see -- you have a lot of choices in MT 4 ... and while confusing, it's nice to have options), but that's where it's going, I'm told.

I was about to turn off anonymous comments, but then I got a sweet Distrowatch link about a week ago, bringing quadruple to quintuple the usual traffic, and I didn't want to shut potential commenters out.

I realize that many people might not want to sign up with Typekey, and entering a comment while logged into the Typekey system is confusing (the name, e-mail address and url boxes remain after you're logged in, but they SHOULDN'T BE filled out), and I'm pretty much waiting for the Web-biggies here to get the Movable Type login comments working.

So I decided to try adjusting the spam filter once again. Under Preferences -- Blog Settings, click on Spam, and see what your spam filter is set at. All of ours default to 0. I started with +4, but that caught too many legitimate comments, and I finally settled on +3. That flags most of the spam as spam, which I have set to delete when it gets 5 days old. That way I can quickly scan the spam to see if any legitimate entries got caught in the filter. But I don't have to do anything to the 99.99 percent of spam comments that I don't want on the system -- they just go away when they reach the age of 5 days.

So far, the only spam to get through has been these weird Obama entries that don't have a URL embedded in the comment (unlike 99.999 percent of the other spam). I suppose that the only problem is that "real" commenters who include URLs of any kind in their comments might not make it past the filter, but that's why I quickly scan the spam (Under Manage -- Comments, click on Spam Comments on the right side of the screen to see them -- and make sure you have your "view" set up for 100 rows with "action" buttons enabled on top and bottom, so you can restore/delete at the top or bottom of the long list).

And anybody who absolutely, positively must put URLs in their comment can sign up with Typekey and leave an "authenticated" comment. Right now, those go right through (though that parameter is also modifiable in MT 4).

I no longer spend a considerable chunk of time marking comments in "nonspam comments" as the spam they truly are. The easy change in spam-filter from 0 to +3 has taken care of it for me.