build, configure, and manage dedicated FreeBSD servers. It will also be useful for those folks who

want to run FreeBSD on their desktop or combined desktop/server systems.

By the time you finish this book, you should be able to use FreeBSD to provide network services.

You should also understand how to manage, patch, and maintain your FreeBSD systems, and have

a basic understanding of networking, system security, and software management. We will discuss

FreeBSD version 4, which is the version recommended for production use as this book is being

released. Most of this book will be applicable to earlier and later versions, as well. Much of this book

is also applicable to NetBSD and OpenBSD.

extensively in the ISP (Internet service provider) world, embedded devices, and anywhere reliability

is paramount. It’s based directly on the original UNIX produced by AT&T in the 1970s.

Many years ago AT&T needed a lot of computer software to run their business. They were not

allowed to compete in the computer business, however. As a result, they licensed various pieces of

software, and the source code for it, to universities at low, low prices. University students with

access to this nifty technology could read the source code to learn how it worked. In return, AT&T

got free exposure, some pocket change, and a generation of computer scientists who cut their teeth

on their equipment. Everyone was happy. The best−known software distributed under this licensing

plan was UNIX.

operating system to be certified “UNIX,” someone must pay The Open Group large chunks of

money. Since FreeBSD is developed in a not−for− profit manner, this isn’t likely.

Compared with modern operating systems, the original UNIX wasn’t very good. But, since so many

students had the source code for UNIX, and so many teachers needed projects for their students,

UNIX was quickly improved by their efforts. Gradually, useful commands were built. The ability to

supported features we take for granted now. Over many years, entire chunks of the original UNIX

operating system were extracted and replaced.

The various universities that worked on UNIX shared their improvements and enhancements, with

the Computer Systems Research Group (CSRG) at the University of California, Berkeley, acting as

a central clearinghouse for UNIX code improvements. The CSRG distributed this code for free to

anyone with a valid AT&T UNIX license.

The resulting collection of patches for UNIX came to be known as the Berkeley Software

Distribution, or BSD UNIX. (It didn’t hurt Berkeley’s status any that the Defense Advanced Research

Projects Agency (DARPA) contributed funding to the CSRG to implement TCP/IP in UNIX.)

This development process continued for a long, long time. In fact, if you look at the copyright

statement on FreeBSD, you’ll see this:

Eventually, the CSRG’s funding started running out. After some political wrangling within the

University of California, in 1992 the code was released to the general public under what became

known as the BSD license. Today, the BSD license has three clauses that can be summarized as

follows:

· Don’t claim you wrote this.

· Don’t blame us if it breaks.

(The original license required that every time someone used the software, they had to include a

notice that it included software copyrighted by the University of California. This requirement was

dropped a few years later. Today, people can use BSD code without having to announce it or notify

anyone.)

The BSD license may be the most liberal software license ever used. People are free to take BSD

and include it in proprietary products, free products, and open−source products, or print it out on

punch cards and cover the lawn with it. Instead of “copyright,” the BSD license is sometimes

referred to as “copy− center,” as in “take this down to the copy center and run off a few for yourself.”

Not surprisingly, companies such as Sun Microsystems jumped right on it because, well, it was free.

During the CSRG’s heyday, however, UNIX work proceeded apace at AT&T. AT&T took parts of the

BSD UNIX distribution and integrated them with their UNIX, then turned around and relicensed the

result.

This worked well for AT&T until the grand breakup, when the mother of all telephone companies

suddenly was permitted to compete in the software business. They had one particularly valuable

property: a high−end operating system that had been extensively debugged by thousands of people

all over the world. They happily started selling UNIX to enterprises and charging very high fees for

it, all the while maintaining the university relationships that had given them such an advanced

operating system.

6

Berkeley’s 1992 release of the BSD code met with great displeasure from AT&T’s subsidiary USL

(UNIX System Laboratories). Almost immediately they took some of the software users, and the

university, to court. USL claimed that Berkeley had given away their intellectual property. The

