The Great 1U Linux Server Shoot-Out

By Jeffrey Carl and Eric Trager

Web Hosting Magazine
Web Hosting Magazine, July 2001

Web Hosting Magazine represented the high water mark of the market for print publications around the Internet Service Provider industry. In other words, it was probably my last-ever opportunity to get a paid gig writing for something that would appear physically on a newsstand. It was intended to be more focused than Boardwatch and, according to Wikipedia, “was written and edited with a deliberately ‘edgy’ style, designed to appeal to the primarily young and male constituency of the ISP industry.” Matt Loschert, Eric Trager and I contributed a few long-form articles before the magazine – like the rest of the telecom industry at the end of the dot-com era – vanished without much of a trace.

Are you looking for excitement, adventure and romance? 

Well, so are we. However, if you’re looking for 1U rack-mountable Linux webservers, we’ve got the goods.

Something Old, Something New, Something Borrowed, Something Blew

Last year, we agreed to meet with Web Hosting Magazine editor Dmitri Eroshenko about being hired to write an in-depth exposé on tradeshow booth babes. Instead, we were chloroformed and when we woke up, we had been locked in a small room with four thin rack-mountable Linux-based webservers to evaluate.

Some of the servers sent to us were early or pre-release models (dating back to December 2000). We were going to test them right away, but in early 2001, the web hosting provider that we all worked for at the time did a belly-flop into the financial deep end of the pool. This created some serious havoc, since it’s hard to do adequate server testing when you keep getting interrupted by people named “Guido” coming to the server facility to repossess your routers. 

As a result, we should note up-front that many of the questions or shortcomings noted in our reviews may have been addressed in more current versions of the servers (like improved documentation, or inclusion of the current Linux 2.4 kernel instead of the then-current 2.2.x kernel with SMP support compiled in). Some of the equipment we reviewed was clearly work-in-progress material, and that shouldn’t be held against the manufacturers, since they were kind enough to supply the results of their hard work to chloroform-hungover and inherently cynical server reviewers.

Hey, Nice Rackmount

Each of the servers was evaluated on 10 criteria:

1.) Out of box/set up/rack mount – How easy is it to get the server out of the box and into a rackmount production location? Is anything unusual about the server hardware and components?

2.) Documentation – What is the quality and quantity of documentation, and its comprehensibility for an intelligent but not necessarily experienced server administrator? How polished and professional is it? 

3.) Basic net configuration – How easy is it to configure its essential network connection information to get it online and accessible to the rest of the ‘net? 

4.) GUI tools – The intended user will probably want to use graphical setup tools rather than relying on the command line. How intuitive, powerful and flexible are these tools?

5.) Set up/start Apache/add a virtual host to Apache – Apache is the de facto web server of choice (and not without good reason) for the free *nix world. How easy is it to set up and configure a typical (but basic) Apache setup?

6.) Set up/start secure web server – If the server included secure (HTTPS) web server software (essential for encrypted e-commerce transactions), how easy was it to set up and/or configure?

7.) Set up/start SSH – Secure SHell (SSH) is more or less indispensable these days as a security-conscious encrypted replacement for the venerable telnet; if you’re going to do remote command-line administration, it’s a must. Is it installed, and how easy is it to get running?

8.) Set up/start MySQL – MySQL is the “Budweiser” of free relational database software, and is almost a necessity for DB-based site hosting on *nix. Is it installed? If not installed, is it easy to get and install?

9.) Sex appeal/miscellaneous – This section is for how the box looked and felt sitting on a rack, and other cool features or options which don’t fit in anywhere else. I guess the fact that we were willing to describe rackmount servers in any way with the word “sex” involved shows what losers we are.

10.) The big picture – What’s the overall assessment of the server, taking into account the good, the bad, and the ugly?

We decided to approach ease of use for administration from the point of view of a non-expert user – someone with an understanding of the concepts of what needed to be done, but without specific experience in using those tools. The idea was to be akin to someone who understood routing but would not know what to do at a Cisco IOS command prompt. 

We were unsure how exactly to address this, since we were all fairly well-trained *nix server administrators. We eventually decided that the best solution was to each drink about a gallon of gin before testing, to simulate the reactions of an unfamiliar administrator, AOL user or above-average intelligence eggplant. Okay, we were kidding about the last part, but we did decide to “jump in” to each server without thoroughly reading all of the included documentation – as many impatient server admins are likely to do. We hoped that skimming the manuals and trying to use our common sense as much as possible would replicate the experience of a “common-denominator” user.

The Heart of Dorkness

Here, then, were our testing results:


Model: ????

Suggested Price: ????


1. Out of Box Setup: It’s powerful, put it isn’t pretty. The dual Pentium-III (866 MHz) server we received came without a power cable or mounting brackets – making out-of-the-box setup difficult for those who aren’t prepared (we assume this little oversight has been remedied for production models). Access to the Ultra SCSI 3 (cool!) hard drives comes through the back fan setup – not entirely intuitive, but nonetheless pretty easy.  For access to the motherboard, unscrew the top of the case; upon looking inside, we questioned why the fan seemed to be placed right next to the internal cabling. 

2. Documentation: Frankly, the documentation we were provided with the demo unit was, well … awful for anyone other than an already-experienced Linux user. Clearly, the good folks at Siliconrax had spent their time on their server rather than their documentation (true to form for engineers), but what was included didn’t give us any “warm, fuzzy” feelings about the server. 

