By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

This column was originally supposed to be about supporting FrontPage users on Unix, but Boardwatch’s editors edited all the swear words out of my 2,000 word column and were left with a total of 12. So instead, I turned to Macmillan’s Linux-Mandrake 7.0. 

The Basics

Linux-Mandrake 7 is earning rave reviews all over the place right now, and with pretty good reason. Linux-Mandrake is heavily optimized for Intel Pentium-family chips, but should run fairly well on AMD or Cyrix-based systems. System requirements are listed as any 586 (Pentium-equivalent) or higher CPU, 16 MB RAM (64 MB recommended), 500 MB disk space minimum (1 GB+ recommended), and a 3.5″ floppy drive or CD-ROM drive for installation.

Linux-Mandrake 7 is available free via FTP from http://www.linux-mandrake.com/en/ftp.php3. It comes in standard FTP install format, as well as a downloadable ISO 9660 CD image. MandrakeSoft itself sells distro CDs, and Macmillan also distributes and sells three shrink-wrapped versions of Linux-Mandrake 7.0: Complete, Deluxe and Secure Server (see below in the interview for more information on what the different packages contain). The Complete package retails for $29.95 (although I found mine at Wal-Mart for $25); Deluxe sells for $55-$60, and the Secure Server package sells for about $100.

The Distribution

The distribution is pretty up-to-date (at least as of this writing). It includes kernel 2.2.14, glibc 2.1.2, XFree86 3.3.6, and more. All of the defaults here are stable – you won’t find anything too bleeding edge in the included components, so if you want to wreck your system with the development kernel or XFree 4.0 beta du jour, you’ll need to go out and download it for yourself.

Most of the clamor for Linux-Mandrake 7 has been over the reports that it’s the easiest Linux distribution ever for a new user to install and set up. Mandrake’s efforts in this direction are focused on three new (or at least fairly new) tools. 

The first and second are DrakX, first introduced with Mandrake 6.1, and DiskDrake. DrakX is the new all-singing, all-dancing, all-graphical installation tool – and it’s certainly the most user-friendly install tool that I’ve seen for a Freenix (an install tool with themes?). It handles all of the basics you’d expect, as well as taking a good stab at autoconfiguring the LILO boot loader and X Windows (plenty of drivers for popular video cards are included). DiskDrake is the graphical disk-partitioning tool for use with DrakX, although you can also use good old fdisk or cfdisk. 

The third new tool is DrakConf, which bundles in LinuxConf as well as its own versions of hardware, software, networking and security tweaking tools. For a user or administrator new to the platform, DrakConf keeps a lot of common tools very handy. Also available are RPMdrake (for RedHat Package Manager installations) and Lothar, a nifty program for autoconfiguring sound cards and other audio-related devices.

So, what’s not to like? With all of the goodies in this distribution, Mandrake has its sights squarely focused on its intended consumer – and that consumer probably isn’t you. Linux newbies and desktop/workstation users are the target market here, and it isn’t evident that much has been done to optimize or enhance Linux-Mandrake’s performance specifically as an Internet server.

However, that last assessment may be a little too harsh (or too much to expect). Regardless of what type of user you are, good administration tools help everybody; and the Pentium optimization certainly helps if you’re running an Intel-based server. And to some extent, every Linux distribution uses some version of the same kernel, so there isn’t much you can expect Mandrake to do to increase the performance of the Linux TCP stack. 

The Questions

To find out more about the appeal of Linux-Mandrake 7 for ISP/webhosting users, I asked Steve Schafer, the Senior Title Manager for Linux at Macmillan.

Jeff: Can you give a brief history of Linux-Mandrake?

Steve Schafer: Linux-Mandrake started as a volunteer project to help make the standard Red Hat Linux distribution more robust and yet more user friendly. Approximately two years ago the principals of the project created a company, MandrakeSoft, to oversee and lead the project into a retail venture. Version 5.3 of Mandrake was built from the Red Hat 5.2 distribution and was distributed through outlets like LinuxMall. The distribution continued to gain a following for power and ease of use. Versions 6.0 and 6.1 went on to win the “Editor’s Choice: Product of the Year” award at LinuxWorld in 1999, and various kudos for being a “better Red Hat than Red Hat.” Mandrake 7.0 raises the bar even further as you will see below.

J: Why should I use Linux instead of another Freenix like FreeBSD or OpenBSD? 

SS: One word: support. Linux remains on the cutting edge of technology, with solid support both online and paid, the latter provided through retail purchase or a support contract through a dedicated Linux support organization like Linuxcare. The interface and standards continue to evolve, presenting a clean, more user-friendly environment for a technical OS.

J: What’s new with Linux-Mandrake 7? 

SS: The main differences in 7.0 come in the way of installation and configuration. The new graphical install (DrakX) can be tailored for each user’s tastes and technical level – the “Recommended” install provides for less decision making on the part of the user and makes various assumptions about the target machine to make the install fairly seamless, while the “Expert” install allows the user full-control over how the OS will be installed. Several new customization utilities allow the user to quickly and effectively change the configuration once the OS is installed, changing the interface, security options, adding and configuring hardware, and more. Mandrake continues their tradition of offering more base utilities and pre-configured desktops as well.

J: How does Linux-Mandrake perform for Internet serving tasks in relation to other Linux distros? Is the differentiation something other than performance (e.g., ease of use, pre-installed apps, etc.)?

SS: By and large, most Linux distributions perform the same types of serving tasks since they are all cut from basically the same mold. The difference Mandrake makes comes in two areas: customization and Pentium optimization. See the other section(s) for info on the customization (both what Mandrake does automatically, and what tools exist for the user). As for Pentium optimization: Mandrake recompiles ALL packages with Pentium optimization. Although the performance increase for workstations is slight, it is much more pronounced in the server environment. When a server is loaded with several users all utilizing resources, the faster the server can complete tasks, the better. (Of course, this is only true if the server’s processor is Pentium [or derivative] based.)

J: What are Linux-Mandrake’s different products, and whom are they intended for?

SS: Macmillan offers three distinct Linux-Mandrake products, geared toward specific Linux customers:

Complete: This value-packed product is geared toward the beginning user, or the user who is taking Linux for a “test drive.”  Macmillan adds the following components to the base Linux-Mandrake OS:

• PartitionMagic and BootMagic – for ease of installation on a Windows machine for dual-booting between OSes. (Recent research showed that 70% of retail Linux purchasers install Linux in a dual-boot configuration.)

• StarOffice 5.2 – This powerful office suite provides word processing, spreadsheet, presentation, and graphics functionality. Compatibility with Microsoft products ensures maximum data transportability.

• Linux Library – 3500 pages of additional Linux documentation (in electronic form) from the Macmillan imprints Que and Sams.

Deluxe: This six-CD set provides the most Linux content for the money. Geared to address the professional user, this product provides more of everything Linux. In addition to the base Mandrake OS and its sources, these additional 4 CDs are provided:

• Contributors CD: Close to 900 additional utilities, applications, documentation, etc from the Linux community.

• Contributors Source CD: Source code for the Contributors CD.

• Applications CDs (1 & 2): Over 30 commercial and demo applications, including StarOffice, WordPerfect for Linux, etc.

[Jeff’s Note: The Commercial Applications CDs (available with the Deluxe version) includes full and limited versions of some very tasty goodies including: Acrobat Reader 4; Executor (a MacOS emulator); IBM’s JDK, Lotus Notes and ViaVoice (voice recognition word processor). It also has demos of the games Civilization: Call to Power, Railroad Tycoon II and Myth II; an evaluation version of VMware; and WordPerfect. True, almost all of this is available via download – but if you’d like it all in one easy-to-install package, this is a mother lode.]

Secure Server: For the professional “with a purpose,” this product offers the base Mandrake OS bundled with a secure Web server for starting an e-commerce operation. Additional utilities and a custom Linux Library (over 4200 pages of electronic docs from Que and Sams) round out this product.

J: What are Linux-Mandrake’s particular strengths? What are its weaknesses?

SS: Mandrake’s strengths include:

• Red Hat compatibility

• Pentium optimization

• Cutting edge components (latest kernel, XFree, etc)

• Scalable graphical installation

• Pre-configured desktops and user interfaces

• Comprehensive graphical configuration tools

• Additional packages, drivers, utilities, apps and more

Honestly, it’s hard for me to think of weaknesses regarding Mandrake. This distribution has the depth to satisfy the hardcore user, but the simplicity (install and customization) to engage the beginner as well. Linux overall does have weaknesses, mostly surrounding the implications of open source and staying ahead of the technology curve. For example, there isn’t one multi-million-dollar firm behind the Linux distros (Microsoft) and the kernel has just begun to support technologies like USB. Keep in mind that these disadvantages exist across the spectrum of Linux, not just with Mandrake.

J: Why should I use Linux-Mandrake instead of another distro for my web, mail or dialup authentication server?

SS: All the reasons stated above, particularly the ability to support the latest hardware, ease of customization, bundled components, etc. This is true across the board of applications (web, mail, dialup authentication, etc).

J: What’s the recommended hardware for a Linux-Mandrake Internet server? Is there anything that works particularly well?

SS: The answer really depends on the workload and user load the particular box will experience. One prominent ISP (CiHost) uses Red Hat for their Web hosting servers which are dual-Pentium boxes. Recently LinuxWorld (February in New York) used Mandrake for their registration system, probably high-end Pentiums using dumb terminals (low-end boxes) for input. 

When considering Linux-Mandrake, it’s important to consider running on a Pentium or derivative due to the recompilation using Pentium optimization.

