- •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
...............................................................................................
# pkg_add −f packagename.tgz
...............................................................................................
You'll see a warning that a dependency was not found, but that the install is proceeding anyway. If the software works, great! If not, uninstall it and start working with ports.
[3]No, Microsoft Word is not available on FreeBSD. Yet. But it's very difficult to think of a major, recognizable example of binary−only software for FreeBSD, as almost all of it is available in source form.
Using Ports
It takes longer to build software using ports than it does when using packages, and the ports system requires a live Internet connection. Still, the ports system can produce better results than packages.
Let's take a look at a port. We're going to pick on one of my favorite security tools, SKIP.[4]
...............................................................................................
#cd /usr/ports/security/skip
#ls
v Makefile |
x |
distinfo |
z |
pkg−comment |
| pkg−plist |
|
w |
README.html y |
files |
{ |
pkg−descr |
} scripts |
|
# |
|
|
|
|
|
|
...............................................................................................
The Makefile in the preceding list (v) contains the basic instructions for building this port. If you were to take a look at this file, you'd quickly notice that there isn't much in it. The Makefiles for individual ports don't contain much beyond some basic information about the port; they don't have information about how to build FreeBSD software in general. (Most of the FreeBSD ports Makefile system is contained in the directory /usr/ports/Mk; editing these files is a very advanced topic, and you really don't want to go there until you're very comfortable with Makefiles.)
The README.html file (w) gives a brief description of the port. If you're using a Web browser to skim the ports collection, you'll be directed to this file when you ask for information on this port.
The distinfo file (x) contains integrity−checking information (or checksums) for the files required to build this program.
The files directory (y) contains any add−on files required to build this port. Our particular example requires 87 patches, but many ports don't even have a files directory, and build cleanly without patching.
The pkg−comment file (z) contains a one−line description of the port. Similarly, pkg−descr ({) contains a longer, more detailed description and (usually) a URL for more information on the program.
The pkg−plist file (|) holds a list of all the files installed by the port (the "packing list"). If a file is not listed here, it will not be installed.
238
Finally, the scripts directory (}) holds a variety of scripts to be run at various stages of the port−building process. This directory might or might not exist—if the port builds without any special tweaking, it won't have any additional scripts. These scripts perform any pre− or post−processing that the port needs, for example, changing permissions on a downloaded distfile so that patch(1) can run properly.
Combined, these files create the tools and instructions needed to build the software.
Installing a Port
If you're familiar with source code, you'll quickly notice that there is no actual source code in the port. Sure, there's patches to apply to source code, and scripts to run on source code, but no actual source code! You might rightly ask just how this is supposed to work without the source code.
When you activate a port, your system automatically downloads the appropriate source code from an approved Internet site. It then checks the downloaded code for integrity errors, extracts the code to a working directory, patches it, builds it, installs everything, and records the installation under /var/db/pkg. If the port has dependencies, and those dependencies aren't installed, it will interrupt the make process to build those dependencies, and then finish its own. To trigger all this, you just have to go to a port directory and type this command:
...............................................................................................
# make install
...............................................................................................
When you do, you'll see lots of text scroll down your terminal window, ending with a "recording installation" message.
This all−in−one installation process handles any changes in dependencies. If a port requires another program, the port will simply gloss over minor changes in that program. For example, perhaps you have a version of Apache that's a few months old. A package would demand that you install the newer version, while a port will just check to see if Apache is installed.
As you grow more experienced with building source code, however, you'll find that this all−in−one approach isn't appropriate for every occasion. Not to worry; the ports system gives you the opportunity to take the port−building process exactly as far as you like, because make install is actually not one but a series of commands.
Using Make Install
The make install process starts with make fetch. During this stage of the process, make checks to see whether the source code is in /usr/ports/distfiles. If it's not, your system goes to get it.
Make Fetch The make fetch process first checks for the source code in the MASTER_SITE listed in the Makefile, then checks a list of backup sites provided by the ports system itself. If it finds the source code, it downloads it, and that downloaded source code is called a distfile.
Make Checksum Next, make checksum confirms that the distfile's digital signature matches the one that the port has in the distinfo file. This is a security measure; if the FTP server was broken into by a malicious hacker and the source code replaced by a Trojan horse, or if the download was
239
corrupted, this step will detect it and stop the build with a warning about a checksum mismatch. If the distfile has been deliberately changed, make checksum stops compilation.
NoteSoftware authors sometimes make minor changes to their code, but give the source file the same name as when they first made it available for download. The FreeBSD port might or might not work after this change. If you're sure that the distfile has not been compromised or corrupted, and want to use it despite this warning, you can override this with make NO_CHECKSUM=YES. I highly recommend that you check with your vendor to see if this is a legitimate change.
Make Depends The make depends stage checks to see if the port is dependent on any other software, and, if so, whether that software is installed. (For example, an X window manager requires an X server.) If the software on which the port depends is not found, this stage recurses through the various dependencies and completely builds them all.
Make Extract Once you have the port distfiles, you have to uncompress and extract them. This is done under a work directory in the port. To create this directory and uncompress the distfiles under it, use make extract.
Make Patch The make patch stage applies any FreeBSD−specific patches listed in the Makefile to the port.
Make Configure Next, make configure checks to see if the program needs a configure script. If it does, it runs it. If not, the port build proceeds silently to the next step.
Make Build The make build stage compiles the checked, extracted, and patched software.
Make Install Finally, make install installs the software and records its presence under /var/db/pkg.
Make Target Dependencies Each make target depends on the make targets before it. You cannot patch source code that you have not yet fetched, for example. Whenever you use any make target, make runs all previous stages that have not yet been run. For example, make extract performs a make fetch, make checksum, and make extract.
How might you use these make stages in practice? Say that you want to apply some patches to a program before you compile it—patches that address stability or security problems. You want to apply the patch to your source code after you've extracted it and applied the FreeBSD−specific patches. To do so, you could run make patch, apply the new patches to the software under the work directory according to the vendor's instructions, and then return to the port directory and type make install.
Built−In Port Features
Ports allow you to do a great deal of customization, which you can read about in the port's Makefile. Since the port's Makefile includes specific instructions for building this particular piece of software, it's where options for that software are most likely to be found.
Many ports announce additional features when you first type make install, though not all will work (especially some older ones). Whether a feature will work depends on the port maintainer's skills, time, and inclination—remember, this is a volunteer project!
240
You can always get information about a port's additional features from the Makefile, but let's look at an announcement and see how to use it first. For example, when you try to install /usr/ports/security/snort you'll see a notice:
...............................................................................................
Set WITH_FLEXRESP, WITH_MYSQL, WITH_ODBC or WITH_POSTGRES
to get additional support.
...............................................................................................
A bit of Web searching would show you that mysql, odbc, and postgresql are database packages, and this message tells you that you could build Snort with support for these databases. A similar search would show that flexresp is part of the libnet software package.
If you get an announcement, and you want to use one of these options, press CONTROL−C to abort the port build. You can then set these options on the install command line like this:
...............................................................................................
# make WITH_ODBC=YES install
...............................................................................................
This command changes the way the port will be built and will build your version of Snort with support for ODBC database connections. With this feature built into Snort, you would then be able to log data across the network to any database that supports ODBC, such as Microsoft SQL Server or an Oracle database.
Here's one area where ports shine over packages. You couldn't do this customization with a package, unless you had multiple versions of the same package. And sorting through snort−odbc−1.9.tgz, snort−mysql−1.9.tgz, snort−postgres−mysql−libnet−1.9.tgz, and so on would be utterly hideous, waste space on the CD, and be mostly unused.
The Makefile itself will tell you the build options for a port. At the top of the Makefile, you'll see a lot of stuff that describes the port, like this:
...............................................................................................
v PORTNAME= |
snort |
w PORTVERSION= |
1.8 |
x CATEGORIES= |
security |
y MASTER_SITES= |
http://www.snort.org/Files/ \ |
|
http://www.physik.TU−Berlin.DE/~ibex/ |
|
ports/distfiles/ |
z DISTNAME= |
${PORTNAME}−${PORTVERSION}−RELEASE |
{ MAINTAINER= |
dirk@FreeBSD.org |
| GNU_CONFIGURE= |
yes |
} CONFIGURE_ARGS= |
−−with−mysql=no −−with−odbc=no −−with−po stgresql=no |
~ MAN8= |
snort.8 |
...............................................................................................
Much of this is obvious to people who habitually build software from source. If you're not at that point yet, don't worry. You'll get there with practice. Let's consider this particular example. Not all of
241
these entries are mandatory, and there are many other possible entries in port Makefiles, but these are fairly common.
The PORTNAME (v) is the name the software uses in FreeBSD's ports system. This is not necessarily the same as the software name, as we saw earlier in our search for Midnight Commander. The PORTVERSION (w) is the version number of the software, as given by the software's author.
CATEGORIES (x) lists all the ports directories where the port can be found. For example, this port is under /usr/ports/security.
MASTER_SITES (y) contains a list of Internet sites where the software can be found. This is where the ports system tries to get the software from. If one site is unreachable, it tries the next.
The DISTNAME (z) is the name of the original file of software source code. The ports system tries to grab this file from the MASTER_SITES given earlier.
The MAINTAINER ({) is the person responsible for maintaining the FreeBSD port. This person doesn't actually write the software, but just makes sure that it installs on FreeBSD.
GNU_CONFIGURE (|) tells the ports system if the software needs to use the classic GNU program autoconf. In a related entry, CONFIGURE_ARGS (}) lists arguments to be given to autoconf.
There is usually a list of man pages that the program installs (~). You can check these pages with man(1) to see how to use the program. You might then see a bunch of "if defined" statements like this one:
...............................................................................................
.if defined v (WITH_FLEXRESP)
BUILD_DEPENDS w += ${LOCALBASE}/lib/libnet.a:$ ? {PORTSDIR}/net/libnet CONFIGURE_ARGS +=−−enable−flexresp
CONFIGURE_ENV += CPPFLAGS="−I${LOCALBASE}/include" LDFLAGS+= "−L${LOCALBASE}/lib"
.endif
...............................................................................................
This is a build option for the port. The first line in this example is the variable (v) you need to set—in this case, WITH_FLEXRESP. The second line shows that this adds a dependency (w) for the port, /usr/ports/net/libnet. The remainder is a bunch of software−building commands that are altered by setting this variable.
You set this variable on the command line. To set WITH_FLEXRESP, you would type
...............................................................................................
# make install WITH_FLEXRESP=YES
...............................................................................................
You don't need to understand the balance of this listing right now, but notice the little question mark
(?) and plus and equal (+=) symbols scattered throughout it. These mean that you're adding commands to the build process, literally changing how the software is built just by setting this
242