Recently in Servers Category

Distrowatch guru Ladislav Bodner has been rolling more than a few operating systems onto his ASUS Eee PC 900 netbook — probably the most popular netbook out there at this point (they even sell them at Target now).

In this week's Distrowatch (which I recommend as a must-read for anybody who wants to follow what's happening in Linux and the BSDs), Ladislav writes about how a mouse-over problem that tends to freeze the screen in Ubuntu Netbook Remix on the ASUS Eee was solved in the Linux kernel but almost immediately returned due to the relevant patch being pulled from the kernel because it began causing other problems.

Ladislav goes over how you can go backward from Linux kernel 2.6.28-11.41 to 2.6.28-11.40 and get your ASUS working again under Ubuntu Netbook Remix.

He also provides a tip for those using SSD (solid-state drive) disks on how not to wear them out:

Finally, a quick reminder for those who are about to install Ubuntu Netbook Remix (or any other Linux distribution) on a netbook with solid state drives. Since these drives have a limited life span that depends on the frequency of write access to the drives, you can greatly prolong their life span if you follow these two rules while installing your preferred distribution (here is the source of this information, although there are those who dispute this):

* choose a non-journalling file system (e.g. ext2)

* don't create a swap partition

As Ladislav says, there is some dispute about the life of flash media in everything from those mini USB drives and SD camera memory cards to devices designed to replace traditional IDE and (mostly these days) SATA .

Some people have said that the MTBF (mean time between failures) for SSDs is so low when compared to spinning hard drives that the devices will last much longer than traditional spinning hard drives due to the lack of moving parts in an SSD. They say that worry about killing the flash memory with repeated write cycles is overblown.

But others are worried about killing their flash memory too quickly and take precautions such as the recommendation above not to have swap space on the drive.

For those who might not know, most operating systems do use swap space on the hard drive in the event that your computer's RAM (memory) fills up. I won't go into just how much space you need for swap because that's a whole new topic that's been discussed countless times in countless places. (I generally set aside 300 MB for swap on my systems).

Even Windows uses swap (that's one of the reasons your box tends to slow down after it's been running all day [or week/month/year]) — you've got a lot of critical stuff that the OS has written to the swap area of the drive.

Back to flash/SSD memory: As I say, some people think that worrying about excessive writes to flash is unwarranted. While I'm tempted to say that you shouldn't use an SSD on a server, Sun Microsystems (yep, the company bought recently by Oracle) is offering SSD-equipped servers and storage arrays. Sun thinks SSDs are the (near) future in servers since performance gains are too large to be ignored.

Sun is using single-level cell (SLC) flash memory, which has a much longer life than the cheaper multilevel cell (MLC) devices that pack more memory into the same space but have shorter write/erase lives.

We're a bit far away from the ASUS Eee PC and Ubuntu at this point in the post, aren't we?

Maybe. But here's what I want to say about flash-based storage: I'm all for it. I'd like to start moving everything I have to SSDs as soon as fiscally possible.

One thing I really like is a silent PC: no fans, and no spinning hard drives. If you've ever worked on a system with drives snaking out of the back of the case and sitting on a table (I did it for years), you know how much noise traditional hard drives make and how much heat they throw off.

For the energy and noise considerations alone, I'd like to dump spinning hard drives.

To that end, I'm doing one test and hope to do another soon. I've been running my Self-Reliant Thin Client (converted Maxspeed Maxterm) with an 8 GB CF card in the box's built-in CF-to-IDE adapter as the unit's main drive. I am still running Debian Etch on it (and will continue with it until I manage to get networking into the room). The box isn't in heavy use at present, but it is running (and has been this time for more than a week). I do have swap set up on the flash, and with only 256 MB of RAM, it'll probably get used a bit.

I'm running regular backups of the /home files to a 1 GB USB flash drive with rsync, so I have an all-flash system.

It's not fast. A low-end CF card (mine is a Transcend) doesn't have the performance of a top-of-the-line SSD. For one thing, the Transcend uses MLC instead of SLC and for that reason alone should have a shorter life.

I'll keep the box running for quite some time to monitor its progress with the flash memory and see if it can withstand repeated use. An upgrade from Etch to Lenny would definitely tax the CF card.

Another thing I'd like to try is an SSD in one of my laptops — maybe the $15 Laptop (Compaq Armada 7770dmt), which I've recently put back into service. At least the drive is easy to get to.

One of the best — and longest running — Linux sites is LWN.net, which I should get into the blogroll, by the way, and it has an excellent interview with Ubuntu founder and leader Mark Shuttleworth.

On Ubuntu's push into the server market:

Given that Ubuntu's roots are on the desktop, what's behind the recent shift in strategy to address the server side too?

That's not a change in strategy, it's more a pull through. We started with a very narrow focus on the desktop, and that allowed us to punch in. As we've penetrated the industry, there's a natural pull through where someone who's started using us on their desktop has now started setting up Ubuntu on a server.

You could always run Ubuntu on a server; there was never a significant reason not to. That body of users has now reached a critical mass on the server, and so our server work is now more responding to that than a shift in strategy. We continue to make the desktop our labor of love, the server requires a very enterprise-oriented approach. We've built out a dedicated team that just handles that. We haven't re-assigned people who are desktop specialists and asked them to test a server.

You're not worried you're spreading yourselves too thinly?

That is a risk, and that's something we discuss here a lot. There are benefits to offering a platform that can be used in both configurations. We see companies often saying: "We love your desktop. We would definitely choose your desktop if we could also use you on the server."

Companies don't like to introduce arbitrary diversity in technology. Everybody has heterogeneous systems, but they don't like to make that situation worse without a very good reason for it. Ubuntu is a very good server for certain use-cases now, just like Ubuntu is a very good desktop for certain use-cases. Our challenge over the next couple of years is just to broaden the base to which it appeals on both fronts.

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