J: How easy/difficult is it to migrate from another Linux distribution to Linux-Mandrake? Is there anything I should know?

SS: It depends on what you are migrating from. Although most Linux distros are pretty much the same, some vary considerably in customization, installed tool sets, libraries, etc. Like migrating between Windows versions, you want to ensure that your added tools (applications, utilities, etc) are compatible with the new system. Red Hat and derivative Linux distros use some different libraries than other distros, requiring different base level support for some programs.

J: On the client side, can ISPs support Linux-Mandrake dialup users easily? Why?

SS: You should be able to with no problem. Linux speaks the Internet natively (TCP/IP) so utilizing a PPP dialup is almost second nature to the OS. It’s a bit tougher [for the user] to set up than [for the ISP to] support really … the ISP shouldn’t have to change a thing. 

The Conclusions

As Linux distributions go, Linux-Mandrake 7.0 is very good. Aside from some strange gaps in documentation (for example, my Macmillan Linux-Mandrake Complete “User Guide and Reference Manual” didn’t even mention DrakConf), it seems pretty solid.

For the ISP/web user, there are two groups that will find it particularly compelling. First are new users/admins who want the easiest, most pain-free installation and setup. Second are users with Pentium-based machines, who may see impressive speed gains over other distributions. Note: I wasn’t able to throw enough machine load at my test server to test this out reasonably; if someone out there does, please let me know the results. For anyone, though, Linux-Mandrake 7 is certainly worth a look.

By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

“Jabber” and “Zope” sound like two characters from “Alice in Wonderland.” Or maybe characters in Quake II (“jabber saw the light from zope’s BFG-10K”). Either way, what they really represent are attempts by the open-source community to beat commercial offerings in emerging critical Internet areas: instant messaging (IM) and web application development. 

Can they do it? On one hand, projects like Apache and Linux or *BSD have shown that open source software can lead the industry in performance. On the other hand, both projects face the perennial Achilles’ heel of open-source projects – lack of commercial distribution channels and a corresponding difficulty in gaining enough market share to become a standard. Let’s take a look at both projects, how ISPs can use them, and whether they can beat the big commercial packages.

Jabber

Once upon a time, there was Mirabilis ICQ (“I Seek You”). And lo, it was good. Then it was bought by AOL and became the basis for AOL Instant Messenger (AIM). Then Microsoft’s MSN and Yahoo! got into the act with similar programs that could communicate with the zillions of ICQ/AIM users. Then AOL said, “Oh no you don’t.” Then Hell froze over and Microsoft started complaining to AOL about “open standards” and MSN et. al. whined to Congress about it…

Right now, IM is a mess. AIM, with an astonishing 45 million users, holds tight to its grip on ICQ, keeping its service proprietary. Few people are inclined to shed tears for Microsoft because it’s being disadvantaged by proprietary systems. Still, many users are seeking an IM program that, like J.R.R. Tolkien’s “One Ring,” would “bind them all together.”

What is it?

There are plenty of open-source ICQ clones (like LICQ [www.licq.org], popular on Linux). Jabber is quick to point out that it isn’t just another ICQ clone. As the project’s FAQ page says: 

Put simply, Jabber is an open source, cross-platform, completely extensible, end-all to Instant Messaging as we know it. Never again will you have to worry about finding the right client to talk to your friends, nor will you have to concern yourself with having three or four different clients open so that you can chat with all of your associates. And all you have to do is pick the client that you like for the platform you want!

Jabber is genuinely different from other instant-messaging products, although the differences are “under the hood.” A Jabber user gets an account with a Jabber server, and the server then takes care of all the “heavy lifting” – communicating with other servers and translating the protocols of other IM systems into Jabber’s own XML (eXtensible Markup Language)-based messaging protocol. In theory, server modules can be written to parse any other IM protocol, and connectivity to those systems is then automatically provided to the client. 

How does it work?

Joe User gets an account with a Jabber server. He also gets accounts with AIM and Yahoo! Pager. His Jabber server stores his account info and “buddy lists” (roster) for each IM service, allowing him to access all of them through his one server and one client. Assuming that the server has the requisite protocol “transports,” he can then communicate with users of any of these services from his Jabber client. 

The native Jabber protocol is an XML stream over a TCP socket, allowing for a number of possibilities for how and over which port it can be sent (a bonus for its potential ability to evade firewalls, critical to the success of any IM protocol). The Jabber client communicates only with its server, which then handles all of the protocol-translation and communication issues. 

What’s so great about it?

Obviously, the ability to communicate with any IM protocol is a huge plus, potentially making Jabber the “holy grail” of IM platforms. Also, its reliance on the server model simplifies matters for users significantly.

While it promotes unity among IM protocols, Jabber also promotes competition within its own ranks, and Jabber users can choose from a number of different Jabber clients, each with their own foci, strengths and weaknesses. Its open standard and protocol means that anyone who would like to create a new client or offer new features can do so with (relative) ease.

Also, Jabber is intended to be cross-platform. Work on clients is reportedly underway for *nix on command line and X-Windows, Win32, MacOS, browser-based, and even Newton.

What still needs work?

As of this writing in mid-April, just about everything. Jabber is still very much a work in progress (its server has yet to reach 1.0 status or implement working transports for other IM systems), and it remains to be seen a.) how well its compatibility with other IM protocols will work, and b.) how well it will work by itself. Most of the clients are still missing some user-interface niceties, and a working standard for security/encryption of Jabber messages has yet to be implemented.

Jabber is like Rambus – one of those long-shot bets which will either take over the world or be a perennial also-ran. It has all of the right ingredients, but only time will tell whether it fulfills its promise. 

A critical hurdle is the same interoperability issue which has plagued other IM clients: will AOL try to block it? AOL’s ICQ users are such a tremendous asset to AOL that it’s hard to imagine that AOL won’t try to block Jabber out if it gains much share of the market. The jury is still very much out on Jabber’s eventual success … and whether, if it can’t communicate with others, it can succeed on its own.

Zope

Zope (the “Z Object Publishing Environment”) is … well, it’s hard to describe in a hurry. But it’s very cool.

What is it?

It describes itself as an “application server,” and its goal is to provide a framework for creating and maintaining large websites with advanced functionality like site users, feedback and content databases. Elements of Zope (currently at version 2.1.6) compete with both higher-end commercial software like WebObjects or Cold Fusion, as well as open-source site spinoffs like slash (the source code for the backend to  slashdot.org). 

