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.

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.

Do you ever run across something that’s just so neat that you run around telling all your friends how they have to try it and how it’s the greatest thing since Mountain Dew? And eventually your friends get tired of it and want to hit you in the head with a crowbar?

Well, neither do I. Mainly because I don’t have any friends. But if I did, I’d be running around bugging them about VNC (Virtual Network Computing, www.uk.research.att.com/vnc). So, since I don’t have any friends, I’m going to bug you about how you can have a free graphical remote-control for your Freenix machine (through XFree86) from any other Unix, Windows, MacOS  – or almost any other platform, including PalmOS – computer. Even better, you can control your Unix, Windows or Mac computer from your Freenix machine. It’s like X windows, Symantec PCanywhere and Apple Remote Access all rolled into one. 

VNC is a client/server program from the good folks at AT&T Labs in Cambridge, UK. VNC has two components: a server program and a viewer. Install the server on any supported OS, and you can use the viewer to control that computer in a graphical window. VNC is released under the GPL (GNU Public License), so the source code is freely available along with the binaries. 

So, what does this mean to you? If you’re accustomed to administering your Freenix through an X windows environment (like AfterStep, Enlightenment or KDE), VNC allows you a completely portable, free and easy-to-use way to do this from virtually any other computer, no matter what OS it’s running. In addition, this one app allows you to manage your consumer-OS workstations from your servers as well. On multi-user systems, VNC can be run for specific users and reflect their particular environments.

Why Choose VNC?

Some of you may be saying, “On Unix, this utilizes X windows. So, why is this better than running X windows sessions remotely?” Well, you should get professional help, since you’re talking to a magazine. But the answer is that VNC has three notable advantages over traditional remote X administration. 

First, the session state is stored on the server rather than on the client machine. This means that I can leave my VNC session at work in the middle of typing a line, go home and fire up a VNC viewer on my home PC, and pick things back up in the middle of the line. While this may not sound ground-breaking, it’s very useful if you need to administer a single server from multiple clients.

Second is the amazing variety of ports of the VNC viewer (see “VNC Platforms,” below). Plus, there’s a Java version, so VNC should be able to be run through a web browser on any platform for which a standards-compliant Java Virtual Machine (JVM) exists. The side benefit from this is standardization: you can install VNC across your network, train your staff on VNC and then let them administer Unix, Windows NT and MacOS servers using the same program, from almost any computer.

Third, it’s a lot easier to configure and run than free X clients generally are. Anyone with the brains to breathe on a regular basis and use their turn signals correctly should be able to get the VNC server up and running within five to 15 minutes, and the VNC viewer in less than that. Of course, if you want your Freenix sessions to run nicely, you’ll have to do a bit of tweaking to your preferences file (like changing the default window manager from the antiquated twm to something more useful). The more you know about X windows, the better; but it’s still usable even if you don’t.

VNC also performs remarkably well, considering that it’s a free, non-commercial product. On Unix machines, I found its performance to be as good as traditional remote X windows sessions. Performance on Windows machines were, in my extremely unscientific tests (I didn’t get around to testing the Windows version until after my third or fourth Heineken), about the same as I had experienced with PCanywhere. I didn’t see any “dancing Bill Gates” while I used PCanywhere, but I’m attributing this to the Heinekens. 

How Do I Install and Run It?

Installing VNC on your Freenix is as simple as following John Dvorak’s delicious Pickled Walnuts recipe (remember: soak in brine for at least six days!). The VNC server for Unix is a Perl script that utilizes XFree86. An XFree86 installation is usually pretty painless on most Freenix flavors; if you don’t have Perl installed, double-check yourself to see if you have a working brain installed in your skull (see “Windows NT”).

On FreeBSD, VNC is part of the ports collection, so installation is fast and easy. Simply cd /usr/ports/net/vnc, type make install, and you’re on your way. One of the beauties of the ports install is that it will also install necessary X components if you need them.

For Linux, .tar or .tgz archives of the binaries are available (note: newer versions require glibc, which you’re probably already using anyway). Simply use gunzip and/or tar –xvf to upack them, and you’re ready to go; if you aren’t planning on keeping VNC to yourself, you’ll want to move the new directory of VNC files under /usr/X11R6/bin. If you’re fond of using (ugh) RedHat Package Manager or Debian packages for one-click installation, those are available as well from rufus.w3.org/linux/RPM and www.debian.org, respectively.

The program’s important binaries (vncserver, vncviewer and vncpasswd) are normally installed in /usr/X11R6/bin. To start a server, simply issue the vncserver command (assuming that the directory that it’s installed in is in your $PATH), or type the full path to the command. The first time that you run it, you’ll be prompted to choose a password, which will be stored in your user’s $HOME/.vnc/ directory that will be created for your session logs, password and preference files. Later, you can use the vncpasswd program to change your password if necessary. Your X/VNC session preferences are stored in the xstartup script located in this directory, as well; this file can usually be changed to be a link to your normal X startup script.

