Recently in Debian Category

As soon as I'm able to begin posting them, my eight-part series on finding the best operating system for my circa-1999 Compaq Armada 7770dmt will begin unfolding, one part a day, on Click.

I've been working on this series for about a month, working with everything from Damn Small Linux and Puppy Linux to OpenBSD and Wolvix Cub, with a lot of thoughts about past use of Slackware, Debian, Ubuntu and more.

So starting — again, as soon as I can get the entries lined up — look for a long meditation on the best way to make old hardware work in the 21st century.

I've been waiting ... and waiting ... for Debian to come to its senses and re-add the sound chip — the ESS 1988 Allegro — in my Gateway Solo 1450 back into the Lenny kernel.

Sound had been fine in Debian Etch (Stable) and in the first two kernels in Debian Lenny (Testing), but once the 2.6.24 kernel was added, I lost sound on the $0 Laptop.

Reverting back to the 2.6.22 kernel restored my sound, and I eventually hunted down the bug report, which — in grand Debian tradition — didn't solve the bug but instead provided a work-around.

Presumably the Debian team didn't like the fact that the ALSA sound module for this chip came in the form of a binary blob, which is non-source, undocumented code, and instead of providing any other way to use sound with these chips, elected to silence the PCs of those using Debian Lenny with this verboten sound chip.

Now if this were the only binary blob traveling in Debian's wagon train, I'd understand. But I'm fairly sure it's not. We're not talking OpenBSD-style religion here.

At least the system could somehow tell me that Debian removed sound support for my chipset and perhaps ask me if I'm OK with using a non-open blob to get the sound working.

No such luck. I suppose I should be so offended at my laptop's use of hardware for which the manufacturers decline to provide open-source drivers that I should soldier on without sound — and like it.

I don't like it. But the reality is that many if not most hardware manufacturers haven't seen the ever-lovin' light and don't know that open-source software in general, and Linux in particular just might take over the world, or at least the geeky portion of it.

Never mind that sound works on this laptop in any number of Linux distributions, including Ubuntu, Puppy, Slackware, CentOS/Red Hat ... as well as FreeBSD and NetBSD.

But Debian decided to get all high, mighty and just strip sound out of the kernel for what must be a whole lot of potential users who either don't know, don't want to know or don't care to track down the instructions for restoring audio on their machines.

I imagine there are a lot of ESS/Allegro chips out there. In Linux, as in OpenBSD and any number of other projects, a lot of really smart developers are very busy writing open drivers for the proprietary hardware we're stuck with. Sometimes they get cooperation from the manufacturers. Often times they reverse-engineer the whole damn thing. Still, there are a lot of "binary blobs" out there.

If the choice is between binary blob and open-source alternative, there's no question — take the code you can see, modify and distribute freely.

But if the choice is between a blog and ... nothing, it's nice to have the opportunity to take the blob. A project can — and should — let the user have a say in what they'll run on their machines.

I've stuck with Debian for awhile now on this laptop, even though I've been using Ubuntu more (blame it on Ubuntu's working suspend/resume ... and other stuff that just works better).

So far, here are the Debian Lenny problems I've had to solve to get things working:

• Change Gconf configuration so Epiphany browser doesn't default to "working offline" mode
• Download and install driver from the Foo2zjs Project to use HP Laserjet 1020 printer (to be fair, this is also an issue with Ubuntu)
• Tweak xorg.conf so Alps Touchpad's tap-to-click function can be managed (can't quite remember how I did this ...)
• Restore sound for ESS 1988 Allegro with firmware from the ALSA Project

It could've been worse, and in almost all of these instances I got the hacks from the Debian Bug Tracking System. But I'd prefer that at least some of these bugs actually get fixed rather that shuffled aside, with users left searching for the hackish fixes that will make their machines usable with a given distribution.

What most of us know is that users pretty much gravitate toward operating systems that work best with their hardware and the software they wish to use.

So if Ubuntu uses the same Linux kernel but supports my sound chip, properly configures my touchpad, doesn't think I'm working offline when I'm not, properly suspends and resumes, and offers a bit more in terms of functionality and polish (like the GNOME menu editor actually, say, working), I'm inclined to use it.