Items 3 – 9: The server was well-stocked, and included a standard version of Red Hat Linux 7.0 running a SMP-enabled 2.2 Linux kernel (2.2.16-22smp), with the powerful (although not, in our likely-to-be-controversial opinion, as user-friendly out of the box as KDE) GNOME installed as the GUI environment. 

Shortly before we were to begin detailed testing of the server, it was recalled home. We can easily imagine why, since it appeared that the evaluation server we had been given was clearly a beta-stage unit. While we were unable to put the server through its normal paces, this was probably a positive move, since the unit seemed to have been prepared for us in a rush and the loose edges seemed fairly evident. However, the server appeard to have a lot of potential, and we’re confident that more recent units of the server (which already included some pretty impressive hardware) will probably tie up those loose edges, and have a more polished and “finished-product” feel.

10. The Big Picture: Impressively powerful hardware for a 1U server, and Red Hat is a good choice of Linux distributions to ensure maximum compatibility with third-party applications. Due to the pre-release feel of the server, it probably isn’t kosher for us to offer an evaluation of the other aspects of the unit without adequate production-unit evaluation. While the server we reviewed wasn’t a very polished package, we think it certainly has potential.


Model: iBox 1U Server

Suggested Price: ????


1. Out of Box Setup: The test server we received included no install media; this can be a problem if, for example, you need to reformat the drives and re-install the default configuration. (Whether this is the case for production servers, we’re not sure; we guessed that this might be an early pre-production unit, since the dual-Pentium III server came in a box with a large “UltraSPARC-powered” sticker.) The server included extra ports, although we weren’t sure why. Nice features included an easy-open case for hardware enthusiasts, and dual power supplies for high reliability (a feature not seen on any of the other servers we evaluated).

2. Documentation: Like reading someone else’s college Computer Science Unix course notes. The box included a sheaf of black-and-white papers that were loaded with information but lost some points on presentation and organization. This, however, seemed like an excusable fault for a review unit; we assume that the documentation shipping with production servers is a bit more polished.

3. Basic Net Configuration: This posed a bit of a problem for us, since the IP address assigned to the machine in the default configuration we received was a non-routable one; we figured that either 1.) the presumption was that this server would be set up inside a protected LAN environment, or 2.) the machine had been shipped to us having just come from such an environment. Since our testing environment was a “real, live IPs” production setup, we initially could not access the server from any machine other than itself. As a result, we could not access the web-based administration from another computer and needed to play at the command line to get it set up for proper networking (in this case, we used linuxconf to change the IP address, then manually edited the Plesk httpsd.conf file to reflect the new IP). However, if you have a fair amount of experience with *nix servers, this shouldn’t prove too much of a problem.

4. GUI Tools: Once we had the server set up for networking, we tried the web-based adminstration. For its graphical interface, the server uses the popular Plesk GUI. Unfortunately for us, when we tried to run it, we received the message: “Time expired. If you want to continue to use PLESK, please buy a license.” This was obviously a simple error made in a pre-production server sent out for review but, alas, it ended our experiments with the GUI tools on the server. However, from other experiences with Plesk, we can vouch that it’s a very cool admin tool, and a good choice on the part of the designers.

5. Apache Setup: Kids, don’t try this at home. Lacking the Plesk GUI, we figured that we’d just set it up from the command line as we normally do. We can’t pinpoint exactly what happened along the way, but after we finished our normal setup routine, Apache was f***ed up beyond all recognition. This, in a sense, is an unfair response, since the system doesn’t seem to have been intended to be configured via the command line, and as noted, Plesk is a very good GUI configuration tool. Still, those seeking to administer via the command line should thoroughly check the documentation beforehand to avoid the kind of problems we encountered.

6. Secure Server: We learned our lesson and didn’t even try this one from the command line. However, a secure server is already installed, and outside experiences confirm that it isn’t too hard to set up via the intuitive Plesk GUI.

7. SSH Setup: Thankfully, SSH was pre-installed on the server, so we didn’t have to break anything manually.

8. MySQL Setup: Also thankfully, MySQL was already installed, so this prevented us from trying to set it up, which presumably would have ended up with the CPU catching on fire. 

9. Sex Appeal: The box itself was solid, although unremarkable. It was certainly impressive in the sense that it sounded like it had a jet engine running inside; the noise was noticeable enough to be slightly troublesome, but not loud enough to make us think that something was broken. Our only lingering question about the hardware we received was the choice of giving it great processing power (dual 800 MHz Pentium IIIs) but only 128 MB of RAM. 

For some reason, despite the obvious power of the machine’s hardware, we found for example that the popular emacs text editor seemed to run very slowly. This was possibly due to the seemingly underpowered (compared to CPU) RAM allocation, or the fact that emacs (“now with Kitchen Sink module!”) is a notorious resource hog. 

10. The Big Picture: Again, limitations in the testing unit prevented us from providing a really accurate evaluation of a production server. Still, from what we knew of the Plesk GUI and the installed software on the server, it should be a pretty user-friendly box, and the included software made for a good start for inexperienced server administrators. There’s obviously some solid engineering behind this server. Aside from minor quibbles about the included server hardware, we felt that the server has a great deal of potential.


Model: ServeLinux 1U Rackmount Server

Suggested Price: ????