With Windows, although external programs like X and Perl aren’t required, things are a bit more complicated. Downloading, unzipping and installing the client and server files for Windows 9x are pretty simple. Unfortunately, under WinNT (NT 4.0 Service Pack 3 or higher required), there are certain important functions (like the ever-important remote CTRL-ALT-DELETE and remote unlocking) that can only be accomplished if you’re running VNC as a service. See the VNC FAQ (www.uk.research.att.com/vnc/faq.html) or a deck of Tarot cards for more information.

On MacOS computers, to run the server, drag the associated Extension and Control Panel into your active System Folder, then restart and double-click the server application (place an alias of the server app in your System Folder/Startup Items folder to run automatically). 

To start a VNC client session, run the vncviewer program (or whatever it’s called on your OS), choose a hostname and session number. The first session you start on hostname foo.bar.com is designated 0, and the next one is designated 1, et cetera. So, to connect to the second VNC server started by a user on that host, you’d connect to foo.bar.com:1.

So, What’s The Catch?

While VNC’s performance is very good, any remote-GUI solution is not going to provide performance equal to a console connection. Of course, the faster and cleaner your network connection is, the better your results will be. 

However, an equal consideration is the video card you have on the client machine – 2 MB or 4 MB video cards with older chipsets probably aren’t going to get you far. Souped-up video cards will significantly improve performance (hint: use this as an excuse to buy a 16 MB Riva TNT2 card for your Linux machine and then play Quake on it). Changing your X, Win or Mac desktop pattern to a single uniform color or shifting down your default color depth (e.g., 24-bit color to 16 or 8 bits) will also help significantly.

Over a 10 Base-T LAN connection, performance for both the client and server on the Freenix versions was good for common tasks (virtually indistinguishable from console access with terminal sessions and X-based admin tools, plus a few simple games and amusements). Over a 56 kbps modem connection, it worked fine for terminal sessions and very light graphical stuff – but even xsnow had some frameskips, so you’re probably still better off with traditional terminal access under most circumstances if you have to use a modem-speed connection.

While the performance of the VNC viewer is excellent for nearly any platform, the server performance is inherently slower with Windows or Mac (since source code for these platforms isn’t open like XFree86 is). 

With Windows 9x/NT, performance is fine but not as fast as the Unix versions, so you may be better off running VNC on Windows machines to control your Unix machines than vice versa. There are some things you can do to increase the performance of the WinVNC server; see the www.uk.research.att.com/vnc/faq.html page for more details. The MacOS version of the server was abysmally slow, although the viewer worked just fine. The MacOS server also proved to be incompatible with MacOS 9, so this may be responsible for the slowness. A superior version of the Mac viewer (which makes use of enhancements for MacOS 8.5 and above) is available at www.webthing.net/gpl/.

If you’re concerned about security (and you should be), adding any services to a machine is an issue. If you’d like, you can use VNC Unix server with TCP Wrappers to restrict VNC port access to specified hosts.

VNC requires simple password challenge-response authentication (only the first eight characters are significant on all platforms, syncing with the Unix version). However, you can use VNC over SSH (providing some compression as well as encrypting all traffic so it can’t be “sniffed”) – more info is available at www.uk.research.att.com/vnc/sshvnc.html. It should be noted that “sniffing” even an unencrypted VNC session would be significantly more difficult than sniffing something like a telnet session, since 1.) the data is compressed (albeit using an open-source method), and 2.) there’s a whole lot of graphical garbage in the data stream. 

By default, the VNC server executable can be run by non-privileged users. VNC opens the first session on port 5900 (port 5800 for HTTP connections) and increments additional sessions on the next available port up. If you’re worried about unsanctioned users running it, you may wish to make vncserver root-owned with 700 permissions, or prohibit non-privileged users from opening up new sockets above 1024. 

VNC Platforms

Platforms aside from those discussed above which have servers include AIX, BSD/OS, HP/UX, LinuxPPC (Linux for Power Macintoshes), Linux/SPARC, NetBSD, NetWinder (Linux for ARM), OSF (DEC Alpha), SGI Irix, SCO OpenServer, and SunOS (by the way: why are you still running SunOS?).

VNC Viewers are available (with varying degrees of updatedness) for the abovementioned OSes, as well as Acorn RISC OS, Amiga, BeOS, CygWin32, MS-DOS (by the way: why are you still using MS-DOS?), Geos/Nokia 9000, OpenStep, OS/2, PalmPilot, VMS, Windows CE and Windows NT/Alpha. There’s also a version that integrates nicely with KDE on Linux for x86. For more information on both server and viewer platforms, see www.uk.research.att.com/vnc/platforms.html.

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.