University of California said that it was their intellectual property. In the meantime, various people

picked up on the code released by Berkeley and began building commercial and free products out

of it. One of these products was 386BSD, which would eventually be used as the core of FreeBSD

1.0.

In 1994, after two years of legal wrangling, the case was settled out of court once it was proved that

a great deal of the code in AT&T UNIX was actually taken in its entirety from BSD, rather than the

other way around! A half−dozen files were the only sources of contention, and to resolve these

outstanding issues some of the files were donated and others were kept proprietary. Unfortunately,

FreeBSD 1.X contained some of these files, so various BSD users worked frantically to rebuild

these missing components.

Once the dust settled, this new version of UNIX was released to the world as BSD4.4−Lite. A

subsequent update, BSD4.4−Lite2, is the grandfather of the current FreeBSD source, as well as the

ancestor of many other operating systems, such as NetBSD, OpenBSD, and Mac OS X.

Today FreeBSD is used throughout the Internet by some of the most vital and visible

Internet−oriented companies. For example, at this writing, Yahoo! is run almost entirely on

FreeBSD. The “baby Bell” US West uses FreeBSD to power its Internet operations. IBM, Nokia, and

many other hardware companies use FreeBSD in embedded systems where you’d never even

know it’s there.

The fact is, if a company needs to pump some serious Internet bandwidth, it’s probably running

FreeBSD. FreeBSD is all around you; you just may not see it because it rarely crashes.

There’s an old saying that managing programmers is like herding cats. However, despite what you

might think, for the most part these FreeBSD developers work well together as members of the

FreeBSD team. And, unlike some other projects, all FreeBSD development happens openly. Two

groups of people develop FreeBSD: contributors and committers.

access to the FreeBSD master source−code repository and can develop, debug, or enhance any

piece they deem necessary.

To plug yourself in to the beehive of FreeBSD development, consider subscribing to the mailing list

FreeBSD−hackers@FreeBSD.org, which contains most of the technical discussion. Some of the

technical talk is broken out into more specific mailing lists—for example, the networking

development is discussed on FreeBSD−net@FreeBSD.org. There are also a few IRC channels

where the FreeBSD crew hangs out and discusses things. Visitors and eavesdroppers are

welcome, so long as they don’t interfere. (Yes, Internet chat can be used for a variety of useful

technical purposes!) The committers are responsible for keeping FreeBSD working, adding new

features, and evaluating patches from contributors. Most of these developers are volunteers; only a

handful are actually paid to do this painstaking work.

7

In addition to the committer team, FreeBSD has thousands of contributors. Contributors don’t have

to worry about breaking the main operating system repository; they just submit patches for

consideration by committers. Committers evaluate submissions and decide what to accept and what

to reject. A contributor who submits consistently acceptable code will frequently be asked by the

committers he works with to become a committer himself.

For example, I spent several years as a contributor. Any time I feel that I’ve wasted my life, I can go

look at the FreeBSD Web page and see where my work has been accepted by the committers and

used by thousands of users. (It helps. Sort of.) Between submitting this book and getting it back

from the editor, however, I had some spare time. I spent a while submitting patches to the FreeBSD

FAQ. Eventually, some members of the FreeBSD Project approached me and asked me to become

a committer. I initially refused, but finally allowed a few developers to persuade me.[2]

Finally, FreeBSD has a mob of users, though it’s impossible to realistically estimate their number.

After all, you can download the whole of FreeBSD for free, and never register, upgrade, or mail to a

mailing list.

Estimates are that somewhere between 5 and 10 percent of the machines on the Internet are

BSD−based. That’s 5–10 percent of all the systems connected to the Internet, including the

countless Windows systems sitting on office desks. If you remove those systems from the count and

only count Internet servers, the percentage rises.

Since FreeBSD is by far the most popular open−source BSD, that’s not an inconsiderable number

of machines. And since one FreeBSD server can handle hundreds or thousands of Internet

