FreeBSD for the SVR4/Linux Administrator
Michael Lucas Typically, UNIX systems administrators are familiar with header files, compilers, and the vagaries of their preferred UNIX. Even though this knowledge can be leveraged across multiple UNIX breeds, the basics of systems administration on an unfamiliar platform can frustrate even an experienced admin. Although I have years of experience in BSD-based UNIXes, two years in Linux, plus a smattering of Solaris, I still sometimes find myself confused when dealing with a new UNIX. The first time I logged onto a SCO UNIX machine, for example, I spent almost half an hour looking for the proper way to set a default route. Essential concepts were the same, but the simple issues of administration and software management cost me hours. System V admins that I know gripe about similar problems when working on a BSD-style machine. This article attempts to give a System V or Linux administrator a basic grounding in FreeBSD configuration and usage. All references are given for FreeBSD 3.x on the x86 architecture, which is slightly different than the Alpha architecture, the obsolete 2.x, or the bleeding-edge 4.0 versions. System Contents The FreeBSD core system includes the kernel and a small assortment of utilities. The core utilities are kept deliberately few. Some items that other UNIX-style operating systems consider absolutely vital, such as the X Window system, are not included by default. (The ports and packages systems simplify adding extra software.) FreeBSD is also designed to be light by modern standards; a base install takes about 50 megs. Unlike a Linux system, FreeBSD does not have “distributions.” Strictly speaking, Linux is just a kernel; the distribution is the assortment of programs and utilities that come with the kernel. In FreeBSD the kernel and core utilities are a unified whole, and are expected to be used as one. Booting The FreeBSD boot loader loads the kernel, waits for 10 seconds by default, and then executes it. You can interrupt during the 10-second lag to issue configuration commands or select another kernel to boot. When the loader starts, you will see a countdown of time remaining (in seconds) until the system boots. Hit enter to boot immediately, or the space bar to get a loader command prompt. At the loader prompt, typing “?” will give you simple on-line help, or check the loader(8) man page on a running system. Some helpful loader commands include:
unl oad -- Remove all modules from memory. This includes the not-yet-booted kernel. loa d -- Load a module into memory. For example, to boot with kernel.old, you would use load kernel.old. boot -- Continue booting. boot_single -- Boot the system in single-user mode (see below). boo t_userconfig -- Boot the system in hardware-configuration mode. This will let you set and change hardware settings, such as memory ports and IRQs. Note that changes you make to one kernel in this mode will not affect other kernels.
Hit “?” for help within the hardware configuration tool. Once you have found this tool, it is fairly self-explanatory if you are familiar with x86 hardware. System booting behavior can be customized with files under /boot. Some of the more interesting files include:
/bo ot/kernel.conf -- This contains any changes made with userconfig during an interrupted boot. You can edit this file directly if you wish, but it is generally recommended to just use userconfig. /bo ot/defaults/loader.conf -- This contains the default booting behavior. You can browse this file for configurable behavior. Do not edit this file directly; the system overwrites it during the upgrade process. /boot/loader.conf -- This is for local customizations of booting behavior. Any entries here override the defaults in /boot/defaults/loader.conf. See man loader.conf (5) for details. Initial Multiuser Configuration When the boot process reaches the multi-user stage, the system runs the script /etc/rc. There is no /etc/init.d or /etc/inittab. /etc/rc reads all system configuration information, calls all other system startup scripts, and performs all other system initialization work. The /etc/rc script is configured by two other shell scripts: /etc/defaults/rc.conf and /etc/rc.conf. The script /etc/defaults/rc.conf contains the systems default, out-of-the-box configuration in shell variable assignments. This file is replaced each time you upgrade the system (see my article “Maintaining Patch Levels in Open Source BSDs”, Sys Admin September 1999). Don't edit this file; any changes made here will be lost in the next upgrade. The script /etc/rc.conf contains more shell variables. Anything you enter here overrides the defaults. This file is for your local use. You can copy any variable assignment from /etc/defaults/rc.conf to /etc/rc.conf, changing the value to fit your needs. For example, /etc/defaults/rc.conf contains the lines:
sendmail_enable="YES" sendmail_flags="-bd q30m" By default, a FreeBSD system has Sendmail enabled at boot. To prevent this, edit /etc/rc.conf and add the line:
sendmail_enable="NO" Don't worry about the sendmail_flags entry. If a program isn't set to run, /etc/rc will ignore any flags given for it. Similar changes will enable or disable daemons and services included with the system at boot time. If you don't like editing shell scripts directly, FreeBSD includes the configuration tool /stand/sysinstall. This will edit all files as you choose. Depending on detected hardware and your rc.conf settings, /etc/rc will call some of the following scripts:
/etc/rc.alpha -- for Alpha systems. /etc/rc.i386 -- for x86 systems. /et c/rc.firewall -- for systems with FIREWALL_ENABLE="YES"set in rc.conf. /et c/rc.pccard -- for systems with PCCARDD_ENABLE="YES" set in rc.conf. /et c/rc.network -- standard network startup routines. /etc/rc.atm -- ATM card configuration. /et c/rc.isdn -- isdnd initial configuration. Called if isdn_enable="YES". /et c/rc.serial -- serial port configuration. Always called. Local daemons One important /etc/defaults/rc.conf entry is:
local_startup="/usr/local/etc/rc.d/usr/X11R6/etc/rc.d" After running /etc/rc and its dependent scripts, the system checks these directories for additional scripts. If it finds any files with a .sh extension, it attempts to execute them. All non-core daemons such as Web servers, sshd, and databases, are started by scripts in these directories. Any locally installed daemons and services are started in these directories. Some places still use the script /etc/rc.local to start local services. This is deprecated, and should be avoided. Runlevels in FreeBSD FreeBSD doesn't have runlevels. If you need to work on the system before it completes booting, you can set the system to boot only in single-user mode (see above). In single-user mode, the / filesystem is mounted read-only. No fsck has been run, other filesystems are not mounted, and swap is not active. Essentially, it is the earliest point where the system can give you a shell prompt. During single-user mode, you can choose exactly which system components you want to use. All the commands you need for a complete boot are documented in /etc/rc. A ^D or exit in single-user mode will continue the boot process and bring the system up normally. Third-Party Software The FreeBSD packages and ports systems handle third-party software for the systems administrator. Packages are pre-compiled binaries with system-readable installation instructions, similar to Solaris pkgadd, RedHat's rpm, or Debian's dpkg. Packages are available on your FreeBSD CD-ROM, or from a FreeBSD ftp site, for example:
ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages Packages are installed with the pkg_add command. For example, if you want to install the sharity-light package (a CIFS client), simply download it and run:
pkg_add sharity-light.12.tgz
Alternately, if you have a live Net connection, you can simply use:
pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/net/sharity-light.12.tgz This will automatically fetch and install the package. If a package depends on other software being installed to function, pkg_add will automatically detect these dependencies. FreeBSD will look under /cdrom/packages for software dependencies. If it doesn't find the necessary packages there, it will download them from the Internet. If pkg_add cannot fetch required packages, the install will fail. Similarly, the ports tree helps the sysadmin build software from source code. The ports tree is under /usr/ports and is divided into several categories. A quick grep of /usr/ports/INDEX will tell you whether a desired piece of software is part of the official FreeBSD ports system. To install sharity-light from source code via ports, you simply go into /usr/ports/net/sharity-light. If you do a ls, you'll see:
%ls -lai total 13 253975 drwxr-xr-x 7 root wheel 512 Oct 26 13:04 . 622586 drwxr-xr-x 230 root wheel 4096 Oct 13 15:21 .. 553485 drwxr-xr-x 2 root wheel 512 Jan 2 1999 CVS 254264 -rw-r--r-- 1 root wheel 1190 Oct 13 15:21 Makefile 253977 -rw-r--r-- 1 root wheel 735 Nov 29 1998 README.html 561174 drwxr-xr-x 3 root wheel 512 May 25 22:52 files 591887 drwxr-xr-x 3 root wheel 512 Aug 11 17:39 patches 668644 drwxr-xr-x 3 root wheel 512 May 25 22:52 pkg % This isn't much at all! What about the source code? It isn't there. All you will find under the port directory is a Makefile on how to build the software, a few FreeBSD-specific patches, and some descriptive information. When you type make install. the system fetches the source code, verifies checksums, decompresses it appropriately, checks for dependencies, applies the patches, builds, and installs. The ports tree will check the following places for a source code tarball, or “distfile”:
/usr/ports/distfiles /cdrom/distfiles the Internet The port Makefile includes information on Internet sites where the distfile can be found. If you don't like this sort of automated install, you can use the patches provided as hints when compiling it yourself. Reading the patches provided can also help introduce you to the internals of FreeBSD. If you like automated installs, but want to check or change the defaults on a port before compilation, you can slow the process with a series of make commands rather than the all-inclusive make all install:
make fetch make checksum make extract make patch make configure make build make install The software is built in the port directory, in a “work” subdirectory. If you want to keep the sources, object files, etc. on hand for later reference, you're done. Otherwise, you can do a make clean to remove the work subdirectory and save disk space. Whether you're installing from packages or ports, the new software will be installed under /usr/local or /usr/X11R6, as appropriate. In no case should a port or package install something in a core system directory, such as /bin or /usr/lib. If you should encounter a port or package that does this, please notify the port/package maintainer (available in the port Makefile) or ports@freebsd.org. If you want to reserve /usr/local for truly local software, you can change the default location. Set the PREFIX environment variable if you want to do this. You can make a package out of your custom-compiled port with make package. You can build your software once and distribute the compiled package across several machines. (Be sure to run make package before make clean!) If you're interested in the internals of the FreeBSD ports system, take a look at the file /usr/ports/Mk/bsd.port.mk. This contains the guts of the port-building system. You don't want to edit this file directly, because it can be overwritten by the upgrade process. Instead, take a look at /etc/make.conf for local customization of port builds. Quite a few third-party programs are not included in the ports system. If you successfully compile a software package on FreeBSD that isn't in the ports, please send your patches to freebsd-ports@freebsd.org, so other people can benefit from your work. Whether you installed software as a package or a port, once it's compiled and in place, it's treated as a package. It becomes a binary, after all. For the rest of this article, both packages and ports will be referred to as packages. For information on installed software, look at /var/db/pkg. The software installation procedure leaves a directory here for each package that has been installed locally. The directory names here are the same as the name of the package. Looking at a typical directory under /var/db/pkg, we see:
%ls +COMMENT +CONTENTS +DESC +REQUIRED_BY % “+COMMENT” gives a brief description of the software. “+DESC” is a longer, more detailed description. “+REQUIRED_BY” lists other packages that depend on this package. “+CONTENTS” is the “packing list” that describes what was installed where, and the checksums of installed files. To remove a package, use the pkg_delete command. A simple pkg_delete pkgname will remove it from your system. The command pkg_info -aI will give you a list of all installed packages. The pkg_delete command will also prevent you from deleting a package required by other packages. Kernel Configuration The kernel configuration is under /usr/src/sys/i386/conf. The two files you will probably be most interested in are LINT and the config file for your existing kernel. You can get the name of your existing kernel configuration file from the command uname -v. LINT contains a brief description of all kernel options for FreeBSD, both supported and unsupported. Although LINT can be compiled for test purposes, you cannot actually run a LINT kernel. When building a new kernel, you probably want to start with the GENERIC configuration. Copy GENERIC to a file of your choosing and edit it. I suggest first removing whatever options and hardware drivers you don't need. If you're not sure about the hardware on your system, the file /var/log/dmesg.boot will give you the boot-time hardware probes and debugging messages. Then, add desired options from LINT. When building a kernel to support some particular x86 equipment (usually older ISA cards), you might need to specify IRQs, DRQs, or memory ports in the kernel config file. You can also specify flags to some device drivers. Check LINT or the driver man page for details. Then do:
/usr/sbin/config kernelconfigfile If config gives you errors, correct them before continuing. Most errors are fairly self-explanatory. If config succeeds, go to the compile directory (returned by a successful “config”) and do:
make depend make all make install This will build and install the new kernel. If you are editing an existing kernel, rather than building one from scratch, this process will only compile changed kernel components. Getting Help To get help, first check the FreeBSD FAQ and Handbook. If the documentation distribution is installed on your system, these can be found under /usr/share/doc. If not, they can be found on the FreeBSD Web site, at: http://www.freebsd.org. A variety of other documents can also be found there; check the “Documentation” link. If you have a specific problem, check the FreeBSD mailing lists at:
http://www.freebsd.org/search/ Chances are someone has had the problem before you. Search for your particular error message in the FreeBSD-questions archive. If the mailing list archive cannot help you, send your question to FreeBSD-questions@FreeBSD.org. Describe your setup completely, including your hardware setup, any error messages you receive, and software installed. Be as complete as possible. Although the FreeBSD crowd has a reputation for being less helpful to newbies than some of the other free UNIX groups, they are actually quite helpful when given the necessary information to debug a problem. If you're looking for information about a change made to a particular FreeBSD component since the BSD 4.4-Lite days, look at the Web-based CVS repository at:
http://www.freebsd.org/cgi/cvsweb.cgi You can see every change made and the log message showing the rationale for it. The site http://www.daemonnews.org/ publishes monthly articles on all the BSD variants, and is well worth checking for FreeBSD-specific documentation. Shutdown When a FreeBSD system shuts down, it calls the shell script /etc/rc.shutdown. If you are running applications that need to be terminated gracefully (such as databases), you can add their shutdown procedures here. Summary From an end user or systems administration viewpoint, the differences between FreeBSD and other UNIXes are fairly cosmetic. The systems administrator is expected to have a reasonably extensive knowledge of x86 hardware for in-depth administration tasks. A basic knowledge of FreeBSD configuration will extend your UNIX repertoire.
About the AuthorMichael Lucas is a networking and FreeBSD consultant who works for the Great Lakes Technologies Group. He lives in Detroit, Michigan, with his wife Liz, five gerbils, and assorted fish. The author wishes to thank Christian Weisgerber, Ronald F. Guilmette, Keith Stevenson, Wes Peters, and David Wolfskill for reviewing this article. |