1. Out of Box Setup: Whoa, this one was large and heavy. Its size and weight will make you wonder briefly about the stability of the supplied rack mounting brackets, but we can assure you that the included brackets hold up just fine. The install media we received was evidently an in-house-made TurboLinux 6 CD, with a hand-scrawled label. 

On the positive side, the box included ports on both front and back, and the case had keys and lockable drive bays for those concerned that their colo providers might randomly rip the drives out and use them for ping-pong paddles. The setup included wire ties, and there was thermal tape for the fan, as well. Still, the two 46 GB IBM DeskStar HDs offered ample if not excessively fast storage, and the dual 933 MHz Pentium III processors showed serious power.

2. Documentation: Bound, printed manuals with diagrams and good step-by-step walkthrough text. There is a separate manual for Slash, the GUI administration tool – a good choice.

3. Basic Net Configuration: On original startup, it launches a ServeLinux-branded LinuxConf-esque semi-graphical tool to configure basic network settings (allowing DHCP or static config). After entering settings into this tool, it saves these settings appropriately and then boots normally into Linux. This original setup screen also allows you to choose whether you’d like to use an SMP-enabled kernel or a single-CPU kernel.

4. GUI Tools: Uses Slash, a ServeLinux proprietary GUI for administrator setup. It runs on a secure port, which is a good choice. Aside from Slash for the administrator, it also includes Webmin for virtual hosting users to use. 

5. Apache Setup: Straightforward and easy with the GUI tools. As a bonus, Microsoft FrontPage extensions are included by default; we found it heart-warming that they would include default support for those individuals who have been enslaved by their unfortunate crack cocaine habit and chose to use FrontPage for their web publishing. As a nice bonus, the well-featured OpenMerchant shopping cart software was included as well.

6. Secure Server: Includes ApacheSSL, the open-source Secure Server variant of Apache. In the past, ApacheSSL has been derided for its relative lack of speed compared to commercial secure servers; but its integration with non-secure Apache, and speed increases in more recent versions, should make it a respectable choice.

7. SSH Setup: OpenSSH was pre-installed on the server, and was ready for starting via Slash without any problems.

8. MySQL Setup: MySQL was pre-installed and configured to work with Slash, which was a nice touch.

9. Sex Appeal: Like the StarBox server, the loudness of the fan made the server (sporting dual 933 MHz Pentium IIIs) sound like it contained a 12-cylinder engine idling in fourth gear. The box itself was pretty cool, sporting a hip shade of purple.

We applauded the choice of the powerful and easy-to-use Qmail as the default mail transfer agent; we love the venerable Sendmail MTA as much as the next *nix geeks, but in-depth configuration of the program is a mysterious black art like alchemy, necromancy or NASCAR. The server we tested had the TurboLinux 6 (a plucky upstart but solid distribution) using Linux kernel 2.2.14 with SMP enabled.

One of the nicest touches we found (something that should be an option with every *nix machine) was the “Mulligan” option, which refers to the golf term for re-taking a muffed shot. After running the original net configuration, if you find that you’ve screwed it up, you can run a special command (/root/Mulligan/Mulligan) from the command line interface. The server will then reset to its default net config options, reboot and present you with the original net configuration screen.

10. The Big Picture: For raw power, this one’s the winner. It lacks a bit of polish, and Slash may not have all the niceties that some other commercial GUIs offer; still, it’s got pretty much all the software you’d want, plus a few extra thoughtful touches. Overall, it’s a very nice package.


Model: ????

Suggested Price: ????


1. Out of Box Setup: Cobalt certainly pays attention to style as well as function. The box included rackmount brackets, and the server itself has plastic “feet” for surface-mounting. The front of the server has a cool LCD panel with simple button controls, through which initial network configuration settings can be made. Unlike the other servers, the Cobalt seemed deliberately constructed to make it difficult to access its internal structure;  simple enough for most users, but difficult for those of us who were determined to violate the warranty and crack it open.

2. Documentation: Documentation for Unix servers is frequently a pretty sparse thing, leaving novice users to thrash around; Cobalt does its best to ease the pain. The Cobalt includes a pretty cool spiral-bound book with thorough directions and screen captures. It’s also pretty obviously the documentation that the makers spent the most time and expense on. 

3. Basic Net Configuration: Basic net setup was easy, and could be done either through an LCD panel on the front of the unit or through a graphical web interface. Changes to IP address or net configuration required a reboot, although it seems that this information must also be stored in some sort of flash RAM (when setting the server up originally, we entered the network settings via the LCD before Linux even began booting).

4. GUI Tools: The Cobalt offered a good interface for configuring the server via a web page, with very simple layout and a rich set of features. The server management stuff was very cool, but we found it somewhat troublesome that the configuration was done through a non-encrypted session (call us paranoid, but we’re security-conscious enough that we’re troubled about sending our Slashdot usernames and passwords over insecure links). 

The GUI interface also offers configuration tools for many of the non-webserver and third-party software that ships with the server, like time, DNS, RAID and the Legato and Arkeia backup systems. It should be noted that besides the web interface (and the obvious command-line Linux tools), most of the most basic configuration options can be set with buttons on the LCD console. 