I still have Debian Lenny on the Gateway, although I might devote its partition to CentOS 5.2 for testing purposes.

Debian is still faster than Ubuntu. Many of the packages I use are better put-together in Debian, especially the educational games my daughter uses.

And I like the setup that Debian defaults to when installed. The fact that I can and have fixed most of the problems I had is a plus.

In Lenny, I'm having a few graphical quirks with GNOME. The top of the screen gets a little funky at times — and I'd love to figure out the suspend/resume problem, but otherwise Debian runs quite well. And as far as compatibility with this specific pile of hardware goes, Lenny has quite an edge over Debian Etch, the project's current stable distribution.

And since Lenny is still in the Testing stage, patches are coming through at a quick pace, and things are bound to improve on the distribution's road to "Stable" status.

I only wish I could know for sure if the things I fixed manually are being fixed automatically for present and future Lenny users.

Next: How exactly to restore sound for ESS Allegro-equipped PCs in Debian Lenny

I booted into Debian Lenny for the first time in a while on the $0 Laptop (Gateway Solo 1450), and after doing about 150 updates, I logged out of the GNOME desktop and switched over to Fluxbox.

Now this PC, for me, anyway, is quite powerful — 1.3 GHz Celeron, 1 GB RAM — so GNOME runs quite well on it.

But with Fluxbox (and even with Xfce, I suspect) it really flies. Apps load way quicker than they do in GNOME, and if you can deal with a more minimalist window manager, you get a lot more in terms of performance.

I had my Alps Touchpad's tap-to-click function turned off in GNOME, but in Fluxbox I had to use GSynaptics to turn it off. I wonder if things will be screwed up in GNOME as a result. The first thing I'll do is see if I can easily turn off the touchpad's tapping for my other users. That doesn't work so well in GNOME, where the "primary" user has control over the touchpad but the others do not.

I logged into one of my other user accounts, turned off tapping in GSynaptics, and everything worked. That's the way it's supposed to be in GNOME.

One thing I'd like to do is modify the Fluxbox menu to make things quicker, with my most-used apps higher up so I don't have to mouse through so many menus to get to them.

I've done some experimenting with encrypted filesystems in Debian, which are easy to do with the Debian installer — and which are just as easy to do in Ubuntu if you use the alternate installer.

Like I said, it's easy to do and to manage, unless you want to have a bunch of partitions under a single passphrase. This blog post helps you figure it out.

While full encryption is something you might want to use on a home desktop, although I wouldn't, it's almost mandatory for a laptop. If the thing gets stolen, whoever gets that drive has access to everything on it. And you really don't want that happening, do you?

Right now, neither of my two Linux laptops are encrypted, since I use them for testing and need to see one system's hard-drive partitions from the other, but in the near future, if I decided to single-boot either or both of these, you can bet I'll be encrypting the hard drive.

I had no idea that the Debian-derived apt and Synaptic are viable choices for package management in Red Hat Enterprise Linux and the free RHEL-like CentOS. Not that I have anything against RPM and Yum, but it's nice to have choices.

Dag Wieers shows you how on his blog, which I found via Planet CentOS. (Have you noticed that Planet CentOS is a great place to find out stuff?)

It's all courtesy of a project called APT-RPM.

I found a bunch of very relevant blog posts via Debian-News.net, which I plan to add to the blogroll immediately.

I also added the following to the blogroll:

Debian Administration

Debian Admin

Debian Weather

The two "administration" sites often have good tips, and I don't know how I didn't get them in the blogroll before.

Debian Weather is a new one &mdash to me, anyway. It has something to do with "quality assurance" for a given build of Debian on a given day. I'm not sure how useful it is, but I did put it in the blogroll and plan to keep an eye on it.

If anything, it says not to try to run Sid at all on some of the more obscure architectures, although it's a sunny day for Sid on i386 and amd64.

It's nice — really nice — to see via Distrowatch that development is continuing on low-spec favorite DeLi Linux. Here's the release announcement.

