- •Table of Contents
- •Dedication
- •Foreword
- •Introduction
- •What Is FreeBSD?
- •How Did FreeBSD Get Here?
- •The BSD License: BSD Goes Public
- •The Birth of Modern FreeBSD
- •FreeBSD Development
- •Committers
- •Contributors
- •Users
- •Other BSDs
- •NetBSD
- •OpenBSD
- •Other UNIXes
- •Solaris
- •Linux
- •IRIX, HPUX, etc.
- •FreeBSD's Strengths
- •Portability
- •Power
- •Simplified Software Management
- •Optimized Upgrade Process
- •Filesystem
- •Who Should Use FreeBSD
- •FreeBSD as Your Desktop
- •Who Should Run Another BSD
- •Who Should Run a Proprietary Operating System
- •How to Read This Book
- •What Must You Know?
- •How to Think About UNIX
- •Channels of Communication
- •Working with Channels
- •The Command Line
- •Chapter 1: Installation
- •FreeBSD Hardware
- •Processor
- •Memory (RAM)
- •Hard Drives
- •Downloading FreeBSD
- •Installing by FTP
- •Other FTP Install Information
- •Hardware Setup
- •Actually Installing FreeBSD
- •Configuring the Kernel for ISA Cards
- •Sysinstall: The Ugly FreeBSD Installer
- •Disk Usage
- •Partitioning
- •Root
- •Swap Space
- •Swap Splitting
- •/var, /usr, and /home
- •A Second Hard Drive
- •Soft Updates
- •Block Size
- •What to Install
- •Installation Media
- •Committing
- •Root Password
- •Adding Users
- •Time Zone
- •Mouse
- •Configuring Network Cards
- •Xfree86
- •Software
- •Restart
- •A Note on Editors
- •Chapter 2: Getting More Help
- •Why Not Mail First?
- •The FreeBSD Attitude
- •Man Pages
- •The FreeBSD Manual
- •Man Page Headings
- •The FreeBSD Documentation
- •The Mailing List Archives
- •Other Web Sites
- •Checking the Handbook/FAQ
- •Checking the Man Pages
- •Checking the Mailing List Archives
- •Using Your Answer
- •Mailing for Help
- •Chapter 3: Read This Before You Break Something Else! (Backup and Recovery)
- •Overview
- •System Backups
- •Tape Devices
- •How to Read Dmesg.boot
- •Controlling Your Tape Drive
- •Device Nodes
- •Using the TAPE Variable
- •The mt Command
- •Backup Programs
- •Dump/Restore
- •Restoring from an Archive
- •Checking the Contents of an Archive
- •Extracting Data from an Archive
- •Restoring Interactively
- •Recording What Happened
- •Revision Control
- •Getting Older Versions
- •Breaking Locks
- •Viewing Log Messages
- •Reviewing a File's Revision History
- •Ident and ident Strings
- •Going Further
- •The Fixit Disk
- •Chapter 4: Kernel Games
- •Overview
- •What Is the Kernel?
- •Configuring Your Kernel
- •Sysctl
- •Changing Sysctls
- •Setting Sysctls at Boot
- •Kernel Configuration with Loader.conf
- •Manually Configuring the Loader
- •Viewing Loaded Modules
- •Loading and Unloading Modules
- •Customizing the Kernel
- •Preparation
- •Your Backup Kernel
- •Editing Kernel Files
- •Basic Options
- •Multiple Processors
- •Device Entries
- •Building Your Kernel
- •Troubleshooting Kernel Builds
- •Booting an Alternate Kernel
- •Adding to the Kernel
- •LINT
- •Fixing Errors with Options
- •Tweaking Kernel Performance
- •Sharing Kernels
- •Chapter 5: Networking
- •Overview
- •Network Layers
- •The Physical Layer
- •The Physical Protocol Layer
- •The Logical Protocol Layer
- •The Application Layer
- •The Network in Practice
- •Mbufs
- •What Is a Bit?
- •Ethernet
- •Broadcasting
- •Address Resolution
- •Hubs and Switches
- •Netmasks
- •Netmask Tricks
- •Hexadecimal Netmasks
- •Unusable IP Addresses
- •Routing
- •Network Ports
- •Connecting to an Ethernet Network
- •Multiple IP Addresses on One Interface
- •Using Netstat
- •Chapter 6: Upgrading FreeBSD
- •Overview
- •FreeBSD Versions
- •Release
- •Snapshots
- •Security Updates
- •Which Release Should You Use?
- •Upgrade Methods
- •Upgrading via Sysinstall
- •Upgrading via CVSup
- •Simplifying the CVSup Upgrade Process
- •Building a Local CVSup Server
- •Controlling Access
- •Authentication
- •Combining Authentication and Access
- •Chapter 7: Securing Your System
- •Overview
- •Who Is the Enemy?
- •Script Kiddies
- •Disaffected Users
- •Skilled Attackers
- •FreeBSD Security Announcements
- •Subscribing
- •What You'll Get
- •Installation Security Profiles
- •Moderate
- •Extreme
- •Root, Groups, and Permissions
- •The root Password
- •Groups of Users
- •Primary Group
- •Some Interesting Default Groups
- •Group Permissions
- •Changing Permissions
- •Changing File Ownership
- •Assigning Permissions
- •File Flags
- •Viewing a File's Flags
- •Setting Flags
- •Securelevels
- •Setting Securelevels
- •Which Securelevel Do You Need?
- •What Won't Securelevel and File Flags Do?
- •Living with Securelevels
- •Programs That Can Be Hacked
- •Putting It All Together
- •Chapter 8: Advanced Security Features
- •Traffic Control
- •Default Accept vs. Default Deny
- •TCP Wrappers
- •Configuring Wrappers
- •Daemon Name
- •The Client List
- •Putting It All Together
- •Packet Filtering
- •IPFilter
- •IPFW
- •Default Accept and Default Deny in Packet Filtering
- •Basic Concepts of Packet Filtering
- •Implementing IPFilter
- •Configuring Your Server to Use Jail
- •Configuring Your Kernel to Use Jail
- •Client Setup
- •Final Jail Setup
- •Starting the Jail
- •Managing Jails
- •Shutting Down a Jail
- •Monitoring System Security
- •If You're Hacked
- •Chapter 9: Too Much Information About /etc
- •Overview
- •Varieties of /etc Files
- •Default Files
- •/etc/defaults/rc.conf
- •/etc/adduser.conf
- •/etc/crontab
- •/etc/dhclient.conf
- •/etc/fstab
- •/etc/hosts.allow
- •/etc/hosts.equiv
- •/etc/hosts.lpd
- •/etc/inetd.conf
- •/etc/locate.rc
- •/etc/login.access
- •/etc/login.conf
- •Specifying Default Environment Settings
- •/etc/mail/mailer.conf
- •/etc/make.conf and /etc/defaults/make.conf
- •/etc/master.passwd
- •/etc/motd
- •/etc/mtree/*
- •/etc/namedb/*
- •/etc/newsyslog.conf
- •/etc/passwd
- •/etc/periodic.conf and /etc/defaults/periodic.conf
- •/etc/printcap
- •Working with Printcap Entries
- •/etc/profile
- •/etc/protocols
- •/etc/rc.conf and /etc/defaults/rc.conf
- •/etc/resolv.conf
- •/etc/security
- •/etc/services
- •/etc/shells
- •/etc/spwd.db
- •/etc/sysctl.conf
- •/etc/syslog.conf
- •Chapter 10: Making Your System Useful
- •Overview
- •Making Software
- •The Pain and Pleasure of Source Code
- •Debugging
- •The Ports and Packages System
- •Ports
- •Finding Software
- •Legal Restrictions
- •Using Packages
- •Installing via FTP
- •What Does a Package Install?
- •Uninstalling Packages
- •Package Information
- •Controlling Pkg_add
- •Package Problems
- •Forcing an Install
- •Using Ports
- •Installing a Port
- •Using Make Install
- •Uninstalling and Reinstalling
- •Cleaning Up with Make Clean
- •Building Packages
- •Changing the Install Path
- •Setting Make Options Permanently
- •Upgrading Ports and Packages
- •Upgrading the Ports Collection
- •Ports Collection Upgrade Issues
- •Checking Software Versions
- •Hints for Upgrading
- •Chapter 11: Advanced Software Management
- •Overview
- •Startup and Shutdown Scripts
- •Typical Startup Script
- •Using Scripts to Manage Running Programs
- •Managing Shared Libraries
- •Ldconfig
- •Running Software from the Wrong OS
- •Recompilation
- •Emulation
- •ABI Implementation
- •Foreign Software Libraries
- •Installing and Enabling Linux Mode
- •Identifying Programs
- •What Is Linux_base?
- •Adding to Linux_base
- •Configuring Linux Shared Libraries
- •Installing Extra Linux Packages as RPMs
- •What Is SMP?
- •Kernel Assumptions
- •FreeBSD 3.0 SMP
- •FreeBSD 5 SMP
- •Using SMP
- •SMP and Upgrades
- •Chapter 12: Finding Hosts With DNS
- •How DNS Works
- •Basic DNS Tools
- •The Host Command
- •Getting Detailed Information with Dig
- •Looking Up Hostnames with Dig
- •More Dig Options
- •Configuring a DNS Client: The Resolver
- •Domain or Search Keywords
- •The Nameserver List
- •DNS Information Sources
- •The Hosts File
- •The Named Daemon
- •Zone Files
- •A Real Sample Zone
- •named.conf
- •/var/named/master/absolutebsd.com
- •Making Changes Work
- •Starting Named at Boottime
- •Checking DNS
- •Named Configuration Errors
- •Named Security
- •Controlling Information Order
- •More About BIND
- •Chapter 13: Managing Small Network Services
- •Bandwidth Control
- •Configuring IPFW
- •Reviewing IPFW Rules
- •Dummynet Queues
- •Directional Traffic Shaping
- •Certificates
- •Create a Request
- •Being Your Own CA
- •Testing SSH
- •Enabling SSH
- •Basics of SSH
- •Creating Keys
- •Confirming SSH Identity
- •SSH Clients
- •Connecting via SSH
- •Configuring SSH
- •System Time
- •Setting the Time Zone
- •Network Time Protocol
- •Ntpdate
- •Ntpd
- •Inetd
- •/etc/inetd.conf
- •Configuring Programs in Inetd
- •Inetd Security
- •Starting Inetd
- •Changing Inetd's Behavior
- •Chapter 14: Email Services
- •Email Overview
- •Where FreeBSD Fits In
- •The Email Protocol
- •Email Programs
- •Who Needs Sendmail?
- •Replacing Sendmail
- •Installing Postfix
- •Pieces of Postfix
- •Configuring Postfix
- •Email Aliases
- •Email Logging
- •Virtual Domains
- •Postfix Commands
- •Finding the Correct Mail Host
- •Undeliverable Mail
- •Installing POP3
- •Testing POP3
- •POP3 Logging
- •POP3 Modes
- •Qpopper Preconfiguration Questions
- •Default Qpopper Configuration
- •APOP Setup
- •Configuring Pop3ssl
- •Qpopper Security
- •Chapter 15: Web and FTP Services
- •Overview
- •How a Web Server Works
- •The Apache Web Server
- •Apache Configuration Files
- •Configuring Apache
- •Controlling Apache
- •Virtual Hosting
- •Tweaking Virtual Hosts
- •.NET on FreeBSD
- •Installing the SSCLI
- •FTP Security
- •The FTP Client
- •The FTP Server
- •Chapter 16: Filsystems and Disks
- •Device Nodes
- •Hard Disks and Partitions
- •The /etc/fstab File
- •Disk Basics
- •The Fast File System
- •Vnodes
- •FFS Mount Types
- •FFS Mount Options
- •What's Mounted Now?
- •Dirty Disks
- •Fsck
- •Mounting and Unmounting Disks
- •Mounting Standard Filesystems
- •Mounting with Options
- •Mounting All Standard Filesystems
- •Mounting at Nonstandard Locations
- •Unmounting
- •Soft Updates
- •Enabling Soft Updates
- •IDE Write Caching and Soft Updates
- •Virtual Memory Directory Caching
- •Mounting Foreign Filesystems
- •Using Foreign Mounts
- •Foreign Filesystem Types
- •Mount Options and Foreign Filesystems
- •Filesystem Permissions
- •Removable Media and /etc/fstab
- •Creating a Floppy
- •Creating an FFS Filesystem
- •The Basics of SCSI
- •SCSI Types
- •SCSI Adapters
- •SCSI Buses
- •Termination and Cabling
- •SCSI IDs and LUNs
- •FreeBSD and SCSI
- •Wiring Down Devices
- •Adding New Hard Disks
- •Creating Slices
- •Creating Partitions
- •Configuring /etc/fstab
- •Installing Existing Files onto New Disks
- •Temporary Mounts
- •Moving Files
- •Stackable Mounts
- •Chapter 17: RAID
- •Hardware vs. Software RAID
- •RAID Levels
- •Software RAID
- •Vinum Disk Components
- •Vinum Plex Types
- •Preparing Vinum Drives
- •Dedicating Partitions to Vinum
- •Configuring Vinum
- •Concatenated Plex
- •Removing Vinum Configuration
- •Striped Volumes
- •Mirrored Volumes
- •Starting Vinum at Boot
- •Other Vinum Commands
- •Replacing a Failed Mirrored Plex
- •Chapter 18: System Performance
- •Overview
- •Computer Resources
- •Disk Input/Output
- •Network Bandwidth
- •CPU and Memory
- •Using Top
- •Memory Usage
- •Swap Space Usage
- •CPU Usage
- •When Swap Goes Bad
- •Paging
- •Swapping
- •Are You Swapping or Paging?
- •Fairness in Benchmarking
- •The Initial Test
- •Using Both CPUs
- •Directory Caching
- •Moving /usr/obj
- •Lessons Learned
- •Chapter 19: Now What's It Doing?
- •Status Mails
- •Forwarding Reports
- •Logging with Syslogd
- •Facilities
- •Levels
- •Syslog.conf
- •Wildcards
- •Rotating Logs with Newsyslog.conf
- •Reporting with SNMP
- •Basics of SNMP
- •MIBs
- •Snmpwalk
- •Specific Snmpwalk Queries
- •Translating Between Numbers and Names
- •Setting Up Snmpd
- •Index Numbers
- •Configuring MRTG
- •Sample mrtg.cfg Entry
- •Testing MRTG
- •Tracking Other System Values
- •Monitoring a Single MIB
- •Customizing MRTG
- •MRTG Index Page
- •Sample MRTG Configurations
- •Chapter 20: System Crashes and Panics
- •What Causes Panics?
- •What Does a Panic Look Like?
- •Responding to a Panic
- •Prerequisites
- •Crash Dump Process
- •The Debugging Kernel
- •kernel.debug
- •Dumpon
- •Savecore
- •Upon a Crash
- •Dumps and Bad Kernels
- •Using the Dump
- •Advanced Kernel Debugging
- •Examining Lines
- •Examining Variables
- •Apparent Gdb Weirdness
- •Results
- •Vmcore and Security
- •Symbols vs. No Symbols
- •Serial Consoles
- •Hardware Serial Console
- •Software Serial Console
- •Changing the Configuration
- •Using a Serial Console
- •Serial Login
- •Emergency Logon Setup
- •Disconnecting the Serial Console
- •Submitting a Problem Report
- •Problem Report System
- •What's in a PR?
- •Filling Out the Form
- •PR Results
- •Chapter 21: Desktop FreeBSD
- •Overview
- •Accessing File Shares
- •Prerequisites
- •Character Sets
- •Kernel Support for CIFS
- •SMB Tools
- •Configuring CIFS
- •Minimum Configuration: Name Resolution
- •Other smbutil Functions
- •Mounting a Share
- •Other mount_smbfs Options
- •Sample nsmb.conf Entries
- •CIFS File Ownership
- •Serving Windows File Shares
- •Accessing Print Servers
- •Running a Local Lpd
- •Printer Testing
- •Local Printers
- •X: A Graphic Interface
- •X Prerequisites
- •X Versions
- •Configuring X
- •Making X Look Decent
- •Desktop Applications
- •Web Browsers
- •Email Readers
- •Office Suites
- •Music
- •Graphics
- •Desk Utilities
- •Games
- •Afterword
- •Overview
- •The Community
- •What Can You Do?
- •Getting Things Done
- •Second Opinions
- •Appendix: Some Useful SYSCTL MIBs
- •List of Figures
- •Chapter 1: Installation
- •Chapter 5: Networking
- •Chapter 6: Upgrading FreeBSD
- •Chapter 19: Now What's It Doing?
- •List of Tables
- •Chapter 4: Kernel Games
- •Chapter 5: Networking
- •Chapter 8: Advanced Security Features
- •Chapter 9: Too Much Information About /etc
- •List of Sidebars
- •Chapter 15: Web and FTP Services
Loading and Unloading Modules
Load and unload software modules with kldload(8) and kldunload(8). For example, to load the warp console−mode screen saver, enter this command:
................................................................
# kldload /modules/warp_saver.ko
#
................................................................
Once you've finished, you can unload the module with this command:
................................................................
# kldunload warp_saver.ko
#
................................................................
If all possible functions were compiled into the kernel, the kernel would be much larger than it is. This way, you can have a smaller, more efficient kernel and only load modules as you need them.
Customizing the Kernel
You'll eventually find that you cannot tweak your kernel as much as you desire using only modules and sysctl, and your only solution will be to build your own custom kernel. But don't worry, the process is perfectly straightforward if you take it step by step.
The kernel shipped in a default install is called GENERIC. GENERIC is designed to run on a wide variety of hardware, though not necessarily to run well or optimally. GENERIC boots nicely on a 486 and later systems, but newer x86 systems have advanced features and optimizations that help them perform better, and GENERIC doesn't take advantage of these features because it's aiming for the lowest common denominator.
When you customize your kernel, you'll get better performance, and you can also include new functionality in it, or support for new hardware.
Preparation
You must have the kernel source code before you can consider building a kernel. If you followed the advice in Chapter 1, you're all set. If not, you can either go back into the installer and load the kernel sources or jump ahead to Chapter 6 and use CVSup instead.
If you don't know whether you have the kernel source code installed, look for a /sys directory. If it exists, and there are a bunch of files and directories in it, you have the kernel sources.
Before building a new kernel, you must know what hardware your system has. This can be difficult to determine, because the brand name on a component doesn't necessarily have any relationship to the device's identity or abilities. After all, many different companies made an NE2000−compatible network card. Even if the box said "3com," the circuits inside the chip said "ne2000."[5] Similarly, companies such as Linksys rebrand inexpensive network cards that all have very different internals. The boxes all say "Linksys," but the chip says something else depending on the month of
79
manufacture.
Fortunately, PCI−based systems have sophisticated hardware−recognition systems, and FreeBSD will almost certainly find these devices at boot. If yours is an older ISA system, on the other hand, you might have to dig through the component manual to learn what sort of device you have and how to set IRQs and I/O ports.
The best place to see what hardware your FreeBSD system found is the file /var/run/dmesg.boot, which contains the boottime kernel messages buffer, also known as all that garbage you saw on boot. (There's an example of dmesg.boot in Chapter 3.) If you've never looked at your dmesg.boot file, take a few moments to do so now. You probably never knew that your computer had so much stuff in it!
When looking at the dmesg.boot file, you'll find the device names at the beginning of the dmesg lines. Each piece of hardware has a separate device name, typically a few letters followed by a unit number, such as npx0. The letters are the name of the driver (npx), and each device is numbered, starting with 0. One device might span several lines, and if you have multiple devices, they'll show up with sequential unit numbers.
Your Backup Kernel
A bad kernel can render your system unbootable, so you absolutely must keep a good kernel around at all times. While the kernel install process retains one old kernel, it's easy to overwrite it.
If you don't keep a good, reliable kernel around, here's what can happen: You forget to put a network driver in your current kernel, so you decide to rebuild it. Your rebuilt kernel becomes the current kernel, your previous (imperfect) kernel becomes the old kernel, and your old working kernel goes off to the Land of Oz. When you discover that your new kernel won't keep running for more than a few hours, you'll really regret the loss of that reliable kernel.
A common place to keep a known good kernel is /kernel.good. Back up your working, reliable kernel to /kernel.good before tweaking your kernel, like this:
................................................................
#mkdir modules.good
#cp kernel kernel.good
#cp −R modules/;* modules.good/
................................................................
Note Don't be afraid to keep a variety of kernels on hand. Some people even put kernels in directories named by date, so that they can have a long−running history of kernels. You can have too many kernels on hand, but only if they fill up your root partition.
Editing Kernel Files
You've now backed up your working kernel and are ready to build a new one. To begin, check out /sys/i386/conf, where you should find several files. The important ones for your purposes are GENERIC and LINT. GENERIC is the kernel configuration file for the standard kernel used on first install. LINT contains all kernel options and the documentation for them, including a variety of really obscure ones.
80
Do not edit any of the files you find in /sys/i386/conf directly. Instead, copy GENERIC to a new file and edit the copy, not the original, and name the file after your machine (the most common convention). For example, if you have a server called "webserver," you would do this:
................................................................
# cp GENERIC WEBSERVER
................................................................
Now open the new configuration file in your favorite text editor. Here's a snippet from the part of the GENERIC configuration that covers IDE (aka ATAPI) drives.
................................................................
# ATA and ATAPI devices |
|
|
|
device |
ata0 |
at isa? port IO_WD1 irq 14 |
|
device |
ata1 |
at isa? port IO_WD2 irq 15 |
|
device |
ata |
|
|
device |
atadisk |
|
# ATA disk drives |
device |
atapicd |
|
# ATAPI CDROM drives |
device |
atapifd |
|
# ATAPI floppy drives |
device |
atapist |
|
# ATAPI tape drives |
options |
ATA_STATIC_ID |
#Static device numbering |
................................................................
Each line in the kernel configuration file is either a comment or description of a kernel feature. The pound sign (#) marks comments and the computer ignores them; they're there for your benefit.
Some lines have comments that start in the middle of the line, describing what appears earlier on the line. Lines beginning with "device" are device drivers; in this example, you'll see entries for IDE disks, IDE CD−ROM drives, IDE floppy drives, and IDE tape drives. There are also entries for the actual IDE bus on the motherboard, and for both of its connectors.
Other lines are for software features, or "options." In this example, the option ATA_STATIC_ID enables "static device numbering"; you'll learn what that means in Chapter 16. You'll also see a few special−purpose keywords, such as "pseudo−device" and "cpu," which are either software options or descriptions of hardware.
Because the GENERIC kernel is designed to run on the greatest variety of equipment, it includes a huge array of network drivers, disk drivers, controllers, and features. As a general rule, begin customizing a kernel by commenting out unnecessary entries to shrink and simplify your kernel. Of course, when you streamline the kernel in this way, you'll have to rebuild it when you change your hardware, and if you're one of those folks who constantly swaps hardware in and out, you probably don't want to gut your kernel. On the other hand, if you have a specific server hardware setup and you mass−produce kernels, strip out anything unnecessary.
Your copied kernel configuration file (WEBSERVER, in our example) starts off with comments describing the purpose of the configuration file and containing pointers to the official FreeBSD documentation. Once you skip these comments, the new config file starts with the following:
................................................................
machine |
i386 |
cpu |
I486_CPU |
cpu |
I586_CPU |
cpu |
I686_CPU |
ident |
GENERIC |
81
maxusers 0
................................................................
machine
The machine keyword in the preceding listing describes the system architecture. You really don't want to change this, unless you're building a kernel for your Alpha on an x86.
cpu
The cpu statements describe the on−chip features the kernel can expect to use and support. This is important because newer CPUs provide instructions that others don't. (For example, consider the Pentium versus the Pentium with MMX.)
You only need to include the CPU you have. If you're not sure of the CPU in your hardware, check dmesg.boot. My laptop's dmesg.boot includes the following lines:
................................................................
CPU: Pentium III/Pentium III Xeon/Celeron (497.56−MHz 686−class CPU) Origin = "GenuineIntel" Id = 0x681 Stepping = 1
Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3
6,MMX,FXSR,SSE>
................................................................
The important part of this description is the 686−class CPU at the end of the first line. This tells me that I can remove the cpu statements I486_CPU and I586_CPU to make my kernel smaller and faster. As a result, the kernel will use 686−class CPU−specific optimizations instead of slower generic code.
ident
The ident statement is the kernel's name, which is usually the same as the server name. If you build one kernel and install it on many machines, you might want to give the kernel a name that reflects its purpose, such as WEBSERVER.
maxusers
The maxusers value is a rough value used to compute the size of various in−kernel tables (not the maximum number of users). These in−kernel tables control things such as the number of available network connections and the number of files that can be open at one time.
Beginning with FreeBSD 4.5, the kernel will look at a system's resources and assign a maxusers value that it believes is appropriate for most users. The maxusers 0 entry means the kernel will take the defaults, which will be entirely appropriate for most systems. (You can still hard−code a MAXUSERS value if you wish, however, as I describe below.)
On FreeBSD versions 4.4 and earlier, you needed to hard−code your maxusers value. I typically ran an X−based laptop with a maxusers value of 16, which is fine for my laptop because I'm the only user of the system; no matter how many fancy desktop widgets I fire up, or how many Web pages
82