- •Table of Contents
- •Dedication
- •Foreword
- •Introduction
- •What Is FreeBSD?
- •How Did FreeBSD Get Here?
- •The BSD License: BSD Goes Public
- •The Birth of Modern FreeBSD
- •FreeBSD Development
- •Committers
- •Contributors
- •Users
- •Other BSDs
- •NetBSD
- •OpenBSD
- •Other UNIXes
- •Solaris
- •Linux
- •IRIX, HPUX, etc.
- •FreeBSD's Strengths
- •Portability
- •Power
- •Simplified Software Management
- •Optimized Upgrade Process
- •Filesystem
- •Who Should Use FreeBSD
- •FreeBSD as Your Desktop
- •Who Should Run Another BSD
- •Who Should Run a Proprietary Operating System
- •How to Read This Book
- •What Must You Know?
- •How to Think About UNIX
- •Channels of Communication
- •Working with Channels
- •The Command Line
- •Chapter 1: Installation
- •FreeBSD Hardware
- •Processor
- •Memory (RAM)
- •Hard Drives
- •Downloading FreeBSD
- •Installing by FTP
- •Other FTP Install Information
- •Hardware Setup
- •Actually Installing FreeBSD
- •Configuring the Kernel for ISA Cards
- •Sysinstall: The Ugly FreeBSD Installer
- •Disk Usage
- •Partitioning
- •Root
- •Swap Space
- •Swap Splitting
- •/var, /usr, and /home
- •A Second Hard Drive
- •Soft Updates
- •Block Size
- •What to Install
- •Installation Media
- •Committing
- •Root Password
- •Adding Users
- •Time Zone
- •Mouse
- •Configuring Network Cards
- •Xfree86
- •Software
- •Restart
- •A Note on Editors
- •Chapter 2: Getting More Help
- •Why Not Mail First?
- •The FreeBSD Attitude
- •Man Pages
- •The FreeBSD Manual
- •Man Page Headings
- •The FreeBSD Documentation
- •The Mailing List Archives
- •Other Web Sites
- •Checking the Handbook/FAQ
- •Checking the Man Pages
- •Checking the Mailing List Archives
- •Using Your Answer
- •Mailing for Help
- •Chapter 3: Read This Before You Break Something Else! (Backup and Recovery)
- •Overview
- •System Backups
- •Tape Devices
- •How to Read Dmesg.boot
- •Controlling Your Tape Drive
- •Device Nodes
- •Using the TAPE Variable
- •The mt Command
- •Backup Programs
- •Dump/Restore
- •Restoring from an Archive
- •Checking the Contents of an Archive
- •Extracting Data from an Archive
- •Restoring Interactively
- •Recording What Happened
- •Revision Control
- •Getting Older Versions
- •Breaking Locks
- •Viewing Log Messages
- •Reviewing a File's Revision History
- •Ident and ident Strings
- •Going Further
- •The Fixit Disk
- •Chapter 4: Kernel Games
- •Overview
- •What Is the Kernel?
- •Configuring Your Kernel
- •Sysctl
- •Changing Sysctls
- •Setting Sysctls at Boot
- •Kernel Configuration with Loader.conf
- •Manually Configuring the Loader
- •Viewing Loaded Modules
- •Loading and Unloading Modules
- •Customizing the Kernel
- •Preparation
- •Your Backup Kernel
- •Editing Kernel Files
- •Basic Options
- •Multiple Processors
- •Device Entries
- •Building Your Kernel
- •Troubleshooting Kernel Builds
- •Booting an Alternate Kernel
- •Adding to the Kernel
- •LINT
- •Fixing Errors with Options
- •Tweaking Kernel Performance
- •Sharing Kernels
- •Chapter 5: Networking
- •Overview
- •Network Layers
- •The Physical Layer
- •The Physical Protocol Layer
- •The Logical Protocol Layer
- •The Application Layer
- •The Network in Practice
- •Mbufs
- •What Is a Bit?
- •Ethernet
- •Broadcasting
- •Address Resolution
- •Hubs and Switches
- •Netmasks
- •Netmask Tricks
- •Hexadecimal Netmasks
- •Unusable IP Addresses
- •Routing
- •Network Ports
- •Connecting to an Ethernet Network
- •Multiple IP Addresses on One Interface
- •Using Netstat
- •Chapter 6: Upgrading FreeBSD
- •Overview
- •FreeBSD Versions
- •Release
- •Snapshots
- •Security Updates
- •Which Release Should You Use?
- •Upgrade Methods
- •Upgrading via Sysinstall
- •Upgrading via CVSup
- •Simplifying the CVSup Upgrade Process
- •Building a Local CVSup Server
- •Controlling Access
- •Authentication
- •Combining Authentication and Access
- •Chapter 7: Securing Your System
- •Overview
- •Who Is the Enemy?
- •Script Kiddies
- •Disaffected Users
- •Skilled Attackers
- •FreeBSD Security Announcements
- •Subscribing
- •What You'll Get
- •Installation Security Profiles
- •Moderate
- •Extreme
- •Root, Groups, and Permissions
- •The root Password
- •Groups of Users
- •Primary Group
- •Some Interesting Default Groups
- •Group Permissions
- •Changing Permissions
- •Changing File Ownership
- •Assigning Permissions
- •File Flags
- •Viewing a File's Flags
- •Setting Flags
- •Securelevels
- •Setting Securelevels
- •Which Securelevel Do You Need?
- •What Won't Securelevel and File Flags Do?
- •Living with Securelevels
- •Programs That Can Be Hacked
- •Putting It All Together
- •Chapter 8: Advanced Security Features
- •Traffic Control
- •Default Accept vs. Default Deny
- •TCP Wrappers
- •Configuring Wrappers
- •Daemon Name
- •The Client List
- •Putting It All Together
- •Packet Filtering
- •IPFilter
- •IPFW
- •Default Accept and Default Deny in Packet Filtering
- •Basic Concepts of Packet Filtering
- •Implementing IPFilter
- •Configuring Your Server to Use Jail
- •Configuring Your Kernel to Use Jail
- •Client Setup
- •Final Jail Setup
- •Starting the Jail
- •Managing Jails
- •Shutting Down a Jail
- •Monitoring System Security
- •If You're Hacked
- •Chapter 9: Too Much Information About /etc
- •Overview
- •Varieties of /etc Files
- •Default Files
- •/etc/defaults/rc.conf
- •/etc/adduser.conf
- •/etc/crontab
- •/etc/dhclient.conf
- •/etc/fstab
- •/etc/hosts.allow
- •/etc/hosts.equiv
- •/etc/hosts.lpd
- •/etc/inetd.conf
- •/etc/locate.rc
- •/etc/login.access
- •/etc/login.conf
- •Specifying Default Environment Settings
- •/etc/mail/mailer.conf
- •/etc/make.conf and /etc/defaults/make.conf
- •/etc/master.passwd
- •/etc/motd
- •/etc/mtree/*
- •/etc/namedb/*
- •/etc/newsyslog.conf
- •/etc/passwd
- •/etc/periodic.conf and /etc/defaults/periodic.conf
- •/etc/printcap
- •Working with Printcap Entries
- •/etc/profile
- •/etc/protocols
- •/etc/rc.conf and /etc/defaults/rc.conf
- •/etc/resolv.conf
- •/etc/security
- •/etc/services
- •/etc/shells
- •/etc/spwd.db
- •/etc/sysctl.conf
- •/etc/syslog.conf
- •Chapter 10: Making Your System Useful
- •Overview
- •Making Software
- •The Pain and Pleasure of Source Code
- •Debugging
- •The Ports and Packages System
- •Ports
- •Finding Software
- •Legal Restrictions
- •Using Packages
- •Installing via FTP
- •What Does a Package Install?
- •Uninstalling Packages
- •Package Information
- •Controlling Pkg_add
- •Package Problems
- •Forcing an Install
- •Using Ports
- •Installing a Port
- •Using Make Install
- •Uninstalling and Reinstalling
- •Cleaning Up with Make Clean
- •Building Packages
- •Changing the Install Path
- •Setting Make Options Permanently
- •Upgrading Ports and Packages
- •Upgrading the Ports Collection
- •Ports Collection Upgrade Issues
- •Checking Software Versions
- •Hints for Upgrading
- •Chapter 11: Advanced Software Management
- •Overview
- •Startup and Shutdown Scripts
- •Typical Startup Script
- •Using Scripts to Manage Running Programs
- •Managing Shared Libraries
- •Ldconfig
- •Running Software from the Wrong OS
- •Recompilation
- •Emulation
- •ABI Implementation
- •Foreign Software Libraries
- •Installing and Enabling Linux Mode
- •Identifying Programs
- •What Is Linux_base?
- •Adding to Linux_base
- •Configuring Linux Shared Libraries
- •Installing Extra Linux Packages as RPMs
- •What Is SMP?
- •Kernel Assumptions
- •FreeBSD 3.0 SMP
- •FreeBSD 5 SMP
- •Using SMP
- •SMP and Upgrades
- •Chapter 12: Finding Hosts With DNS
- •How DNS Works
- •Basic DNS Tools
- •The Host Command
- •Getting Detailed Information with Dig
- •Looking Up Hostnames with Dig
- •More Dig Options
- •Configuring a DNS Client: The Resolver
- •Domain or Search Keywords
- •The Nameserver List
- •DNS Information Sources
- •The Hosts File
- •The Named Daemon
- •Zone Files
- •A Real Sample Zone
- •named.conf
- •/var/named/master/absolutebsd.com
- •Making Changes Work
- •Starting Named at Boottime
- •Checking DNS
- •Named Configuration Errors
- •Named Security
- •Controlling Information Order
- •More About BIND
- •Chapter 13: Managing Small Network Services
- •Bandwidth Control
- •Configuring IPFW
- •Reviewing IPFW Rules
- •Dummynet Queues
- •Directional Traffic Shaping
- •Certificates
- •Create a Request
- •Being Your Own CA
- •Testing SSH
- •Enabling SSH
- •Basics of SSH
- •Creating Keys
- •Confirming SSH Identity
- •SSH Clients
- •Connecting via SSH
- •Configuring SSH
- •System Time
- •Setting the Time Zone
- •Network Time Protocol
- •Ntpdate
- •Ntpd
- •Inetd
- •/etc/inetd.conf
- •Configuring Programs in Inetd
- •Inetd Security
- •Starting Inetd
- •Changing Inetd's Behavior
- •Chapter 14: Email Services
- •Email Overview
- •Where FreeBSD Fits In
- •The Email Protocol
- •Email Programs
- •Who Needs Sendmail?
- •Replacing Sendmail
- •Installing Postfix
- •Pieces of Postfix
- •Configuring Postfix
- •Email Aliases
- •Email Logging
- •Virtual Domains
- •Postfix Commands
- •Finding the Correct Mail Host
- •Undeliverable Mail
- •Installing POP3
- •Testing POP3
- •POP3 Logging
- •POP3 Modes
- •Qpopper Preconfiguration Questions
- •Default Qpopper Configuration
- •APOP Setup
- •Configuring Pop3ssl
- •Qpopper Security
- •Chapter 15: Web and FTP Services
- •Overview
- •How a Web Server Works
- •The Apache Web Server
- •Apache Configuration Files
- •Configuring Apache
- •Controlling Apache
- •Virtual Hosting
- •Tweaking Virtual Hosts
- •.NET on FreeBSD
- •Installing the SSCLI
- •FTP Security
- •The FTP Client
- •The FTP Server
- •Chapter 16: Filsystems and Disks
- •Device Nodes
- •Hard Disks and Partitions
- •The /etc/fstab File
- •Disk Basics
- •The Fast File System
- •Vnodes
- •FFS Mount Types
- •FFS Mount Options
- •What's Mounted Now?
- •Dirty Disks
- •Fsck
- •Mounting and Unmounting Disks
- •Mounting Standard Filesystems
- •Mounting with Options
- •Mounting All Standard Filesystems
- •Mounting at Nonstandard Locations
- •Unmounting
- •Soft Updates
- •Enabling Soft Updates
- •IDE Write Caching and Soft Updates
- •Virtual Memory Directory Caching
- •Mounting Foreign Filesystems
- •Using Foreign Mounts
- •Foreign Filesystem Types
- •Mount Options and Foreign Filesystems
- •Filesystem Permissions
- •Removable Media and /etc/fstab
- •Creating a Floppy
- •Creating an FFS Filesystem
- •The Basics of SCSI
- •SCSI Types
- •SCSI Adapters
- •SCSI Buses
- •Termination and Cabling
- •SCSI IDs and LUNs
- •FreeBSD and SCSI
- •Wiring Down Devices
- •Adding New Hard Disks
- •Creating Slices
- •Creating Partitions
- •Configuring /etc/fstab
- •Installing Existing Files onto New Disks
- •Temporary Mounts
- •Moving Files
- •Stackable Mounts
- •Chapter 17: RAID
- •Hardware vs. Software RAID
- •RAID Levels
- •Software RAID
- •Vinum Disk Components
- •Vinum Plex Types
- •Preparing Vinum Drives
- •Dedicating Partitions to Vinum
- •Configuring Vinum
- •Concatenated Plex
- •Removing Vinum Configuration
- •Striped Volumes
- •Mirrored Volumes
- •Starting Vinum at Boot
- •Other Vinum Commands
- •Replacing a Failed Mirrored Plex
- •Chapter 18: System Performance
- •Overview
- •Computer Resources
- •Disk Input/Output
- •Network Bandwidth
- •CPU and Memory
- •Using Top
- •Memory Usage
- •Swap Space Usage
- •CPU Usage
- •When Swap Goes Bad
- •Paging
- •Swapping
- •Are You Swapping or Paging?
- •Fairness in Benchmarking
- •The Initial Test
- •Using Both CPUs
- •Directory Caching
- •Moving /usr/obj
- •Lessons Learned
- •Chapter 19: Now What's It Doing?
- •Status Mails
- •Forwarding Reports
- •Logging with Syslogd
- •Facilities
- •Levels
- •Syslog.conf
- •Wildcards
- •Rotating Logs with Newsyslog.conf
- •Reporting with SNMP
- •Basics of SNMP
- •MIBs
- •Snmpwalk
- •Specific Snmpwalk Queries
- •Translating Between Numbers and Names
- •Setting Up Snmpd
- •Index Numbers
- •Configuring MRTG
- •Sample mrtg.cfg Entry
- •Testing MRTG
- •Tracking Other System Values
- •Monitoring a Single MIB
- •Customizing MRTG
- •MRTG Index Page
- •Sample MRTG Configurations
- •Chapter 20: System Crashes and Panics
- •What Causes Panics?
- •What Does a Panic Look Like?
- •Responding to a Panic
- •Prerequisites
- •Crash Dump Process
- •The Debugging Kernel
- •kernel.debug
- •Dumpon
- •Savecore
- •Upon a Crash
- •Dumps and Bad Kernels
- •Using the Dump
- •Advanced Kernel Debugging
- •Examining Lines
- •Examining Variables
- •Apparent Gdb Weirdness
- •Results
- •Vmcore and Security
- •Symbols vs. No Symbols
- •Serial Consoles
- •Hardware Serial Console
- •Software Serial Console
- •Changing the Configuration
- •Using a Serial Console
- •Serial Login
- •Emergency Logon Setup
- •Disconnecting the Serial Console
- •Submitting a Problem Report
- •Problem Report System
- •What's in a PR?
- •Filling Out the Form
- •PR Results
- •Chapter 21: Desktop FreeBSD
- •Overview
- •Accessing File Shares
- •Prerequisites
- •Character Sets
- •Kernel Support for CIFS
- •SMB Tools
- •Configuring CIFS
- •Minimum Configuration: Name Resolution
- •Other smbutil Functions
- •Mounting a Share
- •Other mount_smbfs Options
- •Sample nsmb.conf Entries
- •CIFS File Ownership
- •Serving Windows File Shares
- •Accessing Print Servers
- •Running a Local Lpd
- •Printer Testing
- •Local Printers
- •X: A Graphic Interface
- •X Prerequisites
- •X Versions
- •Configuring X
- •Making X Look Decent
- •Desktop Applications
- •Web Browsers
- •Email Readers
- •Office Suites
- •Music
- •Graphics
- •Desk Utilities
- •Games
- •Afterword
- •Overview
- •The Community
- •What Can You Do?
- •Getting Things Done
- •Second Opinions
- •Appendix: Some Useful SYSCTL MIBs
- •List of Figures
- •Chapter 1: Installation
- •Chapter 5: Networking
- •Chapter 6: Upgrading FreeBSD
- •Chapter 19: Now What's It Doing?
- •List of Tables
- •Chapter 4: Kernel Games
- •Chapter 5: Networking
- •Chapter 8: Advanced Security Features
- •Chapter 9: Too Much Information About /etc
- •List of Sidebars
- •Chapter 15: Web and FTP Services
For example, if you're running a program that fails at the same spot every time, you can use script to copy your keystrokes and what the screen says in response. This is particularly useful when upgrading your system or building software from source code; the last 30 or so lines of the typescript file make a nice addition to a request for help.
Revision Control
Generally speaking, revision control is the process of tracking changes. In the UNIX world, this means changes to source code or configuration files. Revision control allows a developer to see how a piece of code looked on a specific date, or an administrator to see how the system was configured before things stopped working. Even a lowly writer can use revision control to see how a manuscript has changed over time. If you're not using revision control, you're making your work more difficult than it needs to be.[2]
While you'll encounter many revision−control systems, from UNIX's SCCS (Source Code Control System) to Microsoft's Visual SourceSafe, we'll discuss RCS (Revision Control System), included with almost all UNIX systems. Once you learn how to work with RCS, you should find it simple to work with most any other revision−control system.
When using revision control, you're essentially keeping a record of what happened to a file. First, you mark the file as checked out, which tells the system that you are going to change the file. You then edit the file as you like, record changes in the system, and release the file for others to edit. RCS uses three basic commands to accomplish this: ci (check−in), co (check−out), and rcs.
Think of revision control as a library—an old−fashioned brick−and−mortar one. To edit a file, you must first tell RCS to keep track of it, or give it to the library. To use it you check it out, like removing a book from a library. Once checked out, nobody else can save or edit that file, though any legitimate user can view, use, copy, compile, or access that file. Once you finish with the file, you check it back in, thus releasing it for others to edit. The whole process is called RCS.
Each file in RCS has a version number. Each time you return an edited file to the system, the Revision Control System compares the returned file with what you checked out. If there is any change at all, the version number is increased by one, which is the system's way of tracking changes to the file. You can use the version number to identify specific versions of the file.
Begin the revision−control process by checking in a file with ci(1), which is much like giving a book to the library. For example, a good file to protect with RCS is /etc/rc.conf. To start the RCS process, enter ci <path/filename> as shown in the following listing:
...............................................................................................
v # ci /etc/rc.conf rc.conf,v <−− rc.conf
w enter description, terminated with single '.' or end of file: NOTE: This is NOT the log message!
x >>System configuration file y >> .
initial revision: 1.1 done
#
...............................................................................................
When you first check in a file with ci (v), ci creates or edits a revision−control file. You see this in the second line of the preceding output, where it creates rc.conf,v. It then asks you for a description (w); enter a descriptive bit of text here (x) for any RCS user to later view the file's description. (While this
61
description isn't very important for standard system files, it can be very helpful for source code or configuration files for custom or complex programs.) Once you've finished the description, enter a single period on a line by itself (y) to exit ci.
If you run ls immediately after checking something in, you'll notice that the file appears to have vanished. Instead you'll see a file with the same name, with a trailing ",v". This is an RCS file, where the file and its changes are stored. While it's fine for some files to disappear in this fashion, source code or Web pages can't just vanish. To solve that problem, when checking in a file you can leave a copy in the working directory with ci −u.
If a file is checked in and has vanished, and you want to put a clean copy in the working directory without editing it, use the co command. In the following example, you can see that the file test has been pulled out of the file test,v, and that it's revision 1.1.
...............................................................................................
# co test
test,v −−> test revision 1.1 done
#
...............................................................................................
Looking closely at the directory where the file test lives, you'll see this:
...............................................................................................
# ls −l total 62
−r−−r−−r−− 1 mwlucas mwlucas 12663 Oct 4 18:06 test −r−−r−−r−− 1 mwlucas mwlucas 12867 Oct 4 17:56 test,v
#
...............................................................................................
I own this file, test, but the permissions have been set to read−only (−r−−r−−r−−, as discussed in Chapter 7). I no longer have permission to edit my own files! This is because the file isn't checked out to me. I've checked it in, or handed it over to the Revision Control System librarian. I can view the file, but if I want to edit it, I have to ask the Revision Control Librarian for it—I need to check it out, and then lock it for my personal use. I use the −l flag with co.
...............................................................................................
# co −l test test,v −−> test
revision 1.1 (locked) done
...............................................................................................
Notice the third line of this listing (the second line of output), which specifies locked. This file is checked out and locked by me, and I am the only one who can save it until I unlock it.
Running another ls at this point will show that the permissions on the file test are now set back to read and write, allowing me to save.[3] (We'll discuss permissions in Chapter 7.) Anyone else who tries to check out this file will get a warning that the file is in use and will be told the username of the person who has locked the file.
62
When finished, I check in the file and, since I want other people to be able to edit the file, I use ci −u to release my lock.
...............................................................................................
# ci −u test test,v <−− test
new revision: 1.2; previous revision: 1.1
v enter log message, terminated with single '.' or end of file:
>>enable sendmail again
>>.
done
#
...............................................................................................
When you check something in, you are asked for a log message (v). Enter a brief description of your changes here. (These log messages are comparable to the CVS log messages seen on the various BSDs’ commit mailing lists.)
These log messages allow others to know what changes you've made to a file without checking through all the changes—or, alternatively, to see what you were trying to do when your change broke something and someone has to start debugging. Your own RCS logs can also be useful for you, months later, when you stare at something and wonder just what was going on inside your head at the time.
Note If you have lots of files in RCS, the ",v" files can quickly clutter a directory. You can hide them by creating a directory called RCS. The ci program will then put the ",v" files in that directory, keeping the working directory cleaner.
Now that you understand the basics of checking files in and out, let's examine some of the more interesting functions of RCS. These include getting old versions of files, breaking locks, finding differences between file versions, and putting RCS identifiers in files.
Getting Older Versions
Every file in RCS has a revision number, and each time you check in a file, the revision number increases. The system remembers what the file looked like during earlier revisions, however, so you can use the revision number to check out any previous version of a file.
For example, if you're trying to track a bug that's just appeared, you can check out earlier versions of your code to see if they also exhibit the bug by using co's −r flag. To retrieve version 1.1 of /etc/rc.conf, enter the following:
...............................................................................................
# co −r1.1 rc.conf
RCS/rc.conf,v −−> rc.conf revision 1.1
done
#
...............................................................................................
63
Breaking Locks
Always check files in once you've finished with them. If you don't, and another user needs to edit your locked file, they'll have to break your lock, and any changes you've made since locking it will be lost.
To break a lock on a file, use rcs −u. RCS will ask you to enter a message about why you're breaking the lock, and this message will be mailed to the lock holder.
Note Be careful when breaking locks: If someone is really editing a file when you force the lock, they'll be justifiably upset. If they've gone home for the day, that's another thing. Do your best to find the person before you break his or her lock!
Viewing Log Messages
The rlog command shows you the log messages for the file.
...............................................................................................
# rlog /etc/rc.conf
RCS file: /etc/RCS/rc.conf,v |
|
|
|
|
Working file: /etc/rc.conf |
|
|
|
|
head: 1.4 |
|
|
|
|
branch: |
|
|
|
|
locks: strict |
|
|
|
|
access list: |
|
|
|
|
symbolic names: |
|
|
|
|
keyword substitution: kv |
|
|
|
|
total revisions: 4; |
selected revisions: 4 |
|
|
|
description: |
|
|
|
|
−−−−−−−−−−−−−−−−−−−−−−−−−−−− |
|
|
|
|
revision 1.4 |
|
|
|
|
vdate: 2000/09/08 17:45:29; |
wauthor: mwlucas; |
xstate: Exp; ylines: +2 −0 |
||
minor updates |
|
|
|
|
−−−−−−−−−−−−−−−−−−−−−−−−−−−− |
|
|
|
|
revision 1.3 |
|
|
|
|
date: 2000/09/07 19:05:30; |
author: mwlucas; |
state: Exp; |
lines: +1 −1 |
|
z *** empty log message *** |
|
|
|
|
−−−−−−−−−−−−−−−−−−−−−−−−−−−− |
|
|
|
|
revision 1.2 |
|
|
|
|
date: 2000/09/05 16:09:47; |
author: mwlucas; |
state: Exp; |
lines: +1 −1 |
|
enable sendmail |
|
|
|
|
−−−−−−−−−−−−−−−−−−−−−−−−−−−− |
|
|
|
|
revision 1.1 |
|
|
|
|
date: 2000/09/02 14:53:43; |
author: mwlucas; |
state: Exp; |
|
|
Initial revision |
|
|
|
|
−−−−−−−−−−−−−−−−−−−−−−−−−−−− |
|
|
|
========================================================================
#
...............................................................................................
All sorts of useful information appear here, including the date each check−in was made (v), the author of the change (w), the entry's state (x), which we won't worry about here (see ci(1)), and the number of lines changed (y).
64