5. Apache Setup: Setup was very easy, and the included GUI tool was very cool; the more we worked on the server, the clearer it became that Cobalt had certainly spent more time than anyone else on the slickness and user-friendliness of their administration tools. The default Apache build includes mod_perl and mod_frontpage. Chilisoft’s ASP-on-Linux software was included as well (a very nice and otherwise expensive freebie), and its setup web tool was very cool; it also offered the non-Apache-standard ability to limit bandwidth by IP address.

6. Secure Server: Secure server setup is quick and easy to understand; we were never tempted to touch the command line to tweak it.

7. SSH Setup: For some reason we couldn’t explain, Cobalt had elected not to include an SSH server/client with the default installation (we figured the reason was probably Alien Mind Control Rays from Outer Space). Nonetheless, installing OpenSSH was rather quick and simple.

8. MySQL Setup: For a change, MySQL wasn’t pre-installed, but feisty challenger PostgreSQL was. We found it to be a nice choice.

9. Sex Appeal: Let’s just say it up front: the deep blue case looks damn cool, and the Cobalt logo on front lights up from inside – normally the sort of nice design touches you’d expect from someone like Apple. 

The default install includes APOP (secure POP3), and to add extra software, you can install Debian .pkgs provided with the server, or via HTTP through the GUI. One odd touch (depending on your point of view) is that the server can’t be shut down through the web interface.

10: The Big Picture: Unquestionably, the Cobalt is the slickest and most user-friendly one of the bunch. The extra third-party software included also makes it the top value – as long as you have need of it. However, we questioned some of the absent software; and it seems a little unfair to compare the polish of Cobalt to some of the other newer and less well-funded outfits on just polish – we feel that the others may easily catch up in time. Still, overall, the Cobalt is the likely choice, based on the units we tested, for a server with the power of Linux without the hassles (for many users) of Linux administration.

Summing it All Up

Let’s face it – Linux is Linux, Apache is Apache, and Pentium-based servers are Pentium-based servers. Variances in version numbers or clock speeds among these servers are important, but only a minor issue in the long run. What really matters are the price, the power and tested stability of the hardware, the polish and ease-of-use, and the extra goodies that are included – and which of these qualities are most important to you. One person’s winner is the other person’s loser.

All of the servers we tested (considering the improvements that were likely made between testing and release models, based on the promising work that had been done already) are more than adequate for the task of mid-range webserving. In the end, it comes down to which server suits your needs best. For price, ???? was the winner. Based on sheer power, ServeLinux comes out on top (but needs more default RAM!) And for software goodies and ease-of-use, Cobalt finishes way ahead of the rest of the pack. 

So, in the end, the decision comes down to which factors are most important to you. Fortunately, the fact that all of these servers are working with mutually available choices of software and hardware will keep them competing over who can build the best server from the newest equipment for the best price – making this month’s winner into next month’s potential loser. All of the servers we reviewed are worth keeping an eye on as they grow and progress – and they will all prove great potential values for web hosters.

Open-Source vs. Commercial Shoot-Out

By Jeffrey Carl, Matt Loschert and Eric Trager

Web Hosting Magazine
Web Hosting Magazine, May 2001

Web Hosting Magazine represented the high water mark of the market for print publications around the Internet Service Provider industry. In other words, it was probably my last-ever opportunity to get a paid gig writing for something that would appear physically on a newsstand. It was intended to be more focused than Boardwatch and, according to Wikipedia, “was written and edited with a deliberately ‘edgy’ style, designed to appeal to the primarily young and male constituency of the ISP industry.” Matt Loschert, Eric Trager and I contributed a few long-form articles before the magazine – like the rest of the telecom industry at the end of the dot-com era – vanished without much of a trace.

Welcome to part one of the Open Source vs. Commercial Server Software Shootout. This time around, we’ll be looking at Web Server Software (Microsoft IIS vs. Apache); Site Scripting (Microsoft ASP vs. PHP); and Microsoft Web Compatibility (FrontPage extensions and ASP options). Before you send nasty response e-mails (these, especially nasty threats, should be addressed to [email protected]), keep in mind that this is merely the advice of three long-time server admins; your mileage may vary). Tax, tags, title and freight not included.

Web Server Software


The breakdown between commercial and open-source web server engines is more about the operating system than the software itself. The most popular commercial option is Microsoft’s IIS, or Internet Information Server. It runs only on commercial operating systems: Windows NT, or the more robust Windows 2000. The far-and-away leader in open-source server options is Apache, and, while it features a version that runs in the Windows server environment, its flagship server runs under even obscure flavors of Unix and has no real competition. 

The battle of IIS vs. Apache in raw performance evaluations is as tangled as the Linux vs. NT benchmarks are. Depending on whose tests or opinion you listen to, you could hear everything from “Apache is blown away at heavy web loads” to “IIS all-around blows goats.” However – all OS and configuration issues aside – it’s probably safe to say that IIS performs better with heavy loads of static pages and Apache tends to handle lots of dynamic DB/CGI stuff better (at low loads, there’s little performance difference to speak of). Keep in mind, though, that because IIS is so tied to Windows and the Apache/Win32 version lags behind its Unix counterparts, it’s unlikely that there will ever be a really even contest between the two.

Since IIS is the clear leader with Windows servers and Apache is by far the most popular choice for Unix foundations, the comparisons here are largely about the duets of OS and webserver. Such a comparison is appropriate, considering how critical the operating system is in funneling the horsepower to a server with hundreds if not thousands of simultaneous clients (we hope your state motor vehicles department is listening).