Hi there, and welcome back to the only column in Boardwatch  read even less frequently than the lame Lucent ads. This month, we’ll be taking a look at common tasks for many system administrators, and whether doing them with a Free Unix (Linux or any of the various free BSDs) will make you pull out your hair and insert your foot in the disk drive instead of a system disk.

Freenixes and Ease of Use

Recently, we’ve looked at why you might want to switch to a Freenix instead of a commercial OS like Solaris (“We’re the dot in $6,000.00”) or Windows NT Server (“The best Solitaire $2500 can buy!”). But the fact remains that an operating system isn’t really “free” if you need to include the costs of divorce and therapy in it. So, can a non-Unix-guru easily accomplish the tasks with a Freenix that he or she is accustomed to doing on a commercial OS?

There are two main ease-of-use problems you’ll face with a Freenix. First is that there’s no such thing as a Unix Server for Dummies. All Unixes are – by design – operating systems by people who know what they’re doing, for people who know what they’re doing. (By way of comparison, Windows 98 and MacOS are operating systems by people who usually know what they’re doing, for people who don’t even want to know what they’re doing. Windows NT is an operating system by people who like stock options, for people who like certification classes.) You’re probably never going to be in full command of a Freenix system until you’ve taken the time to read through a stack of “O’Reilly” books and really learn your OS. This is true of any server OS; it’s just a lot harder to “fake it” with Unix. 

Second is an element that sounds obvious but shouldn’t be discounted: there’s no tech support number to call. Unless you’re willing to pay LinuxCare or one of the other Linux or OpenBSD commercial support companies, you’re stuck with books, online manual pages and documentation, and the support of your fellow Freenix users. Books and documentation cover a lot of your questions, but you’ll still run into plenty of problems where the only real solution is to ask someone who has had the same problem before. Ninety-nine percent of the problems new users will encounter can be handled by the tried-and-true RTFM (“Read The F***ing Manual”) method; but you will inevitably encounter a technical dead end where your best bet is to pray that someone responds to your newsgroup or mailing list post quickly. 

A few caveats need to be given for these ratings. I’m assuming that you’re using the most common free tools here (Apache, Sendmail, etc.); using third-party applications may be significantly different (and probably easier). Also, I’m assuming that you’re willing to get your hands dirty a little with command-line administration and aren’t relying entirely on point-and-click options. So, with that being said, let’s take a look at a few common administrative tasks, the flexibility of configuration options that Freenixes provide, and their ease of use:

Networking Setup

Flexibility: Immense.

Ease for Enough-To-Get-By Administration: Very easy.

Ease for Advanced Administration: Ranges from breezy to baffling.

The greatest virtue of all Freenixes is that, for everything that you want to do, somebody else has already wanted to do that same thing. And, usually, they’ve been a Computer Science student or professor, a communist, or someone else dumb enough to write a program to do it and give it away for free. Therefore, the vast majority of common sysadmin tasks on a Freenix already have a tool to set things up and save you work.

Most Freenixes provide a networking setup tool during their installer process that allows you to set up basic (Ethernet or PPP) network connectivity with only a few pieces of information. Even for some more advanced tasks, Linux tools (like linuxconf in its command-line or GUI versions) or FreeBSD’s /stand/sysinstall program give you simple options for configuring normally arcane tasks. You can generally turn your machine into an ersatz router by running RouteD or GateD, share NFS drives or enable ISDN, ATM or other interfaces with a couple of minutes’ work. These easy-admin programs are (as all Freenix GUI/semi-GUI tools are) just tools for modifying the text configuration files hidden somewhere else on the server (e.g., /etc/rc.network, etc.) that do the actual work. If you’re willing to take a shot at editing the actual text configuration files, your options increase. 

However, be warned that certain advanced or uncommon tasks are going to require not only hunting down the requisite files but also knowing about how networking actually works on an interface and packet level. Nonetheless, the majority of us who don’t have a “seven-layer OSI model” tattoo can still get the job done using the available tools.

User Administration

Flexibility: So-so.

Ease for Enough-To-Get-By Administration: Very easy.

Ease for Advanced Administration: Nothing you can’t handle.

It should be noted that the Unix system security model defines the amount of user account configuration you can do. Unlike Windows NT, you aren’t able to specify “semi-privileged” accounts; practically speaking, you’re root or you’re nobody. (A little joke there. Very little.) However, if you’re willing to get wise in the ways of the Unix permission structure (each file or directory has settings for the permissions allowed to the owner/creator of the file, other users in the owner’s group, and all other users on the system), you can replicate much of this functionality through selectively adding users to specific groups.

For ease-of-administration, Linux leads the way here, providing GUI tools for nearly all window managers that allow you to create and delete users, set disk space quotas, define user meta information and shell info. (These tools are also available for the *BSDs, but they are native to Linux.) Overall, you’ll find simple user administration tasks (as mentioned above) to be quite simple and easily done through either a GUI tool or the command line. Advanced tasks (like putting the user in a chroot-ed environment, or limiting their access to certain methods) are less simple, but still pretty easily accomplished.

