I recently completed a migration from Windows to Linux for a few blogs and wiki - PerCS being one of them! What follows is a record of the process - from initial motivation, through migration and lights-on. If you are interested in a reality-based Linux v. Windows comparison, NFS exports, hardened Apache, or the latest in Drupal then by all means read on!

Motivation
I was hacked by script-fiends. I was pissed off that my hardened Windows server had been breached. As a small business owner I need a low-touch system - for me that means three things:

• minimize adminstrative events (remediation, monitoring, patches)
• secure my data assets
• provide community-based security

If you are reading this post then no doubt you are well versed with this situation. If you are a Windows-head you are probably thinking, "You should have used fill in the blank to protect your Windows servers." If you are a Linux-head you are probably thinking, "What'd you expect!" But before the finger-pointing - whichever camp you call home - the fact remains I had a compromised system that needed to be fixed. So let's take a look at the actual hack (if you don't care about analysis then skip to migration).

Hackers use tools such as Nikto to discover the security situation of a website. Even without such a tool the casual hacker would have discovered my private FTP site. And thus the challenge: get at whatever was on the site. The hack was a brute-force dictionary attack on username and password. It resulted in read access to some files on the server. Not the worst intrusion there is...but I was in their sights. Within hours every security hole was being poked to see if it was open. So I brought the site down while I examined my options. I know you're thinking, "FTP is insecure and should only be used for public data." Well as they say, here's the rub: I needed secure, reliable file transfer of some of my files. On Windows Server 2003 and prior you get one or the other, but not both. You get secure authentication over HTTPS (Integrated Security or certificate-mapped), but file-transfer is unreliable. You get reliable file-transfer over FTP, but authentication is insecure. The well-established SFTP is not part of Windows products - so I chose reliability over security.

During months prior to the hack I spent more time than I could afford: installing patches and monitoring intrusion attempts. Meanwhile Windows was still not meeting my security needs. The problem was simple: the Windows distribution is bloated. Installing so many services increases security risk. With Windows you start from an insecure state; to attain security you remove components, restrict settings, reduce privileges. This is a flawed model. Linux on the other hand starts with a minimal, secure state...and then you add components, settings, and privileges as needed. So why was I running Windows in the first place? Convenience. I got locked into a blogging engine and wiki software; not to mention a huge NTFS volume that I did not have time to migrate.

Once I started looking into replacement services (file server, blogger, wiki) I had another major motivation to migrate: Drupal. If you are not familiar with it then stop reading and go here - you won't be sorry. Drupal is an open-source CMS written in PHP with support for MySQL and PostgreSQL. Its highly modular design gives it both a lightweight footprint and tons of pluggable features. There is very little in the content-publishing space that Drupal cannot do. And while it does run fine on IIS - it runs even finer on Apache. But before getting to the new stuff let's finish up with the motivation. If you have never taken an old machine - say a Pentium III 450Mhz 256MB - and loaded Linux on it then you really should...if nothing else you will see how powerful the machine still is. All that amounts to that 90's buzzword: ROI. But the details are real:
RAM (base OS): Windows: 128MB; Linux: 32MB
RAM (w/ httpd): IIS: 384MB; Apache: 128MB
Processor (mean utilization): Windows: 35%; Linux: 7%

And there is more, from the deployment limitations of ASP.NET blog engines to interoperability lock-in. After a while you just have to ask, why bother? Which leads us to a migration from Windows to Linux that would go something like this:

Windows Server 2003		Gentoo Linux kernel 2.6.11-r11
NTFS 5		Ext3
IIS 6		Apache 2
DasBlog 1.6		Drupal 4.6
FlexWiki 1.6		Drupal 4.6

Migration

• Backup was the first order of business. I needed a file-system that a (hardened) Linux machine could read from. Luckily my Mac Mini had both the storage capacity as well as support for Samba (Windows) and NFS (Linux). After using a script to remove all the legacy Windows files e.g. Desktop.ini, MP3 cover art, Thumbs.db, etc. I copied all my data from Windows host (basenji) to Mac Mini (beagle) using tar -czvf beagle.tar.gz /mnt/data /mnt/documents /mnt/music /mnt/video /mnt/source.
• Linux installation amounted to a standard Stage 2 Gentoo install.
• PHP installation was easy thanks to the dependency system of Portage: emerge mod_php. For a fully automated ride I added to /etc/portage/package.use the following line: dev-php/mod_php mysql gd. When the emerge completed I had a working LAMP stack - albeit configured for non-production use.
• Configuring and hardening Apache was a lengthly (yet crucial) step. Apache emerges configured for development use, so I made the following changes:
  • set UseCanonicalName Off
  • set ServerTokens Prod
  • set ServerSignature Off
  • remove all mod_* except (access, log_config, setenvif, mime, dir, alias, vhost_alias, rewrite)
  • tighten up mod_alias
  • tighten all <Directory *> to deny all
  My designs called for hosting document-roots on an NFS-mounted path - so clearly file-system security needed adjustment. I created /exports/data/sites (chown root && chgrp root && chmod 644). I created a document root for applanet at /exports/data/sites/com/applanet. Apache's mod_vhost is absolutely awesome. If you've only known IIS like me...then stop right now and check it out. I went with /exports/data/sites/%-1/%-2 for my multi-site needs.
• Drupal installation was anticlimactic. One note here: the Drupal ebuild for Gentoo has seemed flaky for a while...so I don't recommend that route. There is simply waaay too much that Drupal can be configured for so I will make a short list here:
  • SMTP mailer is confusing; for a decent start go here
  • use category and aggregator for site partitioning
  • use form_mail for a contact us page (other options are total overkill)
  • use mod_rewrite for clean URLs

Lights-On Once the LAMP stack was setup I used test-driven development methodology from there on. As a result I was able deploy and test sites throughout the migration. I now have a sweet build script for all my sites. I will write about it shortly...but the point is that I knew when to go lights-on: when there were zero tests failing. So this post essentially marks the re-opening of PerCS. I have a great platform now for some of my ideas...and probably some of yours too!