Commercial Option: Microsoft Internet Information Server 5.0

Platforms: Windows NT/2000

Publisher: Microsoft,

IIS is a free package when Windows 2000 server software is acquired, and was available as part of an option pack for Windows NT server. IIS is technically free, but if your goal is to run a webserver and you choose IIS, you’re paying for it by choosing NT or Windows 2000. NT still starts at around $500 for the base server package, while Windows 2000 goes for around the same price and that’s only starting at a five-client license. While that license permits as many web hits as possible, those hits can only be unauthenticated requests; simultaneous accesses that are under a username/password are limited to the number of users permitted by the license (which really cramps your style if you’re running adult-oriented membership houses).

There are advantages to using IIS. One is a relatively simple installation and set-up process. Using an all-too-familiar GUI, a few points and clicks will have IIS serving pages on your Windows system in no time. Once running, IIS is administered with the same familiar Windows GUI and allows for easy access to run-time information including current access statistics and resource consumption. IIS also includes some niceties Apache doesn’t offer, such as making it easy to throttle bandwidth for individual hosts. The IIS setup allows file security to be set easily through the GUI (Apache allows some of this, but not as many options as IIS, and relies on Unix file security options for the rest). Also, it has a clear advantage in dealing with sites created using Microsoft tools (see Microsoft Web Compatibility below).

Using IIS also has its drawbacks. When looking at the open-source model as another option, the potential for security issues with IIS has to make you sleep less easily. Open-source bugs are usually squashed pretty quickly, when there are thousands of developers who examine the insides of a program. Microsoft has had issues in the past dealing with revealed exploits in an (un-)timely fashion, and there’s no reason to believe that IIS is any more immune than Internet Explorer or Windows itself.

Second, because it is tied to Microsoft’s server OSes, you’re … well, you’re tied to Microsoft’s server OSes. We don’t have the several thousand pages it would take to get into this, so we’ll leave it as a matter of preference. If it’s “the right tool for the job” for you, so be it. 