domains, a disproportionate number of sites uses FreeBSD compared to the number of servers.

[2]And some day I might forgive Will, Wilko, and Bruce for that. But I’ll never let them live it down.

FreeBSD is the most popular BSD, but it’s not the only one. BSD 4.4−Lite spawned several different

projects, each with its own focus and purpose.

NetBSD is similar to FreeBSD in many ways, and the teams share developers and code. NetBSD’s

main purpose is to provide an operating system that can be ported to any hardware platform.

As such, NetBSD runs on VAXes, PocketPC devices, and high−end Alpha servers, as well as the

Compaq iPaq. It even runs on hardware that doesn’t exist yet—as I write this, the AMD

The NetBSD code is specifically licensed to be freely reusable, just like the original BSD 4.4−Lite

code it’s based on.

8

OpenBSD branched off from NetBSD in 1996 with the goal of becoming the most secure BSD.

OpenBSD was the first to support hardware−accelerated cryptography (allowing it to encrypt and

decrypt information at a remarkable rate), and the developers are rather proud of the fact that their

default install hasn’t been hacked remotely for over four years.

The OpenBSD people have audited the entire BSD code base, fixing most (but not all) potential

security holes before they can be exploited. OpenBSD is not as friendly or as easy to use as

FreeBSD, however.

BSD/OS, produced by Wind River Systems, is a commercial, closed−source operating system that

greatly resembles FreeBSD. Some hardware manufacturers will not release hardware specifications

without nondisclosure agreements, and developers for a freely available operating system cannot

develop device drivers for such proprietary hardware. BSD/OS supports much of this hardware.

A great deal of the BSD/OS code is available to FreeBSD committers, and FreeBSD absorbs

BSD/OS enhancements that don’t break nondisclosure agreements.

Mac OS X? That’s right. Large chunks of FreeBSD were incorporated into Apple’s Mac OS X. If

you’re looking for a stable operating system with a friendly face and a powerful core, Mac OS X is

unquestionably for you. While FreeBSD makes an excellent desktop for a computer professional, I

wouldn’t put it in front of grandma. I would put Mac OS X in front of grandma without a second

thought, and even feel that I was doing the right thing.

Mac OS X includes a lot of things that aren’t at all necessary for an Internet server, however, and it

only runs on Apple hardware, so I don’t recommend it for an inexpensive, high−powered server.

While you cannot get the user interface source code for Mac OS X, you can view the operating

system’s BSD core and Mach kernel; Apple has released them under the code name Darwin.

There are several other UNIX operating systems out there, some of which have even rented the

trademark UNIX so they can label themselves as such. This list is by no means exhaustive, but we’ll

touch the high points.

The best−known UNIX is Sun Microsystems’ Solaris. Solaris runs on high−end hardware that

supports dozens of processors and gobs of disks. (Yes, “gobs” is a technical term.) It’s used by

many enterprise−level applications, such as Oracle.

Solaris runs mainly on the SPARC hardware platform, which is manufactured by Sun. Since Sun

controls both the hardware and software, they can make their systems support many interesting

features, such as hot−swappable memory and main boards.

9

Another UNIX contender is IBM’s AIX. AIX’s main claim to fame is the journaling filesystem, which

records all disk transactions as they happen. It allows you to recover from system crashes without

much trouble, providing great reliability. AIX is based largely on BSD.

Linux is a clone of UNIX, written from the ground up in the last decade or so. Linux is similar to BSD

in many ways, though BSD has a much longer heritage, and is more friendly to commercial use

than Linux. Linux includes a requirement that a commercial user contribute all changes back to

Linux, while BSD has no such restriction.

Among many UNIX users, there’s a perception of conflict between the BSD and Linux camps. If you

dig a little deeper, however, you’ll find that most of the developers of these platforms communicate

and cooperate in a friendly and open manner. It’s just a hard fringe of users and a very few

developers that generate friction.

Other UNIXes include Silicon Graphics’ IRIX, a solid UNIX for graphics applications, and