FTP Server

Flexibility: How flexible were you expecting FTP to be?

Ease for Enough-To-Get-By Administration: Super easy.

Ease for Advanced Administration: Nothing a few Unix man pages can’t fix.

If what you’re looking for is to allow users to FTP their files to and from their accounts, this is a no-brainer: it’s already set up by default in the *BSDs and most Linux distributions. Likewise, allowing anonymous FTP (even for specific users or directories) is a very simple task – albeit one handled through a command-line interface with a text editor. 

Even better, there are plenty of free FTP Daemons (servers) which give even more advanced features than the default FTPD provided with most Freenixes. FTP isn’t exactly a terribly option-heavy service, and nearly all of your needs can be easily dealt with. Note, however, that advanced issues (like denying FTP to specific users or hosts) aren’t immediately obvious, and may take a bit more work with your /etc/hosts.allow or ftpd config file.

Web Server

Flexibility: Like a gymnastics instructor.

Ease for Enough-To-Get-By Administration: Easy.

Ease for Advanced Administration: No worse than doing your taxes.

Apache (so named because it was “a patchy” upgrade to the original free NCSA webserver) is by far the most popular webserver for Freenixes, and with good reason. It’s stable, it’s almost ridiculously extensible, and it has excellent performance. 

While fairly rudimentary GUI tools exist (again, native to Linux) for Apache configuration, the command line is the way to go. The good news is that the Apache team has gone to great lengths to make this as painless as possible. There are plenty of great books out there on not only configuring Apache, but also on tweaking it for performance as well. With the newest versions of Apache (1.3.4 and greater), all configuration options have by default moved to a single file, the httpd.conf file, located in /etc/httpd/, /usr/local/apache/etc/, or some other directory depending on your OS, your version of Apache, the phase of the moon and a random 32-bit number). 

The default httpd.conf file is extremely well documented, and includes either explanations or examples (or both) for every configuration directive in the file. The great part is that most options are relatively self-explanatory, and by editing this one file you can easily set up everything from CGI execution and file icons to virtual hosts.  

Performance tuning is where things can sometimes get tricky. Most of the GUI/semi-GUI tools (as mentioned above) available will carry the heavy lifting for you – including kernel modifications and other items. However, getting the most out of your webserver may require you to recompile Apache with or without some of its default modules. Nonetheless, Apache is nothing if not exhaustively documented in books and at its website (www.apache.org), and things are at worst frustrating rather than impossible.

Mail Server

Flexibility: Ridiculously flexible.

Ease for Enough-To-Get-By Administration: Fairly easy.

Ease for Advanced Administration: You’d better have some “Advil” handy.

Sendmail is the most powerful and configurable mail server out there (especially for free). The default configuration installed with nearly all Freenixes is all that 99 percent of Sendmail users (like you and me) will ever need. Thank God, because we’d be shooting ourselves left and right if we ever needed to seriously configure the damn thing.

Simple mailserver elements like POP3 accounts are built in by default. E-mail aliases and redirection are easily accomplished with an absolute minimum of configuration (through the /etc/aliases and /etc/mail/virtusertable.db files). In recent versions of Sendmail, anti-spam relaying measures are included by default, and these can easily be circumvented if needed by adding mail-sending domains to the /etc/mail/relay-domains file. 

With that being said, God help you if you ever need to do some serious digging in the Sendmail configuration (/etc/sendmail.cf) file. Sendmail’s primary configuration file is written in something that looks like a cross between C code and Swedish, or maybe both. I was looking through that file and somewhere around line 4000 I actually found a bunch of John Dvorak’s delicious recipes. Sendmail is probably the archetypal example of Unix’s configurability and inscrutability at its best and worst.

For other common mail tasks, there are plenty of common free tools out there. The free pine 4.10 package offers not only the easiest Unix mail reader out there, but an excellent IMAP server (and text editor, with pico) as well. The free majordomo 1.94.4 package provides excellent mailing list options – although at a performance price, since it’s written in Perl and tends to eat up a lot of RAM when it’s running.

The Moral of the Story

Freenixes can save you thousands of dollars if you’re willing to pay a few hundred dollars for technical books and learn how to use them (the Freenixes, not the books). For common ISP sysadmin tasks, 90 to 95 percent of your work can be easily done on an OS with friendly tools and frequent updates. If you’re brave enough to handle any Unix, you’re brave enough to handle a Freenix. However, if you’re a point-and-click addict, or need something with an unhelpful tech support phone line, a Freenix won’t be for you.

By Jeffrey Carl