ALTERNATIVES: There are plenty of other commercial web server software options. The leader in marketshare after IIS as measured by Netcraft (, is iPlanet Enterprise Edition 4.1 (– the former Netscape server, now a Netscape/Sun collaboration – which starts at $1495; the iPlanet FastTrack edition is available for free. Zeus ( is widely known as a heavily optimized, very speedy server for Unix platforms, and starts at $1699. 

WebLogic ( is a popular application server that costs some amount of money, which I wasn’t able to figure out by reading their website. WebSite Professional (, the “original Win32 webserver,” starts at $799. And, for those brave enough to run a webserver on MacOS 8/9, there’s WebStar (, which starts at $599.

Open-Source Option: Apache 1.3.12

Platforms: AIX, BSD/OS, DEC Unix, FreeBSD, HP/UX, Irix, Linux, MacOS X, NetBSD, Novell NetWare, OpenBSD, OS/2, QNX, Solaris, SCO, Windows 9x/NT/2000 (plus many others; see for a list of supported platforms with pre-compiled binaries)

Publisher: The Apache Software Foundation,

The Netcraft ( survey listed the Apache webserver running 61 percent of sites reporting. While Apache’s awesome domination has slipped a little in recent years, it still holds the majority and runs well ahead of IIS, which has (as of this writing) a (relatively) paltry 19.63 percent of the market. Why is it that Apache has such a Goliath-like grasp on the field of webservers in use?

The reasons are numerous and simple. First, Apache is free. Consider that the business of the Internet is still relatively very young and, therefore, not terribly consolidated… yet. There are quite a few small hosting providers that need powerful web servers, and Apache presents an obvious choice, running on equally inexpensive operating systems like Linux and FreeBSD. Consider also that many businesses host sites remotely with those same providers, and Apache presents what has traditionally been the easiest server to configure and maintain remotely (through Telnet/SSH).

Second, Apache is stable and powerful. In years of work on both lightly and heavily worked Apache servers on different operating systems, I’ve had to work very hard to create a scenario that choked the server. The only problem that consistently knocked down Apache was the human one: like any program, Apache can’t work around typos in the configuration file and sometimes isn’t too descriptive about what’s wrong even through its apachectl configtest mechanism (although you’d be amazed at what you can get away with). Also, while IIS allows easy setup of most security permissions through its GUI, it can’t compete with the easy flexibility of Apache’s htaccess feature (especially when doing things like limiting access to a host with password permissions).

The Apache system is modular in nature as well. The initial package has what is necessary to get a web server online, but to accommodate special functions like FrontPage compatibility, persistent CGI, on-the-fly server status or WebDAV, server modules can be downloaded and installed to be incorporated into the Apache daemon. Apache maintains a directory of resources on available modules at The benefit is a streamlined program by default for what the majority of users need, and the ability to fatten it up for special functions only when necessary.

Apache has a few disadvantages. It isn’t nearly as easy to install as IIS; but for anyone familiar with administrative aspects of Unix systems (and that base is growing faster with Linux’s ballooning popularity), it’s rather simple to obtain, install, and configure. Support for Apache is free, but is not as easy to obtain as picking up the phone and calling Microsoft. Of course, considering the user base and its roots in a largely helpful Unix culture, plenty of assistance is there if you’re willing to look (and, please, look first). Lastly, Apache’s performance in some situations isn’t all it could be – hopefully the impending arrival of the heavily-rewritten Apache 2.0 will fix much of that.

ALTERNATIVES: Popular (relatively speaking) alternatives include AOL’s in-house (but open-source) AOLserver (; and the tiny but very fast thttpd (

Final Judgement:

Even the O.J. Simpson jury wouldn’t have much problem with this one. Apache takes the lead in so many categories that it’s not much of a contest. The user statistics don’t lie, either: in terms of servers out there, Apache beats IIS by three to one. While on the surface this could be attributed its cost (zero), remember that IIS is also free if you already have Windows NT/2000 (you did pay for that, right?). Ignoring that factor, Apache is generally regarded to be superior to IIS in reliability and overall performance, which, with a price tag of zero and a support network of users across the globe, makes it an extraordinary value. 

IIS has some bright points, which is important if you’re in the position of being locked into running your webserver on a Microsoft platform. If Microsoft is your exclusive IT vendor, if you’re hosting sites created with Microsoft tools or using third-party apps only available for Windows, or you have lots of Win NT/2K experience and little or no desire to learn Apache and Unix, IIS is your clear choice. Otherwise, even if you have Microsoft platforms running your IT infrastructure, administrative functions, etc, it may be well worth it to purchase additional systems to run Unix, just so your web functions can be handled by Apache.

Microsoft FrontPage Compatibility

For a web hoster, it’s becoming increasingly imperative to be able to provide compatibility for the primary issues associated with sites designed using Microsoft tools: support for FrontPage (Microsoft’s website-building tool, included with Office 2000) and Active Server Pages (Microsoft’s site scripting/application development framework with ODBC database connectivity). On Windows, the commercial option of Microsoft Internet Information Server (IIS) enjoys an obvious advantage, since it’s playing on its “home field,” built by its “home team.” Still, there is a free FrontPage alternative willing to put up a fight on Unix, as well as open-source and commercial alternatives for ASP and ODBC on Unix and Windows.

Commercial Option: Internet Information Server 5.0

Platforms: Windows NT, Windows 2000

Publisher: Microsoft,

Basically, IIS is the software that FrontPage and ASP were built to run with. Windows 2000 Server (which includes IIS 5) runs for about $950 – $1000 with a 10-client license. If you’re hosting on a Windows NT/Windows 2000 platform, this is a no-brainer. If, however, you’re hosting in a Unix (or anything else besides WinNT/2K) environment, IIS simply isn’t an option. There are no open-source alternatives I’m aware of for Apache/Win32.

Under Windows 2000, setup of IIS Server Extensions is pretty simple. After creating a new Web Site in the IIS administration interface, right-click on a site and select “Install Server Extensions.” A wizard will guide you through setting up the extensions for that host, including e-mail options (which you can set for that server or another mail host). After installation, you can select properties for that host’s server extensions through the “properties” dialog box by right-clicking on the host file. 

Once they’re set up, IIS (at least in my experience) supports FrontPage extensions and ASP scripts very well and without much need for special administration. If (when) you experience problems, you should check out the FrontPage Server Extensions Resource Kit (SERK) at Note that IIS 5 also provides support for Active Server Pages and ODBC (see below) on the Windows platform.

Free Software Option: FrontPage Extensions 4.0 for Unix

Platforms: AIX, BSD/OS, FreeBSD, HP/UX, Irix, Linux, Solaris/SPARC, Solaris/x86, Tru64 (Digital)

Publisher: Ready to Run Software,

The FrontPage Server Extensions for Unix (FPSE-U) version 4.x (version 3 was for FrontPage 98, 4.x is for FrontPage 2000) are available only for Apache on Unix platforms. These consist of an Apache module (mod_frontpage) and special binary server extensions that duplicate the publishing and server-side features offered by FrontPage. Note that I say this is a “free” software alternative, since it doesn’t cost you anything, but it isn’t open-source (sorry, Richard Stallman).

To install the FPSE-U, go to the Ready to Run Software site mentioned above, and download the extensions for your platform. These contain the FrontPage Server Extensions, the Apache module, and two installation scripts: (to install the extensions on the server and for each required host/virtual host) and (to replace your Apache installation with a default one including the FP module). I strongly recommend that instead of running, you download the “Improved mod_frontpage” ( and then compile your own Apache (following the instructions at, which will allow you to customize it and include the modules of your choice.

Once you’ve installed it, the FPSE-U generally work fine. You’ll need to learn to use the FPSE-U administration tool, fpsrvadm.exe, (check the FPSE-U SERK for documentation) usually installed into /usr/local/frontpage/currenversion/bin/, which generally isn’t much of a hassle. Note that I say “generally,” since (in my experience, at least) the FPSE-U have a habit of occasionally springing up weird errors which require a reinstall (especially as you try to support more FP users on Unix with more advanced requirements).

For troubleshooting, check out the RTR FrontPage 2000 documentation ( and their message boards ( as well as the official FrontPage SERK (listed above). Note that the FPSE-U don’t provide any sort of compatibility for ASP or ODBC connectivity to Microsoft Access databases (which IIS/Win32 does, as do the ASP alternatives listed below).

Final Judgement:

This simply comes down to your choice of platform. If you’re running Windows NT/2000 Server, there’s no reason (you’ve already paid for it) not to use IIS for this. If you’re running any version of Unix, the free software alternatives are all you have. If you’re running Apache for Win32 … well, why are you running Apache for Win32?

Active Server Page (.asp) Support on Unix

Commercial Option: Chili!Soft ASP 3.x

Platforms: AIX, Solaris, OS/390, HP/UX, Linux

Publisher: Chili!Soft, chiliasp/default.asp

ASP on Unix is already playing at a disadvantage, but for those wanting to support it on Unix hosting platforms (which have their own long list of benefits), it’s a necessary evil to deal with. Chili!Soft’s ASP product is relatively expensive ($795 for a single-CPU Linux or NT license; $1995 for Solaris, HP/UX or AIX). However, it seems to be reliable enough that IBM and Cobalt (recently purchased by Sun) have agreed to make Chili!Soft’s product an option on their server offerings; and, from most reports, it seems to work as advertised. 

For all supported platforms, Chili!Soft offers a fully functional 30-day trial version at Installation may require some pain-in-the-butt steps, but these are documented pretty well by going to and following the directions for your platform of choice. After installation, things usually go pretty much as expected.

For support, you can check out their well-maintained forums (, which offer frequent responses from Chili!Soft support employees, read their other documentation resources (, or call a phone number (for certain paid support packages).

ALTERNATIVES: These include HalcyonSoft’s Instant ASP [iASP] (, which is a Java-based solution that will run on any platform which supports a Java Virtual Machine (JVM). HalcyonSoft seems very committed to making their product available for as many platforms as possible, and offers a free “developer version” download. Note that for Win32 platforms, your commercial alternatives include Microsoft IIS, Chili!Soft ASP, iASP, and others.

Open-Source Option: Apache::ASP

Platforms: Any Unix platform supported by mod_perl (

Publisher: NodeWorks,

Apache::ASP is a Perl-based Apache module that works with mod_perl (with the common Perl module to handle uploads, and Perl’s modules for connectivity to databases) to deliver ASP functionality. This module is heavily dependent on Perl, and the better you are with Perl, the better you will be with using and debugging Apache::ASP.

To install, find the latest version of Apache::ASP at Run Perl on the Makefile, then run a ‘make’ and ‘make install’ on the module (for more help, see Additional resources for using Apache::ASP can be found at its homepage.

For support, try checking out the the Apache::ASP FAQ at, or the mod_perl mailing list archives at

ALTERNATIVES: For more information on ODBC database connectivity through Perl’s DBI/DBD, see (free) or (commercial). 

Final Judgement:

Since Apache::ASP works through Apache’s Perl module, be aware that its performance should be good, but, under heavy server loads, is unlikely to be as good as ASP support through a native binary (a similar concern exists for Halcyon’s Java-based iASP product). Apache::ASP is a good choice for basic installations or non-high-usage installations, but heavy usage, absolute mission-criticality or need for commercial-quality support will probably demand you use the Chili!Soft product (iASP provides commercial-quality support, as well).

Site Scripting Options

Commercial Option: Active Server Pages (ASP)

Platforms: Windows NT/2000, Windows 9x

Publisher: Microsoft,

Open Source Option: PHP Hypertext Preprocessor 4

Platforms: Most Unix platforms, Windows NT/2000, Windows 9x (See Apache platform information above for details)

Publisher: PHP Project,


As the Internet and the web have matured, CGI and dynamic content have rapidly replaced static HTML content for many sites. Unfortunately, as most developers will tell you, the increasingly complex requirements for dynamic sites have exposed many of the limitations of traditional CGI. However useful CGI was in extending the old infrastructure, it falls way short of current requirements for dynamic site design.

Quite a few software products are attempting to address the shortcomings of CGI and the desires of developers. They include products such as Microsoft ASP, Allaire ColdFusion, PHP, Apache ModPerl, and JSP, as well as others. 

We’ll take a look at ASP and PHP, two popular scripting packages that, at first glance, appear to be very different beasts; but on closer examination, show a striking number of similarities. 

ASP/PHP Common Features:

Script-Handling in the Web Server

One of the problems with CGI is that script execution usually requires the web server to spawn a new process in order to run the CGI script. The overhead of process creation is very high on some platforms. Even on platforms where it is efficient, CGI process creation can devastate performance on even moderately busy sites.

ASP and PHP have both sidestepped this problem by allowing the web server to handle the script itself. Neither one requires the web server to create an external process to handle a dynamic request. The script execution functionality resides in a module that is either built-in or dynamically loaded into the server on demand. The ASP functionality is part of Microsoft IIS, while PHP may be compiled directly into a variety of web servers including Apache and IIS. Although ASP and PHP handle this differently, the end result is more or less the same.

Session Handling

Due to the “stateless” nature of HTTP and CGI, it’s very difficult to “follow” a site visitor and keep track of his/her previous selections. As a kludge, developers have often posted data from page to page in hidden HTML form fields. This is neither convenient nor fail-safe, since it’s unwieldy and data can be lost between pages or compromised by malicious users.

ASP and PHP both have added support for “sessions.” A session allows the web server to simulate a continuous interaction between the user and the server. The server assigns the user a form of identification, and then remembers it and the data attached to it until the next request from that user arrives. Sessions minimize the amount of housekeeping work the developer must do to track the user across page requests. Again, ASP and PHP both provide good facilities for this.

Persistent Database Connections

Database access is a critical element for dynamic sites, providing a way to store and retrieve vast amounts of data that can be used to display tables of information, store user information/preferences, or control the operation of a site. A traditional CGI script has to connect to the database for each web request, query it, read the data returned, close the connection, and finally output the data to the user. If that sounds inefficient, it’s because it is.

To address this problem, ASP and PHP both support “persistent” database connections. In this environment, the web server creates a database connection the first time a user makes a request. The connection remains open, and the server reuses it for subsequent requests that arrive. The connection is closed only after a set period of inactivity (or when the web server is shut down). This is possible because the script execution environment remains intact inside the web server, as opposed to CGI where it is created and destroyed with the execution of each web request.

Again, this feature is a win for both ASP and PHP. Their syntaxes (though different) are simple and require no relearning of one’s database development knowledge.

Facilities for Object Design

A lot of useless information about Object-Oriented (“OO”) programming has been written, much of it presumably by people who either 1.) didn’t know what they were talking about, or 2.) were under the influence of Jack Daniel’s and horse tranquilizers. Here’s the real deal: OO design and programming allows you to encapsulate ideas in code through the combination of data and related data manipulation methods. Traditional programming has focused on the procedure that a program should follow, with data used as a “glue” to store information between and during procedures.

OO design focuses instead on the data and how it should act under different circumstances. This is done by housing data and function in distinct packages, or “objects,” that can’t interfere (except in predefined ways) with other objects. It is not a cure-all for poor programming, but it is a facility that allows for the creation of better software through good design and programming techniques. ASP and PHP both support the OO notion of classes (the definition of an object) in order to develop applications that are more modular, robust, and easier to maintain.

Access to External Logic Sources

Many designers would argue that for a truly complex installation, the site’s application or business logic should consist of objects completely external to the website and its presentation facilities. This is highly desirable since it allows you to build business objects that can be used for more than just your website and can be maintained apart from your site presentation code.

ASP and PHP allow you to access two types of external logic sources. The first, COM objects, are a Windows-based object framework. The second, CORBA, is a generalized network-transparent, architecture-neutral object framework. This support, especially of CORBA, is a huge win for both ASP and PHP.

ASP Features:

Ability to Utilize Different Programming Languages

When designing ASP, Microsoft made the decision not to tie the technology to a particular programming language. Although VBScript is what most people think of when they hear ASP, other popular language options include VBScript, Microsoft’s JScript, and PerlScript. This flexibility is especially useful if you or your development team has previous experience with one of these languages and your schedule precludes learning a new language for your current project.

Tight Integration with other Microsoft Software and Tools

For some, the ability to use Microsoft tools is a blessing; for others, a curse. For better or for worse, ASP is tightly integrated with other Microsoft tools. If you are comfortable with a Microsoft development environment, this could easily decide your scripting package for you. On the other hand, this tight integration can turn into a nightmare if you encounter insurmountable platform issues, as many Microsoft Windows tools do not have analogues on other platforms.

PHP Features:

Written Specifically As a Web Scripting Language

PHP benefits from being written from the ground up as a web-scripting language. It is tight and targeted, without the bloat that a general purpose programming language would have. This results in a package that is extremely stable, has a small memory footprint, and is lightning fast.

Integrates With Many Platforms and Web Servers

Version 4 of PHP was written using a new generalized API, which allows it to be ported more easily to other architectures and integrated into a variety of web servers, including Apache, Roxen, thttpd, and Microsoft’s IIS. It also is available for just about every type of UNIX as well as Windows 9x/NT/2000.

Final Judgement:

Both PHP and ASP have addressed many of today’s most critical web development needs. Both offer a ton of features, easy interfacing with all sorts of databases, and the facilities to create complex applications. For many, the decision will come down to a preference for one language or another, depending on what he/she has experience with already.

If the programming language is not a decision-making factor, the decision will probably come down to a choice of hosting platform. If you host on Windows, IIS/ASP is the obvious choice because of their tight integration. PHP operates quite nicely under Windows, but who in his/her right mind would turn down all of the resources Microsoft provides when working on its own platform? On the other hand, if you’re Unix-savvy, the decision to go with PHP is just as simple. PHP was born on Unix and built on top of Apache.

In the end, the question may not really be which solution is better, but which better fits the resources and needs of your project.


About the Authors:

Jeffrey Carl (Microsoft Web Compatiblity) is the Linux/BSD columnist for Boardwatch Magazine, and has written for the Boardwatch Directory of Internet Service ProvidersCLEC Magazine and ISPworld. His writings have been featured on Daemon NewsLinux Today, and Slashdot. He saw the plane dragging the “Web Hosting Magazine Kicks Ass” banner over the Spring 2000 ISPCON and agreed.

Matt Loschert (Site Scripting) is a web-based systems developer with ServInt Internet Services. Although he works with a variety of systems, programming languages, and database packages, he has a soft spot in his heart for FreeBSD, Perl, and MySQL. He begged Jeff to let him pretend to be a writer after hearing how cool Web Hosting Magazine was.

Eric Trager (Web Servers) currently serves as managing director for ServInt. With a background in personnel and operational management, Mr. Trager oversees ServInt’s daily business functions. His technical background includes four years in Unix server administration. He’s never read Web Hosting Magazine, but Matt and Jeff told him it was cool, so he foolishly believed them and wrote an article.