Book Freebsd
Uploaded by
api-3774955Book Freebsd
Uploaded by
api-3774955freebsd handbook
the freebsd documentation project
copyright (c) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by the
freebsd documentation project
welcome to freebsd! this handbook covers the installation and day to day
use of freebsd 4.5-release. 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 freebsd documentation project mailing list
<[email protected]>. the latest version of this document is always
available from the freebsd web site. it may also be downloaded in a
variety of formats and compression options from the freebsd ftp server or
one of the numerous mirror sites. if you would prefer to have a hard copy
of the handbook, you can purchase one at the freebsd mall. you may also
want to search the handbook.
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 freebsd documentation
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 freebsd
documentation 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.
----------------------------------------------------------------------
table of contents
preface
i. getting started
1 introduction
1.1 synopsis
1.2 welcome to freebsd!
1.3 about the freebsd project
2 installing freebsd
2.1 synopsis
2.2 pre-installation tasks
2.3 starting the installation
2.4 introducing sysinstall
2.5 allocating disk space
2.6 choosing what to install
2.7 choosing your installation media
2.8 committing to the installation
2.9 post-installation
2.10 supported hardware
2.11 troubleshooting
2.12 advanced installation guide
2.13 preparing your own installation media
3 unix basics
3.1 synopsis
3.2 permissions
3.3 directory structure
3.4 mounting and unmounting filesystems
3.5 processes
3.6 daemons, signals, and killing processes
3.7 shells
3.8 text editors
3.9 devices and device nodes
3.10 for more information...
4 installing applications: packages and ports
4.1 synopsis
4.2 overview of software installation
4.3 finding your application
4.4 using the packages system
4.5 using the ports collection
4.6 post-installation activities
4.7 troubleshooting
5 the x window system
5.1 synopsis
5.2 understanding x
5.3 installing xfree86
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 virtual hosts
6.7 configuration files
6.8 tuning with sysctl
6.9 tuning disks
6.10 tuning kernel limits
6.11 adding swap space
7 the freebsd booting process
7.1 synopsis
7.2 the booting problem
7.3 the mbr, and boot stages one, two, and three
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 freebsd 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 freebsd
10.4 des, md5, and crypt
10.5 s/key
10.6 kerberos
10.7 firewalls
10.8 openssl
10.9 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 network, memory, and file-based filesystems
12.5 file system quotas
12.6 creating and using optical media (cds &
dvds)
12.7 raid
12.8 tape backup media
12.9 backup programs
12.10 floppy disks
12.11 backups to floppies
13 localization - i18n/l10n usage and setup
13.1 synopsis
13.2 the basics
13.3 using localization
13.4 compiling i18n programs
13.5 localizing freebsd to specific languages
14 sound
14.1 synopsis
14.2 locating the correct device
14.3 creating and testing the device nodes
14.4 mp3 audio
15 serial communications
15.1 synopsis
15.2 introduction
15.3 terminals
15.4 dial-in service
15.5 dial-out service
15.6 setting up the serial console
16 ppp and slip
16.1 synopsis
16.2 using user ppp
16.3 using kernel ppp
16.4 using ppp over ethernet (pppoe)
16.5 using ppp over atm (pppoa)
16.6 using slip
17 advanced networking
17.1 synopsis
17.2 gateways and routes
17.3 bridging
17.4 nfs
17.5 diskless operation
17.6 isdn
17.7 nis/yp
17.8 dhcp
17.9 dns
17.10 ntp
17.11 network address translation
17.12 inetd ``super-server''
17.13 parallel line ip (plip)
18 electronic mail
18.1 synopsis
18.2 using electronic mail
18.3 sendmail configuration
18.4 troubleshooting
18.5 advanced topics
19 the cutting edge
19.1 synopsis
19.2 freebsd-current vs. freebsd-stable
19.3 synchronizing your source
19.4 using make world
19.5 tracking for multiple machines
20 linux binary compatibility
20.1 synopsis
20.2 installation
20.3 installing mathematica
20.4 installing maple
20.5 installing oracle
20.6 installing sap r/3 (4.6b - ides)
20.7 advanced topics
iii. appendices
a. obtaining freebsd
a.1 cdrom publishers
a.2 dvd publishers
a.3 ftp sites
a.4 anonymous cvs
a.5 using ctm
a.6 using cvsup
a.7 cvs tags
a.8 afs sites
b. bibliography
b.1 books & magazines specific to freebsd
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
c.4 email addresses
c.5 shell accounts
d. pgp keys
d.1 officers
d.2 core team members
d.3 developers
colophon
list of tables
2-1. sample device inventory
2-2. disk device codes
2-3. partition layout for first disk
2-4. partition layout for subsequent disks
2-5. possible security profiles
12-1. physical disk naming conventions
17-1. wiring a parallel cable for networking
list of figures
2-1. kernel configuration menu
2-2. the kernel device configuration visual interface
2-3. expanded driver list
2-4. driver configuration with no conflicts
2-5. sysinstall main menu
2-6. typical device probe results
2-7. select sysinstall exit
2-8. selecting usage from sysinstall main menu
2-9. selecting documentation menu
2-10. sysinstall documentation menu
2-11. sysinstall main menu
2-12. sysinstall keymap menu
2-13. sysinstall main menu
2-14. sysinstall options
2-15. begin standard installation
2-16. select drive for fdisk
2-17. typical fdisk partitions before editing
2-18. fdisk partition using entire disk
2-19. sysinstall boot manager menu
2-20. exit select drive
2-21. sysinstall disklabel editor
2-22. sysinstall disklabel editor with auto defaults
2-23. free space for root partition
2-24. edit root partition size
2-25. choose the root partition type
2-26. choose the root mount point
2-27. sysinstall disklabel editor
2-28. choose distributions
2-29. confirm distributions
2-30. choose installation media
2-31. selecting an ethernet device
2-32. set network configuration for ed0
2-33. editing inetd.conf
2-34. default anonymous ftp configuration
2-35. edit the ftp welcome message
2-36. editing the exports file
2-37. security profile options
2-38. system console configuration options
2-39. screensaver options
2-40. screensaver timeout
2-41. system console configuration exit
2-42. select your region
2-43. select your country
2-44. select your timezone
2-45. select mouse protocol type
2-46. set mouse protocol
2-47. configure mouse port
2-48. setting the mouse port
2-49. enable the mouse daemon
2-50. test the mouse daemon
2-51. select configuration method menu
2-52. select default desktop
2-53. select package category
2-54. select packages
2-55. install packages
2-56. confirm package installation
2-57. select add user
2-58. add user information
2-59. exit user and group management
2-60. exit install
list of examples
2-1. using an existing partition unchanged
2-2. shrinking an existing partition
2-3. sample disk, slice, and partition names
2-4. conceptual model of a disk
4-1. downloading a package and then 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
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 vnconfig to mount an existing filesystem image
12-2. creating a new file-backed disk with vnconfig
12-3. md memory disk
12-4. using rdump over ssh
12-5. a script for creating a bootable floppy
15-1. adding terminal entries to /etc/ttys
17-1. mounting an export with amd
17-2. branch office or home network
17-3. head office or other lan
17-4. sending inetd a hangup signal
18-1. configuring the sendmail access database
18-2. mail aliases
18-3. example virtual domain mail map
a-1. checking out something from -current (ls(1)) and deleting it again:
a-2. checking out the version of ls(1) in the 3.x-stable branch:
a-3. creating a list of changes (as unified diffs) to ls(1)
a-4. finding out what other module names can be used:
----------------------------------------------------------------------
preface
intended audience
the freebsd newcomer will find that the first section of this book guides
the user through the freebsd installation process, and gently introduces
the concepts and conventions that underpin unix. 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've have travelled this far, the second, far larger, section of
the handbook is a comprehensive reference to all manner of topics of
interest to freebsd 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.
changes from the first edition
this second edition is the culmination of over two years of work by the
dedicated members of the freebsd documentation project. the following are
the major changes in this new edition:
* a complete index has been added.
* all ascii figures have been replaced by graphical diagrams.
* a standard synopsis has been added to each chapter to give a quick
summary of what information the chapter contains, and what the reader
is expected to know.
* the content has been logically reorganized into three parts: "getting
started", "system administration", and "appendices".
* chapter 2 ("installing freebsd") was completely rewritten with many
screenshots to make it much easier for new users to grasp the text.
* chapter 3 ("unix basics") has been expanded to contain additional
information about processes, daemons, and signals.
* chapter 4 ("installing applications") has been expanded to contain
additional information about binary package management.
* chapter 5 ("the x window system") has been completely rewritten with
an emphasis on using modern desktop technologies such as kde and gnome
on xfree86 4.x.
* chapter 7 ("the freebsd booting process") has been expanded.
* chapter 12 ("storage") has been written from what used to be two
separate chapters on "disks" and "backups". we feel that the topics
are easier to comprehend when presented as a single chapter. a section
on raid (both hardware and software) has also been added.
* chapter 15 ("serial communications") has been completely reorganized
and updated for freebsd 4.x/5.x.
* chapter 16 ("ppp and slip") has been substantially updated.
* many new sections have been added to chapter 17 ("advanced
networking").
* chapter 18 ("electronic mail") has been expanded to include more
information about configuring sendmail.
* chapter 20 ("linux compatibility") has been expanded to include
information about installing oracle and sap/r3.
* the following new topics are covered in this second edition:
* configuration and tuning (chapter 6).
* sound (chapter 14)
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
freebsd. 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 freebsd 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 freebsd to a new user. it describes the history of the
freebsd project, the goals, development model, and everything else
they've done for the freebsd project.
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 freebsd
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 with both
freebsd's innovative "ports collection" and standard binary
packages.
chapter 5, the x window system
describes the x window system in general and using xfree86 on
freebsd 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 freebsd system for optimum performance. also describes the
various configuration files used in freebsd and where to find
them.
chapter 7, booting process
describes the freebsd 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 freebsd 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 freebsd
system secure, including kerberos, ipsec, openssh, and network
firewalls.
chapter 11, printing
describes managing printers on freebsd, including information
about banner pages, printer accounting, and initial setup.
chapter 12, storage
describes how to manage storage media and filesystems with
freebsd. this includes physical disks, raid arrays, optical and
tape media, memory-backed disks, and network filesystems.
chapter 13, localization
describes how to use freebsd in languages other than english.
covers both system and application level localization.
chapter 14, sound
shows how to setup sound support for your system. also describes
some sample audio applications.
chapter 15, serial communications
explains how to connect terminals and modems to your freebsd
system for both dial in and dial out connections.
chapter 16, ppp and slip
describes how to use ppp, slip, or ppp over ethernet to connect to
remote systems with freebsd.
chapter 17, 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 18, electronic mail
explains the different components of an email server and dives
into simple configuration topics for the most popular mail server
software: sendmail.
chapter 19, the cutting edge
explains the different between freebsd-stable, freebsd-current,
and freebsd releases. describes which users would benefit from
tracking a development system and outlines that process.
chapter 20, linux binary compatibility
describes the linux compatibility features of freebsd. also
provides detailed installation instructions for many popular linux
applications such as oracle, sap/r3, and mathematica.
appendix a, obtaining freebsd
lists different sources for obtaining freebsd media on cdrom or
dvd as well as different sites on the internet that allow you to
download and install freebsd.
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 freebsd users to post
questions and engage in technical conversations about freebsd.
appendix d, pgp keys
lists the pgp fingerprints of several freebsd 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 rendered in bold to stand out from other text. key combinations
that are meant to be typed simultaneously are rendered with `+' between
the keys, such as:
ctrl+alt+del
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 e:\> indicate a ms-dos command. unless otherwise
noted, these commands may be executed from a "command prompt" window in a
modern microsoft windows environment.
e:\> tools\fdimage floppies\kern.flp a:
examples starting with # indicate a command that must be invoked as the
superuser in freebsd. you can login as root to type the command, or login
as your normal account and use su 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
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.
several companies have supported the development of this document by
paying authors to work on it full-time, paying for publication, etc. in
particular, bsdi (subsequently acquired by wind river systems) paid
members of the freebsd documentation project to work on improving this
book full time leading up to the publication of the first printed edition
in march 2000 (isbn 1-57176-241-8). wind river systems then paid several
additional authors to make a number of improvements to the print-output
infrastructure and to add additional chapters to the text. this work
culminated in the publication of the second printed edition in november
2001 (isbn 1-57176-303-1).
i. getting started
this part of the freebsd handbook is for users and administrators who are
new to freebsd. these chapters:
* introduce you to freebsd.
* guide you through the installation process.
* teach you some unix basics.
* show you how to install the wealth of third party applications
available for freebsd.
* 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 of page flipping required.
table of contents
1 introduction
2 installing freebsd
3 unix basics
4 installing applications: packages and ports
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 freebsd! the following chapter covers
various items about the freebsd project, such as its history, goals,
development model, and so on.
after reading this chapter, you will know:
* how freebsd relates to other computer operating systems.
* the history of the freebsd project.
* the goals of the freebsd project.
* the basics of the freebsd open-source development model.
* and of course: where the name "freebsd" comes from.
----------------------------------------------------------------------
1.2 welcome to freebsd!
freebsd is a 4.4bsd-lite based operating system for the intel architecture
(x86) and dec alpha based systems. ports to other architectures are also
underway. for a brief overview of freebsd, see the next section. you can
also read about the history of freebsd, or the current release. if you are
interested in contributing something to the project (code, hardware,
unmarked bills), see the contributing to freebsd article.
----------------------------------------------------------------------
1.2.1 what can freebsd do?
freebsd 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 freebsd 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 freebsd 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.
* freebsd is a 32-bit operating system (64-bit on the alpha) and was
designed as such from the ground up.
* 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 freebsd
ports and 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. freebsd 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!
freebsd is based on the 4.4bsd-lite release from computer systems research
group (csrg) at the university of california at berkeley, and carries on
the distinguished tradition of bsd systems development. in addition to the
fine work provided by csrg, the freebsd 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, freebsd can offer them now!
the applications to which freebsd 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 freebsd too! freebsd also benefits significantly
from the 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 freebsd 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
freebsd:
* internet services: the robust tcp/ip networking built into freebsd
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 freebsd, 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 freebsd 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, freebsd is
an excellent platform for research in operating systems as well as
other branches of computer science. freebsd'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? freebsd can easily turn that
unused 386 or 486 pc sitting in the corner into an advanced router
with sophisticated packet-filtering capabilities.
* x window workstation: freebsd is a fine choice for an inexpensive x
terminal solution, either using the freely available xfree86 server or
one of the excellent commercial servers provided by x inside. unlike
an x terminal, freebsd allows many applications to be run locally, if
desired, thus relieving the burden on a central server. freebsd can
even boot ``diskless'', making individual workstations even cheaper
and easier to administer.
* software development: the basic freebsd system comes with a full
complement of development tools including the renowned gnu c/c++
compiler and debugger.
freebsd is available in both source and binary form on cdrom and via
anonymous ftp. please see appendix a for more information about obtaining
freebsd.
----------------------------------------------------------------------
1.2.2 who uses freebsd?
freebsd is used to power some of the biggest sites on the internet,
including:
* yahoo!
* apache
* be, inc.
* blue mountain arts
* pair networks
* whistle communications
* microsoft
* hotmail
* sony japan
and many more.
----------------------------------------------------------------------
1.3 about the freebsd 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 freebsd
contributed by jordan hubbard.
the freebsd project had its genesis in the early part of 1993, partially
as an outgrowth of the ``unofficial 386bsd patchkit'' by the patchkit's
last 3 coordinators: nate williams, rod grimes and myself.
our original goal was to produce an intermediate snapshot of 386bsd in
order to fix a number of problems with it that the patchkit mechanism just
was not capable of solving. some of you may remember the early working
title for the project being ``386bsd 0.5'' or ``386bsd interim'' in
reference to that fact.
386bsd was bill jolitz's operating system, which had been up to that point
suffering rather severely from almost a year's worth of neglect. as the
patchkit swelled ever more uncomfortably with each passing day, we were in
unanimous agreement that something had to be done and decided to try and
assist bill by providing this interim ``cleanup'' snapshot. those plans
came to a rude halt when bill jolitz suddenly decided to withdraw his
sanction from the project without any clear indication of what would be
done instead.
it did not take us long to decide that the goal remained worthwhile, even
without bill's support, and so we adopted the name ``freebsd'', coined by
david greenman. our initial objectives were set after consulting with the
system's current users and, once it became clear that the project was on
the road to perhaps even becoming a reality, i contacted walnut creek
cdrom with an eye towards improving freebsd's distribution channels for
those many unfortunates without easy access to the internet. walnut creek
cdrom not only supported the idea of distributing freebsd on cd but also
went so far as to provide the project with a machine to work on and a fast
internet connection. without walnut creek cdrom's almost unprecedented
degree of faith in what was, at the time, a completely unknown project, it
is quite unlikely that freebsd would have gotten as far, as fast, as it
has today.
the first cdrom (and general net-wide) distribution was freebsd 1.0,
released in december of 1993. this was based on the 4.3bsd-lite
(``net/2'') tape from u.c. berkeley, with many components also provided by
386bsd and the free software foundation. it was a fairly reasonable
success for a first offering, and we followed it with the highly
successful freebsd 1.1 release in may of 1994.
around this time, some rather unexpected storm clouds formed on the
horizon as novell and u.c. berkeley settled their long-running lawsuit
over the legal status of the berkeley net/2 tape. a condition of that
settlement was u.c. berkeley's concession that large parts of net/2 were
``encumbered'' code and the property of novell, who had in turn acquired
it from at&t some time previously. what berkeley got in return was
novell's ``blessing'' that the 4.4bsd-lite release, when it was finally
released, would be declared unencumbered and all existing net/2 users
would be strongly encouraged to switch. this included freebsd, and the
project was given until the end of july 1994 to stop shipping its own
net/2 based product. under the terms of that agreement, the project was
allowed one last release before the deadline, that release being freebsd
1.1.5.1.
freebsd then set about the arduous task of literally re-inventing itself
from a completely new and rather incomplete set of 4.4bsd-lite bits. the
``lite'' releases were light in part because berkeley's csrg had removed
large chunks of code required for actually constructing a bootable running
system (due to various legal requirements) and the fact that the intel
port of 4.4 was highly incomplete. it took the project until november of
1994 to make this transition, at which point it released freebsd 2.0 to
the net and on cdrom (in late december). despite being still more than a
little rough around the edges, the release was a significant success and
was followed by the more robust and easier to install freebsd 2.0.5
release in june of 1995.
we released freebsd 2.1.5 in august of 1996, and it appeared to be popular
enough among the isp and commercial communities that another release along
the 2.1-stable branch was merited. this was freebsd 2.1.7.1, released in
february 1997 and capping the end of mainstream development on 2.1-stable.
now in maintenance mode, only security enhancements and other critical bug
fixes will be done on this branch (releng_2_1_0).
freebsd 2.2 was branched from the development mainline (``-current'') in
november 1996 as the releng_2_2 branch, and the first full release (2.2.1)
was released in april 1997. further releases along the 2.2 branch were
done in the summer and fall of '97, the last of which (2.2.8) appeared in
november 1998. the first official 3.0 release appeared in october 1998 and
spelled the beginning of the end for the 2.2 branch.
the tree branched again on jan 20, 1999, leading to the 4.0-current and
3.x-stable branches. from 3.x-stable, 3.1 was released on february 15,
1999, 3.2 on may 15, 1999, 3.3 on september 16, 1999, 3.4 on december 20,
1999, and 3.5 on june 24, 2000, which was followed a few days later by a
minor point release update to 3.5.1, to incorporate some last-minute
security fixes to kerberos. this will be the final release in the 3.x
branch.
there was another branch on march 13, 2000, which saw the emergence of the
4.x-stable branch, now considered to be the "current -stable branch".
there have been several releases from it so far: 4.0-release came out in
march 2000, 4.1 was released in july 2000, 4.2 in november 2000, 4.3 in
april 2001, and 4.4 in september 2001. there will be more releases along
the 4.x-stable (releng_4) branch well into 2002.
long-term development projects continue to take place in the 5.0-current
(trunk) branch, and snapshot releases of 5.0 on cdrom (and, of course, on
the net) are continually made available from the snapshot server as work
progresses.
----------------------------------------------------------------------
1.3.2 freebsd project goals
contributed by jordan hubbard.
the goals of the freebsd project are to provide software that may be used
for any purpose and without strings attached. many of us have a
significant investment in the code (and project) and would certainly not
mind a little financial compensation now and then, but we are definitely
not prepared to insist on it. we believe that our first and foremost
``mission'' is to provide code to any and all comers, and for whatever
purpose, so that the code gets the widest possible use and provides the
widest possible benefit. this is, i believe, one of the most fundamental
goals of free software and one that we enthusiastically support.
that code in our source tree which falls under the gnu general public
license (gpl) or library general public license (lgpl) comes with slightly
more strings attached, though at least on the side of enforced access
rather than the usual opposite. due to the additional complexities that
can evolve in the commercial use of gpl software we do, however, prefer
software submitted under the more relaxed bsd copyright when it is a
reasonable option to do so.
----------------------------------------------------------------------
1.3.3 the freebsd development model
contributed by satoshi asami.
the development of freebsd is a very open and flexible process, freebsd
being literally built from the contributions of hundreds of people around
the world, as can be seen from our our list of contributors. we are
constantly on the lookout for new developers and ideas, and those
interested in becoming more closely involved with the project need simply
contact us at the freebsd technical discussions mailing list
<[email protected]>. the freebsd announcements mailing list
<[email protected]> is also available to those wishing to make
other freebsd users aware of major areas of work.
useful things to know about the freebsd project and its development
process, whether working independently or in close cooperation:
the cvs repository
the central source tree for freebsd is maintained by cvs
(concurrent versions system), a freely available source code
control tool that comes bundled with freebsd. the primary cvs
repository resides on a machine in santa clara ca, usa from where
it is replicated to numerous mirror machines throughout the world.
the cvs tree, as well as the -current and -stable trees which are
checked out of it, can be easily replicated to your own machine as
well. please refer to the synchronizing your source tree section
for more information on doing this.
the committers list
the committers are the people who have write access to the cvs
tree, and are thus authorized to make modifications to the freebsd
source (the term ``committer'' comes from the cvs(1) commit
command, which is used to bring new changes into the cvs
repository). the best way of making submissions for review by the
committers list is to use the send-pr(1) command, though if
something appears to be jammed in the system then you may also
reach them by sending mail to the freebsd committer's mailing list
<[email protected]>.
the freebsd core team
the freebsd core team would be equivalent to the board of
directors if the freebsd project were a company. the primary task
of the core team is to make sure the project, as a whole, is in
good shape and is heading in the right directions. inviting
dedicated and responsible developers to join our group of
committers is one of the functions of the core team, as is the
recruitment of new core team members as others move on. the
current core team was elected from a pool of committer candidates
in october 2000. elections are held every 2 years.
some core team members also have specific areas of responsibility,
meaning that they are committed to ensuring that some large
portion of the system works as advertised. for a complete list of
freebsd developers and their areas of responsibility, please see
the contributors list
note: most members of the core team are volunteers when it comes
to freebsd development and do not benefit from the project
financially, so ``commitment'' should also not be misconstrued
as meaning ``guaranteed support.'' the ``board of directors''
analogy above is not actually very accurate, and it may be more
suitable to say that these are the people who gave up their
lives in favor of freebsd against their better judgment!
outside contributors
last, but definitely not least, the largest group of developers
are the users themselves who provide feedback and bug fixes to us
on an almost constant basis. the primary way of keeping in touch
with freebsd's more non-centralized development is to subscribe to
the freebsd technical discussions mailing list
<[email protected]> (see mailing list info) where such
things are discussed.
the freebsd contributors list is a long and growing one, so why
not join it by contributing something back to freebsd today?
providing code is not the only way of contributing to the project;
for a more complete list of things that need doing, please refer
to the freebsd project web site.
in summary, our development model is organized as a loose set of
concentric circles. the centralized model is designed for the convenience
of the users of freebsd, who are thereby provided with an easy way of
tracking one central code base, not to keep potential contributors out!
our desire is to present a stable operating system with a large set of
coherent application programs that the users can easily install and use,
and this model works very well in accomplishing that.
all we ask of those who would join us as freebsd developers is some of the
same dedication its current people have to its continued success!
----------------------------------------------------------------------
1.3.4 the current freebsd release
freebsd is a freely available, full source 4.4bsd-lite based release for
intel i386, i486, pentium, pentium pro, celeron, pentium ii, pentium iii
(or compatible) and dec alpha based computer systems. it is based
primarily on software from u.c. berkeley's csrg group, with some
enhancements from netbsd, openbsd, 386bsd, and the free software
foundation.
since our release of freebsd 2.0 in late 94, the performance, feature set,
and stability of freebsd has improved dramatically. the largest change is
a revamped virtual memory system with a merged vm/file buffer cache that
not only increases performance, but also reduces freebsd's memory
footprint, making a 5mb configuration a more acceptable minimum. other
enhancements include full nis client and server support, transaction tcp
support, dial-on-demand ppp, integrated dhcp support, an improved scsi
subsystem, isdn support, support for atm, fddi, fast and gigabit ethernet
(1000mbit) adapters, improved support for the latest adaptec controllers,
and many hundreds of bug fixes.
we have also taken the comments and suggestions of many of our users to
heart and have attempted to provide what we hope is a more sane and easily
understood installation process. your feedback on this (constantly
evolving) process is especially welcome!
in addition to the base distributions, freebsd offers a ported software
collection with thousands of commonly sought-after programs. at the time
of this printing, there were over 6,600 ports! the list of ports ranges
from http (www) servers, to games, languages, editors, and almost
everything in between. the entire ports collection requires approximately
100mb of storage, all ports being expressed as ``deltas'' to their
original sources. this makes it much easier for us to update ports, and
greatly reduces the disk space demands made by the older 1.0 ports
collection. to compile a port, you simply change to the directory of the
program you wish to install, type make install, and let the system do the
rest. the full original distribution for each port you build is retrieved
dynamically off the cdrom or a local ftp site, so you need only enough
disk space to build the ports you want. almost every port is also provided
as a pre-compiled ``package'', which can be installed with a simple
command (pkg_add) by those who do not wish to compile their own ports from
source.
a number of additional documents which you may find very helpful in the
process of installing and using freebsd may now also be found in the
/usr/share/doc directory on any machine running freebsd 2.1 or later. you
may view the locally installed manuals with any html capable browser using
the following urls:
the freebsd handbook
/usr/share/doc/handbook/index.html
the freebsd faq
/usr/share/doc/faq/index.html
you can also view the master (and most frequently updated) copies at
http://www.freebsd.org/.
----------------------------------------------------------------------
chapter 2 installing freebsd
restructured, reorganized, and parts rewritten by jim mock. the sysinstall
walkthrough, screenshots, and general copy by randy pratt.
2.1 synopsis
freebsd is provided with a text-based, easy to use installation program
called sysinstall. this is the default installation program for freebsd,
although vendors are free to provide their own installation suite if they
wish. this chapter describes how to use sysinstall to install freebsd.
after reading this chapter, you will know:
* how to create the freebsd installation disks.
* how freebsd refers to, and subdivides, your hard disks.
* how to start sysinstall.
* the questions sysinstall will ask you, what they mean, and how to
answer them.
before reading this chapter, you should:
* read the supported hardware list that shipped with the version of
freebsd you are installing, and verify that your hardware is
supported.
note: in general, these installation instructions are written for i386
(``pc compatible'') architecture computers. where applicable,
instructions specific to other platforms (for example, alpha) will be
listed.
----------------------------------------------------------------------
2.2 pre-installation tasks
2.2.1 inventory your computer
before installing freebsd you should attempt to inventory the components
in your computer. the freebsd installation routines will show you the
components (hard disks, network cards, cdrom drives, and so forth) with
their model number and manufacturer. freebsd will also attempt to
determine the correct configuration for these devices, which includes
information about irq and io port usage. due to the vagaries of pc
hardware this process is not always completely successful, and you may
need to correct freebsd's determination of your configuration.
if you already have another operating system installed, such as windows or
linux, it is a good idea to use the facilities provided by those operating
systems to see how your hardware is already configured. if you are really
not sure what settings an expansion card is using, you may find it printed
on the card itself. popular irq numbers are 3, 5, and 7, and io port
addresses are normally written as hexadecimal numbers, such as 0x330.
we recommend you print or write down this information before installing
freebsd. it may help to use a table, like this:
table 2-1. sample device inventory
device name irq io port(s) notes
first hard disk n/a n/a 4gb, made by seagate, first ide master
cdrom n/a n/a first ide slave
second hard disk n/a n/a 2gb, made by ibm, second ide master
first ide controller 14 0x1f0
network card n/a n/a intel 10/100
modem n/a n/a 3com 56k faxmodem, on com1
...
----------------------------------------------------------------------
2.2.2 backup your data
if the computer you will be installing freebsd on contains valuable data
then ensure you have it backed up, and that you have tested the backups
before installing freebsd. the freebsd installation routine will prompt
you several times before writing any data to your disk, but once that
process has started it cannot be undone.
----------------------------------------------------------------------
2.2.3 decide where to install freebsd
if you want freebsd to use all your disk, then there is nothing more to
concern yourself with at this point -- you can skip to the next section.
however, if you need freebsd to co-exist with other operating systems then
you need to have a rough understanding of how data is laid out on the
disk, and how this affects you.
----------------------------------------------------------------------
2.2.3.1 disk layouts for the i386
a pc disk can be divided in to discrete chunks. these chunks are called
partitions. by design, the pc only supports four partitions per disk.
these partitions are called primary partitions. to work around this
limitation and allow more than four partitions, a new partition type was
created, the extended partition. a disk may contain only one extended
partition. special partitions, called logical partitions, can be created
inside this extended partition.
each partition has a partition id, which is a number used to identify the
type of data on the partition. freebsd partitions have the partition id
165.
in general, each operating system that you use will identify partitions in
a particular way. for example, dos, and its descendants, like windows,
assign each primary and logical partition a drive letter, starting with
c:.
freebsd must be installed into a primary partition. freebsd can keep all
its data, including any files that you create, on this one partition.
however, if you have multiple disks, then you can create a freebsd
partition on all, or some, of them. when you install freebsd, you must
have one partition available. this might be a blank partition that you
have prepared, or it might be an existing partition that contains data
that you no longer care about.
if you are already using all the partitions on all your disks, then you
will have to free one of them for freebsd using the tools provided by the
other operating systems you use (e.g., fdisk on dos or windows).
if you have a spare partition then you can use that. however, you may need
to shrink one or more of your existing partitions first.
a minimal installation of freebsd takes as little as 100mb of disk space.
however, that is a very minimal install, leaving almost no space for your
own files. a more realistic minimum is 250mb without a graphical
environment, and 350mb or more if you want a graphical user interface. if
you intend to install a lot of third party software as well, then you will
need more space.
you can use a commercial tool such as partition magic to resize your
partitions to make space for freebsd. the tools directory on the cdrom
contains two free software tools which can carry out this task, fips and
presizer. documentation for both of these is in the same directory.
warning: incorrect use of these tools can delete the data on your disk.
be sure that you have recent, working backups before using them.
example 2-1. using an existing partition unchanged
suppose that you have a computer with a single 4gb disk that already has a
version of windows installed, and you have split the disk in to two drive
letters, c: and d:, each of which is 2gb in size. you have 1gb of data on
c:, and 0.5gb of data on d:.
this means that your disk has two partitions on it, one per drive letter.
you can copy all your existing data from d: to c:, which will free up the
second partition, ready for freebsd.
example 2-2. shrinking an existing partition
suppose that you have a computer with a single 4gb disk, that already has
a version of windows installed. when you installed windows you created one
large partition, giving you a c: drive that is 4gb in size. you are
currently using 1.5gb of space, and want freebsd to have 2gb of space.
in order to install freebsd you will need to either:
#1. backup your windows data, and then reinstall windows, asking for a 2gb
partition at install time.
#2. use one of the tools such as partition magic, described above, to
shrink your windows partition.
----------------------------------------------------------------------
2.2.3.2 disk layouts for the alpha
you will need a dedicated disk for freebsd on the alpha. it is not
possible to share a disk with another operating system at this time.
depending on the specific alpha machine you have, this disk can either be
a scsi disk or an ide disk, as long as your machine is capable of booting
from it.
following the conventions of the digital / compaq manuals all srm input is
shown in uppercase. srm is case insensitive.
to find the names and types of disks in your machine, use the show device
command from the srm console prompt:
>>>show device
dka0.0.0.4.0 dka0 toshiba cd-rom xm-57 3476
dkc0.0.0.1009.0 dkc0 rz1bb-bs 0658
dkc100.1.0.1009.0 dkc100 seagate st34501w 0015
dva0.0.0.0.1 dva0
ewa0.0.0.3.0 ewa0 00-00-f8-75-6d-01
pkc0.7.0.1009.0 pkc0 scsi bus id 7 5.27
pqa0.0.0.4.0 pqa0 pci eide
pqb0.0.1.4.0 pqb0 pci eide
this example is from a digital personal workstation 433au and shows three
disks attached to the machine. the first is a cdrom drive called dka0 and
the other two are disks and are called dkc0 and dkc100 respectively.
disks with names of the form dkx are scsi disks. for example dka100 refers
to a scsi with scsi target id 1 on the first scsi bus (a), whereas dkc300
refers to a scsi disk with scsi id 3 on the third scsi bus (c). devicename
pkx refers to the scsi host bus adapter. as seen in the show device output
scsi cdrom drives are treated as any other scsi hard disk drive.
ide disks have names similar to dqx, while pqx is the associated ide
controller.
----------------------------------------------------------------------
2.2.4 collect your network configuration details
if you intend to connect to a network as part of your freebsd installation
(for example, if you will be installing from an ftp site, or an nfs
server), then you need to know your network configuration. you will be
prompted for this information during the installation so that freebsd can
connect to the network to complete the install.
----------------------------------------------------------------------
2.2.4.1 connecting to an ethernet network, or cable/dsl modem
if you connect to an ethernet network, or you have an internet connection
via cable or dsl, then you will need the following information:
#1. ip address.
#2. ip address of the default gateway.
#3. hostname.
#4. dns server ip addresses.
if you do not know this information, then ask your system administrator or
service provider. they may say that this information is assigned
automatically, using dhcp. if so, make a note of this.
----------------------------------------------------------------------
2.2.4.2 connecting using a modem
if you dial up to an isp using a regular modem then you can still install
freebsd over the internet, it will just take a very long time.
you will need to know:
#1. the phone number to dial for your isp.
#2. the com: port your modem is connected to.
#3. the username and password for your isp account.
----------------------------------------------------------------------
2.2.5 check for freebsd errata
although the freebsd project strives to ensure that each release of
freebsd is as stable as possible, bugs do occasionally creep in to the
process. on very rare occasions those bugs affect the installation
process. as these problems are discovered and fixed they are noted in the
freebsd errata, posted on the freebsd web site. you should check the
errata before installing to make sure that there are no late-breaking
problems which you should be aware of.
information about all the releases, including the errata for each release,
can be found on the release information section of the freebsd web site.
----------------------------------------------------------------------
2.2.6 prepare the boot discs
freebsd can be installed from a number of different media; cdrom, dvd, ftp
(both anonymous and non-anonymous), nfs, tape, or an existing ms-dos
partition.
tip: if you have freebsd on cdrom or dvd, and your computer allows you
to boot from the cdrom or dvd (typically a bios option called ``boot
order'' or similar) then you can skip this section. the freebsd cdrom
and dvd images are bootable and can be used to install freebsd without
any other special preparation.
the freebsd installation process is started by booting your computer into
the freebsd installer--it is not a program you run within another
operating system. to do this, you must create some floppy disks that can
be booted from, and then boot from them.
if you are not installing directly from cdrom, dvd, or ftp then you are
probably preparing your own installation media (e.g., an ms-dos
partition), which must be prepared before you install freebsd. this is a
slightly more advanced, infrequent activity, and is documented in section
2.13. this includes the scenario where you want to create your own ftp
site on your own network so that other computers can use your site as a
freebsd ftp installation site.
in general, to create boot floppy images, follow these steps:
#1. acquire the boot floppy images
the boot discs are available on your installation media in the
floppies directory, and can also be downloaded from the floppies
directory.
the floppy images have a .flp extension. the floppies/ directory
contains a number of different images, and the ones you will need to
use depends on the version of freebsd you are installing, and in some
cases, the hardware you are installing to. in most cases you will need
two files, kern.flp and mfsroot.flp, but check readme.txt in the same
directory to be sure.
important: your ftp program must use binary mode to download these
disk images. some web browsers have been known to use text (or
ascii) mode, which will be apparent if you cannot boot from the
disks.
#2. prepare the floppy disks
you must prepare one floppy disk per image file you had to download.
it is imperative that these disks are free from defects. the easiest
way to test this is to format the disks for yourself. do not trust
pre-formatted floppies.
important: if you try to install freebsd and the installation
program crashes, freezes, or otherwise misbehaves, one of the first
things to suspect is the floppies. try writing the floppy image
files to some other disks and try again.
#3. write the image files to the floppy disks.
the .flp files are not regular files you copy to the disk. instead,
they are images of the complete contents of the disk. this means that
you cannot use commands like dos' copy to write the files. instead,
you must use specific tools to write the images directly to the disk.
if you are creating the floppies on a computer running dos/windows,
then we provide a tool to do this called fdimage.
if you are using the floppies from the cdrom, and your cdrom is the e:
drive, then you would run this:
e:\> tools\fdimage floppies\kern.flp a:
repeat this command for each .flp file, replacing the floppy disk each
time, being sure to label the disks with the name of the file that you
copied to them. adjust the command line as necessary, depending on
where you have placed the .flp files. if you do not have the cdrom,
then fdimage can be downloaded from the tools directory on the freebsd
ftp site.
if you are writing the floppies on a unix system (such as another
freebsd system) you can use the dd(1) command to write the image files
directly to disk. on freebsd, you would run:
# dd if=kern.flp of=/dev/fd0
on freebsd, /dev/fd0 refers to the first floppy disk (the a: drive).
/dev/fd1 would be the b: drive, and so on. other unix variants might
have different names for the floppy disk devices, and you will need to
check the documentation for the system as necessary.
you are now ready to start installing freebsd.
----------------------------------------------------------------------
2.3 starting the installation
important: by default, the installation will not make any changes to
your disk(s) until you see the following message.
last chance: are you sure your want continue the installation?
if you're running this on a disk with data you wish to save then we
strongly encourage you to make proper backups before proceeding!
we can take no responsibility for lost disk contents!
the install can be exited at any time prior to the final warning without
changing the contents of the hard drive. if you are concerned that you
have configured something incorrectly you can just turn the computer off
before this point, and no damage will be done.
----------------------------------------------------------------------
2.3.1 booting
2.3.1.1 booting for the i386
#1. start with your computer turned off.
#2. turn on the computer. as it starts it should display an option to
enter the system set up menu, or bios, commonly reached by keys like
f2, f10, del, or alt+s. use whichever keystroke is indicated on
screen. in some cases your computer may display a graphic while it
starts. typically, pressing esc will dismiss the graphic and allow you
to see the necessary messages.
#3. find the setting that controls which devices the system boots from.
this is commonly shown as a list of devices, such as floppy, cdrom,
first hard disk, and so on.
if you needed to prepare boot floppies, then make sure that the floppy
disk is selected. if you are booting from the cdrom then make sure
that that is selected instead. in case of doubt, you should consult
the manual that came with your computer, and/or its motherboard.
make the change, then save and exit. the computer should now restart.
#4. if you needed to prepare boot floppies, as described in section 2.2.6
then one of them will be the first boot disc, probably the one
containing kern.flp. put this disc in your floppy drive.
if you are booting from cdrom, then you will need to turn on the
computer, and insert the cdrom at the first opportunity.
if your computer starts up as normal, and loads your existing
operating system then either:
#1. the disks were not inserted early enough in the boot process.
leave them in, and try restarting your computer.
#2. the bios changes earlier did not work correctly. you should redo
that step until you get the right option.
#5. freebsd will start to boot. if you are booting from cdrom you will see
a display similar to this:
verifying dmi pool data ........
boot from atapi cd-rom :
1. fd 2.88mb system type-(00)
uncompressing ... done
btx loader 1.00 btx version is 1.01
console: internal video/keyboard
bios drive a: is disk0
bios drive b: is disk1
bios drive c: is disk2
bios drive c: is disk3
bios 639kb/261120kb available memory
freebsd/i386 bootstrap loader, revision 0.8
([email protected], thu jan 17 19:28:57 pst 2002)
/kernel text=0x266691 data=0x407c+0x20d68 \
|
hit [enter] to boot immediately, or any other key for command prompt.
booting [kernel] in 9 seconds... _
if you are booting from floppy disc, you will see a display similar to
this:
verifying dmi pool data ........
btx loader 1.00 btx version is 1.01
console: internal video/keyboard
bios drive a: is disk0
bios drive c: is disk1
bios 639kb/261120kb available memory
freebsd/i386 bootstrap loader, revision 0.8
([email protected], thu jan 17 19:28:57 pst 2002)
/kernel text=0x266691 data=0x407c+0x20d68 |
please insert mfs root floppy and press enter:
follow these instructions by removing the kern.flp disc, insert the
mfsroot.flp disc, and press enter.
#6. irrespective of whether you booted from floppy or cdrom, the boot
process will then get to this point.
hit [enter] to boot immediately, or any other key for command prompt.
booting [kernel] in 9 seconds... _
either wait ten seconds, or press enter. this will then launch the
kernel configuration menu.
----------------------------------------------------------------------
2.3.1.2 booting for the alpha
#1. start with your computer turned off.
#2. turn on the computer and wait for a boot monitor prompt.
#3. if you needed to prepare boot floppies, as described in section 2.2.6
then one of them will be the first boot disc, probably the one
containing kern.flp. put this disc in your floppy drive and type the
following command to boot the disk (substituting the name of your
floppy drive if necessary):
>>>boot dva0 -flags '' -file ''
if you are booting from cdrom, insert the cdrom into the drive and
type the following command to start the installation (substituting the
name of the appropriate cdrom drive if necessary):
>>>boot dka0 -flags '' -file ''
#4. freebsd will start to boot. if you are booting from a floppy disc, at
some point you will see the message:
please insert mfs root floppy and press enter:
follow these instructions by removing the kern.flp disc, insert the
mfsroot.flp disc, and press enter.
#5. irrespective of whether you booted from floppy or cdrom, the boot
process will then get to this point.
hit [enter] to boot immediately, or any other key for command prompt.
booting [kernel] in 9 seconds... _
either wait ten seconds, or press enter. this will then launch the
kernel configuration menu.
----------------------------------------------------------------------
2.3.2 kernel configuration
the kernel is the core of the operating system. it is responsible for many
things, including access to all the devices you may have on your system,
such as hard disks, network cards, sound cards, and so on. each piece of
hardware supported by the freebsd kernel has a driver associated with it.
each driver has a two or three letter name, such as sa for the scsi
sequential access driver, or sio for the serial i/o driver (which manages
com ports).
when the kernel starts, each driver checks the system to see whether or
not the hardware it supports exists on your system. if it does, then the
driver configures the hardware and makes it available to the rest of the
kernel.
this checking is commonly referred to as device probing. unfortunately, it
is not always possible to do this in a safe way. some hardware drivers do
not co-exist well together, and probing for one piece of hardware can
sometimes leave another in an inconsistent state. this is a basic
limitation of the design of the pc.
many older devices are called isa devices--as opposed to pci devices. the
isa specification requires each device to have some information hard coded
into it, typically the interrupt request line number (irq) and io port
address that the driver uses. this information is commonly set by using
physical jumpers on the card, or by using a dos based utility.
this was often a source of problems, because it was not possible to have
two devices that shared the same irq or port address.
newer devices follow the pci specification, which does not require this,
as the devices are supposed to cooperate with the bios, and be told which
irq and io port addresses to use.
if you have any isa devices in your computer then freebsd's driver for
that device will need to be configured with the irq and port address that
you have set the card to. this is why carrying out an inventory of your
hardware (see section 2.2.1) can be useful.
unfortunately, the default irqs and memory ports used by some drivers
clash. this is because some isa devices are shipped with irqs or memory
ports that clash. the defaults in freebsd's drivers are deliberately set
to mirror the manufacturer's defaults, so that, out of the box, as many
devices as possible will work.
this is almost never an issue when running freebsd day-to-day. your
computer will not normally contain two pieces of hardware that clash,
because one of them would not work (irrespective of the operating system
you are using).
it becomes an issue when you are installing freebsd for the first time
because the kernel used to carry out the install has to contain as many
drivers as possible, so that many different hardware configurations can be
supported. this means that some of those drivers will have conflicting
configurations. the devices are probed in a strict order, and if you own a
device that is probed late in the process, but conflicted with an earlier
probe, then your hardware might not function or be probed correctly when
you install freebsd.
because of this, the first thing you have the opportunity to do when
installing freebsd is look at the list of drivers that are configured in
to the kernel, and either disable some of them, if you do not own that
device, or confirm (and alter) the driver's configuration if you do own
the device but the defaults are wrong.
this probably sounds much more complicated than it actually is.
figure 2-1 shows the first kernel configuration menu. we recommend that
you choose the start kernel configuration in full-screen visual mode
option, as it presents the easiest interface for the new user.
figure 2-1. kernel configuration menu
the kernel configuration screen (figure 2-2) is then divided into four
sections.
#1. a collapsible list of all the drivers that are currently marked as
``active'', subdivided in to groups such as storage, and network. each
driver is shown as a description, its two three letter driver name,
and the irq and memory port used by that driver. in addition, if an
active driver conflicts with another active driver then conf is shown
next to the driver name. this section also shows the total number of
conflicting drivers that are currently active.
#2. drivers that have been marked inactive. they remain in the kernel, but
they will not probe for their device when the kernel starts. these are
subdivided in to groups in the same way as the active driver list.
#3. more detail about the currently selected driver, including its irq and
memory port address.
#4. information about the keystrokes that are valid at this point in time.
figure 2-2. the kernel device configuration visual interface
at this point there will always be conflicts listed. do not worry about
this, it is to be expected; all the drivers are enabled, and as has
already been explained, some of them will conflict with one another.
you now have to work through the list of drivers, resolving the conflicts.
resolving driver conflicts
#1. press x. this will completely expand the list of drivers, so you can
see all of them. you will need to use the arrow keys to scroll back
and forth through the active driver list.
figure 2-3 shows the result of pressing x.
figure 2-3. expanded driver list
#2. disable all the drivers for devices that you do not have. to disable a
driver, highlight it with the arrow keys and press del. the driver
will be moved to the inactive drivers list.
if you inadvertently disable a device that you need then press tab to
switch to the inactive drivers list, select the driver that you
disabled, and press enter to move it back to the active list.
important: do not disable sc0. this controls the screen, and you
will need this unless you are installing over a serial cable.
important: only disable atkbd0 if you are using a usb keyboard. if
you have a normal keyboard then you must keep atkbd0.
#3. if there are no conflicts listed then you can skip this step.
otherwise, the remaining conflicts need to be examined. if they do not
have the indication of an ``allowed conflict'' in the message area,
then either the irq/address for device probe will need to be changed,
or the irq/address on the hardware will need to be changed.
to change the driver's configuration for irq and io port address,
select the device and press enter. the cursor will move to the third
section of the screen, and you can change the values. you should enter
the values for irq and port address that you discovered when you made
your hardware inventory. press q to finish editing the device's
configuration and return to the active driver list.
if you are not sure what these figures should be then you can try
using -1. some freebsd drivers can safely probe the hardware to
discover what the correct value should be, and a value of -1
configures them to do this.
the procedure for changing the address on the hardware varies from
device to device. for some devices you may need to physically remove
the card from your computer and adjust jumper settings or dip
switches. other cards may have come with a dos floppy that contains
the programs used to reconfigure the card. in any case, you should
refer to the documentation that came with the device. this will
obviously entail restarting your computer, so you will need to boot
back in to the freebsd installation routine when you have reconfigured
the card.
#4. when all the conflicts have been resolved the screen will look similar
to figure 2-4.
figure 2-4. driver configuration with no conflicts
as you can see, the active driver list is now much smaller, with only
drivers for the hardware that actually exists being listed.
you can now save these changes, and move on to the next step of the
install. press q to quit the device configuration interface. this
message will appear.
save these parameters before exiting? ([y]es/[n]o/[c]ancel)
answer y to save the parameters and the probing will start. after
displaying the probe results in white on black text sysinstall will
start and display its main menu (figure 2-5).
figure 2-5. sysinstall main menu
----------------------------------------------------------------------
2.3.3 reviewing the device probe results
the last few hundred lines that have been displayed on screen are stored
and can be reviewed.
to review the buffer, press scroll lock. this turns on scrolling in the
display. you can then use the arrow keys, or pageup and pagedown to view
the results. press scroll lock again to stop scrolling,
do this now, to review the text that scrolled off the screen when the
kernel was carrying out the device probes. you will see text similar to
figure 2-6, although the precise text will differ depending on the devices
that you have in your computer.
figure 2-6. typical device probe results
avail memory = 254611456 (248644k bytes)
preloaded elf kernel "kernel" at 0xc069a000.
preloaded mfs_root "/mfsroot" at 0xc069a084.
md1: malloc disk
npx0: <math processor> on motherboard
npx0: int 16 interface
pcib0: <host to pci bridge> on motherboard
pci0: <pci bus> on pcib0
pcib1: <via 82c598mvp (apollo mvp3) pci-pci (agp bridge> at device 1.0 on
pci0
pci1: <pci bus> on pcib1
pci1: <matrox mga g200 agp graphics accelerator> at 0.0 irq 11
isab0: <via 82c586 pci-isa bridge> at device 7.0 on pci0
isa0: <isa bus> on isab0
atapci0: <via 82c586 ata33 controller> port 0xe000-0xe00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
uhci0: <via 83c572 usb controller> port 0xe400-0xe41f irq 10 at device 7.2 on
pci0
usb0: <via 83c572 usb controller> on uhci0
usb0: usb revision 1.0
uhub0: via uhci root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
chip1: <via 82c586b acpi interface> at device 7.3 on pci0
ed0: <ne2000 pci ethernet (realtek 8029)> port 0xe800-0xe81f irq 9 at device
10.0 on pci0
ed0: address 52:54:05:de:73:1b, type ne2000 (16bit)
isa0: too many dependant configs (8)
isa0: unexpected small tag 14
orm0; <option rom> at iomem 0xc0000-0xc7fff on isa0
fdc0: <nec 72065b or clone> at port 0x3f0-0x3f5,0x3f7 irq6 drq2 on isa0
fdc0: fifo enabled, 8 bytes threshold
fd0: <1440-kb 3.5" drive> on fdc0 drive 0
atkbdc0: <keyboard controller (i8042)> at port 0x60-0x64 on isa0
atkbd0: <at keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <ps/2 mouse> irq 12 on atkbdc0
psm0: model generic ps/2 mouse, device id 0
vga0: <generic isa vga> at port 0x3c0-0c3df iomem 0xa0000-0xbffff on isa0
sc0: <system console> at flags 0x100 on isa0
sc0: vga <16 virtual consoles, flags-0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550a
sio1: at port 0x2f8-0x2ff irq3 on isa0
sio1: type 16550a
ppc0: <parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: smc-like chipset (ecp/epp/ps2/nibble) in compatible mode
ppc0: fifo with 16/16/15 bytes threshold
ppbus0: ieee1284 device found /nibble
probing for pnp devices on ppbus0:
ppi0: <parallel i/o> on ppbus0
plip0: <plip network interface> on ppbus0
ad0: 8063mb <ibm-dhea-38451> [16383/16/63] at ata0-master using udma33
acd0: cdrom <delta otc-h101/st3 f/w by oipd> at ata0-slave using pio4
mounting root from ufs:/dev/md0c
/stand/sysinstall running as init on vty0
check the probe results carefully to make sure that freebsd found all the
devices you expected. if a device was not found, then it will not be
listed. if the device's driver required configuring with the irq and port
address then you should check that you entered them correctly.
if you need to make changes to the userconfig device probing, its easy to
exit the sysinstall program and start over again. its also a good way to
become more familiar with the process.
figure 2-7. select sysinstall exit
use the arrow keys to select exit install from the main install screen
menu. the following message will display:
user confirmation requested
are you sure you wish to exit? the system will reboot
(be sure to remove any floppies from the drives).
[ yes ] no
the install program will start again if the cdrom is left in the drive and
[yes] is selected.
if you are booting from floppies it will be necessary to remove the
mfs.root floppy and replace it with kern.flp before rebooting.
----------------------------------------------------------------------
2.4 introducing sysinstall
sysinstall is the installation application provided by the freebsd
project. it is console based and is divided into a number of menus and
screens that you can use to configure and control the installation
process.
the sysinstall menu system is controlled by the arrow keys, enter, space.
and other keys. a detailed description of these keys, and what they do, is
contained in sysinstall's usage information.
to review this information, ensure that the usage entry is highlighted and
that the [select] button is selected, as shown in figure 2-8, then press
enter.
the instructions for using the menu system will be displayed. after
reviewing them, press enter to return to the main menu.
figure 2-8. selecting usage from sysinstall main menu
----------------------------------------------------------------------
2.4.1 selecting the documentation menu
from the main menu, select doc with the arrow keys and press enter.
figure 2-9. selecting documentation menu
this will display the documentation menu.
figure 2-10. sysinstall documentation menu
it is important to read the documents provided.
to view a document, select it with the arrow keys and press enter. when
finished reading a document, pressing enter will return to the
documentation menu.
to return to the main installation menu, select exit with the arrow keys
and press enter.
----------------------------------------------------------------------
2.4.2 selecting the keymap menu
to change the keyboard mapping, use the arrow keys to select keymap from
the menu and press enter
figure 2-11. sysinstall main menu
a different keyboard mapping may be chosen by selecting the menu item
using up/down arrow keys and pressing space. pressing space again will
unselect the item. when finished, choose the [ ok ] using the arrow keys
and press enter.
only a partial list is shown in this screen representation. selecting
[ cancel ] will use the default keymap and return to the main install
menu.
figure 2-12. sysinstall keymap menu
----------------------------------------------------------------------
2.4.3 installation options screen
select options and press enter
figure 2-13. sysinstall main menu
figure 2-14. sysinstall options
the default values are usually fine for most users and do not need to be
changed.
the description of the selected item will appear at the bottom of the
screen highlighted in blue. notice that one of the options is use defaults
to reset all values to startup defaults.
press f1 to read the help screen about the various options.
pressing q will return to the main install menu.
----------------------------------------------------------------------
2.4.4 begin a standard installation
the standard installation is the option recommended for those new to unix
or freebsd. use the arrow keys to select standard and then press enter to
start the installation.
figure 2-15. begin standard installation
----------------------------------------------------------------------
2.5 allocating disk space
your first task is to allocate disk space for freebsd, and label that
space so that sysinstall can prepare it. in order to do this you need to
know how freebsd expects to find information on the disk.
----------------------------------------------------------------------
2.5.1 bios drive numbering
before you install and configure freebsd on your system, there is an
important subject that you should be aware of, especially if you have
multiple hard drives.
in a pc running a bios-dependent operating system such as ms-dos or
microsoft windows, the bios is able to abstract the normal disk drive
order, and the operating system goes along with the change. this allows
the user to boot from a disk drive other than the so-called ``primary
master''. this is especially convenient for some users who have found that
the simplest and cheapest way to keep a system backup is to buy an
identical second hard drive, and perform routine copies of the first drive
to the second drive using ghost or xcopy . then, if the first drive fails,
or is attacked by a virus, or is scribbled upon by an operating system
defect, he can easily recover by instructing the bios to logically swap
the drives. it is like switching the cables on the drives, but without
having to open the case.
more expensive systems with scsi controllers often include bios extensions
which allow the scsi drives to be re-ordered in a similar fashion for up
to seven drives.
a user who is accustomed to taking advantage of these features may become
surprised when the results with freebsd are not as expected. freebsd does
not use the bios, and does not know the ``logical bios drive mapping''.
this can lead to very perplexing situations, especially when drives are
physically identical in geometry, and have also been made as data clones
of one another.
when using freebsd, always restore the bios to natural drive numbering
before installing freebsd, and then leave it that way. if you need to
switch drives around, then do so, but do it the hard way, and open the
case and move the jumpers and cables.
+------------------------------------------------------------------------+
| an illustration from the files of bill and fred's exceptional |
| adventures: |
| |
| bill breaks-down an older wintel box to make another freebsd box for |
| fred. bill installs a single scsi drive as scsi unit zero and installs |
| freebsd on it. |
| |
| fred begins using the system, but after several days notices that the |
| older scsi drive is reporting numerous soft errors and reports this |
| fact to bill. |
| |
| after several more days, bill decides it is time to address the |
| situation, so he grabs an identical scsi drive from the disk drive |
| ``archive'' in the back room. an initial surface scan indicates that |
| this drive is functioning well, so bill installs this drive as scsi |
| unit four and makes an image copy from drive zero to drive four. now |
| that the new drive is installed and functioning nicely, bill decides |
| that it is a good idea to start using it, so he uses features in the |
| scsi bios to re-order the disk drives so that the system boots from |
| scsi unit four. freebsd boots and runs just fine. |
| |
| fred continues his work for several days, and soon bill and fred |
| decide that it is time for a new adventure -- time to upgrade to a |
| newer version of freebsd. bill removes scsi unit zero because it was a |
| bit flaky and replaces it with another identical disk drive from the |
| ``archive.'' bill then installs the new version of freebsd onto the |
| new scsi unit zero using fred's magic internet ftp floppies. the |
| installation goes well. |
| |
| fred uses the new version of freebsd for a few days, and certifies |
| that it is good enough for use in the engineering department...it is |
| time to copy all of his work from the old version. so fred mounts scsi |
| unit four (the latest copy of the older freebsd version). fred is |
| dismayed to find that none of his precious work is present on scsi |
| unit four. |
| |
| where did the data go? |
| |
| when bill made an image copy of the original scsi unit zero onto scsi |
| unit four, unit four became the ``new clone,'' when bill re-ordered |
| the scsi bios so that he could boot from scsi unit four, he was only |
| fooling himself. freebsd was still running on scsi unit zero. making |
| this kind of bios change will cause some or all of the boot and loader |
| code to be fetched from the selected bios drive, but when the freebsd |
| kernel drivers take-over, the bios drive numbering will be ignored, |
| and freebsd will transition back to normal drive numbering. in the |
| illustration at hand, the system continued to operate on the original |
| scsi unit zero, and all of fred's data was there, not on scsi unit |
| four. the fact that the system appeared to be running on scsi unit |
| four was simply an artifact of human expectations. |
| |
| we are delighted to mention that no data bytes were killed or harmed |
| in any way by our discovery of this phenomenon. the older scsi unit |
| zero was retrieved from the bone pile, and all of fred's work was |
| returned to him, (and now bill knows that he can count as high as |
| zero). |
| |
| although scsi drives were used in this illustration, the concepts |
| apply equally to ide drives. |
+------------------------------------------------------------------------+
----------------------------------------------------------------------
2.5.2 disk organization
the smallest unit of organization that freebsd uses to find files is the
filename. filenames are case-sensitive, which means that readme.txt and
readme.txt are two separate files. freebsd does not use the extension
(.txt) of a file to determine whether the file is 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 filesystem. each filesystem contains
exactly one directory at the very top level, called the root directory for
that filesystem. 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, dos uses \ to separate
file and directory names, while macos uses :.
freebsd does not use drive letters, or other drive names in the path. you
would not write c:/foo/bar/readme.txt on freebsd.
instead, one filesystem is designated the root filesystem. the root
filesystem's root directory is referred to as /. every other filesystem is
then mounted under the root filesystem. no matter how many disks you have
on your freebsd system, every directory appears to be part of the same
disk.
suppose you have three filesystems, called a, b, and c. each filesystem
has one root directory, which contains two other directories, called a1,
a2 (and likewise b1, b2 and c1, c2).
call a the root filesystem. 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 filesystem must be mounted on to a directory in another filesystem. so
now suppose that you mount filesystem 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.
filesystems can be mounted on top of one another. continuing the last
example, the c filesystem could be mounted on top of the b1 directory in
the b filesystem, leading to this arrangement.
/
|
+--- a1
|
`--- a2
|
+--- b1
| |
| +--- c1
| |
| `--- c2
|
`--- b2
or c could be mounted directly on to the a filesystem, under the a1
directory.
/
|
+--- a1
| |
| +--- c1
| |
| `--- c2
|
`--- a2
|
+--- b1
|
`--- b2
if you are familiar with 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 filesystems when installing freebsd 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 filesystem, and not need to
create any others. there are some drawbacks to this approach, and one
advantage.
benefits of multiple filesystems
* different filesystems can have different mount options. for example,
with careful planning, the root filesystem can be mounted read-only,
making it impossible for you to inadvertently delete or edit a
critical file.
* freebsd automatically optimizes the layout of files on a filesystem,
depending on how the filesystem is being used. so a filesystem 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 filesystem this optimization breaks down.
* freebsd's filesystems are very robust should you lose power. however,
a power loss at a critical point could still damage the structure of
the filesystem. by splitting your data over multiple filesystems 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 filesystem
* filesystems are a fixed size. if you create a filesystem when you
install freebsd and give it a specific size, you may later discover
that you need to make the partition bigger. this is not easily
accomplished without backing up, recreating the filesystems with the
size, and then restoring.
important: freebsd 4.4 and up have a featured command, the
growfs(8), which will makes it possible to increase the size of a
filesystem on the fly, removing this limitation.
filesystems are contained in partitions. this does not have the same
meaning as the earlier usage of the term partition in this chapter,
because of freebsd's unix heritage. each partition is identified by a
letter, a through to h. each partition can only contain one filesystem,
which means that filesystems are often described by either their typical
mount point on the root filesystem, or the letter of the partition they
are contained in.
freebsd also uses disk space for swap space. swap space provides freebsd
with virtual memory. this allows your computer to behave as though it has
much more memory than it actually does. when freebsd 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 filesystem
b normally contains swap space
c normally the same size as the enclosing slice. this allows
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 filesystem on this partition.
d partition d used to have a special meaning associated with it,
although that is now gone. to this day, some tools may operate
oddly if told to work on partition d, so sysinstall will not
normally create partition d.
each partition-that-contains-a-filesystem is stored in what freebsd calls
a slice. slice is freebsd's term for what were earlier called partitions,
and again, this is because of freebsd'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 a
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 2-2.
when referring to a partition freebsd 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 2-3.
example 2-4 shows a conceptual model of the disk layout that should help
make things clearer.
in order to install freebsd you must first configure the disk slices, then
create partitions within the slice you will use for freebsd, and then
create a filesystem (or swap space) in each partition, and decide where
that filesystem will be mounted.
table 2-2. 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 2-3. 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 2-4. conceptual model of a disk
this diagram shows freebsd's view of the first ide disk attached to the
system. assume that the disk is 4gb in size, and contains two 2gb slices
(dos partitions). the first slice contains a dos disk, c:, and the second
slice contains a freebsd installation. this example freebsd installation
has three partitions, and a swap partition.
the three partitions will each hold a filesystem. partition a will be used
for the root filesystem, 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 > filesystem, all
| | > referred to as ad0s2e | of freebsd slice,
| | | | ad0s2c
:-----------------: ==: |
| | | |
: : | partition f, used as /usr |
: : > referred to as ad0s2f |
: : | |
| | | |
| | --' |
`-----------------' --'
----------------------------------------------------------------------
2.5.3 creating slices using fdisk
note: no changes you make at this point will be written to the disk. if
you think you have made a mistake and want to start again you can use
the menus to exit sysinstall and try again. if you get confused and can
not see how to exit you can always turn your computer off.
after choosing to begin a standard installation in sysinstall you will be
shown this message.
message
in the next menu, you will need to set up a dos-style ("fdisk")
partitioning scheme for your hard disk. if you simply wish to devote
all disk space to freebsd (overwriting anything else that might be on
the disk(s) selected) then use the (a)ll command to select the default
partitioning scheme followed by a (q)uit. if you wish to allocate only
free space to freebsd, move to a partition marked "unused" and use the
(c)reate command.
[ ok ]
[ press enter to continue ]
press enter as instructed. you will then be shown a list of all the hard
drives that the kernel found when it carried out the device probes. figure
2-16 shows an example from a system with two ide disks. they have been
called ad0 and ad2.
figure 2-16. select drive for fdisk
you might be wondering why ad1 is not listed here. why has it been missed?
consider what would happen if you had two ide hard disks, one as the
master on the first ide controller, and one as the master on the second
ide controller. if freebsd numbered these as it found them, as ad0 and ad1
then everything would work.
but if you then added a third disk, as the slave device on the first ide
controller, it would now be ad1, and the previous ad1 would become ad2.
because device names (such as ad1s1a) are used to find filesystems, you
may suddenly discover that some of your filesystems no longer appear
correctly, and you would need to change your freebsd configuration.
to work around this, the kernel can be configured to name ide disks based
on where they are, and not the order in which they were found. with this
scheme the master disk on the second ide controller will always be ad2,
even if there are no ad0 or ad1 devices.
this configuration is the default for the freebsd kernel, which is why
this display shows ad0 and ad2. the machine on which this screenshot was
taken had ide disks on both master channels of the ide controllers, and no
disks on the slave channels.
you should select the disk on which you want to install freebsd, and then
press [ ok ]. fdisk will start, with a display similar to that shown in
figure 2-17.
the fdisk display is broken in to three sections.
the first section, covering the first two lines of the display, shows
details about the currently selected disk, including its freebsd name, the
disk geometry, and the total size of the disk.
the second section shows the slices that are currently on the disk, where
they start and end, how large they are, the name freebsd gives them, and
their description and sub-type. this example shows two small unused
slices, which are artifacts of disk layout schemes on the pc. it also
shows one large fat slice, which almost certainly appears as c: in dos /
windows, and an extended slice, which may contain other drive letters for
dos / windows.
the third section shows the commands that are available in fdisk.
figure 2-17. typical fdisk partitions before editing
what you do now will depend on how you want to slice up your disk.
if you want to use freebsd for the entire disk (which will delete all the
other data on this disk when you confirm that you want sysinstall to
continue later in the installation process) then you can press a, which
corresponds to the use entire disk option. the existing slices will be
removed, and replaced with a small area flagged as unused (again, an
artifact of pc disk layout), and then one large slice for freebsd. if you
do this then you should then select the newly created freebsd slice using
the arrow keys, and press s to mark the slice as being bootable. the
screen will then look very similar to figure 2-18. note the a in the flags
column, which indicates that this slice is active, and will be booted
from.
if you will be deleting an existing slice to make space for freebsd then
you should select the slice using the arrow keys, and then press d. you
can then press c, and be prompted for size of slice you want to create.
enter the appropriate figure and press enter.
if you have already made space for freebsd (perhaps by using a tool such
as partition magic) then you can press c to create a new slice. again, you
will be prompted for the size of slice you would like to create.
figure 2-18. fdisk partition using entire disk
when finished, press q. your changes will be saved in sysinstall, but will
not yet be written to disk.
----------------------------------------------------------------------
2.5.4 install a boot manager
you now have the option to install a boot manager. in general, you should
choose to install the freebsd boot manager if:
* you have more than one drive, and have installed freebsd onto a drive
other than the first one.
* you have installed freebsd alongside another operating system on the
same disk, and you want to choose whether to start freebsd or the
other operating system when you start the computer.
make your choice and press enter.
figure 2-19. sysinstall boot manager menu
the help screen, reached by pressing f1, discusses the problems that can
be encountered when trying to share the hard disk between operating
systems.
----------------------------------------------------------------------
2.5.5 creating slices on another drive
if there is more than one drive, it will return to the select drives
screen after the boot manager selection. if you wish to install freebsd on
to more than one disk, then you can select another disk here and repeat
the slice process using fdisk,
figure 2-20. exit select drive
the tab key toggles between the last drive selected, [ ok ], and
[ cancel ].
press the tab once to toggle to the [ ok ], then press enter to continue
with the installation.
----------------------------------------------------------------------
2.5.6 creating partitions using disklabel
you must now create some partitions inside each slice that you have just
created. remember that each partition is lettered, from a through to h,
and that partitions b, c, and d have conventional meanings that you should
adhere to.
certain applications can benefit from particular partition schemes,
especially if you are laying out partitions across more than one disk.
however, for this, your first freebsd installation, you do not need to
give too much thought to how you partition the disk. it is more important
that you install freebsd and start learning how to use it. you can always
re-install freebsd to change your partition scheme when you are more
familiar with the operating system.
this scheme features four partitions--one for swap space, and three for
filesystems.
table 2-3. partition layout for first disk
partition filesystem size description
a / 100mb this is the root file system. every
other filesystem will be mounted
somewhere under this one. 100mb is a
reasonable size for this filesystem. you
will not be storing too much data on it,
as a regular freebsd install will put
about 40mb of data here. the remaining
space is for temporary data, and also
leaves expansion space if future
versions of freebsd need more space in /
b n/a 2-3 x ram the system's swap space is kept on this
partition. choosing the right amount of
swap space can be a bit of an art. a
good rule of thumb is that your swap
space should be two or three times as
much as the available physical memory
(ram). so if you have you should also
have at least 64mb of swap, so if you
have less than 32mb of ram in your
computer then set the swap amount to
64mb.
if you have more than one disk then
you can put swap space on each disk.
freebsd will then use each disk for
swap, which effectively speeds up the
act of swapping. in this case, calculate
the total amount of swap you need (e.g.,
128mb), and then divide this by the
number of disks you have (e.g., two
disks) to give the amount of swap you
should put on each disk, in this
example, 64mb of swap per disk.
e /var 50mb the /var directory contains variable
length files; log files, and other
administrative files. many of these
files are read-from or written-to
extensively during freebsd's day-to-day
running. putting these files on another
filesystem allows freebsd to optimise
the access of these files without
affecting other files in other
directories that do not have the same
access pattern.
f /usr rest of disk all your other files will typically be
stored in /usr, and its subdirectories.
if you will be installing freebsd on to more than one disk then you must
also create partitions in the other slices that you configured. the
easiest way to do this is to create two partitions on each disk, one for
the swap space, and one for a filesystem.
table 2-4. partition layout for subsequent disks
partition filesystem size description
b n/a see description as already discussed, you can split
swap space across each disk. even
though the a partition is free,
convention dictates that swap space
stays on the b partition.
e /diskn rest of disk the rest of the disk is taken up with
one big partition. this could easily
be put on the a partition, instead of
the e partition. however, convention
says that the a partition on a slice
is reserved for the filesystem that
will be the root (/) filesystem. you
do not have to follow this
convention, but sysinstall does, so
following it yourself makes the
installation slightly cleaner. you
can choose to mount this filesystem
anywhere; this example suggests that
you mount them as directories /diskn,
where n is a number that changes for
each disk. but you can use another
scheme if you prefer.
having chosen your partition layout you can now create it using
sysinstall. you will see this message.
message
now, you need to create bsd partitions inside of the fdisk
partition(s) just created. if you have a reasonable amount of disk
space (200mb or more) and don't have any special requirements, simply
use the (a)uto command to allocate space automatically. if you have
more specific needs or just don't care for the layout chosen by
(a)uto, press f1 for more information on manual layout.
[ ok ]
press enter to start the freebsd partition editor, called disklabel.
figure 2-21 shows the display when you first start disklabel. the display
is divided in to three sections.
the first few lines show the name of the disk you are currently working
on, and the slice that contains the partitions you are creating (at this
point disklabel calls this the partition name rather than slice name).
this display also shows the amount of free space within the slice; that
is, space that was set aside in the slice, but that has not yet been
assigned to a partition.
the middle of the display shows the partitions that have been created, the
name of the filesystem that each partition contains, their size, and some
options pertaining to the creation of the filesystem.
the bottom third of the screen shows the keystrokes that are valid in
disklabel.
figure 2-21. sysinstall disklabel editor
disklabel can automatically create partitions for you and assign them
default sizes. try this now, by pressing a. you will see a display similar
to that shown in figure 2-22. depending on the size of the disk you are
using the defaults may or may not be appropriate. this does not matter, as
you do not have to accept the defaults.
note: beginning with freebsd 4.5, the default partitioning assigns the
/tmp directory its own partition instead of being part of the /
partition. this helps avoid filling the / partition with temporary
files.
figure 2-22. sysinstall disklabel editor with auto defaults
to delete the suggested partitions, and replace them with your own, use
the arrow keys to select the first partition, and press d to delete it.
repeat this to delete all the suggested partitions.
to create the first partition (a, mounted as /), make sure the disk
information at the top of the screen is selected, and press c. a dialog
box will appear prompting you for the size of the new partition (as shown
in figure 2-23). you can enter the size as the number of disk blocks you
want to use, or, more usefully, as a number followed by either m for
megabytes, g for gigabytes, or c for cylinders.
figure 2-23. free space for root partition
the default size shown will create a partition that takes up the rest of
the slice. if you are using the partition sizes described earlier, then
delete the existing figure using backspace, and then type in 64m, as shown
in figure 2-24. then press [ ok ].
figure 2-24. edit root partition size
having chosen the partition's size you will then asked whether this
partition will contain a filesystem or swap space. the dialog box is shown
in figure 2-25. this first partition will contain a filesystem, so check
that fs is selected and then press enter.
figure 2-25. choose the root partition type
finally, because you are creating a filesystem, you must tell disklabel
where the filesystem is to be mounted. the dialog box is shown in figure
2-26. the root filesystem's mount point is /, so type /, and then press
enter.
figure 2-26. choose the root mount point
the display will then update to show you the newly created partition. you
should repeat this procedure for the other partitions. when you create the
swap partition you will not be prompted for the filesystem mount point, as
swap partitions are never mounted. when you create the final partition,
/usr, you can leave the suggested size as is, to use the rest of the
slice.
your final freebsd disklabel editor screen will appear similar to figure
2-27, although your values chosen may be different. press q to finish.
figure 2-27. sysinstall disklabel editor
----------------------------------------------------------------------
2.6 choosing what to install
2.6.1 select the distribution set
deciding which distribution set to install will depend largely on the
intended use of the system and the amount of disk space available. the
predefined options range from installing the smallest possible
configuration to everything. those who are new to unix and/or freebsd
should almost certainly select one of these canned options. customizing a
distribution set is typically for the more experienced user.
press f1 for more information on the distribution set options and what
they contain. when finished reviewing the help, pressing enter will return
to the select distributions menu.
if a graphical user interface is desired then a distribution set that is
preceded by an x should be chosen. the configuration of xfree86 and
selection of a default desktop is part of the post-installation steps.
the default xfree86 version installed is the 3.x branch. you should check
to see whether your video card is supported at the xfree86 web site. if it
is only supported under the 4.x branch, then you will need to install and
configure xfree86 4.x after installation. select a distribution without x
and refer to chapter 5 for more information.
if compiling a custom kernel is anticipated, select an option which
includes the source code. for more information on why a custom kernel
should be built or how to build a custom kernel see chapter 9.
obviously, the most versatile system is one that includes everything. if
there is adequate disk space, select all as shown in figure 2-28 by using
the arrow keys and press enter. if there is a concern about disk space
consider using an option that is more suitable for the situation. other
distributions can be added after installation.
figure 2-28. choose distributions
----------------------------------------------------------------------
2.6.2 installing the ports collection
after selecting the desired distribution, an opportunity to install the
freebsd ports collection is presented. the ports collection is an easy and
convenient way to install software. the ports collection does not contain
the source code necessary to compile the software. it is a collection of
files which automates the downloading, compiling and installation. chapter
4 discusses how to use the ports collection.
the installation program does not check to see if you have adequate space.
select this option only if you have adequate hard disk space.
user confirmation requested
would you like to install the freebsd ports collection?
this will give you ready access to over 6,600 ported software packages,
at a cost of around 100mb of disk space when "clean" and possibly much
more than that if a lot of the distribution tarballs are loaded
(unless you have the extra cds from a freebsd cd/dvd distribution
available and can mount it on /cdrom, in which case this is far less
of a problem).
the ports collection is a very valuable resource and well worth having
on your /usr partition, so it is advisable to say yes to this option.
for more information on the ports collection & the latest ports,
visit:
http://www.freebsd.org/ports
[ yes ] no
select [ yes ] with the arrow keys to install the ports collection or [ no
] to skip this option. press enter to continue. the choose distributions
menu will redisplay.
figure 2-29. confirm distributions
if satisfied with the options, select exit with the arrow keys, ensure
that [ ok ] is highlighted, and press enter to continue.
----------------------------------------------------------------------
2.7 choosing your installation media
if installing from a cdrom, use the arrow keys to highlight install from a
freebsd cd/dvd. ensure that [ ok ] is highlighted, then press enter to
proceed with the installation.
for other methods of installation, select the appropriate option and
follow the instructions.
press f1 to display the online help for installation media. press enter to
return to the media selection menu.
figure 2-30. choose installation media
ftp installation modes: there are three ftp installation modes you can
choose from: active ftp, passive ftp, or via a http proxy.
ftp active, install from an ftp server
this option will make all ftp transfers use ``active'' mode.
this will not work through firewalls, but will often work with
older ftp servers that do not support passive mode. if your
connection hangs with passive mode (the default), try active!
ftp passive, install from an ftp server through a firewall
this option instructs freebsd to use ``passive'' mode for all
ftp operations. this allows the user to pass through firewalls
that do not allow incoming connections on random port addresses.
ftp via a http proxy, install from an ftp server through a http proxy
this option instructs freebsd to use the http protocol (like a
web browser) to connect to a proxy for all ftp operations. the
proxy will translate the requests and send them to the ftp
server. this allows the user to pass through firewalls that do
not allow ftp at all, but offer a http proxy. in this case, you
have to specify the proxy in addition to the ftp server.
for a proxy ftp server, you should usually give the name of the server
you really want as a part of the username, after an ``@'' sign. the
proxy server then ``fakes'' the real server. for example, assuming you
want to install from ftp.freebsd.org, using the proxy ftp server
foo.example.com, listening on port 1024.
in this case, you go to the options menu, set the ftp username to
[email protected], and the password to your email address. as your
installation media, you specify ftp (or passive ftp, if the proxy
supports it), and the url ftp://foo.example.com:1234/pub/freebsd.
since /pub/freebsd from ftp.freebsd.org is proxied under
foo.example.com, you are able to install from that machine (which will
fetch the files from ftp.freebsd.org as your installation requests them.
----------------------------------------------------------------------
2.8 committing to the installation
the installation can now proceed if desired. this is also the last chance
for aborting the installation to prevent changes to the hard drive.
user confirmation requested
last chance! are you sure you want to continue the installation?
if you're running this on a disk with data you wish to save then we
strongly encourage you to make proper backups before proceeding!
we can take no responsibility for lost disk contents!
[ yes ] no
select [ yes ] and press enter to proceed.
the installation time will vary according to the distribution chosen,
installation media used, and the speed of the computer. there will be a
series of messages displayed indicating the status.
the installation is complete when the following message is displayed:
message
congratulations! you now have freebsd installed on your system.
we will now move on to the final configuration questions.
for any option you do not wish to configure, simply select no.
if you wish to re-enter this utility after the system is up, you may
do so by typing: /stand/sysinstall .
[ ok ]
[ press enter to continue ]
press enter to proceed with post-installation configurations.
selecting [ no ] and pressing enter will abort the installation so no
changes will be made to your system. the following message will appear:
message
installation complete with some errors. you may wish to scroll
through the debugging messages on vty1 with the scroll-lock feature.
you can also choose "no" at the next prompt and go back into the
installation menus to try and retry whichever operations have failed.
[ ok ]
this message is generated because nothing was installed. pressing enter
will return to the main installation menu to exit the installation.
----------------------------------------------------------------------
2.9 post-installation
configuration of various options follows the successful installation. an
option can be configured by re-entering the configuration options before
booting the new freebsd system or after installation using
/stand/sysinstall and selecting configure.
----------------------------------------------------------------------
2.9.1 network device configuration
if you previously configured ppp for an ftp install, this screen will not
display and can be configured later as described above.
for detailed information on local area networks and configuring freebsd as
a gateway/router refer to the tutorial ppp - pedantic ppp primer.
user confirmation requested
would you like to configure ethernet or slip/ppp network devices?
[ yes ] no
to configure a network device, select [ yes ] and press enter. otherwise,
select [ no ] to continue.
figure 2-31. selecting an ethernet device
select the interface to be configured with the arrow keys and press enter.
user confirmation requested
do you want to try ipv6 configuration of the interface?
yes [ no ]
in this private local area network the current internet type protocol
(ipv4) was sufficient and [ no ] was selected with the arrow keys and
enter pressed.
if you want to try the new internet protocol (ipv6), choose [ yes ] and
press enter. it will take several seconds to scan for ra servers.
user confirmation requested
do you want to try dhcp configuration of the interface?
yes [ no ]
if dhcp (dynamic host configuration protocol) is not required select [ no
] with the arrow keys and press enter.
selecting [ yes ] will execute dhclient, and if successful, will fill in
the network configuration information automatically. refer to section 17.8
for more information.
the following network configuration screen shows the configuration of the
ethernet device for a system that will act as the gateway for a local area
network.
figure 2-32. set network configuration for ed0
use tab to select the information fields and fill in appropriate
information:
host
the fully-qualified hostname, e.g. k6-2.example.com in this case.
domain
the name of the domain that your machine is in, e.g. example.com
for this case.
ipv4 gateway
ip address of host forwarding packets to non-local destinations.
fill this in only if the machine is a node on the network. leave
this field blank if the machine is the gateway to the internet for
the network.
name server
ip address of your local dns server. there is no local dns server
on this private local area network so the ip address of the
provider's dns server (208.163.10.2) was used.
ipv4 address
the ip address to be used for this interface was (192.168.0.1).
netmask
the address block being used for this local area network is a
class c block (192.168.0.0 - 192.168.255.255). the default netmask
is for a class c network (255.255.255.0).
extra options to ifconfig
any interface-specific options to ifconfig you would like to add.
there were none in this case.
use tab to select [ ok ] when finished and press enter.
user confirmation requested
would you like to bring up the ed0 interface right now?
[ yes ] no
choosing [ yes ] and pressing enter will bring the machine up on the
network and be ready for use after leaving leaving the installation.
----------------------------------------------------------------------
2.9.2 configure gateway
user confirmation requested
do you want this machine to function as a network gateway?
[ yes ] no
if the machine will be acting as the gateway for a local area network and
forwarding packets between other machines then select [ yes ] and press
enter. if the machine is a node on a network then select [ no ] and press
enter to continue.
----------------------------------------------------------------------
2.9.3 configure internet services
user confirmation requested
do you want to configure inetd and the network services that it provides?
yes [ no ]
if [ no ] is selected, various services such telnetd will not be enabled.
this means that remote users will not be able to telnet into this machine.
local users will be still be able to access remote machines with telnet.
these services can be enabled after installation by editing
/etc/inetd.conf with your favorite text editor. see section 17.12.1 for
more information.
select [ yes ] if you wish to configure these services during install. an
additional confirmation will display.
user confirmation requested
the internet super server (inetd) allows a number of simple internet
services to be enabled, including finger, ftp and telnetd. enabling
these services may increase risk of security problems by increasing
the exposure of your system.
with this in mind, do you wish to enable inetd?
[ yes ] no
select [ yes ] to continue.
user confirmation requested
inetd(8) relies on its configuration file, /etc/inetd.conf, to determine
which of its internet services will be available. the default freebsd
inetd.conf(5) leaves all services disabled by default, so they must be
specifically enabled in the configuration file before they will
function, even once inetd(8) is enabled. note that services for
ipv6 must be seperately enabled from ipv4 services.
select [yes] now to invoke an editor on /etc/inetd.conf, or [no] to
use the current settings.
[ yes ] no
selecting [ yes ] will allow adding services by deleting the # at the
beginning of a line.
figure 2-33. editing inetd.conf
after adding the desired services, pressing esc will display a menu which
will allow exiting and saving the changes.
----------------------------------------------------------------------
2.9.4 anonymous ftp
user confirmation requested
do you want to have anonymous ftp access to this machine?
yes [ no ]
----------------------------------------------------------------------
2.9.4.1 deny anonymous ftp
selecting the default [ no ] and pressing enter will still allow users who
have accounts with passwords to use ftp to access the machine.
----------------------------------------------------------------------
2.9.4.2 allow anonymous ftp
anyone can access your machine if you elect to allow anonymous ftp
connections. the security implications should be considered before
enabling this option. for more information about security see chapter 10.
to allow anonymous ftp, use the arrow keys to select [ yes ] and press
enter. the following screens (or similar) will display:
figure 2-34. default anonymous ftp configuration
pressing f1 will display the help:
this screen allows you to configure the anonymous ftp user.
the following configuration values are editable:
uid: the user id you wish to assign to the anonymous ftp user.
all files uploaded will be owned by this id.
group: which group you wish the anonymous ftp user to be in.
comment: string describing this user in /etc/passwd
ftp root directory:
where files available for anonymous ftp will be kept.
upload subdirectory:
where files uploaded by anonymous ftp users will go.
the ftp root directory will be put in /var by default. if you do not have
enough room there for the anticipated ftp needs, the /usr directory could
be used by setting the ftp root directory to /usr/ftp.
when you are satisfied with the values, press enter to continue.
user confirmation requested
create a welcome message file for anonymous ftp users?
[ yes ] no
if you select [ yes ] and press enter, an editor will automatically start
allowing you to edit the message.
figure 2-35. edit the ftp welcome message
this is a text editor called ee. use the instructions to change the
message or change the message later using a text editor of your choice.
note the file name/location at the bottom.
press esc and a pop-up menu will default to a) leave editor. press enter
to exit and continue.
----------------------------------------------------------------------
2.9.5 configure network file services
network file services (nfs) allows sharing of files across a network. a
machine can be configured as a server, a client, or both. refer to section
17.4 for a more information.
----------------------------------------------------------------------
2.9.5.1 nfs server
user confirmation requested
do you want to configure this machine as an nfs server?
yes [ no ]
if there is no need for a network file system server or client, select [
no ] and press enter.
if [ yes ] is chosen, a message will pop-up indicating that the exports
file must be created.
message
operating as an nfs server means that you must first configure an
/etc/exports file to indicate which hosts are allowed certain kinds of
access to your local file systems.
press [enter] now to invoke an editor on /etc/exports
[ ok ]
press enter to continue. a text editor will start allowing the exports
file to be created and edited.
figure 2-36. editing the exports file
use the instructions to add the actual exported filesystems now or later
using a text editor of your choice. note the filename/location at the
bottom of the editor screen.
press esc and a pop-up menu will default to a) leave editor. press enter
to exit and continue.
----------------------------------------------------------------------
2.9.5.2 nfs client
user confirmation requested
do you want to configure this machine as an nfs client?
yes [ no ]
with the arrow keys, select [ yes ] or [ no ] as appropriate and press
enter.
----------------------------------------------------------------------
2.9.6 security profile
a ``security profile'' is a set of configuration options that attempts to
achieve the desired ratio of security to convenience by enabling and
disabling certain programs and other settings. the more severe the
security profile, the fewer programs will be enabled by default. this is
one of the basic principles of security: do not run anything except what
you must.
please note that the security profile is just a default setting. all
programs can be enabled and disabled after you have installed freebsd by
editing or adding the appropriate line(s) to /etc/rc.conf. for more
information, please see the rc.conf(5) manual page.
the following table describes what each of the security profiles does. the
columns are the choices you have for a security profile, and the rows are
the program or feature that the profile enables or disables.
table 2-5. possible security profiles
+------------------------------------------------------------------------+
| | extreme | moderate |
|--------------------------+-----------------------+---------------------|
| sendmail(8) | no | yes |
|--------------------------+-----------------------+---------------------|
| sshd(8) | no | yes |
|--------------------------+-----------------------+---------------------|
| portmap(8) | no | maybe [a] |
|--------------------------+-----------------------+---------------------|
| nfs server | no | yes |
|--------------------------+-----------------------+---------------------|
| securelevel(8) | yes (2) [b] | no |
|------------------------------------------------------------------------|
| notes: |
| a. the portmapper is enabled if the machine has been configured as an |
| nfs client or server earlier in the installation. |
| b. if you choose a security profile that sets the securelevel (extreme |
| or high), you must be aware of the implications. please read the |
| init(8) manual page and pay particular attention to the meanings of |
| the security levels, or you may have significant trouble later! |
+------------------------------------------------------------------------+
user confirmation requested
do you want to select a default security profile for this host (select
no for "medium" security)?
[ yes ] no
selecting [ no ] and pressing enter will set the security profile to
medium.
selecting [ yes ] and pressing enter will allow selecting a different
security profile.
figure 2-37. security profile options
press f1 to display the help. press enter to return to selection menu.
use the arrow keys to choose medium unless your are sure that another
level is required for your needs. with [ ok ] highlighted, press enter.
an appropriate confirmation message will display depending on which
security setting was chosen.
message
moderate security settings have been selected.
sendmail and sshd have been enabled, securelevels are
disabled, and nfs server setting have been left intact.
please note that this still does not save you from having
to properly secure your system in other ways or exercise
due diligence in your administration, this simply picks
a standard set of out-of-box defaults to start with.
to change any of these settings later, edit /etc/rc.conf
[ok]
message
extreme security settings have been selected.
sendmail, sshd, and nfs services have been disabled, and
securelevels have been enabled.
please note that this still does not save you from having
to properly secure your system in other ways or exercise
due diligence in your administration, this simply picks
a more secure set of out-of-box defaults to start with.
to change any of these settings later, edit /etc/rc.conf
[ok]
press enter to continue with the post-installation configuration.
warning: the security profile is not a silver bullet! even if you use
the extreme setting, you need to keep up with security issues by reading
an appropriate mailing list, using good passwords and passphrases, and
generally adhering to good security practices. it simply sets up the
desired security to convenience ratio out of the box.
----------------------------------------------------------------------
2.9.7 system console settings
there are several options available to customize the system console.
user confirmation requested
would you like to customize your system console settings?
[ yes ] no
to view and configure the options, select [ yes ] and press enter.
figure 2-38. system console configuration options
a commonly used option is the screensaver. use the arrow keys to select
saver and then press enter.
figure 2-39. screensaver options
select the desired screen saver using the arrow keys and then press enter.
the system console configuration menu will redisplay.
the default time interval is 300 seconds. to change the time interval,
select saver again. at the screensaver options menu, select timeout using
the arrow keys and press enter. a pop-up menu will appear:
figure 2-40. screensaver timeout
the value can be changed, then select [ ok ] and press enter to return to
the system console configuration menu.
figure 2-41. system console configuration exit
selecting exit and pressing enter will continue with the post-installation
configurations.
----------------------------------------------------------------------
2.9.8 setting the time zone
setting the timezone for your machine will allow it to automatically
correct for any regional time changes and perform other timezone related
functions properly.
the example shown is for a machine located in the eastern time zone of the
united states. your selections will vary according to your geographical
location.
user confirmation requested
would you like to set this machine's time zone now?
[ yes ] no
select [ yes ] and press enter to set the time zone.
user confirmation requested
is this machine's cmos clock set to utc? if it is set to local time
or you don't know, please choose no here!
yes [ no ]
select [ yes ] or [ no ] according to how the machine's clock is
configured and press enter.
figure 2-42. select your region
the appropriate region is selected using the arrow keys and then press
enter.
figure 2-43. select your country
select the appropriate country using the arrow keys and press enter.
figure 2-44. select your timezone
the appropriate time zone is selected using the arrow keys and pressing
enter.
confirmation
does the abbreviation 'edt' look reasonable?
[ yes ] no
confirm the abbreviation for the time zone is correct. if it looks okay,
press enter to continue with the post-installation configuration.
----------------------------------------------------------------------
2.9.9 linux compatibility
user confirmation requested
would you like to enable linux binary compatibility?
[ yes ] no
selecting [ yes ] and pressing enter will allow running linux software on
freebsd. the install will proceed to add the appropriate packages for
linux compatibility.
if installing by ftp, the machine will need to be connected to the
internet. sometimes a remote ftp site will not have all the distributions
like the linux binary compatibility. this can be installed later if
necessary.
----------------------------------------------------------------------
2.9.10 mouse settings
this option will allow you to cut and paste text in the console and user
programs with a 3-button mouse. if using a 2-button mouse, refer to manual
page, moused(8), after installation for details on emulating the 3-button
style. this example depicts a non-usb mouse.
user confirmation requested
does this system have a non-usb mouse attached to it?
[ yes ] no
select [ yes ] for a non-usb mouse or [ no ] for a usb mouse and press
enter.
figure 2-45. select mouse protocol type
use the arrow keys to select type and press enter
figure 2-46. set mouse protocol
the mouse used in this example is a ps/2 type, so the default auto was
appropriate. to change protocol, use the arrow keys to select another
option. ensure that [ ok ] is highlighted and press enter to exit this
menu.
figure 2-47. configure mouse port
use the arrow keys to select port and press enter.
figure 2-48. setting the mouse port
this system had a ps/2 mouse, so the default ps/2 was appropriate. to
change the port, use the arrow keys and then press enter.
figure 2-49. enable the mouse daemon
last, the mouse daemon is enabled and tested.
figure 2-50. test the mouse daemon
the cursor moved around the screen so the mouse daemon is running:
select [ yes ] to return to the previous menu then select exit with the
arrow keys and press enter to return to continue with the
post-installation configuration.
----------------------------------------------------------------------
2.9.11 configure x-server
in order to use a graphical user interface such as kde, gnome, or others,
the x server will need to be configured.
to see whether your video card is supported, check the xfree86 web site.
if your video card is only supported under xfree86 4.x, refer to chapter 5
for installation and configuration.
user confirmation requested
would you like to configure your x server at this time?
[ yes ] no
warning: it is necessary to know your monitor specifications and video
card information. equipment damage can occur if settings are incorrect.
if you do not have this information, select [ no ] and perform the
configuration after installation when you have the information using
/stand/sysinstall, selecting configure and then xfree86.
if you have graphics card and monitor information, select [ yes ] and
press enter to proceed with configuring the x server.
figure 2-51. select configuration method menu
there are several ways to configure the x server. xf86setup is fully
graphical and probably the easiest. use the arrow keys to select the
xf86setup and press enter.
message
you have configured and been running the mouse daemon.
choose "/dev/sysmouse" as the mouse port and "sysmouse" or
"mousesystems" as the mouse protocol in the x configuration utility.
[ ok ]
[ press enter to continue ]
this indicates that the mouse daemon previously configured has been
detected. press enter to continue.
press [enter] to switch to graphics mode.
this may take a while...
[ ok ]
press enter to switch to the graphics mode and continue. it will not try
to switch to the graphics mode until enter is pressed. the screen will go
black and then shortly a screen with a large x in the center will appear.
be patient and wait.
after a few more moments, the xf86setup introduction will display. read
all instructions carefully. press enter to continue.
xf86setup overview
there are several areas of configuration to be completed. the
configuration choices you make will depend on the hardware in the system
so only a general overview can be given here.
along the top of the configuration tool there are buttons indicating the
areas to be configured. you should be able to use the mouse if it was
previously configured and select each item by clicking on it. review each
area and make appropriate selections for your system.
#1. mouse
the mouse is the first item to be configured. if you previously
configured your mouse, the mouse daemon will already be running and
should indicate sysmouse automatically for the mouse protocol. if you
are use a two button mouse, you should also select emulate3buttons.
there are other settings that can be tweaked if necessary.
after completing your selections, click on the apply and check the
mouse actions are working properly. if further adjustment is needed,
make them and recheck the operation by clicking on apply again. when
finished, move on to the next item.
#2. keyboard
select the appropriate keyboard model. the default keyboard is generic
101-key pc.
select the language layout for your keyboard. the default layout is
u.s. english. if you are not using a u.s. keyboard, you may need to
additionally select a variant.
there are other options under group shift/lock behavior and control
key position that can be selected if desired. generally the default
settings are fine.
after completing the keyboard configuration, click on apply and move
on to the next item.
#3. card
click on read readme file for additional help in configuring your
video card.
select the appropriate video card from the list using the scrollbar.
clicking on your card will show as ``card selected:'' above the list
box.
next, the detailed setup was selected just to check details.
typically, if your video card was in the list, no changes will be
needed here.
when finished, move on to the next item.
#4. monitor
there are two ways to proceed. one method requires that you enter the
horizontal and vertical sweep capabilities of your monitor in the text
boxes.
choosing one of the monitor options listed that the monitor is the
other method. after selecting a listed option, the horizontal and
vertical sweep rates that will be used will display. compare those to
your monitor specifications. the monitor must be capable of using
those ranges.
do not exceed the ratings of your monitor. damage could occur. if you
have doubts select abort and get the information. the remainder of the
installation process will be unaffected and configuring the x-server
can be done later using /stand/sysinstall.
when finished, move on to the next item.
#5. mode
select the video mode(s) that you want to use. you can select more
than one option. typically, useful ranges are 640x480, 800x600, and
1024x768 but those are a function of video card capability, monitor
size, and eye comfort.
next, select the default color depth you want to use. your choices are
8bpp, 16bpp, 24bpp, and 32bpp. select the highest color depth that
your video card will support.
when finished, move on to the next item.
#6. other
the default settings are reasonable values, so you probably will not
need to change anything here.
the default setting which allows the server to be killed with the
hotkey sequence ctrl+alt+backspace should be left on. this can be
executed if something is wrong with the server settings and prevent
hardware damage.
the default setting that allows video mode switching will permit
changing of the mode while running x with the hotkey sequence alt++ or
alt+-.
#7. testing the server
verify all the settings once again and select done and the following
message will display:
if you've finished configuring everything press the
okay button to start the x server using the configuration
you've selected. if you still wish to configure some things,
press one of the buttons at the top and then press "done" again,
when you've finished.
after selecting okay, some messages will briefly appear advising to
wait and attempting to start the x-server. this process takes a few
moments, so be patient.
the screen will go blank for a short period of time and then a screen
will appear with the message ``congratulations, you've got a running
server!''
if nothing appears or the display is distorted, kill the x-server
using ctrl+alt+backspace and adjust the settings or revisit them after
installation.
#8. running xvidtune
the display can be adjusted for height, width, or centering by using
xvidtune.
there are warnings that improper settings can damage your equipment.
heed them. if in doubt, do not do it. instead, use the monitor
controls to adjust the display for x-windows. there may be some
display differences when switching back to text mode, but it is better
than damaging equipment. xvidtune can be ran later using
/stand/sysinstall.
read the xvidtune(1) man page before making any adjustments.
#9. saving configuration
when you are satisfied, the configuration can now be saved. select
save the configuration and exit the configuration file will be saved
to /etc/xf86config.
once the configuration is done, the installation program will need to
create a link to the server:
do you want to create an 'x' link to the svga server?
(the link will be created in the directory:
/usr/x11r6/bin) okay?
[ yes ] no
select [ yes ] and press enter to create the link.
link created successfully.
[ ok ]
press enter to continue configuration.
----------------------------------------------------------------------
2.9.12 select default x desktop
there are a variety of window managers available. they range from very
basic environments to full desktop environments with a large suite of
software. some require only minimal disk space and low memory while others
with more features require much more. the best way to determine which is
most suitable for you is to try a few different ones. those are available
from the ports collection or as packages and can be added after
installation.
you can select one of the popular desktops to be installed and configured
as the default desktop. this will allow you to start it right after
installation.
figure 2-52. select default desktop
use the arrow keys to select a desktop and press enter. installation of
the selected desktop will proceed.
----------------------------------------------------------------------
2.9.13 install packages
the packages are pre-compiled binaries and are a convenient way to install
software.
installation of one package is shown for purposes of illustration.
additional packages can also be added at this time if desired. after
installation /stand/sysinstall can be used to add additional packages.
user confirmation requested
the freebsd package collection is a collection of hundreds of
ready-to-run applications, from text editors to games to web servers
and more. would you like to browse the collection now?
[ yes ] no
selecting [ yes ] and pressing enter will be followed by the package
selection screens:
figure 2-53. select package category
all packages available will be displayed if all is selected or you can
select a particular category. highlight your selection with the arrow keys
and press enter.
a menu will display showing all the packages available for the selection
made.
figure 2-54. select packages
the bash shell is shown selected. select as many as desired by
highlighting the package and pressing the space. a short description of
each package will appear in the lower left corner of the screen.
pressing the tab key will toggle between the last selected package,
[ ok ], and [ cancel ].
when you have finished marking the packages for installation, press tab
once to toggle to the [ ok ] and press enter to return to the package
selection menu.
the left and right arrow keys will also toggle between [ ok ] and
[ cancel ]. this method can also be used to select [ ok ] and press enter
to return to the package selection menu.
figure 2-55. install packages
use the arrow keys to select [ install ] and press enter. you will then
need to confirm that you want to install the packages.
figure 2-56. confirm package installation
selecting [ ok ] and pressing enter will start the package installation.
installing messages will appear until completed. make note if there are
any error messages.
the final configuration continues after packages are installed.
----------------------------------------------------------------------
2.9.14 add user/groups
you should add at least one user during the installation so that you can
use the system without being logged in as root. the root partition is
generally small and running applications as root can quickly fill it. a
bigger danger is noted below:
user confirmation requested
would you like to add any initial user accounts to the system? adding
at least one account for yourself at this stage is suggested since
working as the "root" user is dangerous (it is easy to do things which
adversely affect the entire system).
[ yes ] no
select [ yes ] and press enter to continue with adding a user.
figure 2-57. select add user
select add user with the arrow keys and press enter.
figure 2-58. add user information
the following descriptions will appear in the lower part of the screen as
the items are selected with tab to assist with entering the required
information.
login id
the login name of the new user (mandatory)
uid
the numerical id for this user (leave blank for automatic choice)
group
the login group name for this user (leave blank for automatic
choice)
password
the password for this user (enter this field with care!)
full name
the user's full name (comment)
member groups
the groups this user belongs to (i.e. gets access rights for)
home directory
the user's home directory (leave blank for default)
login shell
the user's login shell (leave blank for default). (/bin/sh)
the login shell was changed from /bin/sh to /usr/local/bin/bash to use the
bash shell that was previously installed as a package. do not try to use a
shell that does not exist or you will not be able to login.
the user was also added to the group wheel to be able to become a
superuser with root privileges.
when you are satisfied, press [ ok ] and the user and group management
menu will redisplay.
figure 2-59. exit user and group management
groups could also be added at this time if specific needs are known.
otherwise, this may be accessed through using /stand/sysinstall after
installation is completed.
when you are finished adding users, select exit with the arrow keys and
press enter to continue the installation.
----------------------------------------------------------------------
2.9.15 set root password
message
now you must set the system manager's password.
this is the password you'll use to log in as "root".
[ ok ]
[ press enter to continue ]
press enter to set the root password.
the password will need to be typed in twice correctly. needless to say,
make sure you have a way of finding the password if you forget.
changing local password for root.
new password :
retype new password :
the installation will continue after the password is successfully entered.
----------------------------------------------------------------------
2.9.16 exiting install
if you need to configure additional network devices or to do any other
configurations, you can do it at this point or after installation with
/stand/sysinstall.
user confirmation requested
visit the general configuration menu for a chance to set any last
options?
yes [ no ]
selecting [ no ] with the arrow keys and pressing enter returns to the
main installation menu
figure 2-60. exit install
select [x exit install] with the arrow keys and press enter. you will be
asked to confirm exiting the installation:
user confirmation requested
are you sure you wish to exit? the system will reboot (be sure to
remove any floppies from the drives).
[ yes ] no
select [ yes ] and remove floppy if booting from floppy. the cdrom drive
is locked until the machine starts to reboot. the cdrom drive is then
unlocked and can be removed from drive (quickly).
the system will reboot so watch for any error messages that may appear.
----------------------------------------------------------------------
2.9.17 freebsd bootup
2.9.17.1 freebsd bootup on the i386
if everything went well, you will see messages scroll off the screen and
you will arrive at a login prompt. you can view the content of the
messages by pressing scroll-lock and using pgup and pgdn. pressing
scroll-lock again will return to the prompt.
the entire message may not display (buffer limitation) but it can be
viewed from the command line after logging in by typing dmesg at the
prompt.
login using the username/password you set during installation (rpratt, in
this example). avoid logging in as root except when necessary.
typical boot messages:
copyright (c) 1992-2002 the freebsd project.
copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
the regents of the university of california. all rights reserved.
freebsd 4.5-rc2 #0: thu jan 17 21:24:52 gmt 2002
[email protected]:/usr/src/sys/compile/generic
timecounter "i8254" frequency 1193182 hz
cpu: amd-k6(tm) 3d processor (300.68-mhz 586-class cpu)
origin = "authenticamd" id = 0x580 stepping = 0
features=0x8001bf<fpu,vme,de,pse,tsc,msr,mce,cx8,mmx>
amd features=0x80000800<syscall,3dnow!>
real memory = 268435456 (262144k bytes)
config> di sn0
config> di lnc0
config> di le0
config> di ie0
config> di fe0
config> di cs0
config> di bt0
config> di aic0
config> di aha0
config> di adv0
config> q
avail memory = 256311296 (250304k bytes)
preloaded elf kernel "kernel" at 0xc0491000.
preloaded userconfig_script "/boot/kernel.conf" at 0xc049109c.
md0: malloc disk
using $pir table, 4 entries at 0xc00fde60
npx0: <math processor> on motherboard
npx0: int 16 interface
pcib0: <host to pci bridge> on motherboard
pci0: <pci bus> on pcib0
pcib1: <via 82c598mvp (apollo mvp3) pci-pci (agp) bridge> at device 1.0 on
pci0
pci1: <pci bus> on pcib1
pci1: <matrox mga g200 agp graphics accelerator> at 0.0 irq 11
isab0: <via 82c586 pci-isa bridge> at device 7.0 on pci0
isa0: <isa bus> on isab0
atapci0: <via 82c586 ata33 controller> port 0xe000-0xe00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: <via 83c572 usb controller> port 0xe400-0xe41f irq 10 at device 7.2 on
pci0
usb0: <via 83c572 usb controller> on uhci0
usb0: usb revision 1.0
uhub0: via uhci root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
chip1: <via 82c586b acpi interface> at device 7.3 on pci0
ed0: <ne2000 pci ethernet (realtek 8029)> port 0xe800-0xe81f irq 9 at
device 10.0 on pci0
ed0: address 52:54:05:de:73:1b, type ne2000 (16 bit)
isa0: too many dependant configs (8)
isa0: unexpected small tag 14
fdc0: <nec 72065b or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: fifo enabled, 8 bytes threshold
fd0: <1440-kb 3.5" drive> on fdc0 drive 0
atkbdc0: <keyboard controller (i8042)> at port 0x60-0x64 on isa0
atkbd0: <at keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <ps/2 mouse> irq 12 on atkbdc0
psm0: model generic ps/2 mouse, device id 0
vga0: <generic isa vga> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <system console> at flags 0x1 on isa0
sc0: vga <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550a
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550a
ppc0: <parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: smc-like chipset (ecp/epp/ps2/nibble) in compatible mode
ppc0: fifo with 16/16/15 bytes threshold
ppbus0: ieee1284 device found /nibble
probing for pnp devices on ppbus0:
plip0: <plip network interface> on ppbus0
lpt0: <printer> on ppbus0
lpt0: interrupt-driven port
ppi0: <parallel i/o> on ppbus0
ad0: 8063mb <ibm-dhea-38451> [16383/16/63] at ata0-master using udma33
ad2: 8063mb <ibm-dhea-38451> [16383/16/63] at ata1-master using udma33
acd0: cdrom <delta otc-h101/st3 f/w by oipd> at ata0-slave using pio4
mounting root from ufs:/dev/ad0s1a
swapon: adding /dev/ad0s1b as swap device
automatic boot in progress...
/dev/ad0s1a: filesystem clean; skipping checks
/dev/ad0s1a: clean, 48752 free (552 frags, 6025 blocks, 0.9% fragmentation)
/dev/ad0s1f: filesystem clean; skipping checks
/dev/ad0s1f: clean, 128997 free (21 frags, 16122 blocks, 0.0% fragmentation)
/dev/ad0s1g: filesystem clean; skipping checks
/dev/ad0s1g: clean, 3036299 free (43175 frags, 374073 blocks, 1.3%
fragmentation)
/dev/ad0s1e: filesystem clean; skipping checks
/dev/ad0s1e: clean, 128193 free (17 frags, 16022 blocks, 0.0% fragmentation)
doing initial network setup: hostname.
ed0: flags=8843<up,broadcast,running,simplex,multicast> mtu 1500
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::5054::5ff::fede:731b%ed0 prefixlen 64 tentative scopeid
0x1
ether 52:54:05:de:73:1b
lo0: flags=8049<up,loopback,running,multicast> mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
additional routing options: ip gateway=yes tcp keepalive=yes
routing daemons:.
additional daemons: syslogd.
doing additional network setup:.
starting final network daemons: creating ssh rsa host key
generating public/private rsa1 key pair.
your identification has been saved in /etc/ssh/ssh_host_key.
your public key has been saved in /etc/ssh/ssh_host_key.pub.
the key fingerprint is:
cd:76:89:16:69:0e:d0:6e:f8:66:d0:07:26:3c:7e:2d [email protected]
creating ssh dsa host key
generating public/private dsa key pair.
your identification has been saved in /etc/ssh/ssh_host_dsa_key.
your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
the key fingerprint is:
f9:a1:a9:47:c4:ad:f9:8d:52:b8:b8:ff:8c:ad:2d:e6 [email protected].
setting elf ldconfig path: /usr/lib /usr/lib/compat /usr/x11r6/lib
/usr/local/lib
a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/x11r6/lib/aout
starting standard daemons: inetd cron sshd usbd sendmail.
initial rc.i386 initialization:.
rc.i386 configuring syscons: blank_time screensaver moused.
additional abi support: linux.
local package initilization:.
additional tcp options:.
freebsd/i386 (k6-2.example.com) (ttyv0)
login: rpratt
password:
generating the rsa and dsa keys may take some time on slower machines.
this happens only on the initial boot-up of a new installation. subsequent
boots will be faster.
if the x server has been configured and a default desktop chosen, it can
be started by typing startx at the command line.
----------------------------------------------------------------------
2.9.17.2 bootup of freebsd on the alpha
once the install procedure has finished, you will be able to start freebsd
by typing something like this to the srm prompt:
>>>boot dkc0
this instructs the firmware to boot the specified disk. to make freebsd
boot automatically in the future, use these commands:
>>> set boot_osflags a
>>> set boot_file ''
>>> set bootdef_dev dkc0
>>> set auto_action boot
the boot messages will be similar (but not identical) to those produced by
freebsd booting on the i386.
----------------------------------------------------------------------
2.9.18 freebsd shutdown
it is important to properly shutdown the operating system. do not just
turn off power. first, become a superuser by typing su at the command line
and entering the root password. this will work only if the user is a
member of the group wheel. otherwise, login as root and use shutdown -h
now.
the operating system has halted.
please press any key to reboot.
it is safe to turn off the power after the shutdown command has been
issued and the message ``please press any key to reboot'' appears. if any
key is pressed instead of turning off the power switch, the system will
reboot.
you could also use the ctrl+alt+del key combination to reboot the system,
however this is not recommended during normal operation.
----------------------------------------------------------------------
2.10 supported hardware
freebsd currently runs on a wide variety of isa, vlb, eisa, and pci
bus-based pcs with intel, amd, cyrix, or nexgen ``x86'' processors, as
well as a number of machines based on the compaq alpha processor. support
for generic ide or esdi drive configurations, various scsi controllers,
pcmcia cards, usb devices, and network and serial cards is also provided.
freebsd also supports ibm's microchannel (mca) bus.
a list of supported hardware is provided with each freebsd release in the
freebsd hardware notes. this document can usually be found in a file named
hardware.txt, in the top-level directory of a cdrom or ftp distribution or
in sysinstall's documentation menu. it lists, for a given architecture,
what hardware devices are known to be supported by each release of
freebsd.
----------------------------------------------------------------------
2.11 troubleshooting
the following section covers basic installation troubleshooting, such as
common problems people have reported. there are also a few questions and
answers for people wishing to dual-boot freebsd with ms-dos.
----------------------------------------------------------------------
2.11.1 what to do if something goes wrong...
due to various limitations of the pc architecture, it is impossible for
probing to be 100% reliable, however, there are a few things you can do if
it fails.
check the hardware notes document for your version of freebsd to make sure
your hardware is supported.
if your hardware is supported and you still experience lock-ups or other
problems, reset your computer, and when the visual kernel configuration
option is given, choose it. this will allow you to go through your
hardware and supply information to the system about it. the kernel on the
boot disks is configured assuming that most hardware devices are in their
factory default configuration in terms of irqs, io addresses, and dma
channels. if your hardware has been reconfigured, you will most likely
need to use the configuration editor to tell freebsd where to find things.
it is also possible that a probe for a device not present will cause a
later probe for another device that is present to fail. in that case, the
probes for the conflicting driver(s) should be disabled.
note: some installation problems can be avoided or alleviated by by
updating the firmware on various hardware components, most notably the
motherboard. the motherboard firmware may also be referred to as bios
and most of the motherboard or computer manufactures have a website
where the upgrades and upgrade information may be located.
most manufacturers strongly advise against upgrading the motherboard
bios unless there is a good reason for doing so, which could possibly be
a critical update of sorts. the upgrade process can go wrong, causing
permanent damage to the bios chip.
warning: do not disable any drivers you will need during the
installation, such as your screen (sc0). if the installation wedges or
fails mysteriously after leaving the configuration editor, you have
probably removed or changed something you should not have. reboot and
try again.
in configuration mode, you can:
* list the device drivers installed in the kernel.
* change device drivers for hardware that is not present in your system.
* change irqs, drqs, and io port addresses used by a device driver.
after adjusting the kernel to match your hardware configuration, type q to
boot with the new settings. once the installation has completed, any
changes you made in the configuration mode will be permanent so you do not
have to reconfigure every time you boot. it is still highly likely that
you will eventually want to build a custom kernel.
----------------------------------------------------------------------
2.11.2 ms-dos user's questions and answers
many users wish to install freebsd on pcs inhabited by ms-dos. here are
some commonly asked questions about installing freebsd on such systems.
2.11.2.1. help, i have no space! do i need to delete everything first?
2.11.2.2. can i use compressed ms-dos filesystems from freebsd?
2.11.2.3. can i mount my extended ms-dos partition?
2.11.2.1. help, i have no space! do i need to delete everything first?
if your machine is already running ms-dos and has little or no free space
available for the freebsd installation, all hope is not lost! you may find
the fips utility, provided in the tools directory on the freebsd cdrom or
various freebsd ftp sites to be quite useful.
fips allows you to split an existing ms-dos partition into two pieces,
preserving the original partition and allowing you to install onto the
second free piece. you first defragment your ms-dos partition using the
windows defrag utility (go into explorer, right-click on the hard drive,
and choose to defrag your hard drive), or norton disk tools. you then must
run fips. it will prompt you for the rest of the information it needs.
afterwards, you can reboot and install freebsd on the new free slice. see
the distributions menu for an estimate of how much free space you will
need for the kind of installation you want.
there is also a very useful product from powerquest called partition
magic. this application has far more functionality than fips, and is
highly recommended if you plan to often add/remove operating systems (like
me). however, it does cost money, and if you plan to install freebsd once
and then leave it there, fips will probably be fine for you.
2.11.2.2. can i use compressed ms-dos filesystems from freebsd?
no. if you are using a utility such as stacker(tm) or doublespace(tm),
freebsd will only be able to use whatever portion of the filesystem you
leave uncompressed. the rest of the filesystem will show up as one large
file (the stacked/double spaced file!). do not remove that file or you
will probably regret it greatly!
it is probably better to create another uncompressed primary ms-dos
partition and use this for communications between ms-dos and freebsd.
2.11.2.3. can i mount my extended ms-dos partition?
yes. dos extended partitions are mapped in at the end of the other
``slices'' in freebsd, e.g., your d: drive might be /dev/da0s5, your e:
drive, /dev/da0s6, and so on. this example assumes, of course, that your
extended partition is on scsi drive 0. for ide drives, substitute ad for
da appropriately if installing 4.0-release or later, and substitute wd for
da if you are installing a version of freebsd prior to 4.0. you otherwise
mount extended partitions exactly like you would any other dos drive, for
example:
# mount -t msdos /dev/ad0s5 /dos_d
----------------------------------------------------------------------
2.11.3 alpha user's questions and answers
this section answers some commonly asked questions about installing
freebsd on alpha systems.
2.11.3.1. can i boot from the arc or alpha bios console?
2.11.3.2. help, i have no space! do i need to delete everything first?
2.11.3.3. can i mount my compaq tru64 or vms filesystems?
2.11.3.1. can i boot from the arc or alpha bios console?
no. freebsd, like compaq tru64 and vms, will only boot from the srm
console.
2.11.3.2. help, i have no space! do i need to delete everything first?
unfortunately, yes.
2.11.3.3. can i mount my compaq tru64 or vms filesystems?
no, not at this time.
----------------------------------------------------------------------
2.12 advanced installation guide
contributed by valentino vaschetto.
this section describes how to install freebsd in exceptional cases.
----------------------------------------------------------------------
2.12.1 installing freebsd on a system without a monitor or keyboard
this type of installation is called a ``headless install'', because the
machine that you are trying to install freebsd on either does not have a
monitor attached to it, or does not even have a vga output. how is this
possible you ask? using a serial console. a serial console is basically
using another machine to act as the main display and keyboard for a
system. to do this, just follow these steps:
#1. fetch the right boot floppy images
first you will need to get the right disk images so that you can boot
into the install program. the secret with using a serial console is
that you tell the boot loader to send i/o through a serial port
instead of displaying console output to the vga device and trying to
read input from a local keyboard. enough of that now, let's get back
to getting these disk images.
you will need to get kern.flp and mfsroot.flp from the floppies
directory.
#2. write the image files to the floppy disks.
the image files, such as kern.flp, are not regular files that you copy
to the disk. instead, they are images of the complete contents of the
disk.
this means that you can not use commands like dos' copy to write the
files. instead, you must use specific tools to write the images
directly to the disk.
if you are creating the floppies on a computer running dos then we
provide a tool to do this called fdimage.
if you are using the floppies from the cdrom, and your cdrom is the e:
drive then you would run this:
e:\> tools\fdimage floppies\kern.flp a:
repeat this command for each .flp file, replacing the floppy disk each
time. adjust the command line as necessary, depending on where you
have placed the .flp files. if you do not have the cdrom then fdimage
can be downloaded from the tools directory on the freebsd ftp site.
if you are writing the floppies on a unix system (such as another
freebsd system) you can use the dd(1) command to write the image files
directly to disk. on freebsd you would run:
# dd if=kern.flp of=/dev/fd0
on freebsd /dev/fd0 refers to the first floppy disk (the a: drive).
/dev/fd1 would be the b: drive, and so on. other unix variants might
have different names for the floppy disk devices, and you will need to
check the documentation for the system as necessary.
#3. enabling the boot floppies to boot into a serial console
warning: do not try to mount the floppy if it is write-protected
if you were to boot into the floppies that you just made, freebsd
would boot into its normal install mode. we want freebsd to boot into
a serial console for our install. to do this, you have to mount the
kern.flp floppy onto your freebsd system using the mount(8) command.
# mount /dev/fd0 /mnt
now that you have the floppy mounted, you must change into the floppy
directory
# cd /mnt
here is where you must set the floppy to boot into a serial console.
you have to make a file called boot.config containing /boot/loader -h.
all this does is pass a flag to the bootloader to boot into a serial
console.
# echo "/boot/loader -h" > boot.config
now that you have your floppy configured correctly, you must unmount
the floppy using the umount(8) command
# cd /
# umount /mnt
now you can remove the floppy from the floppy drive
#4. connecting your null modem cable
you now need to connect a null modem cable between the two machines.
just connect the cable to the serial ports of the 2 machines. a normal
serial cable will not work here, you need a null modem cable because
it has some of the wires inside crossed over.
#5. booting up for the install
it is now time to go ahead and start the install. put the kern.flp
floppy in the floppy drive of the machine you are doing the headless
install on, and power on the machine.
#6. connecting to your headless machine
now you have to connect to that machine with cu(1):
# cu -l /dev/cuaa0
that's it! you should be able to control the headless machine through your
cu session now. it will ask you to put in the mfsroot.flp, and then it
will come up with a selection of what kind of terminal to use. just select
the freebsd color console and proceed with your install!
----------------------------------------------------------------------
2.13 preparing your own installation media
note: to prevent repetition, ``freebsd disk'' in this context means a
freebsd cdrom or dvd that you have purchased, or produced yourself.
there may be some situations in which you need to create your own freebsd
installation media and/or source. this might be physical media, such as a
tape, or a source that sysinstall can use to retrieve the files, such as a
local ftp site, or an ms-dos partition. for example:
* you have many machines connected to your local network, and one
freebsd disk. you want to create a local ftp site using the contents
of the freebsd disk, and then have your machines use this local ftp
site instead of needing to connect to the internet.
* you have a freebsd disk, freebsd does not recognize your cd/dvd drive,
but dos/windows does. you want to copy the freebsd installations files
to a dos partition on the same computer, and then install freebsd
using those files.
* the computer you want to install on does not have a cd/dvd drive, or a
network card, but you can connect a ``laplink-style'' serial or
parallel cable to a computer that does.
* you want to create a tape that can be used to install freebsd.
----------------------------------------------------------------------
2.13.1 creating a local ftp site with a freebsd disk
freebsd disks are laid out in the same way as the ftp site. this makes it
very easy for you to create a local ftp site that can be used by other
machines on your network when installing freebsd.
#1. on the freebsd computer that will host the ftp site, ensure that the
cdrom is in the drive, and mounted on /cdrom.
# mount /cdrom
#2. create an account for anonymous ftp in /etc/passwd. do this by editing
/etc/passwd using vipw(8) and adding this line.
ftp:*:99:99::0:0:ftp:/cdrom:/nonexistent
#3. ensure that the ftp service is enabled in /etc/inetd.conf.
anyone with network connectivity to your machine can now chose a media
type of ftp and type in ftp://your machine after picking ``other'' in the
ftp sites menu during the install.
warning: this approach is ok for a machine that is on your local
network, and that is protected by your firewall. offering up ftp
services to other machines over the internet (and not your local
network) exposes your computer to the attention of crackers and other
undesirables. we strongly recommend that you follow good security
practices if you do this.
----------------------------------------------------------------------
2.13.2 creating installation floppies
if you must install from floppy disk (which we suggest you do not do),
either due to unsupported hardware or simply because you insist on doing
things the hard way, you must first prepare some floppies for the
installation.
at a minimum, you will need as many 1.44mb or 1.2mb floppies as it takes
to hold all the files in the bin (binary distribution) directory. if you
are preparing the floppies from dos, then they must be formatted using the
ms-dos format command. if you are using windows, use explorer to format
the disks (right-click on the a: drive, and select "format".
do not trust factory pre-formatted floppies. format them again yourself,
just to be sure. many problems reported by our users in the past have
resulted from the use of improperly formatted media, which is why we are
making a point of it now.
if you are creating the floppies on another freebsd machine, a format is
still not a bad idea, though you do not need to put a dos filesystem on
each floppy. you can use the disklabel and newfs commands to put a ufs
filesystem on them instead, as the following sequence of commands (for a
3.5" 1.44mb floppy) illustrates:
# fdformat -f 1440 fd0.1440
# disklabel -w -r fd0.1440 floppy3
# newfs -t 2 -u 18 -l 1 -i 65536 /dev/fd0
note: use fd0.1200 and floppy5 for 5.25" 1.2mb disks.
then you can mount and write to them like any other filesystem.
after you have formatted the floppies, you will need to copy the files to
them. the distribution files are split into chunks conveniently sized so
that 5 of them will fit on a conventional 1.44mb floppy. go through all
your floppies, packing as many files as will fit on each one, until you
have all of the distributions you want packed up in this fashion. each
distribution should go into a subdirectory on the floppy, e.g.:
a:\bin\bin.aa, a:\bin\bin.ab, and so on.
once you come to the media screen during the install process, select
``floppy'' and you will be prompted for the rest.
----------------------------------------------------------------------
2.13.3 installing from an ms-dos partition
to prepare for an installation from an ms-dos partition, copy the files
from the distribution into a directory on that partition. for example,
c:\freebsd. the directory structure of the cdrom or ftp site must be
partially reproduced within this directory, so we suggest using the dos
xcopy command if you are copying it from a cd. for example, to prepare for
a minimal installation of freebsd:
c:\> md c:\freebsd
c:\> xcopy e:\bin c:\freebsd\bin\ /s
c:\> xcopy e:\manpages c:\freebsd\manpages\ /s
assuming that c: is where you have free space and e: is where your cdrom
is mounted.
if you do not have a cdrom drive, you can download the distribution from
ftp.freebsd.org. each distribution is in its own directory; for example,
the bin distribution can be found in the 4.5/bin/ directory.
for as many distributions you wish to install from an ms-dos partition
(and you have the free space for), install each one under c:\freebsd --
the bin distribution is the only one required for a minimum installation.
----------------------------------------------------------------------
2.13.4 creating an installation tape
installing from tape is probably the easiest method, short of an online
ftp install or cdrom install. the installation program expects the files
to be simply tarred onto the tape. after getting all of the distribution
files you are interested in, simply tar them onto the tape:
# cd /freebsd/distdir
# tar cvf /dev/rwt0 dist1 ... dist2
when you go to do the installation, you should also make sure that you
leave enough room in some temporary directory (which you will be allowed
to choose) to accommodate the full contents of the tape you have created.
due to the non-random access nature of tapes, this method of installation
requires quite a bit of temporary storage. you should expect to require as
much temporary storage as you have stuff written on tape.
note: when starting the installation, the tape must be in the drive
before booting from the boot floppy. the installation probe may
otherwise fail to find it.
----------------------------------------------------------------------
2.13.5 before installing over a network
there are three types of network installations you can do. serial port
(slip or ppp), parallel port (plip (laplink cable)), or ethernet (a
standard ethernet controller (includes some pcmcia)).
the slip support is rather primitive, and limited primarily to hard-wired
links, such as a serial cable running between a laptop computer and
another computer. the link should be hard-wired as the slip installation
does not currently offer a dialing capability; that facility is provided
with the ppp utility, which should be used in preference to slip whenever
possible.
if you are using a modem, then ppp is almost certainly your only choice.
make sure that you have your service provider's information handy as you
will need to know it fairly early in the installation process.
if you use pap or chap to connect your isp (in other words, if you can
connect to the isp in windows without using a script), then all you will
need to do is type in dial at the ppp prompt. otherwise, you will need to
know how to dial your isp using the ``at commands'' specific to your
modem, as the ppp dialer provides only a very simple terminal emulator.
please refer to the user-ppp handbook and faq entries for further
information. if you have problems, logging can be directed to the screen
using the command set log local ....
if a hard-wired connection to another freebsd (2.0-r or later) machine is
available, you might also consider installing over a ``laplink'' parallel
port cable. the data rate over the parallel port is much higher than what
is typically possible over a serial line (up to 50kbytes/sec), thus
resulting in a quicker installation.
finally, for the fastest possible network installation, an ethernet
adapter is always a good choice! freebsd supports most common pc ethernet
cards; a table of supported cards (and their required settings) is
provided in the hardware notes for each release of freebsd. if you are
using one of the supported pcmcia ethernet cards, also be sure that it is
plugged in before the laptop is powered on! freebsd does not,
unfortunately, currently support hot insertion of pcmcia cards during
installation.
you will also need to know your ip address on the network, the netmask
value for your address class, and the name of your machine. if you are
installing over a ppp connection and do not have a static ip, fear not,
the ip address can be dynamically assigned by your isp. your system
administrator can tell you which values to use for your particular network
setup. if you will be referring to other hosts by name rather than ip
address, you will also need a name server and possibly the address of a
gateway (if you are using ppp, it is your provider's ip address) to use in
talking to it. if you want to install by ftp via a http proxy (see below),
you will also need the proxy's address. if you do not know the answers to
all or most of these questions, then you should really probably talk to
your system administrator or isp before trying this type of installation.
----------------------------------------------------------------------
2.13.5.1 before installing via nfs
the nfs installation is fairly straight-forward. simply copy the freebsd
distribution files you want onto a server somewhere and then point the nfs
media selection at it.
if this server supports only ``privileged port'' (as is generally the
default for sun workstations), you will need to set this option in the
options menu before installation can proceed.
if you have a poor quality ethernet card which suffers from very slow
transfer rates, you may also wish to toggle the appropriate options flag.
in order for nfs installation to work, the server must support subdir
mounts, e.g., if your freebsd 3.4 distribution directory lives
on:ziggy:/usr/archive/stuff/freebsd, then ziggy will have to allow the
direct mounting of /usr/archive/stuff/freebsd, not just /usr or
/usr/archive/stuff.
in freebsd's /etc/exports file, this is controlled by the -alldirs. other
nfs servers may have different conventions. if you are getting
``permission denied'' messages from the server, then it is likely that you
do not have this enabled properly.
----------------------------------------------------------------------
chapter 3 unix basics
rewritten by chris shumway.
3.1 synopsis
the following chapter will cover the basic commands and functionality of
the freebsd 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 freebsd, then you will
definitely want to read through this chapter carefully.
after reading this chapter, you will know:
* how unix file permissions work.
* what processes, daemons, and signals are.
* what a shell is, and how to change your default login environment.
* how to use basic text editors.
* how to read manual pages for more information.
----------------------------------------------------------------------
3.2 permissions
freebsd, being a direct descendant of bsd unix, is based on several key
unix concepts. the first, and most pronounced, is that freebsd 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 evenly 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 two 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. here is how the first column of
ls -l is broken up:
-rw-r--r--
the first character, from left to right, is a special character that tells
if this is a regular file, a directory, a special character or block
device, a socket, or any other special pseudo-file device. the next three
characters, designated as rw- gives the permissions for the owner of the
file. the next three characters, r-- gives the permissions for the group
that the file belongs to. the final three characters, r--, gives 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? freebsd 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 moved into, i.e. it is possible to ``cd'' 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 able 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 to permissions, 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) man page.
----------------------------------------------------------------------
3.3 directory structure
the freebsd 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. standard mount points include /usr, /var, /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. consult the fstab(5) manual page for more
information on the format of the /etc/fstab file and the options it
contains.
a complete description of the filesystem hierarchy is available in
hier(7). for now, a brief overview of the most common directories will
suffice.
directory description
/ root directory of the filesystem.
/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.
/tmp/ temporary files, usually a mfs(8) memory-based filesystem
(the contents of /tmp are usually not preserved across a
system reboot).
/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).
/usr/local/ local executables, libraries, etc. also used as the
default destination for the freebsd ports framework.
within /usr/local, the general layout sketched out by
hier(7) for /usr should be used. exceptions are the man
directory is directly under /usr/local rather than under
/usr/local/share. ports documentation is in
share/doc/port.
/usr/obj/ architecture-specific target tree produced by building the
/usr/src tree.
/usr/ports the freebsd ports collection (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).
/var/ multi-purpose log, temporary, transient, and spool files.
/var/log/ miscellaneous system log files.
/var/mail/ user mailbox files.
/var/spool/ miscellaneous printer and mail system spooling
directories.
/var/tmp/ temporary files that are kept between system reboots.
/var/yp nis maps.
----------------------------------------------------------------------
3.4 mounting and unmounting filesystems
the filesystem 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
filesystems. /var contains the directories log/, spool/, and various types
of temporary files, and as such, may get filled up. filling up the root
filesystem is not a good idea, so splitting /var from / is often
favorable.
another common reason to contain certain directory trees on other
filesystems 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.4.1 the fstab file
during the boot process, filesystems 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 disk naming
conventions above.
mount-point
a directory (which should exist), on which to mount the
filesystem.
fstype
the filesystem type to pass to mount(8). the default freebsd
filesystem is ufs.
options
either rw for read-write filesystems, or ro for read-only
filesystems, followed by any other options that may be needed. a
common option is noauto for filesystems not normally mounted
during the boot sequence. other options are listed in the mount(8)
manual page.
dumpfreq
this is used by dump to determine which filesystems require
dumping. if the field is missing, a value of zero is assumed.
passno
this determines the order in which filesystems should be checked.
filesystems that should be skipped should have their passno set to
zero. the root filesystem (which needs to be checked before
everything else) should have it's passno set to one, and other
filesystems' passno should be set to values greater than one. if
more than one filesystems have the same passno then fsck(8) will
attempt to check filesystems in parallel if possible.
----------------------------------------------------------------------
3.4.2 the mount command
the mount(8) command is what is ultimately used to mount filesystems.
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 filesystems listed in /etc/fstab. exceptions are
those marked as ``noauto'', excluded by the -t flag, or those that
are already mounted.
-d
do everything except for the actual system call. this option is
useful in conjunction with the -v flag to determine what the mount
is actually trying to do.
-f
force the mount of an unclean filesystem (dangerous), or forces
the revocation of write access when downgrading a filesystem's
mount status from read-write to read-only.
-r
mount the filesystem read-only. this is identical to using the
rdonly argument to the -o option.
-t fstype
mount the given filesystem as the given filesystem type, or mount
only filesystems of the given type, if given the -a option.
``ufs'' is the default filesystem type.
-u
update mount options on the filesystem.
-v
be verbose.
-w
mount the filesystem read-write.
the -o option takes a comma-separated list of the options, including the
following:
nodev
do not interpret special devices on the filesystem. this is a
useful security option.
noexec
do not allow execution of binaries on this filesystem. this is
also a useful security option.
nosuid
do not interpret setuid or setgid flags on the filesystem. this is
also a useful security option.
----------------------------------------------------------------------
3.4.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 filesystems
might crash the computer or damage data on the filesystem.
-a and -a are used to unmount all mounted filesystems, possibly modified
by the filesystem types listed after -t. -a, however, does not attempt to
unmount the root filesystem.
----------------------------------------------------------------------
3.5 processes
freebsd 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. init is
always the first process, so its pid is always 1. init is started
automatically by the kernel when freebsd starts.
two commands are particularly useful to see the processes on the system,
ps(1) and top(1). the ps(1) 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(1)
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(1) 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 in to 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. tt 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 not necessarily the elapsed time
since you started the program, as some 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 in to 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
in to 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 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.6 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 bsd mascot has,
for a long time, been the 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 daemons
(or with any 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 try and send a
signal to someone else's process it will be ignored. the exception to this
is the root user, who can send signals to everyone's processes.
freebsd 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, freebsd 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 freebsd will stop that process there and then[1].
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(8)
configuration file is /etc/inetd.conf, and inetd(8) 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 most with unix commands, kill(1) will not print any output
if it is successful. if you try and 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.7 shells
in freebsd, 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 a file management, file globing, command line
editing, command macros, and environment variables. freebsd comes with a
set of shells, such as sh, the bourne shell, and tcsh, the improved
c-shell. many other shells are available from the freebsd ports
collection, 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 file-name 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 function of the shell is 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., freebsd.
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.
to view or set 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 and view environment variables. under bourne shells such
as sh and bash, you would use set and export to view and 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 file name globing. 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.7.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
running chsh with no parameters and editing the shell from there would
work also.
note: the shell that you wish to use must be present in the /etc/shells
file. if you have installed a shell from the ports 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.8 text editors
a lot of configuration in freebsd is done by editing text files. because
of this, it would be a good idea to become familiar with a text editor.
freebsd comes with a few as part of the base system, and many more are
available in the ports collection.
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 means the control key on the
keyboard, so ^e expands to pressing the control key plus the letter e. to
leave ee, hit the escape key, then choose leave editor. the editor will
prompt you to save any changes if the file has been modified.
freebsd also comes with more powerful text editors such as vi as part of
the base system, and emacs and vim as part of the freebsd ports
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.9 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
freebsd boots, the majority of what freebsd 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
a special file called device nodes, which are located in the /dev
directory.
----------------------------------------------------------------------
3.9.1 creating device nodes
when adding a new device to your system, or compiling in support for
additional devices, a device driver often-times needs to be created.
----------------------------------------------------------------------
3.9.1.1 makedev script
on systems without devfs, 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.9.1.2 devfs (device file system)
the device file system, or devfs, provides access to kernel's device
namespace in the global filesystem namespace. instead of having to create
and modify device nodes, devfs maintains this particular filesystem for
you.
see the devfs(5) man page for more information.
devfs is used by default in freebsd 5.0.
----------------------------------------------------------------------
3.10 for more information...
3.10.1 manual pages
the most comprehensive documentation on freebsd 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 developers.
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.10.2 gnu info files
freebsd 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: packages and ports
4.1 synopsis
freebsd 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.
freebsd provides two complementary technologies for installing third party
software on your system; the freebsd ports collection, and binary software
packages. either 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.
* how to build third-party software from the ports collection.
* how to remove previously installed packages or ports.
----------------------------------------------------------------------
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 either compress(1) or gzip(1)).
#3. locate the documentation (perhaps a 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 freebsd 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 freebsd. however, freebsd provides two
technologies which can save you a lot of effort; packages and ports. at
the time of writing, over 6,600 third party applications have been made
available in this way.
for any given application, the freebsd 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 freebsd 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.
a freebsd port for an application is 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 (unpacking, patching, compiling,
installing). the files that make up a port 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 ports system 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.
both packages and ports understand 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 as freebsd
ports and packages. if you use the pkg_add command or the ports system to
add the application, both will notice that the library has not been
installed, and the commands will install the library first.
given that the two technologies are quite similar, you might be wondering
why freebsd bothers with both. packages and ports both have their own
strengths, and which one you use will depend on your own preference.
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 you to understand the process involved in
compiling software on freebsd.
ports benefits
* packages are normally compiled with conservative options, because they
have to run on the maximum number of systems. by installing from the
port, you can tweak the compilation options to (for example) generate
code that is specific to a pentium iii 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 port 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, ghostscript is available as
a ghostscript package and a ghostscript-nox11 package, depending on
whether or not 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. at least with source
code, you can (in theory) read through it and look for potential
problems yourself.
* 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 ports, subscribe to the freebsd ports mailing
list <[email protected]>.
the remainder of this chapter will explain how to use packages and ports
to install and manage third party software on freebsd.
----------------------------------------------------------------------
4.3 finding your application
before you can install any applications you need to know what you want,
and what the application is called.
freebsd's list of available applications is growing all the time.
fortunately, there are a number of ways to find what you want.
* the freebsd web site maintains an up-to-date searchable list of all
the available applications, at http://www.freebsd.org/ports/. the name
space is divided in to categories, and you may either search for an
application by name (if you know it), or you can list all the
applications available in a category.
* dan langille maintains freshports, at http://www.freshports.org/.
freshports tracks changes to the applications in the ports tree as
they happen, and allows you to ``watch'' one or more ports, and will
send you an email when they are updated.
* if you do not know the name of the application you want, try using a
site like freshmeat (http://www.freshmeat.net/) to find an
application, then check back at the freebsd site to see if the
application has been ported yet.
----------------------------------------------------------------------
4.4 using the packages system
contributed by chern lee.
4.4.1 installing a package
you can use the pkg_add(1) utility to install a freebsd software package
from a local file or from a server on the network.
example 4-1. downloading a package and then installing it locally
# ftp -a ftp2.freebsd.org
connected to ftp2.freebsd.org.
220 ftp2.freebsd.org ftp server (version 6.00ls) ready.
331 guest login ok, send your email address as password.
230-
230- this machine is in vienna, va, usa, hosted by verio.
230- questions? e-mail [email protected].
230-
230-
230 guest login ok, access restrictions apply.
remote system type is unix.
using binary mode to transfer files.
ftp> cd /pub/freebsd/ports/packages/sysutils/
250 cwd command successful.
ftp> get lsof-4.56.4.tgz
local: lsof-4.56.4.tgz remote: lsof-4.56.4.tgz
200 port command successful.
150 opening binary mode data connection for 'lsof-4.56.4.tgz' (92375 bytes).
100% |**************************************************| 92375 00:00
eta
226 transfer complete.
92375 bytes received in 5.60 seconds (16.11 kb/s)
ftp> exit
# pkg_add lsof-4.56.4.tgz
if you do not have a source of local packages (such as a freebsd cdrom
set) then it will probably be easier to use the -r option to pkg_add(1).
this will cause the utility to automatically determine the correct object
format and release and then to fetch and install the package from an ftp
site.
# pkg_add -r lsof-4.56.4
the example above would download the correct package and add it without
any further user intervention.
package files are distributed in .tgz format. you can find them at
ftp://ftp.freebsd.org/pub/freebsd/ports/packages/, or on the freebsd cdrom
distribution. every cd on the freebsd 4-cd set (and powerpak, etc)
contains packages in the /packages directory. the layout of the packages
is similar to that of the /usr/ports tree. each category has its own
directory, and every package can be found within the all directory.
the directory structure of the package system is identical to that of the
ports; they work with each other to form the entire package/port system.
----------------------------------------------------------------------
4.4.2 deleting a package
to remove a previously installed software package, use the pkg_delete(1)
utility.
# pkg_delete xchat-1.7.1
----------------------------------------------------------------------
4.4.3 managing packages
pkg_info(1) is a utility that lists and describes the various packages
installed.
# pkg_info
cvsup-16.1 a general network file distribution system optimized for
cv
docbook-1.2 meta-port for the different versions of the docbook dtd
...
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.
# pkg_version
cvsup =
docbook =
...
the symbols in the second column indicate the relative age of the
installed version and the version available in the local ports tree.
symbol meaning
= the version of the installed package matches that of the one found
in the local ports tree.
< the installed version is older then the one available in the ports
tree.
> the installed version is newer than the one found in the local
ports tree. (local ports tree is probably out of date)
? the installed package cannot be found in the ports index.
* there are multiple versions of the package.
----------------------------------------------------------------------
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
files in this directory.
----------------------------------------------------------------------
4.5 using the ports collection
the following sections provide basic instructions on using the ports
collection to install or remove programs from your system.
----------------------------------------------------------------------
4.5.1 obtaining the ports collection
before you can install ports, you must first obtain the ports
collection--which is essentially a set of makefiles, patches, and
description files usually placed in /usr/ports.
when installing your freebsd system, sysinstall asked if you would like to
install the ports collection. if you chose no, you can follow these
instructions to obtain the ports collection.
sysinstall method
this method involves using sysinstall again to manually install the ports
collection.
#1. as root, run /stand/sysinstall as shown below:
# /stand/sysinstall
#2. scroll down and select configure, press enter.
#3. scroll down and select distributions, press enter.
#4. scroll down to ports, press space.
#5. scroll up to exit, press enter.
#6. select your desired installation media, such as cdrom, ftp, and so on.
#7. follow the menus to exit sysinstall.
the alternative method to obtain and keep your ports collection up to date
is by using cvsup. look at the ports cvsup file,
/usr/share/examples/cvsup/ports-supfile. see using cvsup (section a.6) for
more information on using cvsup and the mentioned file.
cvsup method
this is a quick method to getting the ports collection using cvsup. if you
want to keep your ports tree up to date, or learn more about cvsup, read
the previously mentioned sections.
#1. install the net/cvsup port. see cvsup installation (section a.6.2) for
more details.
#2. as root, copy /usr/share/examples/cvsup/ports-supfile to a new
location, such as /root or your home directory.
#3. edit ports-supfile.
#4. change change_this.freebsd.org to a cvsup near you. see cvsup mirrors
(section a.6.7) for a complete listing of mirror sites.
#5. run cvsup:
# cvsup -g -l 2 /root/ports-supfile
#6. running this consequent times at later dates will download all the
recent changes to your ports collection.
----------------------------------------------------------------------
4.5.2 installing ports
the first thing that should be explained when it comes to the ports
collection is what is actually meant by a ``skeleton''. in a nutshell, a
port skeleton is a minimal set of files that tell your freebsd system how
to cleanly compile and install a program. each port skeleton includes:
* 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 checksums, to ensure that
those files have not been corrupted during the download.
* a files directory. this directory contains patches to make the program
compile and install on your freebsd 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 program.
this directory may also contain other files used in building the port.
* a pkg-comment file. this is a one-line description of the program.
* a pkg-descr file. this is a more detailed, often multiple-line,
description of the program.
* a pkg-plist file. this is a list of all the files that will be
installed by the port. it also tells the ports system what files to
remove upon deinstallation.
some ports have other files, such as pkg-message. the ports system uses
these files to handle special situations. if you want more details on
these files, and on ports in general, check out the freebsd porter's
handbook.
now that you have enough background information to know what the ports
collection is used for, you are ready to install your first port. there
are two ways this can be done, and each is explained below.
before we get into that however, you will need to choose a port to
install. there are a few ways to do this, with the easiest method being
the ports listing on the freebsd web site. you can browse through the
ports listed there or use the search function on the site. each port also
includes a description so you can read a bit about each port before
deciding to install it.
another method is to use the whereis command. simply type whereis file,
where file ist the program you want to install. if it is found on your
system, you will be told where it is, like so:
# whereis lsof
lsof: /usr/ports/sysutils/lsof
this tells us that lsof (a system utility) can be found in the
/usr/ports/sysutils/lsof directory.
yet another way of finding a particular port is by using the ports
collection's built-in search mechanism. to use the search feature, you
will need to be in the /usr/ports directory. once in that directory, run
make search name=program-name where program-name is the name of the
program you want to find. for example, if you were looking for lsof:
# cd /usr/ports
# make search name=lsof
port: lsof-4.56.4
path: /usr/ports/sysutils/lsof
info: lists information about open files (similar to fstat(1))
maint: [email protected]
index: sysutils
b-deps:
r-deps:
the part of the output you want to pay particular attention to is the
``path:'' line, since that tells you where to find it. the other
information provided is not needed in order to install the port directly,
so it will not be covered here.
for more in-depth searching you can also use make search key=string where
string is some text to search for. this searches port names, comments,
descriptions and dependencies and can be used to find ports which relate
to a particular subject if you don't know the name of the program you are
looking for.
in both of these cases, the search string is case-insensitive. searching
for ``lsof'' will yield the same results as searching for ``lsof''.
note: you must be the root user to install ports.
now that you have found a port you would like to install, you are ready to
do the actual installation. the port includes instructions on how to build
source code, but no actual source code. you can get the source code from a
cdrom 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 cdrom or from the internet.
----------------------------------------------------------------------
4.5.2.1 installing ports from a cdrom
the freebsd project's official cdrom images no longer include distfiles.
they take up a lot of room that is better used by precompiled packages.
cdrom products such as the freebsd powerpak do include distfiles, and you
can order these sets from a vendor such as the freebsd mall. this section
assumes you have such a freebsd cdrom set.
place your freebsd cdrom in the drive. mount it on /cdrom. (if you use a
different mount point, the install will not work.) to begin, change to the
directory for the port you want to install:
# cd /usr/ports/sysutils/lsof
once inside the lsof directory, you will see the port skeleton. the next
step is to compile (also called build) the port. this is done by simply
typing make at the prompt. once you have done so, you should see something
like this:
# make
>> lsof_4.57d.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> attempting to fetch from file:/cdrom/ports/distfiles/.
===> extracting for lsof-4.57
...
[extraction output snipped]
...
>> checksum ok for lsof_4.57d.freebsd.tar.gz.
===> patching for lsof-4.57
===> applying freebsd patches for lsof-4.57
===> configuring for lsof-4.57
...
[configure output snipped]
...
===> building for lsof-4.57
...
[compilation snipped]
...
#
take notice that once the compile is complete you are returned to your
prompt. the next step is to install the port. in order to install it, you
simply need to tack one word onto the make command, and that word is
install:
# make install
===> installing for lsof-4.57
...
[install routines snipped]
...
===> generating temporary packing list
===> compressing manual pages for lsof-4.57
===> registering installation for lsof-4.57
===> security note:
this port has installed the following binaries which execute with
increased privileges.
#
once you are returned to your prompt, you should be able to run the
application you just installed. since lsof is a program that runs with
increased privileges, a security warning is shown. during the building and
installation of ports, you should take heed of any other warnings that may
appear.
note: you can save an extra step by just running make install instead of
make and make install as two separate steps.
note: please be aware that the licenses of a few ports do not allow for
inclusion on the cdrom. this could be because a registration form needs
to be filled out before downloading, redistribution is not allowed, and
so on. if you wish to install a port not included on the cdrom, you will
need to be online in order to do so (see the next section).
----------------------------------------------------------------------
4.5.2.2 installing ports 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 perform the
cdrom installation.
installing a port from the internet is done exactly the same way as it
would be if you were installing from a cdrom. the only difference between
the two is that the port distfile is downloaded from the internet instead
of pulled from the cdrom.
the steps involved are identical:
# make install
>> lsof_4.57d.freebsd.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> attempting to fetch from
ftp://ftp.freebsd.org/pub/freebsd/ports/distfiles/.
receiving lsof_4.57d.freebsd.tar.gz (439860 bytes): 100%
439860 bytes transferred in 18.0 seconds (23.90 kbps)
===> extracting for lsof-4.57
...
[extraction output snipped]
...
>> checksum ok for lsof_4.57d.freebsd.tar.gz.
===> patching for lsof-4.57
===> applying freebsd patches for lsof-4.57
===> configuring for lsof-4.57
...
[configure output snipped]
...
===> building for lsof-4.57
...
[compilation snipped]
...
===> installing for lsof-4.57
...
[install routines snipped]
...
===> generating temporary packing list
===> compressing manual pages for lsof-4.57
===> registering installation for lsof-4.57
===> security note:
this port has installed the following binaries which execute with
increased privileges.
#
as you can see, the only difference is the line that tells you where the
system is fetching the port from.
that about does it for installing ports onto your system. in the next
section you will learn how to remove a port from your system.
----------------------------------------------------------------------
4.5.3 removing installed ports
now that you know how to install ports, you are probably wondering how to
remove them, just in case you install one and later on you decide that you
installed the wrong port. we will remove our previous example (which was
lsof for those of you not paying attention). as with installing ports, the
first thing you must do is change to the port directory,
/usr/ports/sysutils/lsof. after you change directories, you are ready to
uninstall lsof. this is done with the make deinstall command:
# cd /usr/ports/sysutils/lsof
# make deinstall
===> deinstalling for lsof-4.57
that was easy enough. you have removed lsof from your system. if you would
like to reinstall it, you can do so by running make reinstall from the
/usr/ports/sysutils/lsof directory.
the make deinstall and make reinstall sequence does not work once you have
run make clean. if you want to deinstall a port after cleaning, use
pkg_delete as discussed in the packages section of the handbook.
----------------------------------------------------------------------
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 they
were installed to. 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 foopackage
will find all the installed packages that have foopackage in the
package name. replace foopackage in your commandline 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 question files, 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
will often include a www: line with the url of the application's web
site.
----------------------------------------------------------------------
4.7 troubleshooting
the following sections cover some of the more frequently asked questions
about the ports collection and some basic troubleshooting techniques, and
what do to if a port is broken.
----------------------------------------------------------------------
4.7.1 some questions and answers
4.7.1.1. i thought this was going to be a discussion about modems??!
4.7.1.2. what is a patch?
4.7.1.3. what is all this about tarballs?
4.7.1.4. and a checksum?
4.7.1.5. i did what you said for compiling ports from a cdrom and it
worked great until i tried to install the kermit port.
4.7.1.6. i did that, but when i tried to put it into /usr/ports/distfiles
i got some error about not having permission.
4.7.1.7. does the ports scheme only work if you have everything in
/usr/ports? my system administrator says i must put everything under
/u/people/guests/wurzburger, but it does not seem to work.
4.7.1.8. i do not have a freebsd cdrom, but i would like to have all the
tarballs handy on my system so i do not have to wait for a download every
time i install a port. is there any way to get them all at once?
4.7.1.9. i know it is probably faster to fetch the tarballs from one of
the freebsd mirror sites close by. is there any way to tell the port to
fetch them from servers other than the ones listed in the master_sites?
4.7.1.10. i want to know what files make is going to need before it tries
to pull them down.
4.7.1.11. is there any way to stop the port from compiling? i want to do
some hacking on the source before i install it, but it is a bit tiresome
to watch it and hit ctrl+c every time.
4.7.1.12. i am trying to make my own port and i want to be able to stop it
compiling until i have had a chance to see if my patches worked properly.
is there something like make extract, but for patches?
4.7.1.13. i have heard that some compiler options can cause bugs. is this
true? how can i make sure that i compile ports with the right settings?
4.7.1.14. there are so many ports it is hard to find the one i want. is
there a list anywhere of what ports are available?
4.7.1.15. i went to install the foo port but the system suddenly stopped
compiling it and starting compiling the bar port. what is going on?
4.7.1.16. i installed the grizzle program from the ports and frankly it is
a complete waste of disk space. i want to delete it but i do not know
where it put all the files. any clues?
4.7.1.17. hang on a minute, you have to know the version number to use
that command. you do not seriously expect me to remember that, do you?
4.7.1.18. talking of disk space, the ports directory seems to be taking up
an awful lot of room. is it safe to go in there and delete things?
4.7.1.19. i tried that and it still left all those tarballs or whatever
you called them in the distfiles directory. can i delete those as well?
4.7.1.20. i like having lots and lots of programs to play with. is there
any way of installing all the ports in one go?
4.7.1.21. ok, i tried that, but i thought it would take a very long time
so i went to bed and left it to get on with it. when i looked at the
computer this morning, it had only done three and a half ports. did
something go wrong?
4.7.1.22. i really do not want to spend all day staring at the monitor.
any better ideas?
4.7.1.23. at work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do what we
need. is there any way of making our own packages, so we can distribute it
more easily around our sites?
4.7.1.24. this ports stuff is really clever. i am desperate to find out
how you did it. what is the secret?
4.7.1.1. i thought this was going to be a discussion about modems??!
ah, you must be thinking of the serial ports on the back of your computer.
we are using ``port'' here to mean the result of ``porting'' a program
from one version of unix to another.
4.7.1.2. what is a patch?
a patch is a small file that specifies how to go from one version of a
file to another. it contains plain text, and basically says things like
``delete line 23'', ``add these two lines after line 468'', or ``change
line 197 to this''. they are also known as diffs because they are
generated by the diff program.
4.7.1.3. what is all this about tarballs?
it is a file ending in .tar, or with variations such as .tar.gz, .tar.z,
.tar.bz2, and even .tgz.
basically, it is a directory tree that has been archived into a single
file (.tar) and optionally compressed (.gz). this technique was originally
used for tape archives (hence the name tar), but it is a widely used way
of distributing program source code around the internet.
you can see what files are in them, or even extract them yourself by using
the standard unix tar program, which comes with the base freebsd system,
like this:
% tar tvzf foobar.tar.gz
% tar xzvf foobar.tar.gz
% tar tvf foobar.tar
% tar xvf foobar.tar
4.7.1.4. and a checksum?
it is a number generated by adding up all the data in the file you want to
check. if any of the characters change, the checksum will no longer be
equal to the total, so a simple comparison will allow you to spot the
difference.
4.7.1.5. i did what you said for compiling ports from a cdrom and it
worked great until i tried to install the kermit port.
# make install
>> cku190.tar.gz doesn't seem to exist on this system.
>> attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/.
why can it not be found? have i got a dud cdrom?
as explained in the compiling ports from cdrom section, some ports cannot
be put on the cdrom set due to licensing restrictions. kermit is an
example of that. the licensing terms for kermit do not allow us to put the
tarball for it on the cdrom, so you will have to fetch it by hand--sorry!
the reason why you got all those error messages was because you were not
connected to the internet at the time. once you have downloaded it from
any of the master_sites (listed in the makefile), you can restart the
install process.
4.7.1.6. i did that, but when i tried to put it into /usr/ports/distfiles
i got some error about not having permission.
the ports mechanism will download distribution tarballs into
/usr/ports/distfiles, but many system administrators will symlink this
directory to a remote file server or local read-only cdrom media. if this
is the case, then you should specify a different directory to be used for
storing distfiles with the following command:
# make distdir=/local/dir/with/write/permission install
4.7.1.7. does the ports scheme only work if you have everything in
/usr/ports? my system administrator says i must put everything under
/u/people/guests/wurzburger, but it does not seem to work.
you can use the portsdir and prefix variables to tell the ports mechanism
to use different directories. for instance,
# make portsdir=/u/people/guests/wurzburger/ports install
will compile the port in /u/people/guests/wurzburger/ports and install
everything under /usr/local.
# make prefix=/u/people/guests/wurzburger/local install
will compile it in /usr/ports and install it in
/u/people/guests/wurzburger/local.
and of course,
# make portsdir=../ports prefix=../local install
will combine the two (it is too long to write fully on the page, but it
should give you the general idea).
some ports that use imake(1) (a part of the x windows 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 ports respect prefix is a difficult or impossible job.
if you do not fancy typing all that in every time you install a port, it
is a good idea to put these variables into your environment. read the
manual page for your shell for instructions on doing so.
4.7.1.8. i do not have a freebsd cdrom, but i would like to have all the
tarballs handy on my system so i do not have to wait for a download every
time i install a port. is there any way to get them all at once?
to get every single tarball for the ports collection, do:
# cd /usr/ports
# make fetch
for all the tarballs for a single ports directory, do:
# cd /usr/ports/directory
# make fetch
and for just one port--well, you have probably guessed already.
4.7.1.9. i know it is probably faster to fetch the tarballs from one of
the freebsd mirror sites close by. is there any way to tell the port to
fetch them from servers other than the ones listed in the master_sites?
yes. if you know, for example, that ftp.freebsd.org is much closer to you
than the sites listed in master_sites, do as follows:
# cd /usr/ports/directory
# make master_site_override= \
ftp://ftp.freebsd.org/pub/freebsd/ports/distfiles/ fetch
4.7.1.10. i want to know what files make is going to need before it tries
to pull them down.
make fetch-list will display a list of the files needed for a port.
4.7.1.11. is there any way to stop the port from compiling? i want to do
some hacking on the source before i install it, but it is a bit tiresome
to watch it and hit ctrl+c every time.
doing make extract will stop it after it has fetched and extracted the
source code.
4.7.1.12. i am trying to make my own port and i want to be able to stop it
compiling until i have had a chance to see if my patches worked properly.
is there something like make extract, but for patches?
yes, make patch is what you want. you will probably find the patch_debug
option useful as well. and by the way, thank you for your efforts!
4.7.1.13. i have heard that some compiler options can cause bugs. is this
true? how can i make sure that i compile ports with the right settings?
yes, with version 2.6.3 of gcc (the version shipped with freebsd 2.1.0 and
2.1.5), the -o2 option could result in buggy code unless you used the
-fno-strength-reduce option as well. (most of the ports do not use -o2).
you should be able to specify the compiler options used by something like:
# make cflags='-o2 -fno-strength-reduce' install
or by editing /etc/make.conf, but unfortunately not all ports respect
this. the surest way is to do make configure, then go into the source
directory and inspect the makefiles by hand, but this can get tedious if
the source has lots of sub-directories, each with their own makefiles.
the default freebsd compiler options are quite conservative, so if you
have not changed them you should not have any problems.
4.7.1.14. there are so many ports it is hard to find the one i want. is
there a list anywhere of what ports are available?
look in the index file in /usr/ports. if you would like to search the
ports collection for a keyword, you can do that too. for example, you can
find ports relevant to the lisp programming language using:
% cd /usr/ports
% make search key=lisp
4.7.1.15. i went to install the foo port but the system suddenly stopped
compiling it and starting compiling the bar port. what is going on?
the foo port needs something that is supplied with bar -- for instance, if
foo uses graphics, bar might have a library with useful graphics
processing routines. or bar might be a tool that is needed to compile the
foo port.
4.7.1.16. i installed the grizzle program from the ports and frankly it is
a complete waste of disk space. i want to delete it but i do not know
where it put all the files. any clues?
no problem, just type:
# pkg_delete grizzle-6.5
alternatively, you can type:
# cd /usr/ports/somewhere/grizzle
# make deinstall
4.7.1.17. hang on a minute, you have to know the version number to use
that command. you do not seriously expect me to remember that, do you?
not at all, you can find it out by doing:
# pkg_info -i 'grizzle*'
information for grizzle-6.5:
grizzle-6.5 - the combined piano tutorial, logo interpreter and shoot 'em up
arcade game.
the version number can also be found using the pkg_info or by typing: ls
/var/db/pkg
4.7.1.18. talking of disk space, the ports directory seems to be taking up
an awful lot of room. is it safe to go in there and delete things?
yes, if you have installed the program and are fairly certain you will not
need the source again, there is no point in keeping it hanging around. the
surest way to do this is:
# cd /usr/ports
# make clean
which will go through all the ports subdirectories and delete everything
except the skeletons for each port.
tip: it is possible to achieve the same effect without recursively
calling each makefile. for example, you can delete all of the work/
subdirectories directly with the following command:
# find /usr/ports -depth -name work -exec rm -rf {} \;
4.7.1.19. i tried that and it still left all those tarballs or whatever
you called them in the distfiles directory. can i delete those as well?
yes, if you are sure you have finished with them, those can go as well.
they can be removed manually, or by using make distclean.
4.7.1.20. i like having lots and lots of programs to play with. is there
any way of installing all the ports in one go?
just do:
# cd /usr/ports
# make install
be careful, as some ports may install files with the same name. if you
install two graphics ports and they both install /usr/local/bin/plot then
you will obviously have problems.
4.7.1.21. ok, i tried that, but i thought it would take a very long time
so i went to bed and left it to get on with it. when i looked at the
computer this morning, it had only done three and a half ports. did
something go wrong?
no, the problem is that some of the ports need to ask you questions that
we cannot answer for you (e.g., ``do you want to print on a4 or us letter
sized paper?'') and they need to have someone on hand to answer them.
4.7.1.22. i really do not want to spend all day staring at the monitor.
any better ideas?
ok, do this before you go to bed/work/the local park:
# cd /usr/ports
# make -dbatch install
this will install every port that does not require user input. then, when
you come back, do:
# cd /usr/ports
# make -dinteractive install
to finish the job.
4.7.1.23. at work, we are using frobble, which is in your ports
collection, but we have altered it quite a bit to get it to do what we
need. is there any way of making our own packages, so we can distribute it
more easily around our sites?
no problem, assuming you know how to make patches for your changes:
# cd /usr/ports/somewhere/frobble
# make extract
# cd work/frobble-2.8
[apply your patches]
# cd ../..
# make package
4.7.1.24. this ports stuff is really clever. i am desperate to find out
how you did it. what is the secret?
nothing secret about it at all, just look at the bsd.port.mk and
bsd.port.subdir.mk files in /usr/ports/mk/.
(readers with an aversion to intricate shell-scripts are advised not to
look at the files in this directory.)
----------------------------------------------------------------------
4.7.2 help! this port is broken!
if you come across a port that does not work for you, there are a few
things you can do, including:
#1. fix it! the porter's handbook includes detailed information on the
"ports" infrastructure so that you can fix the occasional broken port
or even submit your own!
#2. gripe--by email only! send email to the maintainer of the port first.
type make maintainer or read the makefile to find the maintainer's
email address. remember to include the name and version of the port
(send the $freebsd: 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 use send-pr to submit a bug
report.
#3. grab the package from an ftp site near you. the ``master'' package
collection is on ftp.freebsd.org in the packages directory, but be
sure to check your local mirror first! 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
freebsd 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 freebsd system. for more information on xfree86 and video hardware
that it supports, check the xfree86 web site.
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 fonts in xfree86.
* how to setup 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 macos.
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(1) 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 macos, and there are various free and
commercial applications available that do exactly that.
the x server that ships with freebsd is called xfree86, and is available
for free, under a license very similar to the freebsd license. commercial
x servers for freebsd are also available.
----------------------------------------------------------------------
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 to
should use 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 x11-wm category of the ports collection.
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
that 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 macos 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 (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
before installing xfree86, decide on which version to run. xfree86 3.x is
a maintenance branch of xfree86 development. it is very stable, and it
supports a huge number of graphics cards. however, no new development is
being done on the software. xfree86 4.x is a complete redesign of the
system with many new features such as better support for fonts and
anti-aliasing. unfortunately this new architecture requires that the video
drivers be rewritten, and some of the older cards that were supported in
3.x are not yet supported in 4.x.
the freebsd setup program offers users the opportunity to install and
configure xfree86 3.3.6 during installation (covered in section 2.9.11).
to run xfree86 4.x, wait until after the base freebsd system is installed,
and then install xfree86. for example, to build and install xfree86 4.x
from the ports collection:
# cd /usr/ports/x11/xfree86-4
# make all install clean
alternatively, xfree86 4.x can be installed from a binary package with the
pkg_add tool or directly from the freebsd binaries provided on the xfree86
web site.
the rest of this chapter will explain how to configure xfree86, and how to
setup 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 current
working directory called xf86config.new. 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.
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' 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. 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.
to run at a resolution of one thousand twenty-four pixels by seven hundred
sixty-eight pixels at twenty-four bits per pixel, add the defaultdepth
keyword with the value of twenty-four, and add to the "display" subsection
with the desired depth the modes keyword with the resolution the user
wishes to run at. note that only vesa standard modes are supported as
defined by the target system's graphics hardware.
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).
----------------------------------------------------------------------
5.4.3 advanced configuration topics
5.4.3.1 configuration with intel i810 graphics chipsets
configuration with intel i810 integrated chipsets requires the agpgart agp
programming interface for xfree86 to drive the card. to use agpgart, the
agp.ko kernel loadable module needs to be loaded into the kernel with
kldload(8). this can be done automatically with the loader(8) at boot
time. 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.
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 config 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) 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, helvetica, palatino and others). the freefont
collection (x11-fonts/freefont) 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 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; 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.
# 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, 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
starting with version 4.0.2, xfree86 supports anti-aliased fonts.
currently, most software has not been updated to take advantage of this
new functionality. however, qt (the toolkit for the kde desktop) does; so
if xfree86 4.0.2 is used (or higher), qt 2.3 (or higher) and kde, all
kde/qt applications can be made to use anti-aliased fonts.
to configure anti-aliasing, create (or edit, if it already exists) the
file /usr/x11r6/lib/x11/xftconfig. several advanced things can be done
with this file; this section describes only the simplest possibilities.
first, tell the x server about the fonts that are to be anti-aliased. for
each font directory, add a line similar to this:
dir "/usr/x11r6/lib/x11/type1"
likewise for the other font directories (urw, truetype, etc) containing
fonts to be anti-aliased. anti-aliasing makes sense only for scalable
fonts (basically, type1 and truetype) so do not include bitmap font
directories here. the directories included here can now be commented out
of the xf86config file.
antialiasing 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 between 9 and
13 from anti-aliasing, include these lines:
match
any size > 8
any size < 14
edit
antialias = false;
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 any family == "fixed" edit family =+ "mono";
match any family == "console" edit family =+ "mono";
(this aliases the other common names for fixed fonts as "mono"), and then
add:
match any family == "mono" edit spacing = 100;
supposing the lucidux fonts as desired whenever monospaced fonts are
required (these look nice, and do not seem to suffer from the spacing
problem), replace that last line with these:
match any family == "mono" edit family += "luciduxmono";
match any family == "lucidux mono" edit family += "luciduxmono";
match any family == "luciduxmono" edit family =+ "lucidux mono";
(the last lines alias different equivalent family names).
finally, it is nice to allow users to add commands to this file, via their
personal .xftconfig files. to do this, add a last line:
includeif "~/.xftconfig"
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 xftconfig
file
match edit rgba=rgb;
(depending on the sort of display, the last word may need to be changed
from from ``rgb'' 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, note that programs must know how to take advantage of it. at the
present time, the toolkit qt does, so the entire kde environment can use
anti-aliased fonts (see section 5.7.3.2 on kde for details); there are
patches for gtk+ to do the same, so if compiled against such a patched
gtk+, the gnome environment and mozilla can also use anti-aliased fonts.
in fact, there is now a port called x11/gdkxft which allows one to use
antialiased fonts without recompiling: see section 5.7.1.3 for details.
anti-aliasing is still new to freebsd and xfree86; configuring it should
get easier with time, and it will soon be supported by many more
applications.
----------------------------------------------------------------------
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 15.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 15.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 field 5
from off to on and restart init(8) using the directions in section
15.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 setup 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
~/.xsessionrc 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 freebsd. 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 through the ``desktop configuration''
menu during the freebsd installation process as described in chapter 2. it
can also be easily installed from a package or the ports collection:
to install the gnome package from the network, simply type:
# pkg_add -r gnome
to build gnome from source, use the ports tree:
# cd /usr/ports/x11/gnome
# 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 kde2 details explains how to
do this for kdm, the display manager of kde.
----------------------------------------------------------------------
5.7.1.3 anti-aliased fonts with gnome
while anti-aliased fonts made their first appearance on xfree86 desktops
in the kde environment and are supported there in the standard
installation, it is also possible to use them with gtk applications such
as the gnome environment. the most straightforward way is probably by
using the libgdkxft library, in the x11/gdkxft port. after installing this
port, read the /usr/x11r6/share/doc/gdkxft/readme file carefully.
then, all that is needed is to tell gtk applications to look for their
font-rendering functions in libgdkxft.so before looking in the standard
place, libgdk.so. this is easily accomplished by setting an environment
variable to point to the right place; with the bourne shell (/bin/sh) or
similar shells, type the command (to start the gimp, say)
% ld_preload=/usr/x11r6/lib/libgdkxft.so gimp
and with csh and similar shells, type
% setenv ld_preload /usr/x11r6/lib/libgdkxft.so
% gimp
or, the commands
ld_preload=/usr/x11r6/lib/libgdkxft.so
export ld_preload
can be put into .xinitrc, .xsession or in the appropriate place(s) in
/usr/x11r6/lib/x11/xdm/xsession, depending on how x is normally started.
however, this short-cut may cause problems if linux gtk binaries are run.
----------------------------------------------------------------------
5.7.2 kde2
5.7.2.1 about kde2
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 kde2
just as with gnome or any other desktop environment, the easiest way to
install kde is through the ``desktop configuration'' menu during the
freebsd installation process as described in chapter 2. once again, the
software can be easily installed from a package or from the ports
collection:
to install the kde2 package from the network, simply type:
# pkg_add -r kde2
to build kde from source, use the ports tree:
# cd /usr/ports/x11/kde2
# make install clean
after kde2 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 "/usr/local/bin/startkde" > ~/.xinitrc
now, whenever the x window system is invoked with startx, kde2 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 kde2
now that kde2 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 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 (kde2, gnome, or
something else) to run after logging on.
to begin with, run the kde2 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 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 ``kde2'' 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 kde2 desktop. just go to the kde2 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 app 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 -r xfce
alternatively, to build from source, use the ports collection:
# cd /usr/ports/x11-wm/xfce
# make install clean
now, tell the x server to launch xfce the next time x is started. simply
type this:
% echo "/usr/x11r6/bin/startxfce" > ~/.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/startxfce 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 freebsd handbook cover all aspects of
freebsd 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 freebsd.
table of contents
6 configuration and tuning
7 the freebsd booting process
8 users and basic account management
9 configuring the freebsd kernel
10 security
11 printing
12 storage
13 localization - i18n/l10n usage and setup
14 sound
15 serial communications
16 ppp and slip
17 advanced networking
18 electronic mail
19 the cutting edge
20 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
configuring a system correctly can substantially reduce the amount of work
involved in maintaining and upgrading it in the future. this chapter
describes some of the aspects of administrative configuration of freebsd
systems.
this chapter will also describe some of the parameters that can be set to
tune a freebsd system for optimum performance.
after reading this chapter, you will know:
* why and how to efficiently size, layout, and place filesystems and
swap partitions on your hard drive.
* the basics of the rc.conf configuration and /usr/local/etc/rc.d
startup systems.
* how to configure virtual hosts on your network devices.
* how to use the various configuration files in /etc.
* how to tune freebsd using sysctl variables.
* how to tune disk performance and modify kernel limitations.
before reading this chapter, you should:
* understand the basics of unix and freebsd (chapter 3).
* be familiar with keeping freebsd sources up to date (chapter 19), and
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 your filesystem with disklabel(8) or sysinstall(8), it is
important to remember that hard drives can transfer data at a faster rate
from the outer tracks than the inner. knowing this, you should place your
smaller, heavily-accessed filesystems, such as root and swap, closer to
the outside of the drive, while placing larger partitions, such as /usr,
towards the inner. to do so, it is a good idea to create partitions in a
similar order: root, swap, /var, /usr.
the size of your /var partition reflects the intended use of your machine.
/var is primarily used to hold mailboxes, log files, and printer spools.
mailboxes and log files, in particular, can grow to unexpected sizes based
upon how many users are on your system and how long your log files are
kept. if you intend to run a mail server, a /var partition of over a
gigabyte can be suitable. additionally, /var/tmp must be large enough to
contain any packages you may wish to add.
the /usr partition holds the bulk of the files required to support the
system and a subdirectory within it called /usr/local holds the bulk of
the files installed from the ports(7) hierarchy. if you do not use ports
all that much and do not intend to keep system source (/usr/src) on the
machine, you can get away with a 1 gigabyte /usr partition. however, if
you install a lot of ports (especially window managers and linux
binaries), we recommend at least a two gigabyte /usr and if you also
intend to keep system source on the machine, we recommend a three gigabyte
/usr. do not underestimate the amount of space you will need in this
partition, it can creep up and surprise you!
when sizing your partitions, keep in mind the space requirements for your
system to grow. running out of space in one partition while having plenty
in another can lead to much frustration.
note: some users who have used sysinstall(8)'s auto-defaults partition
sizer have found either their root or /var partitions too small later
on. partition wisely and generously.
----------------------------------------------------------------------
6.2.1.2 swap partition
as a rule of thumb, your swap space should typically be double the amount
of main memory. for example, if the machine has 128 megabytes of memory,
the swap file should be 256 megabytes. systems with lesser memory may
perform better with a lot more swap. it is not recommended that you
configure any less than 256 megabytes of swap on a system and you should
keep in mind future memory expansion when sizing the swap partition. 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 as
well as create issues later on if you add more memory to your machine.
finally, on larger systems with multiple scsi disks (or multiple ide disks
operating on different controllers), it is strongly recommend that you
configure swap on each drive (up to four drives). the swap partitions on
the drives 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 the disks. do not worry
about overdoing it a little, swap space is the saving grace of unix. even
if you do not normally use much swap, it can give you more time to recover
from a runaway program before being forced to reboot.
----------------------------------------------------------------------
6.2.1.3 why partition?
why partition at all? why not create one big root partition and be done
with it? then i do not have to worry about undersizing things!
there are several reasons this is not a good idea. first, each partition
has different operational characteristics and separating them allows the
filesystem to tune itself to those characteristics. for example, the root
and /usr partitions are read-mostly, with very little writing, while a lot
of reading and writing could occur in /var and /var/tmp.
by properly partitioning your system, fragmentation introduced in the
smaller more heavily write-loaded partitions will not bleed over into the
mostly-read partitions. additionally, keeping the write-loaded partitions
closer to the edge of the disk, for example before the really big
partition instead of after in the partition table, will increase i/o
performance in the partitions where you need it the most. now it is true
that you might also need i/o performance in the larger partitions, but
they are so large that shifting them more towards the edge of the disk
will not lead to a significant performance improvement whereas moving /var
to the edge can have a huge impact. finally, there are safety concerns.
having a small, neat root partition that is essentially read-only gives it
a greater chance of surviving a bad crash intact.
----------------------------------------------------------------------
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 sysinstall(8) or 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 filesize difference shows 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
this script is called with start at startup, and the stop at shutdown to
allow it to carry out its purpose.
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. as of freebsd 3.1 there is no default
/etc/rc.local; if it is created by the administrator it will however be
honored in the normal fashion. 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 virtual hosts
a very common use of freebsd 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 1's.
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.
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.7 configuration files
6.7.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 the boot
file is located here, and contains a directive to
refer to other data in /var/db.
/usr/local/etc configuration files for installed applications. may
contain per-application subdirectories.
/usr/local/etc/rc.d start/stop scripts for installed applications.
/var/db persistent system-specific data files, such as
named(8) zone files, database files, and so on.
----------------------------------------------------------------------
6.7.2 hostnames
----------------------------------------------------------------------
6.7.2.1 /etc/resolv.conf
/etc/resolv.conf dictates how freebsd's resolver accesses the internet
domain name system (dns).
the most common entries to resolv.conf are:
nameserver the ip address of a name server the resolver should query. the
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.7.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.
# $freebsd$
#
# 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.7.3 log file configuration
----------------------------------------------------------------------
6.7.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.
# $freebsd$
#
# 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.7.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
# $freebsd$
#
# 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.7.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 freebsd.
kern.logsigexit=0 # do not log fatal signal exits (e.g. sig 11)
compat.linux.osname=freebsd
compat.linux.osrelease=4.3-stable
----------------------------------------------------------------------
6.8 tuning with sysctl
sysctl(8) is an interface that allows you to make changes to a running
freebsd 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).
----------------------------------------------------------------------
6.9 tuning disks
6.9.1 sysctl variables
6.9.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 1k) in the filesystem and less (typically 512 bytes)
in the buffer cache. however, when operating in the default mode the
buffer cache will only cache a fixed number of directories even if you
have a huge amount of memory. turning on 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 4k)
rather than 512 bytes. we recommend turning 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.
turning on this option will generally not reduce performance even with the
wasted memory but you should experiment to find out.
----------------------------------------------------------------------
6.9.1.2 hw.ata.wc
freebsd 4.3 flirted with turning off ide write caching. this reduced write
bandwidth to ide disks but was considered necessary due to serious data
consistency issues introduced by hard drive vendors. the problem is that
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 filesystem corruption.
freebsd's default was changed to be safe. unfortunately, the result was
such a huge performance loss that we changed write caching back to on by
default after the release. you should check the default on your system by
observing the hw.ata.wc sysctl variable. if ide write caching is turned
off, you can turn it back on by setting the kernel variable back to 1.
this 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).
----------------------------------------------------------------------
6.9.2 soft updates
the tunefs(8) program can be used to fine-tune a filesystem. 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: as of freebsd 4.5, 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
turning soft updates on on all of your filesystems. 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.9.2.1 more details about soft updates
there are two traditional approaches to writing a filesystem's meta-data
back to disk. (meta-data updates are updates to non-content data like
inodes or directories.)
historically, the default behaviour 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 file
system will be left in an unpredictable state. there is no opportunity to
examine the state of the file system 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 newfs 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. this is the idea
behind the background fsck: at system startup time, only a snapshot of the
filesystem is recorded. the fsck can be run later on. all filesystems can
then be mounted ``dirty'', so the system startup proceeds in multiuser
mode. then, background fscks will be scheduled for all filesystems where
this is required, to free resources that may be unused. (filesystems that
do not use soft updates still need the usual foreground fsck though.)
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.10 tuning kernel limits
----------------------------------------------------------------------
6.10.1 file/process limits
6.10.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 as
once, the resources needed may be similar to a high-scale web server.
note: as of freebsd 4.5, 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.
----------------------------------------------------------------------
6.10.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 freebsd's ability. each cluster represents
approximately 2k 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 16k
receive and 16k send buffer, you need approximately 32mb worth of network
buffers to cover the web server. a good rule of thumb is to multiply by 2,
so 32mbx2 = 64mb/2k = 32768.
----------------------------------------------------------------------
6.11 adding swap space
no matter how well you plan, sometimes a system doesn't run as you expect.
if you find you need more swap space, it's 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.11.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 of swap space from the initial
configuration section of the handbook for some suggestions on how to best
arrange your swap.
----------------------------------------------------------------------
6.11.2 swapping over nfs
swapping over nfs is only recommended if you do not have a local hard disk
to swap to. swapping over nfs is slow and inefficient in versions of
freebsd prior to 4.x. it is reasonably fast and efficient in 4.0-release
and newer. even with newer versions of freebsd, nfs swapping will be
limited by the available network bandwidth and puts an additional burden
on the nfs server.
----------------------------------------------------------------------
6.11.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
----------------------------------------------------------------------
chapter 7 the freebsd 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''. freebsd'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 freebsd boot process. this includes everything that happens
until the freebsd 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 freebsd bootstrap system are, and how they
interact.
* the options you can give to the components in the freebsd bootstrap to
control the boot process.
x86 only: this chapter only describes the boot process for freebsd
running on intel 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.
if you only have one operating system installed on your disks then the
standard mbr will suffice. this mbr searches for the first bootable slice
on the disk, and then runs the code on that slice to load the remainder of
the operating system.
if you have installed multiple operating systems on your disks then you
can install a different mbr, one that can display a list of different
operating systems, and allows you to choose the one to boot from. freebsd
comes with one such mbr which can be installed, and other operating system
vendors also provide alternative mbrs.
the remainder of the freebsd 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 freebsd 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 filesystems, sets up network cards to
communicate on the network, and generally starts all the processes that
usually are run on a freebsd system at startup.
----------------------------------------------------------------------
7.3 the mbr, and boot stages one, two, and three
7.3.1 mbr, /boot/boot0
the freebsd mbr is located in /boot/boot0. this is a copy of the mbr, as
the real mbr must be placed on a special part of the disk, outside the
freebsd area.
boot0 is very simple, since the program in the mbr can only be 512 bytes
in size. if you have installed the freebsd mbr and have installed 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 95, 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 freebsd 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.
if you are a linux user, however, and prefer that lilo control the boot
process, you can edit the /etc/lilo.conf file for freebsd, or select leave
the master boot record untouched during the freebsd installation process.
if you have installed the the freebsd boot manager, you can boot back into
linux and modify the lilo configuration file /etc/lilo.conf and add the
following option:
other=/dev/hdxy
table=/dev/hdb
loader=/boot/chain.b
label=freebsd
which will permit the booting of freebsd and linux via lilo. in our
example, we use xy to determine drive number and partition. if you are
using a scsi drive, you will want to change /dev/hdxy to read something
similar to /dev/sdxy, which again uses the xy syntax. the
loader=/boot/chain.b can be omitted if you have both operating systems on
the same drive. you can now run /sbin/lilo -v to commit your new changes
to the system, this should be verified with 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 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 freebsd filesystem.
boot1 is very simple, since it too can only be 512 bytes in size, and
knows just enough about the freebsd disklabel, which stores information
about the slice, to find and execute boot2.
boot2 is slightly more sophisticated, and understands the freebsd
filesystem 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
>> freebsd/i386 boot
default: 0:ad(0,a)/kernel
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.
dangerously dedicated mode: if you use just the disk name, such as ad0,
in the disklabel(8) command you will create a dangerously dedicated
disk, without slices. this is almost certainly not what you want to do,
so make sure you double check the disklabel(8) command before you press
return.
----------------------------------------------------------------------
7.3.3 stage three, /boot/loader
the loader is the final stage of the three-stage bootstrap, and is located
on the filesystem, 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, 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 filesystems available on
the system are consistent. if they are not, and fsck cannot fix the
inconsistencies, init 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 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 finds your filesystems 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 filesystems 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, init 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.
----------------------------------------------------------------------
chapter 8 users and basic account management
contributed by neil blakey-milner.
8.1 synopsis
freebsd 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 [2], 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 freebsd 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 freebsd (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
freebsd systems.
every account on a freebsd 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 from 0 to 65536 used to uniquely identify the
user to the system. internally, freebsd uses the uid to identify
users--any freebsd 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 freebsd 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 from 0 to 65536 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 freebsd 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 freebsd 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 freebsd, 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 | the recommended command-line application for adding new |
| | users. |
|---------+--------------------------------------------------------------|
| rmuser | the recommended command-line application for removing users. |
|---------+--------------------------------------------------------------|
| chpass | a flexible tool to change user database information. |
|---------+--------------------------------------------------------------|
| passwd | the simple command-line tool to change user passwords. |
|---------+--------------------------------------------------------------|
| pw | a powerful and flexible tool to modify all aspects of user |
| | accounts. |
+------------------------------------------------------------------------+
----------------------------------------------------------------------
8.6.1 adduser
adduser 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.
[3] next, we configure adduser defaults, and create our first user
account, since using root for normal usage is evil and nasty.
example 8-1. configuring adduser
# 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 the ports collection), 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 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 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 to completely remove a user from the system. rmuser
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 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/tcsh
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 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.
when passed no options, aside from an optional username, chpass 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 [#]: 1000
gid [# or name]: 1000
change [month day year]:
expire [month day year]:
class:
home directory: /home/jru
shell: /usr/local/bin/tcsh
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/tcsh
full name: j. random user
office location:
office phone:
home phone:
other information:
note: chfn and chsh are just links to chpass, as are ypchpass, ypchfn,
and ypchsh. 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 17
----------------------------------------------------------------------
8.6.4 passwd
passwd is the usual way to change your own password as a user, or another
user's password as the superuser.
note: users must type in their original password before changing their
password, to prevent an unauthorized person from changing their password
when the user is away from their console.
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, yppasswd is just a link to passwd, 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 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 run a multi-user system, chances are that you do not trust all of
your users not to damage your system. freebsd provides a number of ways a
system administrator can limit the amount of system resources an
individual user can use. these limits are generally divided into two
sections: disk quotas, and other resource limits.
disk quotas are a way for the system administrator to tell the filesystem
the amount of disk space a user may use; moreover, they provide a way to
quickly check on the disk usage of a user without having to calculate it
every time. quotas are discussed in section 12.5.
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: a compiler--probably a legitimate
task--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. 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
freebsd, 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.
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 freebsd (and most other unix 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 freebsd kernel
updated and restructured by jim mock. originally contributed by jake
hamby.
9.1 synopsis
the kernel is the core of the freebsd operating system. it is responsible
for managing memory, enforcing security controls, networking, disk access,
and much more. while more and more of freebsd 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, freebsd 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, freebsd 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 in to the kernel that was
not necessary when the kernel was originally compiled. 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 freebsd 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, alpha, or pc98 (an
alternative development branch of pc hardware, popular in japan).
everything inside a particular architecture's directory deals with that
architecture only; the rest of the code is common to all platforms to
which freebsd could potentially be ported. notice the logical organization
of the directory structure, with each supported device, filesystem, 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 by
running /stand/sysinstall as root, choosing configure, then
distributions, then src, then sys. if you have an aversion to sysinstall
and you have access to an ``official'' freebsd cdrom, then you can also
install the source from the command line:
# mount /cdrom
# mkdir -p /usr/src/sys
# ln -s /usr/src/sys /sys
# cat /cdrom/sys/ssys.[a-d]* | tar -xzvf
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 freebsd 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.
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, freebsd 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 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 freebsd project. in this file all important issues
with updating freebsd are written down. /usr/src/updating always fits to
your version of the freebsd source, and is therefore more accurate for
those information than the handbook.
you must now compile the source code for the kernel. there are two
procedures you can use to do this, and the one you will use depends on why
you are rebuilding the kernel, and the version of freebsd you are running.
* if you have installed only the kernel source code, use procedure 1.
* if you are running a freebsd version prior to 4.0, and you are not
upgrading to freebsd 4.0 or higher using the make world procedure, use
procedure 1.
* if you are building a new kernel without updating the source code
(perhaps just to add a new option, such as ipfirewall) you can use
either procedure.
* if you are rebuilding the kernel as part of a make world process, use
procedure 2.
procedure 1. building a kernel the ``traditional'' way
#1. run config(8) to generate the kernel source code.
# /usr/sbin/config mykernel
#2. change in to the build directory.
# cd ../../compile/mykernel
#3. compile the kernel.
# make depend
# make
#4. install the new kernel.
# make install
procedure 2. building a kernel the ``new'' way
#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
note: in freebsd 4.2 and older you must replace kernconf= with kernel=.
4.2-stable that was fetched after feb 2nd, 2001 does recognize
kernconf=.
if you have not upgraded your source tree in any way (you have not run
cvsup, ctm, or used anoncvs), then you should use the config, make depend,
make, make install 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 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" 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.
quoting numbers: in all versions of freebsd up to and including 3.x,
config(8) required that any strings in the configuration file that
contained numbers used as text had to be enclosed in double quotes.
this requirement was removed in the 4.x branch, which this book covers,
so if you are on a pre-4.x system, see the /usr/src/sys/i386/conf/lint
and /usr/src/sys/i386/conf/generic files on your system for examples.
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 freebsd/i386
#
# for more information on this file, please read the handbook section on
# kernel configuration files:
#
# http://www.freebsd.org/handbook/kernelconfig-config.html
#
# the handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# freebsd world wide web server (http://www.freebsd.org/) for the
# latest information.
#
# an exhaustive list of options and more detailed explanations of the
# device lines is also present in the ./lint configuration file. if you are
# in doubt as to the purpose or necessity of a line, check first in lint.
#
# $freebsd: src/sys/i386/conf/generic,v 1.246 2000/03/09 16:32:55 jlemon exp
$
the following are the mandatory keywords required in every kernel you
build:
machine i386
this is the machine architecture. it must be either i386, alpha, or pc98.
cpu i386_cpu
cpu i486_cpu
cpu i586_cpu
cpu i686_cpu
the above 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 use the dmesg command to view your boot up messages.
the alpha architecture has different values for cpu. they include:
cpu ev4
cpu ev5
if you are using an alpha machine, you should be using one of the above
cpu types.
ident generic
this is the identification of the kernel. you should change this to
whatever you named your kernel, as in our previous example, mykernel. 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.
starting with freebsd 4.5, the system will auto-tune this setting for you
if you explicitly set it to 0[4]. if you are using an earlier version of
freebsd, or 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 (like ftp.freebsd.org), 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 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 freebsd, 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
pseudo-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
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
freebsd 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 some code to speed up disk operations on large
directories, at the expense of using a some additional memory. you would
normally keep this for a large server, or interactive workstation, and
remove it if you are using freebsd 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. they are enabled by default in the 4.x branch
but may not be turned on. review the output from mount(8) to see if you
have them enabled. if you do not see the soft-updates option then you will
need to activate it using the tunefs(8) or newfs(8) for new filesystems.
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 the ports
collection) 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 5
seconds, to speed up booting. of course, if you do this, and freebsd 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, talk, 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 visual configuration editor from the
boot menu.
options ktrace #ktrace(1) support
this enables kernel process tracing, which is useful in debugging.
options sysvshm #sysv-style shared memory
this option provides for system v shared memory. the most common use of
this is the xshm extension in x, which many graphics-intensive programs
will automatically take advantage of for extra speed. if you use x, you
will definitely want to include this.
options sysvsem #sysv-style semaphores
support for system v semaphores. less commonly used but only adds a few
hundred bytes to the kernel.
options sysvmsg #sysv-style message queues
support for system v messages. again, only adds a few hundred bytes to the
kernel.
note: the ipcs(1) command will list any processes using each of these
system v facilities.
options p1003_1b #posix p1003_1b real-time extensions
options _kposix_priority_scheduling
real-time extensions added in the 1993 posix. certain applications in the
ports collection use these (such as staroffice).
options icmp_bandlim #rate limit bad replies
this option enables icmp error response bandwidth limiting. you typically
want this option as it will help protect the machine from denial of
service packet attacks.
# to make an smp kernel, the next two are needed
#options smp # symmetric multiprocessor kernel
#options apic_io # symmetric (apic) i/o
the above are both required for smp support.
device isa
all pcs supported by freebsd have one of these. if you have an ibm ps/2
(micro channel architecture), you cannot run freebsd at this time (support
is being worked on).
device eisa
include this if you have an eisa motherboard. this enables auto-detection
and configuration support for all devices on the eisa bus.
device pci
include this if you have a pci motherboard. this enables auto-detection of
pci cards and gatewaying from the pci to isa bus.
# floppy drives
device fdc0 at isa? port io_fd1 irq 6 drq 2
device fd0 at fdc0 drive 0
device fd1 at fdc0 drive 1
this is the floppy drive controller. fd0 is the a: floppy drive, and fd1
is the b: drive.
device ata
this driver supports all ata and atapi devices. you only need one device
ata line for the kernel to detect all pci ata/atapi devices on modern
machines.
device atadisk # ata disk drives
this is needed along with device ata for atapi disk drives.
device atapicd # atapi cdrom drives
this is needed along with device ata for atapi cdrom drives.
device atapifd # atapi floppy drives
this is needed along with device ata for atapi floppy drives.
device atapist # atapi tape drives
this is needed along with device ata for atapi tape drives.
options ata_static_id #static device numbering
this makes the controller number static (like the old driver) or else the
device numbers are dynamically allocated.
# ata and atapi devices
device ata0 at isa? port io_wd1 irq 14
device ata1 at isa? port io_wd2 irq 15
use the above for older, non-pci systems.
# scsi controllers
device ahb # eisa aha1742 family
device ahc # aha2940 and onboard aic7xxx devices
device amd # amd 53c974 (teckram dc-390(t))
device dpt # dpt smartcache - see lint for options!
device isp # qlogic family
device ncr # ncr/symbios logic
device sym # ncr/symbios logic (newer chipsets)
device adv0 at isa?
device adw
device bt0 at isa?
device aha0 at isa?
device aic0 at isa?
scsi controllers. comment out any you do not have in your system. if you
have an ide only system, you can remove these altogether.
# scsi peripherals
device scbus # scsi bus (required)
device da # direct access (disks)
device sa # sequential access (tape etc)
device cd # cd
device pass # passthrough device (direct scsi
access)
scsi peripherals. again, comment out any you do not have, or if you have
only ide hardware, you can remove them completely.
# raid controllers
device ida # compaq smart raid
device amr # ami megaraid
device mlx # mylex dac960 family
supported raid controllers. if you do not have any of these, you can
comment them out or remove them.
# atkbdc0 controls both the keyboard and the ps/2 mouse
device atkbdc0 at isa? port io_kbd
the keyboard controller (atkbdc) provides i/o services for the at keyboard
and ps/2 style pointing devices. this controller is required by the
keyboard driver (atkbd) and the ps/2 pointing device driver (psm).
device atkbd0 at atkbdc? irq 1
the atkbd driver, together with atkbdc controller, provides access to the
at 84 keyboard or the at enhanced keyboard which is connected to the at
keyboard controller.
device psm0 at atkbdc? irq 12
use this device if your mouse plugs into the ps/2 mouse port.
device vga0 at isa?
the video card driver.
# splash screen/screen saver
pseudo-device splash
splash screen at start up! screen savers require this too.
# syscons is the default console driver, resembling an sco console
device sc0 at isa?
sc0 is the default console driver, which resembles a sco console. since
most full-screen programs access the console through a terminal database
library like termcap, it should not matter whether you use this or vt0,
the vt220 compatible console driver. when you log in, set your term
variable to scoansi if full-screen programs have trouble running under
this console.
# enable this and pcvt_freebsd for pcvt vt220 compatible console driver
#device vt0 at isa?
#options xserver # support for x server on a vt console
#options fat_cursor # start with block cursor
# if you have a thinkpad, uncomment this along with the rest of the pcvt
lines
#options pcvt_scanset=2 # ibm keyboards are non-std
this is a vt220-compatible console driver, backward compatible to
vt100/102. it works well on some laptops which have hardware
incompatibilities with sc0. also set your term variable to vt100 or vt220
when you log in. this driver might also prove useful when connecting to a
large number of different machines over the network, where termcap or
terminfo entries for the sc0 device are often not available -- vt100
should be available on virtually any platform.
# power management support (see lint for more options)
device apm0 at nexus? disable flags 0x20 # advanced power
management
advanced power management support. useful for laptops.
# pccard (pcmcia) support
device card
device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000
device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable
pcmcia support. you want this if you are using a laptop.
# serial (com) ports
device sio0 at isa? port io_com1 flags 0x10 irq 4
device sio1 at isa? port io_com2 irq 3
device sio2 at isa? disable port io_com3 irq 5
device sio3 at isa? disable port io_com4 irq 9
these are the four serial ports referred to as com1 through com4 in the
ms-dos/windows world.
note: if you have an internal modem on com4 and a serial port at com2,
you will have to change the irq of the modem to 2 (for obscure technical
reasons, irq2 = irq 9) in order to access it from freebsd. if you have a
multiport serial card, check the manual page for sio(4) for more
information on the proper values for these lines. some video cards
(notably those based on s3 chips) use io addresses in the form of
0x*2e8, and since many cheap serial cards do not fully decode the 16-bit
io address space, they clash with these cards making the com4 port
practically unavailable.
each serial port is required to have a unique irq (unless you are using
one of the multiport cards where shared interrupts are supported), so
the default irqs for com3 and com4 cannot be used.
# parallel port
device ppc0 at isa? irq 7
this is the isa-bus parallel port interface.
device ppbus # parallel port bus (required)
provides support for the parallel port bus.
device lpt # printer
support for parallel port printers.
note: all three of the above are required to enable parallel printer
support.
device plip # tcp/ip over parallel
this is the driver for the parallel network interface.
device ppi # parallel port interface device
the general-purpose i/o (``geek port'') + ieee1284 i/o.
#device vpo # requires scbus and da
this is for an iomega zip drive. it requires scbus and da support. best
performance is achieved with ports in epp 1.9 mode.
# pci ethernet nics.
device de # dec/intel dc21x4x (``tulip'')
device fxp # intel etherexpress pro/100b (82557, 82558)
device tx # smc 9432tx (83c170 ``epic'')
device vx # 3com 3c590, 3c595 (``vortex'')
device wx # intel gigabit ethernet card (``wiseman'')
various pci network card drivers. comment out or remove any of these not
present in your system.
# pci ethernet nics that use the common mii bus controller code.
device miibus # mii bus support
mii bus support is required for some pci 10/100 ethernet nics, namely
those which use mii-compliant transceivers or implement transceiver
control interfaces that operate like an mii. adding device miibus to the
kernel config pulls in support for the generic miibus api and all of the
phy drivers, including a generic one for phys that are not specifically
handled by an individual driver.
device dc # dec/intel 21143 and various workalikes
device rl # realtek 8129/8139
device sf # adaptec aic-6915 (``starfire'')
device sis # silicon integrated systems sis 900/sis 7016
device ste # sundance st201 (d-link dfe-550tx)
device tl # texas instruments thunderlan
device vr # via rhine, rhine ii
device wb # winbond w89c840f
device xl # 3com 3c90x (``boomerang'', ``cyclone'')
drivers that use the mii bus controller code.
# isa ethernet nics.
device ed0 at isa? port 0x280 irq 10 iomem 0xd8000
device ex
device ep
# wavelan/ieee 802.11 wireless nics. note: the wavelan/ieee really
# exists only as a pcmcia device, so there is no isa attachment needed
# and resources will always be dynamically assigned by the pccard code.
device wi
# aironet 4500/4800 802.11 wireless nics. note: the declaration below will
# work for pcmcia and pci cards, as well as isa cards set to isa pnp
# mode (the factory default). if you set the switches on your isa
# card for a manually chosen i/o address and irq, you must specify
# those parameters here.
device an
# the probe order of these is presently determined by i386/isa/isa_compat.c.
device ie0 at isa? port 0x300 irq 10 iomem 0xd0000
device fe0 at isa? port 0x300
device le0 at isa? port 0x300 irq 5 iomem 0xd0000
device lnc0 at isa? port 0x280 irq 10 drq 0
device cs0 at isa? port 0x300
device sn0 at isa? port 0x300 irq 10
# requires pccard (pcmcia) support to be activated
#device xe0 at isa?
isa ethernet drivers. see /usr/src/sys/i386/conf/lint for which cards are
supported by which driver.
pseudo-device ether # ethernet support
ether is only needed if you have an ethernet card. it includes generic
ethernet protocol code.
pseudo-device sl 1 # kernel slip
sl is for slip support. this has been almost entirely supplanted by ppp,
which is easier to set up, better suited for modem-to-modem connection,
and more powerful. the number after sl specifies how many simultaneous
slip sessions to support.
pseudo-device ppp 1 # kernel ppp
this is for kernel ppp support for dial-up connections. there is also a
version of ppp implemented as a userland application that uses tun and
offers more flexibility and features such as demand dialing. the number
after ppp specifies how many simultaneous ppp connections to support.
pseudo-device tun # packet tunnel.
this is used by the userland ppp software. a number after tun specifies
the number of simultaneous ppp sessions to support. see the ppp section of
this book for more information.
pseudo-device pty # pseudo-ttys (telnet etc)
this is a ``pseudo-terminal'' or simulated login port. it is used by
incoming telnet and rlogin sessions, xterm, and some other applications
such as emacs. a number after pty indicates the number of ptys to create.
if you need more than the default of 16 simultaneous xterm windows and/or
remote logins, be sure to increase this number accordingly, up to a
maximum of 256.
pseudo-device md # memory ``disks''
memory disk pseudo-devices.
pesudo-device gif
or
pseudo-device gif 4 # ipv6 and ipv4 tunneling
this implements ipv6 over ipv4 tunneling, ipv4 over ipv6 tunneling, ipv4
over ipv4 tunneling, and ipv6 over ipv6 tunneling. beginning with freebsd
4.4 the gif device is ``auto-cloning'', and you should use the first
example (without the number after gif). earlier versions of freebsd
require the number.
pseudo-device faith 1 # ipv6-to-ipv4 relaying (translation)
this pseudo-device captures packets that are sent to it and diverts them
to the ipv4/ipv6 translation daemon.
# the `bpf' pseudo-device enables the berkeley packet filter.
# be aware of the administrative consequences of enabling this!
pseudo-device bpf # berkeley packet filter
this is the berkeley packet filter. this pseudo-device allows network
interfaces to be placed in promiscuous mode, capturing every packet on a
broadcast network (e.g., an ethernet). these packets can be captured to
disk and or examined with the tcpdump(1) program.
note: the bpf pseudo-device is also used by dhclient(8) to obtain the ip
address of the default router (gateway) and so on. if you use dhcp,
leave this uncommented.
# usb support
#device uhci # uhci pci->usb interface
#device ohci # ohci pci->usb interface
#device usb # usb bus (required)
#device ugen # generic
#device uhid # ``human interface devices''
#device ukbd # keyboard
#device ulpt # printer
#device umass # disks/mass storage - requires scbus and da
#device ums # mouse
# usb ethernet, requires mii
#device aue # admtek usb ethernet
#device cue # catc usb ethernet
#device kue # kawasaki lsi usb ethernet
support for various usb devices.
for more information and additional devices supported by freebsd, see
/usr/src/sys/i386/conf/lint.
----------------------------------------------------------------------
9.5 making device nodes
almost every device in the kernel has a corresponding ``node'' entry in
the /dev directory. these nodes look like regular files, but are actually
special entries into the kernel which programs use to access the device.
the shell script /dev/makedev, which is executed when you first install
the operating system, creates nearly all of the device nodes supported.
however, it does not create all of them, so when you add support for a new
device, it pays to make sure that the appropriate entries are in this
directory, and if not, add them. here is a simple example:
suppose you add the ide cd-rom support to the kernel. the line to add is:
device acd0
this means that you should look for some entries that start with acd0 in
the /dev directory, possibly followed by a letter, such as c, or preceded
by the letter r, which means a ``raw'' device. it turns out that those
files are not there, so you must change to the /dev directory and type:
# sh makedev acd0
when this script finishes, you will find that there are now acd0c and
racd0c entries in /dev so you know that it executed correctly.
for sound cards, the following command creates the appropriate entries:
# sh makedev snd0
note: when creating device nodes for devices such as sound cards, if
other people have access to your machine, it may be desirable to protect
the devices from outside access by adding them to the /etc/fbtab file.
see fbtab(5) for more information.
follow this simple procedure for any other non-generic devices which do
not have entries.
note: all scsi controllers use the same set of /dev entries, so you do
not need to create these. also, network cards and slip/ppp
pseudo-devices do not have entries in /dev at all, so you do not have to
worry about these either.
----------------------------------------------------------------------
9.6 if something goes wrong
there are five categories of trouble that can occur when building a custom
kernel. they are:
config fails:
if the config command fails when you give it your kernel
description, you have probably made a simple error somewhere.
fortunately, config will print the line number that it had trouble
with, so you can quickly skip to it with vi. for example, if you
see:
config: line 17: syntax error
you can skip to the problem in vi by typing 17g in command mode.
make sure the keyword is typed correctly, by comparing it to the
generic kernel or another reference.
make fails:
if the make command fails, it usually signals an error in your
kernel description, but not severe enough for config to catch it.
again, look over your configuration, and if you still cannot
resolve the problem, send mail to the freebsd general questions
mailing list <[email protected]> with your kernel
configuration, and it should be diagnosed very quickly.
installing the new kernel fails
if the kernel compiled fine, but failed to install (the make
install or make installkernel command failed), the first thing to
check is if your system is running at securelevel 1 or higher (see
init(8)). the kernel installation tries to remove the immutable
flag from your kernel and set the immutable flag on the new one.
since securelevel 1 or higher prevents unsetting the immutable
flag for any files on the system, the kernel installation needs to
be performed at securelevel 0 or lower.
the kernel will not boot:
if your new kernel does not boot, or fails to recognize your
devices, do not panic! fortunately, bsd has an excellent mechanism
for recovering from incompatible kernels. simply choose the kernel
you want to boot from at the freebsd boot loader. you can access
this when the system counts down from 10. hit any key except for
the enter key, type unload and then type boot kernel.old, or the
filename of any other kernel that will boot properly. when
reconfiguring a kernel, it is always a good idea to keep a kernel
that is known to work on hand.
after booting with a good kernel you can check over your
configuration file and try to build it again. one helpful resource
is the /var/log/messages file which records, among other things,
all of the kernel messages from every successful boot. also, the
dmesg(8) command will print the kernel messages from the current
boot.
note: if you are having trouble building a kernel, make sure to
keep a generic, or some other kernel that is known to work on
hand as a different name that will not get erased on the next
build. you cannot rely on kernel.old because when installing a
new kernel, kernel.old is overwritten with the last installed
kernel which may be non-functional. also, as soon as possible,
move the working kernel to the proper kernel location or
commands such as ps(1) will not work properly. the proper
command to ``unlock'' the kernel file that make installs (in
order to move another kernel back permanently) is:
# chflags noschg /kernel
if you find you cannot do this, you are probably running at a
securelevel(8) greater than zero. edit kern_securelevel in
/etc/rc.conf and set it to -1, then reboot. you can change it
back to its previous setting when you are happy with your new
kernel.
and, if you want to ``lock'' your new kernel into place, or any
file for that matter, so that it cannot be moved or tampered
with:
# chflags schg /kernel
the kernel works, but ps does not work any more!:
if you have installed a different version of the kernel from the
one that the system utilities have been built with, for example, a
4.x kernel on a 3.x system, many system-status commands like ps(1)
and vmstat(8) will not work any more. you must recompile the
libkvm library as well as these utilities. this is one reason it
is not normally a good idea to use a different version of the
kernel from the rest of the operating system.
----------------------------------------------------------------------
chapter 10 security
much of this chapter has been taken from the security(7) manual page by
matthew dillon.
----------------------------------------------------------------------
10.1 synopsis
this chapter will provide a basic introduction to system security
concepts, some general good rules of thumb, and some advanced topics under
freebsd. a lot of the topics covered here can be applied to system and
internet security in general as well. the internet is no longer a
``friendly'' place in which everyone wants to be your kind neighbor.
securing your system is imperative to protect your data, intellectual
property, time, and much more from the hands of hackers and the like.
freebsd provides an array of utilities and mechanisms to ensure the
integrity and security of your system and network.
after reading this chapter, you will know:
* basic system security concepts, in respect to freebsd.
* about the various crypt mechanisms available in freebsd, such as des
and md5.
* how to setup s/key, an alternative, one-time password authentication
system.
* how to setup kerberos, another alternative authentication system.
* how to create firewalls using ipfw.
* how to configure ipsec.
* how to configure and use openssh, freebsd's ssh implementation.
before reading this chapter, you should:
* understand basic freebsd and internet concepts.
----------------------------------------------------------------------
10.2 introduction
security is a function that begins and ends with the system administrator.
while all bsd unix multi-user systems have some inherent security, the job
of building and maintaining additional security mechanisms to keep those
users ``honest'' is probably one of the single largest undertakings of the
sysadmin. machines are only as secure as you make them, and security
concerns are ever competing with the human necessity for convenience. unix
systems, in general, are capable of running a huge number of simultaneous
processes and many of these processes operate as servers - meaning that
external entities can connect and talk to them. as yesterday's
mini-computers and mainframes become today's desktops, and as computers
become networked and internetworked, security becomes an even bigger
issue.
security is best implemented through a layered ``onion'' approach. in a
nutshell, what you want to do is to create as many layers of security as
are convenient and then carefully monitor the system for intrusions. you
do not want to overbuild your security or you will interfere with the
detection side, and detection is one of the single most important aspects
of any security mechanism. for example, it makes little sense to set the
schg flags (see chflags(1)) on every system binary because while this may
temporarily protect the binaries, it prevents an attacker who has broken
in from making an easily detectable change that may result in your
security mechanisms not detecting the attacker at all.
system security also pertains to dealing with various forms of attack,
including attacks that attempt to crash, or otherwise make a system
unusable, but do not attempt to compromise the root account (``break
root''). security concerns can be split up into several categories:
#1. denial of service attacks.
#2. user account compromises.
#3. root compromise through accessible servers.
#4. root compromise via user accounts.
#5. backdoor creation.
a denial of service attack is an action that deprives the machine of
needed resources. typically, dos attacks are brute-force mechanisms that
attempt to crash or otherwise make a machine unusable by overwhelming its
servers or network stack. some dos attacks try to take advantage of bugs
in the networking stack to crash a machine with a single packet. the
latter can only be fixed by applying a bug fix to the kernel. attacks on
servers can often be fixed by properly specifying options to limit the
load the servers incur on the system under adverse conditions. brute-force
network attacks are harder to deal with. a spoofed-packet attack, for
example, is nearly impossible to stop, short of cutting your system off
from the internet. it may not be able to take your machine down, but it
can saturate your internet connection.
a user account compromise is even more common than a dos attack. many
sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on
their machines.