Hewlett−Packard’s HP−UX, popular in large enterprises. Many high− end software packages, such

as Informix, are specially designed for HP−UX.

If you look around you’ll also find smaller contenders, such as SCO and UnixWare. They aren’t

unimportant, they just aren’t as popular. You’ll also find old castoffs, such as Apple’s A/UX and

Microsoft’s Xenix. (Yes, Microsoft was a licensed UNIX vendor, very, very long ago.) Xenix was

eventually sold to SCO and became SCO UNIX.

So, after all this, how can we summarize FreeBSD?

FreeBSD’s goal is to provide a freely redistributable operating system that runs on popular

hardware. While system security is a vital concern, FreeBSD’s main goal is to run on the hardware

people are most likely to have. Today, this means the Intel x86−compatible systems (386, 486,

Pentium I through IV, Celeron, and AMD). FreeBSD also supports the Alpha processor, and work is

underway to support Intel’s new IA64, AMD’s new 64−bit chips, and Motorola’s PowerPC, as well as

Sun’s SPARC. (These platforms aren’t afterthoughts; the hardware is just now coming out, or only

now becoming popular enough to port to.)

Since FreeBSD runs adequately on 386 hardware, it runs quite well on modern computers. It’s

rather nice to have an operating system that doesn’t demand a Pentium III and a half−gig of RAM

just to power the user interface. As a result, you can actually use all that computing power to do the

work you want, rather than to run tasks you don’t care about. If you choose to run a pretty graphical

interface with all sorts of spinning geegaws and fancy whistles, FreeBSD will support you, it just

10

won’t require you to do so.

FreeBSD also simplifies software management through its ports collection. Traditionally, tuning

software for a UNIX system has required considerable expertise. The ports collection simplifies this

considerably by automating and documenting the install, uninstall, and configuration process for

thousands of software packages. (Several other BSD operating systems have built their own

packaging systems based on the ports collection.)

Unlike operating systems that require painful and risky upgrade procedures, such as Windows,

FreeBSD’s simple upgrade process builds an operating system that is optimized for your hardware

and application. This lets FreeBSD use every feature your hardware supports, instead of just the

lowest common denominator. If you change hardware, you can rebuild your system for that

particular hardware. Vendors such as Sun and Apple do exactly this, since they create both the

hardware and the operating system, but FreeBSD doesn’t lock you in to a particular hardware

platform.

series of zeros and ones on the metal disk in your hard drive. FreeBSD includes very sophisticated

filesystems. It can support files up to a petabyte (one thousand thousand gigabytes) in size, it is

highly damage−resistant, and it reads and writes files extremely quickly. The BSD filesystem is so

advanced that it has been adopted by many commercial UNIX vendors, such as Sun and HP.

While FreeBSD can be used as a very powerful desktop or development machine, its history shows

a strong bias toward Web, mail, file, and support services. In fact, FreeBSD’s main strength is on

Internet servers, and it is an excellent choice for any Internet service.

If you’re thinking of running FreeBSD (or any UNIX) on your desktop, you’ll need to understand how

your computer works. FreeBSD is not your best choice if you’re looking for point−and−click

simplicity. If that’s your goal, get a Macintosh computer and use Mac OS X, which has a BSD core,

so you can access the power of UNIX when you want it and not worry about it the rest of the time.

Or, if you want to use the lowest common denominator, there’s always the various iterations of

Microsoft Windows. You won’t have to understand your computer, but Windows is easy.

You can, of course, use FreeBSD as a powerful desktop OS.

There’s a concept in computing called “eating your own dog food.” If you ran a dog food company,

you’d want to make a product that your own dog would eat. If your dog turns up his nose at your

latest recipe, your company has a problem. The point here is that if you work with a product, you

should actually use it.

11

This total immersion method provides the fastest possible training and is the approach I took to

learn UNIX. By running FreeBSD exclusively on my desktop, I learned how to make a UNIX system