This was my first “UNIX Flavor Country” column for Boardwatch Magazine. My first article had gone over so well – in that it filled up two full pages, did not provoke an angry letters and cost the magazine $100 – that my friend Greg Tally offered me a full-time columnist gig. These, as they say, were the salad days. People even thought Pets.com was a good idea back then, seriously.

If your ISP doesn’t use Unix, it should. Many of the various flavors of Unix provide excellent solutions for everything from webhosting to dialup authentication to networking to powerful workstations. Even better, some of the Unixes (the so-called “Freenixes”) are free to use, are available on cheap hardware, and come with powerful free software suites (like Apache, Sendmail and others) that match or beat the performance of commercial software costing thousands of dollars. Plus – let’s face it – there’s an undeniable “sysadmin badass” appeal that comes from telling people you’re a Unix wizard that you simply don’t get by telling people you’re “a real guru with AppleTalk.”

However, even among Freenixes, there are many to choose from. And, if you’re a new user or even an experienced administrator looking to taste other flavors, it’s difficult to get good advice on which kinds to choose. Most people who already use Unix are very devoted to their flavor of choice, and it’s tough to get unbiased advice from someone with a lifetime subscription to “BSD Jihad” or a tattoo of a heart with a little “Kernel 2.0.36” inside it. 

So, for the next few months, we’ll look at what the strengths and weaknesses of each Freenix flavor are, and which may be right for you. To understand how and why each Freenix does what it does, it’s important to have a knowledge of where they (and Unix itself) come from – and that’s the focus of this month’s column.

Normally, histories of Unix are dull enough that they are used only in scientific experiments to anesthetize lab rats at a distance of 50 yards. In the interest of bringing everyone up to speed, the following is a completely irresponsible, glibly assertive and overly sarcastic yet theoretically amusing brief history of Unix up to the past few years.

IN THE BEGINNING

Many millions of years ago, after the Earth cooled (roughly 1969), there was Unix. And it was good. Ken Thompson and Dennis Ritchie of Bell Labs found the legendary “little-used PDP-7 in a corner” and set to work on creating a new operating system for internal use at AT&T. Originally called “Unics” (UNiplexed Information and Computing System) as a pun on the earlier OS project “Multics” (Ha ha! Programmer humor!), its development was confined for several years to a small group of ultra-geek programmers within Bell Labs. 

A fundamental step for Unix came in 1973 with Version 4, which had been rewritten from platform-dependent assembler code into the new C language (also a creation of Bell Labs). By writing the core of the OS in a high-level programming language, it now essentially meant that Unix could be ported to almost any platform which included a C compiler. Since that time, Unix and C have gone hand-in-hand like deer ticks and Lyme disease.

TRIUMPH OF THE NERDS

Version 6 of Unix in 1975 was released to the outside world in “unsupported” (“Don’t blame us if it hoses your CPU and makes it cough blood”) format. It had two different licenses for the OS/source package: a university license for $100 and an “everybody else” license for $20,000. As a result, a generation of Computer Science students grew up on hacking Unix and improving it (most notably at MIT, Carnegie-Mellon and the University of California-Berkeley). While the “other” price tag sounds hefty, it was a small price for large companies to be able to take an existing OS and build their own around it. This eventually attracted numerous vendors to base an OS on Unix – including Sun, SGI, DEC, HP, IBM, NeXT and even Apple (anyone out there remember A/UX?). Unix grew rapidly in the mainframe world of the ‘70s and ‘80s because it was relatively cheap, and small armies of new computer science graduates entered the workforce already familiar with it.

The early development of Unix defined the characteristics it carries to this day. Every OS is a compromise of sorts between two fundamental sets of questions: maximum configurability versus ease of use, and stability versus expandability. Unix was written by programmers and for programmers, not end users – and it stressed the power of configurability over user-friendliness (although great steps in that direction have been taken lately). 

As time went on, more and more features were added to Unix by various offshoots of Bell and by university computer science students. UC Berkeley’s Computing Systems Research Group (CSRG) acquired a license for Version 6, and set a goal to write a completely AT&T code-free version of the system. The rise of the ARPAnet/NSFnet network drove Berkeley to develop innovations such as a full integration of TCP/IP into Unix and the birth of domain names (DNS and BIND). As such, the development of what would become the Internet was intimately tied to Unix – and Unix would remain the Internet’s OS of choice. By the mid-‘80s, Unix was well known within the computer science community as the operating system that could wring maximum stability and performance out of almost any hardware.

CAN’T WE ALL JUST GET ALONG?

In the early ‘80s, Bell had transferred their development of Unix to Western Electric, which called their commercial version of Unix “System III” (they figured that if they called it “System I” no one would buy it since they’d think it was too buggy). Unix System V was released in 1983, and System V Release 4 (SVR4) was released in 1989, incorporating many of the improvements made by the Berkeley group and Sun Microsystems (including TCP/IP and NFS). Unix even had two Graphical User Interface schemes (Motif and OpenLook) – both commercial and (appropriately) completely incompatible implementations of the open MIT “X Window” standard. By the late 1980s, Unix was a fully commercial operating system family in all its variants; but it was a “high-end” OS that was far out of reach for individual users, and which the personal computer revolution had largely passed by.

