Add an ASCII copy of the handbook to the system. It can't hurt to have it
authorSascha Wildner <swildner@dragonflybsd.org>
Fri, 14 Jul 2006 21:42:07 +0000 (21:42 +0000)
committerSascha Wildner <swildner@dragonflybsd.org>
Fri, 14 Jul 2006 21:42:07 +0000 (21:42 +0000)
around on the LiveCD. It will be updated periodically.

Also, get rid of the /usr/share/doc/ncurses directory (which we don't use).

Handbook-provided-by: Justin C. Sherrill <justin@shiningsilence.com>
                      (with contributions by many others)

Inclusion-OK'd-by: Matt Dillon

etc/Makefile
etc/mtree/BSD.usr.dist
share/Makefile
share/doc/Makefile
share/doc/handbook/Makefile [new file with mode: 0644]
share/doc/handbook/handbook.txt [new file with mode: 0644]

index c7e8800..a041ecf 100644 (file)
@@ -1,6 +1,6 @@
 #      from: @(#)Makefile      5.11 (Berkeley) 5/21/91
 # $FreeBSD: src/etc/Makefile,v 1.219.2.38 2003/03/04 09:49:00 ru Exp $
-# $DragonFly: src/etc/Makefile,v 1.120 2006/07/08 01:20:29 swildner Exp $
+# $DragonFly: src/etc/Makefile,v 1.121 2006/07/14 21:42:06 swildner Exp $
 
 .if !defined(NO_SENDMAIL)
 SUBDIR=        sendmail
@@ -429,6 +429,7 @@ upgrade_etc:        preupgrade
        rm -f ${DESTDIR}/modules/pcic.ko
        csh -c "rm -f ${DESTDIR}/usr/share/man/{man,cat}4/worm.4.gz"
        rm -f ${DESTDIR}/usr/include/sys/wormio.h
+       rm -rf ${DESTDIR}/usr/share/doc/ncurses
        ldconfig -R
 .if !defined(BINARY_UPGRADE) # binary upgrade just copies these nodes
 .if !defined(NO_MAKEDEV)
index 6b1930e..f736ab1 100644 (file)
@@ -1,5 +1,5 @@
 # $FreeBSD: src/etc/mtree/BSD.usr.dist,v 1.188.2.40 2003/02/14 22:38:14 nectar Exp $
-# $DragonFly: src/etc/mtree/BSD.usr.dist,v 1.42 2006/05/20 18:26:27 dillon Exp $
+# $DragonFly: src/etc/mtree/BSD.usr.dist,v 1.43 2006/07/14 21:42:06 swildner Exp $
 #
 # Please see the file src/etc/mtree/README before making changes to this file.
 #
         dict
         ..
         doc
-            ncurses
+            handbook
             ..
         ..
         examples
index a8c7052..1bc9d78 100644 (file)
@@ -1,10 +1,10 @@
 #      @(#)Makefile    8.1 (Berkeley) 6/5/93
 # $FreeBSD: src/share/Makefile,v 1.22.2.4 2002/03/12 17:13:32 phantom Exp $
-# $DragonFly: src/share/Makefile,v 1.4 2005/04/21 16:36:35 joerg Exp $
+# $DragonFly: src/share/Makefile,v 1.5 2006/07/14 21:42:07 swildner Exp $
 
 # Do not include `info' in the SUBDIR list, it is handled separately.
 
-SUBDIR= colldef dict examples i18n locale man me misc mk monetdef \
+SUBDIR= colldef dict doc examples i18n locale man me misc mk monetdef \
        msgdef numericdef skel syscons tabset termcap timedef zoneinfo
 
 .if !defined(NO_I4B)
index 0f118b4..5d5142b 100644 (file)
@@ -1,8 +1,8 @@
 #      From: @(#)Makefile      8.1 (Berkeley) 6/5/93
 # $FreeBSD: src/share/doc/Makefile,v 1.15.2.1 2000/11/24 14:09:33 ru Exp $
-# $DragonFly: src/share/doc/Makefile,v 1.3 2005/03/13 18:05:53 joerg Exp $
+# $DragonFly: src/share/doc/Makefile,v 1.4 2006/07/14 21:42:07 swildner Exp $
 
-SUBDIR=        IPv6
+SUBDIR=        handbook
 
 # Default output formats are ascii for troff documents, and 
 # ascii and html for sgml documents.  
diff --git a/share/doc/handbook/Makefile b/share/doc/handbook/Makefile
new file mode 100644 (file)
index 0000000..eaed61c
--- /dev/null
@@ -0,0 +1,7 @@
+# $DragonFly: src/share/doc/handbook/Attic/Makefile,v 1.1 2006/07/14 21:42:07 swildner Exp $
+
+NOOBJ=         noobj
+FILES=         handbook.txt
+FILESDIR=      ${SHAREDIR}/doc/handbook
+
+.include <bsd.prog.mk>
diff --git a/share/doc/handbook/handbook.txt b/share/doc/handbook/handbook.txt
new file mode 100644 (file)
index 0000000..58f7093
--- /dev/null
@@ -0,0 +1,34914 @@
+$DragonFly: src/share/doc/handbook/Attic/handbook.txt,v 1.1 2006/07/14 21:42:07 swildner Exp $
+
+                               DragonFly Handbook
+
+  The DragonFly Documentation Project
+
+   Copyright (c) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
+   The FreeBSD Documentation Project
+
+   Copyright (c) 2004, 2005, 2006 The DragonFly Documentation Project
+
+   Welcome to DragonFly! This handbook covers the installation and day to day
+   use of the DragonFly operating system. This manual is a work in progress
+   and is the work of many individuals. Many sections do not yet exist and
+   some of those that do exist need to be updated. If you are interested in
+   helping with this project, send email to the DragonFly Documentation
+   project mailing list. The latest version of this document is always
+   available from the DragonFly web site or mirror sites, in a variety of
+   formats.
+
+   Portions of this document originally documented use of the FreeBSD
+   operating system. While many functions should be similar on DragonFly,
+   some differences should be expected. If you find instructions here that no
+   longer apply to DragonFly, please contact the documentation mailing list
+   at DragonFly Documentation project mailing list .
+
+   Redistribution and use in source (SGML DocBook) and 'compiled' forms
+   (SGML, HTML, PDF, PostScript, RTF and so forth) with or without
+   modification, are permitted provided that the following conditions are
+   met:
+
+    1. Redistributions of source code (SGML DocBook) must retain the above
+       copyright notice, this list of conditions and the following disclaimer
+       as the first lines of this file unmodified.
+
+    2. Redistributions in compiled form (transformed to other DTDs, converted
+       to PDF, PostScript, RTF and other formats) must reproduce the above
+       copyright notice, this list of conditions and the following disclaimer
+       in the documentation and/or other materials provided with the
+       distribution.
+
+     Important: THIS DOCUMENTATION IS PROVIDED BY THE DRAGONFLYBSD PROJECT
+     "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+     LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+     PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE DRAGONFLYBSD
+     PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+     EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+     PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+     PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+     LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+     NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+     DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+   DragonFlyBSD is a registered trademark of the DragonFlyBSD Project.
+
+   FreeBSD is a registered trademark of Wind River Systems, Inc. This is
+   expected to change soon.
+
+   NetBSD is a registered trademark of The NetBSD Foundation, Inc.
+
+   3Com and HomeConnect are registered trademarks of 3Com Corporation.
+
+   3ware and Escalade are registered trademarks of 3ware Inc.
+
+   ARM is a registered trademark of ARM Limited.
+
+   Adaptec is a registered trademark of Adaptec, Inc.
+
+   Adobe, Acrobat, Acrobat Reader, and PostScript are either registered
+   trademarks or trademarks of Adobe Systems Incorporated in the United
+   States and/or other countries.
+
+   Apple, FireWire, Mac, Macintosh, Mac OS, Quicktime, and TrueType are
+   trademarks of Apple Computer, Inc., registered in the United States and
+   other countries.
+
+   Corel and WordPerfect are trademarks or registered trademarks of Corel
+   Corporation and/or its subsidiaries in Canada, the United States and/or
+   other countries.
+
+   Sound Blaster is a trademark of Creative Technology Ltd. in the United
+   States and/or other countries.
+
+   CVSup is a registered trademark of John D. Polstra.
+
+   Heidelberg, Helvetica, Palatino, and Times Roman are either registered
+   trademarks or trademarks of Heidelberger Druckmaschinen AG in the U.S. and
+   other countries.
+
+   IBM, AIX, EtherJet, Netfinity, OS/2, PowerPC, PS/2, S/390, and ThinkPad
+   are trademarks of International Business Machines Corporation in the
+   United States, other countries, or both.
+
+   IEEE, POSIX, and 802 are registered trademarks of Institute of Electrical
+   and Electronics Engineers, Inc. in the United States.
+
+   Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are
+   trademarks or registered trademarks of Intel Corporation or its
+   subsidiaries in the United States and other countries.
+
+   Intuit and Quicken are registered trademarks and/or registered service
+   marks of Intuit Inc., or one of its subsidiaries, in the United States and
+   other countries.
+
+   Linux is a registered trademark of Linus Torvalds in the United States.
+
+   LSI Logic, AcceleRAID, eXtremeRAID, MegaRAID and Mylex are trademarks or
+   registered trademarks of LSI Logic Corp.
+
+   M-Systems and DiskOnChip are trademarks or registered trademarks of
+   M-Systems Flash Disk Pioneers, Ltd.
+
+   Macromedia, Flash, and Shockwave are trademarks or registered trademarks
+   of Macromedia, Inc. in the United States and/or other countries.
+
+   Microsoft, FrontPage, MS-DOS, Outlook, Windows, Windows Media, and Windows
+   NT are either registered trademarks or trademarks of Microsoft Corporation
+   in the United States and/or other countries.
+
+   Netscape and the Netscape Navigator are registered trademarks of Netscape
+   Communications Corporation in the U.S. and other countries.
+
+   GateD and NextHop are registered and unregistered trademarks of NextHop in
+   the U.S. and other countries.
+
+   Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The
+   Open Group are trademarks of The Open Group in the United States and other
+   countries.
+
+   Oracle is a registered trademark of Oracle Corporation.
+
+   pkgsrc is a registered trademark of The NetBSD Foundation, Inc.
+
+   PowerQuest and PartitionMagic are registered trademarks of PowerQuest
+   Corporation in the United States and/or other countries.
+
+   RealNetworks, RealPlayer, and RealAudio are the registered trademarks of
+   RealNetworks, Inc.
+
+   Red Hat, RPM, are trademarks or registered trademarks of Red Hat, Inc. in
+   the United States and other countries.
+
+   SAP, R/3, and mySAP are trademarks or registered trademarks of SAP AG in
+   Germany and in several other countries all over the world.
+
+   Sun, Sun Microsystems, Java, Java Virtual Machine, JavaServer Pages, JDK,
+   JSP, JVM, Netra, Solaris, StarOffice, Sun Blade, Sun Enterprise, Sun Fire,
+   SunOS, and Ultra are trademarks or registered trademarks of Sun
+   Microsystems, Inc. in the United States and other countries.
+
+   Symantec and Ghost are registered trademarks of Symantec Corporation in
+   the United States and other countries.
+
+   MATLAB is a registered trademark of The MathWorks, Inc.
+
+   SpeedTouch is a trademark of Thomson
+
+   U.S. Robotics and Sportster are registered trademarks of U.S. Robotics
+   Corporation.
+
+   VMware is a trademark of VMware, Inc.
+
+   Waterloo Maple and Maple are trademarks or registered trademarks of
+   Waterloo Maple Inc.
+
+   Mathematica is a registered trademark of Wolfram Research, Inc.
+
+   XFree86 is a trademark of The XFree86 Project, Inc.
+
+   Ogg Vorbis and Xiph.Org are trademarks of Xiph.Org.
+
+   Many of the designations used by manufacturers and sellers to distinguish
+   their products are claimed as trademarks. Where those designations appear
+   in this document, and the FreeBSD Project was aware of the trademark
+   claim, the designations have been followed by the ``(TM)'' or the ``(R)''
+   symbol.
+
+     ----------------------------------------------------------------------
+
+   Table of Contents
+
+   Preface
+
+   I. Getting Started
+
+                1 Introduction
+
+                             1.1 Synopsis
+
+                             1.2 Welcome to DragonFly!
+
+                             1.3 About the DragonFly Project
+
+                2 Installation from CD
+
+                             2.1 CD Installation Overview
+
+                             2.2 CD Installation - Making room
+
+                             2.3 CD Installation - Disk setup
+
+                             2.4 Installing to Disk from CD
+
+                             2.5 CD Installation - Post-install cleanup
+
+                             2.6 CD Installation - New system setup
+
+                3 UNIX Basics
+
+                             3.1 Synopsis
+
+                             3.2 Virtual Consoles and Terminals
+
+                             3.3 Permissions
+
+                             3.4 Directory Structure
+
+                             3.5 Disk Organization
+
+                             3.6 Mounting and Unmounting File Systems
+
+                             3.7 Processes
+
+                             3.8 Daemons, Signals, and Killing Processes
+
+                             3.9 Shells
+
+                             3.10 Text Editors
+
+                             3.11 Devices and Device Nodes
+
+                             3.12 Binary Formats
+
+                             3.13 For More Information
+
+                4 Installing Applications using NetBSD's pkgsrc framework
+
+                             4.1 Synopsis
+
+                             4.2 Overview of Software Installation
+
+                             4.3 Finding Your Application
+
+                             4.4 Using the Binary Packages System
+
+                             4.5 Using the pkgsrc(R) Source Tree
+
+                             4.6 Post-installation Activities
+
+                             4.7 Dealing with Broken Packages
+
+                5 The X Window System
+
+                             5.1 Synopsis
+
+                             5.2 Understanding X
+
+                             5.3 Installing XFree86(TM)
+
+                             5.4 XFree86 Configuration
+
+                             5.5 Using Fonts in XFree86
+
+                             5.6 The X Display Manager
+
+                             5.7 Desktop Environments
+
+   II. System Administration
+
+                6 Configuration and Tuning
+
+                             6.1 Synopsis
+
+                             6.2 Initial Configuration
+
+                             6.3 Core Configuration
+
+                             6.4 Application Configuration
+
+                             6.5 Starting Services
+
+                             6.6 Configuring the cron Utility
+
+                             6.7 Using rc under DragonFly
+
+                             6.8 Setting Up Network Interface Cards
+
+                             6.9 Virtual Hosts
+
+                             6.10 Configuration Files
+
+                             6.11 Tuning with sysctl
+
+                             6.12 Tuning Disks
+
+                             6.13 Tuning Kernel Limits
+
+                             6.14 Adding Swap Space
+
+                             6.15 Power and Resource Management
+
+                             6.16 Using and Debugging DragonFly ACPI
+
+                7 The DragonFly Booting Process
+
+                             7.1 Synopsis
+
+                             7.2 The Booting Problem
+
+                             7.3 The Boot Manager and Boot Stages
+
+                             7.4 Kernel Interaction During Boot
+
+                             7.5 Init: Process Control Initialization
+
+                             7.6 Shutdown Sequence
+
+                8 Users and Basic Account Management
+
+                             8.1 Synopsis
+
+                             8.2 Introduction
+
+                             8.3 The Superuser Account
+
+                             8.4 System Accounts
+
+                             8.5 User Accounts
+
+                             8.6 Modifying Accounts
+
+                             8.7 Limiting Users
+
+                             8.8 Personalizing Users
+
+                             8.9 Groups
+
+                9 Configuring the DragonFly Kernel
+
+                             9.1 Synopsis
+
+                             9.2 Why Build a Custom Kernel?
+
+                             9.3 Building and Installing a Custom Kernel
+
+                             9.4 The Configuration File
+
+                             9.5 Making Device Nodes
+
+                             9.6 If Something Goes Wrong
+
+                10 Security
+
+                             10.1 Synopsis
+
+                             10.2 Introduction
+
+                             10.3 Securing DragonFly
+
+                             10.4 DES, MD5, and Crypt
+
+                             10.5 One-time Passwords
+
+                             10.6 Kerberos5
+
+                             10.7 Firewalls
+
+                             10.8 OpenSSL
+
+                             10.9 VPN over IPsec
+
+                             10.10 OpenSSH
+
+                11 Printing
+
+                             11.1 Synopsis
+
+                             11.2 Introduction
+
+                             11.3 Basic Setup
+
+                             11.4 Advanced Printer Setup
+
+                             11.5 Using Printers
+
+                             11.6 Alternatives to the Standard Spooler
+
+                             11.7 Troubleshooting
+
+                12 Storage
+
+                             12.1 Synopsis
+
+                             12.2 Device Names
+
+                             12.3 Adding Disks
+
+                             12.4 RAID
+
+                             12.5 Creating and Using Optical Media (CDs)
+
+                             12.6 Creating and Using Optical Media (DVDs)
+
+                             12.7 Creating and Using Floppy Disks
+
+                             12.8 Creating and Using Data Tapes
+
+                             12.9 Backups to Floppies
+
+                             12.10 Backup Basics
+
+                             12.11 Network, Memory, and File-Backed File
+                             Systems
+
+                             12.12 File System Quotas
+
+                13 The Vinum Volume Manager
+
+                             13.1 Synopsis
+
+                             13.2 Disks Are Too Small
+
+                             13.3 Access Bottlenecks
+
+                             13.4 Data Integrity
+
+                             13.5 Vinum Objects
+
+                             13.6 Some Examples
+
+                             13.7 Object Naming
+
+                             13.8 Configuring Vinum
+
+                             13.9 Using Vinum for the Root Filesystem
+
+                14 Localization - I18N/L10N Usage and Setup
+
+                             14.1 Synopsis
+
+                             14.2 The Basics
+
+                             14.3 Using Localization
+
+                             14.4 Compiling I18N Programs
+
+                             14.5 Localizing DragonFly to Specific Languages
+
+                15 Desktop Applications
+
+                             15.1 Synopsis
+
+                             15.2 Browsers
+
+                             15.3 Productivity
+
+                             15.4 Document Viewers
+
+                             15.5 Finance
+
+                             15.6 Summary
+
+                16 Multimedia
+
+                             16.1 Synopsis
+
+                             16.2 Setting Up the Sound Card
+
+                             16.3 MP3 Audio
+
+                             16.4 Video Playback
+
+                             16.5 Setting Up TV Cards
+
+                17 Serial Communications
+
+                             17.1 Synopsis
+
+                             17.2 Introduction
+
+                             17.3 Terminals
+
+                             17.4 Dial-in Service
+
+                             17.5 Dial-out Service
+
+                             17.6 Setting Up the Serial Console
+
+                18 PPP and SLIP
+
+                             18.1 Synopsis
+
+                             18.2 Using User PPP
+
+                             18.3 Using Kernel PPP
+
+                             18.4 Troubleshooting PPP Connections
+
+                             18.5 Using PPP over Ethernet (PPPoE)
+
+                             18.6 Using SLIP
+
+                19 Advanced Networking
+
+                             19.1 Synopsis
+
+                             19.2 Gateways and Routes
+
+                             19.3 Wireless Networking
+
+                             19.4 Bluetooth
+
+                             19.5 Bridging
+
+                             19.6 NFS
+
+                             19.7 Diskless Operation
+
+                             19.8 ISDN
+
+                             19.9 NIS/YP
+
+                             19.10 DHCP
+
+                             19.11 DNS
+
+                             19.12 NTP
+
+                             19.13 Network Address Translation
+
+                             19.14 The inetd ``Super-Server''
+
+                             19.15 Parallel Line IP (PLIP)
+
+                             19.16 IPv6
+
+                20 Electronic Mail
+
+                             20.1 Synopsis
+
+                             20.2 Using Electronic Mail
+
+                             20.3 sendmail Configuration
+
+                             20.4 Changing Your Mail Transfer Agent
+
+                             20.5 Troubleshooting
+
+                             20.6 Advanced Topics
+
+                             20.7 SMTP with UUCP
+
+                             20.8 Setting up to send only
+
+                             20.9 Using Mail with a Dialup Connection
+
+                             20.10 SMTP Authentication
+
+                             20.11 Mail User Agents
+
+                             20.12 Using fetchmail
+
+                             20.13 Using procmail
+
+                21 Updating DragonFly
+
+                             21.1 Initial Setup
+
+                             21.2 Configuration
+
+                             21.3 Preparing to Update
+
+                             21.4 Updating the System
+
+                22 Linux Binary Compatibility
+
+                             22.1 Synopsis
+
+                             22.2 Installation
+
+                             22.3 Installing Mathematica(R)
+
+                             22.4 Installing Maple(TM)
+
+                             22.5 Installing MATLAB(R)
+
+                             22.6 Installing Oracle(R)
+
+                             22.7 Installing SAP(R) R/3(R)
+
+                             22.8 Advanced Topics
+
+   III. Appendices
+
+                A. Obtaining DragonFly
+
+                             A.1 CDROM and DVD Publishers
+
+                             A.2 FTP Sites
+
+                             A.3 Using CVSup
+
+                             A.4 CVS Tags
+
+                B. Bibliography
+
+                             B.1 Books & Magazines Specific to BSD
+
+                             B.2 Users' Guides
+
+                             B.3 Administrators' Guides
+
+                             B.4 Programmers' Guides
+
+                             B.5 Operating System Internals
+
+                             B.6 Security Reference
+
+                             B.7 Hardware Reference
+
+                             B.8 UNIX History
+
+                             B.9 Magazines and Journals
+
+                C. Resources on the Internet
+
+                             C.1 Mailing Lists
+
+                             C.2 Usenet Newsgroups
+
+                             C.3 World Wide Web Servers
+
+                D. PGP Keys
+
+                             D.1 Developers
+
+   Colophon
+
+   List of Tables
+
+   3-1. Disk Device Codes
+
+   12-1. Physical Disk Naming Conventions
+
+   13-1. Vinum Plex Organizations
+
+   19-1. Wiring a Parallel Cable for Networking
+
+   19-2. Reserved IPv6 addresses
+
+   List of Figures
+
+   13-1. Concatenated Organization
+
+   13-2. Striped Organization
+
+   13-3. RAID-5 Organization
+
+   13-4. A Simple Vinum Volume
+
+   13-5. A Mirrored Vinum Volume
+
+   13-6. A Striped Vinum Volume
+
+   13-7. A Mirrored, Striped Vinum Volume
+
+   List of Examples
+
+   3-1. Sample Disk, Slice, and Partition Names
+
+   3-2. Conceptual Model of a Disk
+
+   4-1. Downloading a Package Manually and Installing It Locally
+
+   6-1. Creating a Swapfile
+
+   7-1. boot0 Screenshot
+
+   7-2. boot2 Screenshot
+
+   7-3. An Insecure Console in /etc/ttys
+
+   8-1. Configuring adduser and adding a user
+
+   8-2. rmuser Interactive Account Removal
+
+   8-3. Interactive chpass by Superuser
+
+   8-4. Interactive chpass by Normal User
+
+   8-5. Changing Your Password
+
+   8-6. Changing Another User's Password as the Superuser
+
+   8-7. Adding a Group Using pw(8)
+
+   8-8. Adding Somebody to a Group Using pw(8)
+
+   8-9. Using id(1) to Determine Group Membership
+
+   10-1. Using SSH to Create a Secure Tunnel for SMTP
+
+   12-1. Using dump over ssh
+
+   12-2. Using dump over ssh with RSH set
+
+   12-3. A Script for Creating a Bootable Floppy
+
+   12-4. Using vnconfig to Mount an Existing File System Image
+
+   12-5. Creating a New File-Backed Disk with vnconfig
+
+   12-6. md Memory Disk
+
+   17-1. Adding Terminal Entries to /etc/ttys
+
+   19-1. Mounting an Export with amd
+
+   19-2. Branch Office or Home Network
+
+   19-3. Head Office or Other LAN
+
+   19-4. Sending inetd a HangUP Signal
+
+   20-1. Configuring the sendmail Access Database
+
+   20-2. Mail Aliases
+
+   20-3. Example Virtual Domain Mail Map
+
+     ----------------------------------------------------------------------
+
+                                    Preface
+
+Intended Audience
+
+   The DragonFly newcomer will find that the first section of this book
+   guides the user through the DragonFly installation process and gently
+   introduces the concepts and conventions that underpin UNIX(R). Working
+   through this section requires little more than the desire to explore, and
+   the ability to take on board new concepts as they are introduced.
+
+   Once you have travelled this far, the second, far larger, section of the
+   Handbook is a comprehensive reference to all manner of topics of interest
+   to DragonFly system administrators. Some of these chapters may recommend
+   that you do some prior reading, and this is noted in the synopsis at the
+   beginning of each chapter.
+
+   For a list of additional sources of information, please see Appendix B.
+
+Organization of This Book
+
+   This book is split into three logically distinct sections. The first
+   section, Getting Started, covers the installation and basic usage of
+   DragonFly. It is expected that the reader will follow these chapters in
+   sequence, possibly skipping chapters covering familiar topics. The second
+   section, System Administration, covers a broad collection of subjects that
+   are of interest to more advanced DragonFly users. Each section begins with
+   a succinct synopsis that describes what the chapter covers and what the
+   reader is expected to already know. This is meant to allow the casual
+   reader to skip around to find chapters of interest. The third section
+   contains appendices of reference information.
+
+   Chapter 1, Introduction
+
+           Introduces DragonFly to a new user. It describes the history of
+           the DragonFly Project, its goals and development model.
+
+   Chapter 2, Installation
+
+           Walks a user through the entire installation process. Some
+           advanced installation topics, such as installing through a serial
+           console, are also covered.
+
+   Chapter 3, UNIX Basics
+
+           Covers the basic commands and functionality of the DragonFly
+           operating system. If you are familiar with Linux or another flavor
+           of UNIX then you can probably skip this chapter.
+
+   Chapter 4, Installing Applications
+
+           Covers the installation of third-party software using NetBSD(R)'s
+           Packages Collection pkgsrc(R).
+
+   Chapter 5, The X Window System
+
+           Describes the X Window System in general and using XFree86(TM) and
+           X.org on DragonFly in particular. Also describes common desktop
+           environments such as KDE and GNOME.
+
+   Chapter 6, Configuration and Tuning
+
+           Describes the parameters available for system administrators to
+           tune a DragonFly system for optimum performance. Also describes
+           the various configuration files used in DragonFly and where to
+           find them.
+
+   Chapter 7, Booting Process
+
+           Describes the DragonFly boot process and explains how to control
+           this process with configuration options.
+
+   Chapter 8, Users and Basic Account Management
+
+           Describes the creation and manipulation of user accounts. Also
+           discusses resource limitations that can be set on users and other
+           account management tasks.
+
+   Chapter 9, Configuring the DragonFly Kernel
+
+           Explains why you might need to configure a new kernel and provides
+           detailed instructions for configuring, building, and installing a
+           custom kernel.
+
+   Chapter 10, Security
+
+           Describes many different tools available to help keep your
+           DragonFly system secure, including Kerberos, IPsec, OpenSSH, and
+           network firewalls.
+
+   Chapter 11, Printing
+
+           Describes managing printers on DragonFly, including information
+           about banner pages, printer accounting, and initial setup.
+
+   Chapter 12, Storage
+
+           Describes how to manage storage media and filesystems with
+           DragonFly. This includes physical disks, RAID arrays, optical and
+           tape media, memory-backed disks, and network filesystems.
+
+   Chapter 13, Vinum
+
+           Describes how to use Vinum, a logical volume manager which
+           provides device-independent logical disks, and software RAID-0,
+           RAID-1 and RAID-5.
+
+   Chapter 14, Localization
+
+           Describes how to use DragonFly in languages other than English.
+           Covers both system and application level localization.
+
+   Chapter 15, Desktop Applications
+
+           Lists some common desktop applications, such as web browsers and
+           productivity suites, and describes how to install them on
+           DragonFly.
+
+   Chapter 16, Multimedia
+
+           Shows how to set up sound and video playback support for your
+           system. Also describes some sample audio and video applications.
+
+   Chapter 17, Serial Communications
+
+           Explains how to connect terminals and modems to your DragonFly
+           system for both dial in and dial out connections.
+
+   Chapter 18, PPP and SLIP
+
+           Describes how to use PPP, SLIP, or PPP over Ethernet to connect to
+           remote systems with DragonFly.
+
+   Chapter 19, Advanced Networking
+
+           Describes many networking topics, including sharing an Internet
+           connection with other computers on your LAN, using network
+           filesystems, sharing account information via NIS, setting up a
+           name server, and much more.
+
+   Chapter 20, Electronic Mail
+
+           Explains the different components of an email server and dives
+           into simple configuration topics for the most popular mail server
+           software: sendmail.
+
+   Section 21.1, Updating DragonFly
+
+           Describes the development paths of DragonFly, and how to stay
+           up-to-date.
+
+   Chapter 22, Linux Binary Compatibility
+
+           Describes the Linux compatibility features of DragonFly. Also
+           provides detailed installation instructions for many popular Linux
+           applications such as Oracle(R), SAP(R) R/3(R), and Mathematica(R).
+
+   Appendix A, Obtaining DragonFly
+
+           Lists different sources for obtaining DragonFly media on CDROM or
+           DVD as well as different sites on the Internet that allow you to
+           download and install DragonFly.
+
+   Appendix B, Bibliography
+
+           This book touches on many different subjects that may leave you
+           hungry for a more detailed explanation. The bibliography lists
+           many excellent books that are referenced in the text.
+
+   Appendix C, Resources on the Internet
+
+           Describes the many forums available for DragonFly users to post
+           questions and engage in technical conversations about DragonFly.
+
+   Appendix D, PGP Keys
+
+           Lists the PGP fingerprints of several DragonFly Developers.
+
+Conventions used in this book
+
+   To provide a consistent and easy to read text, several conventions are
+   followed throughout the book.
+
+  Typographic Conventions
+
+   Italic
+
+           An italic font is used for filenames, URLs, emphasized text, and
+           the first usage of technical terms.
+
+   Monospace
+
+           A monospaced font is used for error messages, commands,
+           environment variables, names of ports, hostnames, user names,
+           group names, device names, variables, and code fragments.
+
+   Bold
+
+           A bold font is used for applications, commands, and keys.
+
+  User Input
+
+   Keys are shown in bold to stand out from other text. Key combinations that
+   are meant to be typed simultaneously are shown with `+' between the keys,
+   such as:
+
+   Ctrl+Alt+Del
+
+   Meaning the user should type the Ctrl, Alt,and Del keys at the same time.
+
+   Keys that are meant to be typed in sequence will be separated with commas,
+   for example:
+
+   Ctrl+X, Ctrl+S
+
+   Would mean that the user is expected to type the Ctrl and X keys
+   simultaneously and then to type the Ctrl and S keys simultaneously.
+
+  Examples
+
+   Examples starting with # indicate a command that must be invoked as the
+   superuser in DragonFly. You can login as root to type the command, or
+   login as your normal account and use su(1) to gain superuser privileges.
+
+ # dd if=kern.flp of=/dev/fd0
+
+   Examples starting with % indicate a command that should be invoked from a
+   normal user account. Unless otherwise noted, C-shell syntax is used for
+   setting environment variables and other shell commands.
+
+ % top
+
+   Examples starting with E:\> indicate a MS-DOS(R) command. Unless otherwise
+   noted, these commands may be executed from a ``Command Prompt'' window in
+   a modern Microsoft(R) Windows(R) environment.
+
+ E:\> tools\fdimage floppies\kern.flp A:
+
+Acknowledgments
+
+   The book you are holding represents the efforts of many hundreds of people
+   around the world. Whether they sent in fixes for typos, or submitted
+   complete chapters, all the contributions have been useful.
+
+   The DragonFly Handbook was originally built from an edition of the FreeBSD
+   Handbook. The FreeBSD Handbook was created by the collective hard work of
+   hundreds of people, and the DragonFly Documentation Team appreciates all
+   their labor. Included here is a list of all individually identified people
+   and corporations that contributed resources to this handbook.
+
+   Eric Anderson, Satoshi Asami, Bojan Bistrovic, Neil Blakey-Milner, Andrew
+   Boothman, Harti Brandt, Jim Brown, BSDi, Andrey A. Chernov, Peter Childs,
+   Munish Chopra, Joe Marcus Clarke, Nik Clayton, Mark Dapoz, Matt Dillon,
+   Jean-Franc,ois Dockes, Alex Dupre, Josef El-Rayes, Udo Erdelhoff, Marc
+   Fonvieille, Dirk Fro:mberg, Robert Getschmann, James Gorham, Lucky Green,
+   Coranth Gryphon, Jake Hamby, Brian N. Handy, Guy Helmer, Al Hoang, Tillman
+   Hodgson, Jordan Hubbard, Robert Huff, Tom Hukins, Christophe Juniet,
+   Poul-Henning Kamp, Aaron Kaplan, Martin Karlsson, Sean Kelly, Seth
+   Kingsley, Holger Kipp, Nate Lawson, Chern Lee, Greg Lehey, John Lind, Ross
+   Lippert, Bill Lloyd, Pav Lucistnik, Julio Merino, Mike Meyer, Hellmuth
+   Michaelis, Jim Mock, Marcel Moolenaar, Moses Moore, Bill Moran, Rich
+   Murphey, Mark Murray, Alex Nash, Gregory Neil Shapiro, David O'Brien, Eric
+   Ogren, Gary Palmer, Hiten M. Pandya, Bill Paul, Dan Pelleg, Steve
+   Peterson, John Polstra, Andy Polyakov, Randy Pratt, Jeremy C. Reed, Tom
+   Rhodes, Trev Roydhouse, Peter Schultz, Piero Serini, Christopher Shumway,
+   Marc Silver, Mike Smith, Brian Somers, Gennady B. Sorokopud, Wylie
+   Stilwell, Murray Stokely, Greg Sutter, Bill Swingle, Valentino Vaschetto,
+   Robert Watson, Wind River Systems, Michael C. Wu, and Kazutaka YOKOTA.
+
+                               I. Getting Started
+
+   This part of the DragonFly Handbook is for users and administrators who
+   are new to DragonFly. These chapters:
+
+     * Introduce you to DragonFly.
+
+     * Guide you through the installation process.
+
+     * Teach you UNIX basics and fundamentals.
+
+     * Show you how to install the wealth of third party applications
+       available for DragonFly.
+
+     * Introduce you to X, the UNIX windowing system, and detail how to
+       configure a desktop environment that makes you more productive.
+
+   We have tried to keep the number of forward references in the text to a
+   minimum so that you can read this section of the Handbook from front to
+   back with the minimum page flipping required.
+
+   Table of Contents
+
+   1 Introduction
+
+   2 Installation from CD
+
+   3 UNIX Basics
+
+   4 Installing Applications using NetBSD's pkgsrc framework
+
+   5 The X Window System
+
+     ----------------------------------------------------------------------
+
+                             Chapter 1 Introduction
+
+   Restructured, reorganized, and parts rewritten by Jim Mock.
+
+1.1 Synopsis
+
+   Thank you for your interest in DragonFly! The following chapter covers
+   various aspects of the DragonFly Project, such as its history, goals,
+   development model, and so on.
+
+   After reading this chapter, you will know:
+
+     * How DragonFly relates to other computer operating systems.
+
+     * The history of the DragonFly Project.
+
+     * The goals of the DragonFly Project.
+
+     * The basics of the DragonFly open-source development model.
+
+     * And of course: where the name ``DragonFly'' comes from.
+
+     ----------------------------------------------------------------------
+
+1.2 Welcome to DragonFly!
+
+   DragonFly is a 4.4BSD-Lite based operating system for Intel (x86). A port
+   to AMD64 is in progress. You can also read about the history of DragonFly,
+   or the current release.
+
+     ----------------------------------------------------------------------
+
+  1.2.1 What Can DragonFly Do?
+
+   DragonFly has many noteworthy features. Some of these are:
+
+     * Preemptive multitasking with dynamic priority adjustment to ensure
+       smooth and fair sharing of the computer between applications and
+       users, even under the heaviest of loads.
+
+     * Multi-user facilities which allow many people to use a DragonFly
+       system simultaneously for a variety of things. This means, for
+       example, that system peripherals such as printers and tape drives are
+       properly shared between all users on the system or the network and
+       that individual resource limits can be placed on users or groups of
+       users, protecting critical system resources from over-use.
+
+     * Strong TCP/IP networking with support for industry standards such as
+       SLIP, PPP, NFS, DHCP, and NIS. This means that your DragonFly machine
+       can interoperate easily with other systems as well as act as an
+       enterprise server, providing vital functions such as NFS (remote file
+       access) and email services or putting your organization on the
+       Internet with WWW, FTP, routing and firewall (security) services.
+
+     * Memory protection ensures that applications (or users) cannot
+       interfere with each other. One application crashing will not affect
+       others in any way.
+
+     * DragonFly is a 32-bit operating system.
+
+     * The industry standard X Window System (X11R6) provides a graphical
+       user interface (GUI) for the cost of a common VGA card and monitor and
+       comes with full sources.
+
+     * Binary compatibility with many programs built for Linux, SCO, SVR4,
+       BSDI and NetBSD.
+
+     * Thousands of ready-to-run applications are available from the pkgsrc
+       packages collection. Why search the net when you can find it all right
+       here?
+
+     * Thousands of additional and easy-to-port applications are available on
+       the Internet. DragonFly is source code compatible with most popular
+       commercial UNIX systems and thus most applications require few, if
+       any, changes to compile.
+
+     * Demand paged virtual memory and ``merged VM/buffer cache'' design
+       efficiently satisfies applications with large appetites for memory
+       while still maintaining interactive response to other users.
+
+     * SMP support for machines with multiple CPUs.
+
+     * A full complement of C, C++, Fortran, and Perl development tools. Many
+       additional languages for advanced research and development are also
+       available in the ports and packages collection.
+
+     * Source code for the entire system means you have the greatest degree
+       of control over your environment. Why be locked into a proprietary
+       solution at the mercy of your vendor when you can have a truly open
+       system?
+
+     * Extensive online documentation.
+
+     * And many more!
+
+   DragonFly is based on the 4.4BSD-Lite release from Computer Systems
+   Research Group (CSRG) at the University of California at Berkeley, along
+   with later development of FreeBSD by the FreeBSD Project. It carries on
+   the distinguished tradition of BSD systems development. In addition to the
+   fine work provided by CSRG, the DragonFly Project has put in many
+   thousands of hours in fine tuning the system for maximum performance and
+   reliability in real-life load situations. As many of the commercial giants
+   struggle to field PC operating systems with such features, performance and
+   reliability, DragonFly can offer them now!
+
+   The applications to which DragonFly can be put are truly limited only by
+   your own imagination. From software development to factory automation,
+   inventory control to azimuth correction of remote satellite antennae; if
+   it can be done with a commercial UNIX product then it is more than likely
+   that you can do it with DragonFly too! DragonFly also benefits
+   significantly from literally thousands of high quality applications
+   developed by research centers and universities around the world, often
+   available at little to no cost. Commercial applications are also available
+   and appearing in greater numbers every day.
+
+   Because the source code for DragonFly itself is generally available, the
+   system can also be customized to an almost unheard of degree for special
+   applications or projects, and in ways not generally possible with
+   operating systems from most major commercial vendors. Here is just a
+   sampling of some of the applications in which people are currently using
+   DragonFly:
+
+     * Internet Services: The robust TCP/IP networking built into DragonFly
+       makes it an ideal platform for a variety of Internet services such as:
+
+          * FTP servers
+
+          * World Wide Web servers (standard or secure [SSL])
+
+          * Firewalls and NAT (``IP masquerading'') gateways
+
+          * Electronic Mail servers
+
+          * USENET News or Bulletin Board Systems
+
+          * And more...
+
+       With DragonFly, you can easily start out small with an inexpensive 386
+       class PC and upgrade all the way up to a quad-processor Xeon with RAID
+       storage as your enterprise grows.
+
+     * Education: Are you a student of computer science or a related
+       engineering field? There is no better way of learning about operating
+       systems, computer architecture and networking than the hands on, under
+       the hood experience that DragonFly can provide. A number of freely
+       available CAD, mathematical and graphic design packages also make it
+       highly useful to those whose primary interest in a computer is to get
+       other work done!
+
+     * Research: With source code for the entire system available, DragonFly
+       is an excellent platform for research in operating systems as well as
+       other branches of computer science. DragonFly's freely available
+       nature also makes it possible for remote groups to collaborate on
+       ideas or shared development without having to worry about special
+       licensing agreements or limitations on what may be discussed in open
+       forums.
+
+     * Networking: Need a new router? A name server (DNS)? A firewall to keep
+       people out of your internal network? DragonFly can easily turn that
+       unused older PC sitting in the corner into an advanced router with
+       sophisticated packet-filtering capabilities.
+
+     * X Window workstation: DragonFly is a fine choice for an inexpensive X
+       terminal solution, either using the freely available XFree86 or X.org
+       servers or one of the excellent commercial servers provided by Xi
+       Graphics. Unlike an X terminal, DragonFly allows many applications to
+       be run locally if desired, thus relieving the burden on a central
+       server. DragonFly can even boot ``diskless'', making individual
+       workstations even cheaper and easier to administer.
+
+     * Software Development: The basic DragonFly system comes with a full
+       complement of development tools including the renowned GNU C/C++
+       compiler and debugger.
+
+   DragonFly is available via anonymous FTP or CVS. Please see Appendix A for
+   more information about obtaining DragonFly.
+
+     ----------------------------------------------------------------------
+
+1.3 About the DragonFly Project
+
+   The following section provides some background information on the project,
+   including a brief history, project goals, and the development model of the
+   project.
+
+     ----------------------------------------------------------------------
+
+  1.3.1 A Brief History of DragonFly
+
+   Matthew Dillon, one of the developers for FreeBSD, was growing
+   increasingly frustrated with the FreeBSD Project's direction for release
+   5. The FreeBSD 5 release had been delayed multiple times, and had
+   performance problems compared to earlier releases of FreeBSD.
+
+   DragonFly was announced in June of 2003. The code base was taken from the
+   4.8 release of FreeBSD, which offered better performance and more complete
+   features.
+
+   Development has proceeded at a very quick rate since then, with Matt
+   Dillon and a small group of developers fixing longstanding BSD bugs and
+   modernizing the new DragonFly system.
+
+     ----------------------------------------------------------------------
+
+  1.3.2 DragonFly Project Goals
+
+   DragonFly is an effort to maintain the traditional BSD format -- lean,
+   stable code -- along with modern features such as lightweight threads, a
+   workable packaging system, and a revised VFS. Underpinning all this work
+   is efficient support for multiple processors, something rare among open
+   source systems. Because DragonFly is built on an existing very stable code
+   base, it is possible to make these radical changes as part of an
+   incremental process.
+
+     ----------------------------------------------------------------------
+
+  1.3.3 The DragonFly Development Model
+
+   Written by Justin Sherrill.
+
+   DragonFly is developed by many people around the world. There is no
+   qualification process; anyone may submit his or her code, documentation,
+   or designs, for use in the Project. Here is a general description of the
+   Project's organizational structure.
+
+   The CVS repository
+
+           Source for DragonFly is kept in CVS (Concurrent Versions System),
+           which is available with each DragonFly install. The primary CVS
+           repository resides on a machine in California, USA. Documentation
+           on obtaining the DragonFly source is available elsewhere in this
+           book.
+
+   Commit access
+
+           The best way of getting changes made to the DragonFly source is to
+           mail the submit mailing list. Including desired source code
+           changes (unified diff format is best) is the most useful format. A
+           certain number of developers have access to commit changes to the
+           DragonFly source, and can do so after review on that list.
+
+   The DragonFly development model is loose; changes to the code are
+   generally peer-reviewed and added when any objections have been corrected.
+   There is no formal entry/rejection process, though final say on all code
+   submissions goes to Matt Dillon, as originator of this project.
+
+     ----------------------------------------------------------------------
+
+  1.3.4 The Current DragonFly Release
+
+   DragonFly is a freely available, full source 4.4BSD-Lite based release for
+   Intel i386(TM), i486(TM), Pentium(R), Pentium Pro, Celeron(R), Pentium II,
+   Pentium III, Pentium 4 (or compatible), and Xeon(TM) based computer
+   systems. It is based primarily on FreeBSD 4.8, and includes enhancements
+   from U.C. Berkeley's CSRG group, NetBSD, OpenBSD, 386BSD, and the Free
+   Software Foundation.
+
+   A number of additional documents which you may find very helpful in the
+   process of installing and using DragonFly may now also be found in the
+   /usr/share/doc directory on any machine.
+
+   The most up-to-date documentation can be found at
+   http://www.dragonflybsd.org/.
+
+     ----------------------------------------------------------------------
+
+  1.3.5 "DragonFly" Origin
+
+   Matthew Dillon happened to take a picture of a dragonfly in his garden
+   while trying to come up with a name for this new branch of BSD. Taking
+   this as inspiration, "DragonFly" became the new name.
+
+     ----------------------------------------------------------------------
+
+                         Chapter 2 Installation from CD
+
+   Written by Markus Schatzl and Justin Sherrill.
+
+2.1 CD Installation Overview
+
+   This document describes the installation of DragonFly BSD on a plain i386
+   machine. This process uses a bootable DragonFly CD, usually referred to as
+   a 'live CD'.
+
+   This CD is available at one of the current mirrors, which distribute the
+   images by various protocols. The authorative list can be found at the
+   DragonFly website.
+
+   This document may be superseded by the /README file located on the live
+   CD, which may reflect changes made after this document was last updated.
+   Check that README for any last-minute changes and for an abbreviated
+   version of this installation process.
+
+   The DragonFly development team is working on an automatic installation
+   tool, which simplifies the partitioning and installation processes. Until
+   this tool is in place, the manual process here is required. Some
+   experience with BSD-style tools is recommended.
+
+     Caution: While this guide covers installing to a computer with an
+     existing non-DragonFly operating system, take no chances! Back up any
+     data on your disk drives that you want to save.
+
+   When installing to an old machine, it may not be possible to boot from a
+   CD. Use a bootmanager on a floppy in those cases, such as Smart
+   Bootmanager.
+
+     Caution: Always be sure of the target disk for any command. Unless
+     otherwise specified, each command here assumes the first disk in the IDE
+     chain is the target. (ad0) Adjust commands as needed.
+
+     ----------------------------------------------------------------------
+
+2.2 CD Installation - Making room
+
+  2.2.1 DragonFly as the only operating system
+
+   If DragonFly is to be the only operating system on the target computer,
+   preparing the disk is a short and simple process. Boot with the live CD,
+   and log in as root to reach a command prompt.
+
+   First, the master boot record (MBR) must be cleared of any old
+   information. This command clears all old data off your disk by writing
+   zeros (if=/dev/zero) onto the system's master ata drive (of=/dev/ad0).
+
+         # dd if=/dev/zero of=/dev/ad0 bs=32k count=16
+        
+
+   The now-empty disk must be formatted.
+
+     Important: This will destroy any existing data on a disk. Do this only
+     if you plan to dedicate this disk to DragonFly.
+
+         # fdisk -I ad0
+         # fdisk -B ad0
+        
+
+     ----------------------------------------------------------------------
+
+  2.2.2 Multiple operating systems on one hard disk
+
+   This example assumes that the target computer for installation has at
+   least one operating system installed that needs to survive the
+   installation process. A new partition for DragonFly needs to be created
+   from the existing partition(s) that otherwise fill the disk. There must be
+   unused space within the existing partition in order to resize it.
+
+     Important: The new partition is created from empty space in an existing
+     partition. For example, an 18 gigabyte disk that has 17 gigabytes of
+     existing data in the existing partition will only have 1 gigabyte
+     available for the new partition.
+
+   Partition resizing needs to be accomplished with a third-party tool.
+   Commercial programs such as Partition Magic can accomplish these tasks.
+   Free tools exist that can be adapted to this task, such as 'GNU parted',
+   found on the Knoppix CD, or PAUD.
+
+   Create a new partition of at least 5-6 gigabytes. It is possible to
+   install within a smaller amount of disk space, but this will create
+   problems not covered by this document. The newly created partition does
+   not need to be formatted; the rest of the installation process treats that
+   new partiton as a new disk.
+
+     ----------------------------------------------------------------------
+
+  2.2.3 Multiple operating systems, multiple hard disks
+
+   Installing DragonFly to a separate disk removes the need for partition
+   resizing, and is generally safer when trying to preserve an existing
+   operating system installation.
+
+   This type of installation is very similar to installing DragonFly as the
+   only operating system. The only difference is the disk named in each
+   command.
+
+     ----------------------------------------------------------------------
+
+2.3 CD Installation - Disk setup
+
+  2.3.1 Disk formatting
+
+   The slice layout on the newly formatted disk or partition needs to be set
+   up, using this command.
+
+           # fdisk -u
+          
+
+   If there are multiple operating systems on the disk, pick the correct
+   partition judging by what partitions were created earlier with a resizing
+   tool.
+
+     ----------------------------------------------------------------------
+
+  2.3.2 Boot block installation
+
+   The 'ad0' here refers to the first disk on the first IDE bus of a
+   computer. Increment the number if the target disk is farther down the
+   chain. For example, the master disk on the second IDE controller would be
+   'ad2'.
+
+           # boot0cfg -B ad0
+           # boot0cfg -v ad0
+          
+
+   -s SLICE, where SLICE is a number, controls which slice on disk is used by
+   boot0cfg to start from. By default, this number is 1, and will only need
+   modification if a different slice contains DragonFly.
+
+   Use -o packet as an option to boot0cfg if the DragonFly partition is
+   located beyond cylinder 1023 on the disk. This location problem usually
+   only happens when another operating system is taking up more than the
+   first 8 gigabytes of disk space. This problem cannot happen if DragonFly
+   is installed to a dedicated disk
+
+     ----------------------------------------------------------------------
+
+  2.3.3 Disklabel
+
+   If DragonFly is installed anywhere but the first partition of the disk,
+   the device entry for that partition will have to be created. Otherwise,
+   the device entry is automatically created. Refer to this different
+   partition instead of the 'ad0s1a' used in later examples.
+
+           # cd /dev; ./MAKEDEV ad0s2
+          
+
+   The partition needs to be created on the DragonFly disk.
+
+           # disklabel -B -r -w ad0s1 auto
+          
+
+   Using /etc/disklabel.ad0s1 as an example, issue the following command to
+   edit the disklabel for the just-created partition.
+
+           # disklabel -e ad0s1
+          
+
+   +----------------------------------------------------------------+
+   | Partition |    Size     |              Mountpoint              |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2a    | 256m        | /                                    |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2b    | 1024m       | swap                                 |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2c    | leave alone | This represents the whole slice.     |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2d    | 256m        | /var                                 |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2e    | 256m        | /tmp !                               |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2f    | 8192m       | /usr - This should be at least 4096m |
+   |-----------+-------------+--------------------------------------|
+   | ad0s2g    | *           | /home - This holds 'everything else' |
+   +----------------------------------------------------------------+
+
+     ----------------------------------------------------------------------
+
+  2.3.4 Partition Format
+
+   newfs will format each individual partition.
+
+           # newfs /dev/ad0s1a
+           # newfs -U /dev/ad0s1d
+           # newfs -U /dev/ad0s1e
+           # newfs -U /dev/ad0s1f
+           # newfs -U /dev/ad0s1g
+          
+
+     Note: The -U option is not used for the root partition, since / is
+     usually relatively small. Softupdates can cause it to run out of space
+     while under a lot of disk activity, such as a buildworld.
+
+     Note: The command listing skips directly from ad0s1a to ad0s1d. This is
+     because /dev/ad0s1b is used as swap and does not require formatting;
+     ad0s1c refers to the entire disk and should not be formatted.
+
+     ----------------------------------------------------------------------
+
+2.4 Installing to Disk from CD
+
+   Since the Live CD contains all needed data to create a running DragonFly
+   system, the simplest installation possible is to copy the Live CD data to
+   the newly formatted disk/partition created in previous steps.
+
+   These commands mount the newly created disk space and create the
+   appropriate directories on it.
+
+       # mount /dev/ad0s1a /mnt
+       # mkdir /mnt/var
+       # mkdir /mnt/tmp
+       # mkdir /mnt/usr
+       # mkdir /mnt/home
+       # mount /dev/ad0s1d /mnt/var
+       # mount /dev/ad0s1e /mnt/tmp
+       # mount /dev/ad0s1f /mnt/usr
+       # mount /dev/ad0s1g /mnt/home
+      
+
+   cpdup duplicates data from one volume to another. These commands copy data
+   from the Live CD to the newly created directories on the mounted disk.
+   Each step can take some time, depending on disk speed.
+
+       # cpdup / /mnt
+       # cpdup /var /mnt/var
+       # cpdup /etc /mnt/etc
+       # cpdup /dev /mnt/dev
+       # cpdup /usr /mnt/usr
+      
+
+     Note: Nothing is copied to the /tmp directory that was created in the
+     previous step. This is not an error, since /tmp is intended only for
+     temporary storage.
+
+     ----------------------------------------------------------------------
+
+2.5 CD Installation - Post-install cleanup
+
+   /tmp and /var/tmp are both often used as temporary directories. Since use
+   is not consistent from application to application, it is worthwhile to
+   create /tmp as a link to /var/tmp so space is not wasted in duplication.
+
+       # chmod 1777 /mnt/tmp
+       # rm -fr /mnt/var/tmp
+       # ln -s /tmp /mnt/var/tmp
+      
+
+     Note: /tmp will not work until the computer is rebooted.
+
+   The file /etc/fstab describes the disk partition layout. However, the
+   version copied to the target disk only reflects the Live CD layout. The
+   installed /mnt/fstab.example can be used as a starting point for creating
+   a new /etc/fstab.
+
+       # vi /mnt/etc/fstab.example
+       # mv /mnt/etc/fstab.example /mnt/etc/fstab
+      
+
+   A corrupted disklabel will render a disk useless. While this is thankfully
+   very rare, having a backup of the new install's disklabel may stave off
+   disaster at some point in the future. This is optional. (Adjust the slice
+   name to reflect the actual installation.)
+
+       # disklabel ad0s1 > /mnt/etc/disklabel.backup
+      
+
+     Note: Nothing is copied to the /tmp directory that was created in the
+     previous step. This is not an error, since /tmp is intended only for
+     temporary storage.
+
+   Remove some unnecessary files copied over from the Live CD.
+
+       # rm /mnt/boot/loader.conf
+       # rm /mnt/boot.catalog
+       # rm -r /mnt/rr_moved
+      
+
+   The system can now be rebooted. Be sure to remove the Live CD from the
+   CDROM drive so that the computer can boot from the newly-installed disk.
+
+       # reboot
+      
+
+     Note: Use the reboot command so that the disk can be unmounted cleanly.
+     Hitting the power or reset buttons, while it won't hurt the Live CD, can
+     leave the mounted disk in a inconsistent state.
+
+   If the system refuses to boot, there are several options to try:
+
+     * Old bootblocks can interfere with the initialization-process. To avoid
+       this, zero-out the MBR. "of" should be changed to the correct disk
+       entry if ad0 is not the targeted installation disk.
+
+           # dd if=/dev/zero of=/dev/ad0 bs=32 count=16
+          
+
+     * It is possible that the DragonFly slice is beyond cylinder 1023 on the
+       hard disk, and can't be detected. Packet mode can fix this problem.
+
+           # boot0cfg -o packet ad0
+          
+
+     * If you can select CHS or LBA mode in your BIOS, try changing the mode
+       to LBA.
+
+   After a successful boot from the newly installed hard drive, the timezone
+   should be set. Use the command tzsetup to set the appropriate time zone.
+
+       # tzsetup
+      
+
+     ----------------------------------------------------------------------
+
+2.6 CD Installation - New system setup
+
+   Once the new DragonFly system is booting from disk, there are a number of
+   steps that may be useful before working further. The file /etc/rc.conf
+   controls a number of options for booting the system.
+
+     ----------------------------------------------------------------------
+
+  2.6.1 Setting up rc.conf
+
+   Depending on location, a different keyboard map may be needed. This is
+   only necessary for computers outside of North America.
+
+           # kbdmap
+          
+
+   Pick the appropriate keyboard map and remember the name. Place this name
+   in /etc/rc.conf. For example:
+
+           keymap="german.iso.kbd"
+          
+
+   The file /etc/rc.conf matches the one on the Live CD. Since it is now on
+   an installed system are no longer running in a read-only environment, some
+   changes should be made. Changes to this file will take effect after the
+   next boot of the machine.
+
+   These lines can be removed.
+
+ syslogd_enable="NO"
+ xntpd_enable="NO"
+ cron_enable="NO"
+
+   For a system which uses USB, this line will need to be modified to a value
+   of "YES":
+
+ usbd_enable="NO"
+
+   inetd controls various small servers like telnet or ftp. By default, all
+   servers are off, and must be individually uncommented in /etc/inetd.conf
+   to start them. This is optional.
+
+ inetd_enable="YES"              # Run the network daemon dispatcher (YES/NO).
+ inetd_program="/usr/sbin/inetd" # path to inetd, if you want a different one.
+ inetd_flags="-wW"               # Optional flags to inetd
+
+     ----------------------------------------------------------------------
+
+  2.6.2 Network Setup
+
+   For acquiring an IP address through DHCP, place this entry in
+   /etc/rc.conf, using the appropriate card name. (ep0 is used as an example
+   here.)
+
+           ifconfig_ep0="DHCP"
+          
+
+   For a fixed IP, /etc/rc.conf requires a few more lines of data. (Again,
+   ep0 is used as an example here.) Supply the correct local values for IP,
+   netmask, and default router. The hostname should reflect what is entered
+   in DNS for this computer.
+
+           ifconfig_ep0="inet 123.234.345.456 netmask 255.255.255.0"
+           hostname="myhostname"
+           defaultrouter="654.543.432.321"
+          
+
+     ----------------------------------------------------------------------
+
+                             Chapter 3 UNIX Basics
+
+   Rewritten by Chris Shumway.
+
+3.1 Synopsis
+
+   The following chapter will cover the basic commands and functionality of
+   the DragonFly operating system. Much of this material is relevant for any
+   UNIX-like operating system. Feel free to skim over this chapter if you are
+   familiar with the material. If you are new to DragonFly, then you will
+   definitely want to read through this chapter carefully.
+
+   After reading this chapter, you will know:
+
+     * How to use the ``virtual consoles'' of DragonFly.
+
+     * How UNIX file permissions work along with understanding file flags in
+       DragonFly.
+
+     * The default DragonFly file system layout.
+
+     * The DragonFly disk organization.
+
+     * How to mount and unmount file systems.
+
+     * What processes, daemons, and signals are.
+
+     * What a shell is, and how to change your default login environment.
+
+     * How to use basic text editors.
+
+     * What devices and device nodes are.
+
+     * What binary format is used under DragonFly.
+
+     * How to read manual pages for more information.
+
+     ----------------------------------------------------------------------
+
+3.2 Virtual Consoles and Terminals
+
+   DragonFly can be used in various ways. One of them is typing commands to a
+   text terminal. A lot of the flexibility and power of a UNIX operating
+   system is readily available at your hands when using DragonFly this way.
+   This section describes what ``terminals'' and ``consoles'' are, and how
+   you can use them in DragonFly.
+
+     ----------------------------------------------------------------------
+
+  3.2.1 The Console
+
+   If you have not configured DragonFly to automatically start a graphical
+   environment during startup, the system will present you with a login
+   prompt after it boots, right after the startup scripts finish running. You
+   will see something similar to:
+
+ Additional ABI support:.
+ Local package initialization:.
+ Additional TCP options:.
+
+ Fri Sep 20 13:01:06 EEST 2002
+
+ DragonFlyBSD/i386 (pc3.example.org) (ttyv0)
+
+ login:
+
+   The messages might be a bit different on your system, but you will see
+   something similar. The last two lines are what we are interested in right
+   now. The second last line reads:
+
+ DragonFlyBSD/i386 (pc3.example.org) (ttyv0)
+
+   This line contains some bits of information about the system you have just
+   booted. You are looking at a ``DragonFlyBSD'' console, running on an Intel
+   or compatible processor of the x86 architecture[1]. The name of this
+   machine (every UNIX machine has a name) is pc3.example.org, and you are
+   now looking at its system console--the ttyv0 terminal.
+
+   Finally, the last line is always:
+
+ login:
+
+   This is the part where you are supposed to type in your ``username'' to
+   log into DragonFly. The next section describes how you can do this.
+
+     ----------------------------------------------------------------------
+
+  3.2.2 Logging into DragonFly
+
+   DragonFly is a multiuser, multiprocessing system. This is the formal
+   description that is usually given to a system that can be used by many
+   different people, who simultaneously run a lot of programs on a single
+   machine.
+
+   Every multiuser system needs some way to distinguish one ``user'' from the
+   rest. In DragonFly (and all the UNIX-like operating systems), this is
+   accomplished by requiring that every user must ``log into'' the system
+   before being able to run programs. Every user has a unique name (the
+   ``username'') and a personal, secret key (the ``password''). DragonFly
+   will ask for these two before allowing a user to run any programs.
+
+   Right after DragonFly boots and finishes running its startup scripts[2],
+   it will present you with a prompt and ask for a valid username:
+
+ login:
+
+   For the sake of this example, let us assume that your username is john.
+   Type john at this prompt and press Enter. You should then be presented
+   with a prompt to enter a ``password'':
+
+ login: john
+ Password:
+
+   Type in john's password now, and press Enter. The password is not echoed!
+   You need not worry about this right now. Suffice it to say that it is done
+   for security reasons.
+
+   If you have typed your password correctly, you should by now be logged
+   into DragonFly and ready to try out all the available commands.
+
+   You should see the MOTD or message of the day followed by a command prompt
+   (a #, $, or % character). This indicates you have successfully logged into
+   DragonFly.
+
+     ----------------------------------------------------------------------
+
+  3.2.3 Multiple Consoles
+
+   Running UNIX commands in one console is fine, but DragonFly can run many
+   programs at once. Having one console where commands can be typed would be
+   a bit of a waste when an operating system like DragonFly can run dozens of
+   programs at the same time. This is where ``virtual consoles'' can be very
+   helpful.
+
+   DragonFly can be configured to present you with many different virtual
+   consoles. You can switch from one of them to any other virtual console by
+   pressing a couple of keys on your keyboard. Each console has its own
+   different output channel, and DragonFly takes care of properly redirecting
+   keyboard input and monitor output as you switch from one virtual console
+   to the next.
+
+   Special key combinations have been reserved by DragonFly for switching
+   consoles[3]. You can use Alt-F1, Alt-F2, through Alt-F8 to switch to a
+   different virtual console in DragonFly.
+
+   As you are switching from one console to the next, DragonFly takes care of
+   saving and restoring the screen output. The result is an ``illusion'' of
+   having multiple ``virtual'' screens and keyboards that you can use to type
+   commands for DragonFly to run. The programs that you launch on one virtual
+   console do not stop running when that console is not visible. They
+   continue running when you have switched to a different virtual console.
+
+     ----------------------------------------------------------------------
+
+  3.2.4 The /etc/ttys File
+
+   The default configuration of DragonFly will start up with eight virtual
+   consoles. This is not a hardwired setting though, and you can easily
+   customize your installation to boot with more or fewer virtual consoles.
+   The number and settings of the virtual consoles are configured in the
+   /etc/ttys file.
+
+   You can use the /etc/ttys file to configure the virtual consoles of
+   DragonFly. Each uncommented line in this file (lines that do not start
+   with a # character) contains settings for a single terminal or virtual
+   console. The default version of this file that ships with DragonFly
+   configures nine virtual consoles, and enables eight of them. They are the
+   lines that start with ttyv:
+
+ # name  getty                           type    status          comments
+ #
+ ttyv0   "/usr/libexec/getty Pc"         cons25  on  secure
+ # Virtual terminals
+ ttyv1   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv2   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv3   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv4   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv5   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv6   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv7   "/usr/libexec/getty Pc"         cons25  on  secure
+ ttyv8   "/usr/X11R6/bin/xdm -nodaemon"  xterm   off secure
+
+   For a detailed description of every column in this file and all the
+   options you can use to set things up for the virtual consoles, consult the
+   ttys(5) manual page.
+
+     ----------------------------------------------------------------------
+
+  3.2.5 Single User Mode Console
+
+   A detailed description of what ``single user mode'' is can be found in
+   Section 7.5.2. It is worth noting that there is only one console when you
+   are running DragonFly in single user mode. There are no virtual consoles
+   available. The settings of the single user mode console can also be found
+   in the /etc/ttys file. Look for the line that starts with console:
+
+ # name  getty                           type    status          comments
+ #
+ # If console is marked "insecure", then init will ask for the root password
+ # when going to single-user mode.
+ console none                            unknown off secure
+
+     Note: As the comments above the console line indicate, you can edit this
+     line and change secure to insecure. If you do that, when DragonFly boots
+     into single user mode, it will still ask for the root password.
+
+     Be careful when changing this to insecure. If you ever forget the root
+     password, booting into single user mode is a bit involved. It is still
+     possible, but it might be a bit hard for someone who is not very
+     comfortable with the DragonFly booting process and the programs
+     involved.
+
+     ----------------------------------------------------------------------
+
+3.3 Permissions
+
+   DragonFly, being a direct descendant of BSD UNIX, is based on several key
+   UNIX concepts. The first and most pronounced is that DragonFly is a
+   multi-user operating system. The system can handle several users all
+   working simultaneously on completely unrelated tasks. The system is
+   responsible for properly sharing and managing requests for hardware
+   devices, peripherals, memory, and CPU time fairly to each user.
+
+   Because the system is capable of supporting multiple users, everything the
+   system manages has a set of permissions governing who can read, write, and
+   execute the resource. These permissions are stored as three octets broken
+   into three pieces, one for the owner of the file, one for the group that
+   the file belongs to, and one for everyone else. This numerical
+   representation works like this:
+
+      Value                  Permission                 Directory Listing     
+   0            No read, no write, no execute        ---                      
+   1            No read, no write, execute           --x                      
+   2            No read, write, no execute           -w-                      
+   3            No read, write, execute              -wx                      
+   4            Read, no write, no execute           r--                      
+   5            Read, no write, execute              r-x                      
+   6            Read, write, no execute              rw-                      
+   7            Read, write, execute                 rwx                      
+
+   You can use the -l command line argument to ls(1) to view a long directory
+   listing that includes a column with information about a file's permissions
+   for the owner, group, and everyone else. For example, a ls -l in an
+   arbitrary directory may show:
+
+ % ls -l
+ total 530
+ -rw-r--r--  1 root  wheel     512 Sep  5 12:31 myfile
+ -rw-r--r--  1 root  wheel     512 Sep  5 12:31 otherfile
+ -rw-r--r--  1 root  wheel    7680 Sep  5 12:31 email.txt
+ ...
+
+   Here is how the first column of ls -l is broken up:
+
+ -rw-r--r--
+
+   The first (leftmost) character tells if this file is a regular file, a
+   directory, a special character device, a socket, or any other special
+   pseudo-file device. In this case, the - indicates a regular file. The next
+   three characters, rw- in this example, give the permissions for the owner
+   of the file. The next three characters, r--, give the permissions for the
+   group that the file belongs to. The final three characters, r--, give the
+   permissions for the rest of the world. A dash means that the permission is
+   turned off. In the case of this file, the permissions are set so the owner
+   can read and write to the file, the group can read the file, and the rest
+   of the world can only read the file. According to the table above, the
+   permissions for this file would be 644, where each digit represents the
+   three parts of the file's permission.
+
+   This is all well and good, but how does the system control permissions on
+   devices? DragonFly actually treats most hardware devices as a file that
+   programs can open, read, and write data to just like any other file. These
+   special device files are stored on the /dev directory.
+
+   Directories are also treated as files. They have read, write, and execute
+   permissions. The executable bit for a directory has a slightly different
+   meaning than that of files. When a directory is marked executable, it
+   means it can be traversed into, that is, it is possible to ``cd'' (change
+   directory) into it. This also means that within the directory it is
+   possible to access files whose names are known (subject, of course, to the
+   permissions on the files themselves).
+
+   In particular, in order to perform a directory listing, read permission
+   must be set on the directory, whilst to delete a file that one knows the
+   name of, it is necessary to have write and execute permissions to the
+   directory containing the file.
+
+   There are more permission bits, but they are primarily used in special
+   circumstances such as setuid binaries and sticky directories. If you want
+   more information on file permissions and how to set them, be sure to look
+   at the chmod(1) manual page.
+
+     ----------------------------------------------------------------------
+
+  3.3.1 Symbolic Permissions
+
+   Contributed by Tom Rhodes.
+
+   Symbolic permissions, sometimes referred to as symbolic expressions, use
+   characters in place of octal values to assign permissions to files or
+   directories. Symbolic expressions use the syntax of (who) (action)
+   (permissions), where the following values are available:
+
+           Option             Letter                  Represents              
+   (who)                  u               User                                
+   (who)                  g               Group owner                         
+   (who)                  o               Other                               
+   (who)                  a               All (``world'')                     
+   (action)               +               Adding permissions                  
+   (action)               -               Removing permissions                
+   (action)               =               Explicitly set permissions          
+   (permissions)          r               Read                                
+   (permissions)          w               Write                               
+   (permissions)          x               Execute                             
+   (permissions)          t               Sticky bit                          
+   (permissions)          s               Set UID or GID                      
+
+   These values are used with the chmod(1) command just like before, but with
+   letters. For an example, you could use the following command to block
+   other users from accessing FILE:
+
+ % chmod go= FILE
+
+   A comma separated list can be provided when more than one set of changes
+   to a file must be made. For example the following command will remove the
+   groups and ``world'' write permission on FILE, then it adds the execute
+   permissions for everyone:
+
+ % chmod go-w,a+x FILE
+
+     ----------------------------------------------------------------------
+
+  3.3.2 DragonFly File Flags
+
+   Contributed by Tom Rhodes.
+
+   In addition to file permissions discussed previously, DragonFly supports
+   the use of ``file flags.'' These flags add an additional level of security
+   and control over files, but not directories.
+
+   These file flags add an additional level of control over files, helping to
+   ensure that in some cases not even the root can remove or alter files.
+
+   File flags are altered by using the chflags(1) utility, using a simple
+   interface. For example, to enable the system undeletable flag on the file
+   file1, issue the following command:
+
+ # chflags sunlink
+    file1
+
+   And to disable the system undeletable flag, simply issue the previous
+   command with ``no'' in front of the sunlink. Observe:
+
+ # chflags nosunlink
+    file1
+
+   To view the flags of this file, use the ls(1) with the -lo flags:
+
+ # ls -lo file1
+   
+
+   The output should look like the following:
+
+ -rw-r--r--  1 trhodes  trhodes  sunlnk 0 Mar  1 05:54
+ file1
+
+   Several flags may only added or removed to files by the root user. In
+   other cases, the file owner may set these flags. It is recommended an
+   administrator read over the chflags(1) and chflags(2) manual pages for
+   more information.
+
+     ----------------------------------------------------------------------
+
+3.4 Directory Structure
+
+   The DragonFly directory hierarchy is fundamental to obtaining an overall
+   understanding of the system. The most important concept to grasp is that
+   of the root directory, ``/''. This directory is the first one mounted at
+   boot time and it contains the base system necessary to prepare the
+   operating system for multi-user operation. The root directory also
+   contains mount points for every other file system that you may want to
+   mount.
+
+   A mount point is a directory where additional file systems can be grafted
+   onto the root file system. This is further described in Section 3.5.
+   Standard mount points include /usr, /var, /tmp, /mnt, and /cdrom. These
+   directories are usually referenced to entries in the file /etc/fstab.
+   /etc/fstab is a table of various file systems and mount points for
+   reference by the system. Most of the file systems in /etc/fstab are
+   mounted automatically at boot time from the script rc(8) unless they
+   contain the noauto option. Details can be found in Section 3.6.1.
+
+   A complete description of the file system hierarchy is available in
+   hier(7). For now, a brief overview of the most common directories will
+   suffice.
+
+      Directory                           Description                         
+   /               Root directory of the file system.                         
+   /bin/           User utilities fundamental to both single-user and         
+                   multi-user environments.                                   
+   /boot/          Programs and configuration files used during operating     
+                   system bootstrap.                                          
+   /boot/defaults/ Default bootstrapping configuration files; see             
+                   loader.conf(5).                                            
+   /dev/           Device nodes; see intro(4).                                
+   /etc/           System configuration files and scripts.                    
+   /etc/defaults/  Default system configuration files; see rc(8).             
+   /etc/mail/      Configuration files for mail transport agents such as      
+                   sendmail(8).                                               
+   /etc/namedb/    named configuration files; see named(8).                   
+   /etc/periodic/  Scripts that are run daily, weekly, and monthly, via       
+                   cron(8); see periodic(8).                                  
+   /etc/ppp/       ppp configuration files; see ppp(8).                       
+   /mnt/           Empty directory commonly used by system administrators as  
+                   a temporary mount point.                                   
+   /proc/          Process file system; see procfs(5), mount_procfs(8).       
+   /root/          Home directory for the root account.                       
+   /sbin/          System programs and administration utilities fundamental   
+                   to both single-user and multi-user environments.           
+   /stand/         Programs used in a standalone environment.                 
+                   Temporary files. The contents of /tmp are usually NOT      
+   /tmp/           preserved across a system reboot. A memory-based file      
+                   system is often mounted at /tmp. This can be automated     
+                   with an entry in /etc/fstab; see mfs(8).                   
+   /usr/           The majority of user utilities and applications.           
+   /usr/bin/       Common utilities, programming tools, and applications.     
+   /usr/include/   Standard C include files.                                  
+   /usr/lib/       Archive libraries.                                         
+   /usr/libdata/   Miscellaneous utility data files.                          
+   /usr/libexec/   System daemons & system utilities (executed by other       
+                   programs).                                                 
+                   Local executables, libraries, etc. Within /usr/local, the  
+                   general layout sketched out by hier(7) for /usr should be  
+   /usr/local/     used. An exceptions is the man directory, which is         
+                   directly under /usr/local rather than under                
+                   /usr/local/share.                                          
+   /usr/obj/       Architecture-specific target tree produced by building the 
+                   /usr/src tree.                                             
+                   Used as the default destination for the files installed    
+   /usr/pkg        via the pkgsrc framework or pkgsrc packages (optional).    
+                   The configuration directory is tunable, but the default    
+                   location is /usr/pkg/etc.                                  
+   /usr/pkgsrc     The pkgsrc collection for installing packages (optional).  
+   /usr/sbin/      System daemons & system utilities (executed by users).     
+   /usr/share/     Architecture-independent files.                            
+   /usr/src/       BSD and/or local source files.                             
+   /usr/X11R6/     X11R6 distribution executables, libraries, etc (optional). 
+                   Multi-purpose log, temporary, transient, and spool files.  
+   /var/           A memory-based file system is sometimes mounted at /var.   
+                   This can be automated with an entry in /etc/fstab; see     
+                   mfs(8).                                                    
+   /var/log/       Miscellaneous system log files.                            
+   /var/mail/      User mailbox files.                                        
+   /var/spool/     Miscellaneous printer and mail system spooling             
+                   directories.                                               
+   /var/tmp/       Temporary files. The files are usually preserved across a  
+                   system reboot, unless /var is a memory-based file system.  
+   /var/yp         NIS maps.                                                  
+
+     ----------------------------------------------------------------------
+
+3.5 Disk Organization
+
+   The smallest unit of organization that DragonFly uses to find files is the
+   filename. Filenames are case-sensitive, which means that readme.txt and
+   README.TXT are two separate files. DragonFly does not use the extension
+   (.txt) of a file to determine whether the file is a program, or a
+   document, or some other form of data.
+
+   Files are stored in directories. A directory may contain no files, or it
+   may contain many hundreds of files. A directory can also contain other
+   directories, allowing you to build up a hierarchy of directories within
+   one another. This makes it much easier to organize your data.
+
+   Files and directories are referenced by giving the file or directory name,
+   followed by a forward slash, /, followed by any other directory names that
+   are necessary. If you have directory foo, which contains directory bar,
+   which contains the file readme.txt, then the full name, or path to the
+   file is foo/bar/readme.txt.
+
+   Directories and files are stored in a file system. Each file system
+   contains exactly one directory at the very top level, called the root
+   directory for that file system. This root directory can then contain other
+   directories.
+
+   So far this is probably similar to any other operating system you may have
+   used. There are a few differences; for example, MS-DOS uses \ to separate
+   file and directory names, while Mac OS(R) uses :.
+
+   DragonFly does not use drive letters, or other drive names in the path.
+   You would not write c:/foo/bar/readme.txt on DragonFly.
+
+   Instead, one file system is designated the root file system. The root file
+   system's root directory is referred to as /. Every other file system is
+   then mounted under the root file system. No matter how many disks you have
+   on your DragonFly system, every directory appears to be part of the same
+   disk.
+
+   Suppose you have three file systems, called A, B, and C. Each file system
+   has one root directory, which contains two other directories, called A1,
+   A2 (and likewise B1, B2 and C1, C2).
+
+   Call A the root file system. If you used the ls command to view the
+   contents of this directory you would see two subdirectories, A1 and A2.
+   The directory tree looks like this:
+
+  /
+  |
+  +--- A1
+  |
+  `--- A2
+
+   A file system must be mounted on to a directory in another file system. So
+   now suppose that you mount file system B on to the directory A1. The root
+   directory of B replaces A1, and the directories in B appear accordingly:
+
+  /
+  |
+  +--- A1
+  |     |
+  |     +--- B1
+  |     |
+  |     `--- B2
+  |
+  `--- A2
+
+   Any files that are in the B1 or B2 directories can be reached with the
+   path /A1/B1 or /A1/B2 as necessary. Any files that were in /A1 have been
+   temporarily hidden. They will reappear if B is unmounted from A.
+
+   If B had been mounted on A2 then the diagram would look like this:
+
+  /
+  |
+  +--- A1
+  |
+  `--- A2
+        |
+        +--- B1
+        |
+        `--- B2
+
+   and the paths would be /A2/B1 and /A2/B2 respectively.
+
+   File systems can be mounted on top of one another. Continuing the last
+   example, the C file system could be mounted on top of the B1 directory in
+   the B file system, leading to this arrangement:
+
+  /
+  |
+  +--- A1
+  |
+  `--- A2
+        |
+        +--- B1
+        |     |
+        |     +--- C1
+        |     |
+        |     `--- C2
+        |
+        `--- B2
+
+   Or C could be mounted directly on to the A file system, under the A1
+   directory:
+
+  /
+  |
+  +--- A1
+  |     |
+  |     +--- C1
+  |     |
+  |     `--- C2
+  |
+  `--- A2
+        |
+        +--- B1
+        |
+        `--- B2
+
+   If you are familiar with MS-DOS, this is similar, although not identical,
+   to the join command.
+
+   This is not normally something you need to concern yourself with.
+   Typically you create file systems when installing DragonFly and decide
+   where to mount them, and then never change them unless you add a new disk.
+
+   It is entirely possible to have one large root file system, and not need
+   to create any others. There are some drawbacks to this approach, and one
+   advantage.
+
+   Benefits of Multiple File Systems
+
+     * Different file systems can have different mount options. For example,
+       with careful planning, the root file system can be mounted read-only,
+       making it impossible for you to inadvertently delete or edit a
+       critical file. Separating user-writable file systems, such as /home,
+       from other file systems also allows them to be mounted nosuid; this
+       option prevents the suid/guid bits on executables stored on the file
+       system from taking effect, possibly improving security.
+
+     * DragonFly automatically optimizes the layout of files on a file
+       system, depending on how the file system is being used. So a file
+       system that contains many small files that are written frequently will
+       have a different optimization to one that contains fewer, larger
+       files. By having one big file system this optimization breaks down.
+
+     * DragonFly's file systems are very robust should you lose power.
+       However, a power loss at a critical point could still damage the
+       structure of the file system. By splitting your data over multiple
+       file systems it is more likely that the system will still come up,
+       making it easier for you to restore from backup as necessary.
+
+   Benefit of a Single File System
+
+     * File systems are a fixed size. If you create a file system when you
+       install DragonFly and give it a specific size, you may later discover
+       that you need to make the partition bigger. The growfs(8) command
+       makes it possible to increase the size of a file system on the fly.
+
+   File systems are contained in partitions. This does not have the same
+   meaning as the common usage of the term partition (for example, MS-DOS
+   partition), because of DragonFly's UNIX heritage. Each partition is
+   identified by a letter from a through to h. Each partition can contain
+   only one file system, which means that file systems are often described by
+   either their typical mount point in the file system hierarchy, or the
+   letter of the partition they are contained in.
+
+   DragonFly also uses disk space for swap space. Swap space provides
+   DragonFly with virtual memory. This allows your computer to behave as
+   though it has much more memory than it actually does. When DragonFly runs
+   out of memory it moves some of the data that is not currently being used
+   to the swap space, and moves it back in (moving something else out) when
+   it needs it.
+
+   Some partitions have certain conventions associated with them.
+
+   Partition                            Convention                            
+   a         Normally contains the root file system                           
+   b         Normally contains swap space                                     
+             Normally the same size as the enclosing slice. This allows       
+   c         utilities that need to work on the entire slice (for example, a  
+             bad block scanner) to work on the c partition. You would not     
+             normally create a file system on this partition.                 
+             Partition d used to have a special meaning associated with it,   
+   d         although that is now gone. To this day, some tools may operate   
+             oddly if told to work on partition d.                            
+
+   Each partition-that-contains-a-file-system is stored in what DragonFly
+   calls a slice. Slice is DragonFly's term for what the common call
+   partitions, and again, this is because of DragonFly's UNIX background.
+   Slices are numbered, starting at 1, through to 4.
+
+   Slice numbers follow the device name, prefixed with an s, starting at 1.
+   So ``da0s1'' is the first slice on the first SCSI drive. There can only be
+   four physical slices on a disk, but you can have logical slices inside
+   physical slices of the appropriate type. These extended slices are
+   numbered starting at 5, so ``ad0s5'' is the first extended slice on the
+   first IDE disk. These devices are used by file systems that expect to
+   occupy a slice.
+
+   Slices, ``dangerously dedicated'' physical drives, and other drives
+   contain partitions, which are represented as letters from a to h. This
+   letter is appended to the device name, so ``da0a'' is the a partition on
+   the first da drive, which is ``dangerously dedicated''. ``ad1s3e'' is the
+   fifth partition in the third slice of the second IDE disk drive.
+
+   Finally, each disk on the system is identified. A disk name starts with a
+   code that indicates the type of disk, and then a number, indicating which
+   disk it is. Unlike slices, disk numbering starts at 0. Common codes that
+   you will see are listed in Table 3-1.
+
+   When referring to a partition DragonFly requires that you also name the
+   slice and disk that contains the partition, and when referring to a slice
+   you should also refer to the disk name. Do this by listing the disk name,
+   s, the slice number, and then the partition letter. Examples are shown in
+   Example 3-1.
+
+   Example 3-2 shows a conceptual model of the disk layout that should help
+   make things clearer.
+
+   In order to install DragonFly you must first configure the disk slices,
+   then create partitions within the slice you will use for DragonFly, and
+   then create a file system (or swap space) in each partition, and decide
+   where that file system will be mounted.
+
+   Table 3-1. Disk Device Codes
+
+       Code                                Meaning                            
+   ad           ATAPI (IDE) disk                                              
+   da           SCSI direct access disk                                       
+   acd          ATAPI (IDE) CDROM                                             
+   cd           SCSI CDROM                                                    
+   fd           Floppy disk                                                   
+
+   Example 3-1. Sample Disk, Slice, and Partition Names
+
+    Name                                Meaning                               
+   ad0s1a The first partition (a) on the first slice (s1) on the first IDE    
+          disk (ad0).                                                         
+   da1s2e The fifth partition (e) on the second slice (s2) on the second SCSI 
+          disk (da1).                                                         
+
+   Example 3-2. Conceptual Model of a Disk
+
+   This diagram shows DragonFly's view of the first IDE disk attached to the
+   system. Assume that the disk is 4 GB in size, and contains two 2 GB slices
+   (MS-DOS partitions). The first slice contains a MS-DOS disk, C:, and the
+   second slice contains a DragonFly installation. This example DragonFly
+   installation has three partitions, and a swap partition.
+
+   The three partitions will each hold a file system. Partition a will be
+   used for the root file system, e for the /var directory hierarchy, and f
+   for the /usr directory hierarchy.
+
+ .-----------------.  --.
+ |                 |    |
+ |  DOS / Windows  |    |
+ :                 :     >  First slice, ad0s1
+ :                 :    |
+ |                 |    |
+ :=================:  ==:                               --.
+ |                 |    |  Partition a, mounted as /      |
+ |                 |     > referred to as ad0s2a          |
+ |                 |    |                                 |
+ :-----------------:  ==:                                 |
+ |                 |    |  Partition b, used as swap      |
+ |                 |     > referred to as ad0s2b          |
+ |                 |    |                                 |
+ :-----------------:  ==:                                 |  Partition c, no
+ |                 |    |  Partition e, used as /var       > file system, all
+ |                 |     > referred to as ad0s2e          |  of DragonFly slice,
+ |                 |    |                                 |  ad0s2c
+ :-----------------:  ==:                                 |
+ |                 |    |                                 |
+ :                 :    |  Partition f, used as /usr      |
+ :                 :     > referred to as ad0s2f          |
+ :                 :    |                                 |
+ |                 |    |                                 |
+ |                 |  --'                                 |
+ `-----------------'                                    --'
+
+     ----------------------------------------------------------------------
+
+3.6 Mounting and Unmounting File Systems
+
+   The file system is best visualized as a tree, rooted, as it were, at /.
+   /dev, /usr, and the other directories in the root directory are branches,
+   which may have their own branches, such as /usr/local, and so on.
+
+   There are various reasons to house some of these directories on separate
+   file systems. /var contains the directories log/, spool/, and various
+   types of temporary files, and as such, may get filled up. Filling up the
+   root file system is not a good idea, so splitting /var from / is often
+   favorable.
+
+   Another common reason to contain certain directory trees on other file
+   systems is if they are to be housed on separate physical disks, or are
+   separate virtual disks, such as Network File System mounts, or CDROM
+   drives.
+
+     ----------------------------------------------------------------------
+
+  3.6.1 The fstab File
+
+   During the boot process, file systems listed in /etc/fstab are
+   automatically mounted (unless they are listed with the noauto option).
+
+   The /etc/fstab file contains a list of lines of the following format:
+
+ device       /mount-point fstype     options      dumpfreq     passno
+
+   device
+
+           A device name (which should exist), as explained in Section 12.2.
+
+   mount-point
+
+           A directory (which should exist), on which to mount the file
+           system.
+
+   fstype
+
+           The file system type to pass to mount(8). The default DragonFly
+           file system is ufs.
+
+   options
+
+           Either rw for read-write file systems, or ro for read-only file
+           systems, followed by any other options that may be needed. A
+           common option is noauto for file systems not normally mounted
+           during the boot sequence. Other options are listed in the mount(8)
+           manual page.
+
+   dumpfreq
+
+           This is used by dump(8) to determine which file systems require
+           dumping. If the field is missing, a value of zero is assumed.
+
+   passno
+
+           This determines the order in which file systems should be checked.
+           File systems that should be skipped should have their passno set
+           to zero. The root file system (which needs to be checked before
+           everything else) should have its passno set to one, and other file
+           systems' passno should be set to values greater than one. If more
+           than one file systems have the same passno then fsck(8) will
+           attempt to check file systems in parallel if possible.
+
+   Consult the fstab(5) manual page for more information on the format of the
+   /etc/fstab file and the options it contains.
+
+     ----------------------------------------------------------------------
+
+  3.6.2 The mount Command
+
+   The mount(8) command is what is ultimately used to mount file systems.
+
+   In its most basic form, you use:
+
+ # mount device mountpoint
+
+   There are plenty of options, as mentioned in the mount(8) manual page, but
+   the most common are:
+
+   Mount Options
+
+   -a
+
+           Mount all the file systems listed in /etc/fstab. Except those
+           marked as ``noauto'', excluded by the -t flag, or those that are
+           already mounted.
+
+   -d
+
+           Do everything except for the actual mount system call. This option
+           is useful in conjunction with the -v flag to determine what
+           mount(8) is actually trying to do.
+
+   -f
+
+           Force the mount of an unclean file system (dangerous), or forces
+           the revocation of write access when downgrading a file system's
+           mount status from read-write to read-only.
+
+   -r
+
+           Mount the file system read-only. This is identical to using the
+           rdonly argument to the -o option.
+
+   -t fstype
+
+           Mount the given file system as the given file system type, or
+           mount only file systems of the given type, if given the -a option.
+
+           ``ufs'' is the default file system type.
+
+   -u
+
+           Update mount options on the file system.
+
+   -v
+
+           Be verbose.
+
+   -w
+
+           Mount the file system read-write.
+
+   The -o option takes a comma-separated list of the options, including the
+   following:
+
+   nodev
+
+           Do not interpret special devices on the file system. This is a
+           useful security option.
+
+   noexec
+
+           Do not allow execution of binaries on this file system. This is
+           also a useful security option.
+
+   nosuid
+
+           Do not interpret setuid or setgid flags on the file system. This
+           is also a useful security option.
+
+     ----------------------------------------------------------------------
+
+  3.6.3 The umount Command
+
+   The umount(8) command takes, as a parameter, one of a mountpoint, a device
+   name, or the -a or -A option.
+
+   All forms take -f to force unmounting, and -v for verbosity. Be warned
+   that -f is not generally a good idea. Forcibly unmounting file systems
+   might crash the computer or damage data on the file system.
+
+   -a and -A are used to unmount all mounted file systems, possibly modified
+   by the file system types listed after -t. -A, however, does not attempt to
+   unmount the root file system.
+
+     ----------------------------------------------------------------------
+
+3.7 Processes
+
+   DragonFly is a multi-tasking operating system. This means that it seems as
+   though more than one program is running at once. Each program running at
+   any one time is called a process. Every command you run will start at
+   least one new process, and there are a number of system processes that run
+   all the time, keeping the system functional.
+
+   Each process is uniquely identified by a number called a process ID, or
+   PID, and, like files, each process also has one owner and group. The owner
+   and group information is used to determine what files and devices the
+   process can open, using the file permissions discussed earlier. Most
+   processes also have a parent process. The parent process is the process
+   that started them. For example, if you are typing commands to the shell
+   then the shell is a process, and any commands you run are also processes.
+   Each process you run in this way will have your shell as its parent
+   process. The exception to this is a special process called init(8). init
+   is always the first process, so its PID is always 1. init is started
+   automatically by the kernel when DragonFly starts.
+
+   Two commands are particularly useful to see the processes on the system,
+   ps(1) and top(1). The ps command is used to show a static list of the
+   currently running processes, and can show their PID, how much memory they
+   are using, the command line they were started with, and so on. The top
+   command displays all the running processes, and updates the display every
+   few seconds, so that you can interactively see what your computer is
+   doing.
+
+   By default, ps only shows you the commands that are running and are owned
+   by you. For example:
+
+ % ps
+   PID  TT  STAT      TIME COMMAND
+   298  p0  Ss     0:01.10 tcsh
+  7078  p0  S      2:40.88 xemacs mdoc.xsl (xemacs-21.1.14)
+ 37393  p0  I      0:03.11 xemacs freebsd.dsl (xemacs-21.1.14)
+ 48630  p0  S      2:50.89 /usr/local/lib/netscape-linux/navigator-linux-4.77.bi
+ 48730  p0  IW     0:00.00 (dns helper) (navigator-linux-)
+ 72210  p0  R+     0:00.00 ps
+   390  p1  Is     0:01.14 tcsh
+  7059  p2  Is+    1:36.18 /usr/local/bin/mutt -y
+  6688  p3  IWs    0:00.00 tcsh
+ 10735  p4  IWs    0:00.00 tcsh
+ 20256  p5  IWs    0:00.00 tcsh
+   262  v0  IWs    0:00.00 -tcsh (tcsh)
+   270  v0  IW+    0:00.00 /bin/sh /usr/X11R6/bin/startx -- -bpp 16
+   280  v0  IW+    0:00.00 xinit /home/nik/.xinitrc -- -bpp 16
+   284  v0  IW     0:00.00 /bin/sh /home/nik/.xinitrc
+   285  v0  S      0:38.45 /usr/X11R6/bin/sawfish
+
+   As you can see in this example, the output from ps(1) is organized into a
+   number of columns. PID is the process ID discussed earlier. PIDs are
+   assigned starting from 1, go up to 99999, and wrap around back to the
+   beginning when you run out. The TT column shows the tty the program is
+   running on, and can safely be ignored for the moment. STAT shows the
+   program's state, and again, can be safely ignored. TIME is the amount of
+   time the program has been running on the CPU--this is usually not the
+   elapsed time since you started the program, as most programs spend a lot
+   of time waiting for things to happen before they need to spend time on the
+   CPU. Finally, COMMAND is the command line that was used to run the
+   program.
+
+   ps(1) supports a number of different options to change the information
+   that is displayed. One of the most useful sets is auxww. a displays
+   information about all the running processes, not just your own. u displays
+   the username of the process' owner, as well as memory usage. x displays
+   information about daemon processes, and ww causes ps(1) to display the
+   full command line, rather than truncating it once it gets too long to fit
+   on the screen.
+
+   The output from top(1) is similar. A sample session looks like this:
+
+ % top
+ last pid: 72257;  load averages:  0.13,  0.09,  0.03    up 0+13:38:33  22:39:10
+ 47 processes:  1 running, 46 sleeping
+ CPU states: 12.6% user,  0.0% nice,  7.8% system,  0.0% interrupt, 79.7% idle
+ Mem: 36M Active, 5256K Inact, 13M Wired, 6312K Cache, 15M Buf, 408K Free
+ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
+
+   PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
+ 72257 nik       28   0  1960K  1044K RUN      0:00 14.86%  1.42% top
+  7078 nik        2   0 15280K 10960K select   2:54  0.88%  0.88% xemacs-21.1.14
+   281 nik        2   0 18636K  7112K select   5:36  0.73%  0.73% XF86_SVGA
+   296 nik        2   0  3240K  1644K select   0:12  0.05%  0.05% xterm
+ 48630 nik        2   0 29816K  9148K select   3:18  0.00%  0.00% navigator-linu
+   175 root       2   0   924K   252K select   1:41  0.00%  0.00% syslogd
+  7059 nik        2   0  7260K  4644K poll     1:38  0.00%  0.00% mutt
+ ...
+
+   The output is split into two sections. The header (the first five lines)
+   shows the PID of the last process to run, the system load averages (which
+   are a measure of how busy the system is), the system uptime (time since
+   the last reboot) and the current time. The other figures in the header
+   relate to how many processes are running (47 in this case), how much
+   memory and swap space has been taken up, and how much time the system is
+   spending in different CPU states.
+
+   Below that are a series of columns containing similar information to the
+   output from ps(1). As before you can see the PID, the username, the amount
+   of CPU time taken, and the command that was run. top(1) also defaults to
+   showing you the amount of memory space taken by the process. This is split
+   into two columns, one for total size, and one for resident size--total
+   size is how much memory the application has needed, and the resident size
+   is how much it is actually using at the moment. In this example you can
+   see that Netscape(R) has required almost 30 MB of RAM, but is currently
+   only using 9 MB.
+
+   top(1) automatically updates this display every two seconds; this can be
+   changed with the s option.
+
+     ----------------------------------------------------------------------
+
+3.8 Daemons, Signals, and Killing Processes
+
+   When you run an editor it is easy to control the editor, tell it to load
+   files, and so on. You can do this because the editor provides facilities
+   to do so, and because the editor is attached to a terminal. Some programs
+   are not designed to be run with continuous user input, and so they
+   disconnect from the terminal at the first opportunity. For example, a web
+   server spends all day responding to web requests, it normally does not
+   need any input from you. Programs that transport email from site to site
+   are another example of this class of application.
+
+   We call these programs daemons. Daemons were characters in Greek
+   mythology; neither good or evil, they were little attendant spirits that,
+   by and large, did useful things for mankind. Much like the web servers and
+   mail servers of today do useful things. This is why the mascot for a
+   number of BSD-based operating systems has, for a long time, been a
+   cheerful looking daemon with sneakers and a pitchfork.
+
+   There is a convention to name programs that normally run as daemons with a
+   trailing ``d''. BIND is the Berkeley Internet Name Daemon (and the actual
+   program that executes is called named), the Apache web server program is
+   called httpd, the line printer spooling daemon is lpd and so on. This is a
+   convention, not a hard and fast rule; for example, the main mail daemon
+   for the Sendmail application is called sendmail, and not maild, as you
+   might imagine.
+
+   Sometimes you will need to communicate with a daemon process. These
+   communications are called signals, and you can communicate with a daemon
+   (or with any other running process) by sending it a signal. There are a
+   number of different signals that you can send--some of them have a
+   specific meaning, others are interpreted by the application, and the
+   application's documentation will tell you how that application interprets
+   signals. You can only send a signal to a process that you own. If you send
+   a signal to someone else's process with kill(1) or kill(2) permission will
+   be denied. The exception to this is the root user, who can send signals to
+   everyone's processes.
+
+   DragonFly will also send applications signals in some cases. If an
+   application is badly written, and tries to access memory that it is not
+   supposed to, DragonFly sends the process the Segmentation Violation signal
+   (SIGSEGV). If an application has used the alarm(3) system call to be
+   alerted after a period of time has elapsed then it will be sent the Alarm
+   signal (SIGALRM), and so on.
+
+   Two signals can be used to stop a process, SIGTERM and SIGKILL. SIGTERM is
+   the polite way to kill a process; the process can catch the signal,
+   realize that you want it to shut down, close any log files it may have
+   open, and generally finish whatever it is doing at the time before
+   shutting down. In some cases a process may even ignore SIGTERM if it is in
+   the middle of some task that can not be interrupted.
+
+   SIGKILL can not be ignored by a process. This is the ``I do not care what
+   you are doing, stop right now'' signal. If you send SIGKILL to a process
+   then DragonFly will stop that process there and then[4].
+
+   The other signals you might want to use are SIGHUP, SIGUSR1, and SIGUSR2.
+   These are general purpose signals, and different applications will do
+   different things when they are sent.
+
+   Suppose that you have changed your web server's configuration file--you
+   would like to tell the web server to re-read its configuration. You could
+   stop and restart httpd, but this would result in a brief outage period on
+   your web server, which may be undesirable. Most daemons are written to
+   respond to the SIGHUP signal by re-reading their configuration file. So
+   instead of killing and restarting httpd you would send it the SIGHUP
+   signal. Because there is no standard way to respond to these signals,
+   different daemons will have different behavior, so be sure and read the
+   documentation for the daemon in question.
+
+   Signals are sent using the kill(1) command, as this example shows.
+
+   Sending a Signal to a Process
+
+   This example shows how to send a signal to inetd(8). The inetd
+   configuration file is /etc/inetd.conf, and inetd will re-read this
+   configuration file when it is sent SIGHUP.
+
+    1. Find the process ID of the process you want to send the signal to. Do
+       this using ps(1) and grep(1). The grep(1) command is used to search
+       through output, looking for the string you specify. This command is
+       run as a normal user, and inetd(8) is run as root, so the ax options
+       must be given to ps(1).
+
+ % ps -ax | grep inetd
+   198  ??  IWs    0:00.00 inetd -wW
+
+       So the inetd(8) PID is 198. In some cases the grep inetd command might
+       also occur in this output. This is because of the way ps(1) has to
+       find the list of running processes.
+
+    2. Use kill(1) to send the signal. Because inetd(8) is being run by root
+       you must use su(1) to become root first.
+
+ % su
+ Password:
+ # /bin/kill -s HUP 198
+
+       In common with most UNIX commands, kill(1) will not print any output
+       if it is successful. If you send a signal to a process that you do not
+       own then you will see ``kill: PID: Operation not permitted''. If you
+       mistype the PID you will either send the signal to the wrong process,
+       which could be bad, or, if you are lucky, you will have sent the
+       signal to a PID that is not currently in use, and you will see ``kill:
+       PID: No such process''.
+
+         Why Use /bin/kill?: Many shells provide the kill command as a built
+         in command; that is, the shell will send the signal directly, rather
+         than running /bin/kill. This can be very useful, but different
+         shells have a different syntax for specifying the name of the signal
+         to send. Rather than try to learn all of them, it can be simpler
+         just to use the /bin/kill ... command directly.
+
+   Sending other signals is very similar, just substitute TERM or KILL in the
+   command line as necessary.
+
+     Important: Killing random process on the system can be a bad idea. In
+     particular, init(8), process ID 1, is very special. Running /bin/kill -s
+     KILL 1 is a quick way to shutdown your system. Always double check the
+     arguments you run kill(1) with before you press Return.
+
+     ----------------------------------------------------------------------
+
+3.9 Shells
+
+   In DragonFly, a lot of everyday work is done in a command line interface
+   called a shell. A shell's main job is to take commands from the input
+   channel and execute them. A lot of shells also have built in functions to
+   help everyday tasks such as file management, file globbing, command line
+   editing, command macros, and environment variables. DragonFly comes with a
+   set of shells, such as sh, the Bourne Shell, and tcsh, the improved
+   C-shell. Many other shells are available from pkgsrc, such as zsh and
+   bash.
+
+   Which shell do you use? It is really a matter of taste. If you are a C
+   programmer you might feel more comfortable with a C-like shell such as
+   tcsh. If you have come from Linux or are new to a UNIX command line
+   interface you might try bash. The point is that each shell has unique
+   properties that may or may not work with your preferred working
+   environment, and that you have a choice of what shell to use.
+
+   One common feature in a shell is filename completion. Given the typing of
+   the first few letters of a command or filename, you can usually have the
+   shell automatically complete the rest of the command or filename by
+   hitting the Tab key on the keyboard. Here is an example. Suppose you have
+   two files called foobar and foo.bar. You want to delete foo.bar. So what
+   you would type on the keyboard is: rm fo[Tab].[Tab].
+
+   The shell would print out rm foo[BEEP].bar.
+
+   The [BEEP] is the console bell, which is the shell telling me it was
+   unable to totally complete the filename because there is more than one
+   match. Both foobar and foo.bar start with fo, but it was able to complete
+   to foo. If you type in ., then hit Tab again, the shell would be able to
+   fill in the rest of the filename for you.
+
+   Another feature of the shell is the use of environment variables.
+   Environment variables are a variable key pair stored in the shell's
+   environment space. This space can be read by any program invoked by the
+   shell, and thus contains a lot of program configuration. Here is a list of
+   common environment variables and what they mean:
+
+   Variable                            Description                            
+   USER     Current logged in user's name.                                    
+   PATH     Colon separated list of directories to search for binaries.       
+   DISPLAY  Network name of the X11 display to connect to, if available.      
+   SHELL    The current shell.                                                
+   TERM     The name of the user's terminal. Used to determine the            
+            capabilities of the terminal.                                     
+   TERMCAP  Database entry of the terminal escape codes to perform various    
+            terminal functions.                                               
+   OSTYPE   Type of operating system. e.g., DragonFly.                        
+   MACHTYPE The CPU architecture that the system is running on.               
+   EDITOR   The user's preferred text editor.                                 
+   PAGER    The user's preferred text pager.                                  
+   MANPATH  Colon separated list of directories to search for manual pages.   
+
+   Setting an environment variable differs somewhat from shell to shell. For
+   example, in the C-Style shells such as tcsh and csh, you would use setenv
+   to set environment variables. Under Bourne shells such as sh and bash, you
+   would use export to set your current environment variables. For example,
+   to set or modify the EDITOR environment variable, under csh or tcsh a
+   command like this would set EDITOR to /usr/local/bin/emacs:
+
+ % setenv EDITOR /usr/local/bin/emacs
+
+   Under Bourne shells:
+
+ % export EDITOR="/usr/local/bin/emacs"
+
+   You can also make most shells expand the environment variable by placing a
+   $ character in front of it on the command line. For example, echo $TERM
+   would print out whatever $TERM is set to, because the shell expands $TERM
+   and passes it on to echo.
+
+   Shells treat a lot of special characters, called meta-characters as
+   special representations of data. The most common one is the * character,
+   which represents any number of characters in a filename. These special
+   meta-characters can be used to do filename globbing. For example, typing
+   in echo * is almost the same as typing in ls because the shell takes all
+   the files that match * and puts them on the command line for echo to see.
+
+   To prevent the shell from interpreting these special characters, they can
+   be escaped from the shell by putting a backslash (\) character in front of
+   them. echo $TERM prints whatever your terminal is set to. echo \$TERM
+   prints $TERM as is.
+
+     ----------------------------------------------------------------------
+
+  3.9.1 Changing Your Shell
+
+   The easiest way to change your shell is to use the chsh command. Running
+   chsh will place you into the editor that is in your EDITOR environment
+   variable; if it is not set, you will be placed in vi. Change the
+   ``Shell:'' line accordingly.
+
+   You can also give chsh the -s option; this will set your shell for you,
+   without requiring you to enter an editor. For example, if you wanted to
+   change your shell to bash, the following should do the trick:
+
+ % chsh -s /usr/local/bin/bash
+
+     Note: The shell that you wish to use must be present in the /etc/shells
+     file. If you have installed a shell from the pkgsrc collection, then
+     this should have been done for you already. If you installed the shell
+     by hand, you must do this.
+
+     For example, if you installed bash by hand and placed it into
+     /usr/local/bin, you would want to:
+
+ # echo "/usr/local/bin/bash" >> /etc/shells
+
+     Then rerun chsh.
+
+     ----------------------------------------------------------------------
+
+3.10 Text Editors
+
+   A lot of configuration in DragonFly is done by editing text files. Because
+   of this, it would be a good idea to become familiar with a text editor.
+   DragonFly comes with a few as part of the base system, and many more are
+   available in the pkgsrc collections.
+
+   The easiest and simplest editor to learn is an editor called ee, which
+   stands for easy editor. To start ee, one would type at the command line ee
+   filename where filename is the name of the file to be edited. For example,
+   to edit /etc/rc.conf, type in ee /etc/rc.conf. Once inside of ee, all of
+   the commands for manipulating the editor's functions are listed at the top
+   of the display. The caret ^ character represents the Ctrl key on the
+   keyboard, so ^e expands to the key combination Ctrl+e. To leave ee, hit
+   the Esc key, then choose leave editor. The editor will prompt you to save
+   any changes if the file has been modified.
+
+   DragonFly also comes with more powerful text editors such as vi as part of
+   the base system, while other editors, like emacs and vim, are part of the
+   pkgsrc collection. These editors offer much more functionality and power
+   at the expense of being a little more complicated to learn. However if you
+   plan on doing a lot of text editing, learning a more powerful editor such
+   as vim or emacs will save you much more time in the long run.
+
+     ----------------------------------------------------------------------
+
+3.11 Devices and Device Nodes
+
+   A device is a term used mostly for hardware-related activities in a
+   system, including disks, printers, graphics cards, and keyboards. When
+   DragonFly boots, the majority of what DragonFly displays are devices being
+   detected. You can look through the boot messages again by viewing
+   /var/run/dmesg.boot.
+
+   For example, acd0 is the first IDE CDROM drive, while kbd0 represents the
+   keyboard.
+
+   Most of these devices in a UNIX operating system must be accessed through
+   special files called device nodes, which are located in the /dev
+   directory.
+
+     ----------------------------------------------------------------------
+
+  3.11.1 Creating Device Nodes with MAKEDEV
+
+   When adding a new device to your system, or compiling in support for
+   additional devices, you may need to create one or more device nodes for
+   the new devices.
+
+   Device nodes are created using the MAKEDEV(8) script as shown below:
+
+ # cd /dev
+ # sh MAKEDEV ad1
+      
+
+   This example would make the proper device nodes for the second IDE drive
+   when installed.
+
+     ----------------------------------------------------------------------
+
+3.12 Binary Formats
+
+   To understand why DragonFly uses the elf(5) format, you must first know a
+   little about the three currently ``dominant'' executable formats for UNIX:
+
+     * a.out(5)
+
+       The oldest and ``classic'' UNIX object format. It uses a short and
+       compact header with a magic number at the beginning that is often used
+       to characterize the format (see a.out(5) for more details). It
+       contains three loaded segments: .text, .data, and .bss plus a symbol
+       table and a string table.
+
+     * COFF
+
+       The SVR3 object format. The header now comprises a section table, so
+       you can have more than just .text, .data, and .bss sections.
+
+     * elf(5)
+
+       The successor to COFF, featuring multiple sections and 32-bit or
+       64-bit possible values. One major drawback: ELF was also designed with
+       the assumption that there would be only one ABI per system
+       architecture. That assumption is actually quite incorrect, and not
+       even in the commercial SYSV world (which has at least three ABIs:
+       SVR4, Solaris, SCO) does it hold true.
+
+       DragonFly tries to work around this problem somewhat by providing a
+       utility for branding a known ELF executable with information about the
+       ABI it is compliant with. See the manual page for brandelf(1) for more
+       information. DragonFly runs ELF.
+
+   So, why are there so many different formats?
+
+   Back in the dim, dark past, there was simple hardware. This simple
+   hardware supported a simple, small system. a.out was completely adequate
+   for the job of representing binaries on this simple system (a PDP-11). As
+   people ported UNIX from this simple system, they retained the a.out format
+   because it was sufficient for the early ports of UNIX to architectures
+   like the Motorola 68k, VAXen, etc.
+
+   Then some bright hardware engineer decided that if he could force software
+   to do some sleazy tricks, then he would be able to shave a few gates off
+   the design and allow his CPU core to run faster. While it was made to work
+   with this new kind of hardware (known these days as RISC), a.out was
+   ill-suited for this hardware, so many formats were developed to get to a
+   better performance from this hardware than the limited, simple a.out
+   format could offer. Things like COFF, ECOFF, and a few obscure others were
+   invented and their limitations explored before things seemed to settle on
+   ELF.
+
+   In addition, program sizes were getting huge and disks (and physical
+   memory) were still relatively small so the concept of a shared library was
+   born. The VM system also became more sophisticated. While each one of
+   these advancements was done using the a.out format, its usefulness was
+   stretched more and more with each new feature. In addition, people wanted
+   to dynamically load things at run time, or to junk parts of their program
+   after the init code had run to save in core memory and swap space.
+   Languages became more sophisticated and people wanted code called before
+   main automatically. Lots of hacks were done to the a.out format to allow
+   all of these things to happen, and they basically worked for a time. In
+   time, a.out was not up to handling all these problems without an ever
+   increasing overhead in code and complexity. While ELF solved many of these
+   problems, it would be painful to switch from the system that basically
+   worked. So ELF had to wait until it was more painful to remain with a.out
+   than it was to migrate to ELF.
+
+   ELF is more expressive than a.out and allows more extensibility in the
+   base system. The ELF tools are better maintained, and offer cross
+   compilation support, which is important to many people. ELF may be a
+   little slower than a.out, but trying to measure it can be difficult. There
+   are also numerous details that are different between the two in how they
+   map pages, handle init code, etc. None of these are very important, but
+   they are differences.
+
+     ----------------------------------------------------------------------
+
+3.13 For More Information
+
+  3.13.1 Manual Pages
+
+   The most comprehensive documentation on DragonFly is in the form of manual
+   pages. Nearly every program on the system comes with a short reference
+   manual explaining the basic operation and various arguments. These manuals
+   can be viewed with the man command. Use of the man command is simple:
+
+ % man command
+
+   command is the name of the command you wish to learn about. For example,
+   to learn more about ls command type:
+
+ % man ls
+
+   The online manual is divided up into numbered sections:
+
+    1. User commands.
+
+    2. System calls and error numbers.
+
+    3. Functions in the C libraries.
+
+    4. Device drivers.
+
+    5. File formats.
+
+    6. Games and other diversions.
+
+    7. Miscellaneous information.
+
+    8. System maintenance and operation commands.
+
+    9. Kernel internals.
+
+   In some cases, the same topic may appear in more than one section of the
+   online manual. For example, there is a chmod user command and a chmod()
+   system call. In this case, you can tell the man command which one you want
+   by specifying the section:
+
+ % man 1 chmod
+
+   This will display the manual page for the user command chmod. References
+   to a particular section of the online manual are traditionally placed in
+   parenthesis in written documentation, so chmod(1) refers to the chmod user
+   command and chmod(2) refers to the system call.
+
+   This is fine if you know the name of the command and simply wish to know
+   how to use it, but what if you cannot recall the command name? You can use
+   man to search for keywords in the command descriptions by using the -k
+   switch:
+
+ % man -k mail
+
+   With this command you will be presented with a list of commands that have
+   the keyword ``mail'' in their descriptions. This is actually functionally
+   equivalent to using the apropos command.
+
+   So, you are looking at all those fancy commands in /usr/bin but do not
+   have the faintest idea what most of them actually do? Simply do:
+
+ % cd /usr/bin
+ % man -f *
+
+   or
+
+ % cd /usr/bin
+ % whatis *
+
+   which does the same thing.
+
+     ----------------------------------------------------------------------
+
+  3.13.2 GNU Info Files
+
+   DragonFly includes many applications and utilities produced by the Free
+   Software Foundation (FSF). In addition to manual pages, these programs
+   come with more extensive hypertext documents called info files which can
+   be viewed with the info command or, if you installed emacs, the info mode
+   of emacs.
+
+   To use the info(1) command, simply type:
+
+ % info
+
+   For a brief introduction, type h. For a quick command reference, type ?.
+
+     ----------------------------------------------------------------------
+
+       Chapter 4 Installing Applications using NetBSD's pkgsrc framework
+
+4.1 Synopsis
+
+   DragonFly is bundled with a rich collection of system tools as part of the
+   base system. However, there is only so much one can do before needing to
+   install an additional third-party application to get real work done.
+   DragonFly utilizes NetBSD's pkgsrc framework (pkgsrc.org) for installing
+   third party software on your system. This system may be used to install
+   the newest version of your favorite applications from local media or
+   straight off the network.
+
+   After reading this chapter, you will know:
+
+     * How to install third-party binary software packages from the pkgsrc
+       collection.
+
+     * How to build third-party software from the pkgsrc collection.
+
+     * Where to find DragonFly-specific changes to packages.
+
+     * How to remove previously installed packages.
+
+     * How to override the default values that the pkgsrc collection uses.
+
+     * How to upgrade your packages.
+
+     ----------------------------------------------------------------------
+
+4.2 Overview of Software Installation
+
+   If you have used a UNIX system before you will know that the typical
+   procedure for installing third party software goes something like this:
+
+    1. Download the software, which might be distributed in source code
+       format, or as a binary.
+
+    2. Unpack the software from its distribution format (typically a tarball
+       compressed with compress(1), gzip(1), or bzip2(1)).
+
+    3. Locate the documentation (perhaps an INSTALL or README file, or some
+       files in a doc/ subdirectory) and read up on how to install the
+       software.
+
+    4. If the software was distributed in source format, compile it. This may
+       involve editing a Makefile, or running a configure script, and other
+       work.
+
+    5. Test and install the software.
+
+   And that is only if everything goes well. If you are installing a software
+   package that was not deliberately ported to DragonFly you may even have to
+   go in and edit the code to make it work properly.
+
+   Should you want to, you can continue to install software the
+   ``traditional'' way with DragonFly. However, DragonFly provides technology
+   from NetBSD, which can save you a lot of effort: pkgsrc. At the time of
+   writing, over 6,000 third party applications have been made available in
+   this way.
+
+   For any given application, the DragonFly Binary package for that
+   application is a single file which you must download. The package contains
+   pre-compiled copies of all the commands for the application, as well as
+   any configuration files or documentation. A downloaded package file can be
+   manipulated with DragonFly package management commands, such as
+   pkg_add(1), pkg_delete(1), pkg_info(1), and so on. Installing a new
+   application can be carried out with a single command.
+
+   In addition the pkgsrc collection supplies a collection of files designed
+   to automate the process of compiling an application from source code.
+
+   Remember that there are a number of steps you would normally carry out if
+   you compiled a program yourself (downloading, unpacking, patching,
+   compiling, installing). The files that make up a pkgsrc source collection
+   contain all the necessary information to allow the system to do this for
+   you. You run a handful of simple commands and the source code for the
+   application is automatically downloaded, extracted, patched, compiled, and
+   installed for you.
+
+   In fact, the pkgsrc source subsystem can also be used to generate packages
+   which can later be manipulated with pkg_add and the other package
+   management commands that will be introduced shortly.
+
+   Pkgsrc understands dependencies. Suppose you want to install an
+   application that depends on a specific library being installed. Both the
+   application and the library have been made available through the pkgsrc
+   collection. If you use the pkg_add command or the pkgsrc subsystem to add
+   the application, both will notice that the library has not been installed,
+   and automatically install the library first.
+
+   You might be wondering why pkgsrc bothers with both. Binary packages and
+   the source tree both have their own strengths, and which one you use will
+   depend on your own preference.
+
+   Binary Package Benefits
+
+     * A compressed package tarball is typically smaller than the compressed
+       tarball containing the source code for the application.
+
+     * Packages do not require any additional compilation. For large
+       applications, such as Mozilla, KDE, or GNOME this can be important,
+       particularly if you are on a slow system.
+
+     * Packages do not require any understanding of the process involved in
+       compiling software on DragonFly.
+
+   Pkgsrc source Benefits
+
+     * Binary packages are normally compiled with conservative options,
+       because they have to run on the maximum number of systems. By
+       installing from the source, you can tweak the compilation options to
+       (for example) generate code that is specific to a Pentium IV or Athlon
+       processor.
+
+     * Some applications have compile time options relating to what they can
+       and cannot do. For example, Apache can be configured with a wide
+       variety of different built-in options. By building from the source you
+       do not have to accept the default options, and can set them yourself.
+
+       In some cases, multiple packages will exist for the same application
+       to specify certain settings. For example, vim is available as a vim
+       package and a vim-gtk package, depending on whether you have installed
+       an X11 server. This sort of rough tweaking is possible with packages,
+       but rapidly becomes impossible if an application has more than one or
+       two different compile time options.
+
+     * The licensing conditions of some software distributions forbid binary
+       distribution. They must be distributed as source code.
+
+     * Some people do not trust binary distributions. With source code, it is
+       possible to check for any vulnerabilities built into the program
+       before installing it to an otherwise secure system. Few people perform
+       this much review, however.
+
+     * If you have local patches, you will need the source in order to apply
+       them.
+
+     * Some people like having code around, so they can read it if they get
+       bored, hack it, borrow from it (license permitting, of course), and so
+       on.
+
+   To keep track of updated pkgsrc releases subscribe to the netBSD pkgsrc
+   users mailing list and the netBSD pkgsrc users mailing list. It's also
+   useful to watch the DragonFly User related mailing list as errors with
+   pkgsrc on DragonFly should be reported there.
+
+     Warning: Before installing any application, you should check
+     http://www.pkgsrc.org/ for security issues related to your application.
+
+     You can also install security/audit-packages which will automatically
+     check all installed applications for known vulnerabilities, a check will
+     be also performed before any application build. Meanwhile, you can use
+     the command audit-packages -d after you have installed some packages.
+
+   The remainder of this chapter will explain how to use the pkgsrc system to
+   install and manage third party software on DragonFly.
+
+     ----------------------------------------------------------------------
+
+4.3 Finding Your Application
+
+   Before you can install any applications you need to know what you want,
+   and what the application is called.
+
+   DragonFly's list of available applications is growing all the time.
+   Fortunately, there are a number of ways to find what you want:
+
+     * There is a pkgsrc related web site that maintains an up-to-date
+       searchable list of all the available applications, at
+       http://pkgsrc.se. The packages and the corresponding source tree are
+       divided into categories, and you may either search for an application
+       by name (if you know it), or see all the applications available in a
+       category.
+
+     ----------------------------------------------------------------------
+
+4.4 Using the Binary Packages System
+
+   Original FreeBSD documentation contributed by DragonFly BSD customizations
+   contributed by Chern Lee and Adrian Nida.
+
+  4.4.1 Installing a Binary Package
+
+   You can use the pkg_add(1) utility to install a pkgsrc software package
+   from a local file or from a server on the network.
+
+   Example 4-1. Downloading a Package Manually and Installing It Locally
+
+ # ftp -a packages.stura.uni-rostock.de
+ Connected to fsr.uni-rostock.de.
+ 220 packages.stura.uni-rostock.de FTP server (Version 6.00LS) ready.
+ 331 Guest login ok, send your email address as password.
+ 230 Guest login ok, access restrictions apply.
+ Remote system type is UNIX.
+ Using binary mode to transfer files.
+ ftp> cd /pkgsrc-current/DragonFly/RELEASE/i386/All/
+ 250 CWD command successful.
+ ftp> get 0verkill-0.15.tgz
+ local: 0verkill-0.15.tgz remote: 0verkill-0.15.tgz
+ 229 Entering Extended Passive Mode (|||61652|)
+ 150 Opening BINARY mode data connection for '0verkill-0.15.tgz' (174638 bytes).
+ 100% |*************************************|   170 KB  159.37 KB/s    00:00 ETA
+ 226 Transfer complete.
+ 174638 bytes received in 00:01 (159.30 KB/s)
+ ftp> exit
+ 221 Goodbye.
+ # pkg_add 0verkill-0.15.tgz
+
+     Note: It should be noted that simply issuing:
+
+ # pkg_add ftp://packages.stura.uni-rostock.de/pkgsrc-current/DragonFly/RELEASE/i386/All/0verkill-0.15.tgz
+
+     will yield the same result as the above example.
+
+   Unlike the FreeBSD version, the Pkgsrc pkg_add(1) does not need to be
+   passed the -r option. As can be seen from the second example, you just
+   need to pass in the URL of the package. The utility will also always
+   automatically fetch and install all dependencies.
+
+   The example above would download the correct package and add it without
+   any further user intervention. If you want to specify an alternative
+   DragonFly Packages Mirror, instead of the main distribution site, you have
+   to set PACKAGESITE accordingly, to override the default settings.
+   pkg_add(1) uses fetch(3) to download the files, which honors various
+   environment variables, including FTP_PASSIVE_MODE, FTP_PROXY, and
+   FTP_PASSWORD. You may need to set one or more of these if you are behind a
+   firewall, or need to use an FTP/HTTP proxy. See fetch(3) for the complete
+   list.
+
+   Binary package files are distributed in .tgz formats. You can find them at
+   the default location ftp://goBSD.com//packages/, among other sites. The
+   layout of the packages is similar to that of the /usr/pkgsrc tree. Each
+   category has its own directory, and every package can be found within the
+   All directory.
+
+   The directory structure of the binary package system matches the source
+   tree layout; they work with each other to form the entire package system.
+
+     ----------------------------------------------------------------------
+
+  4.4.2 Managing Packages
+
+   pkg_info(1) is a utility that lists and describes the various packages
+   installed.
+
+ # pkg_info
+ digest-20050731     Message digest wrapper utility
+ screen-4.0.2nb4     Multi-screen window manager
+ ...
+
+   pkg_version(1) is a utility that summarizes the versions of all installed
+   packages. It compares the package version to the current version found in
+   the ports tree.
+
+     ----------------------------------------------------------------------
+
+  4.4.3 Deleting a Package
+
+   To remove a previously installed software package, use the pkg_delete(1)
+   utility.
+
+ # pkg_delete xchat-1.7.1
+
+     ----------------------------------------------------------------------
+
+  4.4.4 Miscellaneous
+
+   All package information is stored within the /var/db/pkg directory. The
+   installed file list and descriptions of each package can be found within
+   subdirectories of this directory.
+
+     ----------------------------------------------------------------------
+
+4.5 Using the pkgsrc(R) Source Tree
+
+   The following sections provide basic instructions on using the pkgsrc
+   source tree to install or remove programs from your system.
+
+     ----------------------------------------------------------------------
+
+  4.5.1 Obtaining the pkgsrc Source Tree
+
+   Before you can install pkgsrc packages from source, you must first obtain
+   the pkgsrc source tree--which is essentially a set of Makefiles, patches,
+   and description files placed in /usr/pkgsrc.
+
+   The primary method to obtain and keep your pkgsrc collection up to date is
+   by using CVS
+
+   CVS
+
+   This is a quick method for getting the pkgsrc collection using CVS.
+
+    1. Run cvs:
+
+           # cd /usr/
+           # cvs -d anoncvs@anoncvs.us.netbsd.org:/cvsroot co pkgsrc
+
+    2. Running the following command later will download and apply all the
+       recent changes to your source tree.
+
+ # cd /usr/pkgsrc
+           # cvs up
+
+     ----------------------------------------------------------------------
+
+  4.5.2 Installing Packages from Source
+
+   The first thing that should be explained when it comes to the source tree
+   is what is actually meant by a ``skeleton''. In a nutshell, a source
+   skeleton is a minimal set of files that tell your DragonFly system how to
+   cleanly compile and install a program. Each source skeleton should
+   include:
+
+     * A Makefile. The Makefile contains various statements that specify how
+       the application should be compiled and where it should be installed on
+       your system.
+
+     * A distinfo file. This file contains information about the files that
+       must be downloaded to build the port and their checksums, to verify
+       that files have not been corrupted during the download using md5(1).
+
+     * A files directory. This directory contains the application specific
+       files that are needed for the programs appropriate run-time
+       configuration.
+
+       This directory may also contain other files used to build the port.
+
+     * A patches directory. This directory contains patches to make the
+       program compile and install on your DragonFly system. Patches are
+       basically small files that specify changes to particular files. They
+       are in plain text format, and basically say ``Remove line 10'' or
+       ``Change line 26 to this ...''. Patches are also known as ``diffs''
+       because they are generated by the diff(1) program.
+
+     * A DESCR file. This is a more detailed, often multiple-line,
+       description of the program.
+
+     * A PLIST file. This is a list of all the files that will be installed
+       by the port. It also tells the pkgsrc system what files to remove upon
+       deinstallation.
+
+   Some pkgsrc source skeletons have other files, such as MESSAGE. The pkgsrc
+   system uses these files to handle special situations. If you want more
+   details on these files, and on pkgsrc in general, check out The pkgsrc
+   guide, available at the NetBSD website.
+
+   Now that you have enough background information to know what the pkgsrc
+   source tree is used for, you are ready to install your first compiled
+   package. There are two ways this can be done, and each is explained below.
+
+   Before we get into that, however, you will need to choose an application
+   to install. There are a few ways to do this, with the easiest method being
+   the pkgsrc listing on Joerg Sonnenberger's web site. You can browse
+   through the packages listed there.
+
+   Another way to find a particular source tree is by using the pkgsrc
+   collection's built-in search mechanism. To use the search feature, you
+   will need to be in the /usr/pkgsrc directory. Once in that directory, run
+   bmake search key="program-name" where program-name is the name of the
+   program you want to find. This searches packages names, comments,
+   descriptions and dependencies and can be used to find packages which
+   relate to a particular subject if you don't know the name of the program
+   you are looking for. For example, if you were looking for apache2:
+
+ # cd /usr/pkgsrc
+ # bmake search key="apache2"
+ Extracting complete dependency database.  This may take a while...
+ ....................................................................................................
+ 100
+ ....................................................................................................
+ 200
+ <Snip />
+ 5800
+ ....................................................................................................
+ 5900
+ .................................................................................................Reading database file
+ Flattening dependencies
+ Flattening build dependencies
+ Generating INDEX file
+ Indexed 5999 packages
+ <Snip />
+ Pkg:    apache-2.0.55nb7
+ Path:   www/apache2
+ Info:   Apache HTTP (Web) server, version 2
+ Maint:  tron@NetBSD.org
+ Index:  www
+ B-deps: perl>=5.0 apr>=0.9.7.2.0.55nb2 expat>=2.0.0nb1 libtool-base>=1.5.22nb1 gmake>=3.78 gettext-lib>=0.14.5 pkg-config>=0.19
+ R-deps: perl>=5.0 apr>=0.9.7.2.0.55nb2 expat>=2.0.0nb1
+ Arch:   any
+
+   The part of the output you want to pay particular attention to is the
+   ``Path:'' line, since that tells you where to find the source tree for the
+   requested application. The other information provided is not needed in
+   order to install the package, so it will not be covered here.
+
+   The search string is case-insensitive. Searching for ``APACHE'' will yield
+   the same results as searching for ``apache''.
+
+     Note: It should be noted that ``Extracting [the] complete dependency
+     database'' does indeed take a while.
+
+     Note: You must be logged in as root to install packages.
+
+   Now that you have found an application you would like to install, you are
+   ready to do the actual installation. The source package includes
+   instructions on how to build source code, but does not include the actual
+   source code. You can get the source code from a CD-ROM or from the
+   Internet. Source code is distributed in whatever manner the software
+   author desires. Frequently this is a tarred and gzipped file, but it might
+   be compressed with some other tool or even uncompressed. The program
+   source code, whatever form it comes in, is called a ``distfile''. You can
+   get the distfile from a CD-ROM or from the Internet.
+
+     Warning: Before installing any application, you should be sure to have
+     an up-to-date source tree and you should check http://www.pkgsrc.org/
+     for security issues related to your port.
+
+     A security vulnerabilities check can be automatically done by
+     audit-packages before any new application installation. This tool can be
+     found in the pkgsrc collection (security/audit-packages). Consider
+     running auditpackages -d before installing a new package, to fetch the
+     current vulnerabilities database. A security audit and an update of the
+     database will be performed during the daily security system check. For
+     more informations read the audit-packages and periodic(8) manual pages.
+
+     Note: It should be noted that the current setup of DragonFly requires
+     the use of bmake instead of make. This is because the current version of
+     make on DragonFly does not support all the parameters that NetBSD's
+     does.
+
+     Note: You can save an extra step by just running bmake install instead
+     of bmake and bmake install as two separate steps.
+
+     Note: Some shells keep a cache of the commands that are available in the
+     directories listed in the PATH environment variable, to speed up lookup
+     operations for the executable file of these commands. If you are using
+     one of these shells, you might have to use the rehash command after
+     installing a package, before the newly installed commands can be used.
+     This is true for both shells that are part of the base-system (such as
+     tcsh) and shells that are available as packages (for instance,
+     shells/zsh).
+
+     ----------------------------------------------------------------------
+
+    4.5.2.1 Installing Packages from the Internet
+
+   As with the last section, this section makes an assumption that you have a
+   working Internet connection. If you do not, you will need to put a copy of
+   the distfile into /usr/pkgsrc/distfiles manually.
+
+   Installing a package from the Internet is done exactly the same way as it
+   would be if you already had the distfile. The only difference between the
+   two is that the distfile is downloaded from the Internet on demand.
+
+   Here are the steps involved:
+
+ # cd /usr/pkgsrc/chat/ircII
+         # bmake install clean
+ => ircii-20040820.tar.bz2 doesn't seem to exist on this system.
+ => Attempting to fetch ircii-20040820.tar.bz2 from ftp://ircii.warped.com/pub/ircII/.
+ => [559843 bytes]
+ Connected to ircii.warped.com.
+ 220 bungi.sjc.warped.net FTP server (tnftpd 20040810) ready.
+ 331 Guest login ok, type your name as password.
+ 230-
+     A SERVICE OF WARPED.COM  -  FOR MORE INFORMATION: http://www.warped.com
+        
+         230-
+             Please read the file README
+                   it was last modified on Mon Feb  9 18:43:17 2004 - 794 days ago
+ 230 Guest login ok, access restrictions apply.
+ Remote system type is UNIX.
+ Using binary mode to transfer files.
+ 200 Type set to I.
+ 250 CWD command successful.
+ 250 CWD command successful.
+ local: ircii-20040820.tar.bz2 remote: ircii-20040820.tar.bz2
+ 229 Entering Extended Passive Mode (|||60090|)
+ 150 Opening BINARY mode data connection for 'ircii-20040820.tar.bz2' (559843 bytes).
+ 100% |***************************************|   550 KB  110.34 KB/s   00:00 ETA
+ 226 Transfer complete.
+ 559843 bytes received in 00:04 (110.34 KB/s)
+ 221-
+     Data traffic for this session was 559843 bytes in 1 file.
+     Total traffic for this session was 560993 bytes in 1 transfer.
+ 221 Thank you for using the FTP service on bungi.sjc.warped.net.
+ => Checksum SHA1 OK for ircii-20040820.tar.bz2.
+ => Checksum RMD160 OK for ircii-20040820.tar.bz2.
+ work -> /usr/obj/pkgsrc/chat/ircII/work
+ ===> Extracting for ircII-20040820
+ ==========================================================================
+ The supported build options for this package are:
+
+ socks4 socks5
+
+ You can select which build options to use by setting PKG_DEFAULT_OPTIONS
+ or the following variable.  Its current value is shown:
+
+ PKG_OPTIONS.ircII (not defined)
+
+ ==========================================================================
+ ==========================================================================
+ The following variables will affect the build process of this package,
+ ircII-20040820.  Their current value is shown below:
+
+ * USE_INET6 = YES
+
+ You may want to abort the process now with CTRL-C and change their value
+ before continuing.  Be sure to run `/usr/pkg/bin/bmake clean' after
+ the changes.
+ ==========================================================================
+ ===> Patching for ircII-20040820
+ ===> Applying pkgsrc patches for ircII-20040820
+ ===> Overriding tools for ircII-20040820
+ ===> Creating toolchain wrappers for ircII-20040820
+ ===> Configuring for ircII-20040820
+ ...
+ [configure output snipped]
+ ...
+ ===>  Building for ircII-20040820
+ ...
+ [compilation output snipped]
+ ...
+ ===>  Installing for ircII-20040820
+ ...
+ [installation output snipped]
+ ...
+ ===> [Automatic manual page handling]
+ ===> Registering installation for ircII-20040820
+ ===> Cleaning for ircII-20040820
+ #
+
+   As you can see, the only difference are the lines that tell you where the
+   system is fetching the package's distfile from.
+
+   The pkgsrc system uses ftp(1) to download the files, which honors various
+   environment variables, including FTP_PASSIVE_MODE, FTP_PROXY, and
+   FTP_PASSWORD. You may need to set one or more of these if you are behind a
+   firewall, or need to use an FTP/HTTP proxy. See ftp(1) for the complete
+   list.
+
+   For users which cannot be connected all the time, the bmake fetch option
+   is provided. Just run this command at the top level directory
+   (/usr/pkgsrc) and the required files will be downloaded for you. This
+   command will also work in the lower level categories, for example:
+   /usr/pkgsrc/net. Note that if a package depends on libraries or other
+   packages this will not fetch the distfiles of those packages as well.
+
+     Note: You can build all the packages in a category or as a whole by
+     running bmake in the top level directory, just like the aforementioned
+     bmake fetch method. This is dangerous, however, as some applications
+     cannot co-exist. In other cases, some packages can install two different
+     files with the same filename.
+
+   In some rare cases, users may need to acquire the tarballs from a site
+   other than the MASTER_SITES (the location where files are downloaded
+   from). You can override the MASTER_SORT, MASTER_SORT_REGEX and
+   INET_COUNTRY options either within the /etc/mk.conf.
+
+     Note: Some packages allow (or even require) you to provide build options
+     which can enable/disable parts of the application which are unneeded,
+     certain security options, and other customizations. A few which come to
+     mind are www/mozilla, security/gpgme, and mail/sylpheed-claws. To find
+     out what build options the application you are installing requires type:
+
+ # bmake show-options
+
+     To change the build process, either change the values of
+     PKG_DEFAULT_OPTIONS or PKG_OPTIONS.PackageName in /etc/mk.conf or on the
+     commandline as so:
+
+ # bmake PKG_OPTIONS.ircII="-ssl"
+
+     An option is enabled if listed. It is disabled if it is prefixed by a
+     minus sign.
+
+     ----------------------------------------------------------------------
+
+    4.5.2.2 Dealing with imake
+
+   Some applications that use imake (a part of the X Window System) do not
+   work well with PREFIX, and will insist on installing under /usr/X11R6.
+   Similarly, some Perl ports ignore PREFIX and install in the Perl tree.
+   Making these applications respect PREFIX is a difficult or impossible job.
+
+     ----------------------------------------------------------------------
+
+  4.5.3 Removing Installed Packages
+
+   Now that you know how to install packages, you are probably wondering how
+   to remove them, just in case you install one and later on decide that you
+   installed the wrong program. We will remove our previous example (which
+   was ircII for those of you not paying attention). As with installing
+   packages, the first thing you must do is change to the package directory,
+   /usr/pkgsrc/chat/ircII. After you change directories, you are ready to
+   uninstall ircII. This is done with the bmake deinstall command:
+
+ # cd /usr/pkgsrc/chat/ircII
+ # make deinstall
+ ===>  Deinstalling for ircII-20040820
+
+   That was easy enough. You have removed ircII from your system. If you
+   would like to reinstall it, you can do so by running bmake reinstall from
+   the /usr/ports/chat/ircII directory.
+
+   The bmake deinstall and bmake reinstall sequence does not work once you
+   have run bmake clean. If you want to deinstall a package after cleaning,
+   use pkg_delete(1) as discussed in the Pkgsrc section of the Handbook.
+
+     ----------------------------------------------------------------------
+
+  4.5.4 Packages and Disk Space
+
+   Using the pkgsrc collection can definitely eat up your disk space. For
+   this reason you should always remember to clean up the work directories
+   using the bmake clean option. This will remove the work directory after a
+   package has been built, and installed. You can also remove the tar files
+   from the distfiles directory, and remove the installed package when their
+   use has delimited.
+
+     ----------------------------------------------------------------------
+
+  4.5.5 Upgrading Packages
+
+     Note: Once you have updated your pkgsrc collection, before attempting a
+     package upgrade, you should check the /usr/pkgsrc/UPDATING file. This
+     file describes various issues and additional steps users may encounter
+     and need to perform when updating a port.
+
+   Keeping your packages up to date can be a tedious job. For instance, to
+   upgrade a package you would go to the package directory, build the
+   package, deinstall the old package , install the new package, and then
+   clean up after the build. Imagine doing that for five packages, tedious
+   right? This was a large problem for system administrators to deal with,
+   and now we have utilities which do this for us. For instance the pkg_chk
+   utility will do everything for you!
+
+   pkg_chk requires a few steps in order to work correctly. They are listed
+   here.
+
+ # pkg_chk -g # make initial list of installed packages
+         # pkg_chk -r  # remove all packages that are not up to date and packages that depend on them
+         # pkg_chk -a  # install all missing packages (use binary packages, this is the default)
+         # pkg_chk -as # install all missing packages (build from source)
+        
+
+     ----------------------------------------------------------------------
+
+4.6 Post-installation Activities
+
+   After installing a new application you will normally want to read any
+   documentation it may have included, edit any configuration files that are
+   required, ensure that the application starts at boot time (if it is a
+   daemon), and so on.
+
+   The exact steps you need to take to configure each application will
+   obviously be different. However, if you have just installed a new
+   application and are wondering ``What now?'' these tips might help:
+
+     * Use pkg_info(1) to find out which files were installed, and where. For
+       example, if you have just installed FooPackage version 1.0.0, then
+       this command
+
+ # pkg_info -L foopackage-1.0.0 | less
+
+       will show all the files installed by the package. Pay special
+       attention to files in man/ directories, which will be manual pages,
+       etc/ directories, which will be configuration files, and doc/, which
+       will be more comprehensive documentation.
+
+       If you are not sure which version of the application was just
+       installed, a command like this
+
+ # pkg_info | grep -i foopackage
+
+       will find all the installed packages that have foopackage in the
+       package name. Replace foopackage in your command line as necessary.
+
+     * Once you have identified where the application's manual pages have
+       been installed, review them using man(1). Similarly, look over the
+       sample configuration files, and any additional documentation that may
+       have been provided.
+
+     * If the application has a web site, check it for additional
+       documentation, frequently asked questions, and so forth. If you are
+       not sure of the web site address it may be listed in the output from
+
+ # pkg_info foopackage-1.0.0
+
+       A WWW: line, if present, should provide a URL for the application's
+       web site.
+
+     * Packages that should start at boot (such as Internet servers) will
+       usually install a sample script in /usr/pkg/etc/rc.d. You should
+       review this script for correctness and edit or rename it if needed.
+       See Starting Services for more information.
+
+     ----------------------------------------------------------------------
+
+4.7 Dealing with Broken Packages
+
+   If you come across a package that does not work for you, there are a few
+   things you can do, including:
+
+    1. Fix it! The pkgsrc Guide includes detailed information on the
+       ``pkgsrc'' infrastructure so that you can fix the occasional broken
+       package or even submit your own!
+
+    2. Gripe--by email only! Send email to the maintainer of the package
+       first. Type bmake maintainer or read the Makefile to find the
+       maintainer's email address. Remember to include the name and version
+       of the port (send the $NetBSD: line from the Makefile) and the output
+       leading up to the error when you email the maintainer. If you do not
+       get a response from the maintainer, you can try users .
+
+    3. Grab the package from an FTP site near you. The ``master'' package
+       collection is on packages.stura.uni-rostock.de in the All directory.
+       These are more likely to work than trying to compile from source and
+       are a lot faster as well. Use the pkg_add(1) program to install the
+       package on your system.
+
+     ----------------------------------------------------------------------
+
+                         Chapter 5 The X Window System
+
+5.1 Synopsis
+
+   DragonFly uses XFree86 to provide users with a powerful graphical user
+   interface. XFree86 is an open-source implementation of the X Window
+   System. This chapter will cover installation and configuration of XFree86
+   on a DragonFly system. For more information on XFree86 and video hardware
+   that it supports, check the XFree86 web site.
+
+     Warning: This chapter contains a number of outdated references to the
+     FreeBSD ports collection. Most instructions still apply to pkgsrc, but
+     proceed with caution until this chapter is updated.
+
+   After reading this chapter, you will know:
+
+     * The various components of the X Window System, and how they
+       interoperate.
+
+     * How to install and configure XFree86.
+
+     * How to install and use different window managers.
+
+     * How to use TrueType(R) fonts in XFree86.
+
+     * How to set up your system for graphical logins (XDM).
+
+   Before reading this chapter, you should:
+
+     * Know how to install additional third-party software (Chapter 4).
+
+     ----------------------------------------------------------------------
+
+5.2 Understanding X
+
+   Using X for the first time can be somewhat of a shock to someone familiar
+   with other graphical environments, such as Microsoft Windows or Mac OS.
+
+   It is not necessary to understand all of the details of various X
+   components and how they interact; however, some basic knowledge makes it
+   possible to take advantage of X's strengths.
+
+     ----------------------------------------------------------------------
+
+  5.2.1 Why X?
+
+   X is not the first window system written for UNIX, but it is the most
+   popular. X's original development team had worked on another window system
+   before writing X. That system's name was ``W'' (for ``Window''). X is just
+   the next letter in the Roman alphabet.
+
+   X can be called ``X'', ``X Window System'', ``X11'', and other terms.
+   Calling X11 ``X Windows'' can offend some people; see X(7) for a bit more
+   insight on this.
+
+     ----------------------------------------------------------------------
+
+  5.2.2 The X Client/Server Model
+
+   X was designed from the beginning to be network-centric, and adopts a
+   ``client-server'' model. In the X model, the ``X server'' runs on the
+   computer that has the keyboard, monitor, and mouse attached. The server is
+   responsible for managing the display, handling input from the keyboard and
+   mouse, and so on. Each X application (such as XTerm, or Netscape) is a
+   ``client''. A client sends messages to the server such as ``Please draw a
+   window at these coordinates'', and the server sends back messages such as
+   ``The user just clicked on the OK button''.
+
+   If there is only one computer involved, such as in a home or small office
+   environment, the X server and the X clients will be running on the same
+   computer. However, it is perfectly possible to run the X server on a less
+   powerful desktop computer, and run X applications (the clients) on, say,
+   the powerful and expensive machine that serves the office. In this
+   scenario the communication between the X client and server takes place
+   over the network.
+
+   This confuses some people, because the X terminology is exactly backward
+   to what they expect. They expect the ``X server'' to be the big powerful
+   machine down the hall, and the ``X client'' to be the machine on their
+   desk.
+
+   Remember that the X server is the machine with the monitor and keyboard,
+   and the X clients are the programs that display the windows.
+
+   There is nothing in the protocol that forces the client and server
+   machines to be running the same operating system, or even to be running on
+   the same type of computer. It is certainly possible to run an X server on
+   Microsoft Windows or Apple's Mac OS, and there are various free and
+   commercial applications available that do exactly that.
+
+   The X server that ships with DragonFly is called XFree86, and is available
+   for free, under a license very similar to the DragonFly license.
+   Commercial X servers for FreeBSD are also available, and ought to work
+   with DragonFly . (Unconfirmed as of this writing.)
+
+     ----------------------------------------------------------------------
+
+  5.2.3 The Window Manager
+
+   The X design philosophy is much like the UNIX design philosophy, ``tools,
+   not policy''. This means that X does not try to dictate how a task is to
+   be accomplished. Instead, tools are provided to the user, and it is the
+   user's responsibility to decide how to use those tools.
+
+   This philosophy extends to X not dictating what windows should look like
+   on screen, how to move them around with the mouse, what keystrokes should
+   be used to move between windows (i.e., Alt+Tab, in the case of
+   Microsoft Windows), what the title bars on each window should look like,
+   whether or not they have close buttons on them, and so on.
+
+   Instead, X delegates this responsibility to an application called a
+   ``Window Manager''. There are dozens of window managers available for X:
+   AfterStep, Blackbox, ctwm, Enlightenment, fvwm, Sawfish, twm, Window
+   Maker, and more. Each of these window managers provides a different look
+   and feel; some of them support ``virtual desktops''; some of them allow
+   customized keystrokes to manage the desktop; some have a ``Start'' button
+   or similar device; some are ``themeable'', allowing a complete change of
+   look-and-feel by applying a new theme. These window managers, and many
+   more, are available in the wm category of pkgsrc.
+
+   In addition, the KDE and GNOME desktop environments both have their own
+   window managers which integrate with the desktop.
+
+   Each window manager also has a different configuration mechanism; some
+   expect configuration file written by hand, others feature GUI tools for
+   most of the configuration tasks; at least one (sawfish) has a
+   configuration file written in a dialect of the Lisp language.
+
+     Focus Policy: Another feature the window manager is responsible for is
+     the mouse ``focus policy''. Every windowing system needs some means of
+     choosing a window to be actively receiving keystrokes, and should
+     visibly indicate which window is active as well.
+
+     A familiar focus policy is called ``click-to-focus''. This is the model
+     utilized by Microsoft Windows, in which a window becomes active upon
+     receiving a mouse click.
+
+     X does not support any particular focus policy. Instead, the window
+     manager controls which window has the focus at any one time. Different
+     window managers will support different focus methods. All of them
+     support click to focus, and the majority of them support several others.
+
+     The most popular focus policies are:
+
+     focus-follows-mouse
+
+             The window that is under the mouse pointer is the window that
+             has the focus. This may not necessarily be the window that is on
+             top of all the other windows. The focus is changed by pointing
+             at another window, there is no need to click in it as well.
+
+     sloppy-focus
+
+             This policy is a small extension to focus-follows-mouse. With
+             focus-follows-mouse, if the mouse is moved over the root window
+             (or background) then no window has the focus, and keystrokes are
+             simply lost. With sloppy-focus, focus is only changed when the
+             cursor enters a new window, and not when exiting the current
+             window.
+
+     click-to-focus
+
+             The active window is selected by mouse click. The window may
+             then be ``raised'', and appear in front of all other windows.
+             All keystrokes will now be directed to this window, even if the
+             cursor is moved to another window.
+
+     Many window managers support other policies, as well as variations on
+     these. Be sure to consult the documentation for the window manager
+     itself.
+
+     ----------------------------------------------------------------------
+
+  5.2.4 Widgets
+
+   The X approach of providing tools and not policy extends to the widgets
+   seen on screen in each application.
+
+   ``Widget'' is a term for all the items in the user interface that can be
+   clicked or manipulated in some way; buttons, check boxes, radio buttons,
+   icons, lists, and so on. Microsoft Windows calls these ``controls''.
+
+   Microsoft Windows and Apple's Mac OS both have a very rigid widget policy.
+   Application developers are supposed to ensure that their applications
+   share a common look and feel. With X, it was not considered sensible to
+   mandate a particular graphical style, or set of widgets to adhere to.
+
+   As a result, do not expect X applications to have a common look and feel.
+   There are several popular widget sets and variations, including the
+   original Athena widget set from MIT, Motif(R) (on which the widget set in
+   Microsoft Windows was modeled, all bevelled edges and three shades of
+   grey), OpenLook, and others.
+
+   Most newer X applications today will use a modern-looking widget set,
+   either Qt, used by KDE, or GTK, used by the GNOME project. In this
+   respect, there is some convergence in look-and-feel of the UNIX desktop,
+   which certainly makes things easier for the novice user.
+
+     ----------------------------------------------------------------------
+
+5.3 Installing XFree86(TM)
+
+     Warning: This section is out of date; please consult the DragonFly BSD
+     wiki or mailing lists for recent discussion.
+
+   A binary package to use with pkg_add(1) tool is also available for XFree86
+   4.X. When the remote fetching feature of pkg_add(1) is used, the version
+   number of the package must be removed. pkg_add(1) will automatically fetch
+   the latest version of the application. So to fetch and install the package
+   of XFree86 4.X, simply type:
+
+ # pkg_add XFree86
+
+   You can also use the ports collection to install XFree86 4.X, for that you
+   simply need to type the following commands:
+
+ # cd /usr/ports/x11/XFree86-4
+ # make install clean
+
+     Note: The examples above will install the complete XFree86 distribution
+     including the servers, clients, fonts etc. Separate packages for
+     different parts of XFree86 4.X are also available.
+
+   The rest of this chapter will explain how to configure XFree86, and how to
+   set up a productive desktop environment.
+
+     ----------------------------------------------------------------------
+
+5.4 XFree86 Configuration
+
+   Contributed by Christopher Shumway.
+
+     ----------------------------------------------------------------------
+
+  5.4.1 Before Starting
+
+   Before configuration of XFree86 4.X, the following information about the
+   target system is needed:
+
+     * Monitor specifications
+
+     * Video Adapter chipset
+
+     * Video Adapter memory
+
+   The specifications for the monitor are used by XFree86 to determine the
+   resolution and refresh rate to run at. These specifications can usually be
+   obtained from the documentation that came with the monitor or from the
+   manufacturer's website. There are two ranges of numbers that are needed,
+   the horizontal scan rate and the vertical synchronization rate.
+
+   The video adapter's chipset defines what driver module XFree86 uses to
+   talk to the graphics hardware. With most chipsets, this can be
+   automatically determined, but it is still useful to know in case the
+   automatic detection does not work correctly.
+
+   Video memory on the graphic adapter determines the resolution and color
+   depth which the system can run at. This is important to know so the user
+   knows the limitations of the system.
+
+     ----------------------------------------------------------------------
+
+  5.4.2 Configuring XFree86 4.X
+
+   Configuration of XFree86 4.X is a multi-step process. The first step is to
+   build an initial configuration file with the -configure option to XFree86.
+   As the super user, simply run:
+
+ # XFree86 -configure
+
+   This will generate a skeleton XFree86 configuration file in the /root
+   directory called XF86Config.new (in fact the directory used is the one
+   covered by the environment variable $HOME, and it will depend from the way
+   you got the superuser rights). The XFree86 program will attempt to probe
+   the graphics hardware on the system and will write a configuration file to
+   load the proper drivers for the detected hardware on the target system.
+
+   The next step is to test the existing configuration to verify that XFree86
+   can work with the graphics hardware on the target system. To perform this
+   task, the user needs to run:
+
+ # XFree86 -xf86config XF86Config.new
+
+   If a black and grey grid and an X mouse cursor appear, the configuration
+   was successful. To exit the test, just press Ctrl+Alt+Backspace
+   simultaneously.
+
+     Note: If the mouse does not work, be sure the device has been
+     configured. See moused(8) for more information
+
+   Next, tune the XF86Config.new configuration file to taste. Open the file
+   in a text editor such as emacs(1) or ee(1). First, add the frequencies for
+   the target system's monitor. These are usually expressed as a horizontal
+   and vertical synchronization rate. These values are added to the
+   XF86Config.new file under the "Monitor" section:
+
+ Section "Monitor"
+         Identifier   "Monitor0"
+         VendorName   "Monitor Vendor"
+         ModelName    "Monitor Model"
+         HorizSync    30-107
+         VertRefresh  48-120
+ EndSection
+
+   The HorizSync and VertRefresh keywords may not exist in the configuration
+   file. If they do not, they need to be added, with the correct horizontal
+   synchronization rate placed after the HorizSync keyword and the vertical
+   synchronization rate after the VertRefresh keyword. In the example above
+   the target monitor's rates were entered.
+
+   X allows DPMS (Energy Star) features to be used with capable monitors. The
+   xset(1) program controls the time-outs and can force standby, suspend, or
+   off modes. If you wish to enable DPMS features for your monitor, you must
+   add the following line to the monitor section:
+
+         Option       "DPMS"
+
+   While the XF86Config.new configuration file is still open in an editor,
+   select the default resolution and color depth desired. This is defined in
+   the "Screen" section:
+
+ Section "Screen"
+         Identifier "Screen0"
+         Device     "Card0"
+         Monitor    "Monitor0"
+         DefaultDepth 24
+         SubSection "Display"
+                 Depth     24
+                 Modes     "1024x768"
+         EndSubSection
+ EndSection
+
+   The DefaultDepth keyword describes the color depth to run at by default.
+   This can be overridden with the -bpp command line switch to XFree86(1).
+   The Modes keyword describes the resolution to run at for the given color
+   depth. Note that only VESA standard modes are supported as defined by the
+   target system's graphics hardware. In the example above, the default color
+   depth is twenty-four bits per pixel. At this color depth, the accepted
+   resolution is one thousand twenty-four pixels by seven hundred and
+   sixty-eight pixels.
+
+   Finally, write the configuration file and test it using the test mode
+   given above. If all is well, the configuration file needs to be installed
+   in a common location where XFree86(1) can find it. This is typically
+   /etc/X11/XF86Config or /usr/X11R6/etc/X11/XF86Config.
+
+ # cp XF86Config.new /etc/X11/XF86Config
+
+   Once the configuration file has been placed in a common location,
+   configuration is complete. In order to start XFree86 4.X with startx(1),
+   install the x11/wrapper port. XFree86 4.X can also be started with xdm(1).
+
+     Note: There is also a graphical tool for configuration, xf86cfg(1), that
+     comes with the XFree86 4.X distribution. It allows to interactively
+     define your configuration by choosing the appropriate drivers and
+     settings. This program can be used under console as well, just use the
+     command xf86cfg -textmode. For more details, refer to the xf86cfg(1)
+     manual page.
+
+     ----------------------------------------------------------------------
+
+  5.4.3 Advanced Configuration Topics
+
+    5.4.3.1 Configuration with Intel(R) i810 Graphics Chipsets
+
+   Configuration with Intel(R) i810 integrated chipsets requires the agpgart
+   AGP programming interface for XFree86 to drive the card. The agp(4) driver
+   is in the GENERIC kernel since releases 4.8-RELEASE and 5.0-RELEASE. On
+   prior releases, you will have to add the following line:
+
+ device agp
+
+   in your kernel configuration file and rebuild a new kernel. Instead, you
+   may want to load the agp.ko kernel module automatically with the loader(8)
+   at boot time. For that, simply add this line to /boot/loader.conf:
+
+ agp_load="YES"
+
+   Next, a device node needs to be created for the programming interface. To
+   create the AGP device node, run MAKEDEV(8) in the /dev directory:
+
+ # cd /dev
+ # sh MAKEDEV agpgart
+
+   This will allow configuration of the hardware as any other graphics board.
+   Note on systems without the agp(4) driver compiled in the kernel, trying
+   to load the module with kldload(8) will not work. This driver has to be in
+   the kernel at boot time through being compiled in or using
+   /boot/loader.conf.
+
+   If you are using XFree86 4.1.0 (or later) and messages about unresolved
+   symbols like fbPictureInit appear, try adding the following line after
+   Driver "i810" in the XFree86 configuration file:
+
+ Option "NoDDC"
+
+     ----------------------------------------------------------------------
+
+5.5 Using Fonts in XFree86
+
+   Contributed by Murray Stokely.
+
+  5.5.1 Type1 Fonts
+
+   The default fonts that ship with XFree86 are less than ideal for typical
+   desktop publishing applications. Large presentation fonts show up jagged
+   and unprofessional looking, and small fonts in Netscape are almost
+   completely unintelligible. However, there are several free, high quality
+   Type1 (PostScript(R)) fonts available which can be readily used with
+   XFree86, either version 3.X or version 4.X. For instance, the URW font
+   collection (x11-fonts/urwfonts) includes high quality versions of standard
+   type1 fonts (Times Roman(R), Helvetica(R), Palatino(R) and others). The
+   Freefonts collection (x11-fonts/freefonts) includes many more fonts, but
+   most of them are intended for use in graphics software such as the Gimp,
+   and are not complete enough to serve as screen fonts. In addition, XFree86
+   can be configured to use TrueType fonts with a minimum of effort: see the
+   section on TrueType fonts later.
+
+   To install the above Type1 font collections from the ports collection, run
+   the following commands:
+
+ # cd /usr/ports/x11-fonts/urwfonts
+ # make install clean
+
+   And likewise with the freefont or other collections. To tell the X server
+   that these fonts exist, add an appropriate line to the XF86Config file (in
+   /etc/ for XFree86 version 3, or in /etc/X11/ for version 4), which reads:
+
+ FontPath "/usr/X11R6/lib/X11/fonts/URW/"
+
+   Alternatively, at the command line in the X session run:
+
+ % xset fp+ /usr/X11R6/lib/X11/fonts/URW
+ % xset fp rehash
+
+   This will work but will be lost when the X session is closed, unless it is
+   added to the startup file (~/.xinitrc for a normal startx session, or
+   ~/.xsession when logging in through a graphical login manager like XDM). A
+   third way is to use the new XftConfig file: see the section on
+   anti-aliasing.
+
+     ----------------------------------------------------------------------
+
+  5.5.2 TrueType(R) Fonts
+
+   XFree86 4.X has built in support for rendering TrueType fonts. There are
+   two different modules that can enable this functionality. The freetype
+   module is used in this example because it is more consistent with the
+   other font rendering back-ends. To enable the freetype module just add the
+   following line to the "Module" section of the /etc/X11/XF86Config file.
+
+ Load  "freetype"
+
+   For XFree86 3.3.X, a separate TrueType font server is needed. Xfstt is
+   commonly used for this purpose. To install Xfstt, simply install the port
+   x11-servers/Xfstt.
+
+   Now make a directory for the TrueType fonts (for example,
+   /usr/X11R6/lib/X11/fonts/TrueType) and copy all of the TrueType fonts into
+   this directory. Keep in mind that TrueType fonts cannot be directly taken
+   from a Macintosh(R); they must be in UNIX/DOS/Windows format for use by
+   XFree86. Once the files have been copied into this directory, use ttmkfdir
+   to create a fonts.dir file, so that the X font renderer knows that these
+   new files have been installed. ttmkfdir is available from the FreeBSD
+   Ports Collection as x11-fonts/ttmkfdir or the pkgsrc collection at
+   fonts/ttmkfdir2.
+
+ # cd /usr/X11R6/lib/X11/fonts/TrueType
+ # ttmkfdir > fonts.dir
+
+   Now add the TrueType directory to the font path. This is just the same as
+   described above for Type1 fonts, that is, use
+
+ % xset fp+ /usr/X11R6/lib/X11/fonts/TrueType
+ % xset fp rehash
+
+   or add a FontPath line to the XF86Config file.
+
+   That's it. Now Netscape, Gimp, StarOffice(TM), and all of the other X
+   applications should now recognize the installed TrueType fonts. Extremely
+   small fonts (as with text in a high resolution display on a web page) and
+   extremely large fonts (within StarOffice) will look much better now.
+
+     ----------------------------------------------------------------------
+
+  5.5.3 Anti-Aliased Fonts
+
+   Updated for XFree86 4.3 by Joe Marcus Clarke.
+
+   Anti-aliasing has been available in XFree86 since 4.0.2. However, font
+   configuration was cumbersome before the introduction of XFree86 4.3.0.
+   Starting in version 4.3.0, all fonts in /usr/X11R6/lib/X11/fonts/ and
+   ~/.fonts/ are automatically made available for anti-aliasing to Xft-aware
+   applications. Not all applications are Xft-aware yet, but many have
+   received Xft support. Examples of Xft-aware applications include Qt 2.3
+   and higher (the toolkit for the KDE desktop), Gtk+ 2.0 and higher (the
+   toolkit for the GNOME desktop), and Mozilla 1.2 and higher.
+
+   In order to control which fonts are anti-aliased, or to configure
+   anti-aliasing properties, create (or edit, if it already exists) the file
+   /usr/X11R6/etc/fonts/local.conf. Several advanced features of the Xft font
+   system can be tuned using this file; this section describes only some
+   simple possibilities. For more details, please see fonts-conf(5).
+
+   This file must be in XML format. Pay careful attention to case, and make
+   sure all tags are properly closed. The file begins with the usual XML
+   header followed by a DOCTYPE definition, and then the <fontconfig> tag:
+
+       <?xml version="1.0"?>
+       <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
+       <fontconfig>
+    
+
+   As previously stated, all fonts in /usr/X11R6/lib/X11/fonts/ as well as
+   ~/.fonts/ are already made available to Xft-aware applications. If you
+   wish to add another directory outside of these two directory trees, add a
+   line similar to the following to /usr/X11R6/etc/fonts/local.conf:
+
+ <dir>/path/to/my/fonts</dir>
+
+   After adding new fonts, and especially new font directories, you should
+   run the following command to rebuild the font caches:
+
+ # fc-cache -f
+
+   Anti-aliasing makes borders slightly fuzzy, which makes very small text
+   more readable and removes ``staircases'' from large text, but can cause
+   eyestrain if applied to normal text. To exclude point sizes smaller than
+   14 point from anti-aliasing, include these lines:
+
+         <match target="font">
+             <test name="size" compare="less">
+                 <double>14</double>
+             </test>
+             <edit name="antialias" mode="assign">
+                 <bool>false</bool>
+             </edit>
+         </match>
+
+   Spacing for some monospaced fonts may also be inappropriate with
+   anti-aliasing. This seems to be an issue with KDE, in particular. One
+   possible fix for this is to force the spacing for such fonts to be 100.
+   Add the following lines:
+
+        <match target="pattern" name="family">
+            <test qual="any" name="family">
+                <string>fixed</string>
+            </test>
+            <edit name="family" mode="assign">
+                <string>mono</string>
+            </edit>
+         </match>
+         <match target="pattern" name="family">
+             <test qual="any" name="family">
+                 <string>console</string>
+             </test>
+             <edit name="family" mode="assign">
+                 <string>mono</string>
+             </edit>
+         </match>
+
+   (this aliases the other common names for fixed fonts as "mono"), and then
+   add:
+
+          <match target="pattern" name="family">
+              <test qual="any" name="family">
+                  <string>mono</string>
+              </test>
+              <edit name="spacing" mode="assign">
+                  <int>100</int>
+              </edit>
+          </match>     
+
+   Certain fonts, such as Helvetica, may have a problem when anti-aliased.
+   Usually this manifests itself as a font that seems cut in half vertically.
+   At worst, it may cause applications such as Mozilla to crash. To avoid
+   this, consider adding the following to local.conf:
+
+          <match target="pattern" name="family">
+              <test qual="any" name="family">
+                  <string>Helvetica</string>
+              </test>
+              <edit name="family" mode="assign">
+                  <string>sans-serif</string>
+              </edit>
+          </match>       
+
+   Once you have finished editing local.conf make sure you end the file with
+   the </fontconfig> tag. Not doing this will cause your changes to be
+   ignored.
+
+   The default font set that comes with XFree86 is not very desirable when it
+   comes to anti-aliasing. A much better set of default fonts can be found in
+   the x11-fonts/bitstream-vera port. This port will install a
+   /usr/X11R6/etc/fonts/local.conf file if one does not exist already. If the
+   file does exist, the port will create a
+   /usr/X11R6/etc/fonts/local.conf-vera file. Merge the contents of this file
+   into /usr/X11R6/etc/fonts/local.conf, and the Bitstream fonts will
+   automatically replace the default XFree86 Serif, Sans Serif, and
+   Monospaced fonts.
+
+   Finally, users can add their own settings via their personal .fonts.conf
+   files. To do this, each user should simply create a ~/.fonts.conf. This
+   file must also be in XML format.
+
+   One last point: with an LCD screen, sub-pixel sampling may be desired.
+   This basically treats the (horizontally separated) red, green and blue
+   components separately to improve the horizontal resolution; the results
+   can be dramatic. To enable this, add the line somewhere in the local.conf
+   file:
+
+          <match target="font">
+              <test qual="all" name="rgba">
+                  <const>unknown</const>
+              </test>
+              <edit name="rgba" mode="assign">
+                  <const>rgb</const>
+              </edit>
+          </match>
+       
+
+     Note: Depending on the sort of display, rgb may need to be changed to
+     bgr, vrgb or vbgr: experiment and see which works best.
+
+   Anti-aliasing should be enabled the next time the X server is started.
+   However, programs must know how to take advantage of it. At present, the
+   Qt toolkit does, so the entire KDE environment can use anti-aliased fonts
+   (see Section 5.7.3.2 on KDE for details). Gtk+ and GNOME can also be made
+   to use anti-aliasing via the ``Font'' capplet (see Section 5.7.1.3 for
+   details). By default, Mozilla 1.2 and greater will automatically use
+   anti-aliasing. To disable this, rebuild Mozilla with the -DWITHOUT_XFT
+   flag.
+
+     ----------------------------------------------------------------------
+
+5.6 The X Display Manager
+
+   Contributed by Seth Kingsley.
+
+  5.6.1 Overview
+
+   The X Display Manager (XDM) is an optional part of the X Window System
+   that is used for login session management. This is useful for several
+   types of situations, including minimal ``X Terminals'', desktops, and
+   large network display servers. Since the X Window System is network and
+   protocol independent, there are a wide variety of possible configurations
+   for running X clients and servers on different machines connected by a
+   network. XDM provides a graphical interface for choosing which display
+   server to connect to, and entering authorization information such as a
+   login and password combination.
+
+   Think of XDM as providing the same functionality to the user as the
+   getty(8) utility (see Section 17.3.2 for details). That is, it performs
+   system logins to the display being connected to and then runs a session
+   manager on behalf of the user (usually an X window manager). XDM then
+   waits for this program to exit, signaling that the user is done and should
+   be logged out of the display. At this point, XDM can display the login and
+   display chooser screens for the next user to login.
+
+     ----------------------------------------------------------------------
+
+  5.6.2 Using XDM
+
+   The XDM daemon program is located in /usr/X11R6/bin/xdm. This program can
+   be run at any time as root and it will start managing the X display on the
+   local machine. If XDM is to be run every time the machine boots up, a
+   convenient way to do this is by adding an entry to /etc/ttys. For more
+   information about the format and usage of this file, see Section 17.3.2.1.
+   There is a line in the default /etc/ttys file for running the XDM daemon
+   on a virtual terminal:
+
+ ttyv8   "/usr/X11R6/bin/xdm -nodaemon"  xterm   off secure
+
+   By default this entry is disabled; in order to enable it change the fifth
+   field from off to on and restart init(8) using the directions in Section
+   17.3.2.2. The first field, the name of the terminal this program will
+   manage, is ttyv8. This means that XDM will start running on the 9th
+   virtual terminal.
+
+     ----------------------------------------------------------------------
+
+  5.6.3 Configuring XDM
+
+   The XDM configuration directory is located in /usr/X11R6/lib/X11/xdm. In
+   this directory there are several files used to change the behavior and
+   appearance of XDM. Typically these files will be found:
+
+      File                             Description                           
+   Xaccess    Client authorization ruleset.                                  
+   Xresources Default X resource values.                                     
+   Xservers   List of remote and local displays to manage.                   
+   Xsession   Default session script for logins.                             
+   Xsetup_*   Script to launch applications before the login interface.      
+   xdm-config Global configuration for all displays running on this machine. 
+   xdm-errors Errors generated by the server program.                        
+   xdm-pid    The process ID of the currently running XDM.                   
+
+   Also in this directory are a few scripts and programs used to set up the
+   desktop when XDM is running. The purpose of each of these files will be
+   briefly described. The exact syntax and usage of all of these files is
+   described in xdm(1).
+
+   The default configuration is a simple rectangular login window with the
+   hostname of the machine displayed at the top in a large font and
+   ``Login:'' and ``Password:'' prompts below. This is a good starting point
+   for changing the look and feel of XDM screens.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.1 Xaccess
+
+   The protocol for connecting to XDM controlled displays is called the X
+   Display Manager Connection Protocol (XDMCP). This file is a ruleset for
+   controlling XDMCP connections from remote machines. By default, it allows
+   any client to connect, but that does not matter unless the xdm-config is
+   changed to listen for remote connections.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.2 Xresources
+
+   This is an application-defaults file for the display chooser and the login
+   screens. This is where the appearance of the login program can be
+   modified. The format is identical to the app-defaults file described in
+   the XFree86 documentation.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.3 Xservers
+
+   This is a list of the remote displays the chooser should provide as
+   choices.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.4 Xsession
+
+   This is the default session script for XDM to run after a user has logged
+   in. Normally each user will have a customized session script in
+   ~/.xsession that overrides this script.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.5 Xsetup_*
+
+   These will be run automatically before displaying the chooser or login
+   interfaces. There is a script for each display being used, named Xsetup_
+   followed by the local display number (for instance Xsetup_0). Typically
+   these scripts will run one or two programs in the background such as
+   xconsole.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.6 xdm-config
+
+   This contains settings in the form of app-defaults that are applicable to
+   every display that this installation manages.
+
+     ----------------------------------------------------------------------
+
+    5.6.3.7 xdm-errors
+
+   This contains the output of the X servers that XDM is trying to run. If a
+   display that XDM is trying to start hangs for some reason, this is a good
+   place to look for error messages. These messages are also written to the
+   user's ~/.xsession-errors file on a per-session basis.
+
+     ----------------------------------------------------------------------
+
+  5.6.4 Running a Network Display Server
+
+   In order for other clients to connect to the display server, edit the
+   access control rules, and enable the connection listener. By default these
+   are set to conservative values. To make XDM listen for connections, first
+   comment out a line in the xdm-config file:
+
+ ! SECURITY: do not listen for XDMCP or Chooser requests
+ ! Comment out this line if you want to manage X terminals with xdm
+ DisplayManager.requestPort:     0
+
+   and then restart XDM. Remember that comments in app-defaults files begin
+   with a ``!'' character, not the usual ``#''. More strict access controls
+   may be desired. Look at the example entries in Xaccess, and refer to the
+   xdm(1) manual page.
+
+     ----------------------------------------------------------------------
+
+  5.6.5 Replacements for XDM
+
+   Several replacements for the default XDM program exist. One of them, KDM
+   (bundled with KDE) is described later in this chapter. KDM offers many
+   visual improvements and cosmetic frills, as well as the functionality to
+   allow users to choose their window manager of choice at login time.
+
+     ----------------------------------------------------------------------
+
+5.7 Desktop Environments
+
+   Contributed by Valentino Vaschetto.
+
+   This section describes the different desktop environments available for X
+   on DragonFly . A ``desktop environment'' can mean anything ranging from a
+   simple window manager to a complete suite of desktop applications, such as
+   KDE or GNOME.
+
+     ----------------------------------------------------------------------
+
+  5.7.1 GNOME
+
+    5.7.1.1 About GNOME
+
+   GNOME is a user-friendly desktop environment that enables users to easily
+   use and configure their computers. GNOME includes a panel (for starting
+   applications and displaying status), a desktop (where data and
+   applications can be placed), a set of standard desktop tools and
+   applications, and a set of conventions that make it easy for applications
+   to cooperate and be consistent with each other. Users of other operating
+   systems or environments should feel right at home using the powerful
+   graphics-driven environment that GNOME provides.
+
+     ----------------------------------------------------------------------
+
+    5.7.1.2 Installing GNOME
+
+   The easiest way to install GNOME is with a package or through the ports
+   collection:
+
+   To install the GNOME package from the network, simply type:
+
+ # pkg_add gnome
+
+   To build GNOME from source, use the ports tree:
+
+ # cd /usr/ports/x11/gnome2
+ # make install clean
+
+   Once GNOME is installed, the X server must be told to start GNOME instead
+   of a default window manager. If a custom .xinitrc is already in place,
+   simply replace the line that starts the current window manager with one
+   that starts /usr/X11R6/bin/gnome-session instead. If nothing special has
+   been done to configuration file, then it is enough to simply type:
+
+ % echo "/usr/X11R6/bin/gnome-session" > ~/.xinitrc
+
+   Next, type startx, and the GNOME desktop environment will be started.
+
+     Note: If a display manager, like XDM, is being used, this will not work.
+     Instead, create an executable .xsession file with the same command in
+     it. To do this, edit the file and replace the existing window manager
+     command with /usr/X11R6/bin/gnome-session:
+
+ % echo "#!/bin/sh" > ~/.xsession
+ % echo "/usr/X11R6/bin/gnome-session" >> ~/.xsession
+ % chmod +x ~/.xsession
+
+   Another option is to configure the display manager to allow choosing the
+   window manager at login time; the section on KDE details explains how to
+   do this for kdm, the display manager of KDE.
+
+     ----------------------------------------------------------------------
+
+    5.7.1.3 Anti-aliased Fonts with GNOME
+
+   Starting with version 4.0.2, XFree86 supports anti-aliasing via its
+   ``RENDER'' extension. Gtk+ 2.0 and greater (the toolkit used by GNOME) can
+   make use of this functionality. Configuring anti-aliasing is described in
+   Section 5.5.3. So, with up-to-date software, anti-aliasing is possible
+   within the GNOME desktop. Just go to Applications->Desktop
+   Preferences->Font, and select either Best shapes, Best contrast, or
+   Subpixel smoothing (LCDs). For a Gtk+ application that is not part of the
+   GNOME desktop, set the environment variable GDK_USE_XFT to 1 before
+   launching the program.
+
+     ----------------------------------------------------------------------
+
+  5.7.2 KDE
+
+     ----------------------------------------------------------------------
+
+    5.7.2.1 About KDE
+
+   KDE is an easy to use contemporary desktop environment. Some of the things
+   that KDE brings to the user are:
+
+     * A beautiful contemporary desktop
+
+     * A desktop exhibiting complete network transparency
+
+     * An integrated help system allowing for convenient, consistent access
+       to help on the use of the KDE desktop and its applications
+
+     * Consistent look and feel of all KDE applications
+
+     * Standardized menu and toolbars, keybindings, color-schemes, etc.
+
+     * Internationalization: KDE is available in more than 40 languages
+
+     * Centralized consisted dialog driven desktop configuration
+
+     * A great number of useful KDE applications
+
+   KDE has an office application suite based on KDE's ``KParts'' technology
+   consisting of a spread-sheet, a presentation application, an organizer, a
+   news client and more. KDE also comes with a web browser called Konqueror,
+   which represents a solid competitor to other existing web browsers on UNIX
+   systems. More information on KDE can be found on the KDE website.
+
+     ----------------------------------------------------------------------
+
+    5.7.2.2 Installing KDE
+
+   Just as with GNOME or any other desktop environment, the easiest way to
+   install KDE is from a package or from the ports collection:
+
+   To install the KDE package from the network, simply type:
+
+ # pkg_add kde3
+
+   pkg_add(1) will automatically fetch the latest version of the application.
+
+   To build KDE from source, use the ports tree:
+
+ # cd /usr/ports/x11/kde3
+ # make install clean
+
+   After KDE has been installed, the X server must be told to launch this
+   application instead of the default window manager. This is accomplished by
+   editing the .xinitrc file:
+
+ % echo "exec startkde" > ~/.xinitrc
+
+   Now, whenever the X Window System is invoked with startx, KDE will be the
+   desktop.
+
+   If a display manager such as xdm is being used, the configuration is
+   slightly different. Edit the .xsession file instead. Instructions for kdm
+   are described later in this chapter.
+
+     ----------------------------------------------------------------------
+
+  5.7.3 More Details on KDE
+
+   Now that KDE is installed on the system, most things can be discovered
+   through the help pages, or just by pointing and clicking at various menus.
+   Windows or Mac(R) users will feel quite at home.
+
+   The best reference for KDE is the on-line documentation. KDE comes with
+   its own web browser, Konqueror, dozens of useful applications, and
+   extensive documentation. The remainder of this section discusses the
+   technical items that are difficult to learn by random exploration.
+
+     ----------------------------------------------------------------------
+
+    5.7.3.1 The KDE Display Manager
+
+   An administrator of a multi-user system may wish to have a graphical login
+   screen to welcome users. xdm can be used, as described earlier. However,
+   KDE includes an alternative, kdm, which is designed to look more
+   attractive and include more login-time options. In particular, users can
+   easily choose (via a menu) which desktop environment (KDE, GNOME, or
+   something else) to run after logging on.
+
+   To begin with, run the KDE control panel, kcontrol, as root. It is
+   generally considered unsafe to run the entire X environment as root.
+   Instead, run the window manager as a normal user, open a terminal window
+   (such as xterm or KDE's konsole), become root with su (the user must be in
+   the wheel group in /etc/group for this), and then type kcontrol.
+
+   Click on the icon on the left marked System, then on Login manager. On the
+   right there are various configurable options, which the KDE manual will
+   explain in greater detail. Click on sessions on the right. Click New type
+   to add various window managers and desktop environments. These are just
+   labels, so they can say KDE and GNOME rather than startkde or
+   gnome-session. Include a label failsafe.
+
+   Play with the other menus as well, they are mainly cosmetic and
+   self-explanatory. When you are done, click on Apply at the bottom, and
+   quit the control center.
+
+   To make sure kdm understands what the labels (KDE, GNOME etc) mean, edit
+   the files used by xdm.
+
+     Note: In KDE 2.2 this has changed: kdm now uses its own configuration
+     files. Please see the KDE 2.2 documentation for details.
+
+   In a terminal window, as root, edit the file
+   /usr/X11R6/lib/X11/xdm/Xsession. There is a section in the middle like
+   this:
+
+ case $# in
+ 1)
+         case $1 in
+         failsafe)
+                 exec xterm -geometry 80x24-0-0
+                 ;;
+         esac
+ esac
+
+   A few lines need to be added to this section. Assuming the labels from
+   used were ``KDE'' and ``GNOME'', use the following:
+
+ case $# in
+ 1)
+         case $1 in
+         kde)
+                 exec /usr/local/bin/startkde
+                 ;;
+         GNOME)
+                 exec /usr/X11R6/bin/gnome-session
+                 ;;
+         failsafe)
+                 exec xterm -geometry 80x24-0-0
+                 ;;
+         esac
+ esac
+
+   For the KDE login-time desktop background to be honored, the following
+   line needs to be added to /usr/X11R6/lib/X11/xdm/Xsetup_0:
+
+ /usr/local/bin/kdmdesktop
+
+   Now, make sure kdm is listed in /etc/ttys to be started at the next
+   bootup. To do this, simply follow the instructions from the previous
+   section on xdm and replace references to the /usr/X11R6/bin/xdm program
+   with /usr/local/bin/kdm.
+
+     ----------------------------------------------------------------------
+
+    5.7.3.2 Anti-aliased Fonts
+
+   Starting with version 4.0.2, XFree86 supports anti-aliasing via its
+   ``RENDER'' extension, and starting with version 2.3, Qt (the toolkit used
+   by KDE) supports this extension. Configuring this is described in Section
+   5.5.3 on antialiasing X11 fonts. So, with up-to-date software,
+   anti-aliasing is possible on a KDE desktop. Just go to the KDE menu, go to
+   Preferences->Look and Feel->Fonts, and click on the check box Use
+   Anti-Aliasing for Fonts and Icons. For a Qt application which is not part
+   of KDE, the environment variable QT_XFT needs to be set to true before
+   starting the program.
+
+     ----------------------------------------------------------------------
+
+  5.7.4 XFce
+
+    5.7.4.1 About XFce
+
+   XFce is a desktop environment based on the GTK toolkit used by GNOME, but
+   is much more lightweight and meant for those who want a simple, efficient
+   desktop which is nevertheless easy to use and configure. Visually, it
+   looks very much like CDE, found on commercial UNIX systems. Some of XFce's
+   features are:
+
+     * A simple, easy-to-handle desktop
+
+     * Fully configurable via mouse, with drag and drop, etc
+
+     * Main panel similar to CDE, with menus, applets and applications
+       launchers
+
+     * Integrated window manager, file manager, sound manager, GNOME
+       compliance module, and other things
+
+     * Themeable (since it uses GTK)
+
+     * Fast, light and efficient: ideal for older/slower machines or machines
+       with memory limitations
+
+   More information on XFce can be found on the XFce website.
+
+     ----------------------------------------------------------------------
+
+    5.7.4.2 Installing XFce
+
+   A binary package for XFce exists (at the time of writing). To install,
+   simply type:
+
+ # pkg_add xfce4
+
+   Alternatively, to build from source, use the ports collection:
+
+ # cd /usr/ports/x11-wm/xfce4
+ # make install clean
+
+   Now, tell the X server to launch XFce the next time X is started. Simply
+   type this:
+
+ % echo "/usr/X11R6/bin/startxfce4" > ~/.xinitrc
+
+   The next time X is started, XFce will be the desktop. As before, if a
+   display manager like xdm is being used, create an .xsession, as described
+   in the section on GNOME, but with the /usr/X11R6/bin/startxfce4 command;
+   or, configure the display manager to allow choosing a desktop at login
+   time, as explained in the section on kdm.
+
+                           II. System Administration
+
+   The remaining chapters of the DragonFly Handbook cover all aspects of
+   DragonFly system administration. Each chapter starts by describing what
+   you will learn as a result of reading the chapter, and also details what
+   you are expected to know before tackling the material.
+
+   These chapters are designed to be read when you need the information. You
+   do not have to read them in any particular order, nor do you need to read
+   all of them before you can begin using DragonFly.
+
+   Table of Contents
+
+   6 Configuration and Tuning
+
+   7 The DragonFly Booting Process
+
+   8 Users and Basic Account Management
+
+   9 Configuring the DragonFly Kernel
+
+   10 Security
+
+   11 Printing
+
+   12 Storage
+
+   13 The Vinum Volume Manager
+
+   14 Localization - I18N/L10N Usage and Setup
+
+   15 Desktop Applications
+
+   16 Multimedia
+
+   17 Serial Communications
+
+   18 PPP and SLIP
+
+   19 Advanced Networking
+
+   20 Electronic Mail
+
+   21 Updating DragonFly
+
+   22 Linux Binary Compatibility
+
+     ----------------------------------------------------------------------
+
+                       Chapter 6 Configuration and Tuning
+
+   Written by Chern Lee. Based on a tutorial written by Mike Smith. Also
+   based on tuning(7) written by Matt Dillon.
+
+6.1 Synopsis
+
+   One of the important aspects of DragonFly is system configuration. Correct
+   system configuration will help prevent headaches during future upgrades.
+   This chapter will explain much of the DragonFly configuration process,
+   including some of the parameters which can be set to tune a DragonFly
+   system.
+
+   After reading this chapter, you will know:
+
+     * How to efficiently work with file systems and swap partitions.
+
+     * The basics of rc.conf configuration and rc.d startup systems.
+
+     * How to configure and test a network card.
+
+     * How to configure virtual hosts on your network devices.
+
+     * How to use the various configuration files in /etc.
+
+     * How to tune DragonFly using sysctl variables.
+
+     * How to tune disk performance and modify kernel limitations.
+
+   Before reading this chapter, you should:
+
+     * Understand UNIX and DragonFly basics (Chapter 3).
+
+     * Be familiar with the basics of kernel configuration/compilation
+       (Chapter 9).
+
+     ----------------------------------------------------------------------
+
+6.2 Initial Configuration
+
+  6.2.1 Partition Layout
+
+     ----------------------------------------------------------------------
+
+    6.2.1.1 Base Partitions
+
+   When laying out file systems with disklabel(8) remember that hard drives
+   transfer data faster from the outer tracks to the inner. Thus smaller and
+   heavier-accessed file systems should be closer to the outside of the
+   drive, while larger partitions like /usr should be placed toward the
+   inner. It is a good idea to create partitions in a similar order to: root,
+   swap, /var, /usr.
+
+   The size of /var reflects the intended machine usage. /var is used to hold
+   mailboxes, log files, and printer spools. Mailboxes and log files can grow
+   to unexpected sizes depending on how many users exist and how long log
+   files are kept. Most users would never require a gigabyte, but remember
+   that /var/tmp must be large enough to contain packages.
+
+   The /usr partition holds much of the files required to support the system,
+   the pkgsrc collection (recommended) and the source code (optional). At
+   least 2 gigabytes would be recommended for this partition.
+
+   When selecting partition sizes, keep the space requirements in mind.
+   Running out of space in one partition while barely using another can be a
+   hassle.
+
+     ----------------------------------------------------------------------
+
+    6.2.1.2 Swap Partition
+
+   As a rule of thumb, the swap partition should be about double the size of
+   system memory (RAM). For example, if the machine has 128 megabytes of
+   memory, the swap file should be 256 megabytes. Systems with less memory
+   may perform better with more swap. Less than 256 megabytes of swap is not
+   recommended and memory expansion should be considered. The kernel's VM
+   paging algorithms are tuned to perform best when the swap partition is at
+   least two times the size of main memory. Configuring too little swap can
+   lead to inefficiencies in the VM page scanning code and might create
+   issues later if more memory is added.
+
+   On larger systems with multiple SCSI disks (or multiple IDE disks
+   operating on different controllers), it is recommend that a swap is
+   configured on each drive (up to four drives). The swap partitions should
+   be approximately the same size. The kernel can handle arbitrary sizes but
+   internal data structures scale to 4 times the largest swap partition.
+   Keeping the swap partitions near the same size will allow the kernel to
+   optimally stripe swap space across disks. Large swap sizes are fine, even
+   if swap is not used much. It might be easier to recover from a runaway
+   program before being forced to reboot.
+
+     ----------------------------------------------------------------------
+
+    6.2.1.3 Why Partition?
+
+   Several users think a single large partition will be fine, but there are
+   several reasons why this is a bad idea. First, each partition has
+   different operational characteristics and separating them allows the file
+   system to tune accordingly. For example, the root and /usr partitions are
+   read-mostly, without much writing. While a lot of reading and writing
+   could occur in /var and /var/tmp.
+
+   By properly partitioning a system, fragmentation introduced in the smaller
+   write heavy partitions will not bleed over into the mostly-read
+   partitions. Keeping the write-loaded partitions closer to the disk's edge,
+   will increase I/O performance in the partitions where it occurs the most.
+   Now while I/O performance in the larger partitions may be needed, shifting
+   them more toward the edge of the disk will not lead to a significant
+   performance improvement over moving /var to the edge. Finally, there are
+   safety concerns. A smaller, neater root partition which is mostly
+   read-only has a greater chance of surviving a bad crash.
+
+     ----------------------------------------------------------------------
+
+6.3 Core Configuration
+
+   The principal location for system configuration information is within
+   /etc/rc.conf. This file contains a wide range of configuration
+   information, principally used at system startup to configure the system.
+   Its name directly implies this; it is configuration information for the
+   rc* files.
+
+   An administrator should make entries in the rc.conf file to override the
+   default settings from /etc/defaults/rc.conf. The defaults file should not
+   be copied verbatim to /etc - it contains default values, not examples. All
+   system-specific changes should be made in the rc.conf file itself.
+
+   A number of strategies may be applied in clustered applications to
+   separate site-wide configuration from system-specific configuration in
+   order to keep administration overhead down. The recommended approach is to
+   place site-wide configuration into another file, such as
+   /etc/rc.conf.site, and then include this file into /etc/rc.conf, which
+   will contain only system-specific information.
+
+   As rc.conf is read by sh(1) it is trivial to achieve this. For example:
+
+     * rc.conf:
+
+         . rc.conf.site
+         hostname="node15.example.com"
+         network_interfaces="fxp0 lo0"
+         ifconfig_fxp0="inet 10.1.1.1"
+
+     * rc.conf.site:
+
+         defaultrouter="10.1.1.254"
+         saver="daemon"
+         blanktime="100"
+
+   The rc.conf.site file can then be distributed to every system using rsync
+   or a similar program, while the rc.conf file remains unique.
+
+   Upgrading the system using make world will not overwrite the rc.conf file,
+   so system configuration information will not be lost.
+
+     ----------------------------------------------------------------------
+
+6.4 Application Configuration
+
+   Typically, installed applications have their own configuration files, with
+   their own syntax, etc. It is important that these files be kept separate
+   from the base system, so that they may be easily located and managed by
+   the package management tools.
+
+   Typically, these files are installed in /usr/local/etc. In the case where
+   an application has a large number of configuration files, a subdirectory
+   will be created to hold them.
+
+   Normally, when a port or package is installed, sample configuration files
+   are also installed. These are usually identified with a .default suffix.
+   If there are no existing configuration files for the application, they
+   will be created by copying the .default files.
+
+   For example, consider the contents of the directory /usr/local/etc/apache:
+
+ -rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf
+ -rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf.default
+ -rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf
+ -rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf.default
+ -rw-r--r--  1 root  wheel  12205 May 20  1998 magic
+ -rw-r--r--  1 root  wheel  12205 May 20  1998 magic.default
+ -rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types
+ -rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types.default
+ -rw-r--r--  1 root  wheel   7980 May 20  1998 srm.conf
+ -rw-r--r--  1 root  wheel   7933 May 20  1998 srm.conf.default
+
+   The file sizes show that only the srm.conf file has been changed. A later
+   update of the Apache port would not overwrite this changed file.
+
+     ----------------------------------------------------------------------
+
+6.5 Starting Services
+
+   It is common for a system to host a number of services. These may be
+   started in several different fashions, each having different advantages.
+
+   Software installed from a port or the packages collection will often place
+   a script in /usr/local/etc/rc.d which is invoked at system startup with a
+   start argument, and at system shutdown with a stop argument. This is the
+   recommended way for starting system-wide services that are to be run as
+   root, or that expect to be started as root. These scripts are registered
+   as part of the installation of the package, and will be removed when the
+   package is removed.
+
+   A generic startup script in /usr/local/etc/rc.d looks like:
+
+ #!/bin/sh
+ echo -n ' FooBar'
+
+ case "$1" in
+ start)
+         /usr/local/bin/foobar
+         ;;
+ stop)
+         kill -9 `cat /var/run/foobar.pid`
+         ;;
+ *)
+         echo "Usage: `basename $0` {start|stop}" >&2
+         exit 64
+         ;;
+ esac
+
+ exit 0
+    
+
+   The startup scripts of DragonFly will look in /usr/local/etc/rc.d for
+   scripts that have an .sh extension and are executable by root. Those
+   scripts that are found are called with an option start at startup, and
+   stop at shutdown to allow them to carry out their purpose. So if you
+   wanted the above sample script to be picked up and run at the proper time
+   during system startup, you should save it to a file called FooBar.sh in
+   /usr/local/etc/rc.d and make sure it is executable. You can make a shell
+   script executable with chmod(1) as shown below:
+
+ # chmod 755 FooBar.sh
+
+   Some services expect to be invoked by inetd(8) when a connection is
+   received on a suitable port. This is common for mail reader servers (POP
+   and IMAP, etc.). These services are enabled by editing the file
+   /etc/inetd.conf. See inetd(8) for details on editing this file.
+
+   Some additional system services may not be covered by the toggles in
+   /etc/rc.conf. These are traditionally enabled by placing the command(s) to
+   invoke them in /etc/rc.local (which does not exist by default). Note that
+   rc.local is generally regarded as the location of last resort; if there is
+   a better place to start a service, do it there.
+
+     Note: Do not place any commands in /etc/rc.conf. To start daemons, or
+     run any commands at boot time, place a script in /usr/local/etc/rc.d
+     instead.
+
+   It is also possible to use the cron(8) daemon to start system services.
+   This approach has a number of advantages, not least being that because
+   cron(8) runs these processes as the owner of the crontab, services may be
+   started and maintained by non-root users.
+
+   This takes advantage of a feature of cron(8): the time specification may
+   be replaced by @reboot, which will cause the job to be run when cron(8) is
+   started shortly after system boot.
+
+     ----------------------------------------------------------------------
+
+6.6 Configuring the cron Utility
+
+   Contributed by Tom Rhodes.
+
+   One of the most useful utilities in DragonFly is cron(8). The cron utility
+   runs in the background and constantly checks the /etc/crontab file. The
+   cron utility also checks the /var/cron/tabs directory, in search of new
+   crontab files. These crontab files store information about specific
+   functions which cron is supposed to perform at certain times.
+
+   The cron utility uses two different types of configuration files, the
+   system crontab and user crontabs. The only difference between these two
+   formats is the sixth field. In the system crontab, the sixth field is the
+   name of a user for the command to run as. This gives the system crontab
+   the ability to run commands as any user. In a user crontab, the sixth
+   field is the command to run, and all commands run as the user who created
+   the crontab; this is an important security feature.
+
+     Note: User crontabs allow individual users to schedule tasks without the
+     need for root privileges. Commands in a user's crontab run with the
+     permissions of the user who owns the crontab.
+
+     The root user can have a user crontab just like any other user. This one
+     is different from /etc/crontab (the system crontab). Because of the
+     system crontab, there's usually no need to create a user crontab for
+     root.
+
+   Let us take a look at the /etc/crontab file (the system crontab):
+
+ # /etc/crontab - root's crontab for DragonFly
+ #
+ # (1)
+ #
+ SHELL=/bin/sh
+ PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin (2)
+ HOME=/var/log
+ #
+ #
+ #minute hour    mday    month   wday    who     command (3)
+ #
+ #
+ */5     *       *       *       *       root    /usr/libexec/atrun (4)
+
+   (1)
+           Like most DragonFly configuration files, the # character
+           represents a comment. A comment can be placed in the file as a
+           reminder of what and why a desired action is performed. Comments
+           cannot be on the same line as a command or else they will be
+           interpreted as part of the command; they must be on a new line.
+           Blank lines are ignored.
+   (2)
+           First, the environment must be defined. The equals (=) character
+           is used to define any environment settings, as with this example
+           where it is used for the SHELL, PATH, and HOME options. If the
+           shell line is omitted, cron will use the default, which is sh. If
+           the PATH variable is omitted, no default will be used and file
+           locations will need to be absolute. If HOME is omitted, cron will
+           use the invoking users home directory.
+   (3)
+           This line defines a total of seven fields. Listed here are the
+           values minute, hour, mday, month, wday, who, and command. These
+           are almost all self explanatory. minute is the time in minutes the
+           command will be run. hour is similar to the minute option, just in
+           hours. mday stands for day of the month. month is similar to hour
+           and minute, as it designates the month. The wday option stands for
+           day of the week. All these fields must be numeric values, and
+           follow the twenty-four hour clock. The who field is special, and
+           only exists in the /etc/crontab file. This field specifies which
+           user the command should be run as. When a user installs his or her
+           crontab file, they will not have this option. Finally, the command
+           option is listed. This is the last field, so naturally it should
+           designate the command to be executed.
+   (4)
+           This last line will define the values discussed above. Notice here
+           we have a */5 listing, followed by several more * characters.
+           These * characters mean ``first-last'', and can be interpreted as
+           every time. So, judging by this line, it is apparent that the
+           atrun command is to be invoked by root every five minutes
+           regardless of what day or month it is. For more information on the
+           atrun command, see the atrun(8) manual page.
+
+           Commands can have any number of flags passed to them; however,
+           commands which extend to multiple lines need to be broken with the
+           backslash ``\'' continuation character.
+
+   This is the basic set up for every crontab file, although there is one
+   thing different about this one. Field number six, where we specified the
+   username, only exists in the system /etc/crontab file. This field should
+   be omitted for individual user crontab files.
+
+     ----------------------------------------------------------------------
+
+  6.6.1 Installing a Crontab
+
+     Important: You must not use the procedure described here to edit/install
+     the system crontab. Simply use your favorite editor: the cron utility
+     will notice that the file has changed and immediately begin using the
+     updated version. If you use crontab to load the /etc/crontab file you
+     may get an error like ``root: not found'' because of the system
+     crontab's additional user field.
+
+   To install a freshly written user crontab, first use your favorite editor
+   to create a file in the proper format, and then use the crontab utility.
+   The most common usage is:
+
+ % crontab crontab-file
+
+   In this example, crontab-file is the filename of a crontab that was
+   previously created.
+
+   There is also an option to list installed crontab files: just pass the -l
+   option to crontab and look over the output.
+
+   For users who wish to begin their own crontab file from scratch, without
+   the use of a template, the crontab -e option is available. This will
+   invoke the selected editor with an empty file. When the file is saved, it
+   will be automatically installed by the crontab command.
+
+   If you later want to remove your user crontab completely, use crontab with
+   the -r option.
+
+     ----------------------------------------------------------------------
+
+6.7 Using rc under DragonFly
+
+   Contributed by Tom Rhodes.
+
+   DragonFly uses the NetBSD rc.d system for system initialization. Users
+   should notice the files listed in the /etc/rc.d directory. Many of these
+   files are for basic services which can be controlled with the start, stop,
+   and restart options. For instance, sshd(8) can be restarted with the
+   following command:
+
+ # /etc/rc.d/sshd restart
+
+   This procedure is similar for other services. Of course, services are
+   usually started automatically as specified in rc.conf(5). For example,
+   enabling the Network Address Translation daemon at startup is as simple as
+   adding the following line to /etc/rc.conf:
+
+ natd_enable="YES"
+
+   If a natd_enable="NO" line is already present, then simply change the NO
+   to YES. The rc scripts will automatically load any other dependent
+   services during the next reboot, as described below.
+
+   Since the rc.d system is primarily intended to start/stop services at
+   system startup/shutdown time, the standard start, stop and restart options
+   will only perform their action if the appropriate /etc/rc.conf variables
+   are set. For instance the above sshd restart command will only work if
+   sshd_enable is set to YES in /etc/rc.conf. To start, stop or restart a
+   service regardless of the settings in /etc/rc.conf, the commands should be
+   prefixed with ``force''. For instance to restart sshd regardless of the
+   current /etc/rc.conf setting, execute the following command:
+
+ # /etc/rc.d/sshd forcerestart
+
+   It is easy to check if a service is enabled in /etc/rc.conf by running the
+   appropriate rc.d script with the option rcvar. Thus, an administrator can
+   check that sshd is in fact enabled in /etc/rc.conf by running:
+
+ # /etc/rc.d/sshd rcvar
+ # sshd
+ $sshd_enable=YES
+
+     Note: The second line (# sshd) is the output from the rc.d script, not a
+     root prompt.
+
+   To determine if a service is running, a status option is available. For
+   instance to verify that sshd is actually started:
+
+ # /etc/rc.d/sshd status
+ sshd is running as pid 433.
+
+   It is also possible to reload a service. This will attempt to send a
+   signal to an individual service, forcing the service to reload its
+   configuration files. In most cases this means sending the service a SIGHUP
+   signal.
+
+   The rcNG structure is used both for network services and system
+   initialization. Some services are run only at boot; and the RCNG system is
+   what triggers them.
+
+   Many system services depend on other services to function properly. For
+   example, NIS and other RPC-based services may fail to start until after
+   the rpcbind (portmapper) service has started. To resolve this issue,
+   information about dependencies and other meta-data is included in the
+   comments at the top of each startup script. The rcorder(8) program is then
+   used to parse these comments during system initialization to determine the
+   order in which system services should be invoked to satisfy the
+   dependencies. The following words may be included at the top of each
+   startup file:
+
+     * PROVIDE: Specifies the services this file provides.
+
+     * REQUIRE: Lists services which are required for this service. This file
+       will run after the specified services.
+
+     * BEFORE: Lists services which depend on this service. This file will
+       run before the specified services.
+
+     * KEYWORD: When rcorder(8) uses the -k option, then only the rc.d files
+       matching this keyword are used. [5] For example, when using -k
+       shutdown, only the rc.d scripts defining the shutdown keyword are
+       used.
+
+       With the -s option, rcorder(8) will skip any rc.d script defining the
+       corresponding keyword to skip. For example, scripts defining the
+       nostart keyword are skipped at boot time.
+
+   By using this method, an administrator can easily control system services
+   without the hassle of ``runlevels'' like some other UNIX operating
+   systems.
+
+   Additional information about the DragonFly rc.d system can be found in the
+   rc(8), rc.conf(5), and rc.subr(8) manual pages.
+
+     ----------------------------------------------------------------------
+
+6.8 Setting Up Network Interface Cards
+
+   Contributed by Marc Fonvieille.
+
+   Nowadays we can not think about a computer without thinking about a
+   network connection. Adding and configuring a network card is a common task
+   for any DragonFly administrator.
+
+     ----------------------------------------------------------------------
+
+  6.8.1 Locating the Correct Driver
+
+   Before you begin, you should know the model of the card you have, the chip
+   it uses, and whether it is a PCI or ISA card. DragonFly supports a wide
+   variety of both PCI and ISA cards. Check the Hardware Compatibility List
+   for your release to see if your card is supported.
+
+   Once you are sure your card is supported, you need to determine the proper
+   driver for the card. The file /usr/src/sys/i386/conf/LINT will give you
+   the list of network interfaces drivers with some information about the
+   supported chipsets/cards. If you have doubts about which driver is the
+   correct one, read the manual page of the driver. The manual page will give
+   you more information about the supported hardware and even the possible
+   problems that could occur.
+
+   If you own a common card, most of the time you will not have to look very
+   hard for a driver. Drivers for common network cards are present in the
+   GENERIC kernel, so your card should show up during boot, like so:
+
+ dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xd3800000-0xd38
+ 000ff irq 15 at device 11.0 on pci0
+ dc0: Ethernet address: 00:a0:cc:da:da:da
+ miibus0: <MII bus> on dc0
+ ukphy0: <Generic IEEE 802.3u media interface> on miibus0
+ ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
+ dc1: <82c169 PNIC 10/100BaseTX> port 0x9800-0x98ff mem 0xd3000000-0xd30
+ 000ff irq 11 at device 12.0 on pci0
+ dc1: Ethernet address: 00:a0:cc:da:da:db
+ miibus1: <MII bus> on dc1
+ ukphy1: <Generic IEEE 802.3u media interface> on miibus1
+ ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
+
+   In this example, we see that two cards using the dc(4) driver are present
+   on the system.
+
+   To use your network card, you will need to load the proper driver. This
+   may be accomplished in one of two ways. The easiest way is to simply load
+   a kernel module for your network card with kldload(8). A module is not
+   available for all network card drivers (ISA cards and cards using the
+   ed(4) driver, for example). Alternatively, you may statically compile the
+   support for your card into your kernel. Check /usr/src/sys/i386/conf/LINT
+   and the manual page of the driver to know what to add in your kernel
+   configuration file. For more information about recompiling your kernel,
+   please see Chapter 9. If your card was detected at boot by your kernel
+   (GENERIC) you do not have to build a new kernel.
+
+     ----------------------------------------------------------------------
+
+  6.8.2 Configuring the Network Card
+
+   Once the right driver is loaded for the network card, the card needs to be
+   configured. As with many other things, the network card may have been
+   configured at installation time.
+
+   To display the configuration for the network interfaces on your system,
+   enter the following command:
+
+ % ifconfig
+ dc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+         inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
+         ether 00:a0:cc:da:da:da
+         media: Ethernet autoselect (100baseTX <full-duplex>)
+         status: active
+ dc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
+         inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
+         ether 00:a0:cc:da:da:db
+         media: Ethernet 10baseT/UTP
+         status: no carrier
+ lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
+ lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
+         inet 127.0.0.1 netmask 0xff000000
+ tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
+
+     Note: Note that entries concerning IPv6 (inet6 etc.) were omitted in
+     this example.
+
+   In this example, the following devices were displayed:
+
+     * dc0: The first Ethernet interface
+
+     * dc1: The second Ethernet interface
+
+     * lp0: The parallel port interface
+
+     * lo0: The loopback device
+
+     * tun0: The tunnel device used by ppp
+
+   DragonFly uses the driver name followed by the order in which one the card
+   is detected at the kernel boot to name the network card, starting the
+   count at zero. For example, sis2 would be the third network card on the
+   system using the sis(4) driver.
+
+   In this example, the dc0 device is up and running. The key indicators are:
+
+    1. UP means that the card is configured and ready.
+
+    2. The card has an Internet (inet) address (in this case 192.168.1.3).
+
+    3. It has a valid subnet mask (netmask; 0xffffff00 is the same as
+       255.255.255.0).
+
+    4. It has a valid broadcast address (in this case, 192.168.1.255).
+
+    5. The MAC address of the card (ether) is 00:a0:cc:da:da:da
+
+    6. The physical media selection is on autoselection mode (media: Ethernet
+       autoselect (100baseTX <full-duplex>)). We see that dc1 was configured
+       to run with 10baseT/UTP media. For more information on available media
+       types for a driver, please refer to its manual page.
+
+    7. The status of the link (status) is active, i.e. the carrier is
+       detected. For dc1, we see status: no carrier. This is normal when an
+       Ethernet cable is not plugged into the card.
+
+   If the ifconfig(8) output had shown something similar to:
+
+ dc0: flags=8843<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
+                 ether 00:a0:cc:da:da:da
+
+   it would indicate the card has not been configured.
+
+   To configure your card, you need root privileges. The network card
+   configuration can be done from the command line with ifconfig(8) as root.
+
+ # ifconfig dc0 inet 192.168.1.3 netmask 255.255.255.0
+
+   Manually configuring the care has the disadvantage that you would have to
+   do it after each reboot of the system. The file /etc/rc.conf is where to
+   add the network card's configuration.
+
+   Open /etc/rc.conf in your favorite editor. You need to add a line for each
+   network card present on the system, for example in our case, we added
+   these lines:
+
+ ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"
+ ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"
+
+   You have to replace dc0, dc1, and so on, with the correct device for your
+   cards, and the addresses with the proper ones. You should read the card
+   driver and ifconfig(8) manual pages for more details about the allowed
+   options and also rc.conf(5) manual page for more information on the syntax
+   of /etc/rc.conf.
+
+   If you configured the network during installation, some lines about the
+   network card(s) may be already present. Double check /etc/rc.conf before
+   adding any lines.
+
+   You will also have to edit the file /etc/hosts to add the names and the IP
+   addresses of various machines of the LAN, if they are not already there.
+   For more information please refer to hosts(5) and to
+   /usr/share/examples/etc/hosts.
+
+     ----------------------------------------------------------------------
+
+  6.8.3 Testing and Troubleshooting
+
+   Once you have made the necessary changes in /etc/rc.conf, you should
+   reboot your system. This will allow the change(s) to the interface(s) to
+   be applied, and verify that the system restarts without any configuration
+   errors.
+
+   Once the system has been rebooted, you should test the network interfaces.
+
+     ----------------------------------------------------------------------
+
+    6.8.3.1 Testing the Ethernet Card
+
+   To verify that an Ethernet card is configured correctly, you have to try
+   two things. First, ping the interface itself, and then ping another
+   machine on the LAN.
+
+   First test the local interface:
+
+ % ping -c5 192.168.1.3
+ PING 192.168.1.3 (192.168.1.3): 56 data bytes
+ 64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms
+ 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms
+ 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms
+ 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms
+ 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms
+
+ --- 192.168.1.3 ping statistics ---
+ 5 packets transmitted, 5 packets received, 0% packet loss
+ round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms
+
+   Now we have to ping another machine on the LAN:
+
+ % ping -c5 192.168.1.2
+ PING 192.168.1.2 (192.168.1.2): 56 data bytes
+ 64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms
+ 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms
+ 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms
+ 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms
+ 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms
+
+ --- 192.168.1.2 ping statistics ---
+ 5 packets transmitted, 5 packets received, 0% packet loss
+ round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms
+
+   You could also use the machine name instead of 192.168.1.2 if you have set
+   up the /etc/hosts file.
+
+     ----------------------------------------------------------------------
+
+    6.8.3.2 Troubleshooting
+
+   Troubleshooting hardware and software configurations is always a pain, and
+   a pain which can be alleviated by checking the simple things first. Is
+   your network cable plugged in? Have you properly configured the network
+   services? Did you configure the firewall correctly? Is the card you are
+   using supported by DragonFly? Always check the hardware notes before
+   sending off a bug report. Update your version of DragonFly to the latest
+   PREVIEW version. Check the mailing list archives, or perhaps search the
+   Internet.
+
+   If the card works, yet performance is poor, it would be worthwhile to read
+   over the tuning(7) manual page. You can also check the network
+   configuration as incorrect network settings can cause slow connections.
+
+   Some users experience one or two ``device timeouts'', which is normal for
+   some cards. If they continue, or are bothersome, you may wish to be sure
+   the device is not conflicting with another device. Double check the cable
+   connections. Perhaps you may just need to get another card.
+
+   At times, users see a few ``watchdog timeout'' errors. The first thing to
+   do here is to check your network cable. Many cards require a PCI slot
+   which supports Bus Mastering. On some old motherboards, only one PCI slot
+   allows it (usually slot 0). Check the network card and the motherboard
+   documentation to determine if that may be the problem.
+
+   ``No route to host'' messages occur if the system is unable to route a
+   packet to the destination host. This can happen if no default route is
+   specified, or if a cable is unplugged. Check the output of netstat -rn and
+   make sure there is a valid route to the host you are trying to reach. If
+   there is not, read on to Chapter 19.
+
+   ``ping: sendto: Permission denied'' error messages are often caused by a
+   misconfigured firewall. If ipfw is enabled in the kernel but no rules have
+   been defined, then the default policy is to deny all traffic, even ping
+   requests! Read on to Section 10.7 for more information.
+
+   Sometimes performance of the card is poor, or below average. In these
+   cases it is best to set the media selection mode from autoselect to the
+   correct media selection. While this usually works for most hardware, it
+   may not resolve this issue for everyone. Again, check all the network
+   settings, and read over the tuning(7) manual page.
+
+     ----------------------------------------------------------------------
+
+6.9 Virtual Hosts
+
+   A very common use of DragonFly is virtual site hosting, where one server
+   appears to the network as many servers. This is achieved by assigning
+   multiple network addresses to a single interface.
+
+   A given network interface has one ``real'' address, and may have any
+   number of ``alias'' addresses. These aliases are normally added by placing
+   alias entries in /etc/rc.conf.
+
+   An alias entry for the interface fxp0 looks like:
+
+ ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"
+
+   Note that alias entries must start with alias0 and proceed upwards in
+   order, (for example, _alias1, _alias2, and so on). The configuration
+   process will stop at the first missing number.
+
+   The calculation of alias netmasks is important, but fortunately quite
+   simple. For a given interface, there must be one address which correctly
+   represents the network's netmask. Any other addresses which fall within
+   this network must have a netmask of all 1s (expressed as either
+   255.255.255.255 or 0xffffffff).
+
+   For example, consider the case where the fxp0 interface is connected to
+   two networks, the 10.1.1.0 network with a netmask of 255.255.255.0 and the
+   202.0.75.16 network with a netmask of 255.255.255.240. We want the system
+   to appear at 10.1.1.1 through 10.1.1.5 and at 202.0.75.17 through
+   202.0.75.20. As noted above, only the first address in a given network
+   range (in this case, 10.0.1.1 and 202.0.75.17) should have a real netmask;
+   all the rest (10.1.1.2 through 10.1.1.5 and 202.0.75.18 through
+   202.0.75.20) must be configured with a netmask of 255.255.255.255.
+
+   The following entries configure the adapter correctly for this
+   arrangement:
+
+  ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
+  ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
+  ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
+  ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
+  ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
+  ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
+  ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
+  ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
+  ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"
+
+     ----------------------------------------------------------------------
+
+6.10 Configuration Files
+
+  6.10.1 /etc Layout
+
+   There are a number of directories in which configuration information is
+   kept. These include:
+
+   /etc                Generic system configuration information; data here is 
+                       system-specific.                                       
+   /etc/defaults       Default versions of system configuration files.        
+   /etc/mail           Extra sendmail(8) configuration, other MTA             
+                       configuration files.                                   
+   /etc/ppp            Configuration for both user- and kernel-ppp programs.  
+   /etc/namedb         Default location for named(8) data. Normally           
+                       named.conf and zone files are stored here.             
+   /usr/local/etc      Configuration files for installed applications. May    
+                       contain per-application subdirectories.                
+   /usr/local/etc/rc.d Start/stop scripts for installed applications.         
+                       Automatically generated system-specific database       
+   /var/db             files, such as the package database, the locate        
+                       database, and so on                                    
+
+     ----------------------------------------------------------------------
+
+  6.10.2 Hostnames
+
+     ----------------------------------------------------------------------
+
+    6.10.2.1 /etc/resolv.conf
+
+   /etc/resolv.conf dictates how DragonFly's resolver accesses the Internet
+   Domain Name System (DNS).
+
+   The most common entries to resolv.conf are:
+
+              The IP address of a name server the resolver should query. The  
+   nameserver servers are queried in the order listed with a maximum of       
+              three.                                                          
+   search     Search list for hostname lookup. This is normally determined by 
+              the domain of the local hostname.                               
+   domain     The local domain name.                                          
+
+   A typical resolv.conf:
+
+ search example.com
+ nameserver 147.11.1.11
+ nameserver 147.11.100.30
+
+     Note: Only one of the search and domain options should be used.
+
+   If you are using DHCP, dhclient(8) usually rewrites resolv.conf with
+   information received from the DHCP server.
+
+     ----------------------------------------------------------------------
+
+    6.10.2.2 /etc/hosts
+
+   /etc/hosts is a simple text database reminiscent of the old Internet. It
+   works in conjunction with DNS and NIS providing name to IP address
+   mappings. Local computers connected via a LAN can be placed in here for
+   simplistic naming purposes instead of setting up a named(8) server.
+   Additionally, /etc/hosts can be used to provide a local record of Internet
+   names, reducing the need to query externally for commonly accessed names.
+
+ #
+ # Host Database
+ # This file should contain the addresses and aliases
+ # for local hosts that share this file.
+ # In the presence of the domain name service or NIS, this file may
+ # not be consulted at all; see /etc/nsswitch.conf for the resolution order.
+ #
+ #
+ ::1                     localhost localhost.my.domain myname.my.domain
+ 127.0.0.1               localhost localhost.my.domain myname.my.domain
+
+ #
+ # Imaginary network.
+ #10.0.0.2               myname.my.domain myname
+ #10.0.0.3               myfriend.my.domain myfriend
+ #
+ # According to RFC 1918, you can use the following IP networks for
+ # private nets which will never be connected to the Internet:
+ #
+ #       10.0.0.0        -   10.255.255.255
+ #       172.16.0.0      -   172.31.255.255
+ #       192.168.0.0     -   192.168.255.255
+ #
+ # In case you want to be able to connect to the Internet, you need
+ # real official assigned numbers.  PLEASE PLEASE PLEASE do not try
+ # to invent your own network numbers but instead get one from your
+ # network provider (if any) or from the Internet Registry (ftp to
+ # rs.internic.net, directory `/templates').
+ #
+
+   /etc/hosts takes on the simple format of:
+
+ [Internet address] [official hostname] [alias1] [alias2] ...
+
+   For example:
+
+ 10.0.0.1 myRealHostname.example.com myRealHostname foobar1 foobar2
+
+   Consult hosts(5) for more information.
+
+     ----------------------------------------------------------------------
+
+  6.10.3 Log File Configuration
+
+     ----------------------------------------------------------------------
+
+    6.10.3.1 syslog.conf
+
+   syslog.conf is the configuration file for the syslogd(8) program. It
+   indicates which types of syslog messages are logged to particular log
+   files.
+
+ #
+ #       Spaces ARE valid field separators in this file. However,
+ #       other *nix-like systems still insist on using tabs as field
+ #       separators. If you are sharing this file between systems, you
+ #       may want to use only tabs as field separators here.
+ #       Consult the syslog.conf(5) manual page.
+ *.err;kern.debug;auth.notice;mail.crit          /dev/console
+ *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
+ security.*                                      /var/log/security
+ mail.info                                       /var/log/maillog
+ lpr.info                                        /var/log/lpd-errs
+ cron.*                                          /var/log/cron
+ *.err                                           root
+ *.notice;news.err                               root
+ *.alert                                         root
+ *.emerg                                         *
+ # uncomment this to log all writes to /dev/console to /var/log/console.log
+ #console.info                                   /var/log/console.log
+ # uncomment this to enable logging of all log messages to /var/log/all.log
+ #*.*                                            /var/log/all.log
+ # uncomment this to enable logging to a remote log host named loghost
+ #*.*                                            @loghost
+ # uncomment these if you're running inn
+ # news.crit                                     /var/log/news/news.crit
+ # news.err                                      /var/log/news/news.err
+ # news.notice                                   /var/log/news/news.notice
+ !startslip
+ *.*                                             /var/log/slip.log
+ !ppp
+ *.*                                             /var/log/ppp.log
+
+   Consult the syslog.conf(5) manual page for more information.
+
+     ----------------------------------------------------------------------
+
+    6.10.3.2 newsyslog.conf
+
+   newsyslog.conf is the configuration file for newsyslog(8), a program that
+   is normally scheduled to run by cron(8). newsyslog(8) determines when log
+   files require archiving or rearranging. logfile is moved to logfile.0,
+   logfile.0 is moved to logfile.1, and so on. Alternatively, the log files
+   may be archived in gzip(1) format causing them to be named: logfile.0.gz,
+   logfile.1.gz, and so on.
+
+   newsyslog.conf indicates which log files are to be managed, how many are
+   to be kept, and when they are to be touched. Log files can be rearranged
+   and/or archived when they have either reached a certain size, or at a
+   certain periodic time/date.
+
+ # configuration file for newsyslog
+ #
+ # filename          [owner:group]    mode count size when [ZB] [/pid_file] [sig_num]
+ /var/log/cron                           600  3     100  *     Z
+ /var/log/amd.log                        644  7     100  *     Z
+ /var/log/kerberos.log                   644  7     100  *     Z
+ /var/log/lpd-errs                       644  7     100  *     Z
+ /var/log/maillog                        644  7     *    @T00  Z
+ /var/log/sendmail.st                    644  10    *    168   B
+ /var/log/messages                       644  5     100  *     Z
+ /var/log/all.log                        600  7     *    @T00  Z
+ /var/log/slip.log                       600  3     100  *     Z
+ /var/log/ppp.log                        600  3     100  *     Z
+ /var/log/security                       600  10    100  *     Z
+ /var/log/wtmp                           644  3     *    @01T05 B
+ /var/log/daily.log                      640  7     *    @T00  Z
+ /var/log/weekly.log                     640  5     1    $W6D0 Z
+ /var/log/monthly.log                    640  12    *    $M1D0 Z
+ /var/log/console.log                    640  5     100  *     Z
+
+   Consult the newsyslog(8) manual page for more information.
+
+     ----------------------------------------------------------------------
+
+  6.10.4 sysctl.conf
+
+   sysctl.conf looks much like rc.conf. Values are set in a variable=value
+   form. The specified values are set after the system goes into multi-user
+   mode. Not all variables are settable in this mode.
+
+   A sample sysctl.conf turning off logging of fatal signal exits and letting
+   Linux programs know they are really running under DragonFly:
+
+ kern.logsigexit=0       # Do not log fatal signal exits (e.g. sig 11)
+ compat.linux.osname=DragonFly
+ compat.linux.osrelease=4.3-STABLE
+
+     ----------------------------------------------------------------------
+
+6.11 Tuning with sysctl
+
+   sysctl(8) is an interface that allows you to make changes to a running
+   DragonFly system. This includes many advanced options of the TCP/IP stack
+   and virtual memory system that can dramatically improve performance for an
+   experienced system administrator. Over five hundred system variables can
+   be read and set using sysctl(8).
+
+   At its core, sysctl(8) serves two functions: to read and to modify system
+   settings.
+
+   To view all readable variables:
+
+ % sysctl -a
+
+   To read a particular variable, for example, kern.maxproc:
+
+ % sysctl kern.maxproc
+ kern.maxproc: 1044
+
+   To set a particular variable, use the intuitive variable=value syntax:
+
+ # sysctl kern.maxfiles=5000
+ kern.maxfiles: 2088 -> 5000
+
+   Settings of sysctl variables are usually either strings, numbers, or
+   booleans (a boolean being 1 for yes or a 0 for no).
+
+   If you want to set automatically some variables each time the machine
+   boots, add them to the /etc/sysctl.conf file. For more information see the
+   sysctl.conf(5) manual page and the Section 6.10.4.
+
+     ----------------------------------------------------------------------
+
+  6.11.1 sysctl(8) Read-only
+
+   Contributed by Tom Rhodes.
+
+   In some cases it may be desirable to modify read-only sysctl(8) values.
+   While this is not recommended, it is also sometimes unavoidable.
+
+   For instance on some laptop models the cardbus(4) device will not probe
+   memory ranges, and fail with errors which look similar to:
+
+ cbb0: Could not map register memory
+ device_probe_and_attach: cbb0 attach returned 12
+
+   Cases like the one above usually require the modification of some default
+   sysctl(8) settings which are set read only. To overcome these situations a
+   user can put sysctl(8) ``OIDs'' in their local /boot/loader.conf. Default
+   settings are located in the /boot/defaults/loader.conf file.
+
+   Fixing the problem mentioned above would require a user to set
+   hw.pci.allow_unsupported_io_range=1 in the aforementioned file. Now
+   cardbus(4) will work properly.
+
+     ----------------------------------------------------------------------
+
+6.12 Tuning Disks
+
+  6.12.1 Sysctl Variables
+
+    6.12.1.1 vfs.vmiodirenable
+
+   The vfs.vmiodirenable sysctl variable may be set to either 0 (off) or 1
+   (on); it is 1 by default. This variable controls how directories are
+   cached by the system. Most directories are small, using just a single
+   fragment (typically 1 K) in the file system and less (typically 512 bytes)
+   in the buffer cache. With this variable turned off (to 0), the buffer
+   cache will only cache a fixed number of directories even if ou have a huge
+   amount of memory. When turned on (to 1), this sysctl allows the buffer
+   cache to use the VM Page Cache to cache the directories, making all the
+   memory available for caching directories. However, the minimum in-core
+   memory used to cache a directory is the physical page size (typically 4 K)
+   rather than 512  bytes. We recommend keeping this option on if you are
+   running any services which manipulate large numbers of files. Such
+   services can include web caches, large mail systems, and news systems.
+   Keeping this option on will generally not reduce performance even with the
+   wasted memory but you should experiment to find out.
+
+     ----------------------------------------------------------------------
+
+    6.12.1.2 vfs.write_behind
+
+   The vfs.write_behind sysctl variable defaults to 1 (on). This tells the
+   file system to issue media writes as full clusters are collected, which
+   typically occurs when writing large sequential files. The idea is to avoid
+   saturating the buffer cache with dirty buffers when it would not benefit
+   I/O performance. However, this may stall processes and under certain
+   circumstances you may wish to turn it off.
+
+     ----------------------------------------------------------------------
+
+    6.12.1.3 vfs.hirunningspace
+
+   The vfs.hirunningspace sysctl variable determines how much outstanding
+   write I/O may be queued to disk controllers system-wide at any given
+   instance. The default is usually sufficient but on machines with lots of
+   disks you may want to bump it up to four or five megabytes. Note that
+   setting too high a value (exceeding the buffer cache's write threshold)
+   can lead to extremely bad clustering performance. Do not set this value
+   arbitrarily high! Higher write values may add latency to reads occurring
+   at the same time.
+
+   There are various other buffer-cache and VM page cache related sysctls. We
+   do not recommend modifying these values. The VM system does an extremely
+   good job of automatically tuning itself.
+
+     ----------------------------------------------------------------------
+
+    6.12.1.4 vm.swap_idle_enabled
+
+   The vm.swap_idle_enabled sysctl variable is useful in large multi-user
+   systems where you have lots of users entering and leaving the system and
+   lots of idle processes. Such systems tend to generate a great deal of
+   continuous pressure on free memory reserves. Turning this feature on and
+   tweaking the swapout hysteresis (in idle seconds) via
+   vm.swap_idle_threshold1 and vm.swap_idle_threshold2 allows you to depress
+   the priority of memory pages associated with idle processes more quickly
+   then the normal pageout algorithm. This gives a helping hand to the
+   pageout daemon. Do not turn this option on unless you need it, because the
+   tradeoff you are making is essentially pre-page memory sooner rather than
+   later; thus eating more swap and disk bandwidth. In a small system this
+   option will have a determinable effect but in a large system that is
+   already doing moderate paging this option allows the VM system to stage
+   whole processes into and out of memory easily.
+
+     ----------------------------------------------------------------------
+
+    6.12.1.5 hw.ata.wc
+
+   IDE drives lie about when a write completes. With IDE write caching turned
+   on, IDE hard drives not only write data to disk out of order, but will
+   sometimes delay writing some blocks indefinitely when under heavy disk
+   loads. A crash or power failure may cause serious file system corruption.
+   Turning off write caching will remove the danger of this data loss, but
+   will also cause disk operations to proceed very slowly. Change this only
+   if prepared to suffer with the disk slowdown.
+
+   Changing this variable must be done from the boot loader at boot time.
+   Attempting to do it after the kernel boots will have no effect.
+
+   For more information, please see ata(4) manual page.
+
+     ----------------------------------------------------------------------
+
+  6.12.2 Soft Updates
+
+   The tunefs(8) program can be used to fine-tune a file system. This program
+   has many different options, but for now we are only concerned with
+   toggling Soft Updates on and off, which is done by:
+
+ # tunefs -n enable /filesystem
+ # tunefs -n disable /filesystem
+
+   A filesystem cannot be modified with tunefs(8) while it is mounted. A good
+   time to enable Soft Updates is before any partitions have been mounted, in
+   single-user mode.
+
+     Note: It is possible to enable Soft Updates at filesystem creation time,
+     through use of the -U option to newfs(8).
+
+   Soft Updates drastically improves meta-data performance, mainly file
+   creation and deletion, through the use of a memory cache. We recommend to
+   use Soft Updates on all of your file systems. There are two downsides to
+   Soft Updates that you should be aware of: First, Soft Updates guarantees
+   filesystem consistency in the case of a crash but could very easily be
+   several seconds (even a minute!) behind updating the physical disk. If
+   your system crashes you may lose more work than otherwise. Secondly, Soft
+   Updates delays the freeing of filesystem blocks. If you have a filesystem
+   (such as the root filesystem) which is almost full, performing a major
+   update, such as make installworld, can cause the filesystem to run out of
+   space and the update to fail.
+
+     ----------------------------------------------------------------------
+
+    6.12.2.1 More Details about Soft Updates
+
+   There are two traditional approaches to writing a file systems meta-data
+   back to disk. (Meta-data updates are updates to non-content data like
+   inodes or directories.)
+
+   Historically, the default behavior was to write out meta-data updates
+   synchronously. If a directory had been changed, the system waited until
+   the change was actually written to disk. The file data buffers (file
+   contents) were passed through the buffer cache and backed up to disk later
+   on asynchronously. The advantage of this implementation is that it
+   operates safely. If there is a failure during an update, the meta-data are
+   always in a consistent state. A file is either created completely or not
+   at all. If the data blocks of a file did not find their way out of the
+   buffer cache onto the disk by the time of the crash, fsck(8) is able to
+   recognize this and repair the filesystem by setting the file length to 0.
+   Additionally, the implementation is clear and simple. The disadvantage is
+   that meta-data changes are slow. An rm -r, for instance, touches all the
+   files in a directory sequentially, but each directory change (deletion of
+   a file) will be written synchronously to the disk. This includes updates
+   to the directory itself, to the inode table, and possibly to indirect
+   blocks allocated by the file. Similar considerations apply for unrolling
+   large hierarchies (tar -x).
+
+   The second case is asynchronous meta-data updates. This is the default for
+   Linux/ext2fs and mount -o async for *BSD ufs. All meta-data updates are
+   simply being passed through the buffer cache too, that is, they will be
+   intermixed with the updates of the file content data. The advantage of
+   this implementation is there is no need to wait until each meta-data
+   update has been written to disk, so all operations which cause huge
+   amounts of meta-data updates work much faster than in the synchronous
+   case. Also, the implementation is still clear and simple, so there is a
+   low risk for bugs creeping into the code. The disadvantage is that there
+   is no guarantee at all for a consistent state of the filesystem. If there
+   is a failure during an operation that updated large amounts of meta-data
+   (like a power failure, or someone pressing the reset button), the
+   filesystem will be left in an unpredictable state. There is no opportunity
+   to examine the state of the filesystem when the system comes up again; the
+   data blocks of a file could already have been written to the disk while
+   the updates of the inode table or the associated directory were not. It is
+   actually impossible to implement a fsck which is able to clean up the
+   resulting chaos (because the necessary information is not available on the
+   disk). If the filesystem has been damaged beyond repair, the only choice
+   is to use newfs(8) on it and restore it from backup.
+
+   The usual solution for this problem was to implement dirty region logging,
+   which is also referred to as journaling, although that term is not used
+   consistently and is occasionally applied to other forms of transaction
+   logging as well. Meta-data updates are still written synchronously, but
+   only into a small region of the disk. Later on they will be moved to their
+   proper location. Because the logging area is a small, contiguous region on
+   the disk, there are no long distances for the disk heads to move, even
+   during heavy operations, so these operations are quicker than synchronous
+   updates. Additionally the complexity of the implementation is fairly
+   limited, so the risk of bugs being present is low. A disadvantage is that
+   all meta-data are written twice (once into the logging region and once to
+   the proper location) so for normal work, a performance ``pessimization''
+   might result. On the other hand, in case of a crash, all pending meta-data
+   operations can be quickly either rolled-back or completed from the logging
+   area after the system comes up again, resulting in a fast filesystem
+   startup.
+
+   Kirk McKusick, the developer of Berkeley FFS, solved this problem with
+   Soft Updates: all pending meta-data updates are kept in memory and written
+   out to disk in a sorted sequence (``ordered meta-data updates''). This has
+   the effect that, in case of heavy meta-data operations, later updates to
+   an item ``catch'' the earlier ones if the earlier ones are still in memory
+   and have not already been written to disk. So all operations on, say, a
+   directory are generally performed in memory before the update is written
+   to disk (the data blocks are sorted according to their position so that
+   they will not be on the disk ahead of their meta-data). If the system
+   crashes, this causes an implicit ``log rewind'': all operations which did
+   not find their way to the disk appear as if they had never happened. A
+   consistent filesystem state is maintained that appears to be the one of 30
+   to 60 seconds earlier. The algorithm used guarantees that all resources in
+   use are marked as such in their appropriate bitmaps: blocks and inodes.
+   After a crash, the only resource allocation error that occurs is that
+   resources are marked as ``used'' which are actually ``free''. fsck(8)
+   recognizes this situation, and frees the resources that are no longer
+   used. It is safe to ignore the dirty state of the filesystem after a crash
+   by forcibly mounting it with mount -f. In order to free resources that may
+   be unused, fsck(8) needs to be run at a later time.
+
+   The advantage is that meta-data operations are nearly as fast as
+   asynchronous updates (i.e. faster than with logging, which has to write
+   the meta-data twice). The disadvantages are the complexity of the code
+   (implying a higher risk for bugs in an area that is highly sensitive
+   regarding loss of user data), and a higher memory consumption.
+   Additionally there are some idiosyncrasies one has to get used to. After a
+   crash, the state of the filesystem appears to be somewhat ``older''. In
+   situations where the standard synchronous approach would have caused some
+   zero-length files to remain after the fsck, these files do not exist at
+   all with a Soft Updates filesystem because neither the meta-data nor the
+   file contents have ever been written to disk. Disk space is not released
+   until the updates have been written to disk, which may take place some
+   time after running rm. This may cause problems when installing large
+   amounts of data on a filesystem that does not have enough free space to
+   hold all the files twice.
+
+     ----------------------------------------------------------------------
+
+6.13 Tuning Kernel Limits
+
+     ----------------------------------------------------------------------
+
+  6.13.1 File/Process Limits
+
+    6.13.1.1 kern.maxfiles
+
+   kern.maxfiles can be raised or lowered based upon your system
+   requirements. This variable indicates the maximum number of file
+   descriptors on your system. When the file descriptor table is full,
+   ``file: table is full'' will show up repeatedly in the system message
+   buffer, which can be viewed with the dmesg command.
+
+   Each open file, socket, or fifo uses one file descriptor. A large-scale
+   production server may easily require many thousands of file descriptors,
+   depending on the kind and number of services running concurrently.
+
+   kern.maxfile's default value is dictated by the MAXUSERS option in your
+   kernel configuration file. kern.maxfiles grows proportionally to the value
+   of MAXUSERS. When compiling a custom kernel, it is a good idea to set this
+   kernel configuration option according to the uses of your system. From
+   this number, the kernel is given most of its pre-defined limits. Even
+   though a production machine may not actually have 256 users connected at
+   once, the resources needed may be similar to a high-scale web server.
+
+     Note: Setting MAXUSERS to 0 in your kernel configuration file will
+     choose a reasonable default value based on the amount of RAM present in
+     your system. It is set to 0 in the default GENERIC kernel.
+
+     ----------------------------------------------------------------------
+
+    6.13.1.2 kern.ipc.somaxconn
+
+   The kern.ipc.somaxconn sysctl variable limits the size of the listen queue
+   for accepting new TCP connections. The default value of 128 is typically
+   too low for robust handling of new connections in a heavily loaded web
+   server environment. For such environments, it is recommended to increase
+   this value to 1024 or higher. The service daemon may itself limit the
+   listen queue size (e.g. sendmail(8), or Apache) but will often have a
+   directive in its configuration file to adjust the queue size. Large listen
+   queues also do a better job of avoiding Denial of Service (DoS) attacks.
+
+     ----------------------------------------------------------------------
+
+  6.13.2 Network Limits
+
+   The NMBCLUSTERS kernel configuration option dictates the amount of network
+   Mbufs available to the system. A heavily-trafficked server with a low
+   number of Mbufs will hinder DragonFly's ability. Each cluster represents
+   approximately 2 K of memory, so a value of 1024 represents 2 megabytes of
+   kernel memory reserved for network buffers. A simple calculation can be
+   done to figure out how many are needed. If you have a web server which
+   maxes out at 1000 simultaneous connections, and each connection eats a
+   16 K receive and 16 K send buffer, you need approximately 32 MB worth of
+   network buffers to cover the web server. A good rule of thumb is to
+   multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. We recommend
+   values between 4096 and 32768 for machines with greater amounts of memory.
+   Under no circumstances should you specify an arbitrarily high value for
+   this parameter as it could lead to a boot time crash. The -m option to
+   netstat(1) may be used to observe network cluster use.
+   kern.ipc.nmbclusters loader tunable should be used to tune this at boot
+   time.
+
+   For busy servers that make extensive use of the sendfile(2) system call,
+   it may be necessary to increase the number of sendfile(2) buffers via the
+   NSFBUFS kernel configuration option or by setting its value in
+   /boot/loader.conf (see loader(8) for details). A common indicator that
+   this parameter needs to be adjusted is when processes are seen in the
+   sfbufa state. The sysctl variable kern.ipc.nsfbufs is a read-only glimpse
+   at the kernel configured variable. This parameter nominally scales with
+   kern.maxusers, however it may be necessary to tune accordingly.
+
+     Important: Even though a socket has been marked as non-blocking, calling
+     sendfile(2) on the non-blocking socket may result in the sendfile(2)
+     call blocking until enough struct sf_buf's are made available.
+
+     ----------------------------------------------------------------------
+
+    6.13.2.1 net.inet.ip.portrange.*
+
+   The net.inet.ip.portrange.* sysctl variables control the port number
+   ranges automatically bound to TCP and UDP sockets. There are three ranges:
+   a low range, a default range, and a high range. Most network programs use
+   the default range which is controlled by the net.inet.ip.portrange.first
+   and net.inet.ip.portrange.last, which default to 1024 and 5000,
+   respectively. Bound port ranges are used for outgoing connections, and it
+   is possible to run the system out of ports under certain circumstances.
+   This most commonly occurs when you are running a heavily loaded web proxy.
+   The port range is not an issue when running servers which handle mainly
+   incoming connections, such as a normal web server, or has a limited number
+   of outgoing connections, such as a mail relay. For situations where you
+   may run yourself out of ports, it is recommended to increase
+   net.inet.ip.portrange.last modestly. A value of 10000, 20000 or 30000 may
+   be reasonable. You should also consider firewall effects when changing the
+   port range. Some firewalls may block large ranges of ports (usually
+   low-numbered ports) and expect systems to use higher ranges of ports for
+   outgoing connections -- for this reason it is recommended that
+   net.inet.ip.portrange.first be lowered.
+
+     ----------------------------------------------------------------------
+
+    6.13.2.2 TCP Bandwidth Delay Product
+
+   The TCP Bandwidth Delay Product Limiting is similar to TCP/Vegas in
+   NetBSD. It can be enabled by setting net.inet.tcp.inflight_enable sysctl
+   variable to 1. The system will attempt to calculate the bandwidth delay
+   product for each connection and limit the amount of data queued to the
+   network to just the amount required to maintain optimum throughput.
+
+   This feature is useful if you are serving data over modems, Gigabit
+   Ethernet, or even high speed WAN links (or any other link with a high
+   bandwidth delay product), especially if you are also using window scaling
+   or have configured a large send window. If you enable this option, you
+   should also be sure to set net.inet.tcp.inflight_debug to 0 (disable
+   debugging), and for production use setting net.inet.tcp.inflight_min to at
+   least 6144 may be beneficial. However, note that setting high minimums may
+   effectively disable bandwidth limiting depending on the link. The limiting
+   feature reduces the amount of data built up in intermediate route and
+   switch packet queues as well as reduces the amount of data built up in the
+   local host's interface queue. With fewer packets queued up, interactive
+   connections, especially over slow modems, will also be able to operate
+   with lower Round Trip Times. However, note that this feature only effects
+   data transmission (uploading / server side). It has no effect on data
+   reception (downloading).
+
+   Adjusting net.inet.tcp.inflight_stab is not recommended. This parameter
+   defaults to 20, representing 2 maximal packets added to the bandwidth
+   delay product window calculation. The additional window is required to
+   stabilize the algorithm and improve responsiveness to changing conditions,
+   but it can also result in higher ping times over slow links (though still
+   much lower than you would get without the inflight algorithm). In such
+   cases, you may wish to try reducing this parameter to 15, 10, or 5; and
+   may also have to reduce net.inet.tcp.inflight_min (for example, to 3500)
+   to get the desired effect. Reducing these parameters should be done as a
+   last resort only.
+
+     ----------------------------------------------------------------------
+
+6.14 Adding Swap Space
+
+   No matter how well you plan, sometimes a system does not run as you
+   expect. If you find you need more swap space, it is simple enough to add.
+   You have three ways to increase swap space: adding a new hard drive,
+   enabling swap over NFS, and creating a swap file on an existing partition.
+
+     ----------------------------------------------------------------------
+
+  6.14.1 Swap on a New Hard Drive
+
+   The best way to add swap, of course, is to use this as an excuse to add
+   another hard drive. You can always use another hard drive, after all. If
+   you can do this, go reread the discussion about swap space in Section 6.2
+   for some suggestions on how to best arrange your swap.
+
+     ----------------------------------------------------------------------
+
+  6.14.2 Swapping over NFS
+
+   Swapping over NFS is only recommended if you do not have a local hard disk
+   to swap to. Even though DragonFly has an excellent NFS implementation, NFS
+   swapping will be limited by the available network bandwidth and puts an
+   additional burden on the NFS server.
+
+     ----------------------------------------------------------------------
+
+  6.14.3 Swapfiles
+
+   You can create a file of a specified size to use as a swap file. In our
+   example here we will use a 64MB file called /usr/swap0. You can use any
+   name you want, of course.
+
+   Example 6-1. Creating a Swapfile
+
+    1. Be certain that your kernel configuration includes the vnode driver.
+       It is not in recent versions of GENERIC.
+
+ pseudo-device   vn 1   #Vnode driver (turns a file into a device)
+
+    2. Create a vn-device:
+
+ # cd /dev
+ # sh MAKEDEV vn0
+
+    3. Create a swapfile (/usr/swap0):
+
+ # dd if=/dev/zero of=/usr/swap0 bs=1024k count=64
+
+    4. Set proper permissions on (/usr/swap0):
+
+ # chmod 0600 /usr/swap0
+
+    5. Enable the swap file in /etc/rc.conf:
+
+ swapfile="/usr/swap0"   # Set to name of swapfile if aux swapfile desired.
+
+    6. Reboot the machine or to enable the swap file immediately, type:
+
+ # vnconfig -e /dev/vn0b /usr/swap0 swap
+
+     ----------------------------------------------------------------------
+
+6.15 Power and Resource Management
+
+   Written by Hiten Pandya and Tom Rhodes.
+
+   It is very important to utilize hardware resources in an efficient manner.
+   Before ACPI was introduced, it was very difficult and inflexible for
+   operating systems to manage the power usage and thermal properties of a
+   system. The hardware was controlled by some sort of BIOS embedded
+   interface, such as Plug and Play BIOS (PNPBIOS), or Advanced Power
+   Management (APM) and so on. Power and Resource Management is one of the
+   key components of a modern operating system. For example, you may want an
+   operating system to monitor system limits (and possibly alert you) in case
+   your system temperature increased unexpectedly.
+
+   In this section, we will provide comprehensive information about ACPI.
+   References will be provided for further reading at the end. Please be
+   aware that ACPI is available on DragonFly systems as a default kernel
+   module.
+
+     ----------------------------------------------------------------------
+
+  6.15.1 What Is ACPI?
+
+   Advanced Configuration and Power Interface (ACPI) is a standard written by
+   an alliance of vendors to provide a standard interface for hardware
+   resources and power management (hence the name). It is a key element in
+   Operating System-directed configuration and Power Management, i.e.: it
+   provides more control and flexibility to the operating system (OS). Modern
+   systems ``stretched'' the limits of the current Plug and Play interfaces
+   (such as APM), prior to the introduction of ACPI. ACPI is the direct
+   successor to APM (Advanced Power Management).
+
+     ----------------------------------------------------------------------
+
+  6.15.2 Shortcomings of Advanced Power Management (APM)
+
+   The Advanced Power Management (APM) facility control's the power usage of
+   a system based on its activity. The APM BIOS is supplied by the (system)
+   vendor and it is specific to the hardware platform. An APM driver in the
+   OS mediates access to the APM Software Interface, which allows management
+   of power levels.
+
+   There are four major problems in APM. Firstly, power management is done by
+   the (vendor-specific) BIOS, and the OS does not have any knowledge of it.
+   One example of this, is when the user sets idle-time values for a hard
+   drive in the APM BIOS, that when exceeded, it (BIOS) would spin down the
+   hard drive, without the consent of the OS. Secondly, the APM logic is
+   embedded in the BIOS, and it operates outside the scope of the OS. This
+   means users can only fix problems in their APM BIOS by flashing a new one
+   into the ROM; which, is a very dangerous procedure, and if it fails, it
+   could leave the system in an unrecoverable state. Thirdly, APM is a
+   vendor-specific technology, which, means that there is a lot or parity
+   (duplication of efforts) and bugs found in one vendor's BIOS, may not be
+   solved in others. Last but not the least, the APM BIOS did not have enough
+   room to implement a sophisticated power policy, or one that can adapt very
+   well to the purpose of the machine.
+
+   Plug and Play BIOS (PNPBIOS) was unreliable in many situations. PNPBIOS is
+   16-bit technology, so the OS has to use 16-bit emulation in order to
+   ``interface'' with PNPBIOS methods.
+
+   The DragonFly APM driver is documented in the apm(4) manual page.
+
+     ----------------------------------------------------------------------
+
+  6.15.3 Configuring ACPI
+
+   The acpi.ko driver is loaded by default at start up by the loader(8) and
+   should not be compiled into the kernel. The reasoning behind this is that
+   modules are easier to work with, say if switching to another acpi.ko
+   without doing a kernel rebuild. This has the advantage of making testing
+   easier. Another reason is that starting ACPI after a system has been
+   brought up is not too useful, and in some cases can be fatal. In doubt,
+   just disable ACPI all together. This driver should not and can not be
+   unloaded because the system bus uses it for various hardware interactions.
+   ACPI can be disabled with the acpiconf(8) utility. In fact most of the
+   interaction with ACPI can be done via acpiconf(8). Basically this means,
+   if anything about ACPI is in the dmesg(8) output, then most likely it is
+   already running.
+
+     Note: ACPI and APM cannot coexist and should be used separately. The
+     last one to load will terminate if the driver notices the other running.
+
+   In the simplest form, ACPI can be used to put the system into a sleep mode
+   with acpiconf(8), the -s flag, and a 1-5 option. Most users will only need
+   1. Option 5 will do a soft-off which is the same action as:
+
+ # halt -p
+
+   The other options are available. Check out the acpiconf(8) manual page for
+   more information.
+
+     ----------------------------------------------------------------------
+
+6.16 Using and Debugging DragonFly ACPI
+
+   Written by Nate Lawson. With contributions from Peter Schultz and Tom
+   Rhodes.
+
+   ACPI is a fundamentally new way of discovering devices, managing power
+   usage, and providing standardized access to various hardware previously
+   managed by the BIOS. Progress is being made toward ACPI working on all
+   systems, but bugs in some motherboards' ACPI Machine Language (AML)
+   bytecode, incompleteness in DragonFly's kernel subsystems, and bugs in the
+   Intel ACPI-CA interpreter continue to appear.
+
+   This document is intended to help you assist the DragonFly ACPI
+   maintainers in identifying the root cause of problems you observe and
+   debugging and developing a solution. Thanks for reading this and we hope
+   we can solve your system's problems.
+
+     ----------------------------------------------------------------------
+
+  6.16.1 Submitting Debugging Information
+
+     Note: Before submitting a problem, be sure you are running the latest
+     BIOS version and, if available, embedded controller firmware version.
+
+   For those of you that want to submit a problem right away, please send the
+   following information to bugs
+
+     * Description of the buggy behavior, including system type and model and
+       anything that causes the bug to appear. Also, please note as
+       accurately as possible when the bug began occurring if it is new for
+       you.
+
+     * The dmesg output after ``boot -v'', including any error messages
+       generated by you exercising the bug.
+
+     * dmesg output from ``boot -v'' with ACPI disabled, if disabling it
+       helps fix the problem.
+
+     * Output from ``sysctl hw.acpi''. This is also a good way of figuring
+       out what features your system offers.
+
+     * URL where your ACPI Source Language (ASL) can be found. Do not send
+       the ASL directly to the list as it can be very large. Generate a copy
+       of your ASL by running this command:
+
+ # acpidump -t -d > name-system.asl
+
+       (Substitute your login name for name and manufacturer/model for
+       system. Example: njl-FooCo6000.asl)
+
+     ----------------------------------------------------------------------
+
+  6.16.2 Background
+
+   ACPI is present in all modern computers that conform to the ia32 (x86),
+   ia64 (Itanium), and amd64 (AMD) architectures. The full standard has many
+   features including CPU performance management, power planes control,
+   thermal zones, various battery systems, embedded controllers, and bus
+   enumeration. Most systems implement less than the full standard. For
+   instance, a desktop system usually only implements the bus enumeration
+   parts while a laptop might have cooling and battery management support as
+   well. Laptops also have suspend and resume, with their own associated
+   complexity.
+
+   An ACPI-compliant system has various components. The BIOS and chipset
+   vendors provide various fixed tables (e.g., FADT) in memory that specify
+   things like the APIC map (used for SMP), config registers, and simple
+   configuration values. Additionally, a table of bytecode (the
+   Differentiated System Description Table DSDT) is provided that specifies a
+   tree-like name space of devices and methods.
+
+   The ACPI driver must parse the fixed tables, implement an interpreter for
+   the bytecode, and modify device drivers and the kernel to accept
+   information from the ACPI subsystem. For DragonFly, Intel has provided an
+   interpreter (ACPI-CA) that is shared with Linux and NetBSD. The path to
+   the ACPI-CA source code is src/sys/contrib/dev/acpica-unix-YYYYMMDD, where
+   YYYYMMDD is the release date of the ACPI-CA source code. The glue code
+   that allows ACPI-CA to work on DragonFly is in src/sys/dev/acpica5/Osd.
+   Finally, drivers that implement various ACPI devices are found in
+   src/sys/dev/acpica5, and architecture-dependent code resides in
+   /sys/arch/acpica5.
+
+     ----------------------------------------------------------------------
+
+  6.16.3 Common Problems
+
+   For ACPI to work correctly, all the parts have to work correctly. Here are
+   some common problems, in order of frequency of appearance, and some
+   possible workarounds or fixes.
+
+     ----------------------------------------------------------------------
+
+    6.16.3.1 Suspend/Resume
+
+   ACPI has three suspend to RAM (STR) states, S1-S3, and one suspend to disk
+   state (STD), called S4. S5 is ``soft off'' and is the normal state your
+   system is in when plugged in but not powered up. S4 can actually be
+   implemented two separate ways. S4BIOS is a BIOS-assisted suspend to disk.
+   S4OS is implemented entirely by the operating system.
+
+   Start by checking sysctl hw.acpi for the suspend-related items. Here are
+   the results for my Thinkpad:
+
+ hw.acpi.supported_sleep_state: S3 S4 S5
+
+ hw.acpi.s4bios: 0
+
+   This means that I can use acpiconf -s to test S3, S4OS, and S5. If s4bios
+   was one (1), I would have S4BIOS support instead of S4 OS.
+
+   When testing suspend/resume, start with S1, if supported. This state is
+   most likely to work since it doesn't require much driver support. No one
+   has implemented S2 but if you have it, it's similar to S1. The next thing
+   to try is S3. This is the deepest STR state and requires a lot of driver
+   support to properly reinitialize your hardware. If you have problems
+   resuming, feel free to email the bugs list but do not expect the problem
+   to be resolved since there are a lot of drivers/hardware that need more
+   testing and work.
+
+   To help isolate the problem, remove as many drivers from your kernel as
+   possible. If it works, you can narrow down which driver is the problem by
+   loading drivers until it fails again. Typically binary drivers like
+   nvidia.ko, X11 display drivers, and USB will have the most problems while
+   Ethernet interfaces usually work fine. If you can load/unload the drivers
+   ok, you can automate this by putting the appropriate commands in
+   /etc/rc.suspend and /etc/rc.resume. There is a commented-out example for
+   unloading and loading a driver. Try setting hw.acpi.reset_video to zero
+   (0) if your display is messed up after resume. Try setting longer or
+   shorter values for hw.acpi.sleep_delay to see if that helps.
+
+   Another thing to try is load a recent Linux distribution with ACPI support
+   and test their suspend/resume support on the same hardware. If it works on
+   Linux, it's likely a DragonFly driver problem and narrowing down which
+   driver causes the problems will help us fix the problem. Note that the
+   ACPI maintainers do not usually maintain other drivers (e.g sound, ATA,
+   etc.) so any work done on tracking down a driver problem should probably
+   eventually be posted to the bugs list and mailed to the driver maintainer.
+   If you are feeling adventurous, go ahead and start putting some debugging
+   printf(3)s in a problematic driver to track down where in its resume
+   function it hangs.
+
+   Finally, try disabling ACPI and enabling APM instead. If suspend/resume
+   works with APM, you may be better off sticking with APM, especially on
+   older hardware (pre-2000). It took vendors a while to get ACPI support
+   correct and older hardware is more likely to have BIOS problems with ACPI.
+
+     ----------------------------------------------------------------------
+
+    6.16.3.2 System Hangs (temporary or permanent)
+
+   Most system hangs are a result of lost interrupts or an interrupt storm.
+   Chipsets have a lot of problems based on how the BIOS configures
+   interrupts before boot, correctness of the APIC (MADT) table, and routing
+   of the System Control Interrupt (SCI).
+
+   Interrupt storms can be distinguished from lost interrupts by checking the
+   output of vmstat -i and looking at the line that has acpi0. If the counter
+   is increasing at more than a couple per second, you have an interrupt
+   storm. If the system appears hung, try breaking to DDB (CTRL+ALT+ESC on
+   console) and type show interrupts.
+
+   Your best hope when dealing with interrupt problems is to try disabling
+   APIC support with hint.apic.0.disabled="1" in loader.conf.
+
+     ----------------------------------------------------------------------
+
+    6.16.3.3 Panics
+
+   Panics are relatively rare for ACPI and are the top priority to be fixed.
+   The first step is to isolate the steps to reproduce the panic (if
+   possible) and get a backtrace. Follow the advice for enabling options DDB
+   and setting up a serial console (see Section 17.6.5.3) or setting up a
+   dump(8) partition. You can get a backtrace in DDB with tr. If you have to
+   handwrite the backtrace, be sure to at least get the lowest five (5) and
+   top five (5) lines in the trace.
+
+   Then, try to isolate the problem by booting with ACPI disabled. If that
+   works, you can isolate the ACPI subsystem by using various values of
+   debug.acpi.disable. See the acpi(4) manual page for some examples.
+
+     ----------------------------------------------------------------------
+
+    6.16.3.4 System Powers Up After Suspend or Shutdown
+
+   First, try setting hw.acpi.disable_on_poweroff=``0'' in loader.conf(5).
+   This keeps ACPI from disabling various events during the shutdown process.
+   Some systems need this value set to ``1'' (the default) for the same
+   reason. This usually fixes the problem of a system powering up
+   spontaneously after a suspend or poweroff.
+
+     ----------------------------------------------------------------------
+
+    6.16.3.5 Other Problems
+
+   If you have other problems with ACPI (working with a docking station,
+   devices not detected, etc.), please email a description to the mailing
+   list as well; however, some of these issues may be related to unfinished
+   parts of the ACPI subsystem so they might take a while to be implemented.
+   Please be patient and prepared to test patches we may send you.
+
+     ----------------------------------------------------------------------
+
+  6.16.4 ASL, acpidump, and IASL
+
+   The most common problem is the BIOS vendors providing incorrect (or
+   outright buggy!) bytecode. This is usually manifested by kernel console
+   messages like this:
+
+ ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\
+ (Node 0xc3f6d160), AE_NOT_FOUND
+
+   Often, you can resolve these problems by updating your BIOS to the latest
+   revision. Most console messages are harmless but if you have other
+   problems like battery status not working, they're a good place to start
+   looking for problems in the AML. The bytecode, known as AML, is compiled
+   from a source language called ASL. The AML is found in the table known as
+   the DSDT. To get a copy of your ASL, use acpidump(8). You should use both
+   the -t (show contents of the fixed tables) and -d (disassemble AML to ASL)
+   options. See the Submitting Debugging Information section for an example
+   syntax.
+
+   The simplest first check you can do is to recompile your ASL to check for
+   errors. Warnings can usually be ignored but errors are bugs that will
+   usually prevent ACPI from working correctly. To recompile your ASL, issue
+   the following command:
+
+ # iasl your.asl
+
+     ----------------------------------------------------------------------
+
+  6.16.5 Fixing Your ASL
+
+   In the long run, our goal is for almost everyone to have ACPI work without
+   any user intervention. At this point, however, we are still developing
+   workarounds for common mistakes made by the BIOS vendors. The Microsoft
+   interpreter (acpi.sys and acpiec.sys) does not strictly check for
+   adherence to the standard, and thus many BIOS vendors who only test ACPI
+   under Windows never fix their ASL. We hope to continue to identify and
+   document exactly what non-standard behavior is allowed by Microsoft's
+   interpreter and replicate it so DragonFly can work without forcing users
+   to fix the ASL. As a workaround and to help us identify behavior, you can
+   fix the ASL manually. If this works for you, please send a diff(1) of the
+   old and new ASL so we can possibly work around the buggy behavior in
+   ACPI-CA and thus make your fix unnecessary.
+
+   Here is a list of common error messages, their cause, and how to fix them:
+
+     ----------------------------------------------------------------------
+
+    6.16.5.1 _OS dependencies
+
+   Some AML assumes the world consists of various Windows versions. You can
+   tell DragonFly to claim it is any OS to see if this fixes problems you may
+   have. An easy way to override this is to set hw.acpi.osname=``Windows
+   2001'' in /boot/loader.conf or other similar strings you find in the ASL.
+
+     ----------------------------------------------------------------------
+
+    6.16.5.2 Missing Return statements
+
+   Some methods do not explicitly return a value as the standard requires.
+   While ACPI-CA does not handle this, DragonFly has a workaround that allows
+   it to return the value implicitly. You can also add explicit Return
+   statements where required if you know what value should be returned. To
+   force iasl to compile the ASL, use the -f flag.
+
+     ----------------------------------------------------------------------
+
+    6.16.5.3 Overriding the Default AML
+
+   After you customize your.asl, you will want to compile it, run:
+
+ # iasl your.asl
+
+   You can add the -f flag to force creation of the AML, even if there are
+   errors during compilation. Remember that some errors (e.g., missing Return
+   statements) are automatically worked around by the interpreter.
+
+   DSDT.aml is the default output filename for iasl. You can load this
+   instead of your BIOS's buggy copy (which is still present in flash memory)
+   by editing /boot/loader.conf as follows:
+
+ acpi_dsdt_load="YES"
+ acpi_dsdt_name="/boot/DSDT.aml"
+
+   Be sure to copy your DSDT.aml to the /boot directory.
+
+     ----------------------------------------------------------------------
+
+  6.16.6 Getting Debugging Output From ACPI
+
+   The ACPI driver has a very flexible debugging facility. It allows you to
+   specify a set of subsystems as well as the level of verbosity. The
+   subsystems you wish to debug are specified as ``layers'' and are broken
+   down into ACPI-CA components (ACPI_ALL_COMPONENTS) and ACPI hardware
+   support (ACPI_ALL_DRIVERS). The verbosity of debugging output is specified
+   as the ``level'' and ranges from ACPI_LV_ERROR (just report errors) to
+   ACPI_LV_VERBOSE (everything). The ``level'' is a bitmask so multiple
+   options can be set at once, separated by spaces. In practice, you will
+   want to use a serial console to log the output if it is so long it flushes
+   the console message buffer.
+
+   Debugging output is not enabled by default. To enable it, add options
+   ACPI_DEBUG to your kernel config if ACPI is compiled into the kernel. You
+   can add ACPI_DEBUG=1 to your /etc/make.conf to enable it globally. If it
+   is a module, you can recompile just your acpi.ko module as follows:
+
+ # cd /sys/dev/acpica5
+ && make clean &&
+ make ACPI_DEBUG=1
+
+   Install acpi.ko in /boot/kernel and add your desired level and layer to
+   loader.conf. This example enables debug messages for all ACPI-CA
+   components and all ACPI hardware drivers (CPU, LID, etc.) It will only
+   output error messages, the least verbose level.
+
+ debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
+ debug.acpi.level="ACPI_LV_ERROR"
+
+   If the information you want is triggered by a specific event (say, a
+   suspend and then resume), you can leave out changes to loader.conf and
+   instead use sysctl to specify the layer and level after booting and
+   preparing your system for the specific event. The sysctls are named the
+   same as the tunables in loader.conf.
+
+     ----------------------------------------------------------------------
+
+  6.16.7 References
+
+   More information about ACPI may be found in the following locations:
+
+     * The FreeBSD ACPI mailing list (This is FreeBSD-specific; posting
+       DragonFly questions here may not generate much of an answer.)
+
+     * The ACPI Mailing List Archives (FreeBSD)
+       http://lists.freebsd.org/pipermail/freebsd-acpi/
+
+     * The old ACPI Mailing List Archives (FreeBSD)
+       http://home.jp.FreeBSD.org/mail-list/acpi-jp/
+
+     * The ACPI 2.0 Specification http://acpi.info/spec.htm
+
+     * DragonFly Manual pages: acpidump(8), acpiconf(8), acpidb(8)
+
+     * DSDT debugging resource. (Uses Compaq as an example but generally
+       useful.)
+
+     ----------------------------------------------------------------------
+
+                    Chapter 7 The DragonFly Booting Process
+
+7.1 Synopsis
+
+   The process of starting a computer and loading the operating system is
+   referred to as ``the bootstrap process'', or simply ``booting''.
+   DragonFly's boot process provides a great deal of flexibility in
+   customizing what happens when you start the system, allowing you to select
+   from different operating systems installed on the same computer, or even
+   different versions of the same operating system or installed kernel.
+
+   This chapter details the configuration options you can set and how to
+   customize the DragonFly boot process. This includes everything that
+   happens until the DragonFly kernel has started, probed for devices, and
+   started init(8). If you are not quite sure when this happens, it occurs
+   when the text color changes from bright white to grey.
+
+   After reading this chapter, you will know:
+
+     * What the components of the DragonFly bootstrap system are, and how
+       they interact.
+
+     * The options you can give to the components in the DragonFly bootstrap
+       to control the boot process.
+
+     * The basics of device.hints(5).
+
+     x86 Only: This chapter only describes the boot process for DragonFly
+     running on x86 systems.
+
+     ----------------------------------------------------------------------
+
+7.2 The Booting Problem
+
+   Turning on a computer and starting the operating system poses an
+   interesting dilemma. By definition, the computer does not know how to do
+   anything until the operating system is started. This includes running
+   programs from the disk. So if the computer can not run a program from the
+   disk without the operating system, and the operating system programs are
+   on the disk, how is the operating system started?
+
+   This problem parallels one in the book The Adventures of Baron Munchausen.
+   A character had fallen part way down a manhole, and pulled himself out by
+   grabbing his bootstraps, and lifting. In the early days of computing the
+   term bootstrap was applied to the mechanism used to load the operating
+   system, which has become shortened to ``booting''.
+
+   On x86 hardware the Basic Input/Output System (BIOS) is responsible for
+   loading the operating system. To do this, the BIOS looks on the hard disk
+   for the Master Boot Record (MBR), which must be located on a specific
+   place on the disk. The BIOS has enough knowledge to load and run the MBR,
+   and assumes that the MBR can then carry out the rest of the tasks involved
+   in loading the operating system possibly with the help of the BIOS.
+
+   The code within the MBR is usually referred to as a boot manager,
+   especially when it interacts with the user. In this case the boot manager
+   usually has more code in the first track of the disk or within some OS's
+   file system. (A boot manager is sometimes also called a boot loader, but
+   FreeBSD uses that term for a later stage of booting.) Popular boot
+   managers include boot0 (a.k.a. Boot Easy, the standard DragonFly boot
+   manager), Grub, GAG, and LILO. (Only boot0 fits within the MBR.)
+
+   If you have only one operating system installed on your disks then a
+   standard PC MBR will suffice. This MBR searches for the first bootable
+   (a.k.a. active) slice on the disk, and then runs the code on that slice to
+   load the remainder of the operating system. The MBR installed by fdisk(8),
+   by default, is such an MBR. It is based on /boot/mbr.
+
+   If you have installed multiple operating systems on your disks then you
+   can install a different boot manager, one that can display a list of
+   different operating systems, and allows you to choose the one to boot
+   from. Two of these are discussed in the next subsection.
+
+   The remainder of the DragonFly bootstrap system is divided into three
+   stages. The first stage is run by the MBR, which knows just enough to get
+   the computer into a specific state and run the second stage. The second
+   stage can do a little bit more, before running the third stage. The third
+   stage finishes the task of loading the operating system. The work is split
+   into these three stages because the PC standards put limits on the size of
+   the programs that can be run at stages one and two. Chaining the tasks
+   together allows DragonFly to provide a more flexible loader.
+
+   The kernel is then started and it begins to probe for devices and
+   initialize them for use. Once the kernel boot process is finished, the
+   kernel passes control to the user process init(8), which then makes sure
+   the disks are in a usable state. init(8) then starts the user-level
+   resource configuration which mounts file systems, sets up network cards to
+   communicate on the network, and generally starts all the processes that
+   usually are run on a DragonFly system at startup.
+
+     ----------------------------------------------------------------------
+
+7.3 The Boot Manager and Boot Stages
+
+     ----------------------------------------------------------------------
+
+  7.3.1 The Boot Manager
+
+   The code in the MBR or boot manager is sometimes referred to as stage zero
+   of the boot process. This subsection discusses two of the boot managers
+   previously mentioned: boot0 and LILO.
+
+   The boot0 Boot Manager: The MBR installed by FreeBSD's installer or
+   boot0cfg(8), by default, is based on /boot/boot0. (The boot0 program is
+   very simple, since the program in the MBR can only be 446 bytes long
+   because of the slice table and 0x55AA identifier at the end of the MBR.)
+   If you have installed boot0 and multiple operating systems on your hard
+   disks, then you will see a display similar to this one at boot time:
+
+   Example 7-1. boot0 Screenshot
+
+ F1 DOS
+ F2 FreeBSD
+ F3 Linux
+ F4 ??
+ F5 Drive 1
+
+ Default: F2
+
+   Other operating systems, in particular Windows, have been known to
+   overwrite an existing MBR with their own. If this happens to you, or you
+   want to replace your existing MBR with the DragonFly MBR then use the
+   following command:
+
+ # fdisk -B -b /boot/boot0 device
+
+   where device is the device that you boot from, such as ad0 for the first
+   IDE disk, ad2 for the first IDE disk on a second IDE controller, da0 for
+   the first SCSI disk, and so on. Or, if you want a custom configuration of
+   the MBR, use boot0cfg(8).
+
+   The LILO Boot Manager: To install this boot manager so it will also boot
+   DragonFly, first start Linux and add the following to your existing
+   /etc/lilo.conf configuration file:
+
+ other=/dev/hdXY
+ table=/dev/hdX
+ loader=/boot/chain.b
+ label=DragonFly
+
+   In the above, specify DragonFly's primary partition and drive using Linux
+   specifiers, replacing X with the Linux drive letter and Y with the Linux
+   primary partition number. If you are using a SCSI drive, you will need to
+   change /dev/hd to read something similar to /dev/sd. The
+   loader=/boot/chain.b line can be omitted if you have both operating
+   systems on the same drive. Now run /sbin/lilo -v to commit your new
+   changes to the system; this should be verified by checking its screen
+   messages.
+
+     ----------------------------------------------------------------------
+
+  7.3.2 Stage One, /boot/boot1, and Stage Two, /boot/boot2
+
+   Conceptually the first and second stages are part of the same program, on
+   the same area of the disk. Because of space constraints they have been
+   split into two, but you would always install them together. They are
+   copied from the combined file /boot/boot by the installer or disklabel
+   (see below).
+
+   They are located outside file systems, in the first track of the boot
+   slice, starting with the first sector. This is where boot0, or any other
+   boot manager, expects to find a program to run which will continue the
+   boot process. The number of sectors used is easily determined from the
+   size of /boot/boot.
+
+   They are found on the boot sector of the boot slice, which is where boot0,
+   or any other program on the MBR expects to find the program to run to
+   continue the boot process. The files in the /boot directory are copies of
+   the real files, which are stored outside of the DragonFly file system.
+
+   boot1 is very simple, since it can only be 512 bytes in size, and knows
+   just enough about the DragonFly disklabel, which stores information about
+   the slice, to find and execute boot2.
+
+   boot2 is slightly more sophisticated, and understands the DragonFly file
+   system enough to find files on it, and can provide a simple interface to
+   choose the kernel or loader to run.
+
+   Since the loader is much more sophisticated, and provides a nice
+   easy-to-use boot configuration, boot2 usually runs it, but previously it
+   was tasked to run the kernel directly.
+
+   Example 7-2. boot2 Screenshot
+
+ >> DragonFly/i386 BOOT
+ Default: 0:ad(0,a)/boot/loader
+ boot:
+
+   If you ever need to replace the installed boot1 and boot2 use
+   disklabel(8):
+
+ # disklabel -B diskslice
+
+   where diskslice is the disk and slice you boot from, such as ad0s1 for the
+   first slice on the first IDE disk.
+
+     ----------------------------------------------------------------------
+
+  7.3.3 Stage Three, /boot/loader
+
+   The loader is the final stage of the three-stage bootstrap, and is located
+   on the file system, usually as /boot/loader.
+
+   The loader is intended as a user-friendly method for configuration, using
+   an easy-to-use built-in command set, backed up by a more powerful
+   interpreter, with a more complex command set.
+
+     ----------------------------------------------------------------------
+
+    7.3.3.1 Loader Program Flow
+
+   During initialization, the loader will probe for a console and for disks,
+   and figure out what disk it is booting from. It will set variables
+   accordingly, and an interpreter is started where user commands can be
+   passed from a script or interactively.
+
+   The loader will then read /boot/loader.rc, which by default reads in
+   /boot/defaults/loader.conf which sets reasonable defaults for variables
+   and reads /boot/loader.conf for local changes to those variables.
+   loader.rc then acts on these variables, loading whichever modules and
+   kernel are selected.
+
+   Finally, by default, the loader issues a 10 second wait for key presses,
+   and boots the kernel if it is not interrupted. If interrupted, the user is
+   presented with a prompt which understands the easy-to-use command set,
+   where the user may adjust variables, unload all modules, load modules, and
+   then finally boot or reboot.
+
+     ----------------------------------------------------------------------
+
+    7.3.3.2 Loader Built-In Commands
+
+   These are the most commonly used loader commands. For a complete
+   discussion of all available commands, please see loader(8).
+
+   autoboot seconds
+
+           Proceeds to boot the kernel if not interrupted within the time
+           span given, in seconds. It displays a countdown, and the default
+           time span is 10 seconds.
+
+   boot [-options] [kernelname]
+
+           Immediately proceeds to boot the kernel, with the given options,
+           if any, and with the kernel name given, if it is.
+
+   boot-conf
+
+           Goes through the same automatic configuration of modules based on
+           variables as what happens at boot. This only makes sense if you
+           use unload first, and change some variables, most commonly kernel.
+
+   help [topic]
+
+           Shows help messages read from /boot/loader.help. If the topic
+           given is index, then the list of available topics is given.
+
+   include filename ...
+
+           Processes the file with the given filename. The file is read in,
+           and interpreted line by line. An error immediately stops the
+           include command.
+
+   load [-t type] filename
+
+           Loads the kernel, kernel module, or file of the type given, with
+           the filename given. Any arguments after filename are passed to the
+           file.
+
+   ls [-l] [path]
+
+           Displays a listing of files in the given path, or the root
+           directory, if the path is not specified. If -l is specified, file
+           sizes will be shown too.
+
+   lsdev [-v]
+
+           Lists all of the devices from which it may be possible to load
+           modules. If -v is specified, more details are printed.
+
+   lsmod [-v]
+
+           Displays loaded modules. If -v is specified, more details are
+           shown.
+
+   more filename
+
+           Displays the files specified, with a pause at each LINES
+           displayed.
+
+   reboot
+
+           Immediately reboots the system.
+
+   set variable, set variable=value
+
+           Sets the loader's environment variables.
+
+   unload
+
+           Removes all loaded modules.
+
+     ----------------------------------------------------------------------
+
+    7.3.3.3 Loader Examples
+
+   Here are some practical examples of loader usage:
+
+     * To simply boot your usual kernel, but in single-user mode:
+
+ boot -s
+
+     * To unload your usual kernel and modules, and then load just your old
+       (or another) kernel:
+
+ unload
+ load kernel.old
+
+       You can use kernel.GENERIC to refer to the generic kernel that comes
+       on the install disk, or kernel.old to refer to your previously
+       installed kernel (when you have upgraded or configured your own
+       kernel, for example).
+
+         Note: Use the following to load your usual modules with another
+         kernel:
+
+ unload
+ set kernel="kernel.old"
+ boot-conf
+
+     * To load a kernel configuration script (an automated script which does
+       the things you would normally do in the kernel boot-time
+       configurator):
+
+ load -t userconfig_script /boot/kernel.conf
+
+     ----------------------------------------------------------------------
+
+7.4 Kernel Interaction During Boot
+
+   Once the kernel is loaded by either loader (as usual) or boot2 (bypassing
+   the loader), it examines its boot flags, if any, and adjusts its behavior
+   as necessary.
+
+     ----------------------------------------------------------------------
+
+  7.4.1 Kernel Boot Flags
+
+   Here are the more common boot flags:
+
+   -a
+
+           during kernel initialization, ask for the device to mount as the
+           root file system.
+
+   -C
+
+           boot from CDROM.
+
+   -c
+
+           run UserConfig, the boot-time kernel configurator
+
+   -s
+
+           boot into single-user mode
+
+   -v
+
+           be more verbose during kernel startup
+
+     Note: There are other boot flags; read boot(8) for more information on
+     them.
+
+     ----------------------------------------------------------------------
+
+7.5 Init: Process Control Initialization
+
+   Once the kernel has finished booting, it passes control to the user
+   process init(8), which is located at /sbin/init, or the program path
+   specified in the init_path variable in loader.
+
+     ----------------------------------------------------------------------
+
+  7.5.1 Automatic Reboot Sequence
+
+   The automatic reboot sequence makes sure that the file systems available
+   on the system are consistent. If they are not, and fsck(8) cannot fix the
+   inconsistencies, init(8) drops the system into single-user mode for the
+   system administrator to take care of the problems directly.
+
+     ----------------------------------------------------------------------
+
+  7.5.2 Single-User Mode
+
+   This mode can be reached through the automatic reboot sequence, or by the
+   user booting with the -s option or setting the boot_single variable in
+   loader.
+
+   It can also be reached by calling shutdown(8) without the reboot (-r) or
+   halt (-h) options, from multi-user mode.
+
+   If the system console is set to insecure in /etc/ttys, then the system
+   prompts for the root password before initiating single-user mode.
+
+   Example 7-3. An Insecure Console in /etc/ttys
+
+ # name  getty                           type    status          comments
+ #
+ # If console is marked "insecure", then init will ask for the root password
+ # when going to single-user mode.
+ console none                            unknown off insecure
+
+     Note: An insecure console means that you consider your physical security
+     to the console to be insecure, and want to make sure only someone who
+     knows the root password may use single-user mode, and it does not mean
+     that you want to run your console insecurely. Thus, if you want
+     security, choose insecure, not secure.
+
+     ----------------------------------------------------------------------
+
+  7.5.3 Multi-User Mode
+
+   If init(8) finds your file systems to be in order, or once the user has
+   finished in single-user mode, the system enters multi-user mode, in which
+   it starts the resource configuration of the system.
+
+     ----------------------------------------------------------------------
+
+    7.5.3.1 Resource Configuration (rc)
+
+   The resource configuration system reads in configuration defaults from
+   /etc/defaults/rc.conf, and system-specific details from /etc/rc.conf, and
+   then proceeds to mount the system file systems mentioned in /etc/fstab,
+   start up networking services, start up miscellaneous system daemons, and
+   finally runs the startup scripts of locally installed packages.
+
+   The rc(8) manual page is a good reference to the resource configuration
+   system, as is examining the scripts themselves.
+
+     ----------------------------------------------------------------------
+
+7.6 Shutdown Sequence
+
+   Upon controlled shutdown, via shutdown(8), init(8) will attempt to run the
+   script /etc/rc.shutdown, and then proceed to send all processes the TERM
+   signal, and subsequently the KILL signal to any that do not terminate
+   timely.
+
+   To power down a DragonFly machine on architectures and systems that
+   support power management, simply use the command shutdown -p now to turn
+   the power off immediately. To just reboot a DragonFly system, just use
+   shutdown -r now. You need to be root or a member of operator group to run
+   shutdown(8). The halt(8) and reboot(8) commands can also be used, please
+   refer to their manual pages and to shutdown(8)'s one for more information.
+
+     Note: Power management requires acpi(4) support in the kernel or loaded
+     as a module, or apm(4) support.
+
+     ----------------------------------------------------------------------
+
+                  Chapter 8 Users and Basic Account Management
+
+   Contributed by Neil Blakey-Milner.
+
+8.1 Synopsis
+
+   DragonFly allows multiple users to use the computer at the same time.
+   Obviously, only one of those users can be sitting in front of the screen
+   and keyboard at any one time [6], but any number of users can log in
+   through the network to get their work done. To use the system every user
+   must have an account.
+
+   After reading this chapter, you will know:
+
+     * The differences between the various user accounts on a DragonFly
+       system.
+
+     * How to add user accounts.
+
+     * How to remove user accounts.
+
+     * How to change account details, such as the user's full name, or
+       preferred shell.
+
+     * How to set limits on a per-account basis, to control the resources
+       such as memory and CPU time that accounts and groups of accounts are
+       allowed to access.
+
+     * How to use groups to make account management easier.
+
+   Before reading this chapter, you should:
+
+     * Understand the basics of UNIX and DragonFly (Chapter 3).
+
+     ----------------------------------------------------------------------
+
+8.2 Introduction
+
+   All access to the system is achieved via accounts, and all processes are
+   run by users, so user and account management are of integral importance on
+   DragonFly systems.
+
+   Every account on a DragonFly system has certain information associated
+   with it to identify the account.
+
+   User name
+
+           The user name as it would be typed at the login: prompt. User
+           names must be unique across the computer; you may not have two
+           users with the same user name. There are a number of rules for
+           creating valid user names, documented in passwd(5); you would
+           typically use user names that consist of eight or fewer all lower
+           case characters.
+
+   Password
+
+           Each account has a password associated with it. The password may
+           be blank, in which case no password will be required to access the
+           system. This is normally a very bad idea; every account should
+           have a password.
+
+   User ID (UID)
+
+           The UID is a number, traditionally from 0 to 65535[7], used to
+           uniquely identify the user to the system. Internally, DragonFly
+           uses the UID to identify users--any DragonFly commands that allow
+           you to specify a user name will convert it to the UID before
+           working with it. This means that you can have several accounts
+           with different user names but the same UID. As far as DragonFly is
+           concerned, these accounts are one user. It is unlikely you will
+           ever need to do this.
+
+   Group ID (GID)
+
+           The GID is a number, traditionally from 0 to 65535[7], used to
+           uniquely identify the primary group that the user belongs to.
+           Groups are a mechanism for controlling access to resources based
+           on a user's GID rather than their UID. This can significantly
+           reduce the size of some configuration files. A user may also be in
+           more than one group.
+
+   Login class
+
+           Login classes are an extension to the group mechanism that provide
+           additional flexibility when tailoring the system to different
+           users.
+
+   Password change time
+
+           By default DragonFly does not force users to change their
+           passwords periodically. You can enforce this on a per-user basis,
+           forcing some or all of your users to change their passwords after
+           a certain amount of time has elapsed.
+
+   Account expiry time
+
+           By default DragonFly does not expire accounts. If you are creating
+           accounts that you know have a limited lifespan, for example, in a
+           school where you have accounts for the students, then you can
+           specify when the account expires. After the expiry time has
+           elapsed the account cannot be used to log in to the system,
+           although the account's directories and files will remain.
+
+   User's full name
+
+           The user name uniquely identifies the account to DragonFly, but
+           does not necessarily reflect the user's real name. This
+           information can be associated with the account.
+
+   Home directory
+
+           The home directory is the full path to a directory on the system
+           in which the user will start when logging on to the system. A
+           common convention is to put all user home directories under
+           /home/username or /usr/home/username. The user would store their
+           personal files in their home directory, and any directories they
+           may create in there.
+
+   User shell
+
+           The shell provides the default environment users use to interact
+           with the system. There are many different kinds of shells, and
+           experienced users will have their own preferences, which can be
+           reflected in their account settings.
+
+   There are three main types of accounts: the Superuser, system users, and
+   user accounts. The Superuser account, usually called root, is used to
+   manage the system with no limitations on privileges. System users run
+   services. Finally, user accounts are used by real people, who log on, read
+   mail, and so forth.
+
+     ----------------------------------------------------------------------
+
+8.3 The Superuser Account
+
+   The superuser account, usually called root, comes preconfigured to
+   facilitate system administration, and should not be used for day-to-day
+   tasks like sending and receiving mail, general exploration of the system,
+   or programming.
+
+   This is because the superuser, unlike normal user accounts, can operate
+   without limits, and misuse of the superuser account may result in
+   spectacular disasters. User accounts are unable to destroy the system by
+   mistake, so it is generally best to use normal user accounts whenever
+   possible, unless you especially need the extra privilege.
+
+   You should always double and triple-check commands you issue as the
+   superuser, since an extra space or missing character can mean irreparable
+   data loss.
+
+   So, the first thing you should do after reading this chapter is to create
+   an unprivileged user account for yourself for general usage if you have
+   not already. This applies equally whether you are running a multi-user or
+   single-user machine. Later in this chapter, we discuss how to create
+   additional accounts, and how to change between the normal user and
+   superuser.
+
+     ----------------------------------------------------------------------
+
+8.4 System Accounts
+
+   System users are those used to run services such as DNS, mail, web
+   servers, and so forth. The reason for this is security; if all services
+   ran as the superuser, they could act without restriction.
+
+   Examples of system users are daemon, operator, bind (for the Domain Name
+   Service), and news. Often sysadmins create httpd to run web servers they
+   install.
+
+   nobody is the generic unprivileged system user. However, it is important
+   to keep in mind that the more services that use nobody, the more files and
+   processes that user will become associated with, and hence the more
+   privileged that user becomes.
+
+     ----------------------------------------------------------------------
+
+8.5 User Accounts
+
+   User accounts are the primary means of access for real people to the
+   system, and these accounts insulate the user and the environment,
+   preventing the users from damaging the system or other users, and allowing
+   users to customize their environment without affecting others.
+
+   Every person accessing your system should have a unique user account. This
+   allows you to find out who is doing what, prevent people from clobbering
+   each others' settings or reading each others' mail, and so forth.
+
+   Each user can set up their own environment to accommodate their use of the
+   system, by using alternate shells, editors, key bindings, and language.
+
+     ----------------------------------------------------------------------
+
+8.6 Modifying Accounts
+
+   There are a variety of different commands available in the UNIX
+   environment to manipulate user accounts. The most common commands are
+   summarized below, followed by more detailed examples of their usage.
+
+   +------------------------------------------------------------------------+
+   |  Command   |                          Summary                          |
+   |------------+-----------------------------------------------------------|
+   | adduser(8) | The recommended command-line application for adding new   |
+   |            | users.                                                    |
+   |------------+-----------------------------------------------------------|
+   | rmuser(8)  | The recommended command-line application for removing     |
+   |            | users.                                                    |
+   |------------+-----------------------------------------------------------|
+   | chpass(1)  | A flexible tool to change user database information.      |
+   |------------+-----------------------------------------------------------|
+   | passwd(1)  | The simple command-line tool to change user passwords.    |
+   |------------+-----------------------------------------------------------|
+   | pw(8)      | A powerful and flexible tool to modify all aspects of     |
+   |            | user accounts.                                            |
+   +------------------------------------------------------------------------+
+
+     ----------------------------------------------------------------------
+
+  8.6.1 adduser
+
+   adduser(8) is a simple program for adding new users. It creates entries in
+   the system passwd and group files. It will also create a home directory
+   for the new user, copy in the default configuration files (``dotfiles'')
+   from /usr/share/skel, and can optionally mail the new user a welcome
+   message.
+
+   To create the initial configuration file, use adduser -s -config_create.
+   [8] Next, we configure adduser(8) defaults, and create our first user
+   account, since using root for normal usage is evil and nasty.
+
+   Example 8-1. Configuring adduser and adding a user
+
+ # adduser -v
+ Use option ``-silent'' if you don't want to see all warnings and questions.
+ Check /etc/shells
+ Check /etc/master.passwd
+ Check /etc/group
+ Enter your default shell: csh date no sh tcsh zsh [sh]: zsh
+ Your default shell is: zsh -> /usr/local/bin/zsh
+ Enter your default HOME partition: [/home]:
+ Copy dotfiles from: /usr/share/skel no [/usr/share/skel]:
+ Send message from file: /etc/adduser.message no
+ [/etc/adduser.message]: no
+ Do not send message
+ Use passwords (y/n) [y]: y
+
+ Write your changes to /etc/adduser.conf? (y/n) [n]: y
+
+ Ok, let's go.
+ Don't worry about mistakes. I will give you the chance later to correct any input.
+ Enter username [a-z0-9_-]: jru
+ Enter full name []: J. Random User
+ Enter shell csh date no sh tcsh zsh [zsh]:
+ Enter home directory (full path) [/home/jru]:
+ Uid [1001]:
+ Enter login class: default []:
+ Login group jru [jru]:
+ Login group is ``jru''. Invite jru into other groups: guest no
+ [no]: wheel
+ Enter password []:
+ Enter password again []:
+
+ Name:     jru
+ Password: ****
+ Fullname: J. Random User
+ Uid:      1001
+ Gid:      1001 (jru)
+ Class:   
+ Groups:   jru wheel
+ HOME:     /home/jru
+ Shell:    /usr/local/bin/zsh
+ OK? (y/n) [y]: y
+ Added user ``jru''
+ Copy files from /usr/share/skel to /home/jru
+ Add another user? (y/n) [y]: n
+ Goodbye!
+ #
+
+   In summary, we changed the default shell to zsh (an additional shell found
+   in pkgsrc), and turned off the sending of a welcome mail to added users.
+   We then saved the configuration, created an account for jru, and made sure
+   jru is in wheel group (so that she may assume the role of root with the
+   su(1) command.)
+
+     Note: The password you type in is not echoed, nor are asterisks
+     displayed. Make sure you do not mistype the password twice.
+
+     Note: Just use adduser(8) without arguments from now on, and you will
+     not have to go through changing the defaults. If the program asks you to
+     change the defaults, exit the program, and try the -s option.
+
+     ----------------------------------------------------------------------
+
+  8.6.2 rmuser
+
+   You can use rmuser(8) to completely remove a user from the system.
+   rmuser(8) performs the following steps:
+
+    1. Removes the user's crontab(1) entry (if any).
+
+    2. Removes any at(1) jobs belonging to the user.
+
+    3. Kills all processes owned by the user.
+
+    4. Removes the user from the system's local password file.
+
+    5. Removes the user's home directory (if it is owned by the user).
+
+    6. Removes the incoming mail files belonging to the user from /var/mail.
+
+    7. Removes all files owned by the user from temporary file storage areas
+       such as /tmp.
+
+    8. Finally, removes the username from all groups to which it belongs in
+       /etc/group.
+
+         Note: If a group becomes empty and the group name is the same as the
+         username, the group is removed; this complements the per-user unique
+         groups created by adduser(8).
+
+   rmuser(8) cannot be used to remove superuser accounts, since that is
+   almost always an indication of massive destruction.
+
+   By default, an interactive mode is used, which attempts to make sure you
+   know what you are doing.
+
+   Example 8-2. rmuser Interactive Account Removal
+
+ # rmuser jru
+ Matching password entry:
+ jru:*:1001:1001::0:0:J. Random User:/home/jru:/usr/local/bin/zsh
+ Is this the entry you wish to remove? y
+ Remove user's home directory (/home/jru)? y
+ Updating password file, updating databases, done.
+ Updating group file: trusted (removing group jru -- personal group is empty) done.
+ Removing user's incoming mail file /var/mail/jru: done.
+ Removing files belonging to jru from /tmp: done.
+ Removing files belonging to jru from /var/tmp: done.
+ Removing files belonging to jru from /var/tmp/vi.recover: done.
+ #
+
+     ----------------------------------------------------------------------
+
+  8.6.3 chpass
+
+   chpass(1) changes user database information such as passwords, shells, and
+   personal information.
+
+   Only system administrators, as the superuser, may change other users'
+   information and passwords with chpass(1).
+
+   When passed no options, aside from an optional username, chpass(1)
+   displays an editor containing user information. When the user exists from
+   the editor, the user database is updated with the new information.
+
+   Example 8-3. Interactive chpass by Superuser
+
+ #Changing user database information for jru.
+ Login: jru
+ Password: *
+ Uid [#]: 1001
+ Gid [# or name]: 1001
+ Change [month day year]:
+ Expire [month day year]:
+ Class:
+ Home directory: /home/jru
+ Shell: /usr/local/bin/zsh
+ Full Name: J. Random User
+ Office Location:
+ Office Phone:
+ Home Phone:
+ Other information:
+
+   The normal user can change only a small subset of this information, and
+   only for themselves.
+
+   Example 8-4. Interactive chpass by Normal User
+
+ #Changing user database information for jru.
+ Shell: /usr/local/bin/zsh
+ Full Name: J. Random User
+ Office Location:
+ Office Phone:
+ Home Phone:
+ Other information:
+
+     Note: chfn(1) and chsh(1) are just links to chpass(1), as are
+     ypchpass(1), ypchfn(1), and ypchsh(1). NIS support is automatic, so
+     specifying the yp before the command is not necessary. If this is
+     confusing to you, do not worry, NIS will be covered in Chapter 19.
+
+     ----------------------------------------------------------------------
+
+  8.6.4 passwd
+
+   passwd(1) is the usual way to change your own password as a user, or
+   another user's password as the superuser.
+
+     Note: To prevent accidental or unauthorized changes, the original
+     password must be entered before a new password can be set.
+
+   Example 8-5. Changing Your Password
+
+ % passwd
+ Changing local password for jru.
+ Old password:
+ New password:
+ Retype new password:
+ passwd: updating the database...
+ passwd: done
+
+   Example 8-6. Changing Another User's Password as the Superuser
+
+ # passwd jru
+ Changing local password for jru.
+ New password:
+ Retype new password:
+ passwd: updating the database...
+ passwd: done
+
+     Note: As with chpass(1), yppasswd(1) is just a link to passwd(1), so NIS
+     works with either command.
+
+     ----------------------------------------------------------------------
+
+  8.6.5 pw
+
+   pw(8) is a command line utility to create, remove, modify, and display
+   users and groups. It functions as a front end to the system user and group
+   files. pw(8) has a very powerful set of command line options that make it
+   suitable for use in shell scripts, but new users may find it more
+   complicated than the other commands presented here.
+
+     ----------------------------------------------------------------------
+
+8.7 Limiting Users
+
+   If you have users, the ability to limit their system use may have come to
+   mind. DragonFly provides several ways an administrator can limit the
+   amount of system resources an individual may use. These limits are divided
+   into two sections: disk quotas, and other resource limits.
+
+   Disk quotas limit disk usage to users, and they provide a way to quickly
+   check that usage without calculating it every time. Quotas are discussed
+   in Section 12.12.
+
+   The other resource limits include ways to limit the amount of CPU, memory,
+   and other resources a user may consume. These are defined using login
+   classes and are discussed here.
+
+   Login classes are defined in /etc/login.conf. The precise semantics are
+   beyond the scope of this section, but are described in detail in the
+   login.conf(5) manual page. It is sufficient to say that each user is
+   assigned to a login class (default by default), and that each login class
+   has a set of login capabilities associated with it. A login capability is
+   a name=value pair, where name is a well-known identifier and value is an
+   arbitrary string processed accordingly depending on the name. Setting up
+   login classes and capabilities is rather straight-forward and is also
+   described in login.conf(5).
+
+   Resource limits are different from plain vanilla login capabilities in two
+   ways. First, for every limit, there is a soft (current) and hard limit. A
+   soft limit may be adjusted by the user or application, but may be no
+   higher than the hard limit. The latter may be lowered by the user, but
+   never raised. Second, most resource limits apply per process to a specific
+   user, not the user as a whole. Note, however, that these differences are
+   mandated by the specific handling of the limits, not by the implementation
+   of the login capability framework (i.e., they are not really a special
+   case of login capabilities).
+
+   And so, without further ado, below are the most commonly used resource
+   limits (the rest, along with all the other login capabilities, may be
+   found in login.conf(5)).
+
+   coredumpsize
+
+           The limit on the size of a core file generated by a program is,
+           for obvious reasons, subordinate to other limits on disk usage
+           (e.g., filesize, or disk quotas). Nevertheless, it is often used
+           as a less-severe method of controlling disk space consumption:
+           since users do not generate core files themselves, and often do
+           not delete them, setting this may save them from running out of
+           disk space should a large program (e.g., emacs) crash.
+
+   cputime
+
+           This is the maximum amount of CPU time a user's process may
+           consume. Offending processes will be killed by the kernel.
+
+             Note: This is a limit on CPU time consumed, not percentage of
+             the CPU as displayed in some fields by top(1) and ps(1). A limit
+             on the latter is, at the time of this writing, not possible, and
+             would be rather useless: legitimate use of a compiler, for
+             instance, can easily use almost 100% of a CPU for some time.
+
+   filesize
+
+           This is the maximum size of a file the user may possess. Unlike
+           disk quotas, this limit is enforced on individual files, not the
+           set of all files a user owns.
+
+   maxproc
+
+           This is the maximum number of processes a user may be running.
+           This includes foreground and background processes alike. For
+           obvious reasons, this may not be larger than the system limit
+           specified by the kern.maxproc sysctl(8). Also note that setting
+           this too small may hinder a user's productivity: it is often
+           useful to be logged in multiple times or execute pipelines. Some
+           tasks, such as compiling a large program, also spawn multiple
+           processes (e.g., make(1), cc(1), and other intermediate
+           preprocessors).
+
+   memorylocked
+
+           This is the maximum amount a memory a process may have requested
+           to be locked into main memory (e.g., see mlock(2)). Some
+           system-critical programs, such as amd(8), lock into main memory
+           such that in the event of being swapped out, they do not
+           contribute to a system's trashing in time of trouble.
+
+   memoryuse
+
+           This is the maximum amount of memory a process may consume at any
+           given time. It includes both core memory and swap usage. This is
+           not a catch-all limit for restricting memory consumption, but it
+           is a good start.
+
+   openfiles
+
+           This is the maximum amount of files a process may have open. In
+           DragonFly, files are also used to represent sockets and IPC
+           channels; thus, be careful not to set this too low. The
+           system-wide limit for this is defined by the kern.maxfiles
+           sysctl(8).
+
+   sbsize
+
+           This is the limit on the amount of network memory, and thus mbufs,
+           a user may consume. This originated as a response to an old DoS
+           attack by creating a lot of sockets, but can be generally used to
+           limit network communications.
+
+   stacksize
+
+           This is the maximum size a process' stack may grow to. This alone
+           is not sufficient to limit the amount of memory a program may use;
+           consequently, it should be used in conjunction with other limits.
+
+   There are a few other things to remember when setting resource limits.
+   Following are some general tips, suggestions, and miscellaneous comments.
+
+     * Processes started at system startup by /etc/rc are assigned to the
+       daemon login class.
+
+     * Although the /etc/login.conf that comes with the system is a good
+       source of reasonable values for most limits, only you, the
+       administrator, can know what is appropriate for your system. Setting a
+       limit too high may open your system up to abuse, while setting it too
+       low may put a strain on productivity.
+
+     * Users of the X Window System (X11) should probably be granted more
+       resources than other users. X11 by itself takes a lot of resources,
+       but it also encourages users to run more programs simultaneously.
+
+     * Remember that many limits apply to individual processes, not the user
+       as a whole. For example, setting openfiles to 50 means that each
+       process the user runs may open up to 50 files. Thus, the gross amount
+       of files a user may open is the value of openfiles multiplied by the
+       value of maxproc. This also applies to memory consumption.
+
+   For further information on resource limits and login classes and
+   capabilities in general, please consult the relevant manual pages:
+   cap_mkdb(1), getrlimit(2), login.conf(5).
+
+     ----------------------------------------------------------------------
+
+8.8 Personalizing Users
+
+   Localization is an environment set up by the system administrator or user
+   to accommodate different languages, character sets, date and time
+   standards, and so on. This is discussed in the localization chapter.
+
+     ----------------------------------------------------------------------
+
+8.9 Groups
+
+   A group is simply a list of users. Groups are identified by their group
+   name and GID (Group ID). In DragonFly (and most other UNIX like systems),
+   the two factors the kernel uses to decide whether a process is allowed to
+   do something is its user ID and list of groups it belongs to. Unlike a
+   user ID, a process has a list of groups associated with it. You may hear
+   some things refer to the ``group ID'' of a user or process; most of the
+   time, this just means the first group in the list.
+
+   The group name to group ID map is in /etc/group. This is a plain text file
+   with four colon-delimited fields. The first field is the group name, the
+   second is the encrypted password, the third the group ID, and the fourth
+   the comma-delimited list of members. It can safely be edited by hand
+   (assuming, of course, that you do not make any syntax errors!). For a more
+   complete description of the syntax, see the group(5) manual page.
+
+   If you do not want to edit /etc/group manually, you can use the pw(8)
+   command to add and edit groups. For example, to add a group called teamtwo
+   and then confirm that it exists you can use:
+
+   Example 8-7. Adding a Group Using pw(8)
+
+ # pw groupadd teamtwo
+ # pw groupshow teamtwo
+ teamtwo:*:1100:
+
+   The number 1100 above is the group ID of the group teamtwo. Right now,
+   teamtwo has no members, and is thus rather useless. Let's change that by
+   inviting jru to the teamtwo group.
+
+   Example 8-8. Adding Somebody to a Group Using pw(8)
+
+ # pw groupmod teamtwo -M jru
+ # pw groupshow teamtwo
+ teamtwo:*:1100:jru
+
+   The argument to the -M option is a comma-delimited list of users who are
+   members of the group. From the preceding sections, we know that the
+   password file also contains a group for each user. The latter (the user)
+   is automatically added to the group list by the system; the user will not
+   show up as a member when using the groupshow command to pw(8), but will
+   show up when the information is queried via id(1) or similar tool. In
+   other words, pw(8) only manipulates the /etc/group file; it will never
+   attempt to read additionally data from /etc/passwd.
+
+   Example 8-9. Using id(1) to Determine Group Membership
+
+ % id jru
+ uid=1001(jru) gid=1001(jru) groups=1001(jru), 1100(teamtwo)
+
+   As you can see, jru is a member of the groups jru and teamtwo.
+
+   For more information about pw(8), see its manual page, and for more
+   information on the format of /etc/group, consult the group(5) manual page.
+
+     ----------------------------------------------------------------------
+
+                   Chapter 9 Configuring the DragonFly Kernel
+
+   Updated and restructured by Jim Mock. Originally contributed by Jake
+   Hamby.
+
+9.1 Synopsis
+
+   The kernel is the core of the DragonFly operating system. It is
+   responsible for managing memory, enforcing security controls, networking,
+   disk access, and much more. While more and more of DragonFly becomes
+   dynamically configurable it is still occasionally necessary to reconfigure
+   and recompile your kernel.
+
+   After reading this chapter, you will know:
+
+     * Why you might need to build a custom kernel.
+
+     * How to write a kernel configuration file, or alter an existing
+       configuration file.
+
+     * How to use the kernel configuration file to create and build a new
+       kernel.
+
+     * How to install the new kernel.
+
+     * How to create any entries in /dev that may be required.
+
+     * How to troubleshoot if things go wrong.
+
+     ----------------------------------------------------------------------
+
+9.2 Why Build a Custom Kernel?
+
+   Traditionally, DragonFly has had what is called a ``monolithic'' kernel.
+   This means that the kernel was one large program, supported a fixed list
+   of devices, and if you wanted to change the kernel's behavior then you had
+   to compile a new kernel, and then reboot your computer with the new
+   kernel.
+
+   Today, DragonFly is rapidly moving to a model where much of the kernel's
+   functionality is contained in modules which can be dynamically loaded and
+   unloaded from the kernel as necessary. This allows the kernel to adapt to
+   new hardware suddenly becoming available (such as PCMCIA cards in a
+   laptop), or for new functionality to be brought into the kernel that was
+   not necessary when the kernel was originally compiled. This is known as a
+   modular kernel. Colloquially these are called KLDs.
+
+   Despite this, it is still necessary to carry out some static kernel
+   configuration. In some cases this is because the functionality is so tied
+   to the kernel that it can not be made dynamically loadable. In others it
+   may simply be because no one has yet taken the time to write a dynamic
+   loadable kernel module for that functionality yet.
+
+   Building a custom kernel is one of the most important rites of passage
+   nearly every UNIX user must endure. This process, while time consuming,
+   will provide many benefits to your DragonFly system. Unlike the GENERIC
+   kernel, which must support a wide range of hardware, a custom kernel only
+   contains support for your PC's hardware. This has a number of benefits,
+   such as:
+
+     * Faster boot time. Since the kernel will only probe the hardware you
+       have on your system, the time it takes your system to boot will
+       decrease dramatically.
+
+     * Less memory usage. A custom kernel often uses less memory than the
+       GENERIC kernel, which is important because the kernel must always be
+       present in real memory. For this reason, a custom kernel is especially
+       useful on a system with a small amount of RAM.
+
+     * Additional hardware support. A custom kernel allows you to add in
+       support for devices such as sound cards, which are not present in the
+       GENERIC kernel.
+
+     ----------------------------------------------------------------------
+
+9.3 Building and Installing a Custom Kernel
+
+   First, let us take a quick tour of the kernel build directory. All
+   directories mentioned will be relative to the main /usr/src/sys directory,
+   which is also accessible through /sys. There are a number of
+   subdirectories here representing different parts of the kernel, but the
+   most important, for our purposes, are arch/conf, where you will edit your
+   custom kernel configuration, and compile, which is the staging area where
+   your kernel will be built. arch represents either i386 or amd64, at this
+   point in development. Everything inside a particular architecture's
+   directory deals with that architecture only; the rest of the code is
+   common to all platforms to which DragonFly could potentially be ported.
+   Notice the logical organization of the directory structure, with each
+   supported device, file system, and option in its own subdirectory.
+
+     Note: If there is not a /usr/src/sys directory on your system, then the
+     kernel source has not been installed. The easiest way to do this is via
+     cvsup.
+
+   Next, move to the arch/conf directory and copy the GENERIC configuration
+   file to the name you want to give your kernel. For example:
+
+ # cd /usr/src/sys/i386/conf
+ # cp GENERIC MYKERNEL
+
+   Traditionally, this name is in all capital letters and, if you are
+   maintaining multiple DragonFly machines with different hardware, it is a
+   good idea to name it after your machine's hostname. We will call it
+   MYKERNEL for the purpose of this example.
+
+     Tip: Storing your kernel config file directly under /usr/src can be a
+     bad idea. If you are experiencing problems it can be tempting to just
+     delete /usr/src and start again. Five seconds after you do that you
+     realize that you have deleted your custom kernel config file. Do not
+     edit GENERIC directly, as it may get overwritten the next time you
+     update your source tree, and your kernel modifications will be lost.
+
+     You might want to keep your kernel config file elsewhere, and then
+     create a symbolic link to the file in the i386 directory.
+
+     For example:
+
+ # cd /usr/src/sys/i386/conf
+ # mkdir /root/kernels
+ # cp GENERIC /root/kernels/MYKERNEL    
+ # ln -s /root/kernels/MYKERNEL
+
+     Note: You must execute these and all of the following commands under the
+     root account or you will get permission denied errors.
+
+   Now, edit MYKERNEL with your favorite text editor. If you are just
+   starting out, the only editor available will probably be vi, which is too
+   complex to explain here, but is covered well in many books in the
+   bibliography. However, DragonFly does offer an easier editor called ee
+   which, if you are a beginner, should be your editor of choice. Feel free
+   to change the comment lines at the top to reflect your configuration or
+   the changes you have made to differentiate it from GENERIC.
+
+   If you have built a kernel under SunOS(TM) or some other BSD operating
+   system, much of this file will be very familiar to you. If you are coming
+   from some other operating system such as DOS, on the other hand, the
+   GENERIC configuration file might seem overwhelming to you, so follow the
+   descriptions in the Configuration File section slowly and carefully.
+
+     Note: Be sure to always check the file /usr/src/UPDATING, before you
+     perform any update steps, in the case you sync your source tree with the
+     latest sources of the DragonFly project. In this file all important
+     issues with updating DragonFly are typed out. /usr/src/UPDATING always
+     fits your version of the DragonFly source, and is therefore more
+     accurate for new information than the handbook.
+
+   Building a Kernel
+
+    1. Change to the /usr/src directory.
+
+ # cd /usr/src
+
+    2. Compile the kernel.
+
+ # make buildkernel KERNCONF=MYKERNEL
+
+    3. Install the new kernel.
+
+ # make installkernel KERNCONF=MYKERNEL
+
+   If you have not upgraded your source tree in any way since the last time
+   you successfully completed a buildworld-installworld cycle (you have not
+   run CVSup), then it is safe to use the quickworld and quickkernel,
+   buildworld, buildkernel sequence.
+
+   The new kernel will be copied to the root directory as /kernel and the old
+   kernel will be moved to /kernel.old. Now, shutdown the system and reboot
+   to use your new kernel. In case something goes wrong, there are some
+   troubleshooting instructions at the end of this chapter. Be sure to read
+   the section which explains how to recover in case your new kernel does not
+   boot.
+
+     Note: If you have added any new devices (such as sound cards), you may
+     have to add some device nodes to your /dev directory before you can use
+     them. For more information, take a look at Making Device Nodes section
+     later on in this chapter.
+
+     ----------------------------------------------------------------------
+
+9.4 The Configuration File
+
+   The general format of a configuration file is quite simple. Each line
+   contains a keyword and one or more arguments. For simplicity, most lines
+   only contain one argument. Anything following a # is considered a comment
+   and ignored. The following sections describe each keyword, generally in
+   the order they are listed in GENERIC, although some related keywords have
+   been grouped together in a single section (such as Networking) even though
+   they are actually scattered throughout the GENERIC file. An exhaustive
+   list of options and more detailed explanations of the device lines is
+   present in the LINT configuration file, located in the same directory as
+   GENERIC. If you are in doubt as to the purpose or necessity of a line,
+   check first in LINT.
+
+   The following is an example GENERIC kernel configuration file with various
+   additional comments where needed for clarity. This example should match
+   your copy in /usr/src/sys/i386/conf/GENERIC fairly closely. For details of
+   all the possible kernel options, see /usr/src/sys/i386/conf/LINT.
+
+ #
+ #
+ # GENERIC -- Generic kernel configuration file for DragonFly/i386
+ #
+ # Check the LINT configuration file in sys/i386/conf, for an
+ # exhaustive list of options.
+ #
+
+   The following are the mandatory keywords required in every kernel you
+   build:
+
+ machine         i386
+
+   This is the machine architecture. It must be either i386, or amd64.
+
+ cpu          I386_CPU
+ cpu          I486_CPU
+ cpu          I586_CPU
+ cpu          I686_CPU
+
+   The above option specifies the type of CPU you have in your system. You
+   may have multiple instances of the CPU line (i.e., you are not sure
+   whether you should use I586_CPU or I686_CPU), however, for a custom
+   kernel, it is best to specify only the CPU you have. If you are unsure of
+   your CPU type, you can check the /var/run/dmesg.boot file to view your
+   boot up messages.
+
+ ident          GENERIC
+
+   This is the identification of the kernel. You should change this to
+   whatever you named your kernel, i.e. MYKERNEL if you have followed the
+   instructions of the previous examples. The value you put in the ident
+   string will print when you boot up the kernel, so it is useful to give the
+   new kernel a different name if you want to keep it separate from your
+   usual kernel (i.e. you want to build an experimental kernel).
+
+ maxusers          n
+
+   The maxusers option sets the size of a number of important system tables.
+   This number is supposed to be roughly equal to the number of simultaneous
+   users you expect to have on your machine.
+
+   (Recommended) The system will auto-tune this setting for you if you
+   explicitly set it to 0[9]. If you want to manage it yourself you will want
+   to set maxusers to at least 4, especially if you are using the X Window
+   System or compiling software. The reason is that the most important table
+   set by maxusers is the maximum number of processes, which is set to 20 +
+   16 * maxusers, so if you set maxusers to 1, then you can only have 36
+   simultaneous processes, including the 18 or so that the system starts up
+   at boot time, and the 15 or so you will probably create when you start the
+   X Window System. Even a simple task like reading a manual page will start
+   up nine processes to filter, decompress, and view it. Setting maxusers to
+   64 will allow you to have up to 1044 simultaneous processes, which should
+   be enough for nearly all uses. If, however, you see the dreaded proc table
+   full error when trying to start another program, or are running a server
+   with a large number of simultaneous users, you can always increase the
+   number and rebuild.
+
+     Note: maxusers does not limit the number of users which can log into
+     your machine. It simply sets various table sizes to reasonable values
+     considering the maximum number of users you will likely have on your
+     system and how many processes each of them will be running. One keyword
+     which does limit the number of simultaneous remote logins and X terminal
+     windows is pseudo-device pty 16.
+
+ # Floating point support - do not disable.
+ device          npx0     at nexus? port IO_NPX irq 13
+
+   npx0 is the interface to the floating point math unit in DragonFly, which
+   is either the hardware co-processor or the software math emulator. This is
+   not optional.
+
+ # Pseudo devices - the number indicates how many units to allocate.
+ pseudo-device   loop          # Network loopback
+
+   This is the generic loopback device for TCP/IP. If you telnet or FTP to
+   localhost (a.k.a., 127.0.0.1) it will come back at you through this
+   device. This is mandatory.
+
+   Everything that follows is more or less optional. See the notes underneath
+   or next to each option for more information.
+
+ #makeoptions     DEBUG=-g          #Build kernel with gdb(1) debug symbols
+
+   The normal build process of the DragonFly does not include debugging
+   information when building the kernel and strips most symbols after the
+   resulting kernel is linked, to save some space at the install location. If
+   you are going to do tests of kernels in the DEVELOPMENT branch or develop
+   changes of your own for the DragonFly kernel, you might want to uncomment
+   this line. It will enable the use of the -g option which enables debugging
+   information when passed to gcc(1).
+
+ options          MATH_EMULATE      #Support for x87 emulation
+
+   This line allows the kernel to simulate a math co-processor if your
+   computer does not have one (386 or 486SX). If you have a 486DX, or a 386
+   or 486SX (with a separate 387 or 487 chip), or higher (Pentium,
+   Pentium II, etc.), you can comment this line out.
+
+     Note: The normal math co-processor emulation routines that come with
+     DragonFly are not very accurate. If you do not have a math co-processor,
+     and you need the best accuracy, it is recommended that you change this
+     option to GPL_MATH_EMULATE to use the GNU math support, which is not
+     included by default for licensing reasons.
+
+ options          INET          #InterNETworking
+
+   Networking support. Leave this in, even if you do not plan to be connected
+   to a network. Most programs require at least loopback networking (i.e.,
+   making network connections within your PC), so this is essentially
+   mandatory.
+
+ options          INET6          #IPv6 communications protocols
+
+   This enables the IPv6 communication protocols.
+
+ options          FFS          #Berkeley Fast Filesystem
+ options          FFS_ROOT     #FFS usable as root device [keep this!]
+
+   This is the basic hard drive Filesystem. Leave it in if you boot from the
+   hard disk.
+
+ options          UFS_DIRHASH  #Improve performance on big directories
+
+   This option includes functionality to speed up disk operations on large
+   directories, at the expense of using additional memory. You would normally
+   keep this for a large server, or interactive workstation, and remove it if
+   you are using DragonFly on a smaller system where memory is at a premium
+   and disk access speed is less important, such as a firewall.
+
+ options          SOFTUPDATES  #Enable FFS Soft Updates support
+
+   This option enables Soft Updates in the kernel, this will help speed up
+   write access on the disks. Even when this functionality is provided by the
+   kernel, it must be turned on for specific disks. Review the output from
+   mount(8) to see if Soft Updates is enabled for your system disks. If you
+   do not see the soft-updates option then you will need to activate it using
+   the tunefs(8) (for existing filesystems) or newfs(8) (for new filesystems)
+   commands.
+
+ options          MFS          #Memory Filesystem
+ options          MD_ROOT      #MD is a potential root device
+
+   This is the memory-mapped filesystem. This is basically a RAM disk for
+   fast storage of temporary files, useful if you have a lot of swap space
+   that you want to take advantage of. A perfect place to mount an MFS
+   partition is on the /tmp directory, since many programs store temporary
+   data here. To mount an MFS RAM disk on /tmp, add the following line to
+   /etc/fstab:
+
+ /dev/ad1s2b     /tmp mfs rw 0 0
+
+   Now you simply need to either reboot, or run the command mount /tmp.
+
+ options          NFS          #Network Filesystem
+ options          NFS_ROOT     #NFS usable as root device, NFS required
+
+   The network Filesystem. Unless you plan to mount partitions from a UNIX
+   file server over TCP/IP, you can comment these out.
+
+ options          MSDOSFS      #MSDOS Filesystem
+
+   The MS-DOS Filesystem. Unless you plan to mount a DOS formatted hard drive
+   partition at boot time, you can safely comment this out. It will be
+   automatically loaded the first time you mount a DOS partition, as
+   described above. Also, the excellent mtools software (in pkgsrc) allows
+   you to access DOS floppies without having to mount and unmount them (and
+   does not require MSDOSFS at all).
+
+ options          CD9660       #ISO 9660 Filesystem
+ options          CD9660_ROOT  #CD-ROM usable as root, CD9660 required
+
+   The ISO 9660 Filesystem for CDROMs. Comment it out if you do not have a
+   CDROM drive or only mount data CDs occasionally (since it will be
+   dynamically loaded the first time you mount a data CD). Audio CDs do not
+   need this Filesystem.
+
+ options          PROCFS       #Process filesystem
+
+   The process filesystem. This is a ``pretend'' filesystem mounted on /proc
+   which allows programs like ps(1) to give you more information on what
+   processes are running.
+
+ options          COMPAT_43    #Compatible with BSD 4.3 [KEEP THIS!]
+
+   Compatibility with 4.3BSD. Leave this in; some programs will act strangely
+   if you comment this out.
+
+ options          SCSI_DELAY=15000    #Delay (in ms) before probing SCSI
+
+   This causes the kernel to pause for 15 seconds before probing each SCSI
+   device in your system. If you only have IDE hard drives, you can ignore
+   this, otherwise you will probably want to lower this number, perhaps to
+   five seconds (5000 ms), to speed up booting. Of course, if you do this,
+   and DragonFly has trouble recognizing your SCSI devices, you will have to
+   raise it back up.
+
+ options          UCONSOLE            #Allow users to grab the console
+
+   Allow users to grab the console, which is useful for X users. For example,
+   you can create a console xterm by typing xterm -C, which will display any
+   write(1), talk(1), and any other messages you receive, as well as any
+   console messages sent by the kernel.
+
+ options          USERCONFIG          #boot -c editor
+
+   This option allows you to boot the configuration editor from the boot
+   menu.
+
+ options          VISUAL_USERCONFIG   #visual boot -c editor
+
+   This option allows you to boot the