I've been able to install DeLi on my VIA C3 Samuel converted thin client, but not without a few tricks that I picked up from the forums (here and here). And I also recently did an entry on some good DeLi-related blog entries from others.

I never was able to get my static IP configured in DeLi, but I think I could do it now.

According to the DeLi site, you need 32 MB of RAM to run the GUI version. The Web browser is Dillo, I believe, and that runs great in 64 MB and looks like it can run about as well in 32 MB.

Probably the biggest change is a shift from GTK+1 to GTK+2, which accounts for the memory requirements rising for this release of DeLi.

When you're trying to resurrect and make an old computer useful, DeLI is a great distro to have in your arsenal, along with Puppy, DSL and even Debian (the Standard install with X and a lightweight window manager and your favorite apps added manually).

I just upgraded the $15 Laptop from 64 MB to 144 MB of RAM, and before the upgrade, OpenBSD, Puppy and Debian ran well on it with X ... unless you try to run a "big" application like Firefox. That's where Damn Small Linux leaped ahead of the pack for that low amount of memory.

Now with 144 MB, I hope that I will have more choices as to what will run on that Compaq Armada 7770dmt, but if you do have a box stuck with 32 MB (I used to run Windows 98 in that amount of RAM, and let me tell you, it was pure hell), DeLi is a great distro to try out.

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 don't know why I'm compelled to continually report on how well Ubuntu 8.04 LTS is running on the $0 Laptop, but I keep doing it.

From the graphical polish to Suspend/Resume, Alps touchpad control and everything else I've done with it, this is the most impressive Linux distribution I've run thus far.

For use on this laptop -- a Gateway Solo 1450 -- it's better than Debian Lenny, my other go-to OS.

Today I tried a live CD of Fedora 9, since Red Hat Enterprise Linux 5.2 supposedly has beefed up its support of Suspend/Resume on laptops, I figured that maybe, just maybe, that functionality was present in Fedora 9.

It very well might be, but in the Fedora 9 live environment, Suspend/Resume doesn't work on this laptop.

Moving on to Debian, in the Lenny updates I installed today, there was a new kernel among them. I booted into it after the update, and the new 2.6.24 kernel still doesn't support the ESS 1988 Allegro sound chip on the Gateway.

In order to have working sound, I'm still using the original Lenny 2.6.22 kernel, which does support the chip. I do understand that I can manually add the module I need to support sound in the new kernel, but I'm waiting to see if and when Debian decides that it would like a certain number of its users to enjoy sound. Until then, I'll stick with 2.6.22.

In case you were wondering, and I know you were, Ubuntu 8.04 LTS supports sound just fine on the laptop, even with a 2.6.24 kernel. Score another one for Ubuntu. If the binary blob in the kernel for the ESS 1988 Allegro sound chip were the only such blob left in the kernel as configured by Debian, then I'd understand its sudden exclusion from the distribution, but I have a very good feeling that this is not the case.

I will consider adding the sound modules myself, as detailed in one of the relevant bug reports, but I'll more than likely turn to Ubuntu for the simple reason that it just runs better. And this is coming from a person who has championed Debian quite a bit. (As an aside, I love bug reports that give you a fix for the problem that often works but leaves the bug intact to a) annoy some users and b) drive others away.)

I've thought about it quite a bit. If you're running a standard desktop computer, it's easy to make just about any Linux distribution work well, if it will work at all. You're not often worrying about unsupported touchpads, uncontrolled CPU fans, flaky or nonexistant Suspend/Resume, other power-management issues and the like. I can run Debian Etch with carefree abandon on some of my desktop systems, but getting Etch to work well with an Alps Touchpad is just not in the cards ... or maybe it is, since I found some new suggestions for configuring xorg.conf to make the Alps perform better. But since I've made the move to Lenny, I'm probably not going back to Etch on that system, even though the sound-chip issue continues to piss me off.

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).

... after the Great Linux At-Home Test, and I forgot about the little Ubuntu bugs that are ... bothering me.

Why isn't the Update Manager telling me about the dozens of updates I have waiting for me. I kind of like not being bothered by it sitting there flashing at me while I'm trying to "work," but every other Ubuntu and Debian system I've ever installed with GNOME automatically checks for updates and tells me to get on it.