At this point, it’s worth a brief digression to discuss “what is Unix?” If you want to be technical, only operating systems based on AT&T code and blessed by the Open Group (the Unix trademark holder) qualify as Unix. Personally, I think that’s a load of crap. For the purposes of this article (and the rest of this column’s run), any OS that you can bring to a screeching halt by typing “kill –9 1“ at a root shell prompt is Unix – and that includes SVR4, BSD and Linux-based OSes.

Anyway, during this time, the university community that had given birth to so many of Unix’s developments remained active – and they wanted a Unix that was inexpensive enough to be used by individuals or groups without the deep pockets of universities and corporations. Parallel to the growth of private Internet Service Providers seeking Internet access outside of the institutions through which they had used the Internet, hackers were still active trying to create a Unix of their own.

HACKERS != LAWYERS

The Berkeley CSRG’s funding ran out before it fully completed its goal of creating an AT&T-free Unix, but just before its demise CSRG released a version (still retaining five or 10 percent AT&T code) called 4.3 BSD Net/2.They published their work under what became known as the “BSD” license, which made the source free to anyone who wanted it (but also allowed it to be incorporated into non-open-source and commercial projects). One of the many groups that picked up the Net/2 ball and ran with it was a commercial interest, Berkeley Software Design, Inc. (BSDI), which worked on filling in the gaps in Net/2 and selling the resulting product. Simultaneously, Berkeley’s Bill Jolitz made a great leap for hackers and hobbyists everywhere with a more-or-less AT&T-free port of Unix to the Intel 80386 architecture called 386BSD.

Frightened by the “free PC Unix clone” possibilities of 386BSD, AT&T sued Berkeley. Predictably, Berkeley countersued AT&T. While their lawyer landsharks battled it out, AT&T sold the SVR4 code rights to Novell (anyone remember UnixWare?). Development still went on in the meantime, and a horde of groups worked on merging the BSD and SVR4 releases or creating an entirely new Unix. Around about a million different Unix “standards” groups came into existence and were wholeheartedly ignored by everyone else.

UNIX – LIVE FREE OR DIE

Richard Stallman had already begun his “free-software” movement in the mid-‘80s when he started to read “Karl Marx’s Greatest Hits” and write Emacs. With some MIT buddies, he formed the GNU (GNU’s Not Unix) Project to take all of those AT&T Unix utilities and make better versions that were free/open source – and eventually to create a completely new free Unix, to be called the GNU Hurd. The GNU license(s) essentially forbade using the code in products that were not open. The GNU licenses provided the crucial distinction of the “free software” movement that would evolve from the GNU project, and separated it from the looser BSD license, which would become the model of the often semi-corporate “open source software” movement of the late 1990s.

Meanwhile, in 1991, a 21-year-old Finnish computer science student named Linus Torvalds was working on making a free and better version of Unix’s kissing cousin Minix. Torvalds developed the beginnings of a completely new kernel (the “core” part of the OS that handles memory management and device input/output, and acts as interface between hardware and software), and posted to Usenet’s comp.os.minix his source code for version 0.02 of what would soon be called “Linux.”

THE RISE OF FREENIXES

The BSD development model emphasized a “core team” of developers responsible for the primary guidance of a project, and a number of teams sprang up to release free versions of Unix based on the BSD code. Unfortunately, they all managed to get along “like two cats in a sack.”

At the same time, Linux – which had been released under a GNU license – emphasized a decentralized development model. Torvalds remained that head of Linux kernel development, and Linux variants were unified by their use of the Torvalds-approved kernel. However, everyone was invited to take part in adding drivers and kernel developments, and anyone was free to form their own Linux “distribution” (anyone remember Yggdrasil?) concentrating on whatever direction they felt that Linux should go. 

Suddenly, in 1994, the lawyer-welfare project known as the “AT&T/Novell vs. Berkeley war” ended. The exact details of the settlement are sketchy, but BSDI shortly thereafter discontinued its Net/2-based system and replaced it with a release based on a new code base called 4.4 BSD Lite. Novell eventually sold its SVR4 rights to the Santa Cruz Organization (SCO), and the SVR4-based non-free Unixes (including Solaris, HP/UX, Digital Unix and IBM’s AIX) continued and proliferated. Also in 1994, Linux kernel 1.0 was quietly released. In time, Stallman’s Free Software Foundation – seeing that the GNU Hurd project would be up to speed sometime around 2040 – came to adopt Linux (Debian distribution) as a replacement for the Hurd, despite some well-publicized nomenclature hissy-fits by Stallman about calling Linux “GNU/Linux.”

RIGHT HERE, RIGHT NOW

