- •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
...............................................................................................
# make update
...............................................................................................
Some people find it more pleasant to simply go to /usr/src and type make update && make buildworld && make install than to give the full CVSup command. It's up to you.
[1]This format is called a "diff," and is quite common in the UNIX world.
[2]Unless, of course, strange behavior, weird crashes, and lost data make you happy.
Building a Local CVSup Server
Many people have quite a few FreeBSD systems. During an upgrade from source, however, every single server must connect to a FreeBSD CVS server and download the latest code, which can be a pain. For one, all of the mirrors are maintained by volunteers who are donating the servers and bandwidth. Why download the same bits over and over again?
Also, each server might wind up with slightly different code if they all connect to different servers. Suppose you log in to each server and start a CVSup. In the few minutes between starting each source−code upgrade, the code on the CVSup server might change slightly. The mirrors aren't going to stop updating their code just because you're in the middle of upgrading four machines, and if you're running several production machines, you'd be best served if all the systems were absolutely identical. Even if they're running a version of −stable somewhere between 4.4−release and 4.5−release, being able to eliminate different versions of the software as a potential problem can help troubleshooting immensely. You don't want to think, "Gee, server 1 keeps dying; could it be because each server has a slightly different version of FreeBSD?" That way lies madness.
You can address this problem by running a central CVSup server (also known as a "cvsupd" server), which is essentially your own local mirror. You can control when your local mirror updates, and you can guarantee that all of your machines have exactly the same code. Doing so will not only make you popular with the mirror operators (or at least, won't make you unpopular with them), it will also eliminate a variety of possible problems resulting from having different code on each of your servers. You can still have problems if you have different settings in /etc/make.conf, but you can compare those files yourself and see what you're doing differently. It is much easier to compare two files than several thousand!
It's not particularly easy to run a CVSup server, but there's help to make it simpler. The port /usr/ports/net/cvsup−mirror handles all the tricky bits of configuring a mirror. When you install the port, cvsup−mirror asks you some questions; there are default suggestions, but you should change many of them. We'll discuss software installation in detail in Chapter 9, but installing this port is pretty straightforward.
First, make sure you have an Internet connection, and enter the following commands:
...............................................................................................
#cd /usr/ports/net/cvsup−mirror
#make install clean
...............................................................................................
You will see messages scroll up your screen, including the compiler messages you should recognize by now. (You might not know what they mean, but you should recognize compiling when you see it.)
132
At some point, the install process will pause and prompt you for information:
...............................................................................................
Master site for your updates [cvsup−master.FreeBSD.org]?
...............................................................................................
The default site, http://cvsup−master.freebsd.org/, is reserved for official FreeBSD mirror use only; you can use it if you become an official mirror and allow the world access to your system. If not, use one of the 80−odd public CVSup servers instead. If you're setting up a CVSup mirror, you should have already identified a public mirror that's close to you. Enter the name of that mirror.
The next prompt will look like this:
...............................................................................................
How many hours between updates of your files [1]?
...............................................................................................
The script updates /etc/crontab (explained in Chapter 9) to run CVSup automatically. You can accept this default, or change it easily. If you accept the default, your system will upgrade itself once an hour via cron. This is the way the official mirrors do it. I generally enter 168, which updates the repository once a week, since I will not be upgrading servers more than weekly! Your first update will take quite a while, but later updates generally only take a few minutes.
Note |
In many cases, I only upgrade the CVSup server by hand by running the |
|
script /usr/local/etc/cvsup/update.sh. To upgrade a group of machines all |
|
to the same version of −stable, all you have to do is update your CVSup |
|
server once and upgrade all the machines from the server. I frequently |
|
upgrade one server, put it through several rounds of extensive |
|
quality−assurance testing, and upgrade the rest from the same CVSup |
|
batch, which guarantees good code and identical systems. There is no |
|
requirement for you to be more up to date than you wish; the source |
|
code is yours to do with as you see fit, after all! If you update your server |
|
manually, you will want to edit /etc/crontab to remove the automatic |
|
update! We'll discuss /etc/crontab in Chapter 9. |
...............................................................................................
Do you wish to mirror the main source repository [y]?
...............................................................................................
Most people just need the main source repository, so the default is usually fine.
...............................................................................................
Where would you like to put it [/home/ncvs]? /repo
...............................................................................................
This prompt is where you enter the path to the location on disk where you want your mirror kept. I frequently add a separate, small disk to a system to keep the mirror on, and call that disk /repo. You can put it in the default location of /home/ncvs without any problems.
133
Since you probably want only the main source repository, answer n to the next three questions:
...............................................................................................
Do you wish to mirror the installed World Wide Web data [y]? n
Do you wish to mirror the GNATS bug tracking database [y]? n
Do you wish to mirror the mailing list archive [y]? n
...............................................................................................
Of course, if you'd prefer to mirror the whole http://www.freebsd.org/ site, including the PR database and the mailing list archives, answer y. But be warned: the mailing list archives are huge. The source repository itself is well over 1GB at this writing, and growing continuously.
Use unique user and group IDs for the next series of questions. (Do not use "nobody", "nonroot", or "nogroup".) You can use the defaults, or change the usernames and group names to fit your local scheme:
...............................................................................................
Unique unprivileged user ID for running the client [cvsupin]? Unique unprivileged group ID for running the client [cvsupin]? Unique unprivileged user ID for running the server [cvsup]?
Unique unprivileged group ID for running the server [cvsup]?
...............................................................................................
Lastly, the maximum simultaneous client connections is easy to change later, so don't sweat it. It's fine to accept the default:
...............................................................................................
Maximum simultaneous client connections [8]?
...............................................................................................
Once you finish answering the questions, the make install process picks up where you left off, adds these usernames, sets the configuration, and generally gets you ready to go.
Controlling Access
Just because you want to be a good systems administrator and have a private repository doesn't mean that you want every Joe Sixpack to download from your CVSup mirror. The CVSup server allows you to control which computers have access to the mirror.
The file /usr/local/etc/cvsup/cvsupd.access controls which hosts may connect to your CVSup mirror. Lines beginning with the pound symbol (#) denote a comment; a plus sign (+) means that the client can connect, and a hyphen (−) means that the client cannot. An asterisk (*) means that the client must authenticate, as discussed in the following "Authentication" section.
Each rule in cvsupd.access can refer to either a hostname or an IP address; IP addresses are preferred. You can use netmasks with IP addresses as well.
For example, to allow access from the network 192.168.0.0/16 and explicitly reject clients accessing from elsewhere, use these lines:
134
...............................................................................................
+192.168.0.0/16
−0.0.0.0/0
...............................................................................................
Controlling access by IP address is good for a static network. For example, an Internet service provider (ISP) knows the IP addresses of its servers and can easily keep them in cvsupd.access. You might need a more flexible system, however, if you're connecting from random IP addresses. When I was consulting, for example, I kept a mirror that accepted connections from any IP address. Users needed a username and password to connect, however. If your cvsupd.access file is empty, access is controlled entirely by username and password authentication.
Authentication
Use authentication to allow connections to your CVSup mirror from any location on the Internet. The CVSup server uses a challenge−response system for authentication, rather than transmitting passwords in clear text. When a client connects, it combines its shared secret (CVSup for "password") and the system time, and runs them through a scrambler. The server does the same. In theory, both the client and the server are performing the same calculations on the same piece of secret data, and both should get the same answer. If the client's scrambled message matches what the server computed, the server assumes that the client has the secret data and permits access.
This is a very secure system. For example, if someone drops a packet sniffer on the network, she cannot grab the password. What's more, since the challenge−response system incorporates the time, a captured response cannot be used a second time.
Authentication requires a password file, /usr/local/etc/cvsup/cvsupd.passwd, which must only be readable by the CVSup user so that no one else can grab user information. (You can do this by running chown cvsup cvsupd.passwd and chmod 600 cvsupd.passwd.) If you don't have a password file, access will be controlled entirely by the cvsupd.access file.
Blank lines and comment lines (which begin with #) in cvsupd.passwd are ignored. The first code line in cvsupd.passwd is the server name and a private key, separated by a colon.
...............................................................................................
magpire.AbsoluteBSD.com:testkey
...............................................................................................
The server name is sent back to the client, and the private key is used for additional randomness. You don't have to have a private key—the CVSup password system is pretty random as is–but you must have the colon that precedes the private key. The private key cannot contain a colon.
Next in the file, you have your legitimate users. Each user appears on a separate line, in the following format:
...............................................................................................
user ID:shared secret:class:comment
...............................................................................................
135
CVSup IDs are email addresses, such as mwlucas@AbsoluteBSD.com. The shared secret is based upon a cryptographic hash saying you're the administrator's chosen password for that user. The class field is reserved for future use, and should be left blank. Finally, the comment field can be used by the administrator. For example, if you give someone access to your CVSup mirror, it's a good idea to put in a comment stating why they have access. (You might remember now, but will you remember in a year or two?)
The cvpasswd(1) command automates generating these cvsupd.passwd entries. Cvpasswd takes two arguments: the email address of the user and the server name. It will ask you for the password for this user twice, and spit out some instructions.
...............................................................................................
# cvpasswd mwlucas@AbsoluteBSD.com magpire.AbsoluteBSD.com Enter password:
Enter same password again:
Send this line to the server administrator at magpire.AbsoluteBSD.com:
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
v mwlucas@AbsoluteBSD.com:$md5$bf489b753a0a949a1c63a3f5da0d61b6::
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Be sure to send it using a secure channel!
Add this line to your file "$HOME/.cvsup/auth", replacing "XXX" with the password you typed in:
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
magpire.AbsoluteBSD.com:mwlucas@AbsoluteBSD.com:XXX: −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Make sure the file is readable and writable only by you!
#
...............................................................................................
The cryptic line in the middle of this output (v) gives the username and the shared secret, based upon the password. Send this line to the user you want to allow to connect. The "secure channel" mentioned means that you should send this line in such a way that it cannot be captured by hostile people on the Internet. You can read the code to the other user over the phone, hand−type it into the system, copy it to a floppy disk, and hand−deliver it, or encrypt it with PGP and email it. If you send it via standard unencrypted email, anyone who captures the email en route can use this to try to access your CVSup server. However, if someone steals this information, the risk of unauthorized access is not that great; a user still needs the password to access the mirror.
Once the user has this line, he puts it in his home directory in the file .cvsup/auth. This can be copied to any system he wants to upgrade from this CVSup server. He also needs to make sure that nobody else can read this file, by running chmod 600 .cvsup/auth.
On the server side, copy that same line into /usr/local/etc/cvsup/cvsupd.passwd. It is formatted to be a correct, although minimal, password entry. You can add a comment at the end, if you like.
Once you have this entry on both the client and server sides, the user will be prompted for a password each time he runs CVSup and tries to connect to this server.
Note If you have neither cvsupd.access nor cvsupd.passwd, anyone can connect to your server from any location on the Internet. The FreeBSD Project is happy to let anyone run a mirror, but you should be aware that you are doing so!
136