diff --git a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml index 0a09263150..e0d9218d1d 100644 --- a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml @@ -1,824 +1,824 @@ Backups Synopsis The following chapter will cover methods of backing up data, and the programs used to create those backups. If you would like to contribute something to this section, send it to the &a.doc;. Tape Media tape media The major tape media are the 4mm, 8mm, QIC, mini-cartridge and DLT. 4mm (DDS: Digital Data Storage) tape media DDS (4mm) tapes tape media QIC tapes 4mm tapes are replacing QIC as the workstation backup media of choice. This trend accelerated greatly when Conner purchased Archive, a leading manufacturer of QIC drives, and then stopped production of QIC drives. 4mm drives are small and quiet but do not have the reputation for reliability that is enjoyed by 8mm drives. The cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51 x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short head life for the same reason, both use helical scan. Data throughput on these drives starts ~150kB/s, peaking at ~500kB/s. Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. Multi-drive tape library units can have 6 drives in a single cabinet with automatic tape changing. Library capacities reach 240 GB. The DDS-3 standard now supports tape capacities up to 12GB (or 24GB compressed). 4mm drives, like 8mm drives, use helical-scan. All the benefits and drawbacks of helical-scan apply to both 4mm and 8mm drives. Tapes should be retired from use after 2,000 passes or 100 full backups. 8mm (Exabyte) tape media Exabyte (8mm) tapes 8mm tapes are the most common SCSI tape drives; they are the best choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm tape drive. 8mm drives are reliable, convenient and quiet. Cartridges are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm). One downside of 8mm tape is relatively short head and tape life due to the high rate of relative motion of the tape across the heads. Data throughput ranges from ~250kB/s to ~500kB/s. Data sizes start at 300 MB and go up to 7 GB. Hardware compression, available with most of these drives, approximately doubles the capacity. These drives are available as single units or multi-drive tape libraries with 6 drives and 120 tapes in a single cabinet. Tapes are changed automatically by the unit. Library capacities reach 840+ GB. The Exabyte Mammoth model supports 12GB on one tape (24GB with compression) and costs approximately twice as much as conventional tape drives. Data is recorded onto the tape using helical-scan, the heads are positioned at an angle to the media (approximately 6 degrees). The tape wraps around 270 degrees of the spool that holds the heads. The spool spins while the tape slides over the spool. The result is a high density of data and closely packed tracks that angle across the tape from one edge to the other. QIC tape media QIC-150 QIC-150 tapes and drives are, perhaps, the most common tape drive and media around. QIC tape drives are the least expensive "serious" backup drives. The downside is the cost of media. QIC tapes are expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB data storage. But, if your needs can be satisfied with a half-dozen tapes, QIC may be the correct choice. QIC is the most common tape drive. Every site has a QIC drive of some density or another. Therein lies the rub, QIC has a large number of densities on physically similar (sometimes identical) tapes. QIC drives are not quiet. These drives audibly seek before they begin to record data and are clearly audible whenever reading, writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x 10.2 x 1.7 mm). Mini-cartridges, which also use 1/4" wide tape are discussed separately. Tape libraries and changers are not available. Data throughput ranges from ~150kB/s to ~500kB/s. Data capacity ranges from 40 MB to 15 GB. Hardware compression is available on many of the newer QIC drives. QIC drives are less frequently installed; they are being supplanted by DAT drives. Data is recorded onto the tape in tracks. The tracks run along the long axis of the tape media from one end to the other. The number of tracks, and therefore the width of a track, varies with the tape's capacity. Most if not all newer drives provide backward-compatibility at least for reading (but often also for writing). QIC has a good reputation regarding the safety of the data (the mechanics are simpler and more robust than for helical scan drives). Tapes should be retired from use after 5,000 backups. * Mini-Cartridge ]]> DLT tape media DLT DLT has the fastest data transfer rate of all the drive types listed here. The 1/2" (12.5mm) tape is contained in a single spool cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a swinging gate along one entire side of the cartridge. The drive mechanism opens this gate to extract the tape leader. The tape leader has an oval hole in it which the drive uses to "hook" the tape. The take-up spool is located inside the tape drive. All the other tape cartridges listed here (9 track tapes are the only exception) have both the supply and take-up spools located inside the tape cartridge itself. Data throughput is approximately 1.5MB/s, three times the throughput of 4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB for a single drive. Drives are available in both multi-tape changers and multi-tape, multi-drive tape libraries containing from 5 to 900 tapes over 1 to 20 drives, providing from 50GB to 9TB of storage. With compression, DLT Type IV format supports up to 70GB capacity. Data is recorded onto the tape in tracks parallel to the direction of travel (just like QIC tapes). Two tracks are written at once. Read/write head lifetimes are relatively long; once the tape stops moving, there is no relative motion between the heads and the tape. AIT tape media AIT AIT is a new format from Sony, and can hold up to 50GB (with compression) per tape. The tapes contain memory chips which retain an index of the tape's contents. This index can be rapidly read by the tape drive to determine the position of files on the tape, instead of the several minutes that would be required for other tapes. Software such as SAMS:Alexandria can operate forty or more AIT tape libraries, communicating directly with the tape's memory chip to display the contents on screen, determine what files where backed up to which tape, locate the correct tape, load it, and restore the data from the tape. Libraries like this cost in the region of $20,000, pricing them a little out of the hobbyist market. Using a New Tape for the First Time The first time that you try to read or write a new, completely blank tape, the operation will fail. The console messages should be similar to: sa0(ncr1:4:0): NOT READY asc:4,1 sa0(ncr1:4:0): Logical unit is in process of becoming ready The tape does not contain an Identifier Block (block number 0). All QIC tape drives since the adoption of QIC-525 standard write an Identifier Block to the tape. There are two solutions: mt fsf 1 causes the tape drive to write an Identifier Block to the tape. Use the front panel button to eject the tape. Re-insert the tape and &man.dump.8; data to the tape. &man.dump.8; will report DUMP: End of tape detected and the console will show: HARDWARE FAILURE info:280 asc:80,96 rewind the tape using: mt rewind Subsequent tape operations are successful. Backup Programs backup software The three major programs are &man.dump.8;, &man.tar.1;, and &man.cpio.1;. Dump and Restore backup software dump / restore dump restore &man.dump.8; and &man.restore.8; are the traditional Unix backup programs. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the filesystems. &man.dump.8; backs up devices, entire filesystems, not parts of a filesystem and not directory trees that span more than one filesystem, using either soft links &man.ln.1; or mounting one filesystem onto another. &man.dump.8; does not write files and directories to tape, but rather writes the data blocks that are the building blocks of files and directories. &man.dump.8; has - quirks that remain from its early days in Version 6 of ATT Unix (circa + quirks that remain from its early days in Version 6 of AT&T Unix (circa 1975). The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives. rhosts &man.rdump.8; and &man.rrestore.8; backup data across the network to a tape drive attached to another computer. Both programs rely upon &man.rcmd.3; and &man.ruserok.3; to access the remote tape drive. Therefore, the user performing the backup must have rhosts access to the remote computer. The arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use on the remote computer. (e.g. When rdumping from a FreeBSD computer to an Exabyte tape drive connected to a Sun called komodo, use: /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there are security implications to allowing rhosts commands. Evaluate your situation carefully. Tar backup software tar - &man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975). + &man.tar.1; also dates back to Version 6 of AT&T Unix (circa 1975). &man.tar.1; operates in cooperation with the filesystem; &man.tar.1; writes files and directories to tape. &man.tar.1; does not support the full range of options that are available from &man.cpio.1;, but &man.tar.1; does not require the unusual command pipeline that &man.cpio.1; uses. tar Most versions of &man.tar.1; do not support backups across the network. The GNU version of &man.tar.1;, which FreeBSD utilizes, supports remote devices using the same syntax as &man.rdump.8;. To &man.tar.1; to an Exabyte tape drive connected to a Sun called komodo, use: /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1. For versions without remote device support, you can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b If you're worried about the security of backing over a network you should use the &man.ssh.1; command instead of &man.rsh.1;. Cpio backup software cpio &man.cpio.1; is the original Unix file interchange tape program for magnetic media. &man.cpio.1; has options (among many others) to perform byte-swapping, write a number of different archives format, and pipe the data to other programs. This last feature makes &man.cpio.1; and excellent choice for installation media. &man.cpio.1; does not know how to walk the directory tree and a list of files must be provided through stdin. cpio &man.cpio.1; does not support backups across the network. You can use a pipeline and &man.rsh.1; to send the data to a remote tape drive. &prompt.root; for f in directory_list; do find $f >> backup.list done &prompt.root; cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device Where directory_list is the list of directories you want to back up, user@host is the user/hostname combination that will be performing the backups, and backup_device is where the backups should be written to (e.g., /dev/nrsa0). Pax backup software pax pax POSIX IEEE &man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and &man.cpio.1;. Over the years the various versions of &man.tar.1; and &man.cpio.1; have gotten slightly incompatible. So rather than fight it out to fully standardize them, POSIX created a new archive utility. &man.pax.1; attempts to read and write many of the various &man.cpio.1; and &man.tar.1; formats, plus new formats of its own. Its command set more resembles &man.cpio.1; than &man.tar.1;. Amanda backup software amanda amanda Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and network communications with the Amanda server. A common problem at locations with a number of large disks is the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem. Amanda can use a "holding disk" to backup several filesystems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the filesystems listed in Amanda's configuration file. The "archive set" also contains nightly incremental (or differential) backups of all the filesystems. Restoring a damaged filesystem requires the most recent full backup and the incremental backups. The configuration file provides fine control backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is available as either a port or a package, it is not installed by default. Do Nothing Do nothing is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it! If your time and your data is worth little to nothing, then Do nothing is the most suitable backup program for your computer. But beware, Unix is a useful tool, you may find that within six months you have a collection of files that are valuable to you. Do nothing is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by your computer. An example is the files that comprise these handbook pages-they have been generated from SGML input files. Creating backups of these HTML files is not necessary. The SGML source files are backed up regularly. Which Backup Program is Best? LISA &man.dump.8; Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of Unix filesystems is &man.dump.8;. Elizabeth created filesystems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of that filesystems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs. Emergency Restore Procedure Before the Disaster There are only four steps that you need to perform in preparation for any disaster that may occur. disklabel First, print the disklabel from each of your disks (e.g. disklabel da0 | lpr), your filesystem table (/etc/fstab) and all boot messages, two copies of each. fix-it floppies Second, determine that the boot and fix-it floppies (boot.flp and fixit.flp) have all your devices. The easiest way to check is to reboot your machine with the boot floppy in the floppy drive and check the boot messages. If all your devices are listed and functional, skip on to step three. Otherwise, you have to create two custom bootable floppies which has a kernel that can mount your all of your disks and access your tape drive. These floppies must contain: &man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and whichever backup program you use. These programs must be statically linked. If you use &man.dump.8;, the floppy must contain &man.restore.8;. Third, create backup tapes regularly. Any changes that you make after your last backup may be irretrievably lost. Write-protect the backup tapes. Fourth, test the floppies (either boot.flp and fixit.flp or the two custom bootable floppies you made in step two.) and backup tapes. Make notes of the procedure. Store these notes with the bootable floppy, the printouts and the backup tapes. You will be so distraught when restoring that the notes may prevent you from destroying your backup tapes (How? In place of tar xvf /dev/rsa0, you might accidently type tar cvf /dev/rsa0 and over-write your backup tape). For an added measure of security, make bootable floppies and two backup tapes each time. Store one of each at a remote location. A remote location is NOT the basement of the same office building. A number of firms in the World Trade Center learned this lesson the hard way. A remote location should be physically separated from your computers and disk drives by a significant distance. An example script for creating a bootable floppy: /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes # cd /mnt/dev ./MAKEDEV std ./MAKEDEV da0 ./MAKEDEV da1 ./MAKEDEV da2 ./MAKEDEV sa0 ./MAKEDEV pty0 cd / # # create minimum filesystem table # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < After the Disaster The key question is: did your hardware survive? You have been doing regular backups so there is no need to worry about the software. If the hardware has been damaged. First, replace those parts that have been damaged. If your hardware is okay, check your floppies. If you are using a custom boot floppy, boot single-user (type -s at the boot: prompt). Skip the following paragraph. If you are using the boot.flp and fixit.flp floppies, keep reading. Insert the boot.flp floppy in the first floppy drive and boot the computer. The original install menu will be displayed on the screen. Select the Fixit--Repair mode with CDROM or floppy. option. Insert the fixit.flp when prompted. restore and the other programs that you need are located in /mnt2/stand. Recover each filesystem separately. mount root partition disklabel newfs Try to &man.mount.8; (e.g. mount /dev/da0a /mnt) the root partition of your first disk. If the disklabel was damaged, use &man.disklabel.8; to re-partition and label the disk to match the label that your printed and saved. Use &man.newfs.8; to re-create the filesystems. Re-mount the root partition of the floppy read-write (mount -u -o rw /mnt). Use your backup program and backup tapes to recover the data for this filesystem (e.g. restore vrf /dev/sa0). Unmount the filesystem (e.g. umount /mnt) Repeat for each filesystem that was damaged. Once your system is running, backup your data onto new tapes. Whatever caused the crash or data loss may strike again. An another hour spent now, may save you from further distress later. * I did not prepare for the Disaster, What Now? ]]> What about Backups to Floppies? Can I use floppies for backing up my data? backup floppies floppy disks Floppy disks are not really a suitable media for making backups as: The media is unreliable, especially over long periods of time Backing up and restoring is very slow They have a very limited capacity (the days of backing up an entire hard disk onto a dozen or so floppies has long since passed). However, if you have no other method of backing up your data then floppy disks are better than no backup at all. If you do have to use floppy disks then ensure that you use good quality ones. Floppies that have been lying around the office for a couple of years are a bad choice. Ideally use new ones from a reputable manufacturer. So how do I backup my data to floppies? The best way to backup to floppy disk is to use &man.tar.1; with the (multi volume) option, which allows backups to span multiple floppies. To backup all the files in the current directory and sub-directory use this (as root): &prompt.root; tar Mcvf /dev/fd0 * When the first floppy is full &man.tar.1; will prompt you to insert the next volume (because &man.tar.1; is media independent it refers to volumes. In this context it means floppy disk) Prepare volume #2 for /dev/fd0 and hit return: This is repeated (with the volume number incrementing) until all the specified files have been archived. Can I compress my backups? tar gzip compression Unfortunately, &man.tar.1; will not allow the option to be used for multi-volume archives. You could, of course, &man.gzip.1; all the files, &man.tar.1; them to the floppies, then &man.gunzip.1; the files again! How do I restore my backups? To restore the entire archive use: &prompt.root; tar Mxvf /dev/fd0 To restore only specific files you can either start with the first floppy and use: &prompt.root; tar Mxvf /dev/fd0 filename &man.tar.1; will prompt you to insert subsequent floppies until it finds the required file. Alternatively, if you know which floppy the file is on then you can simply insert that floppy and use the same command as above. Note that if the first file on the floppy is a continuation from the previous one then &man.tar.1; will warn you that it cannot restore it, even if you have not asked it to! diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml index 0de837d61a..efce5e57dd 100644 --- a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml @@ -1,590 +1,597 @@ Chris Shumway Rewritten Unix Basics Synopsis basics The following chapter will cover the basic commands and functionality of the FreeBSD operating system. If you are new to FreeBSD, you will definitely want to read through this chapter before asking for help. Permissions Unix FreeBSD, having its history rooted in BSD Unix, has its fundamentals 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: permissions files permissions 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 ls directories For the long directory listing by ls -l, a column will show a file's permissions for the owner, group, and everyone else. Here's how it 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 searched into, for example, a directory listing can be done in that directory. 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 &man.chmod.1; man page. Directory Structures directory hierarchy Since FreeBSD uses its file systems to determine many fundamental system operations, the hierarchy of the file system is extremely important. Due to the fact that the &man.hier.7; man page provides a complete description of the directory structure, it will not be duplicated here. Please read &man.hier.7; for more information. Of significant importance is the root of all directories, the / directory. This directory is the first directory mounted at boot time and it contains the base system necessary at boot time. The root directory also contains mount points for every other file system that you 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 &man.rc.8; unless they contain the option. Consult the &man.fstab.5; manual page for more information on the format of the /etc/fstab file and the options it contains. Shells shells command-line 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 csh, the C-shell. Many other shells are available + variables. FreeBSD comes with a set of shells, such as + sh, the Bourne Shell, and csh, + the C-shell. Many other shells are available from the FreeBSD Ports Collection that have much more power, such as - tcsh and bash. + tcsh 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've come from Linux or are new to a Unix - command line interface you might try bash. The point is that each + such as tcsh. If you've 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. environment variables 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: enviornment variables 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. Bourne shells 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 + 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: &prompt.user; setenv EDITOR /usr/local/bin/emacs Under Bourne shells: &prompt.user; 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. 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 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: &prompt.user; chsh -s /usr/local/bin/bash Running chsh with no parameters and editing the shell from there would work also. 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: &prompt.root; echo "/usr/local/bin/bash" >> /etc/shells Then rerun chsh. Text Editors text editors editors A lot of configuration in FreeBSD is done by editing a text file. 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. ee 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 + 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. vi editors vi emacs editors emacs 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. For More Information... Manual pages man pages The most comprehensive documentation on FreeBSD is in the form of man 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: &prompt.user; man command command is the name of the command you wish to learn about. For example, to learn more about ls command type: &prompt.user; man ls The online manual is divided up into numbered sections: User commands. System calls and error numbers. Functions in the C libraries. Device drivers. File formats. Games and other diversions. Miscellaneous information. System maintenance and operation commands. 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: + 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: &prompt.user; 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 &man.chmod.1; refers to the chmod user command and &man.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 switch: &prompt.user; 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: &prompt.user; cd /usr/bin &prompt.user; man -f * or &prompt.user; cd /usr/bin &prompt.user; whatis * which does the same thing. GNU Info Files Free Software Foundation FreeBSD includes many applications and utilities produced by the Free Software Foundation (FSF). In addition to man 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 &man.info.1; command, simply type: &prompt.user; info For a brief introduction, type h. For a quick command reference, type ?. diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml index e578ba9a18..4a05f7b9df 100644 --- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml @@ -1,853 +1,853 @@ Configuration and Tuning This chapter was written by &a.chern; and &a.murray using information originally written by &a.msmith; and &a.dillon; Synopsis System configuration System optimization Configuring a system correctly can substantially reduce the amount of work and hassle 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. Initial Configuration Partition layout Partition layout /etc /var /usr Base Partitions When laying out your filesystem with &man.disklabel.8; or &man.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, print spool and log files. Mail boxes 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 mailserver, a /var partition of over a gig 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 &man.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-emulated 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. Some users who have used &man.sysinstall.8;'s Auto-defaults partition sizer have found either their root or /var partitions too small later on. Partition wisely and generously. Swap Partition swap sizing 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 don't normally use much swap, it can give you more time to recover from a runaway program before being forced to reboot. Why Partition? Why partition at all? Why not create one big root partition and be done with it? Then I don't 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. Core Configuration rc files rc.conf 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 overheads down. The recommended approach is to place site-wide configuration into another file, eg. /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 &man.sh.1; it is trivial to achieve this. For example: rc.conf: . rc.conf.site hostname="node15.webcompany.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 eg. rsync, whilst the rc.conf file remains unique. Upgrading the system eg. via &man.sysinstall.8; or 'make world' will not overwrite the rc.conf file, so system configuration information will not be lost. 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. /usr/local/etc 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, here is /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 It can be quickly seen that only the srm.conf file has been changed. A later update of the apache port would not overwrite this changed file. Starting Services 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. /usr/local/etc/rc.d 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 systemwide services that are to be run as root, or that + 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 at startup, and the at shutdown to allow it to carry out its purpose. Some services expect to be invoked by &man.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 &man.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. 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 &man.cron.8; daemon to start system services. This approach has a number of advantages, not - least being that because cron runs these processes as the owner - of the crontab, services may be started and maintained by - non-root users. - - This takes advantage of an undocumented feature of cron; the + least being that because &man.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 an undocumented feature of &man.cron.8; the time specification may be replaced by '@reboot', which will - cause the job to be run when cron is started shortly after + cause the job to be run when &man.cron.8; is started shortly after system boot. Virtual Hosts virtual hosts ip aliases 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, eg. _alias1, _alias2, etc. 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" Configuration Files <filename>/etc</filename> 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 configuration, other MTA configuration files. /etc/ppp Configuration for both user- and kernel-ppp programs. /etc/namedb Default location for bind(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, eg. bind(8) zone files, database files, and so on. Hostnames hostnames DNS /etc/resolv.conf 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 nameserver the resolver should query. The servers are queried in the order listed with a maximum of three. search Search list hostname lookup. This is normally determined by the domain of the local hostname. domain The local domain name. A typical resolv.conf: search foobar.com nameserver 147.11.1.11 nameserver 147.11.100.30 &man.dhclient.8; usually rewrites resolv.conf with information received from the DHCP server. <filename>/etc/hosts</filename> 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 &man.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.foobar.com myRealHostname foobar1 foobar2 Consult &man.hosts.5; for more information. Log File Configuration log files <filename>syslog.conf</filename> syslog.conf syslog.conf is the configuration file for the &man.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) manpage. *.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 loghost 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 &man.syslog.conf.5; manpage for more information. <filename>newsyslog.conf</filename> newsyslog.conf newsyslog.conf is the configuration file for &man.newsyslog.8;, a program that is scheduled to run normally by &man.cron.8; &man.newsyslog.8; determines when log files require archiving or rearranging. logfile is moved to logfile.1, logfile.1 is moved to logfile.2, and so on. - Additionally, the log files may be archived in gzip format + Additionally, the log files may be archived in &man.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$ # # logfilename [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 &man.newsyslog.8; manpage for more information. <filename>sysctl.conf</filename> sysctl.conf sysctl 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 Tuning with sysctl sysctl Tuning with sysctl &man.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 &man.sysctl.8; At its core, &man.sysctl.8; serves to do two functions: read and modify system settings. To view all readable variables: &prompt.user; sysctl -a To read a particular variable, for example, kern.maxproc: &prompt.user; sysctl kern.maxproc kern.maxproc: 1044 To set a particular variable, use the = option: &prompt.root; 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. Tuning disks Sysctl Variables vfs.vmiodirenable vfs.vmiodirenable The vfs.vmiodirenable sysctl variable defaults to 0 (off) (though soon it will default to 1) and may be set to 0 (off) or 1 (on). This parameter controls how directories are cached by the system. Most directories are small and use but a single fragment (typically 1K) in the filesystem and even 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. The advantage is that all of memory is now available for caching directories. The disadvantage is that 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. hw.ata.wc 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. Basically the problem is that IDE drives lie about when a write completes. With IDE write caching turned on, IDE hard drives will not only write data to disk out of order, they will sometimes delay some of the blocks indefinitely when under heavy disk loads. A crash or power failure can result in serious filesystem corruption. So our default was changed to be safe. Unfortunately, the result was such a huge loss in performance that we caved in and changed the default back to on 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. Please see &man.ata.4;. SoftUpdates SoftUpdates tunefs The &man.tunefs.8; can be used to fine-tune a filesystem. In this situation, we are only concerned with its ability to toggle softupdates on and off, which is done so by: &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem A filesystem cannot be modified with &man.tunefs.8; while it is mounted. A good time to enable SoftUpdates is before any partitions have been mounted, in single-user mode. SoftUpdates drastically improves meta-data performance, mainly file creation and deletion, through the use of a memory cache. We recommend turning SoftUpdates on on all of your filesystems. There are two downsides to SoftUpdates that you should be aware of: First, softupdates 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 you crash you may lose more work than otherwise. Secondly, softupdates delays the freeing of filesystem blocks. If you have a filesystem (such as the root filesystem) which is close to full, doing a major - update of it, e.g. make installworld, can run it out of space and - cause the update to fail. + update of it, e.g. make installworld, can run it + out of space and cause the update to fail. Tuning kernel limits Tuning kernel limits File/process limits kern.maxfiles 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 dmesg. + in dmesg. 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 config. - kern.maxfiles grows proportionally to the - value of maxusers. + dictated by the option in your + kernel config. kern.maxfiles grows + proportionally to the value of . \ No newline at end of file diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index ffcbe899c0..bb2f641176 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,1526 +1,1531 @@ The Cutting Edge Restructured, reorganized, and parts updated by &a.jim; March 2000. Original work by &a.jkh;, &a.phk;, &a.jdp;, and &a.nik; with feedback from various others. Synopsis &os; is under constant development between releases. For people who want to be on the cutting edge, there are several easy mechanisms for keeping your system in sync with the latest developments. Be warned—the cutting edge is not for everyone! This chapter will help you decide if you want to track the development system, or stick with one of the released versions. &os.current; vs. &os.stable; -CURRENT -STABLE There are two development branches to FreeBSD; &os.current; and &os.stable;. This section will explain a bit about each and describe how to keep your system up-to-date with each respective tree. &os.current; will be discussed first, then &os.stable;. Staying Current with &os; As you are reading this, keep in mind that &os.current; is the bleeding edge of &os; development and that if you are new to &os;, you are most likely going to want to think twice about running it. What is &os.current;? snapshot &os.current; is, quite literally, nothing more than a daily snapshot of the working sources for &os;. These include work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. While many of us compile almost daily from &os.current; sources, there are periods of time when the sources are literally un-compilable. These problems are generally resolved as expeditiously as possible, but whether or not &os.current; sources bring disaster or greatly desired functionality can literally be a matter of which part of any given 24 hour period you grabbed them in! Who needs &os.current;? &os.current; is made generally available for 3 primary interest groups: Members of the &os; group who are actively working on some part of the source tree and for whom keeping current is an absolute requirement. Members of the &os; group who are active testers, willing to spend time working through problems in order to ensure that &os.current; remains as sane as possible. These are also people who wish to make topical suggestions on changes and the general direction of &os;. Peripheral members of the &os; (or some other) group who merely wish to keep an eye on things and use the current sources for reference purposes (e.g. for reading, not running). These people also make the occasional comment or contribute code. What is &os.current; <emphasis>not</emphasis>? A fast-track to getting pre-release bits because you heard there is some cool new feature in there and you want to be the first on your block to have it. A quick way of getting bug fixes. In any way officially supported by us. We do our best to help people genuinely in one of the 3 legitimate &os.current; categories, but we simply do not have the time to provide tech support for it. This is not because we are mean and nasty people who do not like helping people out (we would not even be doing &os; if we were), it is literally because we cannot answer 400 messages a day and actually work on FreeBSD! Given the choice between improving &os; and answering lots of questions, most developers, and users, would probably opt for the former. Using &os.current; Join the &a.current; and the &a.cvsall; . This is not just a good idea, it is essential. If you are not on the &a.current;, you will not see the comments that people are making about the current state of the system and thus will probably end up stumbling over a lot of problems that others have already found and solved. Even more importantly, you will miss out on important bulletins which may be critical to your system's continued health. The &a.cvsall; mailing list will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-current subscribe cvs-all majordomo Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. Grab the sources from ftp.FreeBSD.org. You can do this in one of three ways: cvsup cron -CURRENT Syncing with CVSup Use the cvsup program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then - on. Many people run cvsup from cron and keep their + on. Many people run cvsup from + cron and keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 -CURRENT Downloading with ftp Use ftp. The source tree for &os.current; is always exported on: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/. We also use wu-ftpd which allows compressed/tarred grabbing of whole trees. e.g. you see: usr.bin/lex You can do the following to get the whole directory as a tar file: ftp> cd usr.bin ftp> get lex.tar -CURRENT Syncing with CTM Use the CTM facility. If you have very bad connectivity (high price connections or only e-mail access) CTM is an option. However, it is a lot of hassle and can give you broken files. This leads to it being rarely used, which again increases the chance of it not working for fairly long periods of time. We recommend using CVSup for anybody with a 9600bps modem or faster connection. If you are grabbing the sources to run, and not just look at, then grab all of &os.current;, not just selected portions. The reason for this is that various parts of the source depend on updates elsewhere, and trying to compile just a subset is almost guaranteed to get you into trouble. Before compiling &os.current;, read the Makefilein /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.current; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. Be active! If you are running &os.current;, we want to know what you have to say about it, especially if you have suggestions for enhancements or bug fixes. Suggestions with accompanying code are received most enthusiastically! Staying Stable with &os; What is &os.stable;? -STABLE &os.stable; is our development branch for a more low-key and conservative set of changes intended for our next mainstream release. Any changes to this branch will have debuted in &os.current; first, helping to reduce (but not eliminate) the chance that the changes will cause problems. Who needs &os.stable;? If you are interested in tracking the FreeBSD development process, and you want early access to the features that will appear in the next point release of FreeBSD then you should consider following &os.stable;. Tracking &os.stable; also gives you easy access to security fixes for FreeBSD as they are released. However, you do not need to track &os.stable; to do this, as every security advisory for FreeBSD explains how to fix the problem for the releases it affects. - Although we endeavour to ensure that the &os.stable; branch + Although we endeavor to ensure that the &os.stable; branch compiles and runs at all times, this cannot be guaranteed. In addition, while code is developed in &os.current; before including it in &os.stable;, more people run &os.stable; than &os.current;, so it is inevitable that bugs and corner cases will sometimes be found in &os.stable; that were not apparent in &os.current;. For these reasons, we do not recommend that you blindly track &os.stable;, and it is particularly important that you do not update any production servers to &os.stable; without first thoroughly testing the code in your development environment. If you do not have the resources to do this then we recommend that you run the most recent release of FreeBSD, and use the binary update mechanism to move from release to release. Using &os.stable; -STABLE using Join the &a.stable;. This will keep you informed of build-dependencies that may appear in &os.stable; or any other issues requiring special attention. Developers will also make announcements in this mailing list when they are contemplating some controversial fix or update, giving the users a chance to respond if they have any issues to raise concerning the proposed change. The &a.cvsall; mailing list will allow you to see the commit log entry for each change as it is made along with any pertinent information on possible side-effects. To join these lists, send mail to &a.majordomo; and specify the following in the body of your message: subscribe freebsd-stable subscribe cvs-all majordomo Optionally, you can also say help and Majordomo will send you full help on how to subscribe and unsubscribe to the various other mailing lists we support. If you are installing a new system and want it to be as stable as possible, you can simply grab the latest dated branch snapshot from ftp://releng4.FreeBSD.org/pub/FreeBSD/ and install it like any other release. If you are already running a previous release of &os; and wish to upgrade via sources then you can easily do so from ftp.FreeBSD.org. This can be done in one of three ways: CTM -STABLE syncing with CTM Use the CTM facility. Unless you have a good TCP/IP connection at a flat rate, this is the way to do it. -STABLE syncing with CVSup Use the cvsup program with this supfile. This is the second most recommended method, since it allows you to grab the entire collection once and then only what has changed from then - on. Many people run cvsup from cron to keep their + on. Many people run cvsup from + cron to keep their sources up-to-date automatically. For a fairly easy interface to this, simply type:
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 -STABLE downloading with FTP Use ftp. The source tree for &os.stable; is always exported on: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ We also use wu-ftpd which allows compressed/tarred grabbing of whole trees. e.g. you see: usr.bin/lex You can do the following to get the whole directory for you as a tar file: ftp> cd usr.bin ftp> get lex.tar Essentially, if you need rapid on-demand access to the source and communications bandwidth is not a consideration, use cvsup or ftp. Otherwise, use CTM. -STABLE compiling Before compiling &os.stable;, read the Makefile in /usr/src carefully. You should at least run a make world the first time through as part of the upgrading process. Reading the &a.stable; will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. Synchronizing Your Source There are various ways of using an Internet (or email) connection to stay up-to-date with any given area of the &os; project sources, or all areas, depending on what interests you. The primary services we offer are Anonymous CVS, CVSup, and CTM. While it is possible to update only parts of your source tree, the only supported update procedure is to update the entire tree and recompile both userland (i.e., all the programs that run in user space, such as those in /bin and /sbin) and kernel sources. Updating only part of your source tree, only the kernel, or only userland will often result in problems. These problems may range from compile errors to kernel panics or data corruption. anonymous CVS Anonymous CVS and CVSup use the pull model of updating sources. In the case of - CVSup the user (or a cron script) invokes + CVSup the user (or a + cron script) invokes the cvsup program, and it interacts with a cvsupd server somewhere to bring your files up-to-date. The updates you receive are up-to-the-minute and you get them when, and only when, you want them. You can easily restrict your updates to the specific files or directories that are of interest to you. Updates are generated on the fly by the server, according to what you have and what you want to have. Anonymous CVS is quite a bit more simplistic than CVSup in that it's just an extension to CVS which allows it to pull changes directly from a remote CVS repository. CVSup can do this far more efficiently, but Anonymous CVS is easier to use. CTM CTM, on the other hand, does not interactively compare the sources you have with those on the master archive or otherwise pull them across.. Instead, a script which identifies changes in files since its previous run is executed several times a day on the master CTM machine, any detected changes being compressed, stamped with a sequence-number and encoded for transmission over email (in printable ASCII only). Once received, these CTM deltas can then be handed to the &man.ctm.rmail.1; utility which will automatically decode, verify and apply the changes to the user's copy of the sources. This process is far more efficient than CVSup, and places less strain on our server resources since it is a push rather than a pull model. There are other trade-offs, of course. If you inadvertently wipe out portions of your archive, CVSup will detect and rebuild the damaged portions for you. CTM won't do this, and if you wipe some portion of your source tree out (and don't have it backed up) then you will have to start from scratch (from the most recent CVS base delta) and rebuild it all with CTM or, with anoncvs, simply delete the bad bits and resync. More information about Anonymous CVS, CTM, and CVSup is available further down in this section. Using <command>make world</command> make world Once you have synchronized your local source tree against a particular version of &os; (&os.stable;, &os.current;, and so on) you can then use the source tree to rebuild the system. Take a backup It cannot be stressed enough how important it is to take a backup of your system before you do this. While rebuilding the world is (as long as you follow these instructions) an easy task to do, there will inevitably be times when you make mistakes, or when mistakes made by others in the source tree render your system unbootable. Make sure you have taken a backup. And have a fix-it floppy to hand. You will probably never have to use it, but it is better to be safe than sorry! Subscribe to the right mailing list mailing list The &os.stable; and &os.current; branches are, by their nature, in development. People that contribute to &os; are human, and mistakes occasionally happen. Sometimes these mistakes can be quite harmless, just causing your system to print a new diagnostic warning. Or the change may be catastrophic, and render your system unbootable or destroy your filesystems (or worse). If problems like these occur, a heads up is posted to the appropriate mailing list, explaining the nature of the problem and which systems it affects. And an all clear announcement is posted when the problem has been solved. If you try and track &os.stable; or &os.current; and do not read the stable@FreeBSD.org or current@FreeBSD.org mailing lists then you are asking for trouble. Read <filename>/usr/src/UPDATING</filename> Before you do anything else, read /usr/src/UPDATING (or the equivalent file wherever you have a copy of the source code). This file should contain important information about problems you might encounter, or specify the order in which you might have to run certain commands. If UPDATING contradicts something you read here, UPDATING takes precedence. Reading UPDATING is not an acceptable substitute for subscribing to the correct mailing list, as described previously. The two requirements are complementary, not exclusive. Check <filename>/etc/make.conf</filename> make.conf Examine the files /etc/defaults/make.conf and /etc/make.conf. The first contains some default defines – most of which are commented out. To make use of them when you rebuild your system from source, add them to /etc/make.conf. Keep in mind that anything you add to /etc/make.conf is also used every time you run make, so it is a good idea to set them to something sensible for your system. A typical user will probably want to copy the CFLAGS and NOPROFILE lines found in /etc/defaults/make.conf to /etc/make.conf and uncomment them. - Examine the other definitions (COPTFLAGS, NOPORTDOCS and so + Examine the other definitions (COPTFLAGS, + NOPORTDOCS and so on) and decide if they are relevant to you. Update <filename>/etc/group</filename> The /etc directory contains a large part of your system's configuration information, as well as scripts that are run at system startup. Some of these scripts change from version to version of FreeBSD. Some of the configuration files are also used in the day to day running of the system. In particular, /etc/group. There have been occasions when the installation part of make world has expected certain usernames or groups to exist. When performing an upgrade it is likely that these groups did not exist. This caused problems when upgrading. The most recent example of this is when the ppp subsystem were installed using a non-existent (for them) group name. The solution is to examine /usr/src/etc/group and compare its list of groups with your own. If there are any groups in the new file that are not in your file then copy them over. Similarly, you should rename any groups in /etc/group which have the same GID but a different name to those in /usr/src/etc/group. If you are feeling particularly paranoid, you can check your system to see which files are owned by the group you are renaming or deleting. &prompt.root; find / -group GID -print will show all files owned by group GID (which can be either a group name or a numeric group ID). Drop to single user mode single-user mode You may want to compile the system in single user mode. Apart from the obvious benefit of making things go slightly faster, reinstalling the system will touch a lot of important system files, all the standard system binaries, libraries, include files and so on. Changing these on a running system (particularly if you have active users on the system at the time) is asking for trouble. multi-user mode Another method is to compile the system in multi-user mode, and then drop into single user mode for the installation. If you would like to do it this way, simply hold off on the following steps until the build has completed. As the superuser, you can execute &prompt.root; from a running system, which will drop it to single user mode. Alternatively, reboot the system, and at the boot prompt, enter the flag. The system will then boot single user. At the shell prompt you should then run: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a This checks the filesystems, remounts / read/write, mounts all the other UFS filesystems referenced in /etc/fstab and then turns swapping on. Remove <filename>/usr/obj</filename> As parts of the system are rebuilt they are placed in directories which (by default) go under /usr/obj. The directories shadow those under /usr/src. You can speed up the make world process, and possibly save yourself some dependency headaches by removing this directory as well. Some files below /usr/obj may have the immutable flag set (see &man.chflags.1; for more information) which must be removed first. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * Recompile the source Saving the output It is a good idea to save the output you get from running &man.make.1; to another file. If something goes wrong you will have a copy of the error message. While this might not help you in diagnosing what has gone wrong, it can help others if you post your problem to one of the &os; mailing lists. The easiest way to do this is to use the &man.script.1; command, with a parameter that specifies the name of the file to save all output to. You would do this immediately before rebuilding the world, and then type exit when the process has finished. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … If you do this, do not save the output in /tmp. This directory may be cleared next time you reboot. A better place to store it is in /var/tmp (as in the previous example) or in root's home directory. Compile and install the base system You must be in the /usr/src directory... &prompt.root; cd /usr/src (unless, of course, your source code is elsewhere, in which case change to that directory instead). make To rebuild the world you use the &man.make.1; command. This command reads instructions from the Makefile, which describes how the programs that comprise &os; should be rebuilt, the order in which they should be built, and so on. The general format of the command line you will type is as follows: &prompt.root; make In this example, is an option that you would pass to &man.make.1;. See the &man.make.1; manual page for an example of the options you can pass. passes a variable to the Makefile. The behavior of the Makefile is controlled by these variables. These are the same variables as are set in /etc/make.conf, and this provides another way of setting them. &prompt.root; make -DNOPROFILE=true target is another way of specifying that profiled libraries should not be built, and corresponds with the NOPROFILE= true # Avoid compiling profiled libraries lines in /etc/make.conf. target tells &man.make.1; what you want to do. Each Makefile defines a number of different targets, and your choice of target determines what happens. Some targets are listed in the Makefile, but are not meant for you to run. Instead, they are used by the build process to break out the steps necessary to rebuild the system into a number of sub-steps. Most of the time you won't need to pass any parameters to &man.make.1;, and so your command like will look like this: &prompt.root; make target Beginning with version 2.2.5 of &os; (actually, it was first created on the &os.current; branch, and then retrofitted to &os.stable; midway between 2.2.2 and 2.2.5) the world target has been split in two. buildworld and installworld. As the names imply, buildworld builds a complete new tree under /usr/obj, and installworld installs this tree on the current machine. This is very useful for 2 reasons. First, it allows you to do the build safe in the knowledge that no components of your running system will be affected. The build is self hosted. Because of this, you can safely run buildworld on a machine running in multi-user mode with no fear of ill-effects. It is still recommended that you run the installworld part in single user mode, though. Secondly, it allows you to use NFS mounts to upgrade multiple machines on your network. If you have three machines, A, B and C that you want to upgrade, run make buildworld and make installworld on A. B and C should then NFS mount /usr/src and /usr/obj from A, and you can then run make installworld to install the results of the build on B and C. Although the world target still exists, you are strongly encouraged not to use it. Run &prompt.root; make buildworld It is now possible to specify a -j option to make which will cause it to spawn several simultaneous processes. This is most useful on multi-CPU machines. However, since much of the compiling process is IO bound rather than CPU bound it is also useful on single CPU machines. On a typical single-CPU machine you would run: &prompt.root; make -j4 buildworld &man.make.1; will then have up to 4 processes running at any one time. Empirical evidence posted to the mailing lists shows this generally gives the best performance benefit. If you have a multi-CPU machine and you are using an SMP configured kernel try values between 6 and 10 and see how they speed things up. Be aware that this is still somewhat experimental, and commits to the source tree may occasionally break this feature. If the world fails to compile using this parameter try again without it before you report any problems. Timings make world timings Many factors influence the build time, but currently a 500MHz Pentium 3 with 128MB of RAM takes about 3 and a half hours to build the &os.current; tree, with no tricks or shortcuts used during the process. A &os.stable; tree will build somewhat faster. Compile and install a new kernel kernel compiling To take full advantage of your new system you should recompile the kernel. This is practically a necessity, as certain memory structures may have changed, and programs like &man.ps.1; and &man.top.1; will fail to work until the kernel and source code versions are the same. The simplest, safest way to do this is to build and install a kernel based on GENERIC. While GENERIC may not have all the necessary devices for your system, it should contain everything necessary to boot your system back to single user mode. This is a good test that the new system works properly. After booting from GENERIC and verifying that your system works you can then build a new kernel based on your normal kernel config file. If you are upgrading to &os; 4.0 or above then the standard kernel build procedure (as described in ) is deprecated. Instead, you should run these commands. &prompt.root; cd /usr/src &prompt.root; make buildkernel &prompt.root; make installkernel If you are upgrading to a version of &os; below 4.0 you should use the standard kernel build procedure. However, it is recommended that you use the new version of &man.config.8;, using a command line like this. &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME Reboot in to single user mode single-user mode You should reboot in to single user mode to test the new kernel works. Do this by following the instructions in . Install the new system binaries If you were building a version of &os; recent enough to have used make buildworld then you should now use the installworld to install the new system binaries. Run &prompt.root; make installworld If you specified variables on the make buildworld command line, you must specify the same variables in the make installworld command line. This does not necessarily hold true for other options; for example, must never be used with installworld. For example, if you ran: &prompt.root; make -DNOPROFILE=true buildworld you must install the results with: &prompt.root; make -DNOPROFILE=true installworld otherwise it would try and install profiled libraries that had not been built during the make buildworld phase. Update files not updated by <command>make world</command> Remaking the world will not update certain directories (in particular, /etc, /var and /usr) with new or changed configuration files. mergemaster The simplest way to update these files is to use &man.mergemaster.8;, though it is possible to do it manually if you would prefer to do that. We strongly recommend you use &man.mergemaster.8;, however, and if you do then you can skip forward to the next section, since &man.mergemaster.8; is very simple to use. You should read the manual page first, and make a backup of /etc in case anything goes wrong. If you wish to do the update manually, you cannot just copy over the files from /usr/src/etc to /etc and have it work. Some of these files must be installed first. This is because the /usr/src/etc directory is not a copy of what your /etc directory should look like. In addition, there are files that should be in /etc that are not in /usr/src/etc. The simplest way to do this by hand is to install the files into a new directory, and then work through them looking for differences. Backup your existing <filename>/etc</filename> Although, in theory, nothing is going to touch this directory automatically, it is always better to be sure. So copy your existing /etc directory somewhere safe. Something like: &prompt.root; cp -Rp /etc /etc.old does a recursive copy, preserves times, ownerships on files and suchlike. You need to build a dummy set of directories to install the new /etc and other files into. /var/tmp/root is a reasonable choice, and there are a number of subdirectories required under this as well. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution This will build the necessary directory structure and install the files. A lot of the subdirectories that have been created under /var/tmp/root are empty and should be deleted. The simplest way to do this is to: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null This will remove all empty directories. (Standard error is redirected to /dev/null to prevent the warnings about the directories that are not empty.) /var/tmp/root now contains all the files that should be placed in appropriate locations below /. You now have to go through each of these files, determining how they differ with your existing files. Note that some of the files that will have been installed in /var/tmp/root have a leading /var/tmp/root/ and /var/tmp/root/root/, although there may be others (depending on when you are reading this. Make sure you use The simplest way to do this is to use &man.diff.1; to compare the two files. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells This will show you the differences between your /etc/shells file and the new /etc/shells file. Use these to decide whether to merge in changes that you have made or whether to copy over your old file. Name the new root directory (<filename>/var/tmp/root</filename>) with a time stamp, so you can easily compare differences between versions Frequently rebuilding the world means that you have to update /etc frequently as well, which can be a bit of a chore. You can speed this process up by keeping a copy of the last set of changed files that you merged into /etc. The following procedure gives one idea of how to do this. Make the world as normal. When you want to update /etc and the other directories, give the target directory a name based on the current date. If you were doing this on the 14th of February 1998 you could do the following. &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Merge in the changes from this directory as outlined above. Do not remove the /var/tmp/root-19980214 directory when you have finished. When you have downloaded the latest version of the source and remade it, follow step 1. This will give you a new directory, which might be called /var/tmp/root-19980221 (if you wait a week between doing updates). You can now see the differences that have been made in the intervening week using &man.diff.1; to create a recursive diff between the two directories. &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Typically, this will be a much smaller set of differences than those between /var/tmp/root-19980221/etc and /etc. Because the set of differences is smaller, it is easier to migrate those changes across into your /etc directory. You can now remove the older of the two /var/tmp/root-* directories. &prompt.root; rm -rf /var/tmp/root-19980214 Repeat this process every time you need to merge in changes to /etc. You can use &man.date.1; to automate the generation of the directory names. &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` Update <filename>/dev</filename> DEVFS DEVFS If you are using DEVFS this is unnecessary. In most cases, the &man.mergemaster.8 tool will realize when it is necessary to update the devices, and offer to complete it automatically. These instructions tell how to update the devices manually. For safety's sake, this is a multi-step process. Copy /var/tmp/root/dev/MAKEDEV to /dev. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV If you used &man.mergemaster.8; to update /etc, then your MAKEDEV script should have been updated already, though it can't hurt to check (with &man.diff.1;) and copy it manually if necessary. Now, take a snapshot of your current /dev. This snapshot needs to contain the permissions, ownerships, major and minor numbers of each filename, but it should not contain the time stamps. The easiest way to do this is to use &man.awk.1; to strip out some of the information. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out Remake all the devices. &prompt.root; Write another snapshot of the directory, this time to /var/tmp/dev2.out. Now look through these two files for any devices that you missed creating. There should not be any, but it is better to be safe than sorry. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out You are most likely to notice disk slice discrepancies which will involve commands such as &prompt.root; sh MAKEDEV sd0s1 to recreate the slice entries. Your precise circumstances may vary. Update <filename>/stand</filename> This step is included only for completeness. It can safely be omitted. For the sake of completeness, you may want to update the files in /stand as well. These files consist of hard links to the /stand/sysinstall binary. This binary should be statically linked, so that it can work when no other filesystems (and in particular /usr) have been mounted. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install You are now done. After you have verified that everything appears to be in the right place you can reboot the system. A simple &man.fastboot.8; should do it.</para> <screen>&prompt.root; <userinput>fastboot</userinput></screen> </sect2> <sect2> <title>Finished You should now have successfully upgraded your &os; system. Congratulations. If things went slightly wrong, it is easy to rebuild a particular piece of the system. For example, if you accidently deleted /etc/magic as part of the upgrade or merge of /etc, the &man.file.1; command will stop working. In this case, the fix would be to run: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; <qandaentry> <question> <para>Do I need to re-make the world for every change?</para> </question> <answer> <para>There is no easy answer to this one, as it depends on the nature of the change. For example, if you just ran CVSup, and it has shown the following files as being updated,</para> <screen><filename>src/games/cribbage/instr.c</filename> <filename>src/games/sail/pl_main.c</filename> <filename>src/release/sysinstall/config.c</filename> <filename>src/release/sysinstall/media.c</filename> <filename>src/share/mk/bsd.port.mk</filename></screen> <para>it probably is not worth rebuilding the entire world. You could just go to the appropriate sub-directories and <command>make all install</command>, and that's about it. But if something major changed, for example <filename>src/lib/libc/stdlib</filename> then you should either re-make the world, or at least those parts of it that are statically linked (as well as anything else you might have added that is statically linked).</para> <para>At the end of the day, it is your call. You might be happy re-making the world every fortnight say, and let changes accumulate over that fortnight. Or you might want to re-make just those things that have changed, and are confident you can spot all the dependencies.</para> <para>And, of course, this all depends on how often you want to upgrade, and whether you are tracking &os.stable; or &os.current;.</para> </answer> </qandaentry> <qandaentry> <question> <para>My compile failed with lots of signal 11 (or other signal number) errors. What has happened?</para> </question> <answer> <indexterm><primary>signal 11</primary></indexterm> <para>This is normally indicative of hardware problems. (Re)making the world is an effective way to stress test your hardware, and will frequently throw up memory problems. These normally manifest themselves as the compiler mysteriously dying on receipt of strange signals.</para> <para>A sure indicator of this is if you can restart the make and it dies at a different point in the process.</para> <para>In this instance there is little you can do except start swapping around the components in your machine to determine which one is failing.</para> </answer> </qandaentry> <qandaentry> <question> <para>Can I remove <filename>/usr/obj</filename> when I have finished?</para> </question> <answer> <para>The short answer is yes.</para> <para><filename>/usr/obj</filename> contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the <quote/make world/ process is to remove this directory and start afresh. In this case, keeping <filename>/usr/obj</filename> around after you have finished makes little sense, and will free up a large chunk of disk space (currently about 340MB).</para> <para>However, if you know what you are doing you can have <quote/make world/ skip this step. This will make subsequent builds run much faster, since most of sources will not need to be recompiled. The flip side of this is that subtle dependency problems can creep in, causing your build to fail in odd ways. This frequently generates noise on the &os; mailing lists, when one person complains that their build has failed, not realising that it is because they have tried to cut corners.</para> <para>If you want to live dangerously then make the world, passing the <makevar>NOCLEAN</makevar> definition to make, like this:</para> <screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen> </answer> </qandaentry> <qandaentry> <question> <para>Can interrupted builds be resumed?</para> </question> <answer> <para>This depends on how far through the process you got before you found a problem.</para> <para><emphasis>In general</emphasis> (and this is not a hard and fast rule) the <quote>make world</quote> process builds new copies of essential tools (such as &man.gcc.1;, and &man.make.1;) and the system libraries. These tools and libraries are then installed. The new tools and libraries are then used to rebuild themselves, and are installed again. The entire system (now including regular user programs, such as &man.ls.1; or &man.grep.1;) is then rebuilt with the new system files.</para> <para>If you are at the last stage, and you know it (because you have looked through the output that you were storing) then you can (fairly safely) do</para> <screen><emphasis>… fix the problem …</emphasis> &prompt.root; <userinput>cd /usr/src</userinput> &prompt.root; <userinput>make -DNOCLEAN all</userinput></screen> <para>This will not undo the work of the previous <quote>make world</quote>.</para> <para>If you see the message <screen>-------------------------------------------------------------- Building everything.. --------------------------------------------------------------</screen> in the <quote>make world</quote> output then it is probably fairly safe to do so.</para> <para>If you do not see that message, or you are not sure, then it is always better to be safe than sorry, and restart the build from scratch.</para> </answer> </qandaentry> <qandaentry> <question> <indexterm><primary>NFS</primary></indexterm> <para>Can I use one machine as a <emphasis/master/ to upgrade lots of machines (NFS)?</para> </question> <answer> <para>This is a fairly easy task, and can save hours of compile - time for many machines. Simply run the buildworld on a central + time for many machines. Simply run the + <makevar>buildworld</makevar> on a central machine, and then NFS mount <filename>/usr/src</filename> and <filename>/usr/obj</filename> on the remote machine and - installworld there.</para> + <makevar>installworld</makevar> there.</para> </answer> </qandaentry> <qandaentry> <question> <para>How can I speed up making the world?</para> </question> <answer> <itemizedlist> <listitem> <para>Run in single user mode.</para> </listitem> <listitem> <para>Put the <filename>/usr/src</filename> and <filename>/usr/obj</filename> directories on separate filesystems held on separate disks. If possible, put these disks on separate disk controllers.</para> </listitem> <listitem> <para>Better still, put these filesystems across multiple - disks using the <quote>ccd</quote> (concatenated disk + disks using the &man.ccd.4 (concatenated disk driver) device.</para> </listitem> <listitem> <para>Turn off profiling (set <quote>NOPROFILE=true</quote> in <filename>/etc/make.conf</filename>). You almost certainly do not need it.</para> </listitem> <listitem> <para>Also in <filename>/etc/make.conf</filename>, set - <quote>CFLAGS</quote> to something like <quote>-O + <makevar>CFLAGS</makevar> to something like <quote>-O -pipe</quote>. The optimization <quote>-O2</quote> is much slower, and the optimization difference between <quote>-O</quote> and <quote>-O2</quote> is normally negligible. <quote>-pipe</quote> lets the compiler use pipes rather than temporary files for communication, which saves disk access (at the expense of memory).</para> </listitem> <listitem> <para>Pass the <option>-j<n></option> option to make to run multiple processes in parallel. This usually helps regardless of whether you have a single or a multi processor machine.</para> </listitem> <listitem><para>The filesystem holding <filename>/usr/src</filename> can be mounted (or remounted) - with the <quote>noatime</quote> option. This prevents the + with the <option>noatime</option> option. This prevents the filesystem from recording the file access time. You probably do not need this information anyway. <screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen> <warning> <para>The example assumes <filename>/usr/src</filename> is on its own filesystem. If it is not (if it is a part of <filename>/usr</filename> for example) then you will need to use that filesystem mount point, and not <filename>/usr/src</filename>.</para> </warning> </para> </listitem> <listitem> <para>The filesystem holding <filename>/usr/obj</filename> can be mounted (or remounted) with the <quote>async</quote> option. This causes disk writes to happen asynchronously. In other words, the write completes immediately, and the data is written to the disk a few seconds later. This allows writes to be clustered together, and can be a dramatic performance boost.</para> <warning> <para>Keep in mind that this option makes your filesystem more fragile. With this option there is an increased chance that, should power fail, the filesystem will be in an unrecoverable state when the machine restarts.</para> <para>If <filename>/usr/obj</filename> is the only thing on this filesystem then it is not a problem. If you have other, valuable data on the same filesystem then ensure your backups are fresh before you enable this option.</para> </warning> <screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen> <warning> <para>As above, if <filename>/usr/obj</filename> is not on its own filesystem, replace it in the example with the name of the appropriate mount point.</para> </warning> </listitem> </itemizedlist> </answer> </qandaentry> </qandaset> </sect2> </sect1> </chapter> <!-- Local Variables: mode: sgml sgml-declaration: "../chapter.decl" sgml-indent-data: t sgml-omittag: nil sgml-always-quote-attributes: t sgml-parent-document: ("../book.sgml" "part" "chapter") End: --> diff --git a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml index d3c802e30a..c023895ca4 100644 --- a/en_US.ISO8859-1/books/handbook/disks/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/disks/chapter.sgml @@ -1,1200 +1,1202 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/disks/chapter.sgml,v 1.37 2001/07/16 15:02:50 nik Exp $ + $FreeBSD: doc/en_US.ISO8859-1/books/handbook/disks/chapter.sgml,v 1.38 2001/07/19 01:11:52 chern Exp $ --> <chapter id="disks"> <title>Disks Synopsis This chapter covers how to use disks, whether physical, memory, or networked, on FreeBSD. BIOS Drive Numbering Before you install and configure FreeBSD on your system, there is an important subject that you should be aware of if, especially if you have multiple hard drives. DOS Microsoft Windows In a PC running DOS or any of the BIOS-dependent operating systems (WINxxx), 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 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's like switching the cables on the drives, but without having to open the case. SCSI BIOS 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's 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's 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's 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's 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. Disk Naming IDE SCSI RAID fash memory Physical drives come in two main flavors, IDE, or SCSI; but there are also drives backed by RAID controllers, flash memory, and so forth. Since these behave quite differently, they have their own drivers and devices. Physical Disk Naming Conventions Drive type Drive device name IDE hard drives ad in 4.0-RELEASE, wd before 4.0-RELEASE. IDE CDROM drives acd from 4.1-RELEASE, wcd before 4.0-RELEASE. SCSI hard drives da from 3.0-RELEASE, sd before 3.0-RELEASE. SCSI CDROM drives cd Assorted non-standard CDROM drives mcd for Mitsumi CD-ROM, scd for Sony CD-ROM, matcd for Matsushita/Panasonic CD-ROM Floppy drives fd SCSI tape drives sa from 3.0-RELEASE, st before 3.0-RELEASE. IDE tape drives ast from 4.0-RELEASE, wst before 4.0-RELEASE. Flash drives fla for DiskOnChip Flash device from 3.3-RELEASE. RAID drives myxd for Mylex, and amrd for AMI MegaRAID, idad for Compaq Smart RAID. from 4.0-RELEASE. id between 3.2-RELEASE and 4.0-RELEASE.
Slices and Partitions slices partitions dangerously dedicated Physical disks usually contain slices, unless they are dangerously dedicated. Slice numbers follow the device name, prefixed with an s: da0s1. Slices, dangerously dedicated physical drives, and other drives contain partitions, which represented as letters from a to h. b is reserved for swap partitions, and c is an unused partition the size of the entire slice or drive. This is explained in . 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. root filesystem There are various reasons to house some of these directories on separate filesystems. /var contains log/, spool/, and various types of temporary files, and as such, may get filled up. Filling up the root filesystem isn't a good idea, so splitting /var from / is often a good idea. 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. The fstab File filesystems mounted with fstab During the boot process, filesystems listed in /etc/fstab are automatically mounted (unless they are listed with ). The /etc/fstab file contains a list of lines of the following format: device /mount-point fstype options dumpfreq passno device is a device name (which should exist), as explained in the Disk naming conventions above. mount-point is a directory (which should exist), on which to mount the filesystem. fstype is the filesystem type to pass to &man.mount.8;. The default FreeBSD filesystem is ufs. options is either for read-write filesystems, or for read-only filesystems, followed by any other options that may be needed. A common option is for filesystems not normally mounted during the boot sequence. Other options in the &man.mount.8; manual page. dumpfreq is the number of days the filesystem should be dumped, and passno is the pass number during which the filesystem is checked during the boot sequence. The mount Command filesystems mounting The &man.mount.8; command is what is ultimately used to mount filesystems. In its most basic form, you use: &prompt.root; mount device mountpoint There are plenty of options, as mentioned in the &man.mount.8; manual page, but the most common are: mount options Mount all filesystems in /etc/fstab, as modified by , if given. Do everything but actually mount the filesystem. Force the mounting the filesystem. Mount the filesystem read-only. fstype Mount the given filesystem as the given filesystem type, or mount only filesystems of the given type, if given the option. ufs is the default filesystem type. Update mount options on the filesystem. Be verbose. Mount the filesystem read-write. The takes a comma-separated list of the options, including the following: nodev Do not interpret special devices on the filesystem. Useful security option. noexec Do not allow execution of binaries on this filesystem. Useful security option. nosuid Do not interpret setuid or setgid flags on the filesystem. Useful security option. The umount Command filesystems unmounting - The umount command takes, as a parameter, one of a + The &man.umount.8; command takes, as a parameter, one of a mountpoint, a device name, or the or option. All forms take to force unmounting, and for verbosity. and are used to unmount all mounted filesystems, possibly modified by the filesystem types listed after . , however, doesn't attempt to unmount the root filesystem. Adding Disks disks adding Originally contributed by &a.obrien; 26 April 1998 Lets say we want to add a new SCSI disk to a machine that currently only has a single drive. First turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturer. Due the wide variations of procedures to do this, the details are beyond the scope of this document. Login as user root. After you've installed the drive, inspect /var/run/dmesg.boot to ensure the new disk was found. Continuing with our example, the newly added drive will be da1 and we want to mount it on /1 (if you are adding an IDE drive, it will be wd1 in pre-4.0 systems, or ad1 in most 4.X systems). partitions slices fdisk Because FreeBSD runs on IBM-PC compatible computers, it must take into account the PC BIOS partitions. These are different from the traditional BSD partitions. A PC disk has up to four BIOS partition entries. If the disk is going to be truly dedicated to FreeBSD, you can use the dedicated mode. Otherwise, FreeBSD will have to live with in one of the PC BIOS partitions. FreeBSD calls the PC BIOS partitions slices so as not to confuse them with traditional BSD partitions. You may also use slices on a disk that is dedicated to FreeBSD, but used in a computer that also has another operating system installed. This is to not confuse the fdisk utility of the other operating system. In the slice case the drive will be added as /dev/da1s1e. This is read as: SCSI disk, unit number 1 (second SCSI disk), slice 1 (PC BIOS partition 1), and e BSD partition. In the dedicated case, the drive will be added simply as /dev/da1e. Using &man.sysinstall.8; sysinstall adding disks You may use /stand/sysinstall to partition and label a new disk using its easy to use menus. Either login as user root or use the su command. Run /stand/sysinstall and enter the Configure menu. With in the FreeBSD Configuration Menu, scroll down and select the Partition item. Next you should be presented with a list of hard drives installed in your system. If you do not see da1 listed, you need to recheck your physical installation and dmesg output in the file /var/run/dmesg.boot. Select da1 to enter the FDISK Partition Editor. Choose A to use the entire disk for FreeBSD. When asked if you want to remain cooperative with any future possible operating systems, answer YES. Write the - changes to the disk using W. Now exit the - FDISK editor using q. Next you will be + changes to the disk using W. Now exit the + FDISK editor using q. Next you will be asked about the Master Boot Record. Since you are adding a disk to an already running system, choose None. BSD partitions Next enter the Disk Label Editor. This is where you will create the traditional BSD partitions. A disk can have up to eight partitions, labeled a-h. A few of the partition labels have special uses. The a partition is used for the root partition (/). Thus only your system disk (e.g, the disk you boot from) should have an a partition. The b partition is used for swap partitions, and you may have many disks with swap partitions. The c partition addresses the entire disk in dedicated mode, or the entire FreeBSD slice in slice mode. The other partitions are for general use. Sysinstall's Label editor favors the e partition for non-root, non-swap partitions. With in the Label editor, create a single file system using C. When prompted if this will be a FS (file system) or swap, choose FS and give a mount point (e.g, /mnt). When adding a disk in post-install mode, Sysinstall will not create entries in /etc/fstab for you, so the mount point you specify isn't important. You are now ready to write the new label to the disk and create a file system on it. Do this by hitting W. Ignore any errors from Sysinstall that it could not mount the new partition. Exit the Label Editor and Sysinstall completely. The last step is to edit /etc/fstab to add an entry for your new disk. Using Command Line Utilities Using Slices This setup will allow your disk to work correctly with other operating systems that might be installed on your computer and will not confuse other operating systems' fdisk utilities. It is recommended to use this method for new disk installs. Only use dedicated mode if you have a good reason to do so! &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; fdisk -BI da1 #Initialize your new disk &prompt.root; disklabel -B -w -r da1s1 auto #Label it. &prompt.root; disklabel -e da1s1 # Now edit the disklabel you just created and add any partitions. &prompt.root; mkdir -p /1 &prompt.root; newfs /dev/da1s1e # Repeat this for every partition you created. &prompt.root; mount -t ufs /dev/da1s1e /1 # Mount the partition(s) &prompt.root; vi /etc/fstab # When satisfied, add the appropriate entry/entries to your /etc/fstab. If you have an IDE disk, substitute ad for da. On pre-4.X systems use wd. Dedicated OS/2 If you will not be sharing the new drive with another operating system, you may use the dedicated mode. Remember this mode can confuse Microsoft operating systems; however, no damage will be done by them. IBM's OS/2 however, will appropriate any partition it finds which it doesn't understand. &prompt.root; dd if=/dev/zero of=/dev/rda1 bs=1k count=1 &prompt.root; disklabel -Brw da1 auto &prompt.root; disklabel -e da1 # create the `e' partition &prompt.root; newfs -d0 /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 An alternate method is: &prompt.root; dd if=/dev/zero of=/dev/rda1 count=2 &prompt.root; disklabel /dev/rda1 | disklabel -BrR da1 /dev/stdin &prompt.root; newfs /dev/rda1e &prompt.root; mkdir -p /1 &prompt.root; vi /etc/fstab # add an entry for /dev/da1e &prompt.root; mount /1 Virtual Disks: Network, Memory, and File-Based Filesystems virtual disks disks virtual Aside from the disks you physically insert into your computer: floppies, CDs, hard drives, and so forth; other forms of disks are understood by FreeBSD - the virtual disks. NFS Coda disks memory These include network filesystems such as the Network Filesystem and Coda, memory-based filesystems such as md and file-backed filesystems created by vnconfig. vnconfig: file-backed filesystem disks file-backed &man.vnconfig.8; configures and enables vnode pseudo disk devices. A vnode is a representation of a file, and is the focus of file activity. This means that &man.vnconfig.8; uses files to create and operate a filesystem. One possible use is the mounting of floppy or CD images kept in files. To mount an existing filesystem image: Using vnconfig to mount an existing filesystem image &prompt.root; vnconfig vn0 diskimage &prompt.root; mount /dev/vn0c /mnt To create a new filesystem image with vnconfig: Creating a New File-Backed Disk with vnconfig &prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k 5120+0 records in 5120+0 records out &prompt.root; vnconfig -s labels -c vn0 newimage &prompt.root; disklabel -r -w vn0 auto &prompt.root; newfs vn0c Warning: 2048 sector(s) in last cylinder unallocated /dev/rvn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors 5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g) super-block backups (for fsck -b #) at: 32 &prompt.root; mount /dev/vn0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/vn0c 4927 1 4532 0% /mnt md: Memory Filesystem disks memory filesystem - md is a simple, efficient means to do memory + md is a simple, efficient means to do memory filesystems. Simply take a filesystem you've prepared with, for example, &man.vnconfig.8;, and: md memory disk &prompt.root; dd if=newimage of=/dev/md0 5120+0 records in 5120+0 records out &prompt.root; mount /dev/md0c /mnt &prompt.root; df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md0c 4927 1 4532 0% /mnt Disk Quotas accounting disk space disk quotas Quotas are an optional feature of the operating system that allow you to limit the amount of disk space and/or the number of files a user, or members of a group, may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This will prevent one user from consuming all of the available disk space. Configuring Your System to Enable Disk Quotas Before attempting to use disk quotas it is necessary to make sure that quotas are configured in your kernel. This is done by adding the following line to your kernel configuration file: options QUOTA The stock GENERIC kernel does not have this enabled by default, so you will have to configure, build and install a custom kernel in order to use disk quotas. Please refer to the Configuring the FreeBSD Kernel section for more information on kernel configuration. Next you will need to enable disk quotas in /etc/rc.conf. This is done by adding the line: enable_quotas=YES disk quotas checking For finer control over your quota startup, there is an additional configuration variable available. Normally on bootup, the quota integrity of each file system is checked by the quotacheck program. The quotacheck facility insures that the data in the quota database properly reflects the data on the file system. This is a very time consuming process that will significantly affect the time your system takes to boot. If you would like to skip this step, a variable is made available for the purpose: check_quotas=NO If you are running FreeBSD prior to 3.2-RELEASE, the configuration is simpler, and consists of only one variable. Set the following in your /etc/rc.conf: check_quotas=YES Finally you will need to edit /etc/fstab to enable disk quotas on a per-file system basis. This is where you can either enable user or group quotas or both for all of your file systems. To enable per-user quotas on a file system, add the userquota option to the options field in the /etc/fstab entry for the file system you want to enable quotas on. For example: /dev/da1s2g /home ufs rw,userquota 1 2 Similarly, to enable group quotas, use the groupquota option instead of the userquota keyword. To enable both user and group quotas, change the entry as follows: /dev/da1s2g /home ufs rw,userquota,groupquota 1 2 By default the quota files are stored in the root directory of the file system with the names quota.user and quota.group for user and group quotas respectively. See man fstab for more information. Even though that man page says that you can specify an alternate location for the quota files, this is not recommended because the various quota utilities do not seem to handle this properly. At this point you should reboot your system with your new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas you enabled in /etc/fstab, so there is no need to manually create any zero length quota files. In the normal course of operations you should not be required to run the quotacheck, quotaon, or quotaoff commands manually. However, you may want to read their man pages just to be familiar with their operation. Setting Quota Limits disk quotas limits Once you have configured your system to enable quotas, verify that they really are enabled. An easy way to do this is to run: &prompt.root; quota -v You should see a one line summary of disk usage and current quota limits for each file system that quotas are enabled on. You are now ready to start assigning quota limits with the edquota command. You have several options on how to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. You may limit allocations based on disk space (block quotas) or number of files (inode quotas) or a combination of both. Each of these limits are further broken down into two categories; hard and soft limits. hard limit A hard limit may not be exceeded. Once a user reaches his hard limit he may not make any further allocations on the file system in question. For example, if the user has a hard limit of 500 blocks on a file system and is currently using 490 blocks, the user can only allocate an additional 10 blocks. Attempting to allocate an additional 11 blocks will fail. soft limit Soft limits, on the other hand, can be exceeded for a limited amount of time. This period of time is known as the grace period, which is one week by default. If a user stays over his or her soft limit longer than the grace period, the soft limit will turn into a hard limit and no further allocations will be allowed. When the user drops back below the soft limit, the grace period will be reset. The following is an example of what you might see when you run the edquota command. When the edquota command is invoked, you are placed into the editor specified by the EDITOR environment variable, or in the vi editor if the EDITOR variable is not set, to allow you to edit the quota limits. &prompt.root; edquota -u test Quotas for user test: /usr: blocks in use: 65, limits (soft = 50, hard = 75) inodes in use: 7, limits (soft = 50, hard = 60) /usr/var: blocks in use: 0, limits (soft = 50, hard = 75) inodes in use: 0, limits (soft = 50, hard = 60) You will normally see two lines for each file system that has quotas enabled. One line for the block limits, and one line for inode limits. Simply change the value you want updated to modify the quota limit. For example, to raise this users block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change: /usr: blocks in use: 65, limits (soft = 50, hard = 75) to: /usr: blocks in use: 65, limits (soft = 500, hard = 600) The new quota limits will be in place when you exit the editor. Sometimes it is desirable to set quota limits on a range of uids. This can be done by use of the option on the edquota command. First, assign the desired quota limit to a user, and then run edquota -p protouser startuid-enduid. For example, if user test has the desired quota limits, the following command can be used to duplicate those quota limits for uids 10,000 through 19,999: &prompt.root; edquota -p test 10000-19999 See man edquota for more detailed information. Checking Quota Limits and Disk Usage disk quotas checking You can use either the quota or the repquota commands to check quota limits and disk usage. The quota command can be used to check individual user and group quotas and disk usage. Only the super-user may examine quotas and usage for other users, or for groups that they are not a member of. The repquota command can be used to get a summary of all quotas and disk usage for file systems with quotas enabled. The following is some sample output from the quota -v command for a user that has quota limits on two file systems. Disk quotas for user test (uid 1002): Filesystem blocks quota limit grace files quota limit grace /usr 65* 50 75 5days 7 50 60 /usr/var 0 50 75 0 50 60 grace period On the /usr file system in the above example this user is currently 15 blocks over the soft limit of 50 blocks and has 5 days of the grace period left. Note the asterisk * which indicates that the user is currently over his quota limit. Normally file systems that the user is not using any disk space on will not show up in the output from the quota command, even if he has a quota limit assigned for that file system. The option will display those file systems, such as the /usr/var file system in the above example. Quotas over NFS NFS Quotas are enforced by the quota subsystem on the NFS server. The &man.rpc.rquotad.8; daemon makes quota information available to the &man.quota.1; command on NFS clients, allowing users on those machines to see their quota statistics. Enable rpc.rquotad in /etc/inetd.conf like so: rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad Now restart inetd: &prompt.root; kill -HUP `cat /var/run/inetd.pid` Creating CDs CDROMs creating Contributed by Mike Meyer mwm@mired.org, April 2001. Introduction CDs have a number of features that differentiate them from conventional disks. Initially, they weren't writable by the user. They are designed so that they can be read continuously without delays to move the head between tracks. They are also much easier to transport between systems than similarly sized media were at the time. CDs do have tracks, but this refers to a section of data to be read continuously and not a physical property of the disk. To produce a CD on FreeBSD, you prepare the data files that are going to make up the tracks on the CD, then write the tracks to the CD. ISO 9660 filesystems ISO-9660 The ISO 9660 file system was designed to deal with these differences. It unfortunately codifies file system limits that were common then. Fortunately, it provides an extension mechanism that allows properly written CDs to exceed those limits while still working with systems that do not support those extensions. mkisofs The mkisofs program is used to produce a data file containing an ISO 9660 file system. It has options that support various extensions, and is described below. You can install it with the /usr/ports/sysutils/mkisofs port. CD burner ATAPI Which tool to use to burn the CD depends on whether your CD burner is ATAPI or something else. ATAPI CD burners use the burncd program that is part of the base system. SCSI and USB CD burners should use the cdrecord from the /usr/ports/sysutils/cdrecord port. mkisofs mkisofs produces an ISO 9660 file system that is an image of a directory tree in the Unix file system name space. The simplest usage is: &prompt.root; mkisofs imagefile.iso /path/to/tree filesystems ISO-9660 This command will create an imagefile containing an ISO 9660 file system that is a copy of the tree at /path/to/tree. In the process, it will map the file names to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that have names uncharacteristic of ISO file systems. Read &man.mkisofs.8; for details of this process, and options that can be used to control it. filesystems HFS filesystems Joliet A number of options are available to overcome those restrictions. In particular, enables the Rock Ridge extensions common to Unix systems, enables Joliet extensions used by Microsoft systems, and can be used to create HFS file systems used by Macs. Read &man.mkisofs.8; for more information on the last two. For CDs that are going to be used only on FreeBSD systems, can be used to disable all filename restrictions. When used with , it produces a file system image that is identical to the FreeBSD tree you started from, though it may violate the ISO 9660 standard in a number of ways. CDROMs creating bootable The last option of general use is . This is used to specify the location of the boot image for use in producing an El Torito bootable CD. This option takes an argument which is the path to a boot image from the top of the tree being written to the CD. So, given that /tmp/myboot holds a bootable FreeBSD system with the boot image in /tmp/myboot/boot/cdboot, you could produce the image of an ISO 9660 file system in /tmp/bootable.iso like so: &prompt.root; mkisofs boot/cdboot /tmp/bootable.iso /tmp/myboot Having done that, if you have vn configured in your kernel, you can mount the file system with: &prompt.root; vnconfig vn0c /tmp/bootable.iso &prompt.root; mount cd9660 /dev/vn0c /mnt At which point you can verify that /mnt and /tmp/myboot are identical. There are many other options you can use with mkisofs to fine-tune its behavior. See &man.mkisofs.8; for details. burncd CDROMs burning If you have an ATAPI CD burner, you can use the burncd command to burn an ISO image onto a CD. burncd is part of the base system, installed as /usr/sbin/burncd. Usage is very simple, as it has few options: &prompt.root; burncd cddevice data imagefile.iso fixate Will burn a copy of imagefile.iso on cddevice. The default device is /dev/acd0. See &man.burncd.8; for options to set the write speed, eject the CD after burning, and write audio data. cdrecord If you do not have an ATAPI CD burner, you will have to use cdrecord to burn your CDs. cdrecord is not part of the base system; you must install it from either the port at /usr/ports/sysutils/cdrecord or the appropriate package. Changes to the base system can cause binary versions of this program to fail, possibly resulting in a coaster. You should therefore either upgrade the port when you upgrade your system, or if you are tracking -stable, upgrade the port when a new version becomes available. While cdrecord has many options, basic usage is even simpler than burncd. Burning an ISO 9660 image is done with: &prompt.root; cdrecord device imagefile.iso The tricky part of using cdrecord is finding the to use. To find the proper setting, use the flag of cdrecord, which might produce results like this: CDROMs burning &prompt.root; cdrecord Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk 0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk 0,2,0 2) * 0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk 0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) * 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM 1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner 1,7,0 107) * This lists the appropriate value for the devices on the list. Locate your CD burner, and use the three numbers separated by commas as the value for . In this case, the CRW device is 1,5,0, so the appropriate input would be =1,5,0. There are easier ways to specify this value; see &man.cdrecord.1; for details. That is also the place to look for information on writing audio tracks, controlling the speed, and other things. diff --git a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml index 3f33435d7f..b1dedf2552 100644 --- a/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,1618 +1,1619 @@ Resources on the Internet The rapid pace of FreeBSD progress makes print media impractical as a means of following the latest developments. Electronic resources are the best, if not often the only, way stay informed of the latest advances. Since FreeBSD is a volunteer effort, the user community itself also generally serves as a technical support department of sorts, with electronic mail and USENET news being the most effective way of reaching that community. The most important points of contact with the FreeBSD user community are outlined below. If you are aware of other resources not mentioned here, please send them to the &a.doc;so that they may also be included. Mailing Lists Though many of the FreeBSD development members read USENET, we cannot always guarantee that we will get to your questions in a timely fashion (or at all) if you post them only to one of the comp.unix.bsd.freebsd.* groups. By addressing your questions to the appropriate mailing list you will reach both us and a concentrated FreeBSD audience, invariably assuring a better (or at least faster) response. The charters for the various lists are given at the bottom of this document. Please read the charter before joining or sending mail to any list. Most of our list subscribers now receive many hundreds of FreeBSD related messages every day, and by setting down charters and rules for proper use we are striving to keep the signal-to-noise ratio of the lists high. To do less would see the mailing lists ultimately fail as an effective communications medium for the project. Archives are kept for all of the mailing lists and can be searched using the FreeBSD World Wide Web server. The keyword searchable archive offers an excellent way of finding answers to frequently asked questions and should be consulted before posting a question. List Summary General lists: The following are general lists which anyone is free (and encouraged) to join: List Purpose cvs-all Changes made to the FreeBSD source tree freebsd-advocacy FreeBSD Evangelism freebsd-announce Important events and project milestones freebsd-arch Architecture and design discussions freebsd-bugs Bug reports freebsd-chat Non-technical items related to the FreeBSD community freebsd-config Development of FreeBSD installation and configuration tools freebsd-current Discussion concerning the use of FreeBSD-current freebsd-isp Issues for Internet Service Providers using FreeBSD freebsd-jobs FreeBSD employment and consulting opportunities freebsd-newbies New FreeBSD users activities and discussions freebsd-policy FreeBSD Core team policy decisions. Low volume, and read-only freebsd-questions User questions and technical support freebsd-stable Discussion concerning the use of FreeBSD-stable freebsd-test Where to send your test messages instead of one of the actual lists Technical lists: The following lists are for technical discussion. You should read the charter for each list carefully before joining or sending mail to one as there are firm guidelines for their use and content. List Purpose freebsd-afs Porting AFS to FreeBSD freebsd-alpha Porting FreeBSD to the Alpha freebsd-atm Using ATM networking with FreeBSD freebsd-audit Source code audit project freebsd-database Discussing database use and development under FreeBSD freebsd-doc Creating FreeBSD related documents freebsd-emulation Emulation of other systems such as Linux/DOS/Windows freebsd-fs Filesystems freebsd-hackers General technical discussion freebsd-hardware General discussion of hardware for running FreeBSD freebsd-i18n FreeBSD Internationalization freebsd-ia64 Porting FreeBSD to Intel's upcoming IA64 systems freebsd-ipfw Technical discussion concerning the redesign of the IP firewall code freebsd-isdn ISDN developers freebsd-java Java developers and people porting JDKs to FreeBSD freebsd-libh The second generation installation and package system freebsd-mobile Discussions about mobile computing freebsd-mozilla Porting mozilla to FreeBSD freebsd-multimedia Multimedia applications freebsd-new-bus Technical discussions about bus architecture freebsd-net Networking discussion and TCP/IP source code freebsd-platforms Concerning ports to non-Intel architecture platforms freebsd-ports Discussion of the ports collection freebsd-ppc Porting FreeBSD to the PowerPC freebsd-realtime Development of realtime extensions to FreeBSD freebsd-scsi The SCSI subsystem freebsd-security Security issues freebsd-security-notifications Security notifications freebsd-small Using FreeBSD in embedded applications freebsd-smp Design discussions for [A]Symmetric MultiProcessing freebsd-sparc Porting FreeBSD to Sparc systems freebsd-tokenring Support Token Ring in FreeBSD Limited lists: The following lists are for more specialized (and demanding) audiences and are probably not of interest to the general public. It is also a good idea to establish a presence in the technical lists before joining one of these limited lists so that you'll understand the communications etiquette involved. List Purpose freebsd-core FreeBSD core team freebsd-hubs People running mirror sites (infrastructural support) freebsd-install Installation development freebsd-user-groups User group coordination freebsd-www Maintainers of www.freebsd.org Digest lists: Many of the above lists are also available as digests. New messages posted to the list are collected and sent out as a single e-mail when the sizes goes over 100KB. The lists available in digest form are: List freebsd-afs-digest freebsd-alpha-digest freebsd-chat-digest freebsd-current-digest freebsd-cvs-all-digest freebsd-database-digest freebsd-hackers-digest freebsd-ia64-digest freebsd-isdn-digest freebsd-java-digest freebsd-questions-digest freebsd-security-digest freebsd-sparc-digest freebsd-stable-digest freebsd-test-digest CVS lists: The following lists are for people interested in seeing the log messages for changes to various areas of the source tree. They are Read-Only lists and should not have mail sent to them. List Source area Area Description (source for) cvs-all /usr/src All changes to the tree (superset) How to Subscribe All mailing lists live on FreeBSD.org, so to post to a given list you simply mail to <listname@FreeBSD.org>. It will then be redistributed to mailing list members world-wide. To subscribe to a list, send mail to &a.majordomo; and include subscribe <listname> [<optional address>] in the body of your message. For example, to subscribe yourself to freebsd-announce, you'd do: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce ^D If you want to subscribe yourself under a different name, or submit a subscription request for a local mailing list (this is more efficient if you have several interested parties at one site, and highly appreciated by us!), you would do something like: &prompt.user; mail majordomo@FreeBSD.org subscribe freebsd-announce local-announce@somesite.com ^D Finally, it is also possible to unsubscribe yourself from a list, get a list of other list members or see the list of mailing lists again by sending other types of control messages to majordomo. For a complete list of available commands, do this: &prompt.user; mail majordomo@FreeBSD.org help ^D Again, we would like to request that you keep discussion in the technical mailing lists on a technical track. If you are only interested in important announcements then it is suggested that you join freebsd-announce, which is intended only for infrequent traffic. List Charters All FreeBSD mailing lists have certain basic rules which must be adhered to by anyone using them. Failure to comply with these guidelines will result in two (2) written warnings from the FreeBSD Postmaster postmaster@FreeBSD.org, after which, on a third offense, the poster will removed from all FreeBSD mailing lists and filtered from further posting to them. We regret that such rules and measures are necessary at all, but today's Internet is a pretty harsh environment, it would seem, and many fail to appreciate just how fragile some of its mechanisms are. Rules of the road: The topic of any posting should adhere to the basic charter of the list it is posted to, e.g. if the list is about technical issues then your posting should contain technical discussion. Ongoing irrelevant chatter or flaming only detracts from the value of the mailing list for everyone on it and will not be tolerated. For free-form discussion on no particular topic, the freebsd-chat freebsd-chat@FreeBSD.org mailing list is freely available and should be used instead. No posting should be made to more than 2 mailing lists, and only to 2 when a clear and obvious need to post to both lists exists. For most lists, there is already a great deal of subscriber overlap and except for the most esoteric mixes (say "-stable & -scsi"), there really is no reason to post to more than one list at a time. If a message is sent to you in such a - way that multiple mailing lists appear on the Cc line then the Cc + way that multiple mailing lists appear on the + Cc line then the Cc line should also be trimmed before sending it out again. You are still responsible for your own cross-postings, no matter who the originator might have been. Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. Advertising of non-FreeBSD related products or services is strictly prohibited and will result in an immediate ban if it is clear that the offender is advertising by spam. Individual list charters: FREEBSD-AFS Andrew File System This list is for discussion on porting and using AFS from CMU/Transarc FREEBSD-ANNOUNCE Important events / milestones This is the mailing list for people interested only in occasional announcements of significant FreeBSD events. This includes announcements about snapshots and other releases. It contains announcements of new FreeBSD capabilities. It may contain calls for volunteers etc. This is a low volume, strictly moderated mailing list. FREEBSD-ARCH Architecture and design discussions This list is for discussion of the FreeBSD architecture. Messages will mostly be kept strictly technical in nature. Examples of suitable topics are: How to re-vamp the build system to have several customized builds running at the same time. What needs to be fixed with VFS to make Heidemann layers work. How do we change the device driver interface to be able to use the same drivers cleanly on many buses and architectures. How to write a network driver. FREEBSD-AUDIT Source code audit project This is the mailing list for the FreeBSD source code audit project. Although this was originally intended for security-related changes, its charter has been expanded to review any code changes. This list is very heavy on patches, and is probably of no - intrest to the average FreeBSD user. Security discussions + interest to the average FreeBSD user. Security discussions not related to a particular code change are held on freebsd-security. Conversely, all developers are encouraged to send their patches here for review, especially if they touch a part of the system where a bug may adversely affect the integrity of the system. FREEBSD-BUGS Bug reports This is the mailing list for reporting bugs in FreeBSD Whenever possible, bugs should be submitted using the &man.send-pr.1; command or the WEB interface to it. FREEBSD-CHAT Non technical items related to the FreeBSD community This list contains the overflow from the other lists about non-technical, social information. It includes discussion about whether Jordan looks like a toon ferret or not, whether or not to type in capitals, who is drinking too much coffee, where the best beer is brewed, who is brewing beer in their basement, and so on. Occasional announcements of important events (such as upcoming parties, weddings, births, new jobs, etc) can be made to the technical lists, but the follow ups should be directed to this -chat list. FREEBSD-CORE FreeBSD core team This is an internal mailing list for use by the core members. Messages can be sent to it when a serious FreeBSD-related matter requires arbitration or high-level scrutiny. FREEBSD-CURRENT Discussions about the use of FreeBSD-current This is the mailing list for users of freebsd-current. It includes warnings about new features coming out in -current that will affect the users, and instructions on steps that must be taken to remain -current. Anyone running current must subscribe to this list. This is a technical mailing list for which strictly technical content is expected. FREEBSD-CURRENT-DIGEST Discussions about the use of FreeBSD-current This is the digest version of the freebsd-current mailing list. The digest consists of all messages sent to freebsd-current bundled together and mailed out as a single message. This list is Read-Only and should not be posted to. FREEBSD-DOC Documentation project This mailing list is for the discussion of issues and projects related to the creation of documentation for FreeBSD. The members of this mailing list are collectively referred to as The FreeBSD Documentation Project. It is an open list; feel free to join and contribute! FREEBSD-FS Filesystems Discussions concerning FreeBSD filesystems. This is a technical mailing list for which strictly technical content is expected. FREEBSD-IPFW IP Firewall This is the forum for technical discussions concerning the redesign of the IP firewall code in FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-IA64 Porting FreeBSD to IA64 This is a technical mailing list for individuals actively working on porting FreeBSD to the IA-64 platform from Intel, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. FREEBSD-ISDN ISDN Communications This is the mailing list for people discussing the development of ISDN support for FreeBSD. FREEBSD-JAVA Java Development This is the mailing list for people discussing the development of significant Java applications for FreeBSD and the porting and maintenance of JDKs. FREEBSD-HACKERS Technical discussions This is a forum for technical discussions related to FreeBSD. This is the primary technical mailing list. It is for individuals actively working on FreeBSD, to bring up problems or discuss alternative solutions. Individuals interested in following the technical discussion are also welcome. This is a technical mailing list for which strictly technical content is expected. FREEBSD-HACKERS-DIGEST Technical discussions This is the digest version of the freebsd-hackers mailing list. The digest consists of all messages sent to freebsd-hackers bundled together and mailed out as a single message. This list is Read-Only and should not be posted to. FREEBSD-HARDWARE General discussion of FreeBSD hardware General discussion about the types of hardware that FreeBSD runs on, various problems and suggestions concerning what to buy or avoid. FREEBSD-HUBS Mirror sites Announcements and discussion for people who run FreeBSD mirror sites. FREEBSD-INSTALL Installation discussion This mailing list is for discussing FreeBSD installation development for the future releases. FREEBSD-ISP Issues for Internet Service Providers This mailing list is for discussing topics relevant to Internet Service Providers (ISPs) using FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-NEWBIES Newbies activities discussion We cover any of the activities of newbies that are not already dealt with elsewhere, including: independent learning and problem solving techniques, finding and using resources and asking for help elsewhere, how to use mailing lists and which lists to use, general chat, making mistakes, boasting, sharing ideas, stories, moral (but not technical) support, and taking an active part in the FreeBSD community. We take our problems and support questions to freebsd-questions, and use freebsd-newbies to meet others who are doing the same things that we do as newbies. FREEBSD-PLATFORMS Porting to Non-Intel platforms Cross-platform FreeBSD issues, general discussion and proposals for non-Intel FreeBSD ports. This is a technical mailing list for which strictly technical content is expected. FREEBSD-POLICY Core team policy decisions This is a low volume, read-only mailing list for FreeBSD Core Team Policy decisions. FREEBSD-PORTS Discussion of ports Discussions concerning FreeBSD's ports collection (/usr/ports), proposed ports, modifications to ports collection infrastructure and general coordination efforts. This is a technical mailing list for which strictly technical content is expected. FREEBSD-QUESTIONS User questions This is the mailing list for questions about FreeBSD. You should not send how to questions to the technical lists unless you consider the question to be pretty technical. FREEBSD-QUESTIONS-DIGEST User questions This is the digest version of the freebsd-questions mailing list. The digest consists of all messages sent to freebsd-questions bundled together and mailed out as a single message. FREEBSD-SCSI SCSI subsystem This is the mailing list for people working on the scsi subsystem for FreeBSD. This is a technical mailing list for which strictly technical content is expected. FREEBSD-SECURITY Security issues FreeBSD computer security issues (DES, Kerberos, known security holes and fixes, etc). This is a technical mailing list for which strictly technical content is expected. FREEBSD-SECURITY-NOTIFICATIONS Security Notifications Notifications of FreeBSD security problems and fixes. This is not a discussion list. The discussion list is FreeBSD-security. FREEBSD-SMALL Using FreeBSD in embedded applications This list discusses topics related to unusually small and embedded FreeBSD installations. This is a technical mailing list for which strictly technical content is expected. FREEBSD-STABLE Discussions about the use of FreeBSD-stable This is the mailing list for users of freebsd-stable. It includes warnings about new features coming out in -stable that will affect the users, and instructions on steps that must be taken to remain -stable. Anyone running stable should subscribe to this list. This is a technical mailing list for which strictly technical content is expected. FREEBSD-USER-GROUPS User Group Coordination List This is the mailing list for the coordinators from each of the local area Users Groups to discuss matters with each other and a designated individual from the Core Team. This mail list should be limited to meeting synopsis and coordination of projects that span User Groups. Usenet Newsgroups In addition to two FreeBSD specific newsgroups, there are many others in which FreeBSD is discussed or are otherwise relevant to FreeBSD users. Keyword searchable archives are available for some of these newsgroups from courtesy of Warren Toomey wkt@cs.adfa.edu.au. BSD Specific Newsgroups comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc Other Unix Newsgroups of Interest comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window System comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World Wide Web Servers http://www.FreeBSD.org/ — Central Server. http://www.au.FreeBSD.org/ — Australia/1. http://www2.au.FreeBSD.org/ — Australia/2. http://www3.au.FreeBSD.org/ — Australia/3. http://freebsd.itworks.com.au/ — Australia/4. http://www.br.FreeBSD.org/www.freebsd.org/ — Brazil/1. http://www2.br.FreeBSD.org/www.freebsd.org/ — Brazil/2. http://www3.br.FreeBSD.org/ — Brazil/3. http://www.bg.FreeBSD.org/ — Bulgaria. http://www.ca.FreeBSD.org/ — Canada/1. http://www2.ca.FreeBSD.org/ — Canada/2. http://www3.ca.FreeBSD.org/ — Canada/3. http://www.cn.FreeBSD.org/ — China. http://www.cz.FreeBSD.org/ — Czech Republic. http://www.dk.FreeBSD.org/ — Denmark. http://www.ee.FreeBSD.org/ — Estonia. http://www.fi.FreeBSD.org/ — Finland. http://www.fr.FreeBSD.org/ — France. http://www.de.FreeBSD.org/ — Germany/1. http://www1.de.FreeBSD.org/ — Germany/2. http://www2.de.FreeBSD.org/ — Germany/3. http://www.gr.FreeBSD.org/ — Greece. http://www.hu.FreeBSD.org/ — Hungary. http://www.is.FreeBSD.org/ — Iceland. http://www.ie.FreeBSD.org/ — Ireland. http://www.jp.FreeBSD.org/www.FreeBSD.org/ — Japan. http://www.kr.FreeBSD.org/ — Korea/1. http://www2.kr.FreeBSD.org/ — Korea/2. http://www.lv.FreeBSD.org/ — Latvia. http://rama.asiapac.net/freebsd/ — Malaysia. http://www.nl.FreeBSD.org/ — Netherlands/1. http://www2.nl.FreeBSD.org/ — Netherlands/2. http://www.no.FreeBSD.org/ — Norway. http://www.nz.FreeBSD.org/ — New Zealand. http://www.pl.FreeBSD.org/ — Poland/1. http://www2.pl.FreeBSD.org/ — Poland/2. http://www.pt.FreeBSD.org/ — Portugal/1. http://www2.pt.FreeBSD.org/ — Portugal/2. http://www3.pt.FreeBSD.org/ — Portugal/3. http://www.ro.FreeBSD.org/ — Romania. http://www.ru.FreeBSD.org/ — Russia/1. http://www2.ru.FreeBSD.org/ — Russia/2. http://www3.ru.FreeBSD.org/ — Russia/3. http://www4.ru.FreeBSD.org/ — Russia/4. http://freebsd.s1web.com/ — Singapore. http://www.sk.FreeBSD.org/ — Slovak Republic. http://www.si.FreeBSD.org/ — Slovenia. http://www.es.FreeBSD.org/ — Spain. http://www.za.FreeBSD.org/ — South Africa/1. http://www2.za.FreeBSD.org/ — South Africa/2. http://www.se.FreeBSD.org/ — Sweden. http://www.ch.FreeBSD.org/ — Switzerland. http://www.tw.FreeBSD.org/www.freebsd.org/data/ — Taiwan. http://www.tr.FreeBSD.org/ — Turkey. http://www.ua.FreeBSD.org/www.freebsd.org/ — Ukraine/1. http://www2.ua.FreeBSD.org/ — Ukraine/2. http://www4.ua.FreeBSD.org/ — Ukraine/Crimea. http://www.uk.FreeBSD.org/ — United Kingdom/1. http://www2.uk.FreeBSD.org/ — United Kingdom/2. http://www3.uk.FreeBSD.org/ — United Kingdom/3. http://www6.FreeBSD.org/ — USA/Oregon. http://www2.FreeBSD.org/ — USA/Texas. Email Addresses The following user groups provide FreeBSD related email addresses for their members. The listed administrator reserves the right to revoke the address if it is abused in any way. Domain Facilities User Group Administrator ukug.uk.FreeBSD.org Forwarding only freebsd-users@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org Shell Accounts The following user groups provide shell accounts for people who are actively supporting the FreeBSD project. The listed administrator reserves the right to cancel the account if it is abused in any way. Host Access Facilities Administrator storm.uk.FreeBSD.org SSH only Read-only cvs, personal web space, email &a.brian dogma.freebsd-uk.eu.org Telnet/FTP/SSH E-Mail, Web space, Anonymous FTP Lee Johnston lee@uk.FreeBSD.org diff --git a/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml b/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml index b48abd7234..641b060563 100644 --- a/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml @@ -1,970 +1,972 @@ Localization - I18N/L10N Usage and Setup Contributed by &a.ache; Rewritten by &a.keichii;, 30 Nov 2000. Synopsis This section of the handbook discusses the internationalization and localization of FreeBSD to different countries and different settings. If the users wish to use languages other than the system default English, he/she will have to setup the system accordingly. Please note that language support for each language varies in level. Hence, the user should contact the respective FreeBSD local group that is responsible for each language. The author realizes that he may have been incomplete in the description of the I18N process in FreeBSD. Due to the various levels of I18N implementation in both the system and application levels, we advise you to refer to individual documentation, man pages, READMEs, and so forth. Should you have any questions or suggestions regarding this chapter, please email the author. The Basics What is I18N/L10N? internationalization localization Developers shortened internationalization into the term I18N, counting the number of letters between the first and the last letters of internationalization. L10N uses the same naming scheme, coming from "localization". Combined together, I18N/L10N methods, protocols, and applications allow users to use languages of their choice. I18N applications are programmed using I18N kits under libraries. It allows for developers to write a simple file and translate displayed menus and texts to each language. We strongly encourage programmers to follow this convention. Why should I use I18N/L10N? I18N/L10N is used whenever you wish to either view, input, or process data in non-English languages. What languages are supported in the I18N effort? I18N and L10N are not FreeBSD specific. Currently, one can choose from most of the major languages of the World, including but not limited to: Chinese, German, Japanese, Korean, French, Russian, Vietnamese and others. Using Localization In all its splendor, I18N is not FreeBSD-specific and is a convention. We encourage you to help FreeBSD in following this convention. locale Localization settings are based on three main terms: Language Code, Country Code, and Encoding. Locale names are constructed from these parts as follows: LanguageCode_CountryCode.Encoding Language and Country Codes language codes country codes In order to localize a FreeBSD system to a specific language (or any other I18N-supporting Unixes), the user needs to find out the codes for the specify country and language (country codes tell applications what variation of given language to use). In addition, web browsers, SMTP/POP servers, web servers, etc. make decisions based on them. The following are examples of language/country codes: Language/Country Code Description en_US English - United States ru_RU Russian for Russia zh_TW Traditional Chinese for Taiwan Encodings encodings ASCII Some languages use non-ASCII encodings that are 8-bit, wide or multibyte characters, see &man.multibyte.3; for more details. Older applications do not recognize them and mistake them for control characters. Newer applications usually do recognize 8-bit characters. Depending on the implementation, users may be required to compile an application with wide or multibyte characters support, or configure it correctly. To be able to input and process wide or multibyte characters, the FreeBSD Ports collection has provided each language with different programs. Refer to the I18N documentation in the respective FreeBSD Port. Specifically, the user needs to look at the application documentation to decide on how to configure it correctly or to pass correct values into the configure/Makefile/compiler. Some things to keep in mind are: Language specific single C chars character sets (see &man.multibyte.3;), i.e., ISO-8859-1, ISO-8859-15, KOI8-R, CP437. Wide or multibyte encodings, f.e. EUC, Big5. You can check the active list of character sets at the IANA Registry. I18N applications In the FreeBSD Ports and Package system, I18N applications have been named with I18N in their names for easy identification. However, they do not always support the language needed. Setting Locale Theoretically, one only needs to export the value of his/her locale name as LANG in the login shell and is usually done through the user's ~/.login_conf or the user login shell configuration (~/.profile, ~/.bashrc, ~/.cshrc). This should set all of the locale subsets (such as LC_CTYPE, LC_CTIME, etc.). Please refer to language-specific FreeBSD documentation for more information. You should set the following two values in your configuration files: POSIX LANG for POSIX &man.setlocale.3; family functions MIME MM_CHARSET for applications' MIME character set This includes the user shell config, the specific application config, and the X11 config. Setting Locale Methods locale login class There are two methods for setting locale, and both are described below. The first (recommended one) is by assigning the environment variables in login class, and the second is by adding the environment variable assignments to the system's shell startup file. Login Classes Method This method allows environment variables needed for locale name and MIME character sets to be assigned once for every possible shell instead of adding specific shell assignments to each shell's startup file. User Level Setup can be done by an user himself and Administrator Level Setup require superuser privileges. User Level Setup Here is a minimal example of a .login_conf file in user's home directory which has both variables set for Latin-1 encoding: german:German User:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO_8859-1: Traditional Chinese / BIG-5 encoding Here is an example of a .login_conf that sets the variables for Traditional Chinese in BIG-5 encoding. Notice the many more variables set because some software does not respect locale variables correctly for Chinese, Japanese, and Korean. #Users who do not wish to use monetary units or time formats #of Taiwan can manually change each variable taiwan:Taiwanese User:\ lang=zh_TW.Big5:\ lc_all=zh_TW.Big:\ lc_collate=zh_TW.Big5:\ lc_ctype=zh_TW.Big5:\ lc_messages=zh_TW.Big5:\ lc_monetary=zh_TW.Big5:\ lc_numeric=zh_TW.Big5:\ lc_time=zh_TW.Big5:\ charset=big5:\ xmodifiers="@im=xcin": #Setting the XIM Input Server See Administrator Level Setup and &man.login.conf.5; for more details. Administrator Level Setup Check that /etc/login.conf have the correct language user's class. Make sure these settings appear in /etc/login.conf: language_name:accounts_title:\ :charset=MIME_charset:\ :lang=locale_name:\ :tc=default: So sticking with our previous example using Latin-1, it would look like this: german:German Users Accounts:\ :charset=ISO-8859-1:\ :lang=de_DE.ISO_8859-1:\ :tc=default: Changing Login Classes with &man.vipw.8; vipw Use vipw to add new users, and make the entry look like this: user:password:1111:11:language:0:0:User Name:/home/user:/bin/sh Changing Login Classes with &man.adduser.8; adduser login class Use adduser to add new users, and do the following: Set defaultclass = language in /etc/adduser.conf. Keep in mind you must enter a default class for all users of other languages in this case. An alternative variant is answering the specified language each time that Enter login class: default []: appears from &man.adduser.8; Another alternative is to use the following for each user of a different language that you wish to add: &prompt.root; adduser -class language Changing Login Classes with &man.pw.8; pw If you use &man.pw.8; for adding new users, call it in this form: &prompt.root; pw useradd user_name -L language Shell Startup File Method This method is not recommended because it requires a different setup for each possible login program chosen. Use the Login Class Method instead. MIME locale To add the locale name and MIME character set, just set the two environment variables shown below in the /etc/profile and/or /etc/csh.login shell startup files. We will use the German language as an example below: In /etc/profile: LANG=de_DE.ISO_8859-1; export LANG MM_CHARSET=ISO-8859-1; export MM_CHARSET Or in /etc/csh.login: setenv LANG de_DE.ISO_8859-1 setenv MM_CHARSET ISO-8859-1 Alternatively, you can add the above instructions to /usr/share/skel/dot.profile (similar to what was used in /etc/profile above), or /usr/share/skel/dot.login (similar to what was used in /etc/csh.login above). For X11: In $HOME/.xinitrc: LANG=de_DE.ISO_8859-1; export LANG Or: setenv LANG de_DE.ISO_8859-1 Depending on your shell (see above). Console Setup For all single C chars character sets, set the correct console fonts in /etc/rc.conf for the language in question with: font8x16=font_name font8x14=font_name font8x8=font_name The font_name here is taken from the /usr/share/syscons/fonts directory, without the .fnt suffix. sysinstall keymap screenmap Also be sure to set the correct keymap and screenmap for your single C chars character set through /stand/sysinstall. Once inside sysinstall, choose Configure, then Console. Alternatively, you can add the following to /etc/rc.conf: scrnmap=screenmap_name keymap=keymap_name keychange="fkey_number sequence" The screenmap_name here is taken from the /usr/share/syscons/scrnmaps directory, without the .scm suffix. A screenmap with a corresponding mapped font is usually needed as a workaround for expanding bit 8 to bit 9 on a VGA adapter's font character matrix in pseudographics area, i.e., to move letters out of that area if screen font uses a bit 8 column. - If you have the moused daemon enabled by setting the following + If you have the moused daemon + enabled by setting the following in your /etc/rc.conf: moused_enable="YES" then examine the mouse cursor information in the next paragraph. moused By default the mouse cursor of the syscons driver occupies the 0xd0-0xd3 range in the character set. If your language uses this range, you need to move the cursor's range outside of it. To enable the workaround for FreeBSD versions before 5.0, insert the following line into your kernel config: options SC_MOUSE_CHAR=0x03 For the FreeBSD versions 5.0 and up insert the following line into /etc/rc.conf: mousechar_start=3 The keymap_name here is taken from the /usr/share/syscons/keymaps directory, without the .kbd suffix. The keychange is usually needed to program function keys to match the selected terminal type because function key sequences cannot be defined in the key map. Also be sure to set the correct console terminal type in /etc/ttys for all ttyv* entries. Current pre-defined correspondences are: Character Set Terminal Type ISO-8859-1 or ISO-8859-15 cons25l1 ISO-8859-2 cons25l2 KOI8-R cons25r KOI8-U cons25u CP437 (hardware default) cons25 For wide or multibyte characters languages, use the correct FreeBSD port in your /usr/ports/language directory. Some ports appear as console while the system sees it as serial vtty's, hence you must reserve enough vtty's for both X11 and the pseudo-serial console. Here is a partial list of applications for using other languages in console: Language Location Traditional Chinese (BIG-5) /usr/ports/chinese/big5con Japanese /usr/ports/japanese/ja-kon2-* or /usr/ports/japanese/Mule_Wnn Korean /usr/ports/korean/ko-han X11 Setup Although X11 is not part of the FreeBSD Project, we have included some information here for FreeBSD users. For more details, refer to the XFree86 web site or whichever X11 Server you use. In ~/.Xresources, you can additionally tune application specific I18N settings (e.g., fonts, menus, etc.). Displaying Fonts X11 True Type font server Install the X11 True Type-Common server (XTT-common) and install the language truetype fonts. Setting the correct locale should allow you to view your selected language in menus and such. Inputting Non-English Characters X11 Input Method (XIM) The X11 Input Method (XIM) Protocol is a new standard for all X11 clients. All X11 applications should be written as XIM clients that take input from XIM Input servers. There are several XIM servers available for different languages. Printer Setup Some single C chars character sets are usually hardware coded into printers. Wide or multibyte character sets require special setup and we recommend using apsfilter. You may also convert the document to PostScript or PDF formats using language specific converters. Kernel and File Systems The FreeBSD FFS filesystem is 8-bit clean, so it can be used with any single C chars character set (see &man.multibyte.3;), but there is no character set name stored in the filesystem; i.e., it is raw 8-bit and does not know anything about encoding order. Officially, FFS does not support any form of wide or multibyte character sets yet. However, some wide or multibyte character sets have independent patches for FFS enabling such support. They are only temporary unportable solutions or hacks and we have decided to not include them in the source tree. Refer to respective languages' web sites for more informations and the patch files. DOS Unicode The FreeBSD MS-DOS filesystem has the configurable ability to convert between MS-DOS, Unicode character sets and chosen FreeBSD filesystem character sets. See &man.mount.msdos.8; for details. Advanced Topics If you wish to compile I18N applications or program I18N compliant applications, please read this section. Compiling I18N Programs Many FreeBSD Ports have been ported with I18N support. Some of them are marked with -I18N in the port name. These and many other programs have built in support for I18N and need no special consideration. MySQL - However, some applications such as MySQL need to be have the + However, some applications such as + MySQL need to be have the Makefile configured with the specific charset. This is usually done in the Makefile or done by passing a value to configure in the source. Programming I18N Compliant Applications Qt GTK To make your application more useful for speakers of other languages, we hope that you will program I18N compliant. The GNU gcc compiler, GUI Libraries like QT and GTK support I18N through special handling of strings. Making a program I18N compliant is very easy. It allows contributors to port your application to other languages quickly. Refer to library specific I18N documentation for more details. To the contrary of common perception, I18N compliant code is easy to write. Usually, it only involves wrapping your strings with library specific functions. In addition, please be sure to allow for wide or multibyte characters support. A Call to Unify the I18N effort It has come to our attention that the individual I18N/L10N efforts for each country has been repeating each others' efforts. Many of us have been reinventing the wheel repeatedly and inefficiently. We hope that the various major groups in I18N could congregate into a group effort similar to the Core Team's responsibility. Currently, we hope that, when you write or port I18N programs, you would send it out to each country's related FreeBSD mailing lists for testing. In the future, we hope to create applications that work in all the languages out-of-the-box without dirty hacks. The mailing list FreeBSD-I18N@FreeBSD.org has been established. If you are an I18N/L10N developer, please send your comments, ideas, questions, and anything you deem related to it. Michael C. Wu will be maintaining an I18N works in progress homepage at http://www.FreeBSD.org/~keichii/i18n/index.html Please also read the BSDCon2000 I18N paper and presentations by Clive Lin, Chia-Liang Kao, and Michael C. Wu at http://www.FreeBSD.org/~keichii/papers/ Perl and Python Perl Python Perl and Python have I18N and wide characters handling libraries. Please use them for I18N compliance. In older FreeBSD versions, Perl may gives warning about not having a wide characters locale that is already installed in your system. You can set the environmental variable LD_PRELOAD to /usr/lib/libxpg4.so in your shell. In sh-based shells: LD_PRELOAD=/usr/lib/libxpg4.so In C-based shells: setenv LD_PRELOAD /usr/lib/libxpg4.so Localizing FreeBSD to Specific Languages Russian Language (KOI8-R encoding) Russian localization Originally contributed by &a.ache;. For more information about KOI8-R encoding, see the KOI8-R References (Russian Net Character Set). Locale Setup Put the following lines into your ~/.login_conf file: me:My Account:\ :charset=KOI8-R:\ :lang=ru_RU.KOI8-R: See earlier in this chapter for examples of setting up the locale. Console Setup For the FreeBSD versions before 5.0 add the following line to your kernel configuration file: options SC_MOUSE_CHAR=0x03 For the FreeBSD versions 5.0 and up insert the following line into /etc/rc.conf: mousechar_start=3 Use following settings in /etc/rc.conf: keymap="ru.koi8-r" scrnmap="koi8-r2cp866" font8x16="cp866b-8x16" font8x14="cp866-8x14" font8x8="cp866-8x8" For each ttyv* entry in /etc/ttys, use cons25r as the terminal type. See earlier in this chapter for examples of setting up the console. Printer Setup printers Since most printers with Russian characters come with hardware code page CP866, a special output filter is needed for KOI8-R -> CP866 conversion. Such a filter is installed by default as /usr/libexec/lpr/ru/koi2alt. A Russian printer /etc/printcap entry should look like: lp|Russian local line printer:\ :sh:of=/usr/libexec/lpr/ru/koi2alt:\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: See &man.printcap.5; for a detailed description. MS-DOS FS and Russian Filenames The following example &man.fstab.5; entry enables support for Russian filenames in mounted MS-DOS filesystems: /dev/ad0s2 /dos/c msdos rw,-Wkoi2dos,-Lru_RU.KOI8-R 0 0 See &man.mount.msdos.8; for a detailed description of the and options. X11 Setup Do non-X locale setup first as described. The Russian KOI8-R locale may not work with old XFree86 releases (lower than 3.3). The XFree86 port from /usr/ports/x11/XFree86 already is the most recent XFree86 version, so it will work if you install XFree86 from the port. This should not be an issue unless you are using an old version of FreeBSD. Go to the /usr/ports/russian/X.language directory and issue the following command: &prompt.root; make install The above port installs the latest version of the KOI8-R fonts. XFree86 3.3 already has some KOI8-R fonts, but these are scaled better. Check the "Files" section in your /etc/XF86Config file. The following lines must be added before any other FontPath entries: FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/misc" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/cyrillic/100dpi" If you use a high resolution video mode, swap the 75 dpi and 100 dpi lines. To activate a Russian keyboard, add the following to the "Keyboard" section of your XF86Config file. For XFree86 v3.*: XkbLayout "ru" XkbOptions "grp:caps_toggle" For XFree86 v4.*: Option "XkbLayout" "ru" Option "XkbOptions" "grp:caps_toggle" Also make sure that XkbDisable is turned off (commented out) there. The RUS/LAT switch will be CapsLock. The old CapsLock function is still available via Shift+CapsLock (in LAT mode only). If you have Windows keys on your keyboard, and notice that some non-alphabetical keys are mapped incorrectly in RUS mode, add the following line in your XF86Config file. For XFree86 v3.*: XkbVariant "winkeys" For XFree86 v4.*: Option "XkbVariant" "winkeys" The Russian XKB keyboard may not work with old XFree86 versions, see the above note for more information. The Russian XKB keyboard may also not work with non-localized applications as well. Minimally localized applications should call a XtSetLanguageProc (NULL, NULL, NULL); function early in the program. See KOI8-R for X-Window for more instructions on localizing X11 applications. Traditional Chinese Localization for Taiwan Traditional Chinese localization The FreeBSD-Taiwan Project has an I18N/L10N tutorial for FreeBSD at http://freebsd.sinica.edu.tw/~ncvs/zh-l10n-tut/index.html using many /usr/ports/chinese/* applications. The editor for the zh-L10N-tut is Clive Lin Clive@CirX.org. You can also cvsup the following collections at freebsd.sinica.edu.tw: Collection Description outta-port tag=. Beta-quality Ports Collection for Chinese zh-L10N-tut tag=. Localizing FreeBSD Tutorial in BIG-5 Traditional Chinese zh-doc tag=. FreeBSD Documentation Translation to BIG-5 Traditional Chinese Chuan-Hsing Shen s874070@mail.yzu.edu.tw has created the Chinese FreeBSD Collection (CFC) using FreeBSD-Taiwan's zh-L10N-tut. The packages and the script files are available at ftp://ftp.csie.ncu.edu.tw/OS/FreeBSD/taiwan/CFC/. German Language Localization (For All ISO 8859-1 Languages) German localization Slaven Rezic eserte@cs.tu-berlin.de wrote a tutorial how to use umlauts on a FreeBSD machine. The tutorial is written in German and available at http://www.de.FreeBSD.org/de/umlaute/. Japanese and Korean Language Localization Japanese localization Korean localization For Japanese, refer to http://www.jp.FreeBSD.org/, and for Korean, refer to http://www.kr.FreeBSD.org/. Non-English FreeBSD Documentation Some FreeBSD contributors have translated parts of FreeBSD to other languages. They are available through links on the main site or in /usr/share/doc. diff --git a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml index 909ec5f3b5..4fa0e1ae57 100644 --- a/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3856 +1,3866 @@ Obtaining FreeBSD CDROM Publishers FreeBSD is available on CDROM from several retailers:
Daemon News 2680 Bayshore Parkway, Suite 307 Mountain View, CA 94043 USA Phone: +1 650 694-4949 Email: sales@daemonnews.org WWW: http://www.bsdmall.com/
Wind River Systems 4041 Pike Lane, Suite F Concord, CA 94520 USA Phone: +1 925 691-2800 Fax: +1 925 674-0821 Email: info@osd.bsdi.com WWW: http://www.freebsdmall.com/
If you are a reseller and want to carry FreeBSD CDROM products, please contact the relevant department at Wind River Systems or:
Cylogistics 2680 Bayshore Parkway, Suite 307 Mountain View, CA 94043 USA Phone: +1 650 694-4949 Fax: +1 650 694-4953 Email: sales@cylogistics.com WWW: http://www.cylogistics.com/
DVD Publishers FreeBSD is available on DVD from:
FreeBSD Services Ltd 11 Lapwing Close Bicester OX26 6XR United Kingdom WWW: http://www.freebsd-services.com/
FTP Sites The official sources for FreeBSD are available via anonymous FTP from:
ftp://ftp.FreeBSD.org/pub/FreeBSD/.
The FreeBSD mirror sites database is more accurate than the mirror listing in the handbook, as it gets its information from the DNS rather than relying on static lists of hosts. Additionally, FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain FreeBSD via anonymous FTP, please try to use a site near you. Argentina, Australia, Brazil, Canada, China, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hong Kong, Hungary, Ireland, Israel, Japan, Korea, Lithuania, Netherlands, New Zealand, Poland, Portugal, Russia, Saudi Arabia, South Africa, Spain, Slovak Republic, Slovenia, Sweden, Taiwan, Thailand, UK, Ukraine, USA. Argentina In case of problems, please contact the hostmaster hostmaster@ar.FreeBSD.org for this domain. ftp://ftp.ar.FreeBSD.org/pub/FreeBSD/ Australia In case of problems, please contact the hostmaster hostmaster@au.FreeBSD.org for this domain. ftp://ftp.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.au.FreeBSD.org/pub/FreeBSD/ Brazil In case of problems, please contact the hostmaster hostmaster@br.FreeBSD.org for this domain. ftp://ftp.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.br.FreeBSD.org/pub/FreeBSD/ Canada In case of problems, please contact the hostmaster hostmaster@ca.FreeBSD.org for this domain. ftp://ftp.ca.FreeBSD.org/pub/FreeBSD/ China In case of problems, please contact the hostmaster phj@cn.FreeBSD.org for this domain. ftp://ftp.cn.FreeBSD.org/pub/FreeBSD/ Czech Republic In case of problems, please contact the hostmaster hostmaster@cz.FreeBSD.org for this domain. ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/ Contact: calda@dzungle.ms.mff.cuni.cz Denmark In case of problems, please contact the hostmaster hostmaster@dk.FreeBSD.org for this domain. ftp://ftp.dk.FreeBSD.org/pub/FreeBSD/ Estonia In case of problems, please contact the hostmaster hostmaster@ee.FreeBSD.org for this domain. ftp://ftp.ee.FreeBSD.org/pub/FreeBSD/ Finland In case of problems, please contact the hostmaster hostmaster@fi.FreeBSD.org for this domain. ftp://ftp.fi.FreeBSD.org/pub/FreeBSD/ France In case of problems, please contact the hostmaster hostmaster@fr.FreeBSD.org for this domain. ftp://ftp.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.fr.FreeBSD.org/pub/FreeBSD/ Germany In case of problems, please contact the mirror admins de-bsd-hubs@de.FreeBSD.org for this domain. ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/ Hong Kong ftp://ftp.hk.super.net/pub/FreeBSD/ Contact: ftp-admin@HK.Super.NET. Hungary In case of problems, please contact the hostmaster mohacsi@ik.bme.hu for this domain. ftp://ftp.hu.FreeBSD.org/pub/FreeBSD/ Ireland In case of problems, please contact the hostmaster hostmaster@ie.FreeBSD.org for this domain. ftp://ftp.ie.FreeBSD.org/pub/FreeBSD/ Israel In case of problems, please contact the hostmaster hostmaster@il.FreeBSD.org for this domain. ftp://ftp.il.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.il.FreeBSD.org/pub/FreeBSD/ Japan In case of problems, please contact the hostmaster hostmaster@jp.FreeBSD.org for this domain. ftp://ftp.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD/ Korea In case of problems, please contact the hostmaster hostmaster@kr.FreeBSD.org for this domain. ftp://ftp.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.kr.FreeBSD.org/pub/FreeBSD/ Lithuania In case of problems, please contact the hostmaster hostmaster@lt.FreeBSD.org for this domain. ftp://ftp.lt.FreeBSD.org/pub/FreeBSD/ Netherlands In case of problems, please contact the hostmaster hostmaster@nl.FreeBSD.org for this domain. ftp://ftp.nl.FreeBSD.org/pub/FreeBSD/ New Zealand In case of problems, please contact the hostmaster hostmaster@nz.FreeBSD.org for this domain. ftp://ftp.nz.FreeBSD.org/pub/FreeBSD/ Poland In case of problems, please contact the hostmaster hostmaster@pl.FreeBSD.org for this domain. ftp://ftp.pl.FreeBSD.org/pub/FreeBSD/ Portugal In case of problems, please contact the hostmaster hostmaster@pt.FreeBSD.org for this domain. ftp://ftp.pt.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.pt.FreeBSD.org/pub/FreeBSD/ Romania In case of problems, please contact the hostmaster hostmaster@ro.FreeBSD.org for this domain. ftp://ftp.ro.FreeBSD.org/pub/FreeBSD/ Russia In case of problems, please contact the hostmaster hostmaster@ru.FreeBSD.org for this domain. ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.ru.FreeBSD.org/pub/FreeBSD/ Saudi Arabia In case of problems, please contact ftpadmin@isu.net.sa ftp://ftp.isu.net.sa/pub/mirrors/ftp.freebsd.org/ South Africa In case of problems, please contact the hostmaster hostmaster@za.FreeBSD.org for this domain. ftp://ftp.za.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.za.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.za.FreeBSD.org/FreeBSD/ Slovak Republic In case of problems, please contact the hostmaster hostmaster@sk.FreeBSD.org for this domain. ftp://ftp.sk.FreeBSD.org/pub/FreeBSD/ Slovenia In case of problems, please contact the hostmaster hostmaster@si.FreeBSD.org for this domain. ftp://ftp.si.FreeBSD.org/pub/FreeBSD/ Spain In case of problems, please contact the hostmaster hostmaster@es.FreeBSD.org for this domain. ftp://ftp.es.FreeBSD.org/pub/FreeBSD/ Sweden In case of problems, please contact the hostmaster hostmaster@se.FreeBSD.org for this domain. ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.se.FreeBSD.org/pub/FreeBSD/ Taiwan In case of problems, please contact the hostmaster hostmaster@tw.FreeBSD.org for this domain. ftp://ftp.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.tw.FreeBSD.org/pub/FreeBSD/ Thailand ftp://ftp.nectec.or.th/pub/FreeBSD/ Contact: ftpadmin@ftp.nectec.or.th. Ukraine ftp://ftp.ua.FreeBSD.org/pub/FreeBSD/ Contact: freebsd-mnt@lucky.net. UK In case of problems, please contact the hostmaster hostmaster@uk.FreeBSD.org for this domain. ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.uk.FreeBSD.org/pub/FreeBSD/ USA In case of problems, please contact the hostmaster hostmaster@FreeBSD.org for this domain. ftp://ftp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.FreeBSD.org/pub/FreeBSD/ ftp://ftp8.FreeBSD.org/pub/FreeBSD/ ftp://ftp9.FreeBSD.org/pub/os/FreeBSD/ ftp://ftp10.FreeBSD.org/pub/FreeBSD/ Anonymous CVS <anchor id="anoncvs-intro">Introduction Anonymous CVS (or, as it is otherwise known, anoncvs) is a feature provided by the CVS utilities bundled with FreeBSD for synchronizing with a remote CVS repository. Among other things, it allows users of FreeBSD to perform, with no special privileges, read-only CVS operations against one of the FreeBSD project's official anoncvs servers. To use it, one simply sets the CVSROOT environment variable to point at the appropriate anoncvs server, provides the well-known password anoncvs with the cvs login command, and then uses the &man.cvs.1; command to access it like any local repository. While it can also be said that the CVSup and anoncvs services both perform essentially the same function, there are various trade-offs which can influence the user's choice of synchronization methods. In a nutshell, CVSup is much more efficient in its usage of network resources and is by far the most technically sophisticated of the two, but at a price. To use CVSup, a special client must first be installed and configured before any bits can be grabbed, and then only in the fairly large chunks which CVSup calls collections. Anoncvs, by contrast, can be used to examine anything from an individual file to a specific program (like ls or grep) by referencing the CVS module name. Of course, anoncvs is also only good for read-only operations on the CVS repository, so if it's your intention to support local development in one repository shared with the FreeBSD project bits then CVSup is really your only option. <anchor id="anoncvs-usage">Using Anonymous CVS Configuring &man.cvs.1; to use an Anonymous CVS repository is a simple matter of setting the CVSROOT environment variable to point to one of the FreeBSD project's anoncvs servers. At the time of this writing, the following servers are available: USA: :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs (Use cvs login and enter the password anoncvs when prompted.) Since CVS allows one to check out virtually any version of the FreeBSD sources that ever existed (or, in some cases, will exist :-), you need to be familiar with the revision () flag to &man.cvs.1; and what some of the permissible values for it in the FreeBSD Project repository are. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. Here are the branch tags that users might be interested in (keep in mind that the only tags valid for the ports collection is HEAD). HEAD Symbolic name for the main line, or FreeBSD-CURRENT. Also the default when no revision is specified. RELENG_4 The line of development for FreeBSD-4.X, also known as FreeBSD-STABLE. RELENG_4_3 The release branch for FreeBSD-4.3, used only for security advisories and other seriously critical fixes. RELENG_3 The line of development for FreeBSD-3.X, also known as 3.X-STABLE. RELENG_2_2 The line of development for FreeBSD-2.2.X, also known as 2.2-STABLE. This branch is mostly obsolete. Here are the revision tags that users might be interested in. Again, none of these are valid for the ports collection since the ports collection does not have multiple revisions. RELENG_4_3_0_RELEASE FreeBSD 4.3. RELENG_4_2_0_RELEASE FreeBSD 4.2. RELENG_4_1_1_RELEASE FreeBSD 4.1.1. RELENG_4_1_0_RELEASE FreeBSD 4.1. RELENG_4_0_0_RELEASE FreeBSD 4.0. RELENG_3_5_0_RELEASE FreeBSD-3.5. RELENG_3_4_0_RELEASE FreeBSD-3.4. RELENG_3_3_0_RELEASE FreeBSD-3.3. RELENG_3_2_0_RELEASE FreeBSD-3.2. RELENG_3_1_0_RELEASE FreeBSD-3.1. RELENG_3_0_0_RELEASE FreeBSD-3.0. RELENG_2_2_8_RELEASE FreeBSD-2.2.8. RELENG_2_2_7_RELEASE FreeBSD-2.2.7. RELENG_2_2_6_RELEASE FreeBSD-2.2.6. RELENG_2_2_5_RELEASE FreeBSD-2.2.5. RELENG_2_2_2_RELEASE FreeBSD-2.2.2. RELENG_2_2_1_RELEASE FreeBSD-2.2.1. RELENG_2_2_0_RELEASE FreeBSD-2.2.0. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the flag. See the &man.cvs.1; man page for more details. Examples While it really is recommended that you read the manual page for &man.cvs.1; thoroughly before doing anything, here are some quick examples which essentially show how to use Anonymous CVS: Checking out something from -CURRENT (&man.ls.1;) and deleting it again: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co ls &prompt.user; cvs release -d ls &prompt.user; cvs logout Checking out the version of &man.ls.1; in the 3.X-STABLE branch: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co -rRELENG_3 ls &prompt.user; cvs release -d ls &prompt.user; cvs logout Creating a list of changes (as unified diffs) to &man.ls.1; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs rdiff -u -rRELENG_3_0_0_RELEASE -rRELENG_3_4_0_RELEASE ls &prompt.user; cvs logout Finding out what other module names can be used: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs &prompt.user; cvs login At the prompt, enter the password anoncvs. &prompt.user; cvs co modules &prompt.user; more modules/modules &prompt.user; cvs release -d modules &prompt.user; cvs logout Other Resources The following additional resources may be helpful in learning CVS: CVS Tutorial from Cal Poly. Cyclic Software, commercial maintainers of CVS. CVSWeb is the FreeBSD Project web interface for CVS. Using CTM CTM is a method for keeping a remote directory tree in sync with a central one. It has been developed for usage with FreeBSD's source trees, though other people may find it useful for other purposes as time goes by. Little, if any, documentation currently exists at this time on the process of creating deltas, so talk to &a.phk; for more information should you wish to use CTM for other things. Why should I use <application>CTM</application>? CTM will give you a local copy of the FreeBSD source trees. There are a number of “flavors” of the tree available. Whether you wish to track the entire CVS tree or just one of the branches, CTM can provide you the information. If you are an active developer on FreeBSD, but have lousy or non-existent TCP/IP connectivity, or simply wish to have the changes automatically sent to you, CTM was made for you. You will need to obtain up to three deltas per day for the most active branches. However, you should consider having them sent by automatic email. The sizes of the updates are always kept as small as possible. This is typically less than 5K, with an occasional (one in ten) being 10-50K and every now and then a - biggie of 100K+ or more coming around. + large 100K+ or more coming around. You will also need to make yourself aware of the various caveats related to working directly from the development sources rather than a pre-packaged release. This is particularly true if you choose the “current” sources. It is recommended that you read Staying current with FreeBSD. What do I need to use <application>CTM</application>? You will need two things: The CTM program, and the initial deltas to feed it (to get up to “current” levels). The CTM program has been part of FreeBSD ever since version 2.0 was released, and lives in /usr/src/usr.sbin/CTM if you have a copy of the source available. If you are running a pre-2.0 version of FreeBSD, you can fetch the current CTM sources directly from: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/ The “deltas” you feed CTM can be had two ways, FTP or email. If you have general FTP access to the Internet then the following FTP sites support access to CTM: ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ or see section mirrors. FTP the relevant directory and fetch the README file, starting from there. If you wish to get your deltas via email: Send email to &a.majordomo; to subscribe to one of the CTM distribution lists. - “ctm-cvs-cur” supports the entire cvs tree. + “ctm-cvs-cur” supports the entire CVS tree. “ctm-src-cur” supports the head of the development branch. “ctm-src-2_2” supports the 2.2 release branch, etc.. (If you do not know how to subscribe yourself using majordomo, send a message first containing the word help — it will send you back usage instructions.) When you begin receiving your CTM updates in the mail, you may use the ctm_rmail program to unpack and apply them. You can actually use the ctm_rmail program directly from a entry in /etc/aliases if you want to have the process run in a fully automated fashion. Check the ctm_rmail man page for more details. No matter what method you use to get the CTM deltas, you should subscribe to the ctm-announce@FreeBSD.org mailing list. In the future, this will be the only place where announcements concerning the operations of the CTM system will be posted. Send an email to &a.majordomo; with a single line of subscribe ctm-announce to get added to the list. Using <application>CTM</application> for the first time Before you can start using CTM deltas, you will need to get to a starting point for the deltas produced subsequently to it. First you should determine what you already have. Everyone can start from an “empty” directory. You must use an initial “Empty” delta to start off your CTM supported tree. At some point it is intended that one of these “started” deltas be distributed on the CD for your convenience, however, this does not currently happen. Since the trees are many tens of megabytes, you should prefer to start from something already at hand. If you have a -RELEASE CD, you can copy or extract an initial source from it. This will save a significant transfer of data. You can recognize these “starter” deltas by the X appended to the number (src-cur.3210XEmpty.gz for instance). The designation following the X corresponds to the origin of your initial “seed”. Empty is an empty directory. As a rule a base transition from Empty is produced every 100 deltas. By the way, they are large! 25 to 30 Megabytes of gzip'd data is common for the XEmpty deltas. Once you've picked a base delta to start from, you will also need all deltas with higher numbers following it. Using <application>CTM</application> in your daily life To apply the deltas, simply say: &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* CTM understands deltas which have been put through gzip, so you do not need to - gunzip them first, this saves disk space. + gunzip them first, this saves disk space. Unless it feels very secure about the entire process, CTM will not touch your tree. To verify a delta you can also use the flag and CTM will not actually touch your tree; it will merely verify the integrity of the delta and see if it would apply cleanly to your current tree. There are other options to CTM as well, see the manual pages or look in the sources for more information. That is really all there is to it. Every time you get a new delta, just run it through CTM to keep your sources up to date. Do not remove the deltas if they are hard to download again. You just might want to keep them around in case something bad happens. Even if you only have floppy disks, consider using fdwrite to make a copy. Keeping your local changes As a developer one would like to experiment with and change files in the source tree. CTM supports local modifications in a limited way: before checking for the presence of a file foo, it first looks for foo.ctm. If this file exists, CTM will operate on it instead of foo. This behavior gives us a simple way to maintain local changes: simply copy the files you plan to modify to the corresponding file names with a .ctm suffix. Then you can freely hack the code, while CTM keeps the .ctm file up-to-date. Other interesting <application>CTM</application> options Finding out exactly what would be touched by an update You can determine the list of changes that CTM will make on your source repository using the option to CTM. This is useful if you would like to keep logs of the changes, pre- or post- process the modified files in any manner, or just are feeling a tad paranoid :-). Making backups before updating Sometimes you may want to backup all the files that would be changed by a CTM update. Specifying the option causes CTM to backup all files that would be touched by a given CTM delta to backup-file. Restricting the files touched by an update Sometimes you would be interested in restricting the scope of a given CTM update, or may be interested in extracting just a few files from a sequence of deltas. You can control the list of files that CTM would operate on by specifying filtering regular expressions using the and options. For example, to extract an up-to-date copy of lib/libc/Makefile from your collection of saved CTM deltas, run the commands: &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* For every file specified in a CTM delta, the and options are applied in the order given on the command line. The file is processed by CTM only if it is marked as eligible after all the and options are applied to it. Future plans for <application>CTM</application> Tons of them: Use some kind of authentication into the CTM system, so as to allow detection of spoofed CTM updates. Clean up the options to CTM, they became confusing and counter intuitive. Miscellaneous stuff There is a sequence of deltas for the ports collection too, but interest has not been all that high yet. Tell me if you want an email list for that too and we will consider setting it up. CTM mirrors CTM/FreeBSD is available via anonymous FTP from the following mirror sites. If you choose to obtain CTM via anonymous FTP, please try to use a site near you. In case of problems, please contact &a.phk;. California, Bay Area, official source ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CTM/ Germany, Trier ftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTM/ South Africa, backup server for old deltas ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ Taiwan/R.O.C, Chiayi ftp://ctm.tw.FreeBSD.org/pub/FreeBSD/CTM/ ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/CTM/ ftp://ctm3.tw.FreeBSD.org/pub/freebsd/CTM/ If you did not find a mirror near to you or the mirror is incomplete, try FTP search at http://ftpsearch.ntnu.no/ftpsearch. FTP search is a great free archie server in Trondheim, Norway. Using CVSup Introduction CVSup is a software package for distributing and updating source trees from a master CVS repository on a remote server host. The FreeBSD sources are maintained in a CVS repository on a central development machine in California. With CVSup, FreeBSD users can easily keep their own source trees up to date. CVSup uses the so-called pull model of updating. Under the pull model, each client asks the server for updates, if and when they are wanted. The server waits passively for update requests from its clients. Thus all updates are instigated by the client. The server never sends unsolicited updates. Users must either run the CVSup client manually to get an update, or they must set up a cron job to run it automatically on a regular basis. The term CVSup, capitalized just so, refers to the entire software package. Its main components are the client cvsup which runs on each user's machine, and the server cvsupd which runs at each of the FreeBSD mirror sites. As you read the FreeBSD documentation and mailing lists, you may see references to sup. Sup was the predecessor of CVSup, and it served a similar purpose.CVSup is in used in much the same way as sup and, in fact, uses configuration files which are backward-compatible with sup's. Sup is no longer used in the FreeBSD project, because CVSup is both faster and more flexible. Installation The easiest way to install CVSup is to use the net/cvsup-bin port from the FreeBSD ports collection. If you prefer to build CVSup from source, you can use the net/cvsup port instead. But be forewarned: the net/cvsup port depends on the Modula-3 system, which takes a substantial amount of time, memory, and disk space to build. - If you do not know anything about cvsup at all and want a + If you do not know anything about + CVSup at all and want a single package which will install it, set up the configuration file and start the transfer via a pointy-clicky type of interface, then get the cvsupit package. Just hand it to &man.pkg.add.1; and it will lead you through the configuration process in a menu-oriented fashion. CVSup Configuration CVSup's operation is controlled by a configuration file called the supfile. There are some sample supfiles in the directory /usr/share/examples/cvsup/. The information in a supfile answers the following questions for cvsup: Which files do you want to receive? Which versions of them do you want? Where do you want to get them from? Where do you want to put them on your own machine? Where do you want to put your status files? In the following sections, we will construct a typical supfile by answering each of these questions in turn. First, we describe the overall structure of a supfile. A supfile is a text file. Comments begin with # and extend to the end of the line. Lines that are blank and lines that contain only comments are ignored. Each remaining line describes a set of files that the user wishes to receive. The line begins with the name of a collection, a logical grouping of files defined by the server. The name of the collection tells the server which files you want. After the collection name come zero or more fields, separated by white space. These fields answer the questions listed above. There are two types of fields: flag fields and value fields. A flag field consists of a keyword standing alone, e.g., delete or compress. A value field also begins with a keyword, but the keyword is followed without intervening white space by = and a second word. For example, release=cvs is a value field. A supfile typically specifies more than one collection to receive. One way to structure a supfile is to specify all of the relevant fields explicitly for each collection. However, that tends to make the supfile lines quite long, and it is inconvenient because most fields are the same for all of the collections in a supfile. CVSup provides a defaulting mechanism to avoid these problems. Lines beginning with the special pseudo-collection name *default can be used to set flags and values which will be used as defaults for the subsequent collections in the supfile. A default value can be overridden for an individual collection, by specifying a different value with the collection itself. Defaults can also be changed or augmented in mid-supfile by additional *default lines. With this background, we will now proceed to construct a supfile for receiving and updating the main source tree of FreeBSD-CURRENT. Which files do you want to receive? The files available via CVSup are organized into named groups called collections. The collections that are available are described here. In this example, we wish to receive the entire main source tree for the FreeBSD system. There is a single large collection src-all which will give us all of that. As a first step toward constructing our supfile, we simply list the collections, one per line (in this case, only one line): src-all Which version(s) of them do you want? With CVSup, you can receive virtually any version of the sources that ever existed. - That is possible because the cvsupd server works directly - from the CVS repository, which contains all of the versions. - You specify which one of them you want using the + That is possible because the + cvsupd server works directly from + the CVS repository, which contains all of the versions. You + specify which one of them you want using the tag= and value fields. Be very careful to specify any tag= fields correctly. Some tags are valid only for certain collections of files. If you specify an incorrect or - misspelled tag, CVSup will delete files which you probably + misspelled tag, CVSup + will delete files which you probably do not want deleted. In particular, use only tag=. for the ports-* collections. The tag= field names a symbolic tag in the repository. There are two kinds of tags, revision tags and branch tags. A revision tag refers to a specific revision. Its meaning stays the same from day to day. A branch tag, on the other hand, refers to the latest revision on a given line of development, at any given time. Because a branch tag does not refer to a specific revision, it may mean something different tomorrow than it means today. Here are the branch tags that users might be interested in. Keep in mind that only the tag=. is relevant for the ports collection. tag=. The main line of development, also known as FreeBSD-CURRENT. The . is not punctuation; it is the name of the tag. Valid for all collections. tag=RELENG_4 The line of development for FreeBSD-4.X, also known as FreeBSD-STABLE. tag=RELENG_3 The line of development for FreeBSD-3.X tag=RELENG_2_2 The line of development for FreeBSD-2.2.X, also known as 2.2-STABLE. Here are the revision tags that users might be interested in. Again, these are not valid for the ports collection. tag=RELENG_4_2_0_RELEASE FreeBSD-4.2. tag=RELENG_4_1_1_RELEASE FreeBSD-4.1.1. tag=RELENG_4_1_0_RELEASE FreeBSD-4.1. tag=RELENG_4_0_0_RELEASE FreeBSD-4.0. tag=RELENG_3_5_0_RELEASE FreeBSD-3.5. tag=RELENG_3_4_0_RELEASE FreeBSD-3.4. tag=RELENG_3_3_0_RELEASE FreeBSD-3.3. tag=RELENG_3_2_0_RELEASE FreeBSD-3.2. tag=RELENG_3_1_0_RELEASE FreeBSD-3.1. tag=RELENG_3_0_0_RELEASE FreeBSD-3.0. tag=RELENG_2_2_8_RELEASE FreeBSD-2.2.8. tag=RELENG_2_2_7_RELEASE FreeBSD-2.2.7. tag=RELENG_2_2_6_RELEASE FreeBSD-2.2.6. tag=RELENG_2_2_5_RELEASE FreeBSD-2.2.5. tag=RELENG_2_2_2_RELEASE FreeBSD-2.2.2. tag=RELENG_2_2_1_RELEASE FreeBSD-2.2.1. tag=RELENG_2_2_0_RELEASE FreeBSD-2.2.0. Be very careful to type the tag name exactly as shown. CVSup cannot distinguish between valid and invalid tags. If you misspell the tag, CVSup will behave as though you had specified a valid tag which happens to refer to no files at all. It will delete your existing sources in that case. When you specify a branch tag, you normally receive the latest versions of the files on that line of development. If you wish to receive some past version, you can do so by specifying a date with the value field. The &man.cvsup.1; manual page explains how to do that. For our example, we wish to receive FreeBSD-CURRENT. We add this line at the beginning of our supfile: *default tag=. There is an important special case that comes into play if you specify neither a tag= field nor a date= field. In that case, you receive the actual RCS files directly from the server's CVS repository, rather than receiving a particular version. Developers generally prefer this mode of operation. By maintaining a copy of the repository itself on their systems, they gain the ability to browse the revision histories and examine past versions of files. This gain is achieved at a large cost in terms of disk space, however. Where do you want to get them from? We use the host= field to tell cvsup where to obtain its updates. Any of the CVSup mirror sites will do, though you should try to select one that is close to you in cyberspace. In this example we will use a fictional FreeBSD distribution site, cvsup666.FreeBSD.org: *default host=cvsup666.FreeBSD.org You will need to change the host to one that actually - exists before running CVSup. On any particular run of + exists before running CVSup. + On any particular run of cvsup, you can override the host setting on the command line, with . Where do you want to put them on your own machine? The prefix= field tells cvsup where to put the files it receives. In this example, we will put the source files directly into our main source tree, /usr/src. The src directory is already implicit in the collections we have chosen to receive, so this is the correct specification: *default prefix=/usr Where should cvsup maintain its status files? - The cvsup client maintains certain status files in what + The CVSup client maintains + certain status files in what is called the base directory. These files help CVSup to work more efficiently, by keeping track of which updates you have already received. We will use the standard base directory, /usr/local/etc/cvsup: *default base=/usr/local/etc/cvsup This setting is used by default if it is not specified in the supfile, so we actually do not need the above line. If your base directory does not already exist, now would be a good time to create it. The cvsup client will refuse to run if the base directory does not exist. Miscellaneous supfile settings: There is one more line of boiler plate that normally needs to be present in the supfile: *default release=cvs delete use-rel-suffix compress release=cvs indicates that the server should get its information out of the main FreeBSD CVS repository. This is virtually always the case, but there are other possibilities which are beyond the scope of this discussion. delete gives CVSup permission to delete files. You should always specify this, so that CVSup can keep your source tree fully up-to-date. CVSup is careful to delete only those files for which it is responsible. Any extra files you happen to have will be left strictly alone. use-rel-suffix is ... arcane. If you really want to know about it, see the &man.cvsup.1; manual page. Otherwise, just specify it and do not worry about it. compress enables the use of gzip-style compression on the communication channel. If your network link is T1 speed or faster, you probably should not use compression. Otherwise, it helps substantially. Putting it all together: Here is the entire supfile for our example: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all The refuse file As mentioned above, CVSup uses a pull method. Basically, this means that you connect to the CVSup server, and it says, Here's what you can download from me..., and your client responds OK, I'll take this, this, this, and this. In the default configuration, the CVSup client will take every file associated with the collection and tag you chose in the configuration file. However, this is not always what you want, especially if you are synching the doc, ports, or www trees — most people can't read four or five languages, and therefore they don't need to download the language-specific files. If you are CVSuping the ports collection, you can get around this by specifying each collection individually (e.g., ports-astrology, ports-biology, etc instead of simply saying ports-all). However, since the doc and www trees do not have language-specific collections, you must use one of CVSup's many nifty features; the refuse file. The refuse file essentially tells CVSup that it should not take every single file from a collection; in other words, it tells the client to refuse certain files from the server. The refuse file can be found (or, if you do not yet have one, should be placed) in base/sup/refuse. base is defined in your supfile; by default, base is /usr/local/etc/cvsup, which means that by default the refuse file is in /usr/local/etc/cvsup/sup/refuse. The refuse file has a very simple format; it simply contains the names of files or directories that you do not wish to download. For example, if you cannot speak any languages other than English and some German, and you do not feel the need to use the German applications, you can put the following in your refuse file: ports/chinese ports/german ports/japanese ports/korean ports/russian ports/vietnamese doc/es_ES.ISO8859-1 doc/ja_JP.eucJP and so forth for the other languages. Note that the name of the repository is the first directory in the refuse file. With this very useful feature, those users who are on slow links or pay by the minute for their Internet connection will be able to save valuable time as they will no longer need to download files that they will never use. For more information on refuse files and other neat features of CVSup, please view its man page. Running <application>CVSup</application> You are now ready to try an update. The command line for doing this is quite simple: &prompt.root; cvsup supfile where supfile is of course the name of the supfile you have just created. Assuming you are running under X11, cvsup will display a GUI window with some buttons to do the usual things. Press the go button, and watch it run. Since you are updating your actual /usr/src tree in this example, you will need to run the program as root so that cvsup has the permissions it needs to update your files. Having just created your configuration file, and having never used this program before, that might understandably make you nervous. There is an easy way to do a trial run without touching your precious files. Just create an empty directory somewhere convenient, and name it as an extra argument on the command line: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest The directory you specify will be used as the destination directory for all file updates. CVSup will examine your usual files in /usr/src, but it will not modify or delete any of them. Any file updates will instead land in /var/tmp/dest/usr/src. CVSup will also leave its base directory status files untouched when run this way. The new versions of those files will be written into the specified directory. As long as you have read access to /usr/src, you do not even need to be root to perform this kind of trial run. If you are not running X11 or if you just do not like GUIs, you should add a couple of options to the command line when you run cvsup: &prompt.root; cvsup -g -L 2 supfile - The tells cvsup not to use its GUI. - This is automatic if you are not running X11, but otherwise you - have to specify it. + The tells + CVSup not to use its GUI. This is + automatic if you are not running X11, but otherwise you have to + specify it. - The tells cvsup to print out the + The tells + CVSup to print out the details of all the file updates it is doing. There are three levels of verbosity, from to . The default is 0, which means total silence except for error messages. There are plenty of other options available. For a brief list of them, type cvsup -H. For more detailed descriptions, see the manual page. Once you are satisfied with the way updates are working, you - can arrange for regular runs of cvsup using &man.cron.8;. - Obviously, you should not let cvsup use its GUI when running it - from cron. + can arrange for regular runs of CVSup + using &man.cron.8;. + Obviously, you should not let CVSup + use its GUI when running it from &man.cron.8;. <application>CVSup</application> File Collections The file collections available via CVSup are organized hierarchically. There are a few large collections, and they are divided into smaller sub-collections. Receiving a large collection is equivalent to receiving each of its sub-collections. The hierarchical relationships among collections are reflected by the use of indentation in the list below. The most commonly used collections are src-all, and ports-all. The other collections are used only by small groups of people for specialized purposes, and some mirror sites may not carry all of them. cvs-all release=cvs The main FreeBSD CVS repository, including the cryptography code. distrib release=cvs Files related to the distribution and mirroring of FreeBSD. doc-all release=cvs Sources for the FreeBSD handbook and other documentation. ports-all release=cvs The FreeBSD ports collection. ports-archivers release=cvs Archiving tools. ports-astro release=cvs Astronomical ports. ports-audio release=cvs Sound support. ports-base release=cvs Miscellaneous files at the top of /usr/ports. ports-benchmarks release=cvs Benchmarks. ports-biology release=cvs Biology. ports-cad release=cvs Computer aided design tools. ports-chinese release=cvs Chinese language support. ports-comms release=cvs Communication software. ports-converters release=cvs character code converters. ports-databases release=cvs Databases. ports-deskutils release=cvs Things that used to be on the desktop before computers were invented. ports-devel release=cvs Development utilities. ports-editors release=cvs Editors. ports-emulators release=cvs Emulators for other operating systems. ports-ftp release=cvs FTP client and server utilities. ports-games release=cvs Games. ports-german release=cvs German language support. ports-graphics release=cvs Graphics utilities. ports-irc release=cvs Internet Relay Chat utilities. ports-japanese release=cvs Japanese language support. ports-java release=cvs Java utilities. ports-korean release=cvs Korean language support. ports-lang release=cvs Programming languages. ports-mail release=cvs Mail software. ports-math release=cvs Numerical computation software. ports-mbone release=cvs MBone applications. ports-misc release=cvs Miscellaneous utilities. ports-net release=cvs Networking software. ports-news release=cvs USENET news software. ports-palm release=cvs Software support for 3Com Palm(tm) series. ports-print release=cvs Printing software. ports-russian release=cvs Russian language support. ports-security release=cvs Security utilities. ports-shells release=cvs Command line shells. ports-sysutils release=cvs System utilities. ports-textproc release=cvs text processing utilities (does not include desktop publishing). ports-vietnamese release=cvs Vietnamese language support. ports-www release=cvs Software related to the World Wide Web. ports-x11 release=cvs Ports to support the X window system. ports-x11-clocks release=cvs X11 clocks. ports-x11-fm release=cvs X11 file managers. ports-x11-fonts release=cvs X11 fonts and font utilities. ports-x11-toolkits release=cvs X11 toolkits. ports-x11-servers X11 servers. ports-x11-wm X11 window managers. src-all release=cvs The main FreeBSD sources, including the cryptography code. src-base release=cvs Miscellaneous files at the top of /usr/src. src-bin release=cvs User utilities that may be needed in single-user mode (/usr/src/bin). src-contrib release=cvs Utilities and libraries from outside the FreeBSD project, used relatively unmodified (/usr/src/contrib). src-crypto release=cvs Cryptography utilities and libraries from outside the FreeBSD project, used relatively unmodified (/usr/src/crypto). src-eBones release=cvs Kerberos and DES (/usr/src/eBones). Not used in current releases of FreeBSD. src-etc release=cvs System configuration files (/usr/src/etc). src-games release=cvs Games (/usr/src/games). src-gnu release=cvs Utilities covered by the GNU Public License (/usr/src/gnu). src-include release=cvs Header files (/usr/src/include). src-kerberos5 release=cvs Kerberos5 security package (/usr/src/kerberos5). src-kerberosIV release=cvs KerberosIV security package (/usr/src/kerberosIV). src-lib release=cvs Libraries (/usr/src/lib). src-libexec release=cvs System programs normally executed by other programs (/usr/src/libexec). src-release release=cvs Files required to produce a FreeBSD release (/usr/src/release). src-secure release=cvs DES (/usr/src/secure). src-sbin release=cvs System utilities for single-user mode (/usr/src/sbin). src-share release=cvs Files that can be shared across multiple systems (/usr/src/share). src-sys release=cvs The kernel (/usr/src/sys). src-sys-crypto release=cvs Kernel cryptography code (/usr/src/sys/crypto). src-tools release=cvs Various tools for the maintenance of FreeBSD (/usr/src/tools). src-usrbin release=cvs User utilities (/usr/src/usr.bin). src-usrsbin release=cvs System utilities (/usr/src/usr.sbin). www release=cvs The sources for the World Wide Web data. distrib release=self - The CVSup server's own configuration files. Used by - CVSup mirror sites. + The CVSup server's own + configuration files. Used by CVSup + mirror sites. gnats release=current The GNATS bug-tracking database. mail-archive release=current FreeBSD mailing list archive. www release=current The installed World Wide Web data. Used by WWW mirror sites. For more information - For the CVSup FAQ and other information about CVSup, see + For the CVSup FAQ and other + information about CVSup, see The CVSup Home Page. Most FreeBSD-related discussion of CVSup takes place on the &a.hackers;. New versions of the software are announced there, as well as on the &a.announce;. Questions and bug reports should be addressed to the author of the program at cvsup-bugs@polstra.com. CVSup Sites CVSup servers for FreeBSD are running at the following sites: Argentina cvsup.ar.FreeBSD.org (maintainer msagre@cactus.fi.uba.ar) Australia cvsup.au.FreeBSD.org (maintainer dawes@xfree86.org) cvsup3.au.FreeBSD.org (maintainer FreeBSD@admin.gil.com.au) Austria cvsup.at.FreeBSD.org (maintainer postmaster@wu-wien.ac.at) Brazil cvsup.br.FreeBSD.org (maintainer cvsup@cvsup.br.FreeBSD.org) cvsup2.br.FreeBSD.org (maintainer tps@ti.sk) cvsup3.br.FreeBSD.org (maintainer camposr@matrix.com.br) Canada cvsup.ca.FreeBSD.org (maintainer dan@jaded.net) cvsup2.ca.FreeBSD.org (maintainer hostmaster@ca.freebsd.org) China cvsup.cn.FreeBSD.org (maintainer phj@cn.FreeBSD.org) Czech Republic cvsup.cz.FreeBSD.org (maintainer cejkar@dcse.fee.vutbr.cz) Denmark cvsup.dk.FreeBSD.org (maintainer jesper@skriver.dk) Estonia cvsup.ee.FreeBSD.org (maintainer taavi@uninet.ee) Finland cvsup.fi.FreeBSD.org (maintainer count@key.sms.fi) cvsup2.fi.FreeBSD.org (maintainer count@key.sms.fi) France cvsup.fr.FreeBSD.org (maintainer hostmaster@fr.FreeBSD.org) cvsup2.fr.FreeBSD.org (maintainer ftpmaint@uvsq.fr) Germany cvsup.de.FreeBSD.org (maintainer rse@freebsd.org) cvsup1.de.FreeBSD.org (maintainer wosch@FreeBSD.org) cvsup2.de.FreeBSD.org (maintainer cvsup@nikoma.de) cvsup3.de.FreeBSD.org (maintainer ag@leo.org) cvsup4.de.FreeBSD.org (maintainer cvsup@cosmo-project.de) cvsup5.de.FreeBSD.org (maintainer rse@freebsd.org) Greece cvsup.gr.FreeBSD.org (maintainer ftpadm@duth.gr) cvsup2.gr.FreeBSD.org (maintainer paschos@cs.uoi.gr) Iceland cvsup.is.FreeBSD.org (maintainer adam@veda.is) Ireland cvsup.ie.FreeBSD.org (maintainer dwmalone@maths.tcd.ie), Trinity College, Dublin. Japan cvsup.jp.FreeBSD.org (maintainer cvsupadm@jp.FreeBSD.org) cvsup2.jp.FreeBSD.org (maintainer max@FreeBSD.org) cvsup3.jp.FreeBSD.org (maintainer shige@cin.nihon-u.ac.jp) cvsup4.jp.FreeBSD.org (maintainer cvsup-admin@ftp.media.kyoto-u.ac.jp) cvsup5.jp.FreeBSD.org (maintainer cvsup@imasy.or.jp) cvsup6.jp.FreeBSD.org (maintainer cvsupadm@jp.FreeBSD.org) Korea cvsup.kr.FreeBSD.org (maintainer cjh@kr.FreeBSD.org) cvsup2.kr.FreeBSD.org (maintainer holywar@mail.holywar.net) Lithuania cvsup.lt.FreeBSD.org (maintainer domas.mituzas@delfi.lt) Netherlands cvsup.nl.FreeBSD.org (maintainer xaa@xaa.iae.nl) cvsup2.nl.FreeBSD.org (maintainer cvsup@nl.uu.net) Norway cvsup.no.FreeBSD.org (maintainer Per.Hove@math.ntnu.no) Poland cvsup.pl.FreeBSD.org (maintainer Mariusz@kam.pl) Portugal cvsup.pt.FreeBSD.org (maintainer jpedras@webvolution.net) Russia cvsup.ru.FreeBSD.org (maintainer ache@nagual.pp.ru) cvsup2.ru.FreeBSD.org (maintainer dv@dv.ru) cvsup3.ru.FreeBSD.org (maintainer fjoe@iclub.nsu.ru) cvsup4.ru.FreeBSD.org (maintainer zhecka@klondike.ru) cvsup5.ru.FreeBSD.org (maintainer maxim@macomnet.ru) cvsup6.ru.FreeBSD.org (maintainer pvr@corbina.net) Slovak Republic cvsup.sk.FreeBSD.org (maintainer tps@tps.sk) cvsup2.sk.FreeBSD.org (maintainer tps@tps.sk) Slovenia cvsup.si.FreeBSD.org (maintainer blaz@si.FreeBSD.org) South Africa cvsup.za.FreeBSD.org (maintainer markm@FreeBSD.org) cvsup2.za.FreeBSD.org (maintainer markm@FreeBSD.org) Spain cvsup.es.FreeBSD.org (maintainer jesusr@FreeBSD.org) cvsup2.es.FreeBSD.org (maintainer jesusr@FreeBSD.org) cvsup3.es.FreeBSD.org (maintainer jose@we.lc.ehu.es) Sweden cvsup.se.FreeBSD.org (maintainer pantzer@ludd.luth.se) cvsup2.se.FreeBSD.org (maintainer cvsup@dataphone.net) Taiwan cvsup.tw.FreeBSD.org (maintainer jdli@freebsd.csie.nctu.edu.tw) cvsup2.tw.FreeBSD.org (maintainer ycheng@sinica.edu.tw) cvsup3.tw.FreeBSD.org (maintainer foxfair@FreeBSD.org) Ukraine cvsup2.ua.FreeBSD.org (maintainer freebsd-mnt@lucky.net) cvsup3.ua.FreeBSD.org (maintainer ftpmaster@ukr.net), Kiev cvsup4.ua.FreeBSD.org (maintainer phantom@cris.net) United Kingdom cvsup.uk.FreeBSD.org (maintainer joe@pavilion.net) cvsup2.uk.FreeBSD.org (maintainer brian@FreeBSD.org) cvsup3.uk.FreeBSD.org (maintainer ftp-admin@plig.net) USA cvsup1.FreeBSD.org (maintainer skynyrd@opus.cts.cwu.edu), Washington state cvsup2.FreeBSD.org (maintainer jdp@FreeBSD.org), California cvsup3.FreeBSD.org (maintainer wollman@FreeBSD.org), Massachusetts cvsup4.FreeBSD.org (maintainer rgrimes@FreeBSD.org), Oregon cvsup5.FreeBSD.org (maintainer mjr@blackened.com), Arizona cvsup6.FreeBSD.org (maintainer jdp@FreeBSD.org), Florida cvsup7.FreeBSD.org (maintainer jdp@FreeBSD.org), Washington state cvsup8.FreeBSD.org (maintainer hostmaster@bigmirror.com), Washington state cvsup9.FreeBSD.org (maintainer qbsd@uswest.net), Minnesota cvsup10.FreeBSD.org (maintainer jdp@FreeBSD.org), California cvsup11.FreeBSD.org (maintainer cvsup@research.uu.net), Virginia cvsup12.FreeBSD.org (maintainer will@FreeBSD.org), Indiana cvsup13.FreeBSD.org (maintainer dima@valueclick.com), California cvsup14.FreeBSD.org (maintainer freebsd-cvsup@mfnx.net), California cvsup15.FreeBSD.org (maintainer cvsup@math.uic.edu), Illinois cvsup16.FreeBSD.org (maintainer pth3k@virginia.edu), Virginia cvsup17.FreeBSD.org (maintainer cvsup@mirrortree.com), Washington state AFS Sites AFS servers for FreeBSD are running at the following sites; Sweden The path to the files are: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Maintainer ftp@stacken.kth.se diff --git a/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml b/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml index 06d6817232..8cfc1df408 100644 --- a/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/multimedia/chapter.sgml @@ -1,332 +1,333 @@ Sound Contributed by Moses Moore jm-moses@home.com, 20 November 2000. Synopsis This chapter of the handbook deals with setting up sound on a FreeBSD system. Locating the Correct Device PCI ISA sound cards Before you begin, you should know the model of the card you have, the chip it uses, and whether it is a PCI or ISA card. FreeBSD supports a wide variety of both PCI and ISA cards. If you do not see your card in the following list, check the &man.pcm.4; manual page. This is not a complete list; however, it does list some of the most common cards. Crystal 4237, 4236, 4232, 4231 Yamaha OPL-SAx OPTi931 Ensoniq AudioPCI 1370/1371 ESS Solo-1/1E NeoMagic 256AV/ZX Sound Blaster Pro, 16, 32, AWE64, AWE128, Live Creative ViBRA16 Advanced Asound 100, 110, and Logic ALS120 ES 1868, 1869, 1879, 1888 Gravis UltraSound Aureal Vortex 1 or 2 kernelconfiguration The driver you use in your kernel depends on the kind of card you have. The sections below provide more information and what you will need to add to your kernel configuration. Creative, Advance, and ESS Sound Cards If you have one of the above cards, you will need to add device pcm to your kernel. If you have a PnP ISA card, you will also need to add device sbc to your kernel. For a non-PnP ISA card, add device pcm and device sbc0 at isa? port0x220 irq 5 drq 1 flags 0x15 to your kernel. Those are the default settings. You may need to change the IRQ, etc. See the &man.sbc.4; man page for more information. The Sound Blaster Live is not supported under FreeBSD 4.0 without a patch, which this document will not cover. It is recommended that you update to the latest -STABLE before trying to use this card. Gravis UltraSound Cards For a PnP ISA card, you will need to add device pcm and device gusc to your kernel. If you have a non-PnP ISA card, you will need to add device pcm and device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13 to your kernel. You may need to change the IRQ, etc. See the &man.gusc.4; man page for more information. Crystal Sound Cards For Crystal cards, you will need both device pcm and device csa in your kernel. Generic Support For PnP ISA or PCI cards, you will need to add device pcm to your kernel configuration. If you have a non-PnP ISA sound card that does not have a bridge driver, you will need to add device pcm0 at isa? irq 10 drq 1 flags 0x0 to your kernel configuration. You may need to change the IRQ, etc., to match your hardware configuration. Recompiling the Kernel After adding the driver(s) you need to your kernel configuration, you will need to recompile your kernel. Please see of the handbook for more information. Creating and Testing the Device Nodes device nodes After you reboot, log in and run cat /dev/sndstat. You should see output similar to the following: FreeBSD Audio Driver (newpcm) Sep 21 2000 18:29:53 Installed devices: pcm0: <Aureal Vortex 8830> at memory 0xfeb40000 irq 5 (4p/1r +channels duplex) If you see an error message, something went wrong earlier. If that happens, go through your kernel configuration file again and make sure you chose the correct device. If it reported no errors and returned pcm0, su to root and do the following: &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd0 If it reported no errors and returned pcm1, su to root and do the following: &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd1 Please note that either of the above commands will not create a /dev/snd device! Instead it creates a group of device nodes including: Device Description /dev/audio SPARC-compatible audio device /dev/dsp Digitized voice device /dev/dspW Like /dev/dsp, but 16 bits per sample /dev/midi Raw midi access device /dev/mixer Control port mixer device /dev/music Level 2 sequencer interface /dev/sequencer Sequencer device /dev/pss Programmable device interface If all goes well, you should now have a functioning sound card. If you do not, see the next section. Common Problems device node I get an unsupported subdevice XX error! One or more of the device nodes wasn't created correctly. Repeat the steps above. I/O port I get a sb_dspwr(XX) timed out error! The I/O port is not set correctly. IRQ I get a bad irq XX error! The IRQ is set incorrectly. Make sure that the set IRQ and the sound IRQ are the same. - I get a "xxx: gus pcm not attached, out of memory" + I get a xxx: gus pcm not attached, out of + memory error. What causes that? If this happens, it is because there is not enough available memory to use the device. diff --git a/en_US.ISO8859-1/books/handbook/policies/chapter.sgml b/en_US.ISO8859-1/books/handbook/policies/chapter.sgml index 69d33b26be..8731f45abe 100644 --- a/en_US.ISO8859-1/books/handbook/policies/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/policies/chapter.sgml @@ -1,400 +1,403 @@ Source Tree Guidelines and Policies Contributed by &a.phk;. This chapter documents various guidelines and policies in force for the FreeBSD source tree. <makevar>MAINTAINER</makevar> on Makefiles ports maintainer June 1996. If a particular portion of the FreeBSD distribution is being maintained by a person or group of persons, they can communicate this fact to the world by adding a MAINTAINER= email-addresses line to the Makefiles covering this portion of the source tree. The semantics of this are as follows: The maintainer owns and is responsible for that code. This means that he is responsible for fixing bugs and answer problem reports pertaining to that piece of the code, and in the case of contributed software, for tracking new versions, as appropriate. Changes to directories which have a maintainer defined shall be sent to the maintainer for review before being committed. Only if the maintainer does not respond for an unacceptable period of time, to several emails, will it be acceptable to commit changes without review by the maintainer. However, it is suggested that you try and have the changes reviewed by someone else if at all possible. It is of course not acceptable to add a person or group as maintainer unless they agree to assume this duty. On the other hand it doesn't have to be a committer and it can easily be a group of people. Contributed Software contributed software Contributed by &a.phk; and &a.obrien;. June 1996. Some parts of the FreeBSD distribution consist of software that is actively being maintained outside the FreeBSD project. For historical reasons, we call this contributed software. Some - examples are perl, gcc and patch. + examples are perl, gcc and + patch. Over the last couple of years, various methods have been used in dealing with this type of software and all have some number of advantages and drawbacks. No clear winner has emerged. Since this is the case, after some debate one of these methods has been selected as the official method and will be required for future imports of software of this kind. Furthermore, it is strongly suggested that existing contributed software converge on this model over time, as it has significant advantages over the old method, including the ability to easily obtain diffs relative to the official versions of the source by everyone (even without cvs access). This will make it significantly easier to return changes to the primary developers of the contributed software. Ultimately, however, it comes down to the people actually doing the work. If using this model is particularly unsuited to the package being dealt with, exceptions to these rules may be granted only with the approval of the core team and with the general consensus of the other developers. The ability to maintain the package in the future will be a key issue in the decisions. Because of some unfortunate design limitations with the RCS file format and CVS's use of vendor branches, minor, trivial and/or cosmetic changes are strongly discouraged on files that are still tracking the vendor branch. Spelling fixes are explicitly included here under the cosmetic category and are to be avoided for files with revision 1.1.x.x. The repository bloat impact from a single character change can be rather dramatic. The Tcl embedded programming language will be used as example of how this model works: src/contrib/tcl contains the source as distributed by the maintainers of this package. Parts that are entirely not applicable for FreeBSD can be removed. In the case of Tcl, the mac, win and compat subdirectories were eliminated before the import src/lib/libtcl contains only a "bmake style" Makefile that uses the standard bsd.lib.mk makefile rules to produce the library and install the documentation. - src/usr.bin/tclsh contains only a bmake style + src/usr.bin/tclsh contains only a + bmake style Makefile which will produce and install the tclsh program and its associated man-pages using the standard bsd.prog.mk rules. src/tools/tools/tcl_bmake contains a couple of - shell-scripts that can be of help when the tcl software needs updating. + shell-scripts that can be of help when the Tcl software needs updating. These are not part of the built or installed software. The important thing here is that the src/contrib/tcl directory is created according to the rules: It is supposed to contain the sources as distributed (on a proper CVS vendor-branch and without RCS keyword expansion) with as few FreeBSD-specific changes as possible. The 'easy-import' tool on - freefall will assist in doing the import, but if there are any doubts on + freefall will assist in doing the import, but if there + are any doubts on how to go about it, it is imperative that you ask first and not blunder ahead and hope it works out. CVS is not forgiving of import accidents and a fair amount of effort is required to back out major mistakes. Because of the previously mentioned design limitations with CVS's vendor branches, it is required that official patches from the vendor be applied to the original distributed sources and the result re-imported onto the vendor branch again. Official patches should never be patched into the FreeBSD checked out version and "committed", as this destroys the vendor branch coherency and makes importing future versions rather difficult as there will be conflicts. Since many packages contain files that are meant for compatibility with other architectures and environments that FreeBSD, it is permissible to remove parts of the distribution tree that are of no interest to FreeBSD in order to save space. Files containing copyright notices and release-note kind of information applicable to the remaining files shall not be removed. If it seems easier, the bmake Makefiles can be produced from the dist tree automatically by some utility, something which would hopefully make it even easier to upgrade to a new version. If this is done, be sure to check in such utilities (as necessary) in the src/tools directory along with the port itself so that it is available to future maintainers. In the src/contrib/tcl level directory, a file called FREEBSD-upgrade should be added and it should states things like: Which files have been left out Where the original distribution was obtained from and/or the official master site. Where to send patches back to the original authors Perhaps an overview of the FreeBSD-specific changes that have been made. However, please do not import FREEBSD-upgrade with the contributed source. Rather you should cvs add FREEBSD-upgrade ; cvs ci after the initial import. Example wording from src/contrib/cpio is below: This directory contains virgin sources of the original distribution files on a "vendor" branch. Do not, under any circumstances, attempt to upgrade the files in this directory via patches and a cvs commit. New versions or official-patch versions must be imported. Please remember to import with "-ko" to prevent CVS from corrupting any vendor RCS Ids. For the import of GNU cpio 2.4.2, the following files were removed: INSTALL cpio.info mkdir.c Makefile.in cpio.texi mkinstalldirs To upgrade to a newer version of cpio, when it is available: 1. Unpack the new version into an empty directory. [Do not make ANY changes to the files.] 2. Remove the files listed above and any others that don't apply to FreeBSD. 3. Use the command: cvs import -ko -m 'Virgin import of GNU cpio v<version>' \ src/contrib/cpio GNU cpio_<version> For example, to do the import of version 2.4.2, I typed: cvs import -ko -m 'Virgin import of GNU v2.4.2' \ src/contrib/cpio GNU cpio_2_4_2 4. Follow the instructions printed out in step 3 to resolve any conflicts between local FreeBSD changes and the newer version. Do not, under any circumstances, deviate from this procedure. To make local changes to cpio, simply patch and commit to the main branch (aka HEAD). Never make local changes on the GNU branch. All local changes should be submitted to "cpio@gnu.ai.mit.edu" for inclusion in the next vendor release. obrien@FreeBSD.org - 30 March 1997 Encumbered Files It might occasionally be necessary to include an encumbered file in the FreeBSD source tree. For example, if a device requires a small piece of binary code to be loaded to it before the device will operate, and we do not have the source to that code, then the binary file is said to be encumbered. The following policies apply to including encumbered files in the FreeBSD source tree. Any file which is interpreted or executed by the system CPU(s) and not in source format is encumbered. Any file with a license more restrictive than BSD or GNU is encumbered. A file which contains downloadable binary data for use by the hardware is not encumbered, unless (1) or (2) apply to it. It must be stored in an architecture neutral ASCII format (file2c or uuencoding is recommended). Any encumbered file requires specific approval from the Core team before it is added to the CVS repository. Encumbered files go in src/contrib or src/sys/contrib. The entire module should be kept together. There is no point in splitting it, unless there is code-sharing with non-encumbered code. Object files are named arch/filename.o.uu>. Kernel files; Should always be referenced in conf/files.* (for build simplicity). Should always be in LINT, but the Core team decides per case if it should be commented out or not. The Core team can, of course, change their minds later on. The Release Engineer decides whether or not it goes in to the release. User-land files; core team The Core team decides if the code should be part of make world. release engineer The Release Engineer decides if it goes in to the release. Shared Libraries Contributed by &a.asami;, &a.peter;, and &a.obrien; 9 December 1996. If you are adding shared library support to a port or other piece of software that doesn't have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software. The three principles of shared library building are: Start from 1.0 If there is a change that is backwards compatible, bump minor number (note that ELF systems ignore the minor number) If there is an incompatible change, bump major number For instance, added functions and bugfixes result in the minor version number being bumped, while deleted functions, changed function call syntax etc. will force the major version number to change. Stick to version numbers of the form major.minor (x.y). Our a.out dynamic linker does not handle version numbers of the form x.y.z well. Any version number after the y (ie. the third digit) is totally ignored when comparing shared lib version numbers to decide which library to link with. Given two shared libraries that differ only in the micro revision, ld.so will link with the higher one. Ie: if you link with libfoo.so.3.3.3, the linker only records 3.3 in the headers, and will link with anything starting with libfoo.so.3.(anything >= 3).(highest available). ld.so will always use the highest minor revision. Ie: it will use libc.so.2.2 in preference to libc.so.2.0, even if the program was initially linked with libc.so.2.0. In addition, our ELF dynamic linker does not handle minor version numbers at all. However, one should still specify a major and minor version number as our Makefiles "do the right thing" based on the type of system. For non-port libraries, it is also our policy to change the shared library version number only once between releases. In addition, it is our policy to change the major shared library version number only once between major OS releases. Ie: X.0 to (X+1).0. When you make a change to a system library that requires the version number to be bumped, check the Makefile's commit logs. It is the responsibility of the committer to ensure that the first such change since the release will result in the shared library version number in the Makefile to be updated, and any subsequent changes will not. diff --git a/en_US.ISO8859-1/books/handbook/ports/chapter.sgml b/en_US.ISO8859-1/books/handbook/ports/chapter.sgml index a5f109e1bb..a143ef597c 100644 --- a/en_US.ISO8859-1/books/handbook/ports/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/ports/chapter.sgml @@ -1,1260 +1,1267 @@ Installing Applications: Packages and Ports Synopsis There is only so much you can do with FreeBSD. If you are an operating systems developer then the base system likely contains everything you need. If that is not what you are planning to do with FreeBSD then you will probably want to install additional software—perhaps a web server, or a mail reader, or a graphical - environment such as KDE or GNOME. + environment such as KDE or + GNOME. If you have used a Unix system before you will know that the typical procedure for installing third party software goes something like this: Download the software, which might be distributed in source code format, or as a binary. Unpack the software from its distribution format (typically a tarball compressed with either &man.compress.1; or &man.gzip.1;). Locate the documentation (perhaps a README file, or some files in a doc/ subdirectory) and read up on how to install the software. If the software was distributed in source format, compile it. This may involve editing a Makefile, or running a configure script, and other work. 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 &os.numports; 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 pkg_* commands, such as &man.pkg.add.1; &man.pkg.delete.1;, &man.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 the pkg_* commands. 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 any of 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 686 processor. Some packages have compile time options relating to what they can and can't do. For example, Apache can be configured with a wide variety of different builtin 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 freebsd-ports. The remainder of this chapter will explain how to use packages and ports to install and manage third party software on FreeBSD. 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. Currently there are over &os.numports; applications available as packages or ports. 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 e-mail 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/) or AppWatch (http://www.appwatch.com/) to find an application, then check back at the FreeBSD site to see if the application has been ported yet. Chern Lee Contributed Using the Packages System Installing a Package You can use the &man.pkg.add.1; utility to install a FreeBSD software package from a local file or from a server on the network. Downloading a package and then installing it locally &prompt.root; ftp 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 freebsd@vienna.verio.net. 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/irc 250 CWD command successful. ftp> get xchat-1.7.1.tgz local: xchat-1.7.1.tgz remote: xchat-1.7.1.tgz 150 Opening BINARY mode data connection for 'xchat-1.7.1.tgz' (471488 bytes). 100% |**************************************************| 460 KB 00:00 ETA 226 Transfer complete. 471488 bytes received in 5.37 seconds (85.70 KB/s) ftp> exit &prompt.root; pkg_add xchat-1.7.1.tgz &prompt.root; If you don't have a source of local packages (such as a FreeBSD CDROM set) then it will probably be easier to use the -r option to &man.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. &prompt.root; pkg_add -r xchat-1.7.1 This 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 homologous to that of the ports; they work with each other to form the entire package/port system. Deleting a Package &prompt.root pkg_delete xchat-1.7.1 &man.pkg.delete.1; is the utility for removing previously installed software package distributions. Managing packages &man.pkg.info.1; a utility that lists and describes the various packages installed. &prompt.root pkg_info cvsup-bin-16.1 A general network file distribution system optimized for CV docbook-1.2 Meta-port for the different versions of the DocBook DTD ... &man.pkg.version.1; a utility that summarizes the versions of all installed packages. It compares the package version to the current version found in the ports tree. &prompt.root pkg_version cvsup-bin = 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. Miscellaneous &man.pkg.add.1; &man.pkg.delete.1; &man.pkg.info.1; &man.pkg.version.1; &man.pkg.create.1; All package information is stored within the /var/db/pkg directory. The listing of contents and descriptions of each package can be found within files in this directory. Using the Ports Collection The following sections provide basic instructions on using the ports collection to install or remove programs from your system. 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 are needed for a program to compile and install cleanly on FreeBSD. 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. 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. To use whereis, simply type whereis <program you want to install> at the prompt, and if it is found on your system, you will be told where it is, like so: &prompt.root; whereis xchat xchat: /usr/ports/irc/xchat - This tells us that xchat (an irc client) can be found in the + This tells us that xchat (an irc client) + can be found in the /usr/ports/irc/xchat 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 key=program-name where program-name is the name of the program you - want to find. For example, if you were looking for xchat: + want to find. For example, if you were looking for + xchat: &prompt.root; cd /usr/ports &prompt.root; make search key=xchat Port: xchat-1.3.8 Path: /usr/ports/irc/xchat Info: An X11 IRC client using the GTK+ toolkit, and optionally, GNOME Maint: jim@FreeBSD.org Index: irc B-deps: XFree86-3.3.5 bzip2-0.9.5d gettext-0.10.35 giflib-4.1.0 glib-1.2.6 gmake-3.77 gtk-1.2.6 imlib-1.9.8 jpeg-6b png-1.0.3 tiff-3.5.1 R-deps: XFree86-3.3.5 gettext-0.10.35 giflib-4.1.0 glib-1.2.6 gtk-1.2.6 imlib-1.9.8 jpeg-6b png-1.0.3 tiff-3.5.1 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. 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. Installing ports from a CDROM As you may have guessed from the title, everything described in this section assumes you have a FreeBSD CDROM set. If you do not, you can order one from the FreeBSD Mall. Assuming that your FreeBSD CDROM is in the drive and is mounted on /cdrom (and the mount point must be /cdrom), you are ready to install the port. To begin, change directories to the directory where the port you want to install lives: &prompt.root; cd /usr/ports/irc/xchat - Once inside the xchat directory, you will see the port + Once inside the xchat 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: &prompt.root; make >> xchat-1.3.8.tar.bz2 doesn't seem to exist on this system. >> Attempting to fetch from file:/cdrom/ports/distfiles/. ===> Extracting for xchat-1.3.8 >> Checksum OK for xchat-1.3.8.tar.bz2. ===> xchat-1.3.8 depends on executable: bzip2 - found ===> xchat-1.3.8 depends on executable: gmake - found ===> xchat-1.3.8 depends on shared library: gtk12.2 - found ===> xchat-1.3.8 depends on shared library: Imlib.5 - found ===> xchat-1.3.8 depends on shared library: X11.6 - found ===> Patching for xchat-1.3.8 ===> Applying FreeBSD patches for xchat-1.3.8 ===> Configuring for xchat-1.3.8 ... [configure output snipped] ... ===> Building for xchat-1.3.8 ... [compilation snipped] ... &prompt.root; 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: &prompt.root; make install ===> Installing for xchat-1.3.8 ===> xchat-1.3.8 depends on shared library: gtk12.2 - found ===> xchat-1.3.8 depends on shared library: Imlib.5 - found ===> xchat-1.3.8 depends on shared library: X11.6 - found ... [install routines snipped] ... ===> Generating temporary packing list ===> Installing xchat docs in /usr/X11R6/share/doc/xchat ===> Registering installation for xchat-1.3.8 &prompt.root; Once you are returned to your prompt, you should be able to run the application you just installed. You can save an extra step by just running make install instead of make and make install as two separate steps. Please be aware that the licenses of a few ports do not allow for inclusion on the CDROM. This could be for various reasons, including things such as registration form needs to be filled out before downloading, if 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). 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 do 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 program's source code is downloaded from the Internet instead of pulled from the CDROM. The steps involved are identical: &prompt.root; make install >> xchat-1.3.8.tar.bz2 doesn't seem to exist on this system. >> Attempting to fetch from http://xchat.org/files/v1.3/. Receiving xchat-1.3.8.tar.bz2 (305543 bytes): 100% 305543 bytes transferred in 2.9 seconds (102.81 Kbytes/s) ===> Extracting for xchat-1.3.8 >> Checksum OK for xchat-1.3.8.tar.bz2. ===> xchat-1.3.8 depends on executable: bzip2 - found ===> xchat-1.3.8 depends on executable: gmake - found ===> xchat-1.3.8 depends on shared library: gtk12.2 - found ===> xchat-1.3.8 depends on shared library: Imlib.5 - found ===> xchat-1.3.8 depends on shared library: X11.6 - found ===> Patching for xchat-1.3.8 ===> Applying FreeBSD patches for xchat-1.3.8 ===> Configuring for xchat-1.3.8 ... [configure output snipped] ... ===> Building for xchat-1.3.8 ... [compilation snipped] ... ===> Installing for xchat-1.3.8 ===> xchat-1.3.8 depends on shared library: gtk12.2 - found ===> xchat-1.3.8 depends on shared library: Imlib.5 - found ===> xchat-1.3.8 depends on shared library: X11.6 - found ... [install routines snipped] ... ===> Generating temporary packing list ===> Installing xchat docs in /usr/X11R6/share/doc/xchat ===> Registering installation for xchat-1.3.8 &prompt.root; 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. 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. The next few paragraphs will cover just that. - Now we will remove our previous example (which was xchat for + Now we will remove our previous example (which was + xchat for those of you not paying attention). As with installing ports, the first thing you must do is change to the port directory, which if you remember was /usr/ports/irc/xchat. After you change - directories, you are ready to uninstall xchat. This is done with + directories, you are ready to uninstall xchat. + This is done with the make deinstall command (makes sense right?): &prompt.root; cd /usr/ports/irc/xchat &prompt.root; make deinstall ===> Deinstalling for xchat-1.3.8 &prompt.root; - That was easy enough. You have now managed to remove xchat + That was easy enough. You have now managed to remove + xchat from your system. If you would like to reinstall it, you can do so by running make reinstall from the /usr/ports/irc/xchat directory. 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. Some Questions and Answers 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. 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. 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: &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar 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. I did what you said for compiling ports from a CDROM and it worked great until I tried to install the kermit port. &prompt.root; 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 was 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. 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 looks for the tarball in /usr/ports/distfiles, but you will not be able to copy anything there because it is symlinked to the CDROM, which is read-only. You can tell it to look somewhere else by doing: &prompt.root; make DISTDIR=/where/you/put/it install 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, &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install will compile the port in /u/people/guests/wurzburger/ports and install everything under /usr/local. &prompt.root; 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, &prompt.root; 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 &man.imake.1; (a part of the X Windows System) don't 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 man page for your shell for instructions on doing so. 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: &prompt.root; cd /usr/ports &prompt.root; make fetch For all the tarballs for a single ports directory, do: &prompt.root; cd /usr/ports/directory &prompt.root; make fetch and for just one port—well, you have probably guessed already. 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: &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE= \ ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ fetch 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. 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 control-C every time. Doing make extract will stop it after it has fetched and extracted the source code. 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? Yep, 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! 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 option could result in buggy code unless you used the option as well. (Most of the ports do not use ). You should be able to specify the compiler options used by something like: &prompt.root; 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. 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: &prompt.user; cd /usr/ports &prompt.user; make search key=lisp 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. 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 do: &prompt.root; pkg_delete grizzle-6.5 Alternatively, you can do: &prompt.root; cd /usr/ports/somewhere/grizzle &prompt.root; make deinstall 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: &prompt.root; pkg_info -I 'grizzle*' Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. 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 best way to do this is: &prompt.root; cd /usr/ports &prompt.root; make clean which will go through all the ports subdirectories and delete everything except the skeletons for each port. 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. 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: &prompt.root; cd /usr/ports &prompt.root; 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. 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. 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: &prompt.root cd /usr/ports &prompt.root; make -DBATCH install This will install every port that does not require user input. Then, when you come back, do: &prompt.root; cd /usr/ports &prompt.root; make -DINTERACTIVE install to finish the job. 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: &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [Apply your patches] &prompt.root; cd ../.. &prompt.root; make package 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 your makefiles directory. (Readers with an aversion to intricate shell-scripts are advised not to follow this link...) Help! This port is broken! If you come across a port that doesn't work for you, there are a few things you can do, including: Fix it! The Porter's Handbook should help you do this. 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. 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 &man.pkg.add.1; program to install the package on your system. Advanced Topics The documentation that was here has been moved to its own Porter's Handbook for ease of reference. Please go there if you wish to create and submit your own ports. diff --git a/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml b/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml index 1786017cb4..ff601288fb 100644 --- a/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml @@ -1,2840 +1,2845 @@ PPP and SLIP Restructured, reorganized, and updated by &a.jim;, 1 March 2000. Synopsis PPP SLIP If you are connecting to the Internet via modem, or wish to provide dial-up connections to the Internet for others using FreeBSD, you have the option of using PPP or SLIP. PPPuser PPP PPPkernel PPP PPPover Ethernet This chapter covers three varieties of PPP; user, kernel, and PPPoE (PPP over Ethernet). It also covers setting up a SLIP client and server. The first variety of PPP that will be covered is User PPP. User PPP was introduced into FreeBSD in 2.0.5-RELEASE as an addition to the already existing kernel implementation of PPP. You may be wondering what the main difference is between User PPP and kernel PPP. The answer is simple; user PPP does not run as a daemon, and can run as and when desired. No PPP interface needs to be compiled into their kernel; it runs as a user process, and uses the tunnel device driver (tun) to get data into and out of the kernel. From here on out in this chapter, user ppp will simply be referred to as ppp unless a distinction needs to be made between it and any other PPP software such as pppd. Unless otherwise stated, all of the commands explained in this section should be executed as root. Using User PPP Originally contributed by &a.brian;, with input from &a.nik;, &a.dirkvangulik;, and &a.pjc;. User PPP Assumptions This document assumes you have the following: ISP PPP An account with an Internet Service Provider (ISP) which you connect to using PPP. Further, you have a modem or other device connected to your system and configured correctly, which allows you to connect to your ISP. The dial-up number(s) of your ISP. PAP CHAP Unix login name password Your login name and password. This can be either a regular Unix-style login and password pair, or a PAP or CHAP login and password pair. name server The IP address(es) of one or more name servers. Normally, you will be given two IP addresses by your ISP to use for this. If they have not given you at least one, then you can use the enable dns command in your ppp.conf file to tell ppp to set the name servers for you. The following information may be supplied by your ISP, but is not completely necessary: The IP address of your ISP's gateway. The gateway is the machine to which you will connect and will be set up as your default route. If you do not have this information, we can make one up and your ISP's PPP server will tell us the correct value when we connect. This IP number is referred to as HISADDR by ppp. The netmask you should use. If your ISP has not provided you with one, you can safely use 255.255.255.0. static IP address If your ISP provides you with a static IP address and hostname, you can enter it. Otherwise, we simply let the peer assign whatever IP address it sees fit. If you do not have any of the required information, contact your ISP and make sure they provide it to you. Preparing the Kernel As previously mentioned, ppp uses the tun device, and whichever kernel you are using must have tun configured. The tun device is preconfigured for the default GENERIC kernel that ships with FreeBSD. However, if you have installed a custom kernel, you must make sure your kernel is configured for ppp. kernelcompilation To check, go to your kernel compile directory (/sys/i386/conf or /sys/pc98/conf) and examine your configuration file. It should have the following line somewhere in it: pseudo-device tun 1 If this line is not present, you will need to add it to the configuration file and recompile your kernel. The stock GENERIC kernel has this included, so if you have not installed a custom kernel or do not have a /sys directory, you do not have to change anything. If you do need to recompile your kernel, please refer to the kernel configuration section for more information. You can check how many tunnel devices your current kernel has by typing the following: &prompt.root; ifconfig -a tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576 tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 In FreeBSD 4.0 and later releases, you will only see any tun devices which have already been used. This means you might not see any tun devices. If this is the case, do not worry; the device should be created dynamically when ppp attempts to use it. This case shows four tunnel devices, two of which are currently configured and being used. It should be noted that the RUNNING flag above indicates that the interface has been used at some point—it is not an error if your interface does not show up as RUNNING. If for some reason you have a kernel that does not have the tun device in it and cannot recompile the kernel, all is not lost. You should be able to dynamically load the code. Please refer to the appropriate &man.modload.8; and &man.lkm.4; man pages for further details. Check the <devicename>tun</devicename> device Under normal circumstances, most users will only require one tun device (/dev/tun0). If you have specified more than one on the pseudo-device line for tun in your kernel configuration file, then alter all references to tun0 below to reflect whichever device number you are using (e.g., tun2). The easiest way to make sure that the tun0 device is configured correctly, is to remake the device. This process is quite easy. To remake the device, do the following: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun0 If you need 16 tunnel devices in your kernel, you will need to create them. This can be done by executing the following commands: &prompt.root; cd /dev &prompt.root; ./MAKEDEV tun15 To confirm that the kernel is configured correctly, issue the follow command and compare the results: &prompt.root; ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mut 1500 The RUNNING flag may not yet be set, in which case you will see: &prompt.root; ifconfig tun0 tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 Remember from earlier that you might not see the device if it has not been used yet, as tun devices are created on demand in FreeBSD 4.0 and later releases. Name Resolution Configuration resolver hostname hosts The resolver is the part of the system that turns IP addresses into hostnames and vice versa. It can be configured to look for maps that describe IP to hostname mappings in one of two places. The first is a file called /etc/hosts. Read &man.hosts.5; for more information. The second is the Internet Domain Name Service (DNS), a distributed data base, the discussion of which is beyond the scope of this document. The resolver is a set of system calls that do the name mappings, but you have to tell them where to find their information. You do this by first editing the file /etc/host.conf. Do not call this file /etc/hosts.conf (note the extra s) as the results can be confusing. Edit <filename>/etc/host.conf</filename> This file should contain the following two lines (in this order): hosts bind These instruct the resolver to first look in the file /etc/hosts, and then to consult the DNS if the name was not found. Edit <filename>/etc/hosts</filename> This file should contain the IP addresses and names of machines on your network. At a bare minimum it should contain entries for the machine which will be running ppp. Assuming that your machine is called foo.bar.com with the IP address 10.0.0.1, /etc/hosts should contain: 127.0.0.1 localhost.bar.com localhost 127.0.0.1 localhost.bar.com. 10.0.0.1 foo.bar.com foo 10.0.0.1 foo.bar.com. The first two lines define the alias localhost as a synonym for the current machine. Regardless of your own IP address, the IP address for this line should always be 127.0.0.1. The second two lines map the name foo.bar.com (and the shorthand foo) to the IP address 10.0.0.1. If your provider allocates you a static IP address and name, use them in place of the 10.0.0.1 entry. Edit <filename>/etc/resolv.conf</filename> The /etc/resolv.conf file tells the resolver how to behave. If you are running your own DNS, you may leave this file empty. Normally, you will need to enter the following line(s): domain bar.com nameserver x.x.x.x nameserver y.y.y.y The x.x.x.x and y.y.y.y addresses are those given to you by your ISP. Add as many nameserver lines as your ISP provides. The domain line defaults to your hostname's domain, and is probably unnecessary. Refer to the &man.resolv.conf.5; manual page for details of other possible entries in this file. PPP ISP If you are running PPP version 2 or greater, the enable dns command will tell PPP to request that your ISP confirms the nameserver values. If your ISP supplies different addresses (or if there are no nameserver lines in /etc/resolv.conf), PPP will rewrite the file with the ISP-supplied values. <application>PPP</application> Configuration PPPconfiguration Both ppp and pppd (the kernel level implementation of PPP) use the configuration files located in the /usr/share/examples/ppp directory. The sample configuration files provided are a good reference, so do not delete them. Configuring ppp requires that you edit a number of files, depending on your requirements. What you put in them depends to some extent on whether your ISP allocates IP addresses statically (i.e., you get given one IP address, and always use that one) or dynamically (i.e., your IP address changes each time you connect to your ISP). PPP and Static IP Addresses PPPwith static IP addresses You will need to create a configuration file called /etc/ppp/ppp.conf. It should look similar to the example below. Lines that end in a : start in the first column, all other lines should be indented as shown using spaces or tabs. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT" 5 provider: 6 set phone "(123) 456 7890" 7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp" 8 set timeout 300 9 set ifaddr x.x.x.x y.y.y.y 255.255.255.0 0.0.0.0 10 add default HISADDR 11 enable dns Do not include the line numbers, they are just for reference in this discussion. Line 1: Identifies the default entry. Commands in this entry are executed automatically when ppp is run. Line 2: Identifies the device to which the modem is connected. COM1 is /dev/cuaa0 and COM2 is /dev/cuaa1. Line 3: Sets the speed you want to connect at. If 115200 does not work (it should with any reasonably new modem), try 38400 instead. Line 4: PPPuser PPP The dial string. User PPP uses an expect-send syntax similar to the &man.chat.8; program. Refer to the manual page for information on the features of this language. Line 5: Identifies an entry for a provider called provider. Line 6: Sets the phone number for this provider. Multiple phone numbers may be specified using the colon (:) or pipe character (|)as a separator. The difference between the two separators is described in &man.ppp.8;. To summarize, if you want to rotate through the numbers, use a colon. If you want to always attempt to dial the first number first and only use the other numbers if the first number fails, use the pipe character. Always quote the entire set of phone numbers as shown. Line 7: The login string is of the same chat-like syntax as the dial string. In this example, the string works for a service whose login session looks like this: J. Random Provider login: foo password: bar protocol: ppp You will need to alter this script to suit your own needs. When you write this script for the first time, you should enable chat logging to ensure that the conversation is going as expected. PAP CHAP If you are using PAP or CHAP, there will be no login at this point, so your login string can be left blank. See PAP and CHAP authentication for further details. Line 8: timeout Sets the default timeout (in seconds) for the connection. Here, the connection will be closed automatically after 300 seconds of inactivity. If you never want to timeout, set this value to zero. Line 9: ISP Sets the interface addresses. The string x.x.x.x should be replaced by the IP address that your provider has allocated to you. The string y.y.y.y should be replaced by the IP address that your ISP indicated for their gateway (the machine to which you connect). If your ISP hasn't given you a gateway address, use 10.0.0.2/0. If you need to use a guessed address, make sure that you create an entry in /etc/ppp/ppp.linkup as per the instructions for PPP and Dynamic IP addresses. If this line is omitted, ppp cannot run in or mode. Line 10: Adds a default route to your ISP's gateway. The special word HISADDR is replaced with the gateway address specified on line 9. It is important that this line appears after line 9, otherwise HISADDR will not yet be initialized. Line 11: nameserver This line tells PPP to ask your ISP to confirm that your nameserver addresses are correct. If your ISP supports this facility, PPP can then update /etc/resolv.conf with the correct nameserver entries. It is not necessary to add an entry to ppp.linkup when you have a static IP address as your routing table entries are already correct before you connect. You may however wish to create an entry to invoke programs after connection. This is explained later with the sendmail example. Example configuration files can be found in the /usr/share/examples/ppp directory. PPP and Dynamic IP Addresses PPPwith dynamic IP addresses IPCP If your service provider does not assign static IP addresses, ppp can be configured to negotiate the local and remote addresses. This is done by guessing an IP address and allowing ppp to set it up correctly using the IP Configuration Protocol (IPCP) after connecting. The ppp.conf configuration is the same as PPP and Static IP Addresses, with the following change: 9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 Again, do not include the line numbers, they are just for reference. Indentation of at least one space is required. Line 9: The number after the / character is the number of bits of the address that ppp will insist on. You may wish to use IP numbers more appropriate to your circumstances, but the above example will always work. The last argument (0.0.0.0) tells PPP to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use 0.0.0.0 as the first argument to set ifaddr as it prevents PPP from setting up an initial route in mode. If you are running version 1.x of PPP, you will also need to create an entry in /etc/ppp/ppp.linkup. ppp.linkup is used after a connection has been established. At this point, ppp will know what IP addresses should really be used. The following entry will delete the existing bogus routes, and create correct ones: 1 provider: 2 delete ALL 3 add 0 0 HISADDR Line 1: On establishing a connection, ppp will look for an entry in ppp.linkup according to the following rules: First, try to match the same label as we used in ppp.conf. If that fails, look for an entry for the IP address of our gateway. This entry is a four-octet IP style label. If we still have not found an entry, look for the MYADDR entry. Line 2: This line tells ppp to delete all of the existing routes for the acquired tun interface (except the direct route entry). Line 3: This line tells ppp to add a default route that points to HISADDR. HISADDR will be replaced with the IP number of the gateway as negotiated in the IPCP. - See the pmdemand entry in the files + See the pmdemand entry in the files /usr/share/examples/ppp/ppp.conf.sample and /usr/share/examples/ppp/ppp.linkup.sample for a detailed example. Version 2 of PPP introduces sticky routes. Any add or delete lines that contain MYADDR or HISADDR will be remembered, and any time the actual values of MYADDR or HISADDR change, the routes will be reapplied. This removes the necessity of repeating these lines in ppp.linkup. Receiving Incoming Calls PPPreceiving incoming calls When you configure ppp to receive incoming calls on a machine connected to a LAN, you must decide if you wish to forward packets to the LAN. If you do, you should allocate the peer an IP number from your LAN's subnet, and use the command enable proxy in your /etc/ppp/ppp.conf file. You should also confirm that the /etc/rc.conf file contains the following: gateway="YES" Which getty? Configuring FreeBSD for Dial-up Services provides a good description on enabling - dial-up services using getty. + dial-up services using &man.getty.8;. An alternative to getty is mgetty, a smarter version of getty designed with dial-up lines in mind. The advantages of using mgetty is that it actively talks to modems, meaning if port is turned off in /etc/ttys then your modem will not answer the phone. Later versions of mgetty (from 0.99beta onwards) also support the automatic detection of PPP streams, allowing your clients script-less access to your server. Refer to Mgetty and AutoPPP for more information on mgetty. <application>PPP</application> Permissions The ppp command must normally be run as user id 0. If however, you wish to allow ppp to run in server mode as a normal user by executing ppp as described below, that user must be given permission to run ppp by adding them to the network group in /etc/group. You will also need to give them access to one or more sections of the configuration file using the allow command: allow users fred mary If this command is used in the default section, it gives the specified users access to everything. PPP Shells for Dynamic-IP Users PPP shells Create a file called /etc/ppp/ppp-shell containing the following: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT This script should be executable. Now make a symbolic link called ppp-dialup to this script using the following commands: &prompt.root; ln -s ppp-shell /etc/ppp/ppp-dialup You should use this script as the shell for all of your dialup users. This is an example from /etc/password for a dialup PPP user with username pchilds (remember don't directly edit the password file, use vipw). pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup Create a /home/ppp directory that is world readable containing the following 0 byte files: -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts which prevents /etc/motd from being displayed. PPP shells for Static-IP Users PPP shells Create the ppp-shell file as above and for each account with statically assigned IPs create a symbolic link to ppp-shell. For example, if you have three dialup customers fred, sam, and mary, that you route class C networks for, you would type the following: &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam &prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary Each of these users dialup accounts should have their shell set to the symbolic link created above (i.e., mary's shell should be /etc/ppp/ppp-mary). Setting up ppp.conf for dynamic-IP users The /etc/ppp/ppp.conf file should contain something along the lines of: default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy The indenting is important. The default: section is loaded for each session. For each dialup line enabled in /etc/ttys create an entry similar to the one for ttyd0: above. Each line should get a unique IP address from your pool of IP addresses for dynamic users. Setting up <filename>ppp.conf</filename> for static-IP users Along with the contents of the sample /usr/share/examples/ppp/ppp.conf above you should add a section for each of the statically assigned dialup users. We will continue with our fred, sam, and mary example. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255 The file /etc/ppp/ppp.linkup should also contain routing information for each static IP user if required. The line below would add a route for the 203.14.101.0 class C via the client's ppp link. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR More on <command>mgetty</command>, AutoPPP, and MS extensions <command>mgetty</command> and AutoPPP mgetty AutoPPP LCP Configuring and compiling mgetty with the AUTO_PPP option enabled allows mgetty to detect the LCP phase of PPP connections and automatically spawn off a ppp shell. However, since the default login/password sequence does not occur it is necessary to authenticate users using either PAP or CHAP. This section assumes the user has successfully configured, compiled, and installed a version of mgetty with the AUTO_PPP option (v0.99beta or later). Make sure your /usr/local/etc/mgetty+sendfax/login.config file has the following in it: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup This will tell mgetty to run the ppp-pap-dialup script for detected PPP connections. Create a file called /etc/ppp/ppp-pap-dialup containing the following (the file should be executable): #!/bin/sh exec /usr/sbin/ppp -direct pap$IDENT For each dialup line enabled in /etc/ttys, create a corresponding entry in /etc/ppp/ppp.conf. This will happily co-exist with the definitions we created above. pap: enable pap set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40 enable proxy Each user logging in with this method will need to have a username/password in /etc/ppp/ppp.secret file, or alternatively add the following option to authenticate users via PAP from /etc/password file. enable passwdauth If you wish to assign some users a static IP number, you can specify the number as the third argument in /etc/ppp/ppp.secret. See /usr/share/examples/ppp/ppp.secret.sample for examples. MS extensions DNS NetBIOS PPPMicrosoft extensions It is possible to configure PPP to supply DNS and NetBIOS nameserver addresses on demand. To enable these extensions with PPP version 1.x, the following lines might be added to the relevant section of /etc/ppp/ppp.conf. enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 And for PPP version 2 and above: accept dns set dns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5 This will tell the clients the primary and secondary name server addresses, and a netbios nameserver host. In version 2 and above, if the set dns line is omitted, PPP will use the values found in /etc/resolv.conf. PAP and CHAP authentication PAP CHAP Some ISPs set their system up so that the authentication part of your connection is done using either of the PAP or CHAP authentication mechanisms. If this is the case, your ISP will not give a login: prompt when you connect, but will start talking PPP immediately. PAP is less secure than CHAP, but security is not normally an issue here as passwords, although being sent as plain text with PAP, are being transmitted down a serial line only. There's not much room for crackers to eavesdrop. Referring back to the PPP and Static IP addresses or PPP and Dynamic IP addresses sections, the following alterations must be made: 7 set login … 12 set authname MyUserName 13 set authkey MyPassword As always, do not include the line numbers, they are just for reference in this discussion. Indentation of at least one space is required. Line 7: Your ISP will not normally require that you log into the server if you're using PAP or CHAP. You must therefore disable your set login string. Line 12: This line specifies your PAP/CHAP user name. You will need to insert the correct value for MyUserName. Line 13: password This line specifies your PAP/CHAP password. You will need to insert the correct value for MyPassword. You may want to add an additional line, such as: 15 accept PAP or 15 accept CHAP to make it obvious that this is the intention, but PAP and CHAP are both accepted by default. Changing your <command>ppp</command> configuration on the fly It is possible to talk to the ppp program while it is running in the background, but only if a suitable diagnostic port has been set up. To do this, add the following line to your configuration: set server /var/run/ppp-tun%d DiagnosticPassword 0177 This will tell PPP to listen to the specified unix-domain socket, asking clients for the specified password before allowing access. The %d in the name is replaced with the tun device number that is in use. Once a socket has been set up, the &man.pppctl.8; program may be used in scripts that wish to manipulate the running program. Final system configuration PPPconfiguration You now have ppp configured, but there are a few more things to do before it is ready to work. They all involve editing the /etc/rc.conf file. Working from the top down in this file, make sure the hostname= line is set, e.g.: hostname="foo.bar.com" If your ISP has supplied you with a static IP address and name, it's probably best that you use this name as your host name. Look for the network_interfaces variable. If you want to configure your system to dial your ISP on demand, make sure the tun0 device is added to the list, otherwise remove it. network_interfaces="lo0 tun0" ifconfig_tun0= The ifconfig_tun0 variable should be empty, and a file called /etc/start_if.tun0 should be created. This file should contain the line: ppp -auto mysystem This script is executed at network configuration time, starting your ppp daemon in automatic mode. If you have a LAN for which this machine is a gateway, you may also wish to use the switch. Refer to the manual page for further details. Set the router program to NO with following line in your /etc/rc.conf: router_enable="NO" routed It is important that the routed daemon is not started (it is started by default), as it routed tends to delete the default routing table entries created by ppp. It is probably worth your while ensuring that the sendmail_flags line does not include the option, otherwise sendmail will attempt to do a network lookup every now and then, possibly causing your machine to dial out. You may try: sendmail_flags="-bd" sendmail The downside of this is that you must force sendmail to re-examine the mail queue whenever the ppp link is up by typing: &prompt.root; /usr/sbin/sendmail -q You may wish to use the !bg command in ppp.linkup to do this automatically: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m SMTP If you don't like this, it is possible to set up a dfilter to block SMTP traffic. Refer to the sample files for further details. Now the only thing left to do is reboot the machine. All that is left is to reboot the machine. After rebooting, you can now either type: &prompt.root; ppp and then dial provider to start the PPP session, or, if you want ppp to establish sessions automatically when there is outbound traffic (and you have not created the start_if.tun0 script), type: &prompt.root; ppp -auto provider Summary To recap, the following steps are necessary when setting up ppp for the first time: Client side: Ensure that the tun device is built into your kernel. Ensure that the tunX device file is available in the /dev directory. Create an entry in /etc/ppp/ppp.conf. The pmdemand example should suffice for most ISPs. If you have a dynamic IP address, create an entry in /etc/ppp/ppp.linkup. Update your /etc/rc.conf file. Create a start_if.tun0 script if you require demand dialing. Server side: Ensure that the tun device is built into your kernel. Ensure that the tunX device file is available in the /dev directory. Create an entry in /etc/passwd (using the &man.vipw.8; program). Create a profile in this users home directory that runs ppp -direct direct-server or similar. Create an entry in /etc/ppp/ppp.conf. The direct-server example should suffice. Create an entry in /etc/ppp/ppp.linkup. Update your /etc/rc.conf file. Using Kernel PPP Parts originally contributed by &a.gena; and &a.rhuff;. Setting up Kernel PPP PPPkernel PPP Before you start setting up PPP on your machine make sure that pppd is located in /usr/sbin and the directory /etc/ppp exists. pppd can work in two modes: As a client, i.e., you want to connect your machine to the outside world via a PPP serial connection or modem line. PPPserver as a server, i.e. your machine is located on the network and used to connect other computers using PPP. In both cases you will need to set up an options file (/etc/ppp/options or ~/.ppprc if you have more than one user on your machine that uses PPP). You also will need some modem/serial software (preferably kermit) so you can dial and establish a connection with the remote host. Using <command>pppd</command> as a client PPPclient Cisco The following /etc/ppp/options might be used to connect to a CISCO terminal server PPP line. crtscts # enable hardware flow control modem # modem control line noipdefault # remote PPP server must supply your IP address. # if the remote host doesn't send your IP during IPCP # negotiation , remove this option passive # wait for LCP packets domain ppp.foo.com # put your domain name here :<remote_ip> # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be your # default router To connect: kermit modem Dial to the remote host using kermit (or some other modem program), and enter your user name and password (or whatever is needed to enable PPP on the remote host). Exit kermit (without hanging up the line). Enter the following: &prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty01 19200 Be sure to use the appropriate speed and device name. Now your computer is connected with PPP. If the connection fails, you can add the option to the /etc/ppp/options file and check messages on the console to track the problem. Following /etc/ppp/pppup script will make all 3 stages automatically: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.dial pppd /dev/tty01 19200 kermit /etc/ppp/kermit.dial is a kermit script that dials and makes all necessary authorization on the remote host (an example of such a script is attached to the end of this document). Use the following /etc/ppp/pppdown script to disconnect the PPP line: #!/bin/sh pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill -TERM ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi /sbin/ifconfig ppp0 down /sbin/ifconfig ppp0 delete kermit -y /etc/ppp/kermit.hup /etc/ppp/ppptest Check to see if PPP is still running by executing /usr/etc/ppp/ppptest, which should look like this: #!/bin/sh pid=`ps ax| grep pppd |grep -v grep|awk '{print $1;}'` if [ X${pid} != "X" ] ; then echo 'pppd running: PID=' ${pid-NONE} else echo 'No pppd running.' fi set -x netstat -n -I ppp0 ifconfig ppp0 To hang up the modem, execute /etc/ppp/kermit.hup, which should contain: set line /dev/tty01 ; put your modem device here set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 echo \13 exit Here is an alternate method using chat instead of kermit. - The following two files are sufficient to accomplish a pppd - connection. + The following two files are sufficient to accomplish a + pppd connection. /etc/ppp/options: /dev/cuaa1 115200 crtscts # enable hardware flow control modem # modem control line connect "/usr/bin/chat -f /etc/ppp/login.chat.script" noipdefault # remote PPP serve must supply your IP address. # if the remote host doesn't send your IP during # IPCP negotiation, remove this option passive # wait for LCP packets domain <your.domain> # put your domain name here : # put the IP of remote PPP host here # it will be used to route packets via PPP link # if you didn't specified the noipdefault option # change this line to <local_ip>:<remote_ip> defaultroute # put this if you want that PPP server will be # your default router /etc/ppp/login.chat.script: The following should go on a single line. ABORT BUSY ABORT 'NO CARRIER' "" AT OK ATDT<phone.number> CONNECT "" TIMEOUT 10 ogin:-\\r-ogin: <login-id> TIMEOUT 5 sword: <password> Once these are installed and modified correctly, all you need to do is run pppd, like so: &prompt.root; pppd This sample is based primarily on information provided by: Trev Roydhouse <Trev.Roydhouse@f401.n711.z3.fidonet.org> and used with permission. Using <command>pppd</command> as a server /etc/ppp/options should contain something similar to the following: crtscts # Hardware flow control netmask 255.255.255.0 # netmask ( not required ) 192.114.208.20:192.114.208.165 # ip's of local and remote hosts # local ip must be different from one # you assigned to the ethernet ( or other ) # interface on your machine. # remote IP is ip address that will be # assigned to the remote machine domain ppp.foo.com # your domain passive # wait for LCP modem # modem line The following /etc/ppp/pppserv script will enable tell pppd to behave as a server: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi # reset ppp interface ifconfig ppp0 down ifconfig ppp0 delete # enable autoanswer mode kermit -y /etc/ppp/kermit.ans # run ppp pppd /dev/tty01 19200 Use this /etc/ppp/pppservdown script to stop the server: #!/bin/sh ps ax |grep pppd |grep -v grep pid=`ps ax |grep pppd |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing pppd, PID=' ${pid} kill ${pid} fi ps ax |grep kermit |grep -v grep pid=`ps ax |grep kermit |grep -v grep|awk '{print $1;}'` if [ "X${pid}" != "X" ] ; then echo 'killing kermit, PID=' ${pid} kill -9 ${pid} fi ifconfig ppp0 down ifconfig ppp0 delete kermit -y /etc/ppp/kermit.noans The following kermit script (/etc/ppp/kermit.ans) will enable/disable autoanswer mode on your modem. It should look like this: set line /dev/tty01 set speed 19200 set file type binary set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none pau 1 out +++ inp 5 OK out ATH0\13 inp 5 OK echo \13 out ATS0=1\13 ; change this to out ATS0=0\13 if you want to disable ; autoanswer mod inp 5 OK echo \13 exit A script named /etc/ppp/kermit.dial is used for dialing and authenticating on the remote host. You will need to customize it for your needs. Put your login and password in this script; you will also need to change the input statement depending on responses from your modem and remote host. ; ; put the com line attached to the modem here: ; set line /dev/tty01 ; ; put the modem speed here: ; set speed 19200 set file type binary ; full 8 bit file xfer set file names literal set win 8 set rec pack 1024 set send pack 1024 set block 3 set term bytesize 8 set command bytesize 8 set flow none set modem hayes set dial hangup off set carrier auto ; Then SET CARRIER if necessary, set dial display on ; Then SET DIAL if necessary, set input echo on set input timeout proceed set input case ignore def \%x 0 ; login prompt counter goto slhup :slcmd ; put the modem in command mode echo Put the modem in command mode. clear ; Clear unread characters from input buffer pause 1 output +++ ; hayes escape sequence input 1 OK\13\10 ; wait for OK if success goto slhup output \13 pause 1 output at\13 input 1 OK\13\10 if fail goto slcmd ; if modem doesn't answer OK, try again :slhup ; hang up the phone clear ; Clear unread characters from input buffer pause 1 echo Hanging up the phone. output ath0\13 ; hayes command for on hook input 2 OK\13\10 if fail goto slcmd ; if no OK answer, put modem in command mode :sldial ; dial the number pause 1 echo Dialing. output atdt9,550311\13\10 ; put phone number here assign \%x 0 ; zero the time counter :look clear ; Clear unread characters from input buffer increment \%x ; Count the seconds input 1 {CONNECT } if success goto sllogin reinput 1 {NO CARRIER\13\10} if success goto sldial reinput 1 {NO DIALTONE\13\10} if success goto slnodial reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 60 goto look else goto slhup :sllogin ; login assign \%x 0 ; zero the time counter pause 1 echo Looking for login prompt. :slloop increment \%x ; Count the seconds clear ; Clear unread characters from input buffer output \13 ; ; put your expected login prompt here: ; input 1 {Username: } if success goto sluid reinput 1 {\255} if success goto slhup reinput 1 {\127} if success goto slhup if < \%x 10 goto slloop ; try 10 times to get a login prompt else goto slhup ; hang up and start again if 10 failures :sluid ; ; put your userid here: ; output ppp-login\13 input 1 {Password: } ; ; put your password here: ; output ppp-password\13 input 1 {Entering SLIP mode.} echo quit :slnodial echo \7No dialtone. Check the telephone line!\7 exit 1 ; local variables: ; mode: csh ; comment-start: "; " ; comment-start-skip: "; " ; end: Using <application>PPP</application> over Ethernet (PPPoE) PPPover Ethernet PPPoE (see PPP, over Ethernet) Contributed by &a.jim; (from node.to) 10 Jan 2000. The following describes how to set up PPP over Ethernet, a.k.a, PPPoE. Prerequisites There are a few requirements that your system will need to meet in order for PPPoE to function properly. They are: Kernel source for FreeBSD 3.4 or later ppp from FreeBSD 3.4 or later Kernel Configuration kernelconfiguration You will need to set the following options in your kernel configuration file and then compile a new kernel. - options NETGRAPH + Optionally, you can add - options NETGRAPH_PPPOE + - options NETGRAPH_SOCKET + although if this functionality is not available at runtime, ppp will load the relevant modules on demand Setting up <filename>ppp.conf</filename> Here is an example of a working ppp.conf: default: # or name_of_service_provider set device PPPoE:xl1 # replace xl1 with your ethernet device set mru 1492 set mtu 1492 set authname YOURLOGINNAME set authkey YOURPASSWORD set log Phase tun command # you can add more detailed logging if you wish set dial set login set ifaddr 10.0.0.1/0 10.0.0.2/0 add default HISADDR nat enable yes # if you want to enable nat for your local net papchap: set authname YOURLOGINNAME set authkey YOURPASSWORD Care should be taken when running PPPoE with the option. Running <application>PPP</application> As root, you can run: &prompt.root; ppp -ddial name_of_service_provider Starting <application>PPP</application> at Boot Add the following to your /etc/rc.conf file: ppp_enable="YES" ppp_mode="ddial" ppp_nat="YES" ppp_profile="default" # or your provider PPPoE with a 3Com HomeConnect ADSL Modem Dual Link Contributed by &a.lioux;, 07 Apr 2001. In short, it does not work. It should, but unfortunately, that is not the case. For whatever reason, this modem does not follow RFC 2516 (A Method for transmitting PPP over Ethernet (PPPoE), written by L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, and R. Wheeler). Since it does not follow the specification, FreeBSD's PPPoE implementation will not talk to it. It is very likely that it will - not work under other unixes for that same reason. Complain to 3Com if you think it should comply with the PPPoE specification. ADSL If you absolutely want to use your ADSL connection with FreeBSD and are stuck with this modem, you can either: DSL Try replacing the modem with a different brand or model if your DSL provider permits you to do so. If you are not sure which brand(s) will work, the &a.questions; is a good place to ask. Try to get it working. Keep in mind that there is no guarantee it will work, your mileage may vary. If you want to try to make it work, you can do the following, but please keep in mind that you do this at your own risk! Just because it worked for me does not mean it will work for you. There are three steps to the process. They are: Make sure you already have ppp.conf set up. See the beginning of this chapter for more details on doing so. Since the modem does not speak the correct protocol, we need to learn how to speak its variant of the protocol. This information was obtained from a DSLreports forum message. The modem speaks 0x3c12 for DISCOVERY, and 0x3c13 for PAYLOAD identifiers instead of 0x8863 and 0x8864 respectively, as mandated by the PPPoE specification. Code RFC's Code Dual Link Modem's Code PAYLOAD 0x8863 0x3c12 PAYLOAD 0x8864 0x3c13 So, now what? You need to recompile the NETGRAPH_PPPOE code with the modem's codes. For this, you should have installed the full kernel sources. Find the /usr/src/sys/netgraph/ng_pppoe.h file. Be careful while editing this file. You have to modify both the little and the big endian entries. For big endian, find the line with 0x8863 in it, and replace the number with 0x3c12. Do the same with 0x8864, replacing it with 0x3c13. For little endian, find the line with 0x6388in it, and replace the number with 0x123c. Do the same with 0x6488, replacing it with 0x133c. Here is a diff of how the new file should look: &prompt.user; diff -u ng_pppoe.h.orig ng_pppoe.h --- ng_pppoe.h.orig Thu Apr 12 13:42:46 2001 +++ ng_pppoe.h Thu Apr 12 13:44:47 2001 @@ -148,8 +148,8 @@ #define PTT_SYS_ERR (0x0202) #define PTT_GEN_ERR (0x0203) -#define ETHERTYPE_PPPOE_DISC 0x8863 /* pppoe discovery packets */ -#define ETHERTYPE_PPPOE_SESS 0x8864 /* pppoe session packets */ +#define ETHERTYPE_PPPOE_DISC 0x3c12 /* pppoe discovery packets */ +#define ETHERTYPE_PPPOE_SESS 0x3c13 /* pppoe session packets */ #else #define PTT_EOL (0x0000) #define PTT_SRV_NAME (0x0101) @@ -162,8 +162,8 @@ #define PTT_SYS_ERR (0x0202) #define PTT_GEN_ERR (0x0302) -#define ETHERTYPE_PPPOE_DISC 0x6388 /* pppoe discovery packets */ -#define ETHERTYPE_PPPOE_SESS 0x6488 /* pppoe session packets */ +#define ETHERTYPE_PPPOE_DISC 0x123c /* pppoe discovery packets */ +#define ETHERTYPE_PPPOE_SESS 0x133c /* pppoe session packets */ #endif struct pppoe_tag { Then do the following as root: &prompt.root; cd /usr/src/sys/modules/netgraph/pppoe &prompt.root; make clean depend all install &prompt.root; make clean Now you can speak the modem's variant of the PPPoE specification. The third step is to figure out the name of the profile your ISP assigned to the modem. The information for this step was obtained from the Roaring Penguin PPPoE program which can be found in the ports collection. If you still are not able to find it, ask your ISP's tech support. If they do not know it either, and you are feeling bold (this may de-program your modem and render it useless, so think twice about doing it). Install the program shipped with the modem by your provider. Then, access the System menu from the program. The name of your profile should be listed there. It is usually ISP. The profile name will be used in the PPPoE configuration inside ppp.conf as the provider parameter. See the &man.ppp.8; manual page for more information. The PPPoE line in your ppp.conf should look like this: set device PPPoE:xl1:ISP Do not forget to change xl1 to the proper device for your Ethernet card. Do not forget to change ISP to the profile you have just found above. For additional information, you can try: Cheaper Broadband with FreeBSD on DSL by Renaud Waldura in Daemon News. Another PPPoE tutorial by Sympatico Users Group. Using SLIP SLIP Originally contributed by &a.asami; and &a.ghelmer;, with input from &a.wilko; and &a.piero;. Setting up a SLIP Client SLIPclient The following is one way to set up a FreeBSD machine for SLIP on a static host network. For dynamic hostname assignments (i.e., your address changes each time you dial up), you probably need to do something much fancier. First, determine which serial port your modem is connected to. I have a symbolic link to /dev/modem from /dev/cuaa1, and only use the modem name in my configuration files. It can become quite cumbersome when you need to fix a bunch of files in /etc and .kermrc's all over the system! /dev/cuaa0 is COM1, cuaa1 is COM2, etc. Make sure you have the following in your kernel configuration file: pseudo-device sl 1 It is included in the GENERIC kernel, so this should not be a problem unless you have deleted it. Things you have to do only once Add your home machine, the gateway and nameservers to your /etc/hosts file. Mine looks like this: 127.0.0.1 localhost loghost 136.152.64.181 silvia.HIP.Berkeley.EDU silvia.HIP silvia 136.152.64.1 inr-3.Berkeley.EDU inr-3 slip-gateway 128.32.136.9 ns1.Berkeley.edu ns1 128.32.136.12 ns2.Berkeley.edu ns2 Make sure you have before in your /etc/host.conf. Otherwise, funny things may happen. Edit the /etc/rc.conf file. Set your hostname by editing the line that says: hostname=myname.my.domain You should give it your full Internet hostname. Add sl0 to the list of network interfaces by changing the line that says: network_interfaces="lo0" to: network_interfaces=lo0 sl0 Set the startup flags of sl0 by adding a line: ifconfig_sl0="inet ${hostname} slip-gateway netmask 0xffffff00 up" default router Designate the default router by changing the line: defaultrouter=NO to: defaultrouter=slip-gateway Make a file /etc/resolv.conf which contains: domain HIP.Berkeley.EDU nameserver 128.32.136.9 nameserver 128.32.136.12 name server domain name As you can see, these set up the nameserver hosts. Of course, the actual domain names and addresses depend on your environment. - Set the password for root and toor (and any other + Set the password for root and + toor (and any other accounts that do not have a password). Use passwd or &man.vipw.8;, do not edit the /etc/passwd or /etc/master.passwd files! Reboot your machine and make sure it comes up with the correct hostname. Making a SLIP connection SLIPconnecting with Dial up, type slip at the prompt, enter your machine name and password. The things you need to enter depends on your environment. If you use kermit, you can try a script like this: # kermit setup set modem hayes set line /dev/modem set speed 115200 set parity none set flow rts/cts set terminal bytesize 8 set file type binary # The next macro will dial up and login define slip dial 643-9600, input 10 =>, if failure stop, - output slip\x0d, input 10 Username:, if failure stop, - output silvia\x0d, input 10 Password:, if failure stop, - output ***\x0d, echo \x0aCONNECTED\x0a Of course, you have to change the hostname and password to fit yours. After doing so, you can just type slip from the kermit prompt to get connected. Leaving your password in plain text anywhere in the filesystem is generally a BAD idea. Do it at your own risk. Leave the kermit there (you can suspend it by z) and as root, type: &prompt.root; slattach -h -c -s 115200 /dev/modem If you are able to ping hosts on the other side of the router, you are connected! If it does not work, you might want to try instead of - as an argument to slattach. + as an argument to + slattach. How to shutdown the connection Do the following: &prompt.root; kill -INT `cat /var/run/slattach.modem.pid` - to kill slattach. Keep in mind you must be + to kill slattach. Keep in mind you must be root to do the above. Then go back to kermit (fg if you suspended it) and exit from it (q). - The slattach man page says you have to use ifconfig - sl0 down to mark the interface down, but this does not + The slattach man page says you have + to use ifconfig sl0 down + to mark the interface down, but this does not seem to make any difference for me. (ifconfig sl0 reports the same thing.) Some times, your modem might refuse to drop the carrier (mine often does). In that case, simply start kermit and quit it again. It usually goes out on the second try. Troubleshooting If it does not work, feel free to ask me. The things that people tripped over so far: Not using or in - slattach (I have no idea why this can be fatal, but adding + slattach (I have no idea why this + can be fatal, but adding this flag solved the problem for at least one person). Using instead of (might be hard to see the difference on some fonts). Try ifconfig sl0 to see your interface status. For example, you might get: &prompt.root; ifconfig sl0 sl0: flags=10<POINTOPOINT> inet 136.152.64.181 --> 136.152.64.1 netmask ffffff00 Also, netstat -r will give the routing table, in case you get the no route to host messages from ping. Mine looks like: &prompt.root; netstat -r Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (root node) Route Tree for Protocol Family inet: (root node) => default inr-3.Berkeley.EDU UG 8 224515 sl0 - - localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438 inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - - silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438 (root node) This is after transferring a bunch of files, your numbers should be smaller). Setting up a SLIP Server SLIPserver This document provides suggestions for setting up SLIP Server services on a FreeBSD system, which typically means configuring your system to automatically startup connections upon login for remote SLIP clients. The author has written this document based on his experience; however, as your system and needs may be different, this document may not answer all of your questions, and the author cannot be responsible if you damage your system or lose data due to attempting to follow the suggestions here. Prerequisites TCP/IP This document is very technical in nature, so background knowledge is required. It is assumed that you are familiar with the TCP/IP network protocol, and in particular, network and node addressing, network address masks, subnetting, routing, and routing protocols, such as RIP. Configuring SLIP services on a dial-up server requires a knowledge of these concepts, and if you are not familiar with them, please read a copy of either Craig Hunt's TCP/IP Network Administration published by O'Reilly & Associates, Inc. (ISBN Number 0-937175-82-X), or Douglas Comer's books on the TCP/IP protocol. modem It is further assumed that you have already setup your modem(s) and configured the appropriate system files to allow logins through your modems. If you have not prepared your system for this yet, please see the tutorial for configuring dialup services; if you have a World-Wide Web browser available, browse the list of tutorials at http://www.FreeBSD.org/. You may also want to check the manual pages for &man.sio.4; for information on the serial port device driver and &man.ttys.5;, &man.gettytab.5;, &man.getty.8;, & &man.init.8; for information relevant to configuring the system to accept logins on modems, and perhaps &man.stty.1; for information on setting serial port parameters (such as clocal for directly-connected serial interfaces). Quick Overview In its typical configuration, using FreeBSD as a SLIP server works as follows: a SLIP user dials up your FreeBSD SLIP Server system and logs in with a special SLIP login ID that uses /usr/sbin/sliplogin as the special user's shell. The sliplogin program browses the file /etc/sliphome/slip.hosts to find a matching line for the special user, and if it finds a match, connects the serial line to an available SLIP interface and then runs the shell script /etc/sliphome/slip.login to configure the SLIP interface. An Example of a SLIP Server Login For example, if a SLIP user ID were Shelmerg, Shelmerg's entry in /etc/master.passwd would look something like this (except it would be all on one line): Shelmerg:password:1964:89::0:0:Guy Helmer - SLIP:/usr/users/Shelmerg:/usr/sbin/sliplogin When Shelmerg logs in, sliplogin will search /etc/sliphome/slip.hosts for a line that had a matching user ID; for example, there may be a line in /etc/sliphome/slip.hosts that reads: Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp sliplogin will find that matching line, hook the serial line into the next available SLIP interface, and then execute /etc/sliphome/slip.login like this: /etc/sliphome/slip.login 0 19200 Shelmerg dc-slip sl-helmer 0xfffffc00 autocomp If all goes well, /etc/sliphome/slip.login will issue an ifconfig for the SLIP interface to which sliplogin attached itself (slip interface 0,in the above example, which was the first parameter in the list given to slip.login) to set the local IP address (dc-slip), remote IP address (sl-helmer), network mask for the SLIP interface (0xfffffc00), and any additional flags (autocomp). If something goes wrong, sliplogin usually logs good informational messages via the daemon syslog facility, which usually goes into /var/log/messages (see the manual pages for &man.syslogd.8; and &man.syslog.conf.5; and perhaps check /etc/syslog.conf to see to which files syslogd is logging). OK, enough of the examples — let us dive into setting up the system. Kernel Configuration kernelconfiguration FreeBSD's default kernels usually come with two SLIP interfaces defined (sl0 and sl1); you can use netstat -i to see whether these interfaces are defined in your kernel. Sample output from netstat -i: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ed0 1500 <Link>0.0.c0.2c.5f.4a 291311 0 174209 0 133 ed0 1500 138.247.224 ivory 291311 0 174209 0 133 lo0 65535 <Link> 79 0 79 0 0 lo0 65535 loop localhost 79 0 79 0 0 sl0* 296 <Link> 0 0 0 0 0 sl1* 296 <Link> 0 0 0 0 0 The sl0 and sl1 interfaces shown in netstat -i's output indicate that there are two SLIP interfaces built into the kernel. (The asterisks after the sl0 and sl1 indicate that the interfaces are down.) However, FreeBSD's default kernels do not come configured to forward packets (ie, your FreeBSD machine will not act as a router) due to Internet RFC requirements for Internet hosts (see RFCs 1009 [Requirements for Internet Gateways], 1122 [Requirements for Internet Hosts — Communication Layers], and perhaps 1127 [A Perspective on the Host Requirements RFCs]), so if you want your FreeBSD SLIP Server to act as a router, you will have to edit the /etc/rc.conf file and change the setting of the gateway_enable variable to . You will then need to reboot for the new settings to take effect. You will notice that near the end of the default kernel configuration file (/sys/i386/conf/GENERIC) is a line that reads: pseudo-device sl 2 SLIP This is the line that defines the number of SLIP devices available in the kernel; the number at the end of the line is the maximum number of SLIP connections that may be operating simultaneously. Please refer to Configuring the FreeBSD Kernel for help in reconfiguring your kernel. Sliplogin Configuration As mentioned earlier, there are three files in the /etc/sliphome directory that are part of the configuration for /usr/sbin/sliplogin (see &man.sliplogin.8; for the actual manual page for sliplogin): slip.hosts, which defines the SLIP users & their associated IP addresses; slip.login, which usually just configures the SLIP interface; and (optionally) slip.logout, which undoes slip.login's effects when the serial connection is terminated. <filename>slip.hosts</filename> Configuration /etc/sliphome/slip.hosts contains lines which have at least four items, separated by whitespace: SLIP user's login ID Local address (local to the SLIP server) of the SLIP link Remote address of the SLIP link Network mask The local and remote addresses may be host names (resolved to IP addresses by /etc/hosts or by the domain name service, depending on your specifications in /etc/host.conf), and the network mask may be a name that can be resolved by a lookup into /etc/networks. On a sample system, /etc/sliphome/slip.hosts looks like this: # # login local-addr remote-addr mask opt1 opt2 # (normal,compress,noicmp) # Shelmerg dc-slip sl-helmerg 0xfffffc00 autocomp At the end of the line is one or more of the options. — no header compression — compress headers — compress headers if the remote end allows it — disable ICMP packets (so any ping packets will be dropped instead of using up your bandwidth) Note that sliplogin under early releases of FreeBSD 2 ignored the options that FreeBSD 1.x recognized, so the options , , , and had no effect until support was added in FreeBSD 2.2 (unless your slip.login script included code to make use of the flags). SLIP TCP/IP Your choice of local and remote addresses for your SLIP links depends on whether you are going to dedicate a TCP/IP subnet or if you are going to use proxy ARP on your SLIP server (it is not true proxy ARP, but that is the terminology used in this document to describe it). If you are not sure which method to select or how to assign IP addresses, please refer to the TCP/IP books referenced in the slips-prereqs section and/or consult your IP network manager. gated If you are going to use a separate subnet for your SLIP clients, you will need to allocate the subnet number out of your assigned IP network number and assign each of your SLIP client's IP numbers out of that subnet. Then, you will probably either need to configure a static route to the SLIP subnet via your SLIP server on your nearest IP router, or install gated on your FreeBSD SLIP server and configure it to talk the appropriate routing protocols to your other routers to inform them about your SLIP server's route to the SLIP subnet. Ethernet Otherwise, if you will use the proxy ARP method, you will need to assign your SLIP client's IP addresses out of your SLIP server's Ethernet subnet, and you will also need to adjust your /etc/sliphome/slip.login and /etc/sliphome/slip.logout scripts to use &man.arp.8; to manage the proxy-ARP entries in the SLIP server's ARP table. <filename>slip.login</filename> Configuration The typical /etc/sliphome/slip.login file looks like this: #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 This slip.login file merely ifconfig's the appropriate SLIP interface with the local and remote addresses and network mask of the SLIP interface. If you have decided to use the proxy ARP method (instead of using a separate subnet for your SLIP clients), your /etc/sliphome/slip.login file will need to look something like this: #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 inet $4 $5 netmask $6 # Answer ARP requests for the SLIP client with our Ethernet addr /usr/sbin/arp -s $5 00:11:22:33:44:55 pub The additional line in this slip.login, arp -s $5 00:11:22:33:44:55 pub, creates an ARP entry in the SLIP server's ARP table. This ARP entry causes the SLIP server to respond with the SLIP server's Ethernet MAC address whenever a another IP node on the Ethernet asks to speak to the SLIP client's IP address. EthernetMAC address When using the example above, be sure to replace the Ethernet MAC address (00:11:22:33:44:55) with the MAC address of your system's Ethernet card, or your proxy ARP will definitely not work! You can discover your SLIP server's Ethernet MAC address by looking at the results of running netstat -i; the second line of the output should look something like: ed0 1500 <Link>0.2.c1.28.5f.4a 191923 0 129457 0 116 This indicates that this particular system's Ethernet MAC address is 00:02:c1:28:5f:4a — the periods in the Ethernet MAC address given by netstat -i must be changed to colons and leading zeros should be added to each single-digit hexadecimal number to convert the address into the form that &man.arp.8; desires; see the manual page on &man.arp.8; for complete information on usage. When you create /etc/sliphome/slip.login and /etc/sliphome/slip.logout, the execute bit (ie, chmod 755 /etc/sliphome/slip.login /etc/sliphome/slip.logout) must be set, or sliplogin will be unable to execute it. <filename>slip.logout</filename> Configuration /etc/sliphome/slip.logout is not strictly needed (unless you are implementing proxy ARP), but if you decide to create it, this is an example of a basic slip.logout script: #!/bin/sh - # # slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down If you are using proxy ARP, you will want to have /etc/sliphome/slip.logout remove the ARP entry for the SLIP client: #!/bin/sh - # # @(#)slip.logout # # logout file for a slip line. sliplogin invokes this with # the parameters: # 1 2 3 4 5 6 7-n # slipunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig sl$1 down # Quit answering ARP requests for the SLIP client /usr/sbin/arp -d $5 The arp -d $5 removes the ARP entry that the proxy ARP slip.login added when the SLIP client logged in. It bears repeating: make sure /etc/sliphome/slip.logout has the execute bit set for after you create it (ie, chmod 755 /etc/sliphome/slip.logout). Routing Considerations SLIProuting If you are not using the proxy ARP method for routing packets between your SLIP clients and the rest of your network (and perhaps the Internet), you will probably either have to add static routes to your closest default router(s) to route your SLIP client subnet via your SLIP server, or you will probably need to install and configure gated on your FreeBSD SLIP server so that it will tell your routers via appropriate routing protocols about your SLIP subnet. Static Routes static routes Adding static routes to your nearest default routers can be troublesome (or impossible, if you do not have authority to do so...). If you have a multiple-router network in your organization, some routers, such as Cisco and Proteon, may not only need to be configured with the static route to the SLIP subnet, but also need to be told which static routes to tell other routers about, so some expertise and troubleshooting/tweaking may be necessary to get static-route-based routing to work. Running <command>gated</command> gated An alternative to the headaches of static routes is to install gated on your FreeBSD SLIP server and configure it to use the appropriate routing protocols (RIP/OSPF/BGP/EGP) to tell other routers about your SLIP subnet. You can use gated from the ports collection or retrieve and build it yourself from the GateD anonymous FTP site; the current version as of this writing is gated-R3_5Alpha_8.tar.Z, which includes support for FreeBSD out-of-the-box. Complete information and documentation on gated is available on the Web starting at the Merit GateD Consortium. Compile and install it, and then write a /etc/gated.conf file to configure your gated; here is a sample, similar to what the author used on a FreeBSD SLIP server: # # gated configuration file for dc.dsu.edu; for gated version 3.5alpha5 # Only broadcast RIP information for xxx.xxx.yy out the ed Ethernet interface # # # tracing options # traceoptions "/var/tmp/gated.output" replace size 100k files 2 general ; rip yes { interface sl noripout noripin ; interface ed ripin ripout version 1 ; traceoptions route ; } ; # # Turn on a bunch of tracing info for the interface to the kernel: kernel { traceoptions remnants request routes info interface ; } ; # # Propagate the route to xxx.xxx.yy out the Ethernet interface via RIP # export proto rip interface ed { proto direct { xxx.xxx.yy mask 255.255.252.0 metric 1; # SLIP connections } ; } ; # # Accept routes from RIP via ed Ethernet interfaces import proto rip interface ed { all ; } ; RIP The above sample gated.conf file broadcasts routing information regarding the SLIP subnet xxx.xxx.yy via RIP onto the Ethernet; if you are using a different Ethernet driver than the ed driver, you will need to change the references to the ed interface appropriately. This sample file also sets up tracing to /var/tmp/gated.output for debugging gated's activity; you can certainly turn off the tracing options if gated works OK for you. You will need to change the xxx.xxx.yy's into the network address of your own SLIP subnet (be sure to change the net mask in the proto direct clause as well). When you get gated built and installed and create a configuration file for it, you will need to run gated in place of routed on your FreeBSD system; change the routed/gated startup parameters in /etc/netstart as appropriate for your system. Please see the manual page for gated for information on gated's command-line parameters. diff --git a/en_US.ISO8859-1/books/handbook/sound/chapter.sgml b/en_US.ISO8859-1/books/handbook/sound/chapter.sgml index 06d6817232..8cfc1df408 100644 --- a/en_US.ISO8859-1/books/handbook/sound/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/sound/chapter.sgml @@ -1,332 +1,333 @@ Sound Contributed by Moses Moore jm-moses@home.com, 20 November 2000. Synopsis This chapter of the handbook deals with setting up sound on a FreeBSD system. Locating the Correct Device PCI ISA sound cards Before you begin, you should know the model of the card you have, the chip it uses, and whether it is a PCI or ISA card. FreeBSD supports a wide variety of both PCI and ISA cards. If you do not see your card in the following list, check the &man.pcm.4; manual page. This is not a complete list; however, it does list some of the most common cards. Crystal 4237, 4236, 4232, 4231 Yamaha OPL-SAx OPTi931 Ensoniq AudioPCI 1370/1371 ESS Solo-1/1E NeoMagic 256AV/ZX Sound Blaster Pro, 16, 32, AWE64, AWE128, Live Creative ViBRA16 Advanced Asound 100, 110, and Logic ALS120 ES 1868, 1869, 1879, 1888 Gravis UltraSound Aureal Vortex 1 or 2 kernelconfiguration The driver you use in your kernel depends on the kind of card you have. The sections below provide more information and what you will need to add to your kernel configuration. Creative, Advance, and ESS Sound Cards If you have one of the above cards, you will need to add device pcm to your kernel. If you have a PnP ISA card, you will also need to add device sbc to your kernel. For a non-PnP ISA card, add device pcm and device sbc0 at isa? port0x220 irq 5 drq 1 flags 0x15 to your kernel. Those are the default settings. You may need to change the IRQ, etc. See the &man.sbc.4; man page for more information. The Sound Blaster Live is not supported under FreeBSD 4.0 without a patch, which this document will not cover. It is recommended that you update to the latest -STABLE before trying to use this card. Gravis UltraSound Cards For a PnP ISA card, you will need to add device pcm and device gusc to your kernel. If you have a non-PnP ISA card, you will need to add device pcm and device gus0 at isa? port 0x220 irq 5 drq 1 flags 0x13 to your kernel. You may need to change the IRQ, etc. See the &man.gusc.4; man page for more information. Crystal Sound Cards For Crystal cards, you will need both device pcm and device csa in your kernel. Generic Support For PnP ISA or PCI cards, you will need to add device pcm to your kernel configuration. If you have a non-PnP ISA sound card that does not have a bridge driver, you will need to add device pcm0 at isa? irq 10 drq 1 flags 0x0 to your kernel configuration. You may need to change the IRQ, etc., to match your hardware configuration. Recompiling the Kernel After adding the driver(s) you need to your kernel configuration, you will need to recompile your kernel. Please see of the handbook for more information. Creating and Testing the Device Nodes device nodes After you reboot, log in and run cat /dev/sndstat. You should see output similar to the following: FreeBSD Audio Driver (newpcm) Sep 21 2000 18:29:53 Installed devices: pcm0: <Aureal Vortex 8830> at memory 0xfeb40000 irq 5 (4p/1r +channels duplex) If you see an error message, something went wrong earlier. If that happens, go through your kernel configuration file again and make sure you chose the correct device. If it reported no errors and returned pcm0, su to root and do the following: &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd0 If it reported no errors and returned pcm1, su to root and do the following: &prompt.root; cd /dev &prompt.root; sh MAKEDEV snd1 Please note that either of the above commands will not create a /dev/snd device! Instead it creates a group of device nodes including: Device Description /dev/audio SPARC-compatible audio device /dev/dsp Digitized voice device /dev/dspW Like /dev/dsp, but 16 bits per sample /dev/midi Raw midi access device /dev/mixer Control port mixer device /dev/music Level 2 sequencer interface /dev/sequencer Sequencer device /dev/pss Programmable device interface If all goes well, you should now have a functioning sound card. If you do not, see the next section. Common Problems device node I get an unsupported subdevice XX error! One or more of the device nodes wasn't created correctly. Repeat the steps above. I/O port I get a sb_dspwr(XX) timed out error! The I/O port is not set correctly. IRQ I get a bad irq XX error! The IRQ is set incorrectly. Make sure that the set IRQ and the sound IRQ are the same. - I get a "xxx: gus pcm not attached, out of memory" + I get a xxx: gus pcm not attached, out of + memory error. What causes that? If this happens, it is because there is not enough available memory to use the device. diff --git a/en_US.ISO8859-1/books/handbook/users/chapter.sgml b/en_US.ISO8859-1/books/handbook/users/chapter.sgml index 9a983f9b6e..5d6814100c 100644 --- a/en_US.ISO8859-1/books/handbook/users/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/users/chapter.sgml @@ -1,845 +1,850 @@ Neils Blakey-Milner Contributed Users and Basic Account Management Synopsis 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. 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. The Superuser Account accounts superuser (root) 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 haven't already. This applies equally whether you're 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. System Accounts accounts system 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. accounts daemon accounts operator 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. accounts nobody nobody is the generic unprivileged system user. However, it's 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. User Accounts accounts user 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. Modifying Accounts accounts modifying pw is a powerful and flexible tool to modify all aspects of user accounts. For most tasks however, adduser and rmuser are recommended to add and remove accounts respectively. chpass allows both the system administrator and normal users to adjust passwords, shells, and personal information. If you are only interested in changing a password then the passwd command is usually quicker. adduser accounts adding adduser /usr/share/skel skeleton directory 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. - The makes adduser default to + The makes adduser + default to quiet. We use later when we want to change defaults. Next, we configure adduser defaults, and create our first user account, since using root for normal usage is evil and nasty. Configuring adduser &prompt.root; 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 [sh]: zsh Your default shell is: tcsh -> /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: 1007 Gid: 1007 (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! &prompt.root; In summary, we changed the default shell to zsh (an additional shell found in packages), and turned off the sending of a welcome mail to added users. We then saved the configuration, and then created an account for jru, and we made sure jru is in wheel group (which we'll see is important later). The password you type in isn't echoed, nor are asterisks displayed. Make sure you don't mistype the password twice :-) Just use adduser without arguments from now on, and you won't have to go through changing the defaults. If the program asks you to change the defaults, exit the program, and try the option. <application>rmuser</application> rmuser accounts removing You can use rmuser to completely remove a user from the system. rmuser performs the following steps: Removes the user's &man.crontab.1; entry (if any). Removes any &man.at.1; jobs belonging to the user. Kills all processes owned by the user. Removes the user from the system's local password file. Removes the user's home directory (if it is owned by the user). Removes the incoming mail files belonging to the user from /var/mail. Removes all files owned by the user from temporary file storage areas such as /tmp. Finally, removes the username from all groups to which it belongs in /etc/group. 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 &man.adduser.8;. rmuser can't 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're doing. rmuser interactive account removal &prompt.root; rmuser jru Matching password entry: jru:*:1000:1000::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. &prompt.root; <application>pw</application> pw pw is a command line utility to create, remove, modify, and display users and groups, and functions as an editor of the system user and group files. This section describes its use for users; the Groups section below describes its use for groups. It is designed to be useful both as a directly executed command and for use from shell scripts. For detailed information, please see &man.pw.8;. <application>chpass</application> 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. + 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. 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 subsection of this information, and only for themselves. 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: chfn and chsh are - just links to chpass, as are ypchpass, + just links to chpass, as + are ypchpass, ypchfn, and ypchsh. NIS support is automatic, so specifying the yp before the command is not necessary. passwd passwd accounts changing password passwd is the usual way to change your own password as a user, or another user's password as the superuser. 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. Changing your password &prompt.user; passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done Changing another user's password as the superuser &prompt.root; passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done yppasswd is just a link to passwd. NIS support is automatic, so specifying the yp before the command is not necessary. Limiting Users limiting users users limiting (see 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 resources limits. quotas limiting users quotas disk quotas 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 . 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. /etc/login.conf 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 &man.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 &man.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 &man.login.conf.5;). coredumpsize coredumpsize limiting users 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 cputime limiting users cputime This is the maximum amount of CPU time a user's process may consume. Offending processes will be killed by the kernel. This is a limit on CPU time consumed, not percentage of the CPU as displayed in some fields by &man.top.1; and &man.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 filesize limiting users 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 maxproc limiting users 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 + 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., &man.make.1;, &man.cc.1;, and other intermediate preprocessors). memorylocked memorylocked limiting users memorylocked This is the maximum amount a memory a process may have requested to be locked into main memory (e.g., see &man.mlock.2;). Some system-critical programs, such as &man.amd.8;, do this so that their getting swapped out does not contribute to a system's thrashing in time of trouble. memoryuse memoryuse limiting users 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 openfiles limiting users 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. + kern.maxfiles sysctl. sbsize sbsize limiting users 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 stacksize limiting users 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 + 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: &man.cap.mkdb.1;, &man.getrlimit.2;, &man.login.conf.5;. 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. Groups groups /etc/groups accounts 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 fields 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 don't make any syntax errors!). For a more complete description of the syntax, see the &man.group.5; manual page. If you don't want to edit /etc/group manually, you can use the &man.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: Adding a group using &man.pw.8; &prompt.root; pw groupadd teamtwo &prompt.root; 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. Adding somebody to a group using &man.pw.8; &prompt.root; pw groupmod teamtwo jru &prompt.root; pw groupshow teamtwo teamtwo:*:1100:jru The argument to the 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 &man.pw.8;, but will show up when the information is queried via &man.id.1; or similar tool. In other words, &man.pw.8; only manipulates the /etc/group file; it will never attempt to read additionally data from /etc/passwd. Using &man.id.1; to determine group membership &prompt.user; 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 &man.pw.8;, see its manual page, and for more information on the format of /etc/group, consult the &man.group.5; manual page.