Today, the commercial Unixes are still around and (at least some of them) flourishing. Meanwhile, development for hobbyists, hackers, ISPs and many businesses has focused on the Freenix family. Right now, there are four primary Freenixes of interest to ISPs: Linux, FreeBSD, NetBSD and OpenBSD – each with a different philosophy, focus, and strengths or weaknesses.

In next month’s edition, we’ll explore what makes them different, and why one or the other may be right for your ISP. In the meantime, those of you with enough free time or pain tolerance to have read this far should please feel free to send your questions and comments about the varying Freenix families to [email protected]. Flames and hate mail should be directed to John Dvorak. 😉

By Jeffrey Carl

This was the first article I was invited to write for Boardwatch Magazine back in 1998. I had started working at an ISP in 1997 and discovered that not only was I the only Mac user, but all the hardcore techies working there actively disdained Macs and Mac users. At the time, Apple was actively circling the corporate drain and it was a bad time to be a Mac fanboy, so this was my bit of advocacy to speak to ISP operators and encourage them to not lock out the Mac market. As a result, I take full credit for Apple’s resurgence over the past 20 years.

For several years, it seemed that all the Mac users had hidden out in caves with OS/2 Warp users, or had moved to cabins in Montana and spent their time sending angry letters to the editors of PC Week magazine. However, Macintoshes are coming back – roughly 12 percent of new computers sold through retail stores are Macs, and that number is climbing. 

There are some very good reasons for making sure that your ISP supports Macintoshes (if it doesn’t already). You can gain a competitive advantage by advertising yourself as being one of the few (or the only) ISPs in your area that is “Mac-Friendly.” Millions of people have bought iMacs because they want a simple machine for surfing the web and reading E-mail – and they all need an ISP. 

Of course, there are tradeoffs to offering Mac support. On the down side, you’ll still get the same calls from Mac lusers that you get from Windows lusers who are busy looking for the RS-232 port on their toaster. And to really answer all of the questions that might come up, you’ll want an actual Mac user on staff (or at least within E-mail reach).

On the plus side, though, the vast majority of Mac users have the same few questions that you’re used to answering for PC users. By knowing five simple tools and resources, you can answer about 95 percent of the Mac tech support calls you’re likely to receive – even if you’ve never even touched a Mac yourself. These resources, all included in a default installation of the operating system, are part of MacOS (which sounds like a breakfast cereal) version 8.5 or 8.6, which all new Macintoshes are shipped with. For information on providing tech support for customers with older Mac system versions, check out http://www.hosed.net/oldmacsupport.

Mac Basics

Many of the calls you’ll receive with Macs are about the same UCDI (User Clue Deficiency Issues) problems you’ve heard from PC users. You know the drill: make sure that their modem is connected to the computer, make sure all the cables are firmly connected, make sure the phone line is plugged in, et cetera. 

In case you’ve never used a Mac, there are a couple of interface basics that you’ll need to be acquainted with in order to guide a user through troubleshooting. 

The MacOS analog to the Windows 95/98 “Start Button” is the Apple Menu, marked by an Apple icon (a)located in the very top left corner of the screen. Just like Windows menus, Mac menus are single-click “sticky menus” that are easily navigated. To close a Mac document window, click on the button in the upper left (not right) corner; clicking on the buttons in the top right will only expand or collapse the window.

Instead of showing the open applications or control panels in a task bar, Macs have an Application Menu in the top right corner of the screen. The name (or just the icon in some cases) of the foreground app is displayed there; clicking on the menu will allow you to switch between open applications or hide (minimize) them. This is important, since many novice Mac users may not know whether the foreground is an application or the Finder (the application which creates the Mac GUI). To change your foreground task, simply click on the appropriate item in the Application Menu.

The “meta” key on Macs (analogous to the “Windows key” on PCs) is the “command” key, sometimes known as the “Apple key” (it’s the one with the X icon). Applications are launched by double-clicking them, or selecting them with a single click from the Apple Menu. Quitting an application is done by selecting File >> Quit, or with the X–Q keystroke combination.

Internet Setup Assistant

As mentioned, Apple goes to great lengths to make its OS as friendly (“cretin-proof”) as possible, and it provides a pretty useful wizard for supplying all of the information a user needs to set up a dial-up or dedicated Internet connection. The Internet Setup Assistant runs automatically the first time a user boots their Mac, or it can be found with Apple Menu >> Internet Access >> Internet Setup Assistant. 

The initial screen of the Setup Assistant asks, “Would you like to set up your computer to use the Internet?” Click yes. The second screen asks, “Do you already have an Internet account?” If you answer “yes,” this brings you to an introductory screen of a separate program called the Internet Editor Assistant. If you answer “no,” you’re still taken through most of the Internet Editor Assistant steps, but at the end of the process, you can dial into an Apple database of Mac-friendly ISPs to choose one. 