do anything I needed, and I became a much more powerful server administrator as a result.

In fact, I even wrote this book on my FreeBSD laptop, using an open−source word processor

(Emacs) and a business suite called StarOffice. I also use FreeBSD to watch MPEG video from

unencrypted video CDs and DVDs, burn MP3s from my own CDs, and listen to the MP3s when I

should be working. This is a fairly exhaustive sample of desktop tasks.

Desktop operating systems also allow you to do all sorts of silly things. At the moment, I have a

small animated BSD daemon sleeping under my mouse pointer. When I move the mouse, the

daemon awakens, chases down the pointer, and stabs it with his pitchfork. If this doesn’t count as a

Stupid Desktop Trick, I don’t know what does.

NetBSD is FreeBSD’s closest competitor. However, unlike competitors in the commercial world, this

competition is mostly friendly. NetBSD and FreeBSD share code and developers freely; some

people even maintain the same subsystem in both operating systems. For example, NetBSD and

FreeBSD share their USB support. In fact, as I write this, work is actively underway to integrate the

FTP server used in both operating systems.

NetBSD’s main advantage is that it runs on anything. For example, I have an ancient Silicon

Graphics workstation running NetBSD that I use as an NFS (Network File System) and DNS

(Domain Name System) server. It does the job. If you have old or weird hardware, NetBSD is a

good choice for you.

OpenBSD seems to stand apart from the rest of the BSD projects. While its code is available for

general use, the developers appear to be more interested in security than in making their system

approachable. OpenBSD has features that make it easy to do tasks such as bridging firewalls,

however, so if you find you can’t do some security work in FreeBSD, check out OpenBSD.

Proprietary operating systems like Sun’s Solaris, Microsoft’s Windows NT, IBM’s AIX, and their ilk

are still quite popular despite the BSDs and Linux gnawing at their market share. Solaris, in

particular, holds a great deal of the UNIX market.

High−end enterprises (the Fortune 500) are fairly closely shackled to Solaris and Windows NT.

While this is slowly changing, it is true for now, and in such environments you’re probably stuck with

those operating systems. But slipping in an occasional FreeBSD machine to handle basic services

such as DNS and file serving can make your life much easier at a much lower cost.

Of course, if your software will only run on a proprietary UNIX, your choice of operating system is

probably clear. Still, always ask a vendor if a FreeBSD version is available; you may be pleasantly

surprised.

12

Many computer books are thick enough to stun an ox, if you can lift them high enough without an

athletic supporter and a back brace. Plus, they’re either encyclopedic in scope or so painfully

detailed that they’re difficult to read. Do you really need a screenshot when you’re told to “click OK”

or “accept the license agreement”? And when was the last time you actually sat down and read the

encyclopedia?

around if you want to, but each chapter builds on what comes before. It’s also short enough to be

digestible. After you’ve read it once, you can easily use it as a reference.

(If you’re a frequent buyer of computer books, please feel free to insert all the usual stuff about

“read a chapter at a time for best learning” and so on. I’m not going to coddle you—if you picked up

a book on computing, you probably have two brain cells to rub together. Follow the examples, and

you’ll learn.)

This book is aimed at the new UNIX administrator. Several years ago the new UNIX administrator

was already a skilled UNIX user with real programming skills and a degree in computer science, or

at least most of one. Today, UNIX−like operating systems are freely available from the Internet and

even 12−year−old children can run UNIX, read the source code, and learn enough to intimidate us

older folks. As such, I don’t expect you to know a huge amount about UNIX before firing it up.

To use this book to its full potential, you should be familiar with some of the basic UNIX commands,

such as how to change directories (cd), list files in a directory (ls), and log in with a username and

password. If you’re not familiar with basic commands and running UNIX from the shell, I recommend

Scott Seebass, and Trent R. Hein (Prentice Hall PTR).

You’ll also need to know something about PC hardware. (Not a huge amount, mind you, but some.)

For example, it will help to know what an IRQ (interrupt request) is and how to differentiate between