A typical Ubuntu Forums thread sheds little light on the problem ... but for some reason, about 20 minutes after I log in, the funky "updates are available" arrow appears.

I'm thinking: It could have something to do with the Ubuntu repositories being VERY busy. Or not. A built-in delay?

I opened up System -- Administration -- Services, as suggested in the forum thread, but I didn't even unlock the thing when suddenly the icon appeared. Oh well, I'll do the updates and keep an eye on it.

Is it mere impatience on my part? Will the "update" icon begin appearing on a regular basis? Is the mere opening of System -- Administration -- Services without changing a thing enough to jump-start the thing?

Hey, there's an Update Manager update ready to install ... maybe all will become clear.

Like I've said in numerous posts over the past two weeks, Ubuntu has an extra bit of polish on the desktop that Debian lacks, but there are a few niggly issues that keep Ubuntu from, as they say, being all it can be on my Gateway Solo 1450 laptop.

I've probably got the printing issue down, but I have yet to solve the USB flash drive problem, which I will begin working on again.

Note: I originally wrote this post on 2/15/08. Today is 4/24/08. Since that time, I've looked into updating in the BSDs a bit further. In FreeBSD, it's certainly possible to update both ports and packages.

Anyway, here is the "original" 2/15/08 entry:

While it's pretty easy to install software from precompiled packages or from ports in OpenBSD, FreeBSD and NetBSD, I've hit a bit of a wall when it comes to keeping any of these systems up to date with periodic security and bug patches.

I don't know if such updates are either not as necessary in the BSDs, even though my Linux boxes have a dozen or so of them every week, or that it's just to hard to do for the average BSD user.

I see plenty of Web help on how to upgrade from one version of a BSD to another, but I don't see anything that covers searching for periodically updated packages and updating an installation on, lets say, a weekly basis as security and bug problems arise and are presumably updated in the repositories of packages and ports.

O, BSD users, correct me if I'm wrong -- and I do hope that I am wrong. But with apt/Aptitude/Synaptic in Debian-based Linux distributions, rpm/Yum in Red Hat- and Suse-style systems, and upgradepkg (and slapt-get/Gslapt) in Slackware (with security announcements going to the mailing list and the www.slackware.com/security page) ... need I go on?

The point is that almost all Linux installations are easily upgraded with precompiled binary packages. Gentoo ... well, I won't go there because I know it has its own BSD-like ports system, but I've never used it and don't know how it works.

Again, the point is that all of these Linux distributions have me conditioned to expect -- and to install -- updates on a regular basis.

But what do I do with BSD? In OpenBSD, for instance, I've never even downloaded the ports tree. Everything I've installed has been a precompiled binary package for the i386 architecture. It's very slick, works perfectly ... but am I exposing myself to undue risk by running Firefox 2.0.0.6 instead of the newer 2.0.0.12? Is all that extra OpenBSD security for nought if I'm running applications rife with security holes?

I'm being completely serious. Is there something I'm missing here? Since OpenBSD, at least, updates the whole system every six months, am I OK to keep the same packages running until the next release? What does this say about BSD vs. Linux when it comes to security and bugs?

But wait. I did run DesktopBSD for awhile, and I remember that system having a GUI package manager that not only fetched new packages but upgraded those already installed.

So that's what Matt Olander was talking about when he said that PC-BSD and DesktopBSD were working together to share technology when it came to package management.

As far as I'm concerned, I don't need to do my updates in a GUI app. I'm perfectly OK with using the console. Just being able to do that updating is enough. That is, unless someone out there can convince me that Linux has conditioned me to think I need something that I really don't.

Those on all sides of this issue, please enlighten me -- and quickly.

I really need the new "Apache Cookbook" and "Linux System Administration," both from O'Reilly. The Apache book because it's new and covers Apache 2.2 in great detail, and the server book just because it looks pretty good and focuses on Debian.

To get a better idea of what's in these two books, go to the O'Reilly site's tables of contents for both:

"Apache Cookbook"
"Linux System Administration"

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.