The installation process is fairly straightforward, and users should be able to complete it easily if you’ve given them: 1.) their username and password; 2.) your local dialup access number; 3.) their POP and SMTP server addresses and/or passwords; 4.) which type of server they’re connecting to (e.g., PPP, DHCP, BootP, etc.); 5.) their nameserver IP addresses, subnet mask and default router (if this is required); 6.) and a PPP connect script if it’s needed. If you require a PPP connect script, make sure that your user can obtain it and place it in the System Folder >> Extensions >> PPP Connect Scripts directory on their hard drive. If any of these settings have been entered incorrectly, the user can re-run the Assistant, or change their information manually in the relevant control panel. 

Control Panel: Remote Access

To dial in, a Mac user must access the Remote Access control panel, which can be reached through Apple Menu >> Control Panels >> Remote Access. Users may not realize that this control panel is the only way to initiate a PPP connection, since there are two misleadingly-named items in the Apple Menu >> Internet Access menu (Browse the Internet and Connect To…) which don’t create a PPP connection; they simply launch the user’s default web browser, whether a connection is active or not.

To initiate a dial-in PPP session, bring up the Remote Access control panel. If they aren’t already filled in, supply your username and password, then click “Connect.” Remote Access will show the steps it goes through as it dials and connects (or any errors it encounters on the way). If it reports an error, you can use one of the other tools listed here to track down the error, or use the Internet Setup Assistant to replace all of your settings. If all goes well, the Remote Access control panel will then show a connection timer and two columns of lights, indicating data being sent and received. To terminate a session, activate the control panel again and click “Disconnect” (or just snip your phone line with a pair of scissors).

A connection will remain active if you quit the Remote Access control panel. However, if you’re having dropped-connection problems, it’s not a bad idea to just hide the control panel or leave it in the background, since the Remote Access control panel is your best indication of whether a connection is still active.

Control Panel: Modem

If you’re is having trouble dialing, the Modem control panel is the first place to check. Check your modem settings by selecting Apple Menu >> Control Panels >> Modem. Make sure that you have selected the correct port to which your modem is attached; otherwise, you’ll get a “modem could not be found” or “port is in use” error. Also, make sure that you’ve selected a proper modem type (the only effect of the modem type setting is to determine the initialization string). Other options, including pulse or tone dialing, are configured here as well.

Control Panel: TCP/IP

The TCP/IP control panel is where settings for name service, router and IP addresses are stored. To access it, select Apple Menu >> Control Panels >> TCP/IP. The relevant information should already have been entered by the Internet Setup Assistant, but it can be modified here if necessary by typing directly into the fields in the control panel. If the Remote Access control panel reports problems negotiating with the dial-up server, check the TCP/IP control panel to make sure that you have the correct server type selected (PPP, DHCP, BootP, et cetera).

Control Panel: Extensions Manager

If a user reports issues with their system crashing or another application crashing when they connect, odds are that it’s a MacOS extension that’s to blame. Extensions are files containing libraries and routines which patch system traps, and they are notorious for conflicting with each other and causing crashes (especially extensions installed as part of third-party or shareware programs).

The Extensions Manager control panel, accessed by selecting Apple Menu >> Control Panels >> Extensions Manager, controls which extensions and control panels are loaded by the system at startup time. If you’re experiencing frequent crash or freeze problems, activate the Extensions Manager. Click the “My Settings” pull-down menu and select the predefined extensions set called “MacOS 8.5 All” (or “8.6 All”) and restart. This will limit the loaded extensions to only those that are defaults for the OS – which should result in a stable system. You may temporarily lose some of your favorite system enhancements and cool widgets – but the system should be stable enough to access the Internet. If not, then you’ve got inherently bug-ridden software – or worse problems that should be taken up with Apple.

Conversely, you can examine the Extensions Manager control panel to make sure that all of the needed extensions for Internet access are loaded. A “MacOS 8.5 All” setting should include these; if you’re using a custom set of extensions, make sure that the Modem, Remote Access and TCP/IP control panels are checked, as well as any extension relating to Open Transport (the Mac’s native streams-based TCP/IP stack implementation). 

Outside Resources

While the tools listed above can cover most basic connection problems, they can’t solve everything. However, a few other resources go a long way toward fleshing out your Mac support. First, pick up copies of Macworld Mac Secrets (5^th Edition), by David Pogue and Joseph Schorr, and Sad Macs, Bombs, and Other Disasters by Ted Landau. These two books are absolutely indispensable for advanced troubleshooting. Second, you should know where your local Tucows mirror is, since they have a pretty comprehensive stock of Internet software for Macs – everything from the latest versions of web browsers to free tools for FTP, telnet, ping and more. Finally, you may want to bookmark http://til.info.apple.com, Apple’s Tech Info Library, which contains volumes of easily-searchable technical support information.