a SCSI and IDE hard drive. Your need for hardware knowledge will, of course, depend on the

hardware you’re using, but if you’re interested enough to pick up this book and read this far, you

probably have the hardware knowledge that you need. We’ll make this a little easier by assuming

you’re dedicating a system to FreeBSD; very few network servers dual−boot Windows and

FreeBSD, after all!

output from a shell command. To make it easier for newer administrators, however,

I include the exact shell commands needed to produce the desired results. If you

learn best by example, you should find everything you need right here.

Many new system administrators these days come from a Windows background.

They learn that “ls” is like “dir”, and “cd” is the same on both platforms. You can

learn the commands by rote, reading, and experience. What you cannot learn,

coming from this background, is how a UNIX machine thinks. It will not adjust to

you; you must accommodate it. With that in mind, we’re going to spend a little time

discussing how you must think about your FreeBSD system.

13

If you’ll be working with FreeBSD, you should understand some of the UNIX ways of thinking. Users

from a Windows background might very well go into shock during their first attempts to administer a

FreeBSD system if they don’t understand how UNIX behaves, and how it expects you to behave.

People who are used to GUI environments, such as Windows and Macintosh, are probably

unfamiliar with how UNIX handles input and output. If you are new to UNIX, you may be used to

clicking something and seeing either an “OK” message, an error, nothing, or (all too often) a pretty

blue screen with nifty high−tech letters explaining exactly where the system crashed. UNIX does

things a little differently.

UNIX programs have three “channels” of communication: standard input, standard output, and

standard error. Once you understand how each of these channels work, you’re a good way along to

understanding how a computer works.

standard input is the keyboard. If your program is listening to the network, the standard input is the

network. Many programs can rearrange standard input to accept data from the network, a file, the

keyboard, or any other source.

(screen). Network programs usually return the output to the network.

errors to the console; others log errors to a file.

The channels just described can be arbitrarily arranged, a concept that is perhaps the biggest

hurdle for new UNIX users and admins. While it seems simple enough, it’s slightly more difficult to

grow accustomed to than you might think.

For example, if you don’t like the error messages appearing on the terminal, you can redirect them

to a file. If you don’t want to type a list of information into a command, you can put the information in

a file (so you can reuse it), and dump the file into the standard input of your command. Or better

still, run a command to generate that information and put it in a file, or just pipe (send) it directly to

your second command.

Taken to its logical extreme, these input/output channels can overwhelm a new user. The first time I

saw someone type something like the following on a command line during my UNIX admin training,

I wanted to change careers.

…………………………………………………………………………………………

# tail −f /var/log/messages | grep −v sudo | grep −v named &

…………………………………………………………………………………………

14

Lines of incomprehensible text began spilling across the screen. And worse still, my trainer kept

typing as this output poured out!

If you’re coming from a point−and−click environment, a long string of commands like this is definitely

intimidating. What do all those funky words mean, let alone the symbols?

Think of learning to use the command line as learning a language. When learning a language, we

start with simple words. As we increase our vocabulary, we also learn how to string words together.

Learning to use the UNIX command line is like learning a language. You begin with simple single

commands and only later string them together into monstrosities like the one shown earlier.

Another difficulty people have is with the general UNIX program function philosophy. Most

consumer operating systems have monolithic software packages that try to be all things to all

people. UNIX programs are small, simple tools. That’s in part because of the redirectable

input/output channels, and in part because of UNIX’s heritage. Remember, at one time you needed

to be a programmer to run a UNIX system. Programmers don’t mind building their own tools.

Assembling a tool on the command line is fairly easy compared to compiling a whole software

package.

These smaller programs also provide unparalleled flexibility. Have you ever wished you could use a

function from one program in another program? By using a variety of smaller programs and

arranging the inputs and outputs as you like, you can make the system behave in any manner that

amuses you. Many modern platforms have only started catching up with this idea of small, reusable

tools in the last few years.

Download E-book