Zope is portable, since it’s written in Python (with some performance-critical parts in C); currently, it runs on Windows NT and nearly any Unix. Installing and running Zope requires that you have Python (http://www.python.org) version 1.5.2 or higher installed on your server. It requires Python to be built with threads support; if you’re installing Python to use Zope, be sure to run the pre-installation configure script with the –with-thread option.

Zope began life in the Bobo Web Object System, developed by a company called Digital Creations (http://www.digicool.com). The Bobo framework was open-sourced, while the company sold a commercial application server based on it, which was named Principia. 

Seeing that the application server market was dominated by big names whose marketing muscle Digital Creations could never compete with, the company decided in December 1998 to combine Principia and Bobo, rename it Zope, and open-source the whole shebang. Zope began to gain recognition and users, while Digital Creations shifted its business model to providing commercial support and consulting for Zope.

How does it work?

The heart of the system combines an ORB (Object Request Broker) with an object database, allowing pages to be simply and dynamically created. The main components of Zope are: 

• the ORB, which extracts information from the database

• the object database itself 

• the publisher, which interfaces with a web server

• the template system, for dressing up content in your customized page templates

• the management structure, which handles authoring/access permissions 

Here’s the short, short version: you download Zope to the server where its content will be server from. Zope is available as a Windows executable, in RPM format for Linux, or tar-gzipped source archives for Solaris, Linux or any other *nix. For a quick start, just run the Zope setup script, then run the start script it builds, and away you go. Zope launches its own web server on the port of your choice (default 8080), although you can easily configure it to use Apache, IIS or another server.

You can then use a web browser to view pages or go to its “manage” interface. Using these controls, you can create new folders and add content to them. You also use the manage interface to assign basic functionality (who can access or alter the contents, HTML templates and error messages, etc.). This interface also provides “approval” and “undo” functionality as well.

The content comes in the form of … well, lots of things – users, images, or other items usable by the database. Primarily, though, it will be DTML (Document Template Markup Language) objects, which can contain XML, DTML or good plain old HTML. DTML works like server-parsed HTML on steroids, offering very advanced functionality. An example might look like this:

<!–#var my_header–>

<!–#if “AUTHENTICATED_USER==’Jeff'”–>

<h3>Here is the customer list:</h3>

<table>

<!–#in showCustomers–>

<tr>

<td><!–#var cust_name–></td>

<td><!–#var cust_type–></td>

<td><!–#var acct_balance–></td>

</tr>

<!–#/in–>

</table>

<!–#else–>

<em>Sorry, you can’t read this!</em>

<!–#/if–>

<!–#var my_html_footer–>

And there, you have a complete, well-formatted HTML page. The DTML page above calls in an external HTML page header that you uploaded named my_header, checks to see if the user has permission to view a table, and if so calls an object which is a SQL query that you defined earlier called “showCustomers” and displays the results in a table. If the user viewing the page isn’t the one it expected, it prints an innocuous HTML message. For everyone, it then prints the external HTML footer you named my_footer.

All of this can be easily done with CGI, but learning the DTML syntax is significantly easier for most people than learning Perl or C. Furthermore, the ability to integrate this into a sitewide management structure is a big plus.

So, essentially, with Zope you don’t so much build pages of a site as you build objects of content – FAQs, stories, other information – which get stuffed into a database. You then create folders and pages that are DTML frameworks which can include one simple content object (for a simple, non-dynamic page) or make complicated queries (the last five news objects submitted, all objects submitted by a certain author, the most recent graphic of a certain type, SQL queries, etc.). If you’re unfamiliar with the process, it takes a while to “wrap your head around it,” but it provides a tremendous amount of possibilities.

A very readable introduction that lays out the functional aspects of using Zope (as well as giving a much better explanation of DTML examples like the one above) can be found at http://www.devshed.com/Server_Side/Zope/Intro/. An in-depth look focusing on Zope’s database model is at http://webreview.com/pub/1999/03/05/feature/index2.html. There is an excellent library of pre-built and member-contributed projects that provide example code to learn from at http://www.zope.org/Products, as well.

What’s so great about it?

First, Zope provides an interface to adding/administering the site’s content which is accessible through a web browser. It allows for relatively complex security/permissions setups, which allow the administrator to set access privileges for various groups of contributors (administrators, writers, designers, etc.). Zope makes use of the emerging WebDAV (“Web-based Distributed Authoring and Versioning”[www.webdav.org]) standard to collaboratively manage and handle versions of pages or objects on a site. This also allows for good integration with existing software which supports WebDAV, like Microsoft Office 2000 or Internet Explorer 5 on the client side or Apache with mod_dav on the server side. 

Zope provides its own transactional object database, which means that you won’t need to add another database (e.g., MySQL, Oracle, MS SQL, etc.) to provide a back-end. One of the primary benefits to using a transactional (keeping track of additions/changes as “transactions”) database like the one Zope provides is that it allows you to “undo” changes if you need to. The database is optimized to match the needs of most web databases, which are frequently being queried but only occasionally have new data written to them. The Zope database is also easy to back up, and is designed to work with “simple URLs” (unlike those created by WebObjects).  

One of Zope’s strong features is interoperability with existing SQL databases. You can set up a Zope database connection to an existing database and apply SQL queries from a Zope DTML page to the older database. Zope also makes good use of XML, allowing interoperation with XML data sources. The Zope database stores a great deal of information besides just your primary content objects; it also keeps track of user postings and threaded discussions, user logins and permission settings, and allows users to customize the way they view the site.

Like any good open-source product, Zope makes very good use of open standards. Aside from WebDAV, SQL and XML, Zope supports HTML 4 and CSS, HTTP 1.1, FTP, FastCGI, DOM, LDAP and other goodies. 

Lastly, it was announced in late March that Digital Creations would be open-sourcing its ZEO (Zope Enterprise Option), which can turn Zope into a distributed system. Allowing Zope to scale to multiple machines should make it a feasible choice for high-demand sites which need to be served from multiple machines. Zope has also announced interoperability with Microsoft’s SOAP (Simple Object Access Protocol) sort-of-standard. Whether this will become a “big deal” remains to be seen.

What still needs work?

At first glance, Zope is just plain difficult to understand for most people. The Zope feature tour (http://www.zope.org/Tour/ar01.html) is a good start, and the Zope Guides (http://www.zope.org/Documentation/Guides) are helpful (if understandably incomplete) but some more “hand-holding” higher up in the online documentation might convince more users to “get their feet wet” with Zope.

Zope is certainly on the right track with the emerging standards it uses, but some of these standards will take time to build the user base to allow Zope to really shine (for example, when WebDAV publishing will work from more applications than just IE 5 and Office 2000). The WebDAV standard itself isn’t fully fleshed out yet, and I have to admit that any standard which Microsoft has taken a strong interest in makes me worry a bit.

Lastly, Zope simply isn’t for everyone. If you have a relatively small or simple site, the overhead of learning and serving Zope will probably be a waste of time. If you’re willing to put in the time, using Zope from the get-go will help you scale your site if you need to – but in many cases, using Zope is swatting a fly with a sledgehammer.

The Verdict: Jabber, Zope and You

What can Jabber and Zope do for you? Well, in the short term, you can offer support for them and promote them to your customers. With Zope, ISPs can offer Zope support and make a presence in the small (but growing) market for Zope site-hosting. 

With Jabber, ISPs can run their own local Jabber servers. In the short term, it can be used by supplying your NOC with a Jabber nick through which clients can contact them; in the long term, if Jabber meets its promise, your local Jabber server can be a great way to tie users to you (to be Machiavellian, your Jabber server will hold all of their IM contacts and make it a pain to migrate elsewhere).

Will either of these projects ever gain the ubiquity of Apache, sendmail or Linux/BSD? Probably not. But Jabber holds an extraordinary amount of promise, and can be an excellent value-added tool for ISPs – and it’s free – so there’s little reason not to be an early adopter. Zope will almost certainly remain a limited-interest project, but it can be of use to you for your own web sites as well as providing a differentiating service for site hosting. 

Can Jabber and Zope beat out the commercial competition? Only time will tell. But, considering the cost (nothing but your time), it’s almost a no-brainer for you to “do the right thing” and support open standards, and to investigate providing support for both with your ISP. 

Who knows? If you bet on enough long shots, one of them might turn out to be a winner.

By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

Are you looking for an easy web-based GUI to administer Unix servers? Want to provide your Unix clue-challenged hosting customers with an easy way to administer their machines? 

If so, try Webmin (http://www.webmin.com/webmin/), a free application which allows you or your users to easily administer their Freenix system through a web interface. You can use it yourself, or you can offer it to clients with dedicated web or mail servers to do some of their own administration and take the burden off of you.

Installation and Setup

Webmin is a Perl 5 program that allows you to configure everything from user accounts to DNS and Samba filesharing and more. Webmin is free, and runs on a wide variety of Linuxes (including Caldera OpenLinux, RedHat, S.u.S.E., Slackware, Debian, TurboLinux, Mandrake, Delix DLD, Apple MkLinux) as well as FreeBSD and OpenBSD. It has been most thoroughly tested on Caldera OpenLinux, RedHat and FreeBSD, but it should run fine on other systems with potentially a bit of tweaking. 

To install, go to ftp://ftp.webmin.com, and select the most recent version of Webmin (webmin-0.78.tar.gz at the time of this writing). Unzip and untar the file, then run the included setup.sh to install Webmin. Answer a few questions about your system setup, create a username and password for yourself, select a port for Webmin to run on, and you’re ready to go. To upgrade, download the source for a new version and specify the source file’s location in the Webmin interface’s Webmin Configuration -> Webmin Upgrade option.

Webmin is modular in nature, and comprises a “core” Webmin server with a number of default modules. Each module (like Cron, BIND, Syslog, etc.) provides administration functionality for its specified service. At installation time, all default modules are installed; you can remove modules through the Webmin interface, or download new third-party modules from a link on the Webmin home page. Webmin stores configuration files for all of its modules inside directories located (usually) in /etc/webmin/modulename/. The start and stop scripts for Webmin are also stored (somewhat confusingly) in /etc/webmin, rather than in /usr/local/sbin or in the Webmin home directory. Its logs are by default stored in /var/webmin/, rather than in /var/log/webmin/.

Webmin includes its own “miniature” webserver, so you don’t need to alter your Apache (or other web server) configuration to use it. The mini server is also a Perl script (/usr/local/webmin-0.78/miniserv.pl or something similar), which runs (owned by the root user) until the process is killed. This isn’t a terribly elegant solution, and it eats up about 3 MB of RAM as long as Webmin is running, but we’re assuming here that convenience is more of an issue here than absolute maximum performance.

If the idea of running a root-owned process over unencrypted HTTP scares you, you’re right. Webmin includes functionality to use Perl’s Net::SSLeay module to run its miniserver through HTTPS. If you don’t have this Perl module installed (and you’ll need to have the C libraries included with OpenSSL to get SSLeay to work), you’ll find download links and (relatively) helpful instructions for OpenSSL and SSLeay on the Webmin home page. Keep in mind, however, that setting SSLeay up can sometimes be, to use the technical term, a “major pain in the butt.”

Even better for security, you can also use Webmin’s interface to specify specific IP addresses from which Webmin can be accessed. This isn’t a foolproof setup, but it should be good enough for many system administrators.

Fun with Modules

Webmin’s interface is no-frills. It has very plain and simple graphics, loads quickly and gets the job done – a very wise choice, in my opinion. All functionality is provided in HTML tables instead of through a contrived graphical user interface.

As mentioned before, Webmin’s functionality is based on its included modules, each of which provides an interface to a specific service, application or daemon. The default installation includes all of the Webmin modules, which include such helpful items as MySQL, WU-FTPD, NFS, Apache, Users, Groups and Passwords, and a large number of other actions (for a complete list, see www.webmin.com/webmin/standard.html). Some default modules are OS-specific, like LinuxRAID, Linux Boot Loader and Network Configuration (for Linux and Solaris). Third-party modules which are available for Webmin (including ones for QMail, VNC and one which allows SSH logins in place of Webmin’s telnet tool) are available at www.webmin.com/webmin/third.html. There’s also a “wish list” of modules currently planned or under development at www.coastnet.com/~ken/webmin/wish.html.

Of course, having all of these modules available doesn’t mean that all of these services are available to you. Despite the fact that there’s a Samba Windows File Sharing module, for example, you’ll still need to manually download and install Samba on your machine before you can use Webmin to configure it. 

Each of the included modules is well written, and provides a wide range of functionality. For example, the Apache module allows you to set up or alter virtual hosts, set permissions, add or modify MIME types, change Apache’s process limits and more. Even better, the module-writing spec is open, allowing you to write your own modules if you have a good knowledge of Perl and the application or service that you’re writing your module for. 

One exception to this is the included Telnet Login module, which offers up a Java applet allowing you a telnet login through the web browser. This module is (surprise!) unfortunately dependent upon the Java Virtual Machine (JVM)/ Just-In-Time compiler (JIT) your browser is using, and can be unreliable in some cases. For example, it runs fine with the Apple JVM/JIT used by Netscape/MacOS, but is unusable with the Symantec JVM/JIT used by Microsoft Internet Explorer/MacOS. 

Overall, however, Webmin’s functions are well defined and easily accessible. If you are at all familiar with the service that you’re configuring, Webmin provides a simple point-and-click interface that absolves you from needing to remember file locations and command-line switches.

Fun with Configurability

Through the Webmin Configuration option on its index page, you can set up a variety of options, including Webmin logging, port/address for Webmin, and interface look and feel. Perhaps unsurprisingly, this is a significant improvement over command-line based programs which often leave no clues as to where their configuration files are. Also, most of these configuration options can be set manually via the command line in /etc/webmin/miniserv.conf.

Another handy feature if you’re using Webmin to administer a number of machines is its Webmin Servers Index function (available from your Webmin index page). Choose a central machine where you do most of your administration, and then fill out the forms to “register” the other servers you’re running Webmin on. Alternatively, you can set up a list of servers on one machine, then copy the files in /etc/webmin/servers/ from that server to all of your other servers and have those links automatically established. 

Every time thereafter that you click on the Servers Index button, you’ll be presented with a quick link to all of your other Webmin-enabled servers. You can specify a username and password to quickly log in to the other servers for convenience, or you can create a normal connection that will prompt you for a username and password for extra security.

An especially useful configuration option on the index page is Webmin Users. Through this, you can set up a variety of username/password logins for Webmin, and the modules that they’re allowed to access. This is particularly worthwhile if you want to set up one user for you (allowing access to all modules) and another user for your customer (only allowing access to modules for adding/removing users, Sendmail, Apache, etc.). With this setup, you can allow customers access to commonly used features but keep them from doing anything which might seriously “hose” their system. 

This isn’t a completely secure setup, however, since information about the modules that users can access is store in a plain text file as /etc/webmin/webmin.acl (usernames and passwords are stored in /etc/webmin/webmin.users), and a user with root access could easily change this.

You Can Lead a User to Man Pages, But You Can’t Make Them Think

Webmin provides a great deal of functionality in the modules it provides; but what it doesn’t provide is help in understanding them. This is almost certainly too much to ask from a free admin program, but it does limit Webmin’s usefulness in some ways (at least for users who are not already very familiar with Unix). For example, it can allow a user to enable or disable the chargen service or edit /etc/fstab, but it provides no information about what those things are, or why you might want (or might not!) want to change them. 

While a truly novice-friendly administration interface is too much to ask for, clickable keywords with glossary listings probably aren’t too much to ask for. The lack of documentation and help defeats one of Webmin’s primary benefits: the ability for a Unix novice to easily administer their system. While Webmin certainly aids new users by removing the burden of needing to know command-line options, it certainly won’t help them to configure Apache options if they don’t know what “Maximum requests per server process” means. Novice users are one of Webmin’s potentially largest markets, and it would be a shame if they didn’t provide explanatory text for their options in a future release version.

Still, this is a very forgivable gripe for a program which still isn’t even at release 1.0. What isn’t forgivable, however, is Webmin’s severe lack of documentation about itself, what it does, and how it does what it does. While this won’t deter the experienced system administrator, it limits how useful Webmin can be to administrators who would like an explanation of what they’re doing to their system, but don’t have the skills or knowledge to examine Webmin and its modules closely.

On the positive side, the Webmin site answers many frequently asked questions, and each built-in module also contains its own help information. A Webmin mailing list (frequently posted to by the authors) is also available; subscription information and a searchable archive are available from the Webmin home page. Even better, a Webmin Helpoption is always available from the index screen. Unfortunately, the help that is available appears to have been written as an afterthought, and the regexp searches that Webmin appears to do when you’re looking for help aren’t always very useful. 

The installation doesn’t even include a documentation directory or man page, and users are left to figure out for themselves how the system works and what goes on. Most of the information I managed to gather about Webmin’s internal workings was from reading the source for the installer shell script and the Perl code of the individual modules. If you’re like me (and I feel bad for you if you are), you will want lots of documentation about any third-party tool that runs as root.

Conclusions: Good, But Not Perfect

Is Webmin worth downloading, installing and trying? Absolutely – it offers excellent features, and the price (none) can’t be beat. Is it worth deploying for your technical support staff or customers? It depends on whether you’re willing to accept its limitations (and potential security or system integrity risks).

Nonetheless, Webmin has tremendous potential to provide a great web interface for Unix control. If your needs match its strengths and you aren’t too concerned about its weaknesses, then it’s something you should add to your administration arsenal right away. Even if it doesn’t meet your needs now, it certainly is a tool worth watching for the future.

By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

Dig through any Internet engineer’s “toolkit” of favorite utilities, and you’ll find (probably right under the empty pizza boxes) the traceroute program. Users have now joined the bandwagon, using traceroute to find out why they can’t get to site A or what link is killing their throughput to site B. 

Traceroute uses already-stored information in a packet header for queries on each part of the path to a specified host. With it, you can find out how you get to a site, why it’s failing or slow, and what might be causing the problem. Traceroute seems like a simple and perfect tool, but it can sometimes give misleading answers due to the complexities of Internet routing. While it should never be relied on to give the complete answer to any question about paths, peering or network problems, it is a very good place to start.

Traceroute, in its most basic form, allows you to print out a list of all the intermediate routers between two destinations on the Internet. It allows you to diagram a path through the network. More important to IP network administrators, however, is traceroute’s potential as a powerful tool for diagnosing breakdowns between your network and the outside world, or perhaps even within the network itself.

The Internet is vast and not all service providers are willing to talk to one another. As a result, your connection to your favorite web or FTP site is often grudgingly left to the hands (or fiber) of a middleman, perhaps your upstream, or a peer of theirs, or even more remote than that. When there is performance trouble or even a total failure in reaching that site, you might be left scratching your head, trying to determine who is at fault once you’ve determined it’s not a fault within your control.

The traceroute utility is a probe that will enable you to better determine where the breakdown begins on that path. Once you have some experience with the program, you’ll be able to see when performance trouble is likely a case of oversaturation of a network along the way, or that your target is simply hosted behind a chain of too many different providers. You will be able to see when your upstream has likely made a mistake routing your requests out to the world, and be able to place one call to their NOC; a call that would resolve the situation much more quickly than scratching your head and anxiously phoning your sales representative.

Performing a Traceroute

Initiating a traceroute is a very simple procedure  (although interpreting them is not). Traceroutes can be done from any Unix or Windows computer on which you have an account; MacOS users will need to download the shareware program IP Net Monitor, available from shareware sites or at There are also numerous traceroute gateways around the Internet which can be accessed via the web.

From a Unix shell account, you can usually just type traceroute at the prompt, followed by any of the Unix traceroute options, followed by the host or IP you’re attempting to trace to. If you receive a “command not found” message, it indicates either that traceroute isn’t installed on the computer (very unlikely), or it’s simply installed in a location which isn’t in your command path. To fix this, you may need to edit your path or specify the absolute location of the program – on many systems, it’s at /usr/sbin/traceroute or /sbin/traceroute.

Windows users with an active Internet connection can drop to a DOS prompt and type tracert followed by the hostname or IP address they want to trace to. With the Unix and DOS traceroute commands, you can use any of a number of command-line options to customize the report that the trace will give back to you. With web-based traceroute gateways, you may be able to specify which options you want, or a default set of options will be preselected

How it Works

As the Unix man page for traceroute says, “The Internet is a large and complex aggregation of network hardware, connected together by gateways. Tracking the route your packets follow (or finding the miscreant gateway that’s discarding your packets) can be difficult. Traceroute utilizes the IP protocol “time to live” field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.”

Traceroutes go from hop to hop, showing the path taken to site A from site B. Using the 8-bit TTL (“Time To Live”) in every packet header, traceroute tries to see the latency from each hop, printing the DNS reverse lookup as it goes (or showing the IP address if there is no name). 

Traceroute works by sending a UDP (User Datagram Protocol) packet to a high-numbered port (which would be unlikely to be in use by another service), with the TTL set to a low value (initially 1). This gets partway to the destination and then the TTL expires, which provokes (if all goes as planned) an ICMP_TIME_EXCEEDED message from the router at which the TTL expires. This signal is what traceroute listens for. 

After sending out a few of these (usually three) and seeing what returns, traceroute then sends out similar packets with a TTL of 2. These get two routers down the road before generating ICMP_TIME_EXCEEDED packets. The TTL is increased until either some maximum (typically 30) is reached, or it hits a snag and reports back an error.

The only mandatory parameter is the destination host name or IP number. The default probe datagram length is 38 bytes, but this may be increased by specifying a packet size (in bytes) after the destination host name.

What it Means

What traceroute tells you (assuming everything works) is how packets from you get to another specific destination, and how long they take to get there. Armed with a little knowledge about the way the Internet works, you can then make informed guesses about a number of things.

Getting There is Half the Fun

Let’s say that you’d like to know how traffic from my website is reaching the network of Sites On Line, a large online service. So, I run a traceroute to their network from my webserver.

traceroute to www.sol.com (127.188.146.18), 30 hops max, 40 byte packets

1  epsilon3.myisp.net (127.50.252.2)  1 ms  1 ms  1 ms

2  sc-mc-4-0-A-OC3.myisp.net (127.50.254.50)  1 ms  1 ms  1 ms

3  sol-hn-1-0-H-T3.myisp.net (127.50.254.58)  2 ms  2 ms  2 ms

4  gpopr-rre2-P2-2.sol.com (127.163.134.61)  2 ms  1 ms  2 ms

5  127.168.0.30 (127.168.0.30)  3 ms  3 ms  3 ms

6  www-dr4.rri.sol.com (127.188.128.254)  4 ms 7ms  8 ms

You can see from this example that your traffic passes through a router for my ISP, then passes through what is evidently an OC-3, before entering a line that (judging by the name) is evidently a DS-3 gateway between my ISP and SOL. From there, it enters the GigaPop of SOL, passes through a router which doesn’t have a reverse lookup (I see only its IP address), and eventually to one last router (clearly marked as leading to its webserver) at SOL.

Because of the way routing works, an ISP can really only control its inter-network traffic as far as choosing what to listen to from each peer or upstream, and then deciding which of those same contact points gets its outbound packets. So when you’re tracerouting from your network to another network, you’re getting a glimpse of how your neighbor network is announcing itself to the rest of the ‘Net. Because of the existence of this “asymmetric routing” in some circumstances, you should probably do two traces (one in each direction) between each two points you’re interested in.

Reading the T3 Leaves

While you can easily read the names that appear in the traceroute, interpreting them is a hazy enterprise. If you’ve got a pretty good feel for the topology of the Internet, the reverse lookups on your traceroute can (possibly) tell you a lot about the networks you’re passing through. Geographic details, line types and even bandwidth may be hinted at in the names – but hints are really all that one can expect. Since every large network names its routers and gateways differently, you can assume some things about them, but you can’t be sure. If you want to engage in router-spotting, note that common names may  reflect:

• locations (a mae in the name might indicate a MAE connection, or la might indicate Los Angeles)

• line type (atm may indicate an ATM circuit as opposed to a clear-channel line)

• bandwidth (T3 or 45 is generally a dead giveaway, for example)

• a gateway (sometimes flagged as gw) to a customer’s network (sometimes referred to as cust or something similar) 

• positions within the network (some lines may be named with core or border, or something similar)

• engineering senses of humor (as seen by the reference to Babylon 5 in my ISP’s network)

• The network whose router it is (almost always identifiable by the domain name; if the router doesn’t have a reverse lookup, you can perform a nslookup on an IP address to find out whose IP space it is in).

However, it should be reiterated here that amateur router-ology is a dangerous sport, since really the only people who understand a router’s name are the people that named it. So don’t get too upset when you think you’ve spotted someone routing your traffic through Nome, Alaska when it fact it was named by a Hobbit-obsessed engineer with bad spelling.

Some Clues About Connectivity

A prospective ISP, prospectiveisp.net, tells you that it is fully peered. Is there any way that you can check up on this? Well, yes and no.

Traceroute can tell you whether two networks communicate directly, or through a third party. First, you traceroute from a traceroute page behind hugeisp.net to a location within prospectiveisp.net.

traceroute to www.prospectiveisp.net (127.50.225.13), 30 hops max, 40 byte packets

1  s8-3.oakland-cr2.hugeisp.net (127.0.68.77)  12 ms  17 ms  8 ms

2  h2-0-0.paloalto-br1.hugeisp.net (127.0.1.61)  15 ms  32 ms  12 ms

3  sl-bb10-sj-9-0.intermediary.net (127.232.3.25)  30 ms  15 ms  13 ms

4  sl-gw11-dc-8-0-0.intermediary.net (127.232.7.198)  82 ms  103 ms  73 ms

5  sl-prospective-1-0-0-T3.intermediary.net (127.228.220.14)  77 ms  74 ms  73 ms

6  border1-fddi.charlottesville.prospectiveisp.net (127.152.42.1)  121 ms  76 ms  75 ms

7  ns.prospectiveisp.net (127.50.225.13)  80 ms  79 ms  94 ms

It is evident from this traceroute that hugeisp.net and prospectiveisp.net travel through a third party to reach each other. While this doesn’t say anything definite about their relationship, two networks will generally pass their traffic directly to each other about if they are peers (barring strange routing circumstances or other arrangements). This doesn’t paint a full picture (and you should confirm this with a trace from prospectiveisp to hugeisp), but it leads you not to think that prospectiveisp’s claims of full peering are true. 

Note that while traceroute can tell you whether two networks communicate directly or indirectly, it can’t tell you any more about their relationship. Even if any two networks do communicate directly, traceroute can’t tell me whether their relationship is provider-customer or NAP peering (except perhaps through whatever hazy clues you obtain from router names or by calling a psychic hotline and reading them my trace). 

In the above example, you might conclude that prospectiveisp buys transit or service from intermediary.net, which peers with (or buys service from) hugeisp.net. Of course, the opposite may be true – that prospectiveisp.net peers with intermediary.net, and hugeisp.net buys service from intermediary.net. However, common sense and a rough feel for the “pecking order” of first- and second-tier networks should guide your guesses here. 

Where’s the Traffic Jam?

Let’s say that you encounter some difficulty reaching the Somesite.Com website (you describe the site’s download speed as “glacial”), and decide to show off your newfound traceroute skills to investigate the cause of the problem. Here’s what you find:

traceroute to somesite.com (127.8.29.15), 30 hops max, 40 byte packets

1  epsilon3.yourisp.net (127.50.252.2)  1 ms  0 ms  1 ms

2  other-FDDI.yourisp.net (127.50.254.46)  2 ms  2 ms  2 ms

3  br2.tco1.huge.net (127.41.177.249)  6 ms  4 ms  22 ms

4  112.ATM2-0.XR2.HUGE.NET (127.188.160.94)  8 ms  28 ms  30 ms

5  192.ATM9-0-0.GW3.HUGE.NET (127.188.161.125)  8 ms  32 ms  28 ms

6  * * *

7  * somesite-gw.customer.HUGE.NET (127.130.32.234)  12 ms !A *

From this, you can guess (with a high degree of certainty) that the initial source of trouble is outside of our your ISP’s network and somewhere along the route used by the site’s carrier, huge.net. Hop six shows some type of trouble, with none of the three packets sent to that gateway returning. Notice the traceroute continues on to the next stop despite the failure at hop six. The problem there was also likely for the loss of two of the packets sent to hop seven. Thankfully, one managed to get back and indicated the trace was complete. 

Using the example above, you could ping the address reflected in hop seven and then compare it to a ping to, say, hop four or five, and see if loss of packets to hop seven versus hop five reflects what the traceroute indicated. 

Selected Traceroute Error Messages:

• !H Host Unreachable

This frequently happens when the site or server is down.

• !N Network Unreachable

This can be caused by networks being down, or routers unable to transmit known routes to a network.

• !P Protocol Unreachable

This only happens when a router fails to carry a protocol that is used in the packet, like IPX. 

• !S Source Route Failed

This can only happen if you are using the source route functions of traceroute, (i.e.) tracing from a remote site to another remote site. The site you are using source route tracing from must have source route tracing turned on, or it will not work.

• * TTL Time Exceeded

This is caused when the path back exceeds the TTL time limit, or the router sends a ICMP Time Exceeded message to site A.

• !TTL is <=1

This happens any time the TTL is changed, via RIP or some other protocol, to a new TTL.

Caveat Tracerouter

Before you make too many decisions based on the results of traceroutes, you should be very aware that tracerouting is a complex phenomenon, and that plenty of otherwise innocuous things can interfere with it. For example, it may be possible to ping a site, but not to traceroute to it. This is because many routers are capable of being set to drop time exceeded packets, but not echo reply packets.

Traceroutes may return an unknown host response, but this frequently does not mean that the sites are down, or the network connection in between is faulty. Some domains are simply not mapped to be used without a third-level domain as part of the name. For example, tracerouting to aol.com will not work; but tracing to www.aol.com will.

In short, tracerouting is a valuable tool, but does not give a complete picture of a network’s status. Try to use as many gauges of network status as possible when attempting to debug an Internet connection. 

Other Traceroute Resources:

http://boardwatch.internet.com/mag/96/dec/bwm38.html

A lengthy tutorial on Traceroute by Jack Rickard.

http://www.traceroute.org

Traceroute.org directory of Traceroute Gateways

http://www.tracert.com/cgi-bin/trace.pl

The Multiple Simultaneous Traceroute Gateway

http://boardwatch.internet.com/traceroute.html

Boardwatch’s own list of traceroute servers

http://nitrous.digex.net/

A handy site that allows you to trace from Digex’s network at MAE-East, MAE-West, Sprint NAP or PAIX.

http://www.sustworks.com/products/product_ipnm.html.

Home Page for the program IP Net Monitor for MacOS

By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

Many times, we are faced with difficult questions about installing, maintaining and running an Internet server with a Free Unix OS. And the best answer is, “take a nap.” That’s what I always do.

Anyway … the point is that anyone who tells you they know everything about running a Unix server is lying. The power and configurability of Unix leads to “complexity.” “Complexity” leads to there being “lots of information that you don’t know.” This leads to “needing to look stuff up.” Also, “fear” leads to “anger,” “anger” leads to “hate,” and “hate” leads to “suffering².” 

The first source for answers to any problems with your Freenix of choice is to be found in your man pages, and whatever handbook pages your OS or distribution provides. However, since these often tend to be big on abstractions and short on real-world examples, the web is often your best choice for clear answers to common problems. Since the amount of documentation available on the web is tremendous, in this column I’ll be focusing on free support resources; commercial support will be the topic of a future column.

The following is intended to be a very brief guide to the best free spots on the Web for information. The list is very incomplete; if you have a favorite Freenix resource site you don’t see here, please e-mail me.

Free Linux Support Resources

• Linux Documentation Project (www.linuxdoc.org): The LDP is one of the best things that the Linux community has going for it. The subjects sometimes tend toward the arcane and academic, but you’ll almost certainly find a HOTWO or FAQ guide for any program or service you want to set up for almost any Linux distribution. Its material isn’t always updated to cover the “latest and greatest,” but overall it’s an invaluable resource for how to do almost anything with Linux.

• Linux Distribution Support Sites: Most of the various Linux distributions provide support pages for their distributions. Helpfulness varies from distro to distro, but they generally provide good tips on distribution-specific issues. Among the most notable are Red Hat Linux (www.redhat.com/apps/support/), Linux Mandrake (English homepage at www.linux-mandrake.com/en/), SuSE (www.suse.com/Support/), Debian GNU/Linux (www.debian.org/support), Corel LinuxOS (linux.corel.com/products/linux_os/techsupport/support.htm), Caldera OpenLinux (support.calderasystems.com/caldera), Slackware (www.slackware.com/), LinuxPPC (www.linuxppc.org) and WinLinux 2000(www.winlinux.net/support.html). For a good list of English-language Linux distributions, go to www.linux.org/dist/english.html.

• Linux Journal Help Desk (www2.linuxjournal.com/cgi-bin/frames.pl/help/): The print magazine Linux Journal offers a high-quality collection of links to outside help resources. The links are updated well, and are a good first step to finding answers.

• Linux Fool (www.linuxfool.com): This site features a number of message/discussion boards on topics ranging from X windows to DNS configuration. Some of the forums contain far more questions than answers, but the site has a fairly high signal-to-noise ratio, and is an excellent way to get one-on-one answers. Linux Fool currently has few registered readers/posters as of this writing (about 1000), but hopefully this number will be higher by the time you read this (and a greater number of topics covered). 

• Fresh Meat (freshmeat.net): The number-one source for new software and updates. If you’re looking for the newest version of anything, you’ll find it here; more importantly, you can search for a description term (like “statistics”) and find software whose description matches. Not strictly useful for Q & A, but helpful as a launching point for homepages and resources of software packages you might be using.

• Gary’s Encyclopedia (members.aa.net/~swear/pedia/): This site is geared toward Linux, but also has some good information for any Unix user. The “pedia” features a few well-written original tutorials and literally hundreds of links, most of which are very well maintained, and many of the links feature comments about their specific subject or usefulness. Sadly, the page contains a note that as of January 2000, the links will not be actively maintained due to a lack of usage.

• Linux Developer’s Network (lindev.net): Updated several times daily, this site is an excellent source for information on new software packages (especially enterprise apps and code libraries). It also features links and tutorials, and while it doesn’t have the range of informative or thought-provoking reader comments that Slashdot (slashdot.org, the dean of Linux/open source news sites) does, it also doesn’t have the high noise-to-signal ratio.

• Linux Online Help Center (www.linux.org/help/): Hundreds of Linux support links. They aren’t as updated as they might be (when I looked at it, its links to the LDP still hadn’t been moved from the LDP’s old home at UNC), but there’s a lot of helpful material there that’s likely to at least point you in the right direction. The site lists its links with helpful comments, and can point you to resources you’re unlikely to find elsewhere.

• LinuxCare Support (www.linuxcare.com/support/): LinuxCare is a commercial Linux support company, but they maintain a free support database at this site. It’s well-organized, but doesn’t yet have too many answers, and requires you to sign up for free access before you can see the answers to any questions posted.

• LinPeople (www.linpeople.org/): This isn’t technically a web resource, but it can still be quite useful. The Linux Internet Support Cooperative is a groups of sysadmins who devote time to answering Linux questions on their IRC channel. Depending on the time of day, phase of the moon, and who else is logged on, the responses to your questions can range from thoroughly helpful to utter silence; still, one-on-one dialogue is often the best way to understand important Unix problems and concepts. Find LinPeople at irc.openprojects.net, channel #LinPeople.

• Linux Glossary Project (glossary.linux-support.net): The Linux Glossary provides a number of “user-friendly” basic definitions of important terms. It seems to borrow heavily from the Hacker Jargon File and other common sources, but can be useful if you’re looking for a down-to-earth definition of an unfamiliar term.

Free *BSD Support Resources

• FreeBSD Home (www.freebsd.org): FreeBSD’s website should probably be your first destination when looking for an answer. Most important is the documentation on the site, including the FreeBSD Resources for Newbies page (www.freebsd.org/projects/newbies.html), their (slightly outdated) FreeBSD Tutorials page (www.freebsd.org/tutorials/), and the FreeBSD FAQ (www.freebsd.org/FAQ/FAQ.html). Most important, however, is the FreeBSD Handbook (www.freebsd.org/handbook/), which can answer almost any common question you’ll have (note that a copy of the handbook should have been put in your /usr/share/doc directory when you installed the system). FreeBSD’s Support Page (www.freebsd.org/support.html) has a number of resources, including links to mailing lists and newsgroups, a list of regional user groups, links to the GNATS bug-reporting system, and lists of commercial FreeBSD consultants. 

• NetBSD Documentation (www.netbsd.org/Documentation/): NetBSD’s support site isn’t as in-depth as some others, but it’s an admirable effort, considering the number of platforms that it’s ported to. The documentation available is not as in-depth as for some other OSes, but it is very well organized (my personal documentation test is how quick you can find out how to boot into single-user mode). Overall, very helpful to NetBSD users, especially new sysadmins trying to find out how to perform normal tasks.

• OpenBSD Home (www.openbsd.org): OpenBSD’s site provides several high-quality resources for its users, including the OpenBSD FAQ (www.openbsd.org/faq/) a Manual Page Search feature (www.openbsd.org/cgi-bin/man.cgi) and a listing of OpenBSD Mailing Lists (www.openbsd.org/mail.html).

• Daemon News / “Help, I’ve Fallen” (www.daemonnews.org, www.daemonnews.org/[YYYYMM]/answerman.html): Daemon News is a monthly e-zine covering all sorts of cool *BSD-related topics, including descriptions of new software and “how-to” articles. If you run any BSD, it’s definitely worth a look every month or so. 

The “Help, I’ve Fallen” column is an absolute must for newer *BSD administrators. It might not cover your more “out there” questions, but a lot of common problems (from setting up modems to setting up printers) have a very understandable explanation here. Each column includes a listing of all of the previous questions answered, so it’s best to look at the most recent column first.

• Comprehensive Guide to FreeBSD (www.vmunix.com/fbsd-book/): Covers everything from installation (Chapter 2) to setting up PPP with FreeBSD (Chapter 8). Some of the material is outdated (referring to FreeBSD 2.x), but most of it is very applicable. It’s short on theoretical grounding and explanations, but very good for real world “quick-and-dirty” explanations on almost any problem to be found with FreeBSD, and much of the information can be applied to other BSDs.

• The FreeBSD Diary (www.freebsddiary.org/): The “diary” of a FreeBSD sysadmin, focusing heavily on links to topics regarding Internet servers (like Apache and e-mail). Not the easiest to search for answers, but featuring links to a lot of content you won’t find elsewhere (if you can find it here).

• FreeBSD “How-To”s for the Lazy and Hopeless (flag.blackened.net/freebsd/): Some of the links on this site are outdated, but most provide useful information. While this is long on step-by-step intros and short on explanations, it can provide links to quick info (on things from TCP Wrappers to PnP audio gear drivers) if that’s what you’re looking for. 

• FreeBSD Rocks! (www.freebsdrocks.com/): Not updated as frequently as some other sites, but still a good choice when you’re looking for FreeBSD news or support forums.

Free General Unix Support Resources

• Geocrawler (www.geocrawler.com/): Geocrawler is a repository of archives of more than a hundred mailing lists, on topics ranging from Linux distributions to *BSD to Apache, PHP and Perl. Each mailing list has a search interface, making the site an invaluable resource for those searching for new topics or those not well-documented in existing HOW-TOs or FAQs.

• Root Prompt (rootprompt.org/): Provides a number of informative articles and tips on various *nixes. Not much original content, but provides an excellent (and well-updated) collection of links to papers and FAQ/HOWTOs on everything from configuring Sendmail to recycling IP addresses.

• Unix Help for Users (www.geek-girl.com/Unixhelp/): This site provides basic Unix answers and questions. If a question seems to simple to be answered on one of the more platform-specific sites, it’s probably here.

• Unix Guru Universe (www.ugu.com): UGU provides a neat search interface with a number of links to outside information on almost any Unix you can think of. While it’s light on “in-house” material, it can find things in nooks and crannies that other sites don’t have.

In a future column, we’ll look at commercial support offerings online. Thanks for reading, and remember – if you’ve had half as much fun reading this as I’ve had writing it, I’ve had twice as much fun as you.

^[1] My sincerest apologies to anyone offended by this, but I just had to include a John Dvorak joke.

²  The Force for Dummies, Master Yoda, Jedi Press.

By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

If you aren’t familiar with the OpenBSD project (www.openbsd.org), it’s worth your time to find out about it. The core of OpenBSD’s mission is to provide the most secure Unix operating system available. For many ISPs, this is a very powerful consideration for protecting their customers’ data and their own – and one that can give them a competitive advantage among security-conscious customers.

OpenBSD offers a free variant of the BSD Unix operating system. It runs on a variety of platforms (from Intel x86 to Motorola M68k to Sun SPARC and several others). It has a number of native ports of popular software, and includes binary emulation options to run programs written for other operating systems including Solaris, Linux, FreeBSD, BSD/OS, SunOS and HP-UX. 

OpenBSD runs on a tight budget. The project is funded primarily by the sales of installation CD-ROMs, T-shirts and goodies, plus donations of money and equipment. OpenBSD has various commercial support options, and is available via anonymous FTP (www.openbsd.org/ftp.html) or on CD (www.openbsd.org/orders.html).

Answers from Louis Bertrand

Recently, I had a chance to interview Louis Bertrand (an OpenBSD developer, and the project’s unofficial PR guy) on the past and future of OpenBSD, as well as why ISPs might want to deploy it. Here’s what he had to say.

Question: What’s the short version of the history of the OpenBSD project?

Bertrand: Started in 1995 by Theo de Raadt, OpenBSD’s primary goal was to address the deplorable state of Unix and network security at the time. The cryptography angle was a natural outgrowth because it allowed the team to address security problems inherent in some protocols without breaking standards. The main effort was a comprehensive code audit, looking for the kind of sloppy coding practices that lead to buffer overrun attacks, races and other root hacks. Another goal was to release a BSD-derived OS with completely open access to the source code: OpenBSD was the first to let any and all users maintain their own copy of the source tree via anonymous CVS. We also kept the multi-platform aspects of BSD, subject to manpower – security comes first.

The OpenBSD source tree was created in October 1995, the first FTP-only release (2.0) happened in Fall ‘96, the first CD-ROM release (2.1) came out in Spring 1997, and CD-ROM releases have been coming out like clockwork every six months. 2.6 just came out Dec.1, 1999.

OpenBSD is derived from NetBSD (Theo de Raadt was a co-founder of that project). NetBSD is in turn derived from the Berkeley Computer Systems Research Group final releases of 4.4BSD-Lite.

Q: What does OpenBSD see as its niche or mission? Will that stay the same in the future?

Bertrand: OpenBSD is unique because of the security stance and the code audit, and the cryptography integration. There are no plans to change that focus. I mean, why should we? No other OS vendor (open source or commercial) is doing an active code audit, and nobody integrates encryption the way we do.

OpenBSD’s mission continues to be working proof that it is possible to offer a full-function OS that is also secure. The software industry and consumers (both commercial and open source) are locked into the “New! New! New!” mindset. Consequently, the accepted security stance is to back-patch whenever someone finds a problem. We completely reject that – ideally we’ll have corrected all the problems before they can be discovered and exploited by the bad guys. 

OpenBSD’s existence is also a constant reminder that the US government’s ban on exporting strong cryptographic software (it’s considered “munitions”) has become essentially futile. It is now easier to obtain strong encryption software outside the USA than inside. Being free software, we also completely avoid the restrictions of the Wassenaar Arrangement (UN-based arms export controls).

Q: Where does the project stand now (version, newest features added)?

Bertrand: The most important addition to 2.6 was OpenSSH, a free implementation of the SSH1 protocol (www.openssh.com). OpenSSH is integrated in OpenBSD 2.6. It’s an essential replacement for telnet and rsh for remote access where there is a danger of password sniffing over the wire. You can also use scp to transfer files instead of rcp or ftp. The last hurdle to complete crypto coverage in OpenBSD is the patent on RSA public key encryption, as used in SSL for SSH and secure web servers). OpenSSL is used everywhere

except the USA, where you can only use the RSAREF library, and then only for non-commercial applications.

Another big improvement in 2.6 was the huge effort to improve the documentation (both manual pages and web FAQ) and to make sure the information was up to date and correct. We’re trying to avoid the situation where people are dissatisfied with the main sources of information and start writing their own how-to documents – that only serves to fragment the sources of information, and users end up wasting a lot of time hunting around for reliable information.

Q: What’s coming up on the roadmap for the next major/minor versions? What new features? When might we expect to see them?

Bertrand: If all goes according to plan, there will be a release 2.7 in early summer 2000. There are no plans for a “major” release (e.g. 3.0).

Currently there’s a lot of work going on to integrate the KAME (www.kame.net) IPv6 networking code into OpenBSD (it’s already supported, but this actually integrates it into the source tree). There’s also a major rework of the “ports” tree, the facility by which people can download and build applications simply by doing make install in the target directory.

There is also some exploratory work going on for multi-processor support. Previously we flatly turned down the idea because it would be a huge effort that would only benefit a minority of users who are running SMP machines. But the recent drop in prices of SMP hardware means that it’s time to revisit that decision, and a few developers are interested in doing it. We still need to make sure we’re doing it right, not just heating up the second processor.

Q: What are OpenBSD’s weak spots right now, or what needs the most work?

Bertrand: The main criticism leveled at OpenBSD is that it doesn’t track the very latest standards. It’s a fair comment because we’ll often hold back on a new feature because of stability concerns. We held back APM (power management) support from the 2.5 release because it hadn’t been tested enough, and we still use named-4.9.7 for DNS because of security concerns, even though named-8 is in routine use elsewhere (there was a remote root hole found in bind-8.2.1 as recently as last November).

A lot of people have been asking for multi-processor support. Up to now, that was out of the question, but SMP hardware has been getting cheaper and several developers are interested in starting on it.

Also we don’t support the Macintosh PPC platform or the HP PA-RISC platforms. Again, there’s some work going on to change that. We’ve also dropped active support on Alpha because we were getting no support from Compaq. It still builds and runs, but we’re falling behind on hardware support.

Q: From an ISP/webhosting perspective, what specifically would you cite as reasons to choose OpenBSD?

Bertrand: Security and code correctness, along with the “secure by default” configuration. They all go hand in hand.

Start with the “secure by default” philosophy. It means that a sysadmin doesn’t have to rummage around dark corners shutting down risky or useless server daemons that the installation script enabled by default, or run around tightening up permissions. Sysadmins are very busy and we let them get their job done by enabling only those services and daemons they actually want and need. The default installation of OpenBSD has no remote root holes, and hasn’t had one for over two years.

Then there’s the security/correctness angle. The OpenBSD code audit discovered that if you fix the bugs, you have gone a long way to securing the system. In fact, it’s not necessary to prove that some buffer overflow would have caused a security hole – it’s enough to know that the software is now doing what it’s supposed to do, with no nasty side effects. That’s the kind of proactive measures that allowed OpenSSH to avoid the recent RSAREF vulnerability in SSH.

Finally (but not least), there’s the built-in cryptography. Whether you’re setting up an IPSec VPN between subnets across the Internet, or just running a modest client/server VPN with SSH and stunnel, OpenBSD has the built-in tools, maintained and tested for interoperability with commercial vendors. You don’t have to download, build, test and integrate your own cryptographic subsystems. No other OS ships with this level of integration.

Q: Can you point to any user base or constituency that OpenBSD is a “must-have” for? If so, why?

Bertrand: Any users who need to run intrusion detection, firewall or servers carrying sensitive information (e-commerce too!). For intrusion detection, there’s no point in trying to guard against malicious behavior on your network if the IDS system or firewall itself is vulnerable. For sensitive data, the built-in SSL makes it very easy to set up a secure web server. (Note, however, that the RSA patent restriction is still something US-based service providers must deal with).

Security is also a concern if you’re offering VPNs: any encryption scheme is worthless if the underlying OS is vulnerable (this is like an intruder bypassing a steel door by breaking a window).

Q: How vital do you see security as being to the future of the ‘Net and the future of OpenBSD? 

Bertrand: Extremely vital for both. I’d like to say concern for security is going to hit a threshold where more and more people are going to ask tough questions of their software vendors, ISPs and e-commerce outlets, but it’s probably wishful thinking. We’d like to see more than just “safety blanket” assurances from vendors.

One nasty trend is the growing full-time presence of powerful servers on end-user DSL and cable modems. This means there will be a fresh batch of compromise-able machines available for concerted attacks. If more vendors adopted a “secure by default” stance, that would go a long way to reducing the exposure of naive sysadmins.

Should You Use OpenBSD?

There are positives and negatives to OpenBSD’s focus on security. On the plus side, it’s the most secure free operating system you can get anywhere. If your number-one concern is making your server safe from intrusion, look no further than OpenBSD.

All Freenixes offer options for securing your system, but the fact that OpenBSD is secure “right out of the box” is a major advantage for the inexperienced administrator who isn’t sure how to secure a system, or the busy administrator who has the knowledge but not the time. A plain-vanilla installation of the OS will already include a number of security features that might take hours of installation and configuration (plus some considerable knowledge and research) with other Unixes.

On the negative side, OpenBSD’s security comes as a tradeoff for new gadgets and features – a tradeoff you may or may not be willing to make. Also, there’s a very true old saying that “security is inversely proportional to convenience.” And tight security can be very inconvenient. A lot of administrators (myself included) are used to saving time through leaving ourselves little insecurities (like rsh, allowing logins as root, or not using TCP-Wrappers for services like ftpd or telnetd). Conversely, many of the same busy or inexperienced administrators who find benefits in a “secure by default” installation may not have the time or the knowledge to then enable these insecure items if they want them.

And remember that you, the server administrator, can easily foil OpenBSD’s security precautions by doing something boneheaded, like installing third-party software with known security holes, or running your webserver as root. You yourself can make OpenBSD insecure by twiddling the knobs and switches if you don’t know what you’re doing.

Unless security is your primary consideration, you probably aren’t going to use OpenBSD for all of your Unix servers. Linux, FreeBSD and NetBSD all excel in various areas where OpenBSD does not. However, OpenBSD certainly has its place, and should be part of any network administrator’s toolkit. For your most security-sensitive tasks, OpenBSD is very likely to be “the right tool for the right job.”

By Jeffrey Carl

Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.

By the time you read this, I will be dead. Just kidding. By the time you read this, FreeBSD 4.0 should be out – or close to it. So, what’s the big deal? And why should you upgrade to it, or use it as a convenient excuse to switch to FreeBSD? 

The Short Version of the Story

A quick recap for the new students in class: FreeBSD is a free version of the BSD Unix operating system (and one which claims to have roughly 30 percent market share in the ISP space). BSD Unix is descended from the original AT&T Unix code currently maintained by SCO. When BSD grew up, moved out of the house for good and broke away from the dysfunctional Ma Bell family, FreeBSD emerged, originally dedicated to enhancing the performance of BSD servers on Intel-compatible (x86) hardware.

FreeBSD began a relatively rapid growth and adoption phase, at least inside the ISP/webhosting markets. FreeBSD’s developers concentrated on developing and optimizing for the hardware they were using – which was largely x86 servers, SCSI drives and other server-centric (rather than home-user centric) equipment. As a result, they developed (arguably) the highest public profile of any of the free BSD Unixes, building a list of users that included Yahoo!, the world’s busiest FTP server (ftp.cdrom.com), and Hotmail.

However, from seemingly out of nowhere, Linux exploded onto the scene and left all other free Unixes behind. Although BSD Unix had been around for years, as far as most of the world was concerned, Linux was it. 

By 1998, FreeBSD was at its lowest ebb. Linux – through its open development model and focus on end-user hardware – had long since become the free Unix for legions of old and new hackers worldwide. Linux advocacy was loud, assertive, got press attention – and as a result, Linux had stepped into the public limelight while the BSDs were Unix’s “crazy old aunt up in the attic.” Finding the old O’Reilly books on 4.4 BSD Unix – let alone finding a mention in the press of BSD – was harder than putting lipstick on a chicken. Fortunately, FreeBSD seemed to have learned something from the experience. 

The Fall and Rise of FreeBSD

Jordan Hubbard works for Walnut Creek CD-ROM (think ftp.cdrom.com), which sells FreeBSD, Linux and other open-source distributions. He’s also the Current Release Engineer for FreeBSD, and its unofficial PR guy. Known as “jkh” by legions of FreeBSD devotees, he’s also responsible for /stand/sysinstall and other user-interface niceties of FreeBSD, as well as legions of other internal enhancements.

In his 1999 FreeBSD “State of the Union” address, Hubbard indicated – like Steve Jobs before him – that he understood that technical superiority of an operating system alone did not guarantee its success – it took PR and user help. He said that FreeBSD’s upgrades would henceforth come in tenth decimals, rather than hundreds, so that the public and press would take more notice. Furthermore, he actively called on FreeBSD users to advocate for their OS. 

The FreeBSD core team had fortunately learned from the divisive standards wars that Unix had undergone (and they had been a part of). FreeBSD would work with Linux rather than against it. Recognizing Linux as a sort of de facto API for free Unix applications, FreeBSD would include compatibility for Linux, rather than insist on developers writing their applications for one OS or the other. Smart move.

Since that time, FreeBSD has enjoyed a significant growth in popular support, has been the subject of articles in MSNBC and Salon, the subject of a special section on Slashdot, and has experienced a surge in downloads. Darwin, the open-source base of Apple’s forthcoming MacOS X, will have its future releases tied to FreeBSD. Even better, FreeBSD now has its own yearly tradeshow – FreeBSDcon, showing strong signs of the growth in its support.

I ran into Jordan Hubbard at ISPCON, when I stopped by the FreeBSD booth to see if anyone could tell me whether one of the core team members would be at the conference for me to interview. There was Hubbard. The result was much like going to CompUSA to buy a copy of Slackware and finding Linus Torvalds in a red shirt, explaining it was in aisle six. I fumbled and stuttered that I needed to go grab my iBook laptop, and I’d come back and interview him, and P.S. I thought he was so cool. He turned to my friend Namita who came with me and asked, “Is he always this smooth?” Anyway, this interview is the result of that meeting and a couple of E-mail follow-ups:

Q & A with Jordan Hubbard

Question: When can we expect to see FreeBSD 4.0?

Hubbard: Sometime in the January – February timeframe. We’ll enter feature freeze for the 4.0 branch on December 15th, after which we’ll take about 30 days to stabilize the branch.

What are the new architectures that FreeBSD will be coming to?

Hubbard: Well, we’re working on several fronts. First, we’re working with Compaq right now on Alpha SMP (Symmetric Multi-Processing, or multiple CPUs) support (for which Compaq has kindly sent us almost $300K worth of miscellaneous hardware) and hope to have something working there by Q1 2000. We’ve also started a PowerPC port with the Power Macintosh G3 being our initial reference platform, but there are no firm dates on when that will be available. If all goes well, we should also see some significant work on the UltraSPARC port coming into the tree around the same time (Q1 2000).

Does branching out to more architectures mean you’re changing your focus? Does this mean anything to the speed or quality of x86 development?

Hubbard: We’re not really changing our focus so much as simply leveraging the much more significant developer assets we now have available, many of whom want to work on non-x86 platforms, so why not let them? I also don’t expect this to affect the x86 development work in any way since the lion’s share of our developers will still be working on that platform and we have enough extra people now that we can do both. 

The only reason we’ve focused exclusively on the x86 platform to date is that we didn’t feel we had the resources to do a really good job there AND also tackle other architectures. However, we’re at least three times the size we were when we made that initial determination. I think it’s now more than possible for us to do a good job on at least four major architectures, especially since such work tends to “amortize” due to similarities in those various platforms. For example, the PCI bus is an increasingly common interface standard, and just about everyone offers USB.

I think going cross-platform is simply an inevitable aspect of our evolution and the Alpha port has allowed us stay more “honest” with respect to FreeBSD’s architectural dependencies.

How important do you see ISPs/webhosters/etc. as a constituency? What are you working on adding/improving that might be of special interest to them or might constitute a reason (aside from the already-existing reasons) for ISPs to use FreeBSD?

Hubbard: We see ISPs, NSPs and the SOHO market as very important parts of our constituency and we intend to work on a number of issues which will make FreeBSD more attractive to them. In no particular order those are:

• Pervasive multi-threading (in the kernel)

• Fine-grained SMP resource locking

• Clustering (on a variety of fronts)

• RAID controllers and other large-scale data storage systems

• Embedded systems support (more picoBSD work)

• Serious security auditing and more built-in security subsystems (K5, IPSec, openSSH, etc).

• Fiber channel support

• Gigabit (and faster) networking (already works, but we’ll be also working on zero-copy TCP and other performance features)

• IPv6 and IPSec (both slated for 4.0).

• Better multimedia support (3D cards, audio, video capture, etc).

We’re also working with a number of vendors, like Oracle, to bring their products to the FreeBSD market and are getting far more support for this than we used to. Things are definitely looking up in that category and we hope to have some significant announcements by the end of the month.

How would you define the mission of FreeBSD now?

Hubbard: I’d say it’s much the same as it always was: Provide robust, high-performance BSD technology in a form which is accessible to the “mass market” by being easy to install and configure and by offering better documentation. It has never been our intention to be just another academic resource, BSD’s traditional niche, we want to give Solaris, NT and Linux a run for their money (in that order).

What advancements in ease-of-administration will people see in 4.0? What about directions for the future?

Hubbard: More easy to turn knobs in places like /etc/rc.conf and more tools for manipulating those knobs in a friendly fashion, to put it in a nutshell. Future directions include making kernels truly GENERIC, in that you don’t have to configure your own any more; you just have one kernel, which dynamically extends itself as necessary. It will still be possible to configure and run static non-self-extending kernels if necessary for security or other reasons, but this shouldn’t be necessary for the average user. We’re also putting more time into configuration interfaces and fancier GUI front-ends for those things, which make clear sense to give the user a “friendlier face” on.

When might FreeBSD’s planned new threads architecture (the proposed mix of kernel-level and user-level threads I’ve read a bit about in freebsd-arch) make its way into stable? What benefits will ISP/server users see?

Hubbard: …4.0 is our current target for the new threads feature set. ISPs should see the ability to multi-thread applications like mysql in such a way that a single process can take advantage of multiple CPUs, unlike the one process per CPU model we have now, and we’ll have more POSIX compliant thread behavior for people porting applications from other platforms.

In Conclusion

Jordan Hubbard indicated that FreeBSD might soon be giving OpenBSD a run for its money as the “secure” BSD. Hubbard also alluded to – but wouldn’t give any specifics on – a potential “big name” player offering commercial support for FreeBSD. By the time you read this, this name may have come to light; if not, we’ll just have to wait and see. However, it appears that FreeBSD is very much on an upswing right now.

Is FreeBSD 4 a “Must-Upgrade?” Probably not right away, since its advances are evolutionary rather than quantum. Nonetheless, if you’re using FreeBSD now, you’ll want to upgrade soon; if the new features and improvements aren’t enough, you’ll want to consider that bug and security fixes always come fastest for the most recent version. 

Having watched the rise, fall and rebirth of Apple, I think I know an OS in resurgence when I see one. And FreeBSD is definitely on the track to resurgence. It will be a very long, hard road – but I think that all of us who are looking for a free Unix with optimum performance and usability will benefit.