Synchronous Serial TransmissionSynchronous serial transmission requires that the sender
and receiver share a clock with one another, or that the
sender provide a strobe or other timing signal so that the
receiver knows when to read the next bit of the data. In
most forms of serial Synchronous communication, if there is no
data available at a given instant to transmit, a fill
character must be sent instead so that data is always being
transmitted. Synchronous communication is usually more
efficient because only data bits are transmitted between
sender and receiver, and synchronous communication can be more
more costly if extra wiring and circuits are required to share
a clock signal between the sender and receiver.A form of Synchronous transmission is used with printers
and fixed disk devices in that the data is sent on one set of
wires while a clock or strobe is sent on a different wire.
Printers and fixed disk devices are not normally serial
devices because most fixed disk interface standards send an
entire word of data for each clock or strobe signal by using a
separate wire for each bit of the word. In the PC industry,
these are known as Parallel devices.The standard serial communications hardware in the PC does
not support Synchronous operations. This mode is described
here for comparison purposes only.Asynchronous Serial TransmissionAsynchronous transmission allows data to be transmitted
without the sender having to send a clock signal to the
receiver. Instead, the sender and receiver must agree on
timing parameters in advance and special bits are added to
each word which are used to synchronize the sending and
receiving units.When a word is given to the UART for Asynchronous
transmissions, a bit called the "Start Bit" is added to the
beginning of each word that is to be transmitted. The Start
Bit is used to alert the receiver that a word of data is about
to be sent, and to force the clock in the receiver into
synchronization with the clock in the transmitter. These two
clocks must be accurate enough to not have the frequency
drift by more than 10% during the transmission of the
remaining bits in the word. (This requirement was set in the
days of mechanical teleprinters and is easily met by modern
electronic equipment.)After the Start Bit, the individual bits of the word of
data are sent, with the Least Significant Bit (LSB) being sent
first. Each bit in the transmission is transmitted for
exactly the same amount of time as all of the other bits, and
the receiver looks at the wire at approximately halfway
through the period assigned to each bit to determine if the
bit is a 1 or a 0. For example, if it takes two seconds
to send each bit, the receiver will examine the signal to
determine if it is a 1 or a 0 after one second has passed,
then it will wait two seconds and then examine the value of
the next bit, and so on.The sender does not know when the receiver has looked at
the value of the bit. The sender only knows when the clock
says to begin transmitting the next bit of the word.When the entire data word has been sent, the transmitter
may add a Parity Bit that the transmitter generates. The
Parity Bit may be used by the receiver to perform simple error
checking. Then at least one Stop Bit is sent by the
transmitter. When the receiver has received all of the bits in the data
word, it may check for the Parity Bits (both sender and
receiver must agree on whether a Parity Bit is to be used),
and then the receiver looks for a Stop Bit. If the Stop Bit
does not appear when it is supposed to, the UART considers the
entire word to be garbled and will report a Framing Error to
the host processor when the data word is read. The usual
cause of a Framing Error is that the sender and receiver
clocks were not running at the same speed, or that the signal
was interrupted.Regardless of whether the data was received correctly or
not, the UART automatically discards the Start, Parity and
Stop bits. If the sender and receiver are configured
identically, these bits are not passed to the host.If another word is ready for transmission, the Start Bit
for the new word can be sent as soon as the Stop Bit for the
previous word has been sent.Because asynchronous data is self synchronizing, if
there is no data to transmit, the transmission line can be
idle.Other UART FunctionsIn addition to the basic job of converting data from
parallel to serial for transmission and from serial to
parallel on reception, a UART will usually provide additional
circuits for signals that can be used to indicate the state of
the transmission media, and to regulate the flow of data in
the event that the remote device is not prepared to accept
more data. For example, when the device connected to the
UART is a modem, the modem may report the presence of a
carrier on the phone line while the computer may be able to
instruct the modem to reset itself or to not take calls by
asserting or deasserting one more more of these extra signals.
The function of each of these additional signals is defined in
the EIA RS232-C standard.The RS232-C and V.24 StandardsIn most computer systems, the UART is connected to
circuitry that generates signals that comply with the EIA
RS232-C specification. There is also a CCITT standard named
V.24 that mirrors the specifications included in
RS232-C.RS232-C Bit Assignments (Marks and Spaces)In RS232-C, a value of 1 is called a Mark and a
value of 0 is called a Space. When a communication line
is idle, the line is said to be "Marking", or transmitting
continuous 1 values.The Start bit always has a value of 0 (a Space). The
Stop Bit always has a value of 1 (a Mark). This means
that there will always be a Mark (1) to Space (0) transition
on the line at the start of every word, even when multiple
word are transmitted back to back. This guarantees that
sender and receiver can resynchronize their clocks
regardless of the content of the data bits that are being
transmitted.The idle time between Stop and Start bits does not have
to be an exact multiple (including zero) of the bit rate of
the communication link, but most UARTs are designed this way
for simplicity.In RS232-C, the "Marking" signal (a 1) is represented
by a voltage between -2 VDC and -12 VDC, and a "Spacing"
signal (a 0) is represented by a voltage between 0 and +12
VDC. The transmitter is supposed to send +12 VDC or -12
VDC, and the receiver is supposed to allow for some voltage
loss in long cables. Some transmitters in low power devices
(like portable computers) sometimes use only +5 VDC and -5
VDC, but these values are still acceptable to a RS232-C
receiver, provided that the cable lengths are short.RS232-C Break SignalRS232-C also specifies a signal called a Break, which
is caused by sending continuous Spacing values (no Start or
Stop bits). When there is no electricity present on the
data circuit, the line is considered to be sending Break.
The Break signal must be of a duration longer than the
time it takes to send a complete byte plus Start, Stop and
Parity bits. Most UARTs can distinguish between a Framing
Error and a Break, but if the UART cannot do this, the
Framing Error detection can be used to identify
Breaks.In the days of teleprinters, when numerous printers
around the country were wired in series (such as news
services), any unit could cause a Break by temporarily
opening the entire circuit so that no current flowed. This
was used to allow a location with urgent news to interrupt
some other location that was currently sending
information.In modern systems there are two types of Break signals.
If the Break is longer than 1.6 seconds, it is considered a
"Modem Break", and some modems can be programmed to
terminate the conversation and go on-hook or enter the
modems' command mode when the modem detects this signal. If
the Break is smaller than 1.6 seconds, it signifies a Data
Break and it is up to the remote computer to respond to this
signal. Sometimes this form of Break is used as an
Attention or Interrupt signal and sometimes is accepted as a
substitute for the ASCII CONTROL-C character.Marks and Spaces are also equivalent to Holes and No
Holes in paper tape systems.Breaks cannot be generated from paper tape or from any
other byte value, since bytes are always sent with Start
and Stop bit. The UART is usually capable of generating
the continuous Spacing signal in response to a special
command from the host processor.RS232-C DTE and DCE DevicesThe RS232-C specification defines two types of
equipment: the Data Terminal Equipment (DTE) and the Data
Carrier Equipment (DCE). Usually, the DTE device is the
terminal (or computer), and the DCE is a modem. Across the
phone line at the other end of a conversation, the receiving
modem is also a DCE device and the computer that is
connected to that modem is a DTE device. The DCE device
receives signals on the pins that the DTE device transmits
on, and vice versa.When two devices that are both DTE or both DCE must be
connected together without a modem or a similar media
translater between them, a NULL modem must be used. The
NULL modem electrically re-arranges the cabling so that the
transmitter output is connected to the receiver input on the
other device, and vice versa. Similar translations are
performed on all of the control signals so that each device
will see what it thinks are DCE (or DTE) signals from the
other device.The number of signals generated by the DTE and DCE
devices are not symmetrical. The DTE device generates fewer
signals for the DCE device than the DTE device receives from
the DCE.RS232-C Pin AssignmentsThe EIA RS232-C specification (and the ITU equivalent,
V.24) calls for a twenty-five pin connector (usually a DB25)
and defines the purpose of most of the pins in that
connector. In the IBM Personal Computer and similar systems, a
subset of RS232-C signals are provided via nine pin
connectors (DB9). The signals that are not included on the
PC connector deal mainly with synchronous operation, and
this transmission mode is not supported by the UART that IBM
selected for use in the IBM PC.Depending on the computer manufacturer, a DB25, a DB9,
or both types of connector may be used for RS232-C
communications. (The IBM PC also uses a DB25 connector for
the parallel printer interface which causes some
confusion.)Below is a table of the RS232-C signal assignments in
the DB25 and DB9 connectors.DB25 DB9 EIA CCITT Common Signal
Description RS232-C IBM PC Circuit Circuit Name Source
Pin Pin Symbol Symbol 1 - AA 101
PG/FG --- Frame/Protective Ground 2 3
BA 103 TD DTE Transmit Data 3 2 BB
104 RD DCE Receive Data 4 7 CA 105
RTS DTE Request to Send 5 8 CB 106
CTS DCE Clear to Send 6 6 CC 107 DSR
DCE Data Set Ready 7 5 AV 102 SG/GND
--- Signal Ground 8 1 CF 109 DCD/CD DCE
Data Carrier Detect 9 - - - -
- Reserved for Test 10 - - - -
- Reserved for Test 11 - - - -
- Unassigned 12 - CI 122 SRLSD DCE
Sec. Recv. Line Signal Detector 13 - SCB 121
SCTS DCE Secondary Clear To Send 14 -
SBA 118 STD DTE Secondary Transmit Data 15
- DB 114 TSET DCE Trans. Sig. Element
Timing 16 - SBB 119 SRD DCE
Secondary Received Data 17 - DD 115 RSET
DCE Receiver Signal Element Timing 18 - -
141 LOOP DTE Local Loopback 19 - SCA
120 SRS DTE Secondary Request to Send 20 4
CD 108.2 DTR DTE Data Terminal Ready 21 -
- - RDL DTE Remote Digital Loopback 22
9 CE 125 RI DCE Ring Indicator 23
- CH 111 DSRS DTE Data Signal Rate
Selector 24 - DA 113 TSET DTE Trans.
Sig. Element Timing 25 - - 142 -
DCE Test ModeBits, Baud and SymbolsBaud is a measurement of transmission speed in
asynchronous communication. Because of advances in modem
communication technology, this term is frequently misused when
describing the data rates in newer devices.Traditionally, a Baud Rate represents the number of bits
that are actually being sent over the media, not the amount of
data that is actually moved from one DTE device to the other.
The Baud count includes the overhead bits Start, Stop and
Parity that are generated by the sending UART and removed by
the receiving UART. This means that seven-bit words of data
actually take 10 bits to be completely transmitted. Therefore,
a modem capable of moving 300 bits per second from one place
to another can normally only move 30 7-bit words if Parity is
used and one Start and Stop bit are present. If 8-bit data words are used and Parity bits are also
used, the data rate falls to 27.27 words per second, because
it now takes 11 bits to send the eight-bit words, and the
modem still only sends 300 bits per second.The formula for converting bytes per second into a baud
rate and vice versa was simple until error-correcting modems
came along. These modems receive the serial stream of bits
from the UART in the host computer (even when internal modems
are used the data is still frequently serialized) and converts
the bits back into bytes. These bytes are then combined into
packets and sent over the phone line using a Synchronous
transmission method. This means that the Stop, Start, and
Parity bits added by the UART in the DTE (the computer) were
removed by the modem before transmission by the sending modem.
When these bytes are received by the remote modem, the remote
modem adds Start, Stop and Parity bits to the words, converts
them to a serial format and then sends them to the receiving
UART in the remote computer, who then strips the Start, Stop
and Parity bits.The reason all these extra conversions are done is so that
the two modems can perform error correction, which means that
the receiving modem is able to ask the sending modem to resend
a block of data that was not received with the correct
checksum. This checking is handled by the modems, and the DTE
devices are usually unaware that the process is
occurring.By striping the Start, Stop and Parity bits, the
additional bits of data that the two modems must share between
themselves to perform error-correction are mostly concealed
from the effective transmission rate seen by the sending and
receiving DTE equipment. For example, if a modem sends ten
7-bit words to another modem without including the Start, Stop
and Parity bits, the sending modem will be able to add 30 bits
of its own information that the receiving modem can use to do
error-correction without impacting the transmission speed of
the real data.The use of the term Baud is further confused by modems
that perform compression. A single 8-bit word passed over the
telephone line might represent a dozen words that were
transmitted to the sending modem. The receiving modem will
expand the data back to its original content and pass that
data to the receiving DTE.Modern modems also include buffers that allow the rate
that bits move across the phone line (DCE to DCE) to be a
different speed than the speed that the bits move between the
DTE and DCE on both ends of the conversation. Normally the
speed between the DTE and DCE is higher than the DCE to DCE
speed because of the use of compression by the modems.Because the number of bits needed to describe a byte
varied during the trip between the two machines plus the
differing bits-per-seconds speeds that are used present on
the DTE-DCE and DCE-DCE links, the usage of the term Baud to
describe the overall communication speed causes problems and
can misrepresent the true transmission speed. So Bits Per
Second (bps) is the correct term to use to describe the
transmission rate seen at the DCE to DCE interface and Baud or
Bits Per Second are acceptable terms to use when a connection
is made between two systems with a wired connection, or if a
modem is in use that is not performing error-correction or
compression.Modern high speed modems (2400, 9600, 14,400, and
19,200bps) in reality still operate at or below 2400 baud, or
more accurately, 2400 Symbols per second. High speed modem
are able to encode more bits of data into each Symbol using a
technique called Constellation Stuffing, which is why the
effective bits per second rate of the modem is higher, but the
modem continues to operate within the limited audio bandwidth
that the telephone system provides. Modems operating at 28,800
and higher speeds have variable Symbol rates, but the
technique is the same.The IBM Personal Computer UARTStarting with the original IBM Personal Computer, IBM
selected the National Semiconductor INS8250 UART for use in
the IBM PC Parallel/Serial Adapter. Subsequent generations of
compatible computers from IBM and other vendors continued to
use the INS8250 or improved versions of the National
Semiconductor UART family.National Semiconductor UART Family TreeThere have been several versions and subsequent
generations of the INS8250 UART. Each major version is
described below. INS8250 -> INS8250B \ \ \->
INS8250A -> INS82C50A \ \ \-> NS16450 ->
NS16C450 \ \ \-> NS16550 -> NS16550A ->
PC16550DINS8250This part was used in the original IBM PC and
IBM PC/XT. The original name for this part was the
INS8250 ACE (Asynchronous Communications Element)
and it is made from NMOS technology.The 8250 uses eight I/O ports and has a one-byte
send and a one-byte receive buffer. This original
UART has several race conditions and other flaws.
The original IBM BIOS includes code to work around
these flaws, but this made the BIOS dependent on the
flaws being present, so subsequent parts like the
8250A, 16450 or 16550 could not be used in the
original IBM PC or IBM PC/XT.INS8250-BThis is the slower speed of the INS8250 made
from NMOS technology. It contains the same problems
as the original INS8250.INS8250AAn improved version of the INS8250 using XMOS
technology with various functional flaws corrected.
The INS8250A was used initially in PC clone
computers by vendors who used clean BIOS designs.
Because of the corrections in the chip, this part
could not be used with a BIOS compatible with the
INS8250 or INS8250B.INS82C50AThis is a CMOS version (low power consumption)
of the INS8250A and has similar functional
characteristics.NS16450Same as NS8250A with improvements so it can be
used with faster CPU bus designs. IBM used this
part in the IBM AT and updated the IBM BIOS to no
longer rely on the bugs in the INS8250.NS16C450This is a CMOS version (low power consumption)
of the NS16450.NS16550Same as NS16450 with a 16-byte send and receive
buffer but the buffer design was flawed and could
not be reliably be used.NS16550ASame as NS16550 with the buffer flaws corrected.
The 16550A and its successors have become the most
popular UART design in the PC industry, mainly due
it its ability to reliably handle higher data rates
on operating systems with sluggish interrupt
response times.NS16C552This component consists of two NS16C550A CMOS
UARTs in a single package. PC16550DSame as NS16550A with subtle flaws corrected.
This is revision D of the 16550 family and is the
latest design available from National Semiconductor.
The NS16550AF and the PC16550D are the same
thingNational reorganized their part numbering system a few
years ago, and the NS16550AFN no longer exists by that name.
(If you have a NS16550AFN, look at the date code on the
part, which is a four digit number that usually starts with
a nine. The first two digits of the number are the year,
and the last two digits are the week in that year when the
part was packaged. If you have a NS16550AFN, it is probably
a few years old.) The new numbers are like PC16550DV, with minor
differences in the suffix letters depending on the package
material and its shape. (A description of the numbering
system can be found below.) It is important to understand that in some stores, you
may pay $15(US) for a NS16550AFN made in 1990 and in the
next bin are the new PC16550DN parts with minor fixes that
National has made since the AFN part was in production, the
PC16550DN was probably made in the past six months and it
costs half (as low as $5(US) in volume) as much as the
NS16550AFN because they are readily available.As the supply of NS16550AFN chips continues to shrink,
the price will probably continue to increase until more
people discover and accept that the PC16550DN really has the
same function as the old part number.National Semiconductor Part Numbering SystemThe older NSnnnnnrqp part numbers
are now of the format
PCnnnnnrgp.The r is the revision field. The
current revision of the 16550 from National Semiconductor is
D. The p is the package-type field.
The types are: "F" QFP (quad
flat pack) L lead type "N" DIP (dual inline package)
through hole straight lead type "V" LPCC (lead plastic
chip carrier) J lead typeThe "g" is the product grade field.
If an I precedes the package-type letter, it indicates an
industrial grade part, which has higher specs than a
standard part but not as high as Military Specification
(Milspec) component. This is an optional field.So what we used to call a NS16550AFN (DIP Package) is
now called a PC16550DN or PC16550DIN.Other Vendors and Similar UARTsOver the years, the 8250, 8250A, 16450 and 16550 have been
licensed or copied by other chip vendors. In the case of the
8250, 8250A and 16450, the exact circuit (the megacell) was
licensed to many vendors, including Western Digital and Intel.
Other vendors reverse-engineered the part or produced
emulations that had similar behavior. In internal modems, the modem designer will frequently
emulate the 8250A/16450 with the modem microprocessor, and the
emulated UART will frequently have a hidden buffer consisting
of several hundred bytes. Because of the size of the buffer,
these emulations can be as reliable as a 16550A in their
ability to handle high speed data. However, most operating
systems will still report that the UART is only a 8250A or
16450, and may not make effective use of the extra buffering
present in the emulated UART unless special drivers are
used.Some modem makers are driven by market forces to abandon a
design that has hundreds of bytes of buffer and instead use a
16550A UART so that the product will compare favorably in
market comparisons even though the effective performance may
be lowered by this action.A common misconception is that all parts with 16550A
written on them are identical in performance. There are
differences, and in some cases, outright flaws in most of
these 16550A clones.When the NS16550 was developed, the National Semiconductor
obtained several patents on the design and they also limited
licensing, making it harder for other vendors to provide a
chip with similar features. Because of the patents,
reverse-engineered designs and emulations had to avoid
infringing the claims covered by the patents. Subsequently,
these copies almost never perform exactly the same as the
NS16550A or PC16550D, which are the parts most computer and
modem makers want to buy but are sometimes unwilling to pay
the price required to get the genuine part. Some of the differences in the clone 16550A parts are
unimportant, while others can prevent the device from being
used at all with a given operating system or driver. These
differences may show up when using other drivers, or when
particular combinations of events occur that were not well
tested or considered in the Windows driver. This is because
most modem vendors and 16550-clone makers use the Microsoft
drivers from Windows for Workgroups 3.11 and the Microsoft MSD
utility as the primary tests for compatibility with the
NS16550A. This over-simplistic criteria means that if a
different operating system is used, problems could appear due
to subtle differences between the clones and genuine
components.National Semiconductor has made available a program named
COMTEST that performs compatibility tests independent of any
OS drivers. It should be remembered that the purpose of this
type of program is to demonstrate the flaws in the products of
the competition, so the program will report major as well as
extremely subtle differences in behavior in the part being
tested.In a series of tests performed by the author of this
document in 1994, components made by National Semiconductor,
TI, StarTech, and CMD as well as megacells and emulations
embedded in internal modems were tested with COMTEST. A
difference count for some of these components is listed below.
Because these tests were performed in 1994, they may not
reflect the current performance of the given product from a
vendor.It should be noted that COMTEST normally aborts when an
excessive number or certain types of problems have been
detected. As part of this testing, COMTEST was modified so
that it would not abort no matter how many differences were
encountered.Vendor Part number Errors
aka "differences" reported National (PC16550DV)
0 * National (NS16550AFN) 0 National
(NS16C552V) 0 * TI (TL16550AFN)
3 CMD (16C550PE) 19 StarTech
(ST16C550J) 23 Rockwell reference
modem with internal 16550 or an emulation
(RC144DPi/C3000-25) 117 Sierra modem with an
internal 16550 (SC11951/SC11351)
91It is important to understand that a simple count of
differences from COMTEST does not reveal a lot about what
differences are important and which are not. For example,
about half of the differences reported in the two modems
listed above that have internal UARTs were caused by the clone
UARTs not supporting five- and six-bit character modes. The
real 16550, 16450, and 8250 UARTs all support these modes and
COMTEST checks the functionality of these modes so over fifty
differences are reported. However, almost no modern modem
supports five- or six-bit characters, particularly those with
error-correction and compression capabilities. This means
that the differences related to five- and six-bit character
modes can be discounted.Many of the differences COMTEST reports have to do with
timing. In many of the clone designs, when the host reads
from one port, the status bits in some other port may not
update in the same amount of time (some faster, some slower)
as a real NS16550AFN and COMTEST looks
for these differences. This means that the number of
differences can be misleading in that one device may only have
one or two differences but they are extremely serious, and
some other device that updates the status registers faster or
slower than the reference part (that would probably never
affect the operation of a properly written driver) could have
dozens of differences reported.* To date, the author of this document has not found any
non-National parts that report zero differences using the
COMTEST program. It should also be noted that National has
had five versions of the 16550 over the years and the newest
parts behave a bit differently than the classic NS16550AFN
that is considered the benchmark for functionality. COMTEST
appears to turn a blind eye to the differences within the
National product line and reports no errors on the National
parts (except for the original 16550) even when there are
official erratas that describe bugs in the A, B and C
revisions of the parts, so this bias in COMTEST must be taken
into account.COMTEST can be used as a screening tool to alert the
administrator to the presence of potentially incompatible
components that might cause problems or have to be handled as
a special case.If you run COMTEST on a 16550 that is in a modem or a
modem is attached to the serial port, you need to first issue
a ATE0&W command to the modem so that the modem will not
echo any of the test characters. If you forget to do this,
COMTEST will report at least this one difference:
This is a user process PPP software package. Normally, PPP
is implemented as a part of the kernel (e.g. as managed by pppd)
and it is thus somewhat hard to debug and/or modify its
behavior. However, in this implementation PPP is done as a user
process with the help of the tunnel device driver (tun).
In essence, this means that rather than running a PPP daemon,
the ppp program can be run as and when desired. No PPP interface
needs to be compiled into the kernel, as the program can use the
generic tunnel device to get data into and out of the kernel.From here on out, user ppp will be referred to simply as ppp
unless a distinction needs to be made between it and any other PPP
client/server software such as pppd. Unless otherwise stated, all
commands in this section should be executed as root.Before you startThis document assumes you are in roughly this position:You have an account with an Internet Service Provider (ISP)
which lets you use PPP. Further, you have a modem (or other
device) connected and configured correctly which allows you to
connect to your ISP.You are going to need the following information to
hand:Your ISPs phone number(s).Your login name and password. This can be either a
regular unix style login/password pair, or a PPP PAP or CHAP
login/password pair.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 your
ISP hasn't given you this number, don't worry. We can make
one up and your ISP's PPP server will tell us when we
connect.This number is known from now on as
HISADDR.Your ISP's netmask setting. Again, if your ISP hasn't
given you this information, you can safely use a netmask of
255.255.255.0.The IP addresses of one or more nameservers. Normally,
you will be given two IP numbers. You
MUST have this information unless you run
your own nameserver.If your ISP allocates you a static IP address and
hostname then you will need this information too. If not,
you will need to know from what range of IP addresses your
allocated IP address will belong. If you haven't been given
this range, don't worry. You can configure PPP to accept any
IP number (as explained later).If you do not have any of the required information, contact
your ISP and make sure they provide it to you.Building a ppp ready kernelAs the description states, ppp uses the kernel tun
device. It is necessary to make sure that your kernel has support
for this device compiled in.To check this, go to your kernel compile directory
(/sys/i386/conf or
/sys/pc98/conf) and examine your kernel
configuration file. It needs to have the line pseudo-device tun 1in it somewhere. The stock GENERIC kernel
has this as standard, so if you have not installed a custom kernel
or you do not have a /sys directory, you do not have to change
anything.If your kernel configuration file does not have this line in
it, or you need to configure more than one tun device (for
example, if you are setting up a server and could have 16 dialup
ppp connections at any one time then you will need to use 16
instead of 1), then you should add the line, re-compile,
re-install and boot the new kernel. Please refer to the
section for more information on kernel
configuration.You can check how many tunnel devices your current kernel has
by typing the following: # 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=8050<POINTOPOINT,RUNNING,MULTICAST> mtu
1500which in this case shows four tunnel devices, two of which are
currently configured and being used.If you have a kernel without the tun device, and you can not
rebuild it for some reason, all is not lost. You should be able
to dynamically load the code. Refer to the appropriate modload8
and lkm4 pages for further details.You may also wish to take this opportunity to configure a
firewall. Details can be found in the section.Check the tun deviceMost users will only require one tun device (/dev/tun0). If you
have used more (i.e., a number other than 1 in the pseudo-device
line in the kernel configuration file) then alter all references
to tun0 below to reflect whichever device number you are
using.The easiest way to make sure that the tun0 device is
configured correctly is to re-make it. To do this, execute the
following commands: # cd /dev # ./MAKEDEV tun0If you require 16 tunnel devices in your kernel, you will need
to create more than just tun0: # cd /dev # ./MAKEDEV tun15Also, to confirm that the kernel is configured correctly, the
following command should give the indicated output: $ ifconfig tun0 tun0:
flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 $
Name Resolution ConfigurationThe 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
(man 5 hosts). The second is the
Internet Domain Name Service (DNS), a distributed data base, the
discussion of which is beyond the scope of this document.This section describes briefly how to configure your
resolver.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 the /etc/host.conf fileThis file should contain the following two lines: hosts bind which instructs the resolver to first look in
the file /etc/hosts, and then to consult
the DNS if the name was not found.Edit the <filename>/etc/hosts</filename>(5) fileThis 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 10.0.0.1 foo.bar.com
fooThe first line defines 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
line maps 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,
then use these in place of the 10.0.0.1 entry.Edit the <filename>/etc/resolv.conf</filename> file/etc/resolv.conf 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): nameserver x.x.x.x nameserver y.y.y.y domain
bar.comThe 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 resolv.conf
manual page for details of other possible entries in this
file.PPP ConfigurationBoth user ppp and pppd (the kernel level implementation of
PPP) use configuration files located in the
/etc/ppp directory. The sample configuration
files provided are a good reference for user ppp, so don't 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 can be different for each PPP
session).PPP and 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\\T
TIMEOUT 40 CONNECT" 5 provider: 6 set phone
"(0123) 456 7890" 7 set login "TIMEOUT 10
gin:-BREAK-gin: foo word: bar col: ppp" 8 set timeout
300 9 deny lqr 10 set ifaddr x.x.x.x y.y.y.y 11
delete ALL 12 add 0 0 HISADDR 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
doesn't work (it should with any reasonably new modem),
try 38400 instead.Line 4:The dial string. User ppp uses an expect-send
syntax similar to the chat8
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 : or |
character as a separator. The difference between these
spearators is described in the ppp manual page. To
summarize, if you want to rotate through the numbers,
use the :. 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 |. 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: pppYou will need to alter this script to suit your own
needs. If you're using PAP or CHAP, there will be no
login at this point, so your login string can be left
blank. See
for further details.Line 8: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:Ppp can be configured to exchange Link Quality
Report (LQR) packets. These packets describe how good
the physical link is. Ppp's LQR strategy is to close
the connection when a number of these packets are
missed. This is useful when you have a direct serial
link to another machine and the DSR modem signal is not
available to indicate that the line is up. When data
saturates the line, LQR packets are sometimes
missed, causing ppp to close the connection
prematurely. Refusing to negotiate lqr is sometimes
prudent (if you are going through a modem) as it avoids
this whole mess. By default, ppp will not attempt to
negotiate LQR, but will accept LQR negotiation from the
peer.Line 10: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
. If this line is omitted, ppp cannot
run in or
mode.Line 11:Deletes all existing routing table entries for the
acquired tun device. This should not normally be
necessary, but will make sure that PPP is starting with
a clean bill of health.Line 12:Adds a default route to your ISPs 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.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
/etc/ppp directory.PPP and Dynamic IP addresses
If your service provider does not assign static IP numbers,
ppp can be configured to negotiate
the local and remote addresses. This is done by guessing an
IP number and allowing ppp to set it up correctly using the IP
Configuration Protocol (IPCP) after connecting. The
ppp.conf configuration is the same as , with the following change:10 set ifaddr 10.0.0.1/0 10.0.0.2/0
255.255.255.0Again, do not include the line numbers, they are just for
reference in this discussion. Indentation of at least one space
is required.Line 10: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 almost always
work. If it fails, you may be able to defeat some
broken ppp implementations by supplying an additional
0.0.0.0 argument: set ifaddr 10.0.0.1/0 10.0.0.2/0
255.255.255.0 0.0.0.0This tells ppp to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use 0.0.0.0/0 as the first argument
to set ifaddr as it
prevents ppp from setting up an initial route in
and
mode.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
HISADDRLine 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 number of our
gateway. This entry is a four-octet IP style label. If
we still haven't found an entry, look for the
MYADDR entry.Line 2:This line tells ppp to delete all 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
/etc/ppp/ppp.conf.sample and
/etc/ppp/ppp.linkup.sample for a detailed
example.Receiving incoming calls with PPPThis section describes setting up ppp in a server
role.When you configure ppp to
receive incoming calls, you must decide whether you wish to
forward packets for just ppp
connections, for all interfaces, or not at all. To forward for
just ppp connections, include the line enable proxyin your ppp.conf file. If you wish to
forward packets on all interfaces, use the gateway=YESoption in /etc/rc.conf (this file used
to be called /etc/sysconfig).Which getty? provides a good description on enabling
dialup services using getty.An alternative to getty is mgetty, a smarter version of getty designed with dialup 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
won't 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 for more information on mgetty.PPP permissionsPPP 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.Setting up a PPP shell for dynamic-IP usersCreate 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 $IDENTThis script should be executable. Now make a symbolic
link called ppp-dialup to this script
using the following commands: # ln -s /etc/ppp/ppp-shell
/etc/ppp/ppp-dialupYou should use this script as the
shell for all your dialup ppp 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-dialupCreate 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 .rhostswhich prevents /etc/motd from being
displayed.Setting up a PPP shell for static-IP usersCreate 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: # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred # ln
-s /etc/ppp/ppp-shell /etc/ppp/ppp-sam # ln -s
/etc/ppp/ppp-shell /etc/ppp/ppp-maryEach of these users dialup accounts should have their
shell set to the symbolic link created above. (ie. mary's
shell should be
/etc/ppp/ppp-mary).Setting up ppp.conf for dynamic-IP usersThe /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
proxyNote 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 from your pool of ip address for
dynamic users.Setting up ppp.conf for static-IP usersAlong with the contents of the sample
/etc/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.255The 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
HISADDRMore on mgetty, AutoPPP, and MS extensionsMgetty and AutoPPP
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-dialupThis 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 TTY=`tty` IDENT=`basename $TTY` exec
/usr/sbin/ppp -direct pap$IDENTFor 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. papttyd0: enable pap set ifaddr 203.14.100.1
203.14.100.20 255.255.255.255 enable proxy papttyd1:
enable pap set ifaddr 203.14.100.1 203.14.100.21
255.255.255.255 enable proxyEach user logging in with this method will need to have
a username/password in
/etc/ppp/ppp.secret file, or
alternatively add the enable passwdauthoption to authenticate users via pap from the
/etc/passwordd file. (*) (*) Note this option only available in 2.2-961014-SNAP
or later, or by getting the updated ppp code for 2.1.x. (see
MS extensions below for details)MS extentionsFrom 2.2-961014-SNAP onwards it is possible to allow the
automatic negotiation of DNS and NetBIOS name servers with
clients supporting this feature (namely Win95/NT clients).
See RFC1877 for more details on the protocol.An example of enabling these extensions in your
/etc/ppp/ppp.conf file is illustrated
below. default: set debug phase lcp chat set timeout 0
enable msext set ns 203.14.100.1 203.14.100.2 set nbns
203.14.100.5This will tell the clients the primary and secondary
name server addresses, and a netbios nameserver host.PAP and CHAP authentication
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 hackers to eavesdrop.Referring back to the or sections, the following alterations must be
made:7 set login ..... 13 set authname
MyUserName 14 set authkey MyPasswordAs 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 13:This line specifies your PAP/CHAP user name. You
will need to insert the correct value for MyUserName.Line 14: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
15 accept PAP or
15 accept CHAP to make it obvious that this is the
intention, but PAP and CHAP are accepted by
default.Your authkey will be logged
if you have command logging turned on (set log
+command). Care should be taken when deciding the
ppp log file permissions.Changing your ppp configuration on the flyIt is possible to talk to the ppp program while it is
running in the background, but only if a suitable password has
been set up.By default, ppp will listen to a TCP port of 3000 +
tunno, where tunno is the number of the tun device
acquired, however, if a password for the local machine is not
set up in /etc/ppp/ppp.secret, no server
connection will be created. To set your password, put the
following line in
/etc/ppp/ppp.secret:foo MyPasswordwhere foo is your local
hostname (run hostname -s to determine the
correct name), and MyPassword is
the unencrypted password that you wish to use.
/etc/ppp/ppp.secret should
NOT be accessable by anyone without user id
0. This means that /,
/etc and /etc/ppp
should not be writable, and ppp.secret
should be owned by user id 0 and have permissions 0600.It is also possible to select a specific port number or to
have ppp listen to a local unix domain socket rather than to a
TCP socket. Refer to the set
socket command in manual page for further
details.Once a socket has been set up, the
pppctl8 program may be used in scripts that
wish to manipulate the running program.Final system configuration
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 (was
/etc/sysconfig).Working from the top down in this file, make sure the
hostname= line is set, e.g.: hostname=foo.bar.comIf 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 mysystemThis 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 the line router_enable=NO (/etc/rc.conf) router=NO
(/etc/sysconfig)It is important that the routed
daemon is not started (it's started by default) as 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"The upshot of this is that you must force sendmail to
re-examine the mail queue whenever the ppp link is up by
typing: # /usr/sbin/sendmail -qYou 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 -q30mIf 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.All that is left is to reboot the machine.After rebooting, you can now either type # pppand then dial provider to start the PPP session, or, if
you want ppp to establish sessions automatically when there is
outbound traffic (and you haven't created the start_if.tun0
script), type # ppp -auto providerSummaryTo 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 (or
sysconfig) 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 vipw8 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 (or
sysconfig) file.AcknowledgmentsThis section of the handbook was last updated on Sun Sep 7,
1997 by &a.brian;Thanks to the following for their input, comments &
suggestions:&a.nik;&a.dirkvangulik;&a.pjc;Setting up Kernel PPPContributed by &a.gena;.Before you start setting up PPP on your machine make sure that
pppd is located in /usr/sbin and directory
/etc/ppp exists.pppd can work in two modes:
as a client , i.e. you want to connect your machine to
outside world via PPP serial connection or modem line.
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 then one user on your
machine that uses PPP).You also will need some modem/serial software ( preferably
kermit ) so you can dial and establish connection with remote
host.Working as a PPP clientI used the following /etc/ppp/options to
connect to 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
routerTo connect:
Dial to the remote host using kermit ( or other modem
program ) 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: /usr/src/usr.sbin/pppd.new/pppd
/dev/tty01 19200 ( put the appropriate
speed and device name )Now your computer is connected with PPP. If the connection
fails for some reasons you can add the option to the
/etc/ppp/options file and check messages on
the console to track the problemFollowing /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/etc/ppp/kermit.dial is kermit script
that dials and makes all necessary authorization on the remote
host. ( Example of such 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/ppptestCheck if PPP is still running
(/usr/etc/ppp/ppptest):
#!/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 ppp0Hangs up modem line
(/etc/ppp/kermit.hup): 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 exitHere is an alternate method using chat instead of kermit.Contributed by &a.rhuff;.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 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 <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:(This should actually go into 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 ispppd. This sample based primarily on information provided
by: Trev Roydhouse
<Trev.Roydhouse@f401.n711.z3.fidonet.org> and used by
permission.Working as a PPP server/etc/ppp/options: 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 lineFollowing /etc/ppp/pppserv script will
enable ppp server on your machine #!/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
19200Use this /etc/ppp/pppservdown script to
stop ppp 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.noansFollowing kermit script will enable/disable autoanswer mode
on your modem (/etc/ppp/kermit.ans):
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
exitThis /etc/ppp/kermit.dial script is used
for dialing and authorizing on remote host. You will need to
customize it for your needs. Put your login and password in this
script , also you will need to change 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:Setting up a SLIP ClientContributed by &a.asami;8 Aug
1995.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 /dev/modem ->
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 pseudo-device sl
1 in your kernel's config file. It is included in
the GENERIC kernel, so this will not be a
problem unless you deleted it.Things you have to do only onceAdd 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 By the way, silvia is
the name of the car that I had when I was back in Japan (it
is called 2?0SX here in U.S.).
Make sure you have before in your
/etc/host.conf. Otherwise, funny things
may happen.
Edit the file /etc/rc.conf. Note
that you should edit the file
/etc/sysconfig instead if you are
running FreeBSD previous to version 2.2.2.
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"
Designate the default router by changing the line:
defaultrouter=NO to:
defaultrouter=slip-gatewayMake a file /etc/resolv.conf which
contains: domain HIP.Berkeley.EDU nameserver
128.32.136.9 nameserver 128.32.136.12 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
accounts that does not have a password). Use passwd, 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 connectionDial up, type slip at the prompt, enter your machine
name and password. The things you need to enter depends on
your environment. I use kermit, with 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). Then 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. I am just too lazy.Leave the kermit there (you can suspend it by z) and
as root, type 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.How to shutdown the connectionType kill -INT `cat /var/run/slattach.modem.pid` (as root)
to kill slattach. 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 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.TroubleshootingIf 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 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. I get:
silvia# ifconfig sl0 sl0:
flags=10<POINTOPOINT> inet 136.152.64.181 -->
136.152.64.1 netmask ffffff00Also, netstat -r will give the
routing table, in case you get the "no route to host"
messages from ping. Mine looks like: silvia#
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 ServerContributed by &a.ghelmer;. v1.0, 15 May
1995.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.This guide was originally written for SLIP Server services on a
FreeBSD 1.x system. It has been modified to reflect changes in the
pathnames and the removal of the SLIP interface compression flags in
early versions of FreeBSD 2.X, which appear to be the only major
changes between FreeBSD versions. If you do encounter mistakes in
this document, please email the author with enough information to
help correct the problem.PrerequisitesThis 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.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/;
otherwise, check the place where you found this document for a
document named dialup.txt or something
similar. You may also want to check the manual pages for
sio4 for information on the serial
port device driver and ttys5,
gettytab5,
getty8, & init8 for
information relevant to configuring the system to accept logins on
modems, and perhaps stty1 for information on
setting serial port parameters [such as clocal for directly-connected serial
interfaces].Quick OverviewIn 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 LoginFor 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/sliploginand, 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
autocompsliplogin 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 autocompIf 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 syslogd8 and
syslog.conf5, 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 ConfigurationFreeBSD'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 0The 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
RFC's 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 (called
/etc/sysconfig in FreeBSD releases prior to
2.2.2) and change the setting of the gateway variable to .
If you have an older system which predates even the
/etc/sysconfig file, then add the following
command: sysctl -w net.inet.ip.forwarding =
1 to your /etc/rc.local
file.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 2which 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 for help in
reconfiguring your kernel.Sliplogin ConfigurationAs mentioned earlier, there are three files in the
/etc/sliphome directory that are part of the
configuration for /usr/sbin/sliplogin (see
sliplogin8 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 maskThe 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 I believe 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:----- begin /etc/sliphome/slip.hosts ----- # # login
local-addr remote-addr mask opt1 opt2
#
(normal,compress,noicmp) # Shelmerg dc-slip
sl-helmerg 0xfffffc00 autocomp ----- end
/etc/sliphome/slip.hosts ------At the end of the line is one or more of the options.normal - no header
compressioncompress - compress
headersautocomp - compress
headers if the remote end allows itnoicmp - 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 normal,
compress, autocomp, and noicmp had no effect until support was
added in FreeBSD 2.2 (unless your
slip.login script included code to make use
of the flags).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 section
and/or consult your IP network manager.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.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
arp8 to manage the proxy-ARP entries in the
SLIP server's ARP table.<filename>slip.login</filename> ConfigurationThe typical /etc/sliphome/slip.login
file looks like this:----- begin /etc/sliphome/slip.login ----- #!/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 ----- end /etc/sliphome/slip.login
-----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:----- begin /etc/sliphome/slip.login for "proxy ARP"
----- #!/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 ----- end
/etc/sliphome/slip.login for "proxy ARP" -----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.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 ^^^^^^^^^^^^^^
which 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
arp8 desires; see the manual page on
arp8 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:----- begin /etc/sliphome/slip.logout ----- #!/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 ----- end
/etc/sliphome/slip.logout -----If you are using proxy ARP, you will want to have
/etc/sliphome/slip.logout remove the ARP
entry for the SLIP client:----- begin /etc/sliphome/slip.logout for "proxy ARP"
----- #!/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 ----- end /etc/sliphome/slip.logout for "proxy ARP"
-----The arp -d $5 removes the ARP entry
that the proxy ARPslip.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 ConsiderationsIf 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 RoutesAdding 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 gatedAn 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
or retrieve and
build it yourself from the GateD anonymous ftp site; I believe 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:----- begin sample /etc/gated.conf for gated version
3.5Alpha5 ----- # # 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 ; } ; ----- end sample
/etc/gated.conf -----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.AcknowledgmentsThanks to these people for comments and advice regarding this
tutorial:&a.wilko;Piero Serini<Piero@Strider.Inet.IT>Advanced NetworkingGateways and RoutesContributed by &a.gryphon;.6 October
1995.For one machine to be able to find another, there must be a
mechanism in place to describe how to get from one to the other.
This is called Routing. A route is a defined pair of addresses:
a destination and a gateway. The pair indicates that if you are
trying to get to this destination, send along
through this gateway. There are three types of
destinations: individual hosts, subnets, and default. The
default route is used if none of the other routes apply. We will
talk a little bit more about default routes later on. There are
also three types of gateways: individual hosts, interfaces (also
called links), and ethernet hardware addresses.An exampleTo illustrate different aspects of routing, we will use the
following example which is the output of the command
netstat -r:Destination Gateway Flags Refs
Use Netif Expire default outside-gw UGSc
37 418 ppp0 localhost localhost UH
0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW
5 63288 ed0 77 10.20.30.255 link#1
UHLW 1 2421 foobar.com link#1 UC
0 0 host1 0:e0:a8:37:8:1e UHLW 3
4601 lo0 host2 0:e0:a8:37:8:1e UHLW
0 5 lo0 => host2.foobar.com link#1
UC 0 0 224 link#1 UC
0 0The first two lines specify the default route (which we will
cover in the next section) and the localhost route.The interface (Netif column)
that it specifies to use for localhost is lo0, also known as the loopback device. This
says to keep all traffic for this destination internal, rather
than sending it out over the LAN, since it will only end up back
where it started anyway.The next thing that stands out are the 0:e0:... addresses. These are ethernet
hardware addresses. FreeBSD will automatically identify any hosts
(test0 in the example) on the local
ethernet and add a route for that host, directly to it over the
ethernet interface, ed0. There is
also a timeout (Expire column)
associated with this type of route, which is used if we fail to
hear from the host in a specific amount of time. In this case the
route will be automatically deleted. These hosts are identified
using a mechanism known as RIP (Routing Information Protocol),
which figures out routes to local hosts based upon a shortest path
determination.FreeBSD will also add subnet routes for the local subnet
(10.20.30.255 is the broadcast
address for the subnet 10.20.30, and
foobar.com is the domain name
associated with that subnet). The designation link#1 refers to the first ethernet card in
the machine. You will notice no additional interface is specified
for those.Both of these groups (local network hosts and local subnets)
have their routes automatically configured by a daemon called
routed. If this is not run, then
only routes which are statically defined (ie. entered explicitly)
will exist.The host1 line refers to our
host, which it knows by ethernet address. Since we are the
sending host, FreeBSD knows to use the loopback interface
(lo0) rather than sending it out
over the ethernet interface.The two host2 lines are an
example of what happens when we use an ifconfig alias (see the
section of ethernet for reasons why we would do this). The
=> symbol after the lo0 interface says that not only are we
using the loopback (since this is address also refers to the local
host), but specifically it is an alias. Such routes only show up
on the host that supports the alias; all other hosts on the local
network will simply have a link#1
line for such.The final line (destination subnet 224) deals with MultiCasting, which will be
covered in a another section.The other column that we should talk about are the Flags. Each route has different attributes
that are described in the column. Below is a short table of some
of these flags and their meanings:UUp: The route is
active.HHost: The route
destination is a single host.GGateway: Send anything
for this destination on to this remote system, which will
figure out from there where to send it.SStatic: This route was
configured manually, not automatically generated by the
system.CClone: Generates a new
route based upon this route for machines we connect to.
This type of route is normally used for local
networks.WWasCloned Indicated a
route that was auto-configured based upon a local area
network (Clone) route.LLink: Route involves
references to ethernet hardware.Default routesWhen the local system needs to make a connection to remote
host, it checks the routing table to determine if a known path
exists. If the remote host falls into a subnet that we know how to
reach (Cloned routes), then the system checks to see if it can
connect along that interface.If all known paths fail, the system has one last option: the
default route. This route is a
special type of gateway route (usually the only one present in the
system), and is always marked with a c in the flags field. For hosts on a
local area network, this gateway is set to whatever machine has a
direct connection to the outside world (whether via PPP link, or
your hardware device attached to a dedicated data line).If you are configuring the default route for a machine which
itself is functioning as the gateway to the outside world, then
the default route will be the gateway machine at your Internet
Service Provider's (ISP) site.Let us look at an example of default routes. This is a common
configuration:
[Local2] <--ether--> [Local1] <--PPP-->
[ISP-Serv] <--ether--> [T1-GW]The hosts Local1 and Local2 are at your site, with the formed
being your PPP connection to your ISP's Terminal Server. Your ISP
has a local network at their site, which has, among other things,
the server where you connect and a hardware device (T1-GW)
attached to the ISP's Internet feed.The default routes for each of your machines will be:host default gateway interface ----
--------------- --------- Local2 Local1
ethernet Local1 T1-GW PPPA common question is Why (or how) would we set the T1-GW to
be the default gateway for Local1, rather than the ISP server it
is connected to?.Remember, since the PPP interface is using an address on the
ISP's local network for your side of the connection, routes for
any other machines on the ISP's local network will be
automatically generated. Hence, you will already know how to reach
the T1-GW machine, so there is no need for the intermediate step
of sending traffic to the ISP server.As a final note, it is common to use the address ...1 as the gateway address for your local
network. So (using the same example), if your local class-C
address space was 10.20.30 and your
ISP was using 10.9.9 then the
default routes would be:Local2 (10.20.30.2) --> Local1
(10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW
(10.9.9.1)Dual homed hostsThere is one other type of configuration that we should cover,
and that is a host that sits on two different networks.
Technically, any machine functioning as a gateway (in the example
above, using a PPP connection) counts as a dual-homed host. But
the term is really only used to refer to a machine that sits on
two local-area networks.In one case, the machine as two ethernet cards, each having an
address on the separate subnets. Alternately, the machine may only
have one ethernet card, and be using ifconfig aliasing. The former
is used if two physically separate ethernet networks are in use,
the latter if there is one physical network segment, but two
logically separate subnets.Either way, routing tables are set up so that each subnet
knows that this machine is the defined gateway (inbound route) to
the other subnet. This configuration, with the machine acting as
a Bridge between the two subnets, is often used when we need to
implement packet filtering or firewall security in either or both
directions.Routing propagationWe have already talked about how we define our routes to the
outside world, but not about how the outside world finds
us.We already know that routing tables can be set up so that all
traffic for a particular address space (in our examples, a class-C
subnet) can be sent to a particular host on that network, which
will forward the packets inbound.When you get an address space assigned to your site, your
service provider will set up their routing tables so that all
traffic for your subnet will be sent down your PPP link to your
site. But how do sites across the country know to send to your
ISP?There is a system (much like the distributed DNS information)
that keeps track of all assigned address-spaces, and defines their
point of connection to the Internet Backbone. The Backbone are
the main trunk lines that carry Internet traffic across the
country, and around the world. Each backbone machine has a copy of
a master set of tables, which direct traffic for a particular
network to a specific backbone carrier, and from there down the
chain of service providers until it reaches your network.It is the task of your service provider to advertise to the
backbone sites that they are the point of connection (and thus the
path inward) for your site. This is known as route
propagation.TroubleshootingSometimes, there is a problem with routing propagation, and
some sites are unable to connect to you. Perhaps the most useful
command for trying to figure out where a routing is breaking down
is the traceroute8 command. It is equally
useful if you cannot seem to make a connection to a remote machine
(ie. ping8 fails).The traceroute8 command is run with the
name of the remote host you are trying to connect to. It will show
the gateway hosts along the path of the attempt, eventually either
reaching the target host, or terminating because of a lack of
connection.For more information, see the manual page for
traceroute8.NFSContributed by &a.jlind;.Certain Ethernet adapters for ISA PC systems have limitations
which can lead to serious network problems, particularly with NFS.
This difficulty is not specific to FreeBSD, but FreeBSD systems are
affected by it.The problem nearly always occurs when (FreeBSD) PC systems are
networked with high-performance workstations, such as those made by
Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount
will work fine, and some operations may succeed, but suddenly the
server will seem to become unresponsive to the client, even though
requests to and from other systems continue to be processed. This
happens to the client system, whether the client is the FreeBSD
system or the workstation. On many systems, there is no way to shut
down the client gracefully once this problem has manifested itself.
The only solution is often to reset the client, because the NFS
situation cannot be resolved.Though the correct solution is to get a higher performance and
capacity Ethernet adapter for the FreeBSD system, there is a simple
workaround that will allow satisfactory operation. If the FreeBSD
system is the SERVER, include the option on the mount from
the client. If the FreeBSD system is the CLIENT, then mount the NFS
file system with the option . These options may be
specified using the fourth field of the fstab entry on the client
for automatic mounts, or by using the parameter of the mount
command for manual mounts.It should be noted that there is a different problem, sometimes
mistaken for this one, when the NFS servers and clients are on
different networks. If that is the case, make CERTAIN that your
routers are routing the necessary UDP information, or you will not
get anywhere, no matter what else you are doing.In the following examples, "fastws" is the host (interface) name
of a high-performance workstation, and "freebox" is the host
(interface) name of a FreeBSD system with a lower-performance
Ethernet adapter. Also, /sharedfs will be the exported NFS
filesystem (see man exports), and /project will be the mount
point on the client for the exported file system. In all cases,
note that additional options, such as or and may
be desirable in your application.Examples for the FreeBSD system ("freebox") as the client: in
/etc/fstab on freebox: fastws:/sharedfs
/project nfs rw,-r=1024 0 0 as a manual mount command on freebox:
mount -t nfs -o -r=1024 fastws:/sharedfs /projectExamples for the FreeBSD system as the server: in
/etc/fstab on fastws: freebox:/sharedfs
/project nfs rw,-w=1024 0 0 as a manual mount command on fastws:
mount -t nfs -o -w=1024 freebox:/sharedfs /projectNearly any 16-bit Ethernet adapter will allow operation without
the above restrictions on the read or write size.For anyone who cares, here is what happens when the failure
occurs, which also explains why it is unrecoverable. NFS typically
works with a block size of 8k (though it may do fragments of
smaller sizes). Since the maximum Ethernet packet is around 1500
bytes, the NFS block gets split into multiple Ethernet packets,
even though it is still a single unit to the upper-level code, and
must be received, assembled, and ACKNOWLEDGED as a unit. The
high-performance workstations can pump out the packets which
comprise the NFS unit one right after the other, just as close
together as the standard allows. On the smaller, lower capacity
cards, the later packets overrun the earlier packets of the same
unit before they can be transferred to the host and the unit as a
whole cannot be reconstructed or acknowledged. As a result, the
workstation will time out and try again, but it will try again with
the entire 8K unit, and the process will be repeated, ad
infinitum.By keeping the unit size below the Ethernet packet size
limitation, we ensure that any complete Ethernet packet received can
be acknowledged individually, avoiding the deadlock
situation.Overruns may still occur when a high-performance workstations is
slamming data out to a PC system, but with the better cards, such
overruns are not guaranteed on NFS "units". When an overrun occurs,
the units affected will be retransmitted, and there will be a fair
chance that they will be received, assembled, and acknowledged.
Diskless OperationContributed by &a.martin;.netboot.com/netboot.rom allow you to boot
your FreeBSD machine over the network and run FreeBSD without having
a disk on your client. Under 2.0 it is now possible to have local
swap. Swapping over NFS is also still supported.Supported Ethernet cards include: Western Digital/SMC 8003,
8013, 8216 and compatibles; NE1000/NE2000 and compatibles (requires
recompile)Setup Instructions Find a machine that will be your server. This machine
will require enough disk space to hold the FreeBSD 2.0
binaries and have bootp, tftp and NFS services available.
Tested machines:
HP9000/8xx running HP-UX 9.04 or later (pre 9.04
doesn't work)Sun/Solaris 2.3. (you may need to get
bootp)Set up a bootp server to provide the client with IP,
gateway, netmask.
diskless:\ :ht=ether:\ :ha=0000c01f848a:\
:sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\
:ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048:Set up a TFTP server (on same machine as bootp server)
to provide booting information to client. The name of this
file is cfg.X.X.X.X (or
/tftpboot/cfg.X.X.X.X, it will try
both) where X.X.X.X is the IP address
of the client. The contents of this file can be any valid
netboot commands. Under 2.0, netboot has the following
commands:
help - print help list ip
<X.X.X.X> - print/set client's IP
address server <X.X.X.X> - print/set bootp/tftp
server address netmask <X.X.X.X> - print/set
netmask hostname <name> - print/set
hostname kernel <name> - print/set
kernel name rootfs <ip:/fs> - print/set
root filesystem swapfs <ip:/fs> -
print/set swap filesystem swapsize <size>
- set diskless swapsize in Kbytes diskboot
- boot from disk autoboot - continue boot
process trans <on|off> - turn
transceiver on|off flags [bcdhsv] - set boot
flags A typical completely diskless cfg file
might contain:
rootfs 192.1.2.3:/rootfs/myclient swapfs
192.1.2.3:/swapfs swapsize 20000 hostname
myclient.mydomain A cfg file for a machine with local swap
might contain:
rootfs 192.1.2.3:/rootfs/myclient hostname
myclient.mydomainEnsure that your NFS server has exported the root (and
swap if applicable) filesystems to your client, and that the
client has root access to these filesystems A typical
/etc/exports file on FreeBSD might look
like:
/rootfs/myclient -maproot=0:0 myclient.mydomain
/swapfs -maproot=0:0 myclient.mydomain And on HP-UX:
/rootfs/myclient -root=myclient.mydomain /swapfs
-root=myclient.mydomainIf you are swapping over NFS (completely diskless
configuration) create a swap file for your client using
dd. If your swapfs command has the arguments
/swapfs and the size 20000 as in the
example above, the swapfile for myclient will be called
/swapfs/swap.X.X.X.X where
X.X.X.X is the client's IP addr, eg:
# dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k
count=20000 Also, the client's swap space might
contain sensitive information once swapping starts, so make
sure to restrict read and write access to this file to
prevent unauthorized access:
# chmod 0600 /swapfs/swap.192.1.2.4 Unpack the root filesystem in the directory the client
will use for its root filesystem
(/rootfs/myclient in the example
above).
On HP-UX systems: The server should be running
HP-UX 9.04 or later for HP9000/800 series machines.
Prior versions do not allow the creation of device
files over NFS.
When extracting /dev in
/rootfs/myclient, beware that
some systems (HPUX) will not create device files that
FreeBSD is happy with. You may have to go to single
user mode on the first bootup (press control-c during
the bootup phase), cd /dev and do
a sh ./MAKEDEV all
from the client to fix this.Run netboot.com on the client or
make an EPROM from the netboot.rom
fileUsing Shared <filename>/</filename> and
<filename>/usr</filename> filesystemsAt present there isn't an officially sanctioned way of doing
this, although I have been using a shared
/usr filesystem and individual
/ filesystems for each client. If anyone has
any suggestions on how to do this cleanly, please let me and/or
the &a.core; know.Compiling netboot for specific setupsNetboot can be compiled to support NE1000/2000 cards by
changing the configuration in
/sys/i386/boot/netboot/Makefile. See the
comments at the top of this file.ISDNLast modified by &a.wlloyd;.A good resource for information on ISDN technology and hardware
is Dan Kegel's
ISDN Page.A quick simple roadmap to ISDN follows:
If you live in Europe I suggest you investigate the ISDN
card section.
If you are planning to use ISDN primarily to connect to
the Internet with an Internet Provider on a dialup
non-dedicated basis, I suggest you look into Terminal
Adapters. This will give you the most flexibility, with the
fewest problems, if you change providers.
If you are connecting two lans together, or connecting to
the Internet with a dedicated ISDN connection, I suggest you
consider the stand alone router/bridge option.Cost is a significant factor in determining what solution you
will choose. The following options are listed from least expensive
to most expensive.ISDN CardsOriginal Contribution by &a.hm;.This section is really only relevant to European ISDN users.
The cards supported are not yet(?) available for North American
ISDN standards.You should be aware that this code is largely under
development. Specifically, drivers have only been written for two
manufacturers cards.PC ISDN cards support the full bandwidth of ISDN, 128Kbs.
These cards are often the least expensive type of ISDN equipment.
Under FreeBSD 2.1.0 and 2.1.5, there is early unfinished ISDN
code under /usr/src/gnu/isdn. This code is
out of date and should not be used. If you want to go this route,
get the bisdn stuff. This code has been removed from the main
source tree starting with FreeBSD 2.2.There is the bisdn ISDN package available from hub.freebsd.org
supporting FreeBSD 2.1R, FreeBSD-current and NetBSD. The latest
source can be found on the above mentioned ftp server under
directory isdn as file bisdn-097.tar.gz.There are drivers for the following cards:
Currently all (passive) Teles cards and their clones are
supported for the EuroISDN (DSS1) and 1TR6 protocols.Dr. Neuhaus - Niccy 1016There are several limitations with the bisdn stuff.
Specifically the following features usually associated with ISDN
are not supported.No PPP support, only raw hdlc. This means you cannot
connect to most standalone routers.Bridging Control Protocol not supported.Multiple cards are not supported.No bandwidth on demand.No channel bundling.A majordomo maintained mailing list is available. To join the
list, send mail to &a.majordomo; and specify:
subscribe freebsd-isdn In the body
of your message. ISDN Terminal AdaptersTerminal adapters(TA), are to ISDN what modems are to regular
phone lines.Most TA's use the standard hayes modem AT command set, and can
be used as a drop in replacement for a modem.A TA will operate basically the same as a modem except
connection and throughput speeds will be much faster than your old
modem. You will need to configure exactly the
same as for a modem setup. Make sure you set your serial speed as
high as possible.The main advantage of using a TA to connect to an Internet
Provider is that you can do Dynamic PPP. As IP address space
becomes more and more scarce, most providers are not willing to
provide you with a static IP anymore. Most standalone routers are
not able to accommodate dynamic IP allocation.TA's completely rely on the PPP daemon that you are running
for their features and stability of connection. This allows you
to upgrade easily from using a modem to ISDN on a FreeBSD machine,
if you already have PPP setup. However, at the same time any
problems you experienced with the PPP program and are going to
persist.If you want maximum stability, use the kernel option, not the user-land .
The following TA's are know to work with FreeBSD.Motorola BitSurfer and Bitsurfer ProAdtranMost other TA's will probably work as well, TA vendors try to
make sure their product can accept most of the standard modem AT
command set.The real problem with external TA's is like modems you need a
good serial card in your computer. You should read the
section in the handbook for a detailed understanding of serial
devices, and the differences between asynchronous and synchronous
serial ports.A TA running off a standard PC serial port (asynchronous)
limits you to 115.2Kbs, even though you have a 128Kbs connection.
To fully utilize the 128Kbs that ISDN is capable of, you must move
the TA to a synchronous serial card. Do not be fooled into buying an internal TA and thinking you
have avoided the synchronous/asynchronous issue. Internal TA's
simply have a standard PC serial port chip built into them. All
this will do, is save you having to buy another serial cable, and
find another empty electrical socket.A synchronous card with a TA is at least as fast as a
standalone router, and with a simple 386 FreeBSD box driving it,
probably more flexible.The choice of sync/TA vs standalone router is largely a
religious issue. There has been some discussion of this in the
mailing lists. I suggest you search the archives for
the complete discussion.Standalone ISDN Bridges/RoutersISDN bridges or routers are not at all specific to FreeBSD or
any other operating system. For a more complete description of
routing and bridging technology, please refer to a Networking
reference book.In the context of this page, I will use router and bridge
interchangeably.As the cost of low end ISDN routers/bridges comes down, it
will likely become a more and more popular choice. An ISDN router
is a small box that plugs directly into your local Ethernet
network(or card), and manages its own connection to the other
bridge/router. It has all the software to do PPP and other
protocols built in.A router will allow you much faster throughput that a standard
TA, since it will be using a full synchronous ISDN
connection.The main problem with ISDN routers and bridges is that
interoperability between manufacturers can still be a problem. If
you are planning to connect to an Internet provider, I recommend
that you discuss your needs with them.If you are planning to connect two lan segments together, ie:
home lan to the office lan, this is the simplest lowest
maintenance solution. Since you are buying the equipment for both
sides of the connection you can be assured that the link will
work.For example to connect a home computer or branch office
network to a head office network the following setup could be
used.Branch office or Home networkNetwork is 10 Base T Ethernet. Connect router to network
cable with AUI/10BT transceiver, if necessary.---Sun workstation | ---FreeBSD box |
---Windows 95 (Do not admit to owning it) | Standalone router |
ISDN BRI line If your home/branch office is only
one computer you can use a twisted pair crossover cable to connect
to the standalone router directly.Head office or other lanNetwork is Twisted Pair Ethernet.
-------Novell Server | H | | ---Sun | | | U
---FreeBSD | | | ---Windows 95 | B |
|___---Standalone router | ISDN BRI lineOne large advantage of most routers/bridges is that they allow
you to have 2 SEPARATE INDEPENDENT PPP connections to 2 separate
sites at the SAME time. This is not supported on most TA's,
except for specific(expensive) models that have two serial ports.
Do not confuse this with channel bonding, MPP etc.This can be very useful feature, for example if you have an
dedicated internet ISDN connection at your office and would like
to tap into it, but don't want to get another ISDN line at work.
A router at the office location can manage a dedicated B channel
connection (64Kbs) to the internet, as well as a use the other B
channel for a separate data connection. The second B channel can
be used for dialin, dialout or dynamically bond(MPP etc.) with the
first B channel for more bandwidth.An Ethernet bridge will also allow you to transmit more than
just IP traffic, you can also send IPX/SPX or whatever other
protocols you use.Electronic MailContributed by &a.wlloyd;. Electronic Mail configuration is the subject of many books. If you
plan on doing anything beyond setting up one mailhost for your
network, you need industrial strength help.Some parts of E-Mail configuration are controlled in the Domain
Name System (DNS). If you are going to run your own own DNS server
check out /etc/namedb
and ' man -k named
' for more information.Basic InformationThese are the major programs involved in an E-Mail exchange. A
mailhost is a server that is
responsible for delivering and receiving all email for your host,
and possibly your network.User program This is a program like elm, pine,
mail , or something more sophisticated like a WWW
browser. This program will simply pass off all e-mail
transactions to the local mailhost ,
either by calling sendmail or
delivering it over TCP.Mailhost Server Daemon Usually this program is sendmail or
smail running in the background. Turn it off or
change the command line options in
/etc/rc.conf (or, prior to FreeBSD 2.2.2,
/etc/sysconfig). It is best to leave it on,
unless you have a specific reason to want it off. Example: You
are building a .You should be aware that sendmail is a potential weak link in a
secure site. Some versions of sendmail have known security
problems. sendmail
does two jobs. It looks after delivering
and receiving mail.If sendmail needs to deliver mail off your site it will look up in
the DNS to determine the actual host that will receive mail for
the destination. If it is acting as a delivery agent sendmail will take the message from the
local queue and deliver it across the Internet to another sendmail
on the receivers computer. DNS - Name ServiceThe Domain Name System and its daemon named , contain the database mapping
hostname to IP address, and hostname to mailhost. The IP address
is specified in an A record. The MX record specifies the
mailhost that will receive mail for you. If you do not have a
MX record mail for your hostname, the mail will be delivered to
your host directly. Unless you are running your own DNS server, you will not be
able to change any information in the DNS yourself. If you are
using an Internet Provider, speak to them.POP Servers This program gets the mail from your mailbox and gives it to
your browser. If you want to run a POP server on your computer,
you will need to do 2 things.
Get pop software from the Ports collection that
can be found in /usr/ports or packages
collection. This handbook section has a complete reference
on the system.Modify /etc/inetd.conf
to load the POP server.The pop program will have instructions with it. Read
them.ConfigurationBasicAs your FreeBSD system comes out of the box[TM], you should
be able to send E-mail to external hosts as long as you have
/etc/resolv.conf setup or are running a name
server. If you want to have mail for your host delivered to your
specific host,there are two methods: - Run a name server ( man -k
named ) and have your own domain
smallminingco.com - Get mail delivered to the current DNS name for your host.
Ie: dorm6.ahouse.school.edu No matter what option you choose, to have mail delivered
directly to your host, you must be a full Internet host. You must
have a permanent IP address. IE: NO dynamic PPP. If you are
behind a firewall, the firewall must be passing on smtp traffic to
you. From /etc/servicessmtp
25/tcp mail #Simple Mail Transfer If you
want to receive mail at your host itself, you must make sure that
the DNS MX entry points to your host address, or there is no MX
entry for your DNS name.Try this newbsdbox# hostname
newbsdbox.freebsd.org newbsdbox# host newbsdbox.freebsd.org
newbsdbox.freebsd.org has address 204.216.27.xxIf that is all that comes out for your machine, mail directory
to root@newbsdbox.freebsd.org
will work no problems.If instead, you have this newbsdbox# host
newbsdbox.freebsd.org newbsdbox.FreeBSD.org has address
204.216.27.xx newbsdbox.FreeBSD.org mail is handled (pri=10) by
freefall.FreeBSD.org All mail sent to your host
directly will end up on freefall, under the same username.
This information is setup in your domain name server. This
should be the same host that is listed as your primary nameserver
in /etc/resolv.confThe DNS record that carries mail routing information is the
Mail eXchange entry. If no MX entry exists, mail will be
delivered directly to the host by way of the Address
record.The MX entry for freefall.freebsd.org at one time.
freefall MX 30
mail.crl.net freefall MX 40
agora.rdrop.com freefall HINFO Pentium
FreeBSD freefall MX 10
freefall.FreeBSD.org freefall MX 20
who.cdrom.com freefall A 204.216.27.xx
freefall CNAME
www.FreeBSD.orgFreefall has many MX entries. The lowest MX number gets the
mail in the end. The others will queue mail temporarily, if
freefall is busy or down.Alternate MX sites should have separate connections to the
Internet, to be most useful. An Internet Provider or other
friendly site can provide this service.dig, nslookup,
and
host are your friends.Mail for your Domain (Network).To setup up a network mailhost, you need to direct the mail
from arriving at all the workstations. In other words, you want to
hijack all mail for *.smallminingco.com
and divert it to one machine, your mailhost.The network users on their workstations will most likely pick
up their mail over POP or telnet. A user account with the SAME USERNAME should exist on both
machines. Please use adduser to do
this as required. If you set the shell to /nonexistent
the user will not be allowed to login.The mailhost that you will be using must be designated the
Mail eXchange for each workstation. This must be arranged in DNS
(ie BIND, named). Please refer to a Networking book for in-depth
information.You basically need to add these lines in your DNS server.
pc24.smallminingco.com A
xxx.xxx.xxx.xxx ; Workstation ip MX 10
smtp.smallminingco.com ; Your mailhostYou cannot do this yourself unless you are running a DNS
server. If you do not want to run a DNS server, get somebody else
like your Internet Provider to do it.This will redirect mail for the workstation to the Mail
eXchange host. It does not matter what machine the A record
points to, the mail will be sent to the MX host.This feature is used to implement Virtual E-Mail Hosting.
ExampleI have a customer with domain foo.bar and I want all mail for
foo.bar to be sent to my machine smtp.smalliap.com. You must make
an entry in your DNS server like: foo.bar
MX 10 smtp.smalliap.com ; your
mailhost The A record is not needed if you only
want E-Mail for the domain. IE: Don't expect ping foo.bar
to work unless an Address record for foo.bar
exists as well.On the mailhost that actually accepts mail for final delivery
to a mailbox, sendmail must be told what hosts it will be
accepting mail for.Add pc24.smallminingco.com to /etc/sendmail.cw (if you are
using FEATURE(use_cw_file)), or add a "Cw myhost.smalliap.com"
line to /etc/sendmail.cfIf you plan on doing anything serious with sendmail you should install the sendmail
source. The source has plenty of documentation with it. You will
find information on getting sendmail
source from . Setting up UUCP.Stolen from the FAQ.The sendmail configuration that ships with FreeBSD is suited
for sites that connect directly to the Internet. Sites that wish
to exchange their mail via UUCP must install another sendmail
configuration file.Tweaking /etc/sendmail.cf manually is
considered something for purists. Sendmail version 8 comes with a
new approach of generating config files via some m4 preprocessing, where the actual
hand-crafted configuration is on a higher abstraction level. You
should use the configuration files under /usr/src/usr.sbin/sendmail/cfIf you did not install your system with full sources, the
sendmail config stuff has been broken out into a separate source
distribution tarball just for you. Assuming you have your CD-ROM
mounted, do: cd /usr/src tar -xvzf
/cdrom/dists/src/ssmailcf.aaDo not panic, this is only a few hundred kilobytes in size.
The file README in the cf directory can serve as a basic
introduction to m4 configuration.For UUCP delivery, you are best advised to use the
mailertable feature. This constitutes a
database that sendmail can use to base its routing decision
upon.First, you have to create your .mc file.
The directory
/usr/src/usr.sbin/sendmail/cf/cf is the home
of these files. Look around, there are already a few examples.
Assuming you have named your file foo.mc, all
you need to do in order to convert it into a valid
sendmail.cf is: cd /usr/src/usr.sbin/sendmail/cf/cf make
foo.cfIf you don't have a /usr/obj hiearchy,
then: cp foo.cf /etc/sendmail.cfOtherwise: cp /usr/obj/`pwd`/foo.cf
/etc/sendmail.cfA typical .mc file might look
like: include(`../m4/cf.m4') VERSIONID(`Your version
number') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify)
FEATURE(mailertable) define(`UUCP_RELAY', your.uucp.relay)
define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp)
MAILER(uucp) Cw your.alias.host.name Cw
youruucpnodename.UUCPThe nodns and
nocanonify features will prevent any usage of
the DNS during mail delivery. The UUCP_RELAY
clause is needed for bizarre reasons, do not ask. Simply put an
Internet hostname there that is able to handle .UUCP pseudo-domain
addresses; most likely, you will enter the mail relay of your ISP
there.Once you have this, you need this file called
/etc/mailertable. A typical example of this
gender again: # # makemap hash /etc/mailertable.db <
/etc/mailertable # horus.interface-business.de uucp-dom:horus
.interface-business.de uucp-dom:if-bus
interface-business.de uucp-dom:if-bus .heep.sax.de
smtp8:%1 horus.UUCP uucp-dom:horus
if-bus.UUCP uucp-dom:if-bus .
uucp-dom:saxAs you can see, this is part of a real-life file. The first
three lines handle special cases where domain-addressed mail
should not be sent out to the default route, but instead to some
UUCP neighbor in order to shortcut the delivery path. The
next line handles mail to the local Ethernet domain that can be
delivered using SMTP. Finally, the UUCP neighbors are mentioned
in the .UUCP pseudo-domain notation, to allow for a
uucp-neighbor!recipient override of the default rules. The
last line is always a single dot, matching everything else, with
UUCP delivery to a UUCP neighbor that serves as your universal
mail gateway to the world. All of the node names behind the
uucp-dom: keyword must be valid UUCP
neighbors, as you can verify using the command uuname.As a reminder that this file needs to be converted into a DBM
database file before being usable, the command line to accomplish
this is best placed as a comment at the top of the mailertable.
You always have to execute this command each time you change your
mailertable.Final hint: if you are uncertain whether some particular mail
routing would work, remember the option to
sendmail. It starts sendmail in address test
mode; simply enter 0, followed by the address
you wish to test for the mail routing. The last line tells you
the used internal mail agent, the destination host this agent will
be called with, and the (possibly translated) address. Leave this
mode by typing Control-D. j@uriah 191% sendmail -bt ADDRESS TEST MODE
(ruleset 3 NOT automatically invoked) Enter <ruleset>
<address> > 0 foo@interface-business.de rewrite:
ruleset 0 input: foo @ interface-business . de ... rewrite:
ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @
interface-business . de > > ^D j@uriah 192%
FAQMigration from FAQ.Why do I have to use the FQDN for hosts on my site?You will probably find that the host is actually in a
different domain; for example, if you are in foo.bar.edu and you
wish to reach a host called mumble in the bar.edu domain, you
will have to refer to it by the fully-qualified domain name,
mumble.bar.edu, instead of just mumble. Traditionally, this was allowed by BSD BIND resolvers. However
the current version of BIND that ships with
FreeBSD no longer provides default abbreviations for non-fully
qualified domain names other than the domain you are in. So an
unqualified host mumble must either
be found as mumble.foo.bar.edu, or
it will be searched for in the root domain.This is different from the previous behavior, where the search
continued across mumble.bar.edu,
and mumble.edu. Have a look at
RFC 1535 for why this was considered bad practice, or even a
security hole.As a good workaround, you can place the linesearch foo.bar.edu
bar.eduinstead of the previousdomain foo.bar.eduinto your /etc/resolv.conf. However,
make sure that the search order does not go beyond the boundary
between local and public administration, as RFC 1535 calls
it.Sendmail says <errorname>mail loops back to myself</errorname>This is answered in the sendmail FAQ as follows:-
* I am getting "Local configuration
error" messages, such as: 553 relay.domain.net config error:
mail loops back to myself 554 <user@domain.net>... Local
configuration error How can I solve this problem? You have asked
mail to the domain (e.g., domain.net) to be forwarded to a
specific host (in this case, relay.domain.net) by using an MX
record, but the relay machine does not recognize itself as
domain.net. Add domain.net to /etc/sendmail.cw (if you are
using FEATURE(use_cw_file)) or add "Cw domain.net" to
/etc/sendmail.cf. The sendmail FAQ is in
/usr/src/usr.sbin/sendmail and is recommended
reading if you want to do any tweaking of your mail
setup.How can I do E-Mail with a dialup PPP host?You want to connect a FreeBSD box on a lan, to the Internet.
The FreeBSD box will be a mail gateway for the lan. The PPP
connection is non-dedicated.There are at least two way to do this.The other is to use UUCP.The key is to get a Internet site to provide secondary MX
services for your domain. For example: bigco.com.
MX 10 bigco.com. MX 20
smalliap.com.Only one host should be specified as the final recipient ( add
Cw bigco.com in /etc/sendmail.cf on
bigco.com).When the senders sendmail is trying to deliver the mail it
will try to connect to you over the modem link. It will most
likely time out because you are not online. Sendmail will
automatically deliver it to the secondary MX site, ie your
Internet provider. The secondary MX site will try every
(sendmail_flags = "-bd -q15m" in
/etc/rc.conf ) 15 minutes to connect to your
host to deliver the mail to the primary MX site. You might wat to use something like this as a login script.
#!/bin/sh # Put me in /usr/local/bin/pppbigco (
sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct
pppbigco If you are going to create a separate
login script for a user you could use sendmail
-qRbigco.com instead in the script above. This will
force all mail in your queue for bigco.com to be processed
immediately.A further refinement of the situation is as follows.Message stolen from the freebsd-isp mailing list.
> we provide the secondary mx for a customer.
The customer connects to > our services several times a day
automatically to get the mails to > his primary mx (We do
not call his site when a mail for his domains > arrived).
Our sendmail sends the mailqueue every 30 minutes. At the >
moment he has to stay 30 minutes online to be sure that all mail
is > gone to the primary mx. > > Is there a command
that would initiate sendmail to send all the mails > now?
The user has not root-privileges on our machine of course. In
the 'privacy flags' section of sendmail.cf, there is a
definition Opgoaway,restrictqrun Remove restrictqrun to allow
non-root users to start the queue processing. You might also
like to rearrange the MXs. We are the 1st MX for our customers
like this, and we have defined: # If we are the best MX for a
host, try directly instead of generating # local config error.
OwTrue That way a remote site will deliver straight to you,
without trying the customer connection. You then send to your
customer. Only works for "hosts", so you need to get your
customer to name their mail machine "customer.com" as well as
"hostname.customer.com" in the DNS. Just put an A record in
the DNS for "customer.com".Advanced topicsThe Cutting Edge: FreeBSD-current and FreeBSD-stableFreeBSD 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.Staying Current with FreeBSDContributed by &a.jkh;.What is FreeBSD-current?FreeBSD-current is, quite literally, nothing more than a daily
snapshot of the working sources for FreeBSD. 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
FreeBSD-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
FreeBSD-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 FreeBSD-current?FreeBSD-current is made generally available for 3 primary
interest groups:
Members of the FreeBSD group who are actively working
on some part of the source tree and for whom keeping
`current' is an absolute requirement.
Members of the FreeBSD group who are active testers,
willing to spend time working through problems in order to
ensure that FreeBSD-current remains as sane as possible.
These are also people who wish to make topical suggestions
on changes and the general direction of FreeBSD.
Peripheral members of the FreeBSD (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 FreeBSD-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
FreeBSD-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 FreeBSD
if we were), it is literally because we cannot answer 400
messages a day and actually work on
FreeBSD! I am sure that, if given the choice between having
us answer lots of questions or continuing to improve
FreeBSD, most of you would vote for us improving it.Using FreeBSD-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 FreeBSD-current
mailing list 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 potentially critical information (e.g.
Yo, Everybody! Before you rebuild
/usr/src, you must
rebuild the kernel or your system will crash horribly!).
The cvs-all 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: subscribe
freebsd-current subscribe cvs-all In the
body of your message. 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 three ways:
Use the
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.
Use the
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 sources up-to-date automatically.
Use ftp. The source tree for FreeBSD-current is
always exported on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current We also use `wu-ftpd' which allows compressed/tar'd grabbing of whole trees. e.g. you see: usr.bin/lex You can do: ftp> cd usr.bin ftp> get lex.tar.Z And it will get the whole directory for you as a compressed tar file. 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.
If you are grabbing the sources to run, and not just
look at, then grab all of 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 current, read the Makefile in
/usr/src carefully. You should at
least run a 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 FreeBSD-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 FreeBSDContributed by &a.jkh;.What is FreeBSD-stable?FreeBSD-stable is our development branch for a more low-key
and conservative set of changes intended for our next mainstream
release. Changes of an experimental or untested nature do not go
into this branch (see ).Who needs FreeBSD-stable?If you are a commercial user or someone who puts maximum
stability of their FreeBSD system before all other concerns, you
should consider tracking stable. This is
especially true if you have installed the most recent release
(&rel.current;-RELEASE at the time of this writing) since the stable branch is effectively a bug-fix stream relative to the previous release.The stable tree endeavors, above all,
to be fully compilable and stable at all times, but we do
occasionally make mistakes (these are still active sources with
quickly-transmitted updates, after all). We also do our best to
thoroughly test fixes in current before
bringing them into stable, but sometimes
our tests fail to catch every case. If something breaks for you
in stable, please let us know
immediately! (see next section).Using FreeBSD-stable Join the &a.stable; . This will keep you informed of
build-dependencies that may appear in
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. To join this list, send mail to
&a.majordomo; and say: subscribe
freebsd-stable In the body of your
message. 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 three ways:
Use the
facility. Unless you have a good TCP/IP connection
at a flat rate, this is the way to do it.
Use the
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 sources up-to-date automatically.
Use ftp. The source tree for FreeBSD-stable is
always exported on: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stableWe also use `wu-ftpd' which allows
compressed/tar'd grabbing of whole trees. e.g. you
see:
usr.bin/lex You can do:
ftp> cd usr.bin ftp>
get lex.tar.Z And it will get the
whole directory for you as a compressed tar
file. 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.
Before compiling stable, read the Makefile in
/usr/src carefully. You should at
least run a 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 Source Trees over the InternetContributed by &a.jkh;.There are various ways of using an Internet (or email)
connection to stay up-to-date with any given area of the FreeBSD
project sources, or all areas, depending on what interests you. The
primary services we offer are CVSup and CTM.CVSup uses the
pull model of updating. 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.CTM, on the other hand, does not
interactively compare the sources you have with those on the master
archive. Instead, a script which identifies changes in files since
its previous run is executed several times a day on the master
archive, any detected changes being compressed, stamped with a
sequence-number and encoded for transmission over email (printable
ASCII only). Once received, these "CTM deltas" can then be handed
to the ctm_rmail1 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.For more information on CTM and CVSup, please see one of the
following sections:CTMContributed by &a.phk;. Updated
19-October-1997.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.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 .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 online.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/ctmThe deltas you feed CTM can be had
two ways, FTP or e-mail. If you have general FTP access to the
Internet then the following FTP sites support access to
CTM:ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTMor see section .FTP the relevant directory and fetch the
README file, starting from there.If you may 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-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.Starting off with <application>CTM</application> for the first
timeBefore you can start using CTM deltas,
you will need to get a 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. However, 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.Once you identify a suitable starting point, you must use an
initial transition delta to transform your starting point
into a CTM supported tree.You can recognize these transition 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, R225 would designate the 2.2.5 release,
etc. As a rule a base transition from Empty is producted
every 100 deltas. By the way, they are large! 25 to 30
Megabytes of gzip'ed 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 lifeTo apply the deltas, simply say:
cd /where/ever/you/want/the/stuff 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.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.I would also be very happy if somebody could help with the
user interface portions, as I have realized that I cannot
make up my mind on what options should do what, how and
when...That's 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 changesAs 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 behaviour 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 CTM optionsFinding out exactly what would be touched by an
updateYou 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 updatingSometimes 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 updateSometimes 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:
cd /where/ever/you/want/to/extract/it/ 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.The bad news is that I am very busy, so any help in doing
this will be most welcome. And do not forget to tell me what
you want also...Miscellaneous stuffAll the DES infected (e.g. export controlled) source is
not included. You will get the international version only.
If sufficient interest appears, we will set up a sec-cur sequence too. 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.Thanks!&a.bde;for his pointed pen and invaluable comments.&a.sos;for patience.Stephen McKaywrote ctm_[rs]mail,
much appreciated.&a.jkh;for being so stubborn that I had to make it
better.All the usersI hope you like it...CVSupContributed by &a.jdp;.IntroductionCVSup 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.InstallationThe easiest way to install CVSup if you are running FreeBSD
2.2 or later is to use either the port from the FreeBSD or the corresponding binary package, depending on whether you prefer to roll your own or not.If you are running FreeBSD-2.1.6 or 2.1.7, you unfortunately
cannot use the binary package versions due to the fact that it
requires a version of the C library that does not yet exist in
FreeBSD-2.1.{6,7}. You can easily use the port, however, just as with FreeBSD 2.2. Simply unpack the tar file, cd to the cvsup subdirectory and type make install.Because CVSup is written in Modula-3, both the package and the port require that the Modula-3 runtime libraries be installed. These are available as the lang/modula-3-lib port and the lang/modula-3-lib-3.6 package. If you follow the same directions as for cvsup, these libraries will be compiled and/or installed automatically when you install the CVSup port or package.The Modula-3 libraries are rather large, and fetching and
compiling them is not an instantaneous process. For that
reason, a third option is provided. You can get
statically linked FreeBSD executables for
CVSup from either the USA distribution site:ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup-bin-15.3.tar.gz (client including GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.3.tar.gz (client without GUI).ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/cvsupd-bin-15.3.tar.gz (server).or the German mirror:ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup-bin-15.3.tar.gz (client including GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsup.nogui-bin-15.3.tar.gz (client without GUI).ftp://ftp.cs.tu-berlin.de/pub/FreeBSD/CVSup/cvsupd-bin-15.3.tar.gz (server).Most users will need only the client. These executables are
entirely self-contained, and they will run on any version of
FreeBSD from FreeBSD-2.1.0 to FreeBSD-current.In summary, your options for installing CVSup are:FreeBSD-2.2 or later: static binary, port,
or packageFreeBSD-2.1.6, 2.1.7: static binary or
portFreeBSD-2.1.5 or earlier: static binaryConfigurationCVSup's operation is controlled by a configuration file
called the supfile. Beginning with
FreeBSD-2.2, there are some sample supfiles
in the directory /usr/share/examples/cvsup. These examples are also available from ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ if you are on a pre-2.2 system.The information in a supfile answers
the following questions for cvsup: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., or . A value field also begins
with a keyword, but the keyword is followed without intervening
white space by = and a second word. For example,
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 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 lines.With this background, we will now proceed to construct a
supfile for receiving and updating the main
source tree of .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 . In this example, we wish to receive the
entire main source tree for the FreeBSD system. There is
a single large collection which will give us all
of that, except the export-controlled cryptography
support. Let us assume for this example that we are in
the USA or Canada. Then we can get the cryptography code
with one additional collection, . As a first
step toward constructing our supfile,
we simply list these collections, one per line: src-all cvs-cryptoWhich 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 and value
fields.WARNING: Be very
careful to specify any 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 do not want deleted. In
particular, use only
tag=. for the
collections.The 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: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_2_2The line of development for FreeBSD-2.2.x,
also known as FreeBSD-stable. Not valid for the
ports-* collections.tag=RELENG_2_1_0The line of development for FreeBSD-2.1.x -
this branch is largely obsolete. Not valid for the
ports-* collections.Here are the revision tags that users might be
interested in:tag=RELENG_2_2_6_RELEASEFreeBSD-2.2.6. Not valid for the ports-*
collections.tag=RELENG_2_2_5_RELEASEFreeBSD-2.2.5. Not valid for the ports-*
collections.tag=RELENG_2_2_2_RELEASEFreeBSD-2.2.2. Not valid for the ports-*
collections.tag=RELENG_2_2_1_RELEASEFreeBSD-2.2.1. Not valid for the ports-*
collections.tag=RELENG_2_2_0_RELEASEFreeBSD-2.2.0. Not valid for the ports-*
collections.tag=RELENG_2_1_7_RELEASEFreeBSD-2.1.7. Not valid for the ports-*
collections.tag=RELENG_2_1_6_1_RELEASEFreeBSD-2.1.6.1. Not valid for the ports-*
collections.tag=RELENG_2_1_6_RELEASEFreeBSD-2.1.6. Not valid for the ports-*
collections.tag=RELENG_2_1_5_RELEASEFreeBSD-2.1.5. Not valid for the ports-*
collections.tag=RELENG_2_1_0_RELEASEFreeBSD-2.1.0. Not valid for the ports-*
collections.WARNING: 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 cvsup1 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 field nor a
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 field to tell cvsup where to obtain
its updates. Any of the will do, though you should try to select
one that's near to you. In this example, we'll use the
primary FreeBSD distribution site,
"cvsup.FreeBSD.org": *default
host=cvsup.FreeBSD.orgOn any particular run of cvsup, you can override this
setting on the command line, with .Where do you want to put them on your own
machine?The 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=/usrWhere should cvsup maintain its status files?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/cvsupThis 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 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. 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. is ... arcane. If you really want to
know about it, see the cvsup1 manual page. Otherwise,
just specify it and do not worry about it. 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=cvsup.FreeBSD.org *default prefix=/usr *default
base=/usr/local/etc/cvsup *default release=cvs delete
use-rel-suffix compress src-all
cvs-cryptoRunning CVSupYou are now ready to try an update. The command line for
doing this is quite simple: cvsup supfilewhere 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: mkdir /var/tmp/dest cvsup supfile
/var/tmp/destThe 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: cvsup -g -L 2 supfileThe 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 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 cron8. Obviously,
you should not let cvsup use its GUI when running it from
cron.CVSup File CollectionsThe 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, cvs-crypto, 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=cvsThe main FreeBSD CVS repository, excluding the
export-restricted cryptography code.distrib
release=cvsFiles related to the distribution and
mirroring of FreeBSD.doc-all
release=cvsSources for the FreeBSD handbook and other
documentation.ports-all
release=cvsThe FreeBSD ports collection.ports-archivers
release=cvsArchiving tools.ports-astro
release=cvsAstronomical ports.ports-audio
release=cvsSound support.ports-base
release=cvsMiscellaneous files at the top of
/usr/ports.ports-benchmarks
release=cvsBenchmarks.ports-biology
release=cvsBiology.ports-cad
release=cvsComputer aided design tools.ports-chinese
release=cvsChinese language support.ports-comms
release=cvsCommunication software.ports-converters
release=cvscharacter code converters.ports-databases
release=cvsDatabases.ports-devel
release=cvsDevelopment utilities.ports-editors
release=cvsEditors.ports-emulators
release=cvsEmulators for other operating
systems.ports-games
release=cvsGames.ports-german
release=cvsGerman language support.ports-graphics
release=cvsGraphics utilities.ports-japanese
release=cvsJapanese language support.ports-korean
release=cvsKorean language support.ports-lang
release=cvsProgramming languages.ports-mail
release=cvsMail software.ports-math
release=cvsNumerical computation
software.ports-mbone
release=cvsMBone applications.ports-misc
release=cvsMiscellaneous utilities.ports-net
release=cvsNetworking software.ports-news
release=cvsUSENET news software.ports-plan9
release=cvsVarious programs from Plan9.ports-print
release=cvsPrinting software.ports-russian
release=cvsRussian language support.ports-security
release=cvsSecurity utilities.ports-shells
release=cvsCommand line shells.ports-sysutils
release=cvsSystem utilities.ports-textproc
release=cvstext processing utilities (does not
include desktop publishing).ports-vietnamese
release=cvsVietnamese language support.ports-www
release=cvsSoftware related to the World Wide
Web.ports-x11
release=cvsX11 software.src-all
release=cvsThe main FreeBSD sources, excluding the
export-restricted cryptography code.src-base
release=cvsMiscellaneous files at the top of
/usr/src.src-bin
release=cvsUser utilities that may be needed in
single-user mode
(/usr/src/bin).src-contrib
release=cvsUtilities and libraries from outside
the FreeBSD project, used relatively
unmodified
(/usr/src/contrib).src-etc
release=cvsSystem configuration files
(/usr/src/etc).src-games
release=cvsGames
(/usr/src/games).src-gnu
release=cvsUtilities covered by the GNU Public
License
(/usr/src/gnu).src-include
release=cvsHeader files
(/usr/src/include).src-kerberosIV
release=cvsKerberosIV security package
(/usr/src/kerberosIV).src-lib
release=cvsLibraries
(/usr/src/lib).src-libexec
release=cvsSystem programs normally executed by
other programs
(/usr/src/libexec).src-release
release=cvsFiles required to produce a FreeBSD
release
(/usr/src/release).src-sbin
release=cvsSystem utilities for single-user
mode
(/usr/src/sbin).src-share
release=cvsFiles that can be shared across
multiple systems
(/usr/src/share).src-sys
release=cvsThe kernel
(/usr/src/sys).src-tools
release=cvsVarious tools for the maintenance of
FreeBSD
(/usr/src/tools).src-usrbin
release=cvsUser utilities
(/usr/src/usr.bin).src-usrsbin
release=cvsSystem utilities
(/usr/src/usr.sbin).www
release=cvsThe sources for the World Wide Web
data.cvs-crypto
release=cvsThe export-restricted cryptography code.src-crypto
release=cvsExport-restricted utilities and libraries
from outside the FreeBSD project, used
relatively unmodified
(/usr/src/crypto).src-eBones
release=cvsKerberos and DES
(/usr/src/eBones).src-secure
release=cvsDES
(/usr/src/secure).distrib
release=selfThe CVSup server's own configuration files. Used by
CVSup mirror sites.gnats
release=currentThe GNATS bug-tracking database.mail-archive
release=currentFreeBSD mailing list archive.www
release=currentThe installed World Wide Web data. Used by WWW
mirror sites.Announcements, Questions, and Bug ReportsMost 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.
Using <command>make world</command> to rebuild your
systemContributed by &a.nik;.Once you have synchronised your local source tree against a
particular version of FreeBSD (stable,
current and so on) you must then use
the source tree to rebuild the system.Currently, the best source of information on how to do that is a
tutorial available from http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html.A successor to this tutorial will be integrated into the
handbook.Contributing to FreeBSDContributed by &a.jkh;.So you want to contribute something to FreeBSD? That is great! We
can always use the help, and FreeBSD is one of those systems that
relies on the contributions of its user base in
order to survive. Your contributions are not only appreciated, they
are vital to FreeBSD's continued growth!Contrary to what some people might also have you believe, you do
not need to be a hot-shot programmer or a close personal friend of the
FreeBSD core team in order to have your contributions accepted. The
FreeBSD Project's development is done by a large and growing number of
international contributors whose ages and areas of technical expertise
vary greatly, and there is always more work to be done than there are
people available to do it.Since the FreeBSD project is responsible for an entire operating
system environment (and its installation) rather than just a kernel or
a few scattered utilities, our TODO list also spans a very wide
range of tasks, from documentation, beta testing and presentation to
highly specialized types of kernel development. No matter what your
skill level, there is almost certainly something you can do to help
the project!Commercial entities engaged in FreeBSD-related enterprises are
also encouraged to contact us. Need a special extension to make your
product work? You will find us receptive to your requests, given that
they are not too outlandish. Working on a value-added product?
Please let us know! We may be able to work cooperatively on some
aspect of it. The free software world is challenging a lot of
existing assumptions about how software is developed, sold, and
maintained throughout its life cycle, and we urge you to at least give
it a second look.What Is NeededThe following list of tasks and sub-projects represents
something of an amalgam of the various core team TODO lists and user
requests we have collected over the last couple of months. Where
possible, tasks have been ranked by degree of urgency. If you are
interested in working on one of the tasks you see here, send mail to
the coordinator listed by clicking on their names. If no
coordinator has been appointed, maybe you would like to
volunteer?High priority tasksThe following tasks are considered to be urgent, usually
because they represent something that is badly broken or sorely
needed:
3-stage boot issues. Overall coordination:
&a.hackers;Autodetect memory over 64MB properly.Move userconfig (-c) into 3rd stage boot.Do WinNT compatible drive tagging so that the 3rd
stage can provide an accurate mapping of BIOS
geometries for disks.Filesystem problems. Overall coordination: &a.fs;
Fix the MSDOS file system.Clean up and document the nullfs filesystem code.
Coordinator: &a.gibbs;Fix the union file system. Coordinator:
&a.dyson;Implement kernel and user vm86 support. Coordinator:
&a.hackers;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;SCSI driver issues. Overall coordination:
&a.hackers;Support tagged queuing generically. Requires a
rewrite of how we do our command queuing, but we need
this anyway to for prioritized I/O (CD-R
writers/scanners).Better error handling (Busy status and
retries).Merged Scatter-Gather list creation code.Kernel issues. Overall coordination: &a.hackers;Complete the eisaconf conversion of all existing
drivers.Change all interrupt routines to take a (void *)
instead of using unit numbers.Merge EISA/PCI/ISA interrupt registration
code.Split PCI/EISA/ISA probes out from drivers like
bt742a.c (WIP)Fix the syscons ALT-Fn/vt switching hangs.
Coordinator: &a.sos;Rewrite the Intel Etherexpress 16 driver.Merge the 3c509 and 3c590 drivers (essentially
provide a PCI probe for ep.c).Support Adaptec 3985 (first as a simple 3 channel
SCSI card) Coordinator: &a.gibbs;Support Advansys SCSI controller products.
Coordinator: &a.gibbs;Medium priority tasksThe following tasks need to be done, but not with any
particular urgency:
Port AFS (Andrew File System) to FreeBSD Coordinator:
Alexander Seth
JonesMCA support? This should be finalized one way or the
other.Full LKM based driver support/Configuration Manager.
Devise a way to do all LKM registration without
ld. This means some kind of symbol table in the
kernel.Write a configuration manager (in the 3rd stage
boot?) that probes your hardware in a sane manner,
keeps only the LKMs required for your hardware,
etc.PCMCIA/PCCARD. Coordinators: &a.nate; and &a.phk;
Documentation!Reliable operation of the pcic driver (needs
testing).Recognizer and handler for
sio.c (mostly done).Recognizer and handler for
ed.c (mostly done).Recognizer and handler for
ep.c (mostly done).User-mode recognizer and handler (partially
done).Advanced Power Management. Coordinators: &a.nate; and
&a.phk;
APM sub-driver (mostly done).IDE/ATA disk sub-driver (partially done).syscons/pcvt sub-driver.Integration with the PCMCIA/PCCARD drivers
(suspend/resume).Low priority tasksThe following tasks are purely cosmetic or represent such an
investment of work that it is not likely that anyone will get them
done anytime soon:The first 20 items are from Terry Lambert
<terry@lambert.org>
Ability to make BIOS calls from protected mode using V86
mode on the processor and return the results via a mapped
interrupt IPC mechanism to the protected mode caller.
Drivers built into the kernel that use the BIOS call
mechanism to allow them to be independent of the actual
underlying hardware the same way that DOS is independent of
the underlying hardware. This includes NetWork and ASPI
drivers loaded in DOS prior to BSD being loaded by a
DOS-based loader program, which means potential polling,
which means DOS-not-busy interrupt generation for V86
machines by the protected mode kernel.
An image format that allows tagging of such drivers data
and text areas in the default kernel executable so that that
portion of the kernel address space may be recovered at a
later time, after hardware specific protected mode drivers
have been loaded and activated. This includes separation of
BIOS based drivers from each other, since it is better to
run with a BIOS based driver in all cases than to not run at
all.
Abstraction of the bus interface mechanism. Currently,
PCMCIA, EISA, and PCI busses are assumed to be bridged from
ISA. This is not something which should be assumed.
A configuration manager that knows about PNP events,
including power management events, insertion, extraction,
and bus (PNP ISA and PCMCIA bridging chips) vs. card level
event management.
A topological sort mechanism for assigning reassignable
addresses that do not collide with other reassignable and
non-reassignable device space resource usage by fixed
devices.
A registration based mechanism for hardware services
registration. Specifically, a device centric registration
mechanism for timer and sound and other system critical
service providers. Consider Timer2 and Timer0 and speaker
services as one example of a single monolithic service
provider.
A kernel exported symbol space in the kernel data space
accessible by an LKM loader mechanism that does relocation
and symbol space manipulation. The intent of this interface
is to support the ability to demand load and unload kernel
modules.
NetWare Server (protected mode ODI driver) loader and
subservices to allow the use of ODI card drivers supplied
with network cards. The same thing for NDIS drivers and
NetWare SCSI drivers.
An "upgrade system" option that works on Linux boxes
instead of just previous rev FreeBSD boxes.
Splitting of the console driver into abstraction layers,
both to make it easier to port and to kill the X and
ThinkPad and PS/2 mouse and LED and console switching and
bouncing NumLock problems once and for all.
Other kernel emulation environments for other foreign
drivers as opportunity permits. SCO and Solaris are good
candidates, followed by UnixWare, etc.
Processor emulation environments for execution of
foreign binaries. This is easier than it sounds if the
system call interface does not change much.
Streams to allow the use of commercial streams drivers.
Kernel multithreading (requires kernel preemption).
Symmetric Multiprocessing with kernel preemption
(requires kernel preemption).
A concerted effort at support for portable computers.
This is somewhat handled by changing PCMCIA bridging rules
and power management event handling. But there are things
like detecting internal vs. external display and picking a
different screen resolution based on that fact, not spinning
down the disk if the machine is in dock, and allowing
dock-based cards to disappear without affecting the machines
ability to boot (same issue for PCMCIA).
Reorganization of the source tree for multiple platform
ports.
A make world that "makes the world" (rename the
current one to make regress if that is all it is good
for).
A 4M (preferably smaller!) memory footprint.
Smaller tasksMost of the tasks listed in the previous sections require
either a considerable investment of time or an in-depth knowledge
of the FreeBSD kernel (or both). However, there are also many
useful tasks which are suitable for "weekend hackers",
or people without programming skills.If you run FreeBSD-current and have a good Internet
connection, there is a machine current.freebsd.org which
builds a full release once a day - every now and again, try
and install the latest release from it and report any
failures in the process.
Read the freebsd-bugs mailing list. There might be a
problem you can comment constructively on or with patches
you can test. Or you could even try to fix one of the
problems yourself.
Read through the FAQ and Handbook periodically. If
anything is badly explained, out of date or even just
completely wrong, let us know. Even better, send us a fix
(SGML is not difficult to learn, but there is no objection
to ASCII submissions).
Help translate FreeBSD documentation into your native
language (if not already available) - just send an email to
&a.doc; asking if anyone is working on it. Note that you
are not committing yourself to translating every single
FreeBSD document by doing this - in fact, the documentation
most in need of translation is the installation
instructions.
Read the freebsd-questions mailing list and the
newsgroup comp.unix.bsd.freebsd.misc occasionally (or even
regularly). It can be very satisfying to share your
expertise and help people solve their problems; sometimes
you may even learn something new yourself! These forums can
also be a source of ideas for things to work on.
If you know of any bugfixes which have been successfully
applied to -current but have not been merged into -stable
after a decent interval (normally a couple of weeks), send
the committer a polite reminder.
Move contributed software to
src/contrib in the source tree.
Make sure code in src/contrib is up
to date.
Look for year 2000 bugs (and fix any you find!)
Build the source tree (or just part of it) with extra
warnings enabled and clean up the warnings.
Fix warnings for ports which do deprecated things like
using gets() or including malloc.h.
If you have contributed any ports, send your patches
back to the original author (this will make your life easier
when they bring out the next version)
Suggest further tasks for this list!
How to ContributeContributions to the system generally fall into one or more of
the following 6 categories:Bug reports and general commentary
An idea or suggestion of general
technical interest should be mailed to the &a.hackers;. Likewise,
people with an interest in such things (and a tolerance for a
high volume of mail!) may subscribe to the
hackers mailing list by sending mail to &a.majordomo;. See
for more
information about this and other mailing lists.If you find a bug or are submitting a specific change, please
report it using the send-pr1program or its
WEB-based
equivalent. Try to fill-in each field of the bug report.
Unless they exceed 65KB, include any patches directly in the
report. Consider compressing them and using
uuencode1 if they exceed 20KB.After filing a report, you should receive confirmation along
with a tracking number. Keep this tracking number so that you can
update us with details about the problem by sending mail to bug-followup@FreeBSD.ORG. Use the number as the message subject, e.g. "Re: kern/3377". Additional information for any bug report should be submitted this way.If you do not receive confirmation in a timely fashion (3 days
to a week, depending on your email connection) or are, for some
reason, unable to use the send-pr1 command,
then you may ask someone to file it for you by sending mail to the
&a.bugs;.Changes to the documentationChanges to the documentation are overseen by the &a.doc;. Send
submissions and changes (even small ones are welcome!) using
send-pr as described in
.Changes to existing source codeAn addition or change to the existing source code is a
somewhat trickier affair and depends a lot on how far out of date
you are with the current state of the core FreeBSD development.
There is a special on-going release of FreeBSD known as
FreeBSD-current which is made available in a variety of ways
for the convenience of developers working actively on the system.
See for more information
about getting and using FreeBSD-current.Working from older sources unfortunately means that your
changes may sometimes be too obsolete or too divergent for easy
re-integration into FreeBSD. Chances of this can be minimized
somewhat by subscribing to the &a.announce; and the &a.current;
lists, where discussions on the current state of the system take
place.Assuming that you can manage to secure fairly up-to-date
sources to base your changes on, the next step is to produce a set
of diffs to send to the FreeBSD maintainers. This is done with
the diff1 command, with the `context diff'
form being preferred. For example:
diff -c oldfile newfile or
diff -c -r olddir newdir would generate such a set of context diffs for
the given source file or directory hierarchy. See the man page
for diff1 for more details.Once you have a set of diffs (which you may test with the
patch1 command), you should submit them for
inclusion with FreeBSD. Use the send-pr1
program as described in
. Do not just send the diffs to
the &a.hackers; or they will get lost! We greatly appreciate your
submission (this is a volunteer project!); because we are busy, we
may not be able to address it immediately, but it will remain in
the pr database until we do.If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a tar file and run the
uuencode1 program on it. Shar archives are
also welcome.If your change is of a potentially sensitive nature, e.g. you
are unsure of copyright issues governing its further distribution
or you are simply not ready to release it without a tighter review
first, then you should send it to &a.core; directly rather than
submitting it with send-pr1. The core
mailing list reaches a much smaller group of people who do much of
the day-to-day work on FreeBSD. Note that this group is also
very busy and so you should only send mail to
them where it is truly necessary.Please refer to man 9 intro and
man 9 style for some information on
coding style. We would appreciate it if you were at least aware
of this information before submitting code.New code or major value-added packagesIn the rare case of a significant contribution of a large body
work, or the addition of an important new feature to FreeBSD, it
becomes almost always necessary to either send changes as
uuencode'd tar files or upload them to our ftp site ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming.When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights for
code included in FreeBSD are:The BSD copyright. This copyright is most preferred due
to its no strings attached nature and general
attractiveness to commercial enterprises. Far from
discouraging such commercial use, the FreeBSD Project
actively encourages such participation by commercial
interests who might eventually be inclined to invest
something of their own into FreeBSD.
The GNU Public License, or GPL. This license is not
quite as popular with us due to the amount of extra effort
demanded of anyone using the code for commercial purposes,
but given the sheer quantity of GPL'd code we currently
require (compiler, assembler, text formatter, etc) it would
be silly to refuse additional contributions under this
license. Code under the GPL also goes into a different part
of the tree, that being /sys/gnu or
/usr/src/gnu, and is therefore easily
identifiable to anyone for whom the GPL presents a
problem.Contributions coming under any other type of copyright must be
carefully reviewed before their inclusion into FreeBSD will be
considered. Contributions for which particularly restrictive
commercial copyrights apply are generally rejected, though the
authors are always encouraged to make such changes available
through their own channels.To place a BSD-style copyright on your work, include the
following text at the very beginning of every source code file you
wish to protect, replacing the text between the %% with the appropriate information.
Copyright (c) %%proper_years_here%% %%your_name_here%%,
%%your_state%% %%your_zip%%. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met: 1. Redistributions of source
code must retain the above copyright notice, this list of
conditions and the following disclaimer as the first lines of
this file unmodified. 2. Redistributions in binary form must
reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other
materials provided with the distribution. THIS SOFTWARE IS
PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%your_name_here%%
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
$Id$ For your convenience, a copy of this text can
be found in
/usr/share/examples/etc/bsd-style-copyright.Porting an existing piece of free softwareContributed by &a.jkh;, &a.gpalmer;, &a.asami; and
&a.obrien;.28 August 1996.The porting of freely available software, while perhaps not as
gratifying as developing your own from scratch, is still a vital
part of FreeBSD's growth and of great usefulness to those who
would not otherwise know where to turn for it. All ported
software is organized into a carefully organized hierarchy known
as the ports collection. The collection enables a new user to
get a quick and complete overview of what is available for FreeBSD
in an easy-to-compile form. It also saves considerable space by
not actually containing the majority of the sources being ported,
but merely those differences required for running under FreeBSD.
What follows are some guidelines for creating a new port for
FreeBSD 3.x. The bulk of the work is done by
/usr/share/mk/bsd.port.mk, which all port
Makefiles include. Please refer to that file for more details on
the inner workings of the ports collection. Even if you don't
hack Makefiles daily, it is well commented, and you will still
gain much knowledge from it.Before Starting the PortOnly a fraction of the overridable variables
(${..}) are mentioned in
this document. Most (if not all) are documented at the start
of bsd.port.mk. This file uses a
non-standard tab setting. Emacs and
Vim should recognize the setting on loading
the file. vi or ex can
be set to using the correct value by typing :set
tabstop=4 once the file has been loaded.You may come across code that needs modifications or
conditional compilation based upon what version of UNIX it is
running under. If you need to make such changes to the code for
conditional compilation, make sure you make the changes as
general as possible so that we can back-port code to FreeBSD 1.x
systems and cross-port to other BSD systems such as 4.4BSD from
CSRG, BSD/386, 386BSD, NetBSD, and OpenBSD.The preferred way to tell 4.3BSD/Reno (1990) and newer
versions of the BSD code apart is by using the
BSD macro defined in
<sys/param.h>. Hopefully that file
is already included; if not, add the code:#ifdef (defined(__unix__) || defined(unix)) &&
!defined(USG) #include <sys/param.h> #endifto the proper place in the .c file. We
believe that every system that defines these to symbols has
sys/param.h. If you find a system that
doesn't, we would like to know. Please send mail to
&a.ports;.Another way is to use the GNU Autoconf style of doing
this:#ifdef HAVE_SYS_PARAM_H #include <sys/param.h>
#endifDon't forget to add -DHAVE_SYS_PARAM_H to
the CFLAGS in the Makefile for this
method.Once you have sys/param.h
included, you may use:#if (defined(BSD) && (BSD >=
199103))to detect if the code is being compiled on a 4.3 Net2 code
base or newer (e.g. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD,
BSD/386 1.1 and below).Use:#if (defined(BSD) && (BSD >=
199306))to detect if the code is being compiled on a 4.4 code base
or newer (e.g. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 or
above).The value of the BSD macro is 199506 for the 4.4BSD-Lite2
code base. This is stated for informational purposes only. It
should not be used to distinguish between version of FreeBSD
based only on 4.4-Lite vs. versions that have merged in changes
from 4.4-Lite2. The __FreeBSD__ macro should be used
instead.Use sparingly:__FreeBSD__ is defined in all
versions of FreeBSD. Use it if the change you are making
ONLY affects FreeBSD. Porting gotchas like the use of
sys_errlist[] vs
strerror() are Berkeleyisms, not
FreeBSD changes.
In FreeBSD 2.x, __FreeBSD__ is
defined to be 2. In earlier
versions, it is 1. Later
versions will bump it to match their major version number.
If you need to tell the difference between a FreeBSD
1.x system and a FreeBSD 2.x or 3.x system, usually the
right answer is to use the BSD macros
described above. If there actually is a FreeBSD specific
change (such as special shared library options when using
ld) then it is OK to use
__FreeBSD__ and #if
__FreeBSD__ > 1 to detect a FreeBSD 2.x
and later system. If you need more granularity in
detecting FreeBSD systems since 2.0-RELEASE you can use
the following:
#if __FreeBSD__ >= 2 #include
<osreldate.h> # if __FreeBSD_version >=
199504 /* 2.0.5+ release specific code here */ #
endif #endif__FreeBSD_version
values:
2.0-RELEASE: 199411
2.1-current's: 199501, 199503
2.0.5-RELEASE: 199504
2.2-current before 2.1: 199508
2.1.0-RELEASE: 199511
2.2-current before 2.1.5: 199512
2.1.5-RELEASE: 199607
2.2-current before 2.1.6: 199608
2.1.6-RELEASE: 199612
2.1.7-RELEASE: 199612
2.2-RELEASE: 220000
2.2.1-RELEASE: 220000 (yes,
no change) 2.2-STABLE after 2.2.1-RELEASE: 220000
(yes, still no change) 2.2-STABLE after texinfo-3.9:
221001 2.2-STABLE after top: 221002
2.2.2-RELEASE: 222000
2.2-STABLE after 2.2.2-RELEASE: 222001
2.2.5-RELEASE: 225000
2.2-STABLE after 2.2.5-RELEASE: 225001
2.2-STABLE after ldconfig -R merge: 225002
2.2.6-RELEASE: 226000
2.2-STABLE after 2.2.6-RELEASE: 226001
3.0-current before mount(2) change: 300000
3.0-current as of Nov 1997:
300001Note that 2.2-STABLE sometimes identifies itself as
2.2.5-STABLE after the 2.2.5-RELEASE. The pattern used to
be year followed by the month, but we decided to change it
to a more straightforward major/minor system starting from
2.2. This is because the parallel development on several
branches made it infeasible to classify the releases simply
by their real release dates. If you are making a port now,
you don't have to worry about old -current's; they are
listed here just for your reference.In the hundreds of ports that have been done, there have
only been one or two cases where __FreeBSD__
should have been used. Just because an earlier port screwed up
and used it in the wrong place does not mean you should do so
too.Quick PortingThis section tells you how to do a quick port. In many
cases, it is not enough, but we will see.First, get the original tarball and put it into ${DISTDIR}, which defaults to
/usr/ports/distfiles.The following assumes that the software compiled
out-of-the-box, i.e., there was absolutely no change required
for the port to work on your FreeBSD box. If you needed to
change something, you will have to refer to the next section
too.Writing the <filename>Makefile</filename>The minimal Makefile would
look something like this: # New ports collection makefile for: oneko #
Version required: 1.1b # Date created: 5 December
1994 # Whom: asami # # $Id$ #
DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES=
ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/
MAINTAINER= asami@FreeBSD.ORG USE_IMAKE= yes .include
<bsd.port.mk>See if you can figure it out. Do not worry about the
contents of the $Id$
line, it will be filled in automatically by CVS when the port
is imported to our main ports tree. You can find a more
detailed example in the
section.Writing the description filesThere are three required description files that are
required for any port, whether they actually package or not.
They are COMMENT,
DESCR, and PLIST,
and reside in the pkg
subdirectory.<filename>COMMENT</filename>This is the one-line description of the port.
PLEASE do not include the package name (or version
number of the software) in the comment. Here is
an example:
A cat chasing a mouse all over the
screen.<filename>DESCR</filename>This is a longer description of the port. One to a few
paragraphs concisely explaining what the port does is
sufficient.This is not a manual nor an
in-depth description on how to use or compile the port. In
particular, please do not just copy the
README file here, unless,
of course, it is a concise description of the port.It is recommended that you sign the name at the end of
this file, as in:This is a port of oneko, in which a cat chases a
poor mouse all over the screen. : (etc.) - Satoshi
asami@cs.berkeley.edu<filename>PLIST</filename>This file lists all the files installed by the port. It
is also called the `packing list' because the package is
generated by packing the files listed here. The pathnames
are relative to the installation prefix (usually
/usr/local or
/usr/X11R6). Also it is assumed the
manpages will be compressed.Here is a small example:bin/oneko man/man1/oneko.1.gz
lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpmRefer to the pkg_create1 man page
for details on the packing list.Creating the checksum fileJust type make makesum.
The ports make rules will automatically generate the file
files/md5.Testing the portYou should make sure that the port rules do exactly what
you want it to do, including packaging up the port. Try doing
make install, make package and then make deinstall and see if all the files
and directories are correctly deleted. Then do a pkg_add `make package-name`.tgz and see
if everything re-appears and works correctly. Then do another
make deinstall and then
make reinstall; make package
to make sure you haven't included in the packing list any
files that are not installed by your port.Submitting the portNow that you are happy with your port, the only thing
remaining is to put it in the main FreeBSD ports tree and make
everybody else happy about it too. To accomplish this, pack
the necessary files (everything described in this section --
in particular do not include the original
source tarball, the work
subdirectory or the package) into a
.tar.gz file, stick it in the directory
ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming/ and send mail to us using
send-pr1 (please classify it as category
`ports' and class `change-request'). There is no need to
upload the package, we will build it by ourselves. We will
take a look, get back to you if necessary, and put it in the
tree. Your name will also appear in the list of `Additional
FreeBSD contributors' on the FreeBSD Handbook and other files.
Isn't that great?!? :)Slow PortingOk, so it was not that simple, and the port required some
modifications to get it to work. In this section, we will
explain, step by step, how to modify it to get it to work with
the ports paradigm.How things workFirst, this is the sequence of events which occurs when
the user first types make in
your port's directory, and you may find that having
bsd.port.mk in another window while you
read this really helps to understand it.But do not worry if you do not really understand what
bsd.port.mk is doing, not many people
do... :>The fetch target is run. The fetch target is
responsible for making sure that the tarball exists
locally in ${DISTDIR}.
If fetch cannot find the required files in ${DISTDIR} it will look up the
URL ${MASTER_SITES},
which is set in the Makefile, as well as our main ftp
site at ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/, where we put sanctioned distfiles as backup. It will then attempt to fetch the named distribution file with ${FETCH}, assuming that the requesting site has direct access to the Internet. If that succeeds, it will save the file in ${DISTDIR} for future use and proceed.
The extract target is run. It looks for your ports'
distribution file in ${DISTDIR} (typically a gzip'd
tarball) and unpacks it into a temporary subdirectory
specified by ${WRKDIR}
(defaults to work).
The patch target is run. First, any patches defined
in ${PATCHFILES} are
applied. Second, if any patches are found in ${PATCHDIR} (defaults to the
patches subdirectory), they are
applied at this time in alphabetical order.
The configure target is run. This can do any one of
many different things.
If it exists,
scripts/configure is run.
If ${HAS_CONFIGURE} or
${GNU_CONFIGURE}
is set,
${WRKSRC}/configure is
run.
If ${USE_IMAKE} is set,
${XMKMF}
(default: xmkmf
-a) is run.
The build target is run. This is responsible for
descending into the ports' private working directory
(${WRKSRC}) and
building it. If ${USE_GMAKE} is set, GNU
make will be used,
otherwise the system make
will be used.
The above are the default actions. In addition, you can
define targets pre-<something> or post-<something>, or put scripts
with those names, in the scripts
subdirectory, and they will be run before or after the default
actions are done.For example, if you have a post-extract target defined in your
Makefile, and a file pre-build in the
scripts subdirectory, the
post-extract target will be
called after the regular extraction actions, and the
pre-build script will be executed before
the default build rules are done. It is recommended that you
use Makefile targets if the actions are
simple enough, because it will be easier for someone to figure
out what kind of non-default action the port requires.The default actions are done by the
bsd.port.mk targets do-<something>. For example, the
commands to extract a port are in the target do-extract. If you are not happy with
the default target, you can fix it by redefining the
do-<something> target in
your Makefile.The `main' targets (e.g., extract, configure, etc.) do nothing more than
make sure all the stages up to that one is completed and
call the real targets or scripts, and they are not intended
to be changed. If you want to fix the extraction, fix
do-extract, but never ever
touch extract!Now that you understand what goes on when the user types
make, let us go through the
recommended steps to create the perfect port.Getting the original sourcesGet the original sources (normally) as a compressed
tarball (<foo>.tar.gz or
<foo>.tar.Z) and copy it into
${DISTDIR}. Always use
mainstream sources when and where you
can.If you cannot find a ftp/http site that is well-connected
to the net, or can only find sites that have irritatingly
non-standard formats, we can `house' it ourselves by putting
it on
ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/ as the last resort. Please refer to this
location as ${MASTER_SITE_LOCAL}. Send mail to
the &a.ports;if you are not sure what to do.If your port requires some additional `patches' that are
available on the Internet, fetch them too and put them in
${DISTDIR}. Do not worry if
they come from site other than where you got the main source
tarball, we have a way to handle these situations (see the
description of below).Modifying the portUnpack a copy of the tarball in a private directory and
make whatever changes are necessary to get the port to compile
properly under the current version of FreeBSD. Keep
careful track of everything you do, as
you will be automating the process shortly. Everything,
including the deletion, addition or modification of files
should be doable using an automated script or patch file when
your port is finished.If your port requires significant user
interaction/customization to compile or install, you should
take a look at one of Larry Wall's classic Configure scripts
and perhaps do something similar yourself. The goal of the
new ports collection is to make each port as `plug-and-play'
as possible for the end-user while using a minimum of disk
space.Unless explicitly stated, patch files, scripts, and
other files you have created and contributed to the FreeBSD
ports collection are assumed to be covered by the standard
BSD copyright conditions.PatchingIn the preparation of the port, files that have been added
or changed can be picked up with a recursive diff for later
feeding to patch. Each set of patches you wish to apply
should be collected into a file named
patch-<xx> where
<xx> denotes the sequence in which
the patches will be applied -- these are done in
alphabetical order, thus aa first, ab second and so on. These files
should be stored in ${PATCHDIR}, from where they will be
automatically applied. All patches should be relative to
${WRKSRC} (generally the
directory your port's tarball unpacks itself into, that being
where the build is done). To make fixes and upgrades easier
you should avoid having more than one patch fix the same file
(e.g., patch-aa and patch-ab both changing ${WRKSRC}/foobar.c).ConfiguringInclude any additional customization commands to your
configure script and save it in the
scripts subdirectory. As mentioned
above, you can also do this as Makefile
targets and/or scripts with the name
pre-configure or
post-configure.Handling user inputIf your port requires user input to build, configure or
install, then set IS_INTERACTIVE in your
Makefile. This will allow `overnight builds' to skip your port
if the user sets the variable BATCH in his
environment (and if the user sets the variable
INTERACTIVE, then only
those ports requiring interaction are built).Configuring the MakefileConfiguring the Makefile is pretty simple, and again we
suggest that you look at existing examples before starting.
Also, there is a in this handbook, so take a look and please follow
the ordering of variables and sections in that template to make
your port easier for others to read.Now, consider the following problems in sequence as you
design your new Makefile:The original sourceDoes it live in ${DISTDIR} as a standard gzip'd
tarball? If so, you can go on to the next step. If not, you
should look at overriding any of the ${EXTRACT_CMD}, ${EXTRACT_BEFORE_ARGS}, ${EXTRACT_AFTER_ARGS}, ${EXTRACT_SUFX}, or ${DISTFILES} variables, depending on
how alien a format your port's distribution file is. (The
most common case is EXTRACT_SUFX=.tar.Z,
when the tarball is condensed by regular compress, not
gzip.)In the worst case, you can simply create your own
do-extract target to override
the default, though this should be rarely, if ever,
necessary.DISTNAMEYou should set ${DISTNAME} to be the base name of
your port. The default rules expect the distribution file
list (${DISTFILES}) to be
named ${DISTNAME}${EXTRACT_SUFX} by
default which, if it is a normal tarball, is going to be
something like:
foozolix-1.0.tar.gz for a setting of
DISTNAME=foozolix-1.0.The default rules also expect the tarball(s) to extract
into a subdirectory called
work/${DISTNAME}, e.g.
work/foozolix-1.0/All this behavior can be overridden, of course, it simply
represents the most common time-saving defaults. For a port
requiring multiple distribution files, simply set ${DISTFILES} explicitly. If only a
subset of ${DISTFILES} are
actual extractable archives, then set them up in ${EXTRACT_ONLY}, which will override
the ${DISTFILES} list when
it comes to extraction, and the rest will be just left in
${DISTDIR} for later
use.CATEGORIESWhen a package is created, it is put under
/usr/ports/packages/All and links are
made from one or more subdirectories of
/usr/ports/packages. The names of these
subdirectories are specified by the variable ${CATEGORIES}. It is intended to
make life easier for the user when he is wading through the
pile of packages on the ftp site or the CD-ROM. Please take a
look at the existing categories (you can find them in the ports
page) and pick the ones that are suitable for your
port. If your port truly belongs to something that is
different from all the existing ones, you can even create a
new category name.MASTER_SITESRecord the directory part of the ftp/http-URL pointing at
the original tarball in ${MASTER_SITES}. Do not forget the
trailing slash (/)!The make macros will try to use this specification for
grabbing the distribution file with ${FETCH} if they cannot find it
already on the system.It is recommended that you put multiple sites on this
list, preferably from different continents. This will
safeguard against wide-area network problems, and we are even
planning to add support for automatically determining the
closest master site and fetching from there!If the original tarball is part of one of the following
popular archives: X-contrib, GNU, Perl CPAN, TeX CTAN, or
Linux Sunsite, you refer to those sites in an easy compact
form using MASTER_SITE_XCONTRIB, MASTER_SITE_GNU,
MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, and
MASTER_SITE_SUNSITE. Simply set MASTER_SITE_SUBDIR to the
path with in the archive. Here is an example:
MASTER_SITES= ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR= applicationsThe user can also set the MASTER_SITE_* variables in
/etc/make.conf to override our choices,
and use their favorite mirrors of these popular archives
instead.PATCHFILESIf your port requires some additional patches that are
available by ftp or http, set ${PATCHFILES} to the names of the
files and ${PATCH_SITES} to
the URL of the directory that contains them (the format is the
same as ${MASTER_SITES}).If the patch is not relative to the top of the source tree
(i.e., ${WKRSRC}) because it
contains some extra pathnames, set ${PATCH_DIST_STRIP} accordingly.
For instance, if all the pathnames in the patch has an extra
foozolix-1.0/ in front of the
filenames, then set
PATCH_DIST_STRIP=-p1.Do not worry if the patches are compressed, they will be
decompressed automatically if the filenames end with
.gz or
.Z.If the patch is distributed with some other files, such as
documentation, in a gzip'd tarball, you can't just use
${PATCHFILES}. If that is
the case, add the name and the location of the patch tarball
to ${DISTFILES} and
${MASTER_SITES}. Then, from
the pre-patch target, apply the
patch either by running the patch command from there, or
copying the patch file into the ${PATCHDIR} directory and calling it
patch-<xx>.Note the tarball will have been extracted alongside the
regular source by then, so there is no need to explicitly
extract it if it is a regular gzip'd or compress'd tarball.
If you do the latter, take extra care not to overwrite
something that already exists in that directory. Also do
not forget to add a command to remove the copied patch in
the pre-clean target.MAINTAINERSet your mail-address here. Please. :)For detailed description of the responsibility of
maintainers, refer to section.DependenciesMany ports depend on other ports. There are five
variables that you can use to ensure that all the required
bits will be on the user's machine.LIB_DEPENDSThis variable specifies the shared libraries this port
depends on. It is a list of lib:dir pairs where
lib is the name of the shared library,
and dir is the directory in which to
find it in case it is not available. For example,
LIB_DEPENDS=
jpeg\\.6\\.:${PORTSDIR}/graphics/jpeg will check for a shared jpeg library with
major version 6, and descend into the
graphics/jpeg subdirectory of your
ports tree to build and install it if it is not
found.The lib part is just an argument
given to ldconfig -r | grep, so
periods should be escaped by two backslashes like in the
example above.The dependency is checked from within the extract target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.RUN_DEPENDSThis variable specifies executables or files this port
depends on during run-time. It is a list of path:dir pairs where
path is the name of the executable or
file, and dir is the directory in which
to find it in case it is not available. If
path starts with a slash
(/), it is treated as a file and its
existence is tested with test -e;
otherwise, it is assumed to be an executable, and
which -s is used to determine if the
program exists in the user's search path.For example,
RUN_DEPENDS=
${PREFIX}/etc/innd:${PORTSDIR}/news/inn \
wish:${PORTSDIR}/x11/tk will check if the file
/usr/local/etc/innd exists, and build
and install it from the news/inn
subdirectory of the ports tree if it is not found. It will
also see if an executable called wish is in your search path, and
descend into the x11/tk subdirectory of
your ports tree to build and install it if it is not
found.In this case, innd is actually an
executable; if an executable is in a place that is not
expected to be in a normal user's search path, you should
use the full pathname.The dependency is checked from within the install target. Also, the name of the
dependency is put in to the package so that
pkg_add will automatically install it if it
is not on the user's system.BUILD_DEPENDSThis variable specifies executables or files this port
requires to build. Like RUN_DEPENDS, it is
a list of path:dir pairs.
For example,
BUILD_DEPENDS=
unzip:${PORTSDIR}/archivers/unzip will check for an executable called
unzip, and descend into the
archivers/unzip subdirectory of your
ports tree to build and install it if it is not
found.`build' here means everything from extracting to
compilation. The dependency is checked from within the
extract target.FETCH_DEPENDSThis variable specifies executables or files this port
requires to fetch. Like the previous two, it is a list of
path:dir pairs. For
example,
FETCH_DEPENDS=
ncftp2:${PORTSDIR}/net/ncftp2 will check for an executable called
ncftp2, and descend into the
net/ncftp2 subdirectory of your ports
tree to build and install it if it is not found.The dependency is checked from within the fetch target.DEPENDSIf there is a dependency that does not fall into either
of the above four categories, or your port requires to have
the source of the other port extracted (i.e., having them
installed is not enough), then use this variable. This is
just a list of directories, as there is nothing to check,
unlike the previous four.Building mechanismsIf your package uses GNU make, set
USE_GMAKE=yes. If your package uses GNU
configure, set
GNU_CONFIGURE=yes. If you want to give
some extra arguments to GNU configure (other than the default
--prefix=${PREFIX}), set those extra
arguments in ${CONFIGURE_ARGS}.If your package is an X application that creates
Makefiles from
Imakefiles using imake, then set
USE_IMAKE=yes. This will cause the
configure stage to automatically do an xmkmf
-a. If the flag is a
problem for your port, set
XMKMF=xmkmf.If your port's source Makefile has
something else than all as the
main build target, set ${ALL_TARGET} accordingly. Same
goes for install and ${INSTALL_TARGET}.NO_INSTALL_MANPAGESIf the port uses imake but does not understand the
install.man target,
NO_INSTALL_MANPAGES=yes should be set.
In addition, the author of the original port should be shot.
:>Ports that require MotifThere are many programs that require a Motif library
(available from several commercial vendors, while there is (at
least) one effort to create a free clone) to compile. Since it
is a popular toolkit and their licenses usually permit
redistribution of statically linked binaries, we have made
special provisions for handling ports that require Motif in a
way that we can easily compile binaries linked either
dynamically or statically.REQUIRES_MOTIFIf your port requires Motif, define this variable in the
Makefile. This will prevent people who don't own a copy of
Motif from even attempting to build it.${MOTIFLIB}This variable will be set by
bsd.port.mk to be the appropriate
reference to the Motif library. Please patch the source to
use this wherever the Motif library is referenced in the
Makefile or Imakefile.There are two common cases:
If the port refers to the Motif library as
in its Makefile or Imakefile,
simply substitute ${MOTIFLIB} for it.
If the port uses XmClientLibs in its Imakefile,
change it to ${MOTIFLIB}
${XTOOLLIB} ${XLIB}.${MOTIFLIB} (usually)
expands to or
/usr/X11R6/lib/libXm.a, so there is
no need to add or
in front.Info filesThe new version of texinfo (included in 2.2.2-RELEASE and
onwards) contains a utility called install-info to add and delete entries to
the dir file. If your port installs any
info documents, please follow these instructions so your
port/package will correctly update the user's
${PREFIX}/info/dir file. (Sorry for
the length of this section, but it is imperative to weave all
the info files together. If done correctly, it will produce a
beautiful listing, so please bear with me!
:)First, this is what you (as a porter) need to know:% install-info --help install-info [OPTION]...
[INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info
directory file DIR-FILE. Options: --delete Delete
existing entries in INFO-FILE; don't insert any new entries.
: --entry=TEXT Insert TEXT as an Info directory entry.
: --section=SEC Put this file's entries in section SEC
of the directory. :This program will not actually
install info files; it merely inserts or
deletes entries in the dir file.Here's a seven-step procedure to convert ports to use
install-info. I will use
editors/emacs as an example.Look at the texinfo sources and make a patch to insert
@dircategory and @direntry
statements to files that don't have them. This is part of
my patch:
--- ./man/vip.texi.org Fri Jun 16 15:31:11
1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@
-2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP
+@dircategory The Emacs editor and associated tools
+@direntry +* VIP: (vip). A VI-emulation
for Emacs. +@end direntry @iftex @finalout :The format should be self-explanatory. Many authors
leave a dir file in the source tree
that contains all the entries you need, so look around
before you try to write your own. Also, make sure you
look into related ports and make the section names and
entry indentations consistent (we recommend that all entry
text start at the 4th tab stop).Note that you can put only one info entry per file
because of a bug in install-info
--delete that deletes only the first entry
if you specify multiple entries in the
@direntry section.You can give the dir
entries to install-info as
arguments ( and
) instead of patching the texinfo
sources. I do not think this is a good idea for ports
because you need to duplicate the same information in
three places
(Makefile and
@exec/@unexec of
PLIST; see below). However, if you
have a Japanese (or other multibyte encoding) info files,
you will have to use the extra arguments to install-info because makeinfo can't handle those texinfo
sources. (See Makefile and
PLIST of
japanese/skk for examples on how to
do this).Go back to the port directory and do a make clean; make and verify that
the info files are regenerated from the texinfo sources.
Since the texinfo sources are newer than the info files,
they should be rebuilt when you type make; but many
Makefiles don't include correct
dependencies for info files. In emacs' case, I had to
patch the main Makefile.in so it will
descend into the man
subdirectory to rebuild the info pages.
--- ./Makefile.in.org Mon Aug 19 21:12:19
1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@
-184,7 +184,7 @@ # Subdirectories to make recursively.
`lisp' is not included # because the compiled lisp
files are part of the distribution # and you cannot
remake them without installing Emacs first. -SUBDIR =
lib-src src +SUBDIR = lib-src src man # The makefiles
of the directories in $SUBDIR. SUBDIR_MAKEFILES =
lib-src/Makefile man/Makefile src/Makefile
oldXMenu/Makefile lwlib/Makefile ---
./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++
./man/Makefile.in Tue Apr 15 00:29:52 1997 @@
-66,6 +66,7 @@ ${srcdir}/gnu1.texi \
${srcdir}/glossary.texi +all: info info:
$(INFO_TARGETS) dvi: $(DVI_TARGETS)The second hunk was necessary because the default
target in the man subdir is called
info, while the main
Makefile wants to call all. I also deleted the installation
of the info info file
because we already have one with the same name in
/usr/share/info (that patch is not
shown here).If there is a place in the
Makefile that is installing the
dir file, delete it. Your
port may not be doing it. Also, remove any commands that
are otherwise mucking around with the
dir file.
--- ./Makefile.in.org Mon Aug 19 21:12:19
1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@
-368,14 +368,8 @@ if [ `(cd ${srcdir}/info &&
/bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ];
\ then \ (cd ${infodir}; \ - if [ -f dir ]; then
\ - if [ ! -f dir.old ]; then mv -f dir
dir.old; \ - else mv -f dir dir.bak; fi; \ -
fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir};
${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \
- (cd $${thisdir}; chmod a+r ${infodir}/dir);
\ for f in ccmode* cl* dired-x* ediff* emacs* forms*
gnus* info* message* mh-e* sc* vip*; do \ (cd
$${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f
${infodir}/$$f; \ chmod a+r ${infodir}/$$f);
\(This step is only necessary if you are modifying an
existing port.) Take a look at
pkg/PLIST and delete anything that is
trying to patch up info/dir. They
may be in pkg/INSTALL or some other
file, so search extensively.
Index: pkg/PLIST
=================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2Add a post-install
target to the Makefile to create a
dir file if it is not there. Also,
call install-info with the
installed info files.
Index: Makefile
=================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include <bsd.port.mk>Do not use anything other than
/usr/share/info/dir and the above
command to create a new info file. In fact, I'd add the
first three lines of the above patch to
bsd.port.mk if you (the porter)
wouldn't have to do it in PLIST by
yourself anyway.Edit PLIST and add equivalent
@exec statements and also
@unexec for pkg_delete.
You do not need to delete info/dir
with @unexec.
Index: pkg/PLIST
=================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-docThe @unexec install-info
--delete commands have to be listed before
the info files themselves so they can read the files.
Also, the @exec install-info commands
have to be after the info files and the
@exec command that creates the the
dir file.Test and admire your work. :) The sequence I recommend is:
make package,
pkg_delete, then
pkg_add. Check the dir file before and after each
step.Licensing ProblemsSome software packages have restrictive licenses or can be
in violation to the law (PKP's patent on public key crypto, ITAR
(export of crypto software) to name just two of them). What we
can do with them vary a lot, depending on the exact wordings of
the respective licenses.It is your responsibility as a porter to read the
licensing terms of the software and make sure that the FreeBSD
project will not be held accountable of violating them by
redistributing the source or compiled binaries either via ftp
or CD-ROM. If in doubt, please contact the &a.ports;.There are two variables you can set in the Makefile to
handle the situations that arise frequently:If the port has a `do not sell for profit' type of
license, set the variable NO_CDROM. We
will make sure such ports won't go into the CD-ROM come
release time. The distfile and package will still be
available via ftp.
If the resulting package needs to be built uniquely
for each site, or the resulting binary package can't be
distributed due to licensing; set the variable
NO_PACKAGE. We will make sure such
packages won't go on the ftp site, nor into the CD-ROM
come release time. The distfile will still be included on
both however.
If the port has legal restrictions on who can use it
(e.g., crypto stuff) or has a `no commercial use' license,
set the variable RESTRICTED to be the
string describing the reason why. For such ports, the
distfiles/packages will not be available even from our ftp
sites.The GNU General Public License (GPL), both version 1
and 2, should not be a problem for ports.If you are a committer, make sure you update the
ports/LEGAL file too.UpgradingWhen you notice that a port is out of date compared to the
latest version from the original authors, first make sure you
have the latest port. You can find them in the
ports-current directory of the ftp mirror
sites.The next step is to send a mail to the maintainer, if one is
listed in the port's Makefile. That person may already be
working on an upgrade, or have a reason to not upgrade the port
right now (because of, for example, stability problems of the
new version).If the maintainer asks you to do the upgrade or there isn't
any such person to begin with, please make the upgrade and send
the recursive diff (either unified or context diff is fine, but
port committers appear to prefer unified diff more) of the new
and old ports directories to us (i.e., if your modified ports
directory is called superedit
and the original as in our tree is
superedit.bak, then send us the result of
diff -ruN superedit.bak
superedit). Please examine the output to make
sure all the changes make sense. The best way to send us the
diff is by including it to send-pr1
(category `ports'). Please mention any added or deleted files
in the message, as they have to be explicitly specified to CVS
when doing a commit. If the diff is more than about 20KB, please
compress and uuencode it; otherwise, just include it in as is in
the PR.Do's and Dont'sHere is a list of common do's and dont's that you encounter
during the porting process.WRKDIRDo not leave anything valuable lying around in the
work subdirectory, make clean will
nuke it completely! If you need
auxiliary files that are not scripts or patches, put them in
the ${FILESDIR} subdirectory
(files by default) and use the
post-extract target to copy them
to the work subdirectory.Package informationDo include package information, i.e.
COMMENT, DESCR, and
PLIST, in pkg.Note that these files are not used only for packaging
anymore, and are mandatory now, even if
${NO_PACKAGE} is
set.Compress manpages, strip binariesDo compress manpages and strip binaries. If the original
source already strips the binary, fine; otherwise, you can add
a post-install rule to do it
yourself. Here is an example:
post-install: strip ${PREFIX}/bin/xdlUse the file command on the
installed executable to check whether the binary is stripped
or not. If it does not say `not stripped', it is
stripped.To automagically compress the manpages, use the MAN[1-9LN]
variables. They will check the variable
NOMANCOMPRESS that the user can set in
/etc/make.conf to disable man page
compression. Place them last in the section below the
MAINTAINER variable. Here is an example:
MAN1= foo.1 bar.1 MAN5= foo.conf.5 MAN8=
baz.8This is not usually necessary with ports that are X
applications and use Imake to build.If your port anchors its man tree somewhere other than
PREFIX, you can use the
MANPREFIX to set it. Also, if only manpages
in certain section go in a non-standard place, such as many
Perl modules ports, you can set individual man paths using
MANsectPREFIX
(where sect is one of 1-9, L or
N).INSTALL_* macrosDo use the macros provided in
bsd.port.mk to ensure correct modes and
ownership of files in your own *-install targets. They
are:${INSTALL_PROGRAM} is
a command to install binary executables.${INSTALL_SCRIPT} is a
command to install executable scripts.${INSTALL_DATA} is a
command to install sharable data.${INSTALL_MAN} is a
command to install manpages and other documentation (it
doesn't compress anything).These are basically the install command with all the appropriate
flags. See below for an example on how to use them.<filename>INSTALL</filename> package scriptIf your port needs execute commands when the binary
package is installed with pkg_add you can do with via the
pkg/INSTALL script. This script will
automatically be added to the package, and will be run twice
by pkg_add. The first time will as INSTALL ${PKGNAME} PRE-INSTALL and the
second time as INSTALL ${PKGNAME}
POST-INSTALL. $2 can be tested to determine which
mode the script is being run in. The
PKG_PREFIX environmental variable will be
set to the package installation directory. See man
pkg_add1 for additional
information.This script is not run automatically if you install the
port with make install. If you are
depending on it being run, you will have to explicitly call
it on your port's Makefile.<filename>REQ</filename> package scriptIf your port needs to determine if it should install or
not, you can create a pkg/REQrequirements script. It will be invoked automatically at
installation/deinstallation time to determine whether or not
installation/deinstallation should proceed. See man
pkg_create1 and man
pkg_add1 for more information.Install additional documentationIf your software has some documentation other than the
standard man and info pages that you think is useful for the
user, install it under
${PREFIX}/share/doc. This can be
done, like the previous item, in the post-install target.Create a new directory for your port. The directory name
should reflect what the port is. This usually means ${PKGNAME} minus the version part.
However, if you think the user might want different versions
of the port to be installed at the same time, you can use the
whole ${PKGNAME}.Make the installation dependent to the variable
NOPORTDOCS so that users can disable it in
/etc/make.conf, like this:
post-install: .if !defined(NOPORTDOCS) ${MKDIR}
${PREFIX}/share/doc/xv ${INSTALL_MAN}
${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv
.endifDo not forget to add them to
pkg/PLIST too! (Do not worry about
NOPORTDOCS here; there is currently no way
for the packages to read variables from
/etc/make.conf.)If you need to display a message to the installer, you may
place the message in pkg/MESSAGE. This
capibility is often useful to display additional installation
steps to be taken after a pkg_add, or to display licensing
information.MESSAGE does not need to be added
to pkg/PLIST).DIST_SUBDIRDo not let your port clutter
/usr/ports/distfiles. If your port
requires a lot of files to be fetched, or contains a file that
has a name that might conflict with other ports (e.g.,
`Makefile'), set ${DIST_SUBDIR} to the name of the
port (${PKGNAME} without the
version part should work fine). This will change ${DISTDIR} from the default
/usr/ports/distfiles to
/usr/ports/distfiles/${DIST_SUBDIR},
and in effect puts everything that is required for your port
into that subdirectory.It will also look at the subdirectory with the same name
on the backup master site at
ftp.freebsd.org. (Setting ${DISTDIR} explicitly in your
Makefile will not accomplish this, so please use ${DIST_SUBDIR}.)This does not affect the ${MASTER_SITES} you define in your
Makefile.FeedbackDo send applicable changes/patches to the original
author/maintainer for inclusion in next release of the code.
This will only make your job that much easier for the next
release.RCS stringsDo not put RCS strings in patches. CVS will mangle them
when we put the files into the ports tree, and when we check
them out again, they will come out different and the patch
will fail. RCS strings are surrounded by dollar ($) signs, and typically start with
$Id or $RCS.Recursive diffUsing the recurse () option to
diff to generate patches is
fine, but please take a look at the resulting patches to make
sure you don't have any unnecessary junk in there. In
particular, diffs between two backup files, Makefiles when the
port uses Imake or GNU configure, etc., are unnecessary and
should be deleted. Also, if you had to delete a file, then you
can do it in the post-extract
target rather than as part of the patch. Once you are happy
with the resuling diff, please split it up into one source
file per patch file.PREFIXDo try to make your port install relative to ${PREFIX}. (The value of this
variable will be set to ${LOCALBASE} (default
/usr/local), unless ${USE_IMAKE} or ${USE_X11} is set, in which case it
will be ${X11BASE} (default
/usr/X11R6).)Not hard-coding /usr/local or
/usr/X11R6 anywhere in the source will
make the port much more flexible and able to cater to the
needs of other sites. For X ports that use imake, this is
automatic; otherwise, this can often be done by simply
replacing the occurrences of /usr/local
(or /usr/X11R6 for X ports that do not
use imake) in the various scripts/Makefiles in the port to
read ${PREFIX}, as this
variable is automatically passed down to every stage of the
build and install processes.The variable ${PREFIX}
can be reassigned in your Makefile or in the user's
environment. However, it is strongly discouraged for
individual ports to set this variable explicitly in the
Makefiles. (If your port is an X port but does not use imake,
set USE_X11=yes; this is quite different
from setting PREFIX=/usr/X11R6.)Also, refer to programs/files from other ports with the
variables mentioned above, not explicit pathnames. For
instance, if your port requires a macro
PAGER to be the full pathname of less, use the compiler flag:
-DPAGER=\"${PREFIX}/bin/less\" or -DPAGER=\"${LOCALBASE}/bin/less\" if this is an X port, instead of -DPAGER=\"/usr/local/bin/less\". This way it will have a better chance of working if the system administrator has moved the whole `/usr/local' tree somewhere else.SubdirectoriesTry to let the port put things in the right subdirectories
of ${PREFIX}. Some ports
lump everything and put it in the subdirectory with the port's
name, which is incorrect. Also, many ports put everything
except binaries, header files and manual pages in the a
subdirectory of lib, which does not
bode well with the BSD paradigm. Many of the files should be
moved to one of the following: etc
(setup/configuration files), libexec
(executables started internally), sbin
(executables for superusers/managers),
info (documentation for info browser)
or share (architecture independent
files). See man hier7 for
details, the rule governing /usr pretty
much applies to /usr/local too. The
exception are ports dealing with USENET `news'. They may use
${PREFIX}/news as a destination for
their files.ldconfigIf your port installs a shared library, add a post-install target to your Makefile
that runs /sbin/ldconfig -m on
the directory where the new library is installed (usually
${PREFIX}/lib) to register it into
the shared library cache.Also, add an @exec line to your
pkg/PLIST file so that a user who
installed the package can start using the shared library
immediately. This line should immediately follow the line
for the shared library itself, as in:
lib/libtcl80.so.1.0 @exec /sbin/ldconfig -m
%D/libNever, ever, ever add a line that
says ldconfig without any
arguments to your Makefile or pkg/PLIST. This will reset the
shared library cache to the contents of
/usr/lib only, and will royally screw up
the user's machine (Help, xinit does not run anymore after I
install this port!). Anybody who does this will be shot and
cut into 65,536 pieces by a rusty knife and have his liver
chopped out by a bunch of crows and will eternally rot to
death in the deepest bowels of hell (not necessarily in that
order)....UIDsIf your port requires a certain user ID to be on the
installed system, let the pkg/INSTALL
script call pw to create it
automatically. Look at japanese/Wnn or
net/cvsup-mirror for examples. It is
customary to use UIDs in the upper 2-digit range (i.e., from
around 50 to 99) for this purpose.Make sure you don't use a UID already used by the system
or other ports. This is the current list of UIDs between 50
and 99.majordom:*:54:1024:Majordomo Pseudo
User:/usr/local/majordomo:/nonexistent cyrus:*:60:248:the
cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database
owner:/usr/local/share/gnats/gnats-db:/bin/sh
uucp:*:66:66:UUCP
pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner:/nonexistent:/nonexistent
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent
pgsql:*:71:246:PostgreSQL
pseudo-user:/usr/local/pgsql:/bin/sh msql:*:80:249:mSQL-2
pseudo-user:/var/db/msqldb:/bin/shPlease send a notice to &a.ports; if you submit or commit
a port that allocates a new UID in this range so we can keep
this list up to date.If you are stuck....Do look at existing examples and the
bsd.port.mk file before asking us
questions! ;)Do ask us questions if you have any trouble! Do not just
beat your head against a wall! :)A Sample <filename>Makefile</filename>Here is a sample Makefile that you can
use to create a new port. Make sure you remove all the extra
comments (ones between brackets)!It is recommended that you follow this format (ordering of
variables, empty lines between sections, etc.). Not all of the
existing Makefiles are in this format
(mostly old ones), but we are trying to uniformize how they
look. This format is designed so that the most important
information is easy to locate. [the header...just to make it easier for us to
identify the ports.] # New ports collection makefile for:
xdvi [the version required header should updated when
upgrading a port.] # Version required: pl18 [things
like "1.5alpha" are fine here too] [this is the date when
the first version of this Makefile was created. Never
change this when doing an update of the port.] # Date
created: 26 May 1995 [this is the person who
did the original port to FreeBSD, in particular, the person
who wrote the first version of this Makefile. Remember,
this should not be changed when upgrading the port later.] #
Whom: Satoshi Asami
<asami@FreeBSD.ORG> # # $Id$ [ ^^^^ This will
be automatically replaced with RCS ID string by CVS when it
is committed to our repository.] # [section to describe the
port itself and the master site - DISTNAME is always first,
followed by PKGNAME (if necessary), CATEGORIES, and then
MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
After those, one of EXTRACT_SUFX or DISTFILES can be
specified too.] DISTNAME= xdvi PKGNAME= xdvi-pl18
CATEGORIES= print [do not forget the trailing slash ("/")!
if you aren't using MASTER_SITE_* macros] MASTER_SITES=
${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications
[set this if the source is not in the standard ".tar.gz"
form] EXTRACT_SUFX= .tar.Z [section for distributed
patches -- can be empty] PATCH_SITES=
ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES=
xdvi-18.patch1.gz xdvi-18.patch2.gz [maintainer;
*mandatory*! This is the person (preferably with commit
privileges) who a user can contact for questions and bug
reports - this person should be the porter or someone who
can forward questions to the original porter reasonably
promptly. If you really do not want to have your address
here, set it to "ports@FreeBSD.ORG".] MAINTAINER=
asami@FreeBSD.ORG [dependencies -- can be empty]
RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS=
Xpm\\.4\\.:${PORTSDIR}/graphics/xpm [this section is for
other standard bsd.port.mk variables that do not belong to
any of the above] [If it asks questions during configure,
build, install...] IS_INTERACTIVE= yes [If it extracts to
a directory other than ${DISTNAME}...] WRKSRC=
${WRKDIR}/xdvi-new [If the distributed patches were not made
relative to ${WRKSRC}, you may need to tweak this]
PATCH_DIST_STRIP= -p1 [If it requires a "configure"
script generated by GNU autoconf to be run] GNU_CONFIGURE=
yes [If it requires GNU make, not /usr/bin/make, to
build...] USE_GMAKE= yes [If it is an X application and
requires "xmkmf -a" to be run...] USE_IMAKE= yes [et
cetera.] [non-standard variables to be used in the rules
below] MY_FAVORITE_RESPONSE= "yeah, right" [then the
special rules, in the order they are called] pre-fetch: i go
fetch something, yeah post-patch: i need to do something
after patch, great pre-install: and then some more stuff
before installing, wow [and then the epilogue] .include
<bsd.port.mk>Package NamesThe following are the conventions you should follow in
naming your packages. This is to have our package directory
easy to scan, as there are already lots and lots of packages and
users are going to turn away if they hurt their eyes!The package name should look like[<language>-]<name>[[-]<compiled.specifics>]-<version.string.numbers>;If your ${DISTNAME}
doesn't look like that, set ${PKGNAME} to something in that
format.FreeBSD strives to support the native language of its
users. The `<language>' part should be a two letter
abbreviation of the natural language defined by ISO-639 if
the port is specific to a certain language. Examples are
`ja' for Japanese, `ru' for Russian, `vi' for Vietnamese,
`zh' for Chinese, `ko' for Korean and `de' for German.
The <name> part
should be all lowercases, except for a really large
package (with lots of programs in it). Things like
XFree86 (yes there really is a package of it, check it
out) and ImageMagick fall into this category. Otherwise,
convert the name (or at least the first letter) to
lowercase. If the software in question really is called
that way, you can have numbers, hyphens and underscores in
the name too (like `kinput2').
If the port can be built with different hardcoded
defaults (usually specified as environment variables or on
the make command line), the
`<compiled.specifics>' part should state the
compiled-in defaults (the hyphen is optional). Examples
are papersize and font units.
The version string should be a period-separated list
of integers and single lowercase alphabetics. The only
exception is the string `pl' (meaning `patchlevel'), which
can be used only when there are no
major and minor version numbers in the software.Here are some (real) examples on how to convert a ${DISTNAME} into a suitable ${PKGNAME}:DISTNAME PKGNAME Reason
mule-2.2.2 mule-2.2.2 no prob at all
XFree86-3.1.2 XFree86-3.1.2 ditto EmiClock-1.0.2
emiclock-1.0.2 no uppercase names for single
programs gmod1.4 gmod-1.4 need
hyphen after `<name>' xmris.4.02 xmris-4.02
ditto rdist-1.3alpha rdist-1.3a no strings
like `alpha' allowed es-0.9-beta1 es-0.9b1
ditto v3.3beta021.src tiff-3.3 what the heck
was that anyway? ;) tvtwm tvtwm-pl11
version string always required piewm piewm-1.0
ditto xvgr-2.10pl1 xvgr-2.10.1 `pl' allowed
only when no maj/minor numbers gawk-2.15.6 ja-gawk-2.15.6
Japanese language version psutils-1.13
psutils-letter-1.13 papersize hardcoded at package build
time pkfonts pkfonts300-1.0 package for
300dpi fontsIf there is absolutely no trace of version information in
the original source and it is unlikely that the original author
will ever release another version, just set the version string
to `1.0' (like the piewm example above). Otherwise, ask the
original author or use the date string (`yy.mm.dd') as the
version.That is It, Folks!Boy, this sure was a long tutorial, wasn't it? Thanks for
following us to here, really.Well, now that you know how to do a port, let us go at it
and convert everything in the world into ports! That is the
easiest way to start contributing to the FreeBSD Project!
:)Money, Hardware or Internet accessWe are always very happy to accept donations to further the
cause of the FreeBSD Project and, in a volunteer effort like ours,
a little can go a long way! Donations of hardware are also very
important to expanding our list of supported peripherals since we
generally lack the funds to buy such items ourselves. Donating fundsWhile the FreeBSD Project is not a 501(C3) (non-profit)
corporation and hence cannot offer special tax incentives for
any donations made, any such donations will be gratefully
accepted on behalf of the project by FreeBSD, Inc.FreeBSD, Inc. was founded in early 1995 by &a.jkh; and
&a.davidg; with the goal of furthering the aims of the FreeBSD
Project and giving it a minimal corporate presence. Any and all
funds donated (as well as any profits that may eventually be
realized by FreeBSD, Inc.) will be used exclusively to further
the project's goals. Please make any checks payable to FreeBSD, Inc., sent in
care of the following address:FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, suite
#D. Concord CA, 94520 [temporarily using the Walnut Creek
CDROM address until a PO box can be opened]Wire transfers may also be sent directly to:Bank Of America Concord Main Office P.O. Box 37176
San Francisco CA, 94137-5176 Routing #: 121-000-358 Account
#: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to
Jordan Hubbard,
either via email or to the FreeBSD, Inc. postal address given
above.If you do not wish to be listed in our section, please specify this
when making your donation. Thanks!Donating hardwareDonations of hardware in any of the 3 following categories
are also gladly accepted by the FreeBSD Project:General purpose hardware such as disk drives, memory
or complete systems should be sent to the FreeBSD, Inc.
address listed in the donating funds
section.
Hardware for which ongoing compliance testing is
desired. We are currently trying to put together a testing
lab of all components that FreeBSD supports so that proper
regression testing can be done with each new release. We
are still lacking many important pieces (network cards,
motherboards, etc) and if you would like to make such a
donation, please contact &a.davidg; for information on
which items are still required.
Hardware currently unsupported by FreeBSD for which
you would like to see such support added. Please contact
the &a.core; before sending such items as we will need to
find a developer willing to take on the task before we can
accept delivery of new hardware. Donating Internet accessWe can always use new mirror sites for FTP, WWW or cvsup. If
you would like to be such a mirror, please contact the FreeBSD project
administrators for more information.Donors GalleryThe FreeBSD Project is indebted to the following donors and
would like to publically thank them here!Contributors to the central server
project:The following individuals and businesses made it possible
for the FreeBSD Project to build a new central server machine
to eventually replace
freefall.freebsd.org by donating the
following items:Ade
Barkah and his employer, Hemisphere Online,
donated a Pentium Pro (P6) 200Mhz
CPUASA
Computers donated a Tyan
1662 motherboard.
Joe McGuckin
of ViaNet
Communications donated a Kingston ethernet controller.Jack
O'Neill donated an NCR
53C875 SCSI controller card.
Ulf
Zimmermann of Alameda Networks
donated 128MB of memory, a
4 Gb disk drive and the
case.Direct funding:The following individuals and businesses have generously
contributed direct funding to the project:Annelise
AndersonMatt
DillonEpilogue
Technology CorporationSean Eric Fagan
Gianmarco
GiovannelliJosef C.
GroschChuck
RobeyKenneth
P. Stox of Imaginary Landscape,
LLC.Dmitry S.
KohmanyukLaser5
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.
Fuki
Shuppan Publishing Co. donated a portion of
their profits from Hajimete no
FreeBSD (FreeBSD, Getting started) to the
FreeBSD and XFree86 projects.ASCII
Corp. donated a portion of their profits from
several FreeBSD-related books to the FreeBSD
project.Yokogawa
Electric Corp has generously donated
significant funding to the FreeBSD project.BuffNETHardware contributors:The following individuals and businesses have generously
contributed hardware for testing and device driver
development/support:Walnut Creek CDROM for providing the Pentium P5-90
and 486/DX2-66 EISA/VL systems that are being used for
our development work, to say nothing of the network
access and other donations of hardware resources.
TRW Financial Systems, Inc. provided 130 PCs, three
68 GB fileservers, twelve Ethernets, two routers and an
ATM switch for debugging the diskless code. They also
keep a couple of FreeBSD hackers alive and busy.
Thanks!
Dermot McDonnell donated the Toshiba XM3401B CDROM
drive currently used in freefall.
&a.chuck; contributed his floppy tape streamer for
experimental work.
Larry Altneu <larry@ALR.COM>, and &a.wilko;, provided Wangtek and Archive QIC-02 tape drives in order to improve the wt driver.
Ernst Winter <ewinter@lobo.muc.de> contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. ;-)
Tekram
Technologies sent one each of their DC-390,
DC-390U and DC-390F FAST and ULTRA SCSI host adapter
cards for regression testing of the NCR and AMD drivers
with their cards. They are also to be applauded for
making driver sources for free operating systems
available from their FTP server ftp://ftp.tekram.com/scsi/FreeBSD.
Larry M.
Augustin contributed not only a Symbios
Sym8751S SCSI card, but also a set of data books,
including one about the forthcoming Sym53c895 chip with
Ultra-2 and LVD support, and the latest programming
manual with information on how to safely use the
advanced features of the latest Symbios SCSI chips.
Thanks a lot!
Christoph
Kukulies donated an FX120 12 speed Mitsumi
CDROM drive for IDE CDROM driver development.
Special contributors:Walnut Creek
CDROM has donated almost more than we can say
(see the
document for
more details). In particular, we would like to thank
them for the original hardware used for
freefall.FreeBSD.ORG, our primary
development machine, and for
thud.FreeBSD.ORG, a testing and
build box. We are also indebted to them for funding
various contributors over the years and providing us
with unrestricted use of their T1 connection to the
Internet.The interface
business GmbH, Dresden has been patiently
supporting &a.joerg; who has often preferred FreeBSD
work over paywork, and used to fall back to their (quite
expensive) EUnet Internet connection whenever his
private connection became too slow or flakey to work
with it...Berkeley Software
Design, Inc. has contributed their DOS
emulator code to the remaining BSD world, which is used
in the dosemu command.Derived Software ContributorsThis software was originally derived from William F. Jolitz's
386BSD release 0.1, though almost none of the original 386BSD
specific code remains. This software has been essentially
re-implemented from the 4.4BSD-Lite release provided by the Computer
Science Research Group (CSRG) at the University of California,
Berkeley and associated academic contributors.There are also portions of NetBSD that have been integrated into
FreeBSD as well, and we would therefore like to thank all the
contributors to NetBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):A JOSEPH KOSHY <koshy@india.hp.com>ABURAYA Ryushirou <rewsirow@ff.iij4u.or.jp>Ada T Lim <ada@bsd.org>Adam Glass <glass@postgres.berkeley.edu>Adrian T. Filipi-Martin <atf3r@agate.cs.virginia.edu>Akito Fujita <fujita@zoo.ncl.omron.co.jp>Alain Kalker <A.C.P.M.Kalker@student.utwente.nl>Alan Cox <alc@cs.rice.edu>Andreas Kohout <shanee@rabbit.augusta.de>Andreas Lohr <andreas@marvin.RoBIN.de>Andrew Gordon <andrew.gordon@net-tel.co.uk>Andrew Herbert <andrew@werple.apana.org.au>Andrew McRae <amcrae@cisco.com>Andrew Moore <alm@FreeBSD.org>Andrew Stevenson <andrew@ugh.net.au>Andrew V. Stesin <stesin@elvisti.kiev.ua>Andrey Zakhvatov <andy@icc.surw.chel.su>Andy Whitcroft <andy@sarc.city.ac.uk>Angelo Turetta <ATuretta@stylo.it>Anthony Yee-Hang Chan <yeehang@netcom.com>Ari Suutari <ari@suutari.iki.fi>Brent J. Nordquist <bjn@visi.com>Bernd Rosauer <br@schiele-ct.de>Bill Kish <kish@osf.org>&a.wlloyd;Bob Wilcox <bob@obiwan.uucp>Boyd Faulkner <faulkner@mpd.tandem.com>Brent J. Nordquist <bjn@visi.com>Brett Taylor <brett@peloton.physics.montana.edu>Brian Clapper <bmc@willscreek.com>Brian Handy <handy@lambic.space.lockheed.com>Brian Tao <taob@risc.org>Brion Moss <brion@queeg.com>Bruce Gingery <bgingery@gtcs.com>Carey Jones <mcj@acquiesce.org>Carl Fongheiser <cmf@netins.net>Charles Hannum <mycroft@ai.mit.edu>Charles Mott <cmott@srv.net>Chet Ramey <chet@odin.INS.CWRU.Edu>Chris Dabrowski <
chris@vader.org>Chris G. Demetriou <cgd@postgres.berkeley.edu>Chris Shenton <cshenton@angst.it.hq.nasa.gov>Chris Stenton <jacs@gnome.co.uk>Chris Timmons <skynyrd@opus.cts.cwu.edu>Chris Torek <torek@ee.lbl.gov>Christian Gusenbauer <cg@fimp01.fim.uni-linz.ac.at>Christian Haury <Christian.Haury@sagem.fr>Christoph Robitschko <chmr@edvz.tu-graz.ac.at>Choi Jun Ho <junker@jazz.snu.ac.kr>Chuck Hein <chein@cisco.com>Conrad Sabatier <conrads@neosoft.com>Cornelis van der Laan <nils@guru.ims.uni-stuttgart.de>Craig Struble <cstruble@vt.edu>Cristian Ferretti <cfs@riemann.mat.puc.cl>Curt Mayer <curt@toad.com>Dai Ishijima <ishijima@tri.pref.osaka.jp>Dan Cross <tenser@spitfire.ecsel.psu.edu>Daniel Baker <dbaker@crash.ops.neosoft.com>Daniel M. Eischen <deischen@iworks.InterWorks.org>Daniel O'Connor <doconnor@gsoft.com.au>Danny J. Zerkel <dzerkel@feephi.phofarm.com>Dave Bodenstab <imdave@synet.net>Dave Burgess <burgess@hrd769.brooks.af.mil>Dave Chapeskie <dchapes@zeus.leitch.com>Dave Edmondson <davided@sco.com>Dave Rivers <rivers@ponds.uucp>David A. Bader <dbader@umiacs.umd.edu>David Dawes <dawes@physics.su.OZ.AU>David Holloway <daveh@gwythaint.tamis.com>David Leonard <d@scry.dstc.edu.au>Dean Huxley <dean@fsa.ca>Dirk Froemberg <dirk@hal.in-berlin.de>Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>Dmitry Kohmanyuk <dk@farm.org>&a.whiteside;Don Yuniskis <dgy@rtd.com>Donald Burr <d_burr@ix.netcom.com>Doug Ambrisko <ambrisko@ambrisko.roble.com>Douglas Carmichael <dcarmich@mcs.com>Eiji-usagi-MATSUmoto <usagi@ruby.club.or.jp>ELISA Font ProjectEric A. Griff <eagriff@global2000.net>Eric Blood <eblood@cs.unr.edu>Eric J. Chet <ejc@bazzle.com>Eric J. Schwertfeger <eric@cybernut.com>Francis M J Hsieh <mjhsieh@life.nthu.edu.tw>Frank Bartels <knarf@camelot.de>Frank Chen Hsiung Chan <frankch@waru.life.nthu.edu.tw>Frank Maclachlan <fpm@crash.cts.com>Frank Nobis <fn@trinity.radio-do.de>FUJIMOTO Kensaku <fujimoto@oscar.elec.waseda.ac.jp>FURUSAWA Kazuhisa <furusawa@com.cs.osakafu-u.ac.jp>Gary A. Browning <gab10@griffcd.amdahl.com>Gary Kline <kline@thought.org>Gerard Roudier <groudier@club-internet.fr>Greg Ungerer <gerg@stallion.oz.au>Harlan Stenn <Harlan.Stenn@pfcs.com>Havard Eidnes <Havard.Eidnes@runit.sintef.no>Hideaki Ohmon <ohmon@tom.sfc.keio.ac.jp>Hidekazu Kuroki <hidekazu@cs.titech.ac.jp>Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>Hideyuki Suzuki <hideyuki@sat.t.u-tokyo.ac.jp>Hironori Ikura <hikura@kaisei.org>Holger Veit <Holger.Veit@gmd.de>Hung-Chi Chu <hcchu@r350.ee.ntu.edu.tw>Ian Vaudrey <i.vaudrey@bigfoot.com>Igor Vinokurov <igor@zynaps.ru>Ikuo Nakagawa <ikuo@isl.intec.co.jp>IMAMURA Tomoaki <tomoak-i@is.aist-nara.ac.jp>Ishii Masahiro Issei Suzuki<issei@t-cnet.or.jp>Itsuro Saito <saito@miv.t.u-tokyo.ac.jp>J. David Lowe <lowe@saturn5.com>J.T. Conklin <jtc@cygnus.com>James Clark <jjc@jclark.com>James da Silva <jds@cs.umd.edu> et alJanusz Kokot <janek@gaja.ipan.lublin.pl>Jason Thorpe <thorpej@nas.nasa.gov>Javier Martin Rueda <jmrueda@diatel.upm.es>Jeff Bartig <jeffb@doit.wisc.edu>Jeffrey Wheat <jeff@cetlink.net>Jian-Da Li <jdli@csie.NCTU.edu.tw>Jim Binkley <jrb@cs.pdx.edu>Jim Lowe <james@cs.uwm.edu>Jim Wilson <wilson@moria.cygnus.com>Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>Joel Sutton <sutton@aardvark.apana.org.au>Johann Tonsing <jtonsing@mikom.csir.co.za>John Capo <jc@irbs.com>John Heidemann <johnh@isi.edu>John Perry <perry@vishnu.alias.net>John Polstra <jdp@polstra.com>John Rochester <jr@cs.mun.ca>Josef Karthauser <joe@uk.freebsd.org>Joseph Stein <joes@seaport.net>Josh Gilliam <josh@quick.net>Josh Tiefenbach <josh@ican.net>Juergen Lock <nox@jelal.hb.north.de>Juha Inkari <inkari@cc.hut.fi>Julian Assange <proff@suburbia.net>Julian Jenkins <kaveman@magna.com.au>Julian Stacey <jhs@freebsd.org>Junichi Satoh <junichi@jp.freebsd.org>Kapil Chowksey <kchowksey@hss.hns.com>Kazuhiko Kiriyama <kiri@kiri.toba-cmt.ac.jp>Keith Bostic <bostic@bostic.com>Keith MooreKenneth Monville <desmo@bandwidth.org>Kent Vander Velden <graphix@iastate.edu>Kirk McKusick <mckusick@mckusick.com>Kiroh HARADA <kiroh@kh.rim.or.jp>Koichi Sato <copan@ppp.fastnet.or.jp>Kostya Lukin <lukin@okbmei.msk.su>Kurt Olsen <kurto@tiny.mcs.usu.edu>Lars Koeller <Lars.Koeller@Uni-Bielefeld.DE>Lucas James <Lucas.James@ldjpc.apana.org.au>Luigi Rizzo <luigi@iet.unipi.it>Makoto MATSUSHITA <matusita@jp.freebsd.org>Manu Iyengar <iyengar@grunthos.pscwa.psca.com>Marc Frajola <marc@dev.com>Marc Ramirez <mrami@mramirez.sy.yale.edu>Marc Slemko <marcs@znep.com>Marc van Kempen <wmbfmk@urc.tue.nl>Mario Sergio Fujikawa Ferreira <lioux@gns.com.br>Mark Huizer <xaa@stack.nl>Mark J. Taylor <mtaylor@cybernet.com>Mark Krentel <krentel@rice.edu>Mark Tinguely <tinguely@plains.nodak.edu><tinguely@hookie.cs.ndsu.NoDak.edu>Martin BirgmeierMartti Kuparinen <erakupa@kk.etx.ericsson.se>Masachika ISHIZUKA <ishizuka@isis.min.ntt.jp>Mats Lofkvist <mal@algonet.se>Matt Bartley <mbartley@lear35.cytex.com>Matt Thomas <thomas@lkg.dec.com>Matt White <mwhite+@CMU.EDU>Matthew Hunt <mph@pobox.com>Matthew N. Dodd <winter@jurai.net>Matthew Stein <matt@bdd.net>Maurice Castro <maurice@planet.serc.rmit.edu.au>Michael Butschky <butsch@computi.erols.com>Michael Elbel <me@FreeBSD.ORG>Michael Searle <searle@longacre.demon.co.uk>Miguel Angel Sagreras <msagre@cactus.fi.uba.ar>Mikael Hybsch <micke@dynas.se>Mikhail Teterin <mi@aldan.ziplink.net>Mike McGaughey <mmcg@cs.monash.edu.au>Mike Peck <mike@binghamton.edu>Ming-I Hseh <PA@FreeBSD.ee.Ntu.edu.TW>MITA Yoshio <mita@jp.FreeBSD.ORG>MOROHOSHI Akihiko <moro@race.u-tokyo.ac.jp>Murray Stokely <murray@cdrom.com>NAKAMURA Kazushi <nkazushi@highway.or.jp>Naoki Hamada <nao@tom-yam.or.jp>Narvi <narvi@haldjas.folklore.ee>NIIMI Satoshi <sa2c@and.or.jp>Nick Sayer <nsayer@quack.kfu.com>Nicolas Souchu <Nicolas.Souchu@prism.uvsq.fr>Nisha Talagala <nisha@cs.berkeley.edu>Nobuhiro Yasutomi <nobu@psrc.isac.co.jp>Nobuyuki Koganemaru <kogane@kces.koganemaru.co.jp>Noritaka Ishizumi <graphite@jp.FreeBSD.ORG>Oliver Fromme <oliver.fromme@heim3.tu-clausthal.de>Oliver Laumann <net@informatik.uni-bremen.de>Oliver Oberdorf <oly@world.std.com>Paul Fox <pgf@foxharp.boston.ma.us>Paul Kranenburg <pk@cs.few.eur.nl>Paul Mackerras <paulus@cs.anu.edu.au>Paulo Menezes <paulo@isr.uc.pt>Paul T. Root <proot@horton.iaces.com>Pedro Giffuni <giffunip@asme.org>Pedro A M Vazquez <vazquez@IQM.Unicamp.BR>Peter Cornelius <pc@inr.fzk.de>Peter Haight <peterh@prognet.com>Peter Hawkins <peter@rhiannon.clari.net.au>Peter Stubbs <PETERS@staidan.qld.edu.au>Pierre Beyssac <bp@fasterix.freenix.org>Phil Maker <pjm@cs.ntu.edu.au>R. Kym HorsellRandall Hopper <rhh@stealth.ct.picker.com>Richard Hwang <rhwang@bigpanda.com>Richard Seaman, Jr. <dick@tar.com>Richard Stallman <rms@gnu.ai.mit.edu>Richard Wiwatowski <rjwiwat@adelaide.on.net>Rob Mallory <rmallory@csusb.edu>Rob Shady <rls@id.net>Rob Snow <rsnow@txdirect.net>Robert Sanders <rsanders@mindspring.com>Robert Withrow <witr@rwwa.com>Ronald Kuehn <kuehn@rz.tu-clausthal.de>Roland Jesse <jesse@cs.uni-magdeburg.de>Ruslan Shevchenko <rssh@cki.ipri.kiev.ua>Samuel Lam <skl@ScalableNetwork.com>Sander Vesik <sander@haldjas.folklore.ee>Sandro Sigala <ssigala@globalnet.it>Sascha Blank <blank@fox.uni-trier.de>Sascha Wildner <swildner@channelz.GUN.de>Satoshi Taoka <taoka@infonets.hiroshima-u.ac.jp>Scott Blachowicz <scott.blachowicz@seaslug.org>Scott A. Kenney <saken@rmta.ml.org>Serge V. Vakulenko <vak@zebub.msk.su>Sheldon Hearn <axl@iafrica.com>Simon Marlow <simonm@dcs.gla.ac.uk>Slaven Rezic (Tomic) <eserte@cs.tu-berlin.de>Soren Dayton <csdayton@midway.uchicago.edu>Soren Dossing <sauber@netcom.com>Stefan Moeding <moeding@bn.DeTeMobil.de>Stephane Legrand <stephane@lituus.fr>Stephen J. Roznowski <sjr@home.net>Steve Gerakines <steve2@genesis.tiac.net>Suzuki Yoshiaki <zensyo@ann.tama.kawasaki.jp>Tadashi Kumano <kumano@strl.nhk.or.jp>Taguchi Takeshi <taguchi@tohoku.iij.ad.jp>Takayuki Ariga <a00821@cc.hc.keio.ac.jp>Terry Lambert <terry@lambert.org>Terry Lee <terry@uivlsi.csl.uiuc.edu>Tetsuya Furukawa <tetsuya@secom-sis.co.jp>Theo Deraadt <deraadt@fsa.ca>Thomas König <Thomas.Koenig@ciw.uni-karlsruhe.de>Þórður Ívarsson <totii@est.is>Tim Kientzle <kientzle@netcom.com>Tim Wilkinson <tim@sarc.city.ac.uk>Tom Samplonius <tom@misery.sdf.com>Torbjorn Granlund <tege@matematik.su.se>Toshihiro Kanda <candy@fct.kgc.co.jp>Trefor S. <trefor@flevel.co.uk>Ville Eerola <ve@sci.fi>Werner Griessl <werner@btp1da.phy.uni-bayreuth.de>Wes Santee <wsantee@wsantee.oz.net>Wilko Bulte <wilko@yedi.iaf.nl>Wolfgang Stanglmeier <wolf@kintaro.cologne.de>Wu Ching-hong <woju@FreeBSD.ee.Ntu.edu.TW>Yen-Shuo Su <yssu@CCCA.NCTU.edu.tw>Yoshiaki Uchikawa <yoshiaki@kt.rim.or.jp>Yoshiro Mihira <sanpei@yy.cs.keio.ac.jp>Yukihiro Nakai <nakai@mlab.t.u-tokyo.ac.jp>Yuval Yarom <yval@cs.huji.ac.il>Yves Fonk <yves@cpcoup5.tn.tudelft.nl>386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass <glass@postgres.berkeley.edu>Adrian Hall <adrian@ibmpcug.co.uk>Andrey A. Chernov <ache@astral.msk.su>Andrew Herbert <andrew@werple.apana.org.au>Andrew Moore <alm@netcom.com>Andy Valencia <ajv@csd.mot.com><jtk@netcom.com>Arne Henrik Juul <arnej@Lise.Unit.NO>Bakul Shah <bvs@bitblocks.com>Barry Lustig <barry@ictv.com>Bob Wilcox <bob@obiwan.uucp>Branko LankesterBrett Lymn <blymn@mulga.awadi.com.AU>Charles Hannum <mycroft@ai.mit.edu>Chris G. Demetriou <cgd@postgres.berkeley.edu>Chris Torek <torek@ee.lbl.gov>Christoph Robitschko <chmr@edvz.tu-graz.ac.at>Daniel Poirot <poirot@aio.jsc.nasa.gov>Dave Burgess <burgess@hrd769.brooks.af.mil>Dave Rivers <rivers@ponds.uucp>David Dawes <dawes@physics.su.OZ.AU>David Greenman <davidg@Root.COM>Eric J. Haug <ejh@slustl.slu.edu>Felix Gaehtgens <felix@escape.vsse.in-berlin.de>Frank Maclachlan <fpm@crash.cts.com>Gary A. Browning <gab10@griffcd.amdahl.com>Gary Howland <gary@hotlava.com>Geoff Rehmet <csgr@alpha.ru.ac.za>Goran Hammarback <goran@astro.uu.se>Guido van Rooij <guido@gvr.win.tue.nl>Guy Harris <guy@auspex.com>Havard Eidnes <Havard.Eidnes@runit.sintef.no>Herb Peyerl <hpeyerl@novatel.cuc.ab.ca>Holger Veit <Holger.Veit@gmd.de>Ishii Masahiro, R. Kym HorsellJ.T. Conklin <jtc@cygnus.com>Jagane D Sundar < jagane@netcom.com
>James Clark <jjc@jclark.com>James Jegers <jimj@miller.cs.uwm.edu>James W. DolterJames da Silva <jds@cs.umd.edu> et alJay Fenlason <hack@datacube.com>Jim Wilson <wilson@moria.cygnus.com>Jörg Lohse <lohse@tech7.informatik.uni-hamburg.de>Jörg Wunsch <joerg_wunsch@uriah.heep.sax.de>John Dyson - <formerly
dyson@ref.tfs.com>John Woods <jfw@eddie.mit.edu>Jordan K. Hubbard <jkh@whisker.hubbard.ie>Julian Elischer <julian@dialix.oz.au>Julian Stacey <jhs@freebsd.org>Karl Lehenbauer <karl@NeoSoft.com><karl@one.neosoft.com>Keith Bostic <bostic@toe.CS.Berkeley.EDU>Ken HughesKent Talarico <kent@shipwreck.tsoft.net>Kevin Lahey <kml%rokkaku.UUCP@mathcs.emory.edu><kml@mosquito.cis.ufl.edu>Marc Frajola <marc@dev.com>Mark Tinguely <tinguely@plains.nodak.edu><tinguely@hookie.cs.ndsu.NoDak.edu>Martin Renters <martin@tdc.on.ca>Michael Clay <mclay@weareb.org>Michael Galassi <nerd@percival.rain.com>Mike Durkin <mdurkin@tsoft.sf-bay.org>Naoki Hamada <nao@tom-yam.or.jp>Nate Williams <nate@bsd.coe.montana.edu>Nick Handel <nhandel@NeoSoft.com><nick@madhouse.neosoft.com>Pace Willisson <pace@blitz.com>Paul Kranenburg <pk@cs.few.eur.nl>Paul Mackerras <paulus@cs.anu.edu.au>Paul Popelka <paulp@uts.amdahl.com>Peter da Silva <peter@NeoSoft.com>Phil Sutherland <philsuth@mycroft.dialix.oz.au>Poul-Henning Kamp<phk@FreeBSD.ORG>Ralf Friedl <friedl@informatik.uni-kl.de>Rick Macklem <root@snowhite.cis.uoguelph.ca>Robert D. Thrush <rd@phoenix.aii.com>Rodney W. Grimes <rgrimes@cdrom.com>Sascha Wildner <swildner@channelz.GUN.de>Scott Burris <scott@pita.cns.ucla.edu>Scott Reynolds <scott@clmqt.marquette.mi.us>Sean Eric Fagan <sef@kithrup.com>Simon J Gerraty <sjg@melb.bull.oz.au><sjg@zen.void.oz.au>Stephen McKay <syssgm@devetir.qld.gov.au>Terry Lambert <terry@icarus.weber.edu>Terry Lee <terry@uivlsi.csl.uiuc.edu>Tor Egge <Tor.Egge@idi.ntnu.no>Warren Toomey <wkt@csadfa.cs.adfa.oz.au>Wiljo Heinen <wiljo@freeside.ki.open.de>William Jolitz <withheld>Wolfgang Solfrank <ws@tools.de>Wolfgang Stanglmeier <wolf@dentaro.GUN.de>Yuval Yarom <yval@cs.huji.ac.il>Source Tree Guidelines and Policies
Contributed by &a.phk;.This chapter documents various guidelines and policies in force
for the FreeBSD source tree.MAINTAINER on Makefiles
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-addressesline 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 SoftwareJune 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.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.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 importsrc/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
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. 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) 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 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 some unfortunate 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 bmakeMakefiles
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. 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
-m 'Virgin import of GNU cpio v<version>' \ src/contrib/cpio
GNU v<version> For example, to do the import of version
2.4.2, I typed: cvs import -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU v2.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 1997Shared 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.0If there is a change that is backwards compatible, bump
minor numberIf there is an incompatible change, bump major
numberFor 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
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.For non-port libraries, it is also our policy to change the
shared library version number only once between releases. 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.
Adding New Kernel Configuration OptionsContributed by &a.joerg;You should be familiar with the section about
before reading here.What's a <emphasis>Kernel Option</emphasis>, Anyway?The use of kernel options is basically described in the
section. There's also an explanation of historic and
new-style options. The ultimate goal is to eventually turn all
the supported options in the kernel into new-style ones, so for
people who correctly did a make depend
in their kernel compile directory after running
config8, the build process will automatically
pick up modified options, and only recompile those files where it is
necessary. Wiping out the old compile directory on each run of
config8 as it is still done now can then be
eliminated again.Basically, a kernel option is nothing else than the definition
of a C preprocessor macro for the kernel compilation process. To
make the build truly optional, the corresponding part of the kernel
source (or kernel .h file) must be written with
the option concept in mind, i. e. the default must have been made
overridable by the config option. This is usually done with
something like:#ifndef THIS_OPTION #define THIS_OPTION
(some_default_value) #endif /* THIS_OPTION */This way, an administrator mentioning another value for the
option in his config file will take the default out of effect, and
replace it with his new value. Clearly, the new value will be
substituted into the source code during the preprocessor run, so it
must be a valid C expression in whatever context the default value
would have been used.It is also possible to create value-less options that simply
enable or disable a particular piece of code by embracing it
in#ifdef THAT_OPTION [your code here]
#endifSimply mentioning THAT_OPTION in the config
file (with or without any value) will then turn on the corresponding
piece of code.People familiar with the C language will immediately recognize
that everything could be counted as a config option where there
is at least a single #ifdef
referencing it... However, it's unlikely that many people would
put options notyet,notdefin their config file, and then wonder why the kernel compilation
falls over. :-)Clearly, using arbitrary names for the options makes it very
hard to track their usage throughout the kernel source tree. That
is the rationale behind the new-style option
scheme, where each option goes into a separate
.h file in the kernel compile directory, which
is by convention named
opt_foo.h. This way,
the usual Makefile dependencies could be applied, and make can determine what needs to be recompiled
once an option has been changed.The old-style option mechanism still has one advantage for local
options or maybe experimental options that have a short anticipated
lifetime: since it is easy to add a new #ifdef to the kernel source, this has already
made it a kernel config option. In this case, the administrator
using such an option is responsible himself for knowing about its
implications (and maybe manually forcing the recompilation of parts
of his kernel). Once the transition of all supported options has
been done, config8 will warn whenever an
unsupported option appears in the config file, but it will
nevertheless include it into the kernel Makefile.Now What Do I Have to Do for it?First, edit sys/conf/options (or
sys/i386/conf/options.<arch>, e. g. sys/i386/conf/options.i386), and select an opt_foo.h file where your new option would best go into.If there is already something that comes close to the purpose of
the new option, pick this. For example, options modifying the
overall behaviour of the SCSI subsystem can go into
opt_scsi.h. By default, simply mentioning an
option in the appropriate option file, say FOO,
implies its value will go into the corresponding file
opt_foo.h. This can be overridden on the
right-hand side of a rule by specifying another filename.If there is no
opt_foo.h already
available for the intended new option, invent a new name. Make it
meaningful, and comment the new section in the
options[.<arch>] file. config8 will automagically pick up the change, and create that file next time it is run. Most options should go in a header file by themselves..Packing too many options into a single
opt_foo.h will cause
too many kernel files to be rebuilt when one of the options has been
changed in the config file.Finally, find out which kernel files depend on the new option.
Unless you have just invented your option, and it does not exist
anywhere yet, find /usr/src/sys -name type f | xargs fgrep
NEW_OPTIONis your friend in finding them. Go and edit all those files,
and add#include "opt_foo.h"on top, before all the #include <xxx.h> stuff. This sequence
is most important as the options could override defaults from the
regular include files, if the defaults are of the form#ifndef NEW_OPTION #define NEW_OPTION (something)
#endifin the regular header.Adding an option that overrides something in a system header
file (i. e., a file sitting in
/usr/include/sys/) is almost always a mistake.
opt_foo.h cannot be
included into those files since it would break the headers more
seriously, but if it is not included, then places that include it
may get an inconsistent value for the option. Yes, there are
precedents for this right now, but that does not make them more
correct.
Kernel DebuggingContributed by &a.paul; and &a.joerg;Debugging a Kernel Crash Dump with KGDBHere are some instructions for getting kernel debugging working
on a crash dump. They assume that you have enough swap space for a
crash dump. If you have multiple swap partitions and the first one
is too small to hold the dump, you can configure your kernel to use
an alternate dump device (in the config
kernel line), or you can specify an alternate using the
dumpon8 command. Dumps to non-swap devices, tapes for example,
are currently not supported. Config your kernel using
config -g. See for
details on configuring the FreeBSD kernel.Use the dumpon8 command to tell the kernel
where to dump to (note that this will have to be done after
configuring the partition in question as swap space via
swapon8). This is normally arranged via
/etc/rc.conf and /etc/rc.
Alternatively, you can hard-code the dump device via the `dump'
clause in the `config' line of your kernel config file. This is
deprecated and should be used only if you want a crash dump from a
kernel that crashes during booting.In the following, the term kgdb refers to
gdb run in `kernel debug mode'. This can be
accomplished by either starting the gdb with
the option , or by linking and starting it
under the name kgdb. This is not being done by
default, however, and the idea is basically deprecated since the
GNU folks do not like their tools to behave differently when
called by another name. This feature may well be discontinued in
further releases.When the kernel has been built make a copy of it, say
kernel.debug, and then run strip
-d on the original. Install the original as normal. You
may also install the unstripped kernel, but symbol table lookup time
for some programs will drastically increase, and since the whole
kernel is loaded entirely at boot time and cannot be swapped out
later, several megabytes of physical memory will be wasted.If you are testing a new kernel, for example by typing the new
kernel's name at the boot prompt, but need to boot a different one
in order to get your system up and running again, boot it only into
single user state using the flag at the boot
prompt, and then perform the following steps:
fsck -p mount -a -t ufs # so your file system for
/var/crash is writable savecore -N /kernel.panicked /var/crash
exit # ...to multi-user This instructs savecore8 to
use another kernel for symbol name extraction. It would otherwise
default to the currently running kernel and most likely not do
anything at all since the crash dump and the kernel symbols
differ.Now, after a crash dump, go to
/sys/compile/WHATEVER and run kgdb. From kgdb
do:
symbol-file kernel.debug exec-file /var/crash/kernel.0
core-file /var/crash/vmcore.0 and voila, you can debug the crash dump using the
kernel sources just like you can for any other program.Here is a script log of a kgdb
session illustrating the procedure. Long lines have been folded to
improve readability, and the lines are numbered for reference.
Despite this, it is a real-world error trace taken during the
development of the pcvt console driver.
1:Script started on Fri Dec 30 23:15:22 1994 2:uriah #
cd /sys/compile/URIAH 3:uriah # kgdb kernel /var/crash/vmcore.1
4:Reading symbol data from
/usr/src/sys/compile/URIAH/kernel...done. 5:IdlePTD 1f3000
6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading
in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where
10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767)
11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie ()
(../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in
db_fncall () 14:#4 0xf0101586 in db_command (-266509132,
-266509516, -267381073) 15:#5 0xf0101711 in db_command_loop ()
16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap
(12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal
(...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f
in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12
0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open ()
24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open ()
26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in
symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in
trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072,
tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx =
-266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err =
-272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368,
tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884})
(../../i386/i386/trap.c line 283) 35:283
(void) trap_pfault(&frame, FALSE); 36:(kgdb) frame
frame->tf_ebp frame->tf_eip 37:Reading in symbols for
../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in
pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *)
0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403
return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb)
list 42:398 43:399 tp->t_state |=
TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /*
cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD
|| (PCVT_FREEBSD >= 200) 47:403 return
((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else
49:405 return ((*linesw[tp->t_line].l_open)(dev,
tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD
>= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in
symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty
*) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816
57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000,
flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00)
(../../i386/i386/cons.c line 126) 60: return
((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up
62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014
in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open ()
67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39,
tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp =
-272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1,
tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582,
tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:=
-272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
73:673 error = (*callp->sy_call)(p, args, rval);
74:(kgdb) up 75:Initial frame selected; you cannot go up.
76:(kgdb) quit 77:uriah # exit 78:exit 79: 80:Script done on Fri
Dec 30 23:18:04 1994 Comments to the above script:line 6:This is a dump taken from within DDB (see below), hence
the panic comment because you said to!, and a rather
long stack trace; the initial reason for going into DDB has
been a page fault trap though.line 20:This is the location of function
trap() in the stack trace. line 36:Force usage of a new stack frame; this is no longer
necessary now. The stack frames are supposed to point to
the right locations now, even in case of a trap. (I do not
have a new core dump handy <g>, my kernel has not
panicked for a rather long time.) From looking at the code
in source line 403, there is a high probability that either
the pointer access for tp was messed up, or the array
access was out of bounds.line 52:The pointer looks suspicious, but happens to be a valid
address.line 56:However, it obviously points to garbage, so we have
found our error! (For those unfamiliar with that particular
piece of code: tp->t_line
refers to the line discipline of the console device here,
which must be a rather small integer number.)Post-mortem Analysis of a DumpWhat do you do if a kernel dumped core but you did not expect
it, and it is therefore not compiled using config
-g? Not everything is lost here. Do not panic!Of course, you still need to enable crash dumps. See above on
the options you have to specify in order to do this.Go to your kernel compile directory, and edit the line
containing COPTFLAGS?=-O. Add the
option there (but do not
change anything on the level of optimization). If you do already
know roughly the probable location of the failing piece of code
(e.g., the pcvt driver in the example
above), remove all the object files for this code. Rebuild the
kernel. Due to the time stamp change on the Makefile, there will be
some other object files rebuild, for example
trap.o. With a bit of luck, the added
option will not change anything for the
generated code, so you will finally get a new kernel with similar
code to the faulting one but some debugging symbols. You should at
least verify the old and new sizes with the
size1 command. If there is a mismatch, you
probably need to give up here.Go and examine the dump as described above. The debugging
symbols might be incomplete for some places, as can be seen in the
stack trace in the example above where some functions are displayed
without line numbers and argument lists. If you need more debugging
symbols, remove the appropriate object files and repeat the
kgdb session until you know
enough.All this is not guaranteed to work, but it will do it fine in
most cases.On-line Kernel Debugging Using DDBWhile kgdb as an offline debugger
provides a very high level of user interface, there are some things
it cannot do. The most important ones being breakpointing and
single-stepping kernel code.If you need to do low-level debugging on your kernel, there is
an on-line debugger available called DDB. It allows to setting
breakpoints, single-steping kernel functions, examining and changing
kernel variables, etc. However, it cannot access kernel source
files, and only has access to the global and static symbols, not to
the full debug information like kgdb.To configure your kernel to include DDB, add the option line
options DDB to your config file, and rebuild. (See for details on configuring the
FreeBSD kernel.Note that if you have an older version of the boot blocks,
your debugger symbols might not be loaded at all. Update the boot
blocks; the recent ones load the DDB symbols
automagically.)Once your DDB kernel is running, there are several ways to enter
DDB. The first, and earliest way is to type the boot flag
right at the boot prompt. The kernel will start
up in debug mode and enter DDB prior to any device probing. Hence
you can even debug the device probe/attach functions.The second scenario is a hot-key on the keyboard, usually
Ctrl-Alt-ESC. For syscons, this can be remapped; some of the
distributed maps do this, so watch out. There is an option available
for serial consoles that allows the use of a serial line BREAK on
the console line to enter DDB (options
BREAK_TO_DEBUGGER in the kernel config file). It is
not the default since there are a lot of crappy serial adapters
around that gratuitously generate a BREAK condition, for example
when pulling the cable.The third way is that any panic condition will branch to DDB if
the kernel is configured to use it. For this reason, it is not
wise to configure a kernel with DDB for a machine running
unattended.The DDB commands roughly resemble some gdb commands. The first thing you probably
need to do is to set a breakpoint:
b function-name b addressNumbers are taken hexadecimal by default, but to make them
distinct from symbol names; hexadecimal numbers starting with the
letters a-f need to be preceded with
0x (this is optional for other numbers). Simple
expressions are allowed, for example: function-name +
0x103.To continue the operation of an interrupted kernel, simply type
c To get a stack trace, use
traceNote that when entering DDB via a hot-key, the kernel is
currently servicing an interrupt, so the stack trace might be not
of much use for you.If you want to remove a breakpoint, use
del del address-expression The first form will be accepted immediately after
a breakpoint hit, and deletes the current breakpoint. The second
form can remove any breakpoint, but you need to specify the exact
address; this can be obtained from
show b To single-step the kernel, try
s This will step into functions, but you can make
DDB trace them until the matching return statement is reached by
nThis is different from gdb's `next'
statement; it is like gdb's `finish'.To examine data from memory, use (for example):
x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10
x/s stringbuf for word/halfword/byte access, and
hexadecimal/decimal/character/ string display. The number after the
comma is the object count. To display the next 0x10 items, simply
use
x ,10 Similarly, use
x/ia foofunc,10 to disassemble the first 0x10 instructions of
foofunc, and display them along with
their offset from the beginning of foofunc.To modify memory, use the write command:
w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 The command modifier (b/h/w) specifies the size of the data to be
written, the first following expression is the address to write to
and the remainder is interpreted as data to write to successive
memory locations.If you need to know the current registers, use
show reg Alternatively, you can display a single register
value by e.g.
p $eax and modify it by
set $eax new-valueShould you need to call some kernel functions from DDB, simply
say
call func(arg1, arg2, ...) The return value will be printed.For a ps1 style summary of all running
processes, use
psNow you have now examined why your kernel failed, and you wish
to reboot. Remember that, depending on the severity of previous
malfunctioning, not all parts of the kernel might still be working
as expected. Perform one of the following actions to shut down and
reboot your system:
call diediedie()This will cause your kernel to dump core and reboot, so you can
later analyze the core on a higher level with kgdb. This command
usually must be followed by another continue statement. There is now an alias for
this: panic. call boot(0) might be a good way to cleanly shut down the
running system, sync() all disks, and finally
reboot. As long as the disk and file system interfaces of the
kernel are not damaged, this might be a good way for an almost clean
shutdown. call cpu_reset() is the final way out of disaster and almost the
same as hitting the Big Red Button.If you need a short command summary, simply type
help However, it is highly recommended to have a
printed copy of the ddb4 manual page
ready for a debugging session. Remember that it is hard to read the
on-line manual while single-stepping the kernel.On-line Kernel Debugging Using Remote GDBThis feature has been supported since FreeBSD 2.2, and it's
actually a very neat one.GDB has already supported remote debugging
for a long time. This is done using a very simple protocol along a
serial line. Unlike the other methods described above, you will
need two machines for doing this. One is the host providing the
debugging environment, including all the sources, and a copy of the
kernel binary with all the symbols in it, and the other one is the
target machine that simply runs a similar copy of the very same
kernel (but stripped of the debugging information).You should configure the kernel in question with config
-g, include into the
configuration, and compile it as usual. This gives a large blurb of
a binary, due to the debugging information. Copy this kernel to the
target machine, strip the debugging symbols off with strip
-x, and boot it using the boot
option. Connect the first serial line of the target machine to any
serial line of the debugging host. Now, on the debugging machine,
go to the compile directory of the target kernel, and start gdb:
% gdb -k kernel GDB is free software and you are welcome
to distribute copies of it under certain conditions; type "show
copying" to see the conditions. There is absolutely no warranty
for GDB; type "show warranty" for details. GDB 4.16
(i386-unknown-freebsd), Copyright 1996 Free Software
Foundation, Inc... (kgdb) Initialize the remote debugging session (assuming the first
serial port is being used) by:
(kgdb) target remote /dev/cuaa0Now, on the target host (the one that entered DDB right before
even starting the device probe), type:
Debugger("Boot flags requested debugger") Stopped at
Debugger+0x35: movb $0, edata+0x51bc db> gdbDDB will respond with:
Next trap will enter GDB remote protocol modeEvery time you type gdb, the mode will be toggled between
remote GDB and local DDB. In order to force a next trap
immediately, simply type s (step). Your hosting GDB will now
gain control over the target kernel:
Remote debugging using /dev/cuaa0 Debugger (msg=0xf01b0383
"Boot flags requested debugger") at
../../i386/i386/db_interface.c:257 (kgdb) You can use this session almost as any other GDB session,
including full access to the source, running it in gud-mode inside
an Emacs window (which gives you an automatic source code display in
another Emacs window) etc.Remote GDB can also be used to debug LKMs. First build the LKM
with debugging symbols:
# cd /usr/src/lkm/linux # make clean; make
COPTS=-gThen install this version of the module on the target machine,
load it and use modstat to find out
where it was loaded:
# linux # modstat Type Id Off Loadaddr Size Info
Rev Module Name EXEC 0 4 f5109000 001c f510f010 1
linux_modTake the load address of the module and add 0x20 (probably to
account for the a.out header). This is the address that the module
code was relocated to. Use the add-symbol-file command in GDB to tell the
debugger about the module:
(kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o
0xf5109020 add symbol table from file
"/usr/src/lkm/linux/linux_mod.o" at text_addr = 0xf5109020? (y
or n) y (kgdb)You now have access to all the symbols in the LKM.Debugging a Console DriverSince you need a console driver to run DDB on, things are more
complicated if the console driver itself is failing. You might
remember the use of a serial console (either with modified boot
blocks, or by specifying at the Boot: prompt), and hook up a standard terminal
onto your first serial port. DDB works on any configured console
driver, of course also on a serial console.Linux EmulationContributed by &a.handy; and &a.rich;How to Install the Linux EmulatorLinux emulation in FreeBSD has reached a point where it is
possible to run a large fraction of Linux binaries in both a.out and
ELF format. The linux emulation in the 2.1-STABLE branch is capable
of running Linux DOOM and Mathematica; the version present in
FreeBSD-2.2-RELEASE is vastly more capable and runs all these as
well as Quake, Abuse, IDL, netrek for Linux and a whole host of
other programs.There are some Linux-specific operating system features that are
not supported on FreeBSD. Linux binaries will not work on FreeBSD
if they use the Linux /proc filesystem (which
is different from the optional FreeBSD /proc
filesystem) or i386-specific calls, such as enabling virtual 8086
mode.To tell whether your kernel is configured for Linux
compatibility simply run any Linux binary. If it prints the error
message
linux-executable: Exec format error. Wrong
Architecture. then you do not have linux compatibility support
and you need to configure and install a new kernel.Depending on which version of FreeBSD you are running, how you
get Linux-emulation up will vary slightly:Installing Linux Emulation in 2.1-STABLEThe GENERIC kernel in 2.1-STABLE is not
configured for linux compatibility so you must reconfigure your
kernel for it. There are two ways to do this: 1. linking the
emulator statically in the kernel itself and 2. configuring your
kernel to dynamically load the linux loadable kernel module
(LKM).To enable the emulator, add the following to your
configuration file (c.f.
/sys/i386/conf/LINT):
options COMPAT_LINUX If you want to run doom or other applications
that need shared memory, also add the following.
options SYSVSHM The linux system calls require 4.3BSD system
call compatibility. So make sure you have the following.
options "COMPAT_43"If you prefer to statically link the emulator in the kernel
rather than use the loadable kernel module (LKM), then add
options LINUX Then run config and install the new kernel as
described in the
section.If you decide to use the LKM you must also install the
loadable module. A mismatch of versions between the kernel and
loadable module can cause the kernel to crash, so the safest thing
to do is to reinstall the LKM when you install the kernel.
% cd /usr/src/lkm/linux % make all install Once you have installed the kernel and the LKM,
you can invoke `linux' as root to load the LKM.
% linux Linux emulator installed Module loaded as ID 0
% To see whether the LKM is loaded, run
`modstat'.
% modstat Type Id Off Loadaddr Size Info Rev
Module Name EXEC 0 3 f0baf000 0018 f0bb4000 1
linux_emulator % You can cause the LKM to be loaded when the
system boots in either of two ways. In FreeBSD 2.2.1-RELEASE and
2.1-STABLE enable it in /etc/sysconfiglinux=YES by changing it from NO to YES. FreeBSD 2.1
RELEASE and earlier do not have such a line and on those you will
need to edit /etc/rc.local to add the following line.
linuxInstalling Linux Emulation in 2.2.2-RELEASE and laterIt is no longer necessary to specify options LINUX or
options COMPAT_LINUX. Linux emulation is done with an LKM
(Loadable Kernel Module) so it can be installed on the fly
without having to reboot. You will need the following things in
your startup files, however:
In /etc/rc.conf, you need the
following line:
linux_enable=YES This, in turn, triggers the following action in
/etc/rc.i386:
# Start the Linux binary emulation if requested.
if [ "X${linux_enable}" = X"YES" ]; then echo -n '
linux'; linux > /dev/null 2>&1
fiIf you want to verify it is running, modstat will do that:
% modstat Type Id Off Loadaddr Size Info Rev
Module Name EXEC 0 4 f09e6000 001c f09ec010 1
linux_mod % However, there have been reports that this
fails on some 2.2-RELEASE and later systems. If for some reason
you cannot load the linux LKM, then statically link the emulator
in the kernel by adding
options LINUX to your kernel config file. Then run config
and install the new kernel as described in the section.Installing Linux Runtime LibrariesInstalling using the linux_lib portMost linux applications use shared libraries, so you are
still not done until you install the shared libraries. It is
possible to do this by hand, however, it is vastly simpler to
just grab the linux_lib port:
% cd /usr/ports-current/emulators/linux_lib % make all
installand you should have a working linux emulator. Legend (and
the mail archives :-) seems to hold that Linux emulation works
best with linux binaries linked against the ZMAGIC libraries;
QMAGIC libraries (such as those used in Slackware V2.0) may tend
to give the Linuxulator heartburn. As of this writing (March
1996) ELF emulation is still in the formulative stages but seems
to work pretty well. Also, expect some programs to complain
about incorrect minor versions. In general this does not seem
to be a problem.Installing libraries manuallyIf you do not have the ports distribution, you can
install the libraries by hand instead. You will need the Linux
shared libraries that the program depends on and the runtime
linker. Also, you will need to create a "shadow root"
directory, /compat/linux, for Linux
libraries on your FreeBSD system. Any shared libraries opened
by Linux programs run under FreeBSD will look in this tree
first. So, if a Linux program loads, for example,
/lib/libc.so, FreeBSD will first try to
open /compat/linux/lib/libc.so, and if that
does not exist then it will try
/lib/libc.so. Shared libraries should be
installed in the shadow tree
/compat/linux/lib rather than the paths
that the Linux ld.so reports.FreeBSD-2.2-RELEASE and later works slightly differently
with respect to /compat/linux. On -CURRENT, all files, not just
libraries, are searched for from the shadow root/compat/linux.Generally, you will need to look for the shared libraries
that Linux binaries depend on only the first few times that you
install a Linux program on your FreeBSD system. After a while,
you will have a sufficient set of Linux shared libraries on your
system to be able to run newly imported Linux binaries without
any extra work.How to install additional shared librariesWhat if you install the linux_lib port and your application
still complains about missing shared libraries? How do you know
which shared libraries Linux binaries need, and where to get
them? Basically, there are 2 possibilities (when following these
instructions: you will need to be root on your FreeBSD system to
do the necessary installation steps).If you have access to a Linux system, see what shared
libraries it needs, and copy them to your FreeBSD system.
Example: you have just ftp'ed the Linux binary of Doom. Put it
on the Linux system you have access to, and check which shared
libraries it needs by running `ldd linuxxdoom':% ldd linuxxdoom libXt.so.3 (DLL Jump 3.1) =>
/usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) =>
/usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26)
=> /lib/libc.so.4.6.29You would need to get all the files from the last column,
and put them under /compat/linux, with the
names in the first column as symbolic links pointing to them.
This means you eventually have these files on your FreeBSD
system:
/compat/linux/usr/X11/lib/libXt.so.3.1.0
/compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3.1.0
/compat/linux/usr/X11/lib/libX11.so.3 -> libX11.so.3.1.0
/compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4
-> libc.so.4.6.29Note that if you already have a Linux shared library with
a matching major revision number to the first column of the
'ldd' output, you will not need to copy the file named in the
last column to your system, the one you already have should
work. It is advisable to copy the shared library anyway if it
is a newer version, though. You can remove the old one, as
long as you make the symbolic link point to the new one. So,
if you have these libraries on your system:
/compat/linux/lib/libc.so.4.6.27
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27and you find a new binary that claims to require a later
version according to the output of ldd:
libc.so.4 (DLL Jump 4.5pl26) ->
libc.so.4.6.29If it is only one or two versions out of date in the in
the trailing digit then do not worry about copying
/lib/libc.so.4.6.29 too, because the
program should work fine with the slightly older version.
However, if you like you can decide to replace the
libc.so anyway, and that should leave you
with:
/compat/linux/lib/libc.so.4.6.29
/compat/linux/lib/libc.so.4 -> libc.so.4.6.29The symbolic link mechanism is only
needed for Linux binaries. The FreeBSD runtime linker takes
care of looking for matching major revision numbers itself and
you do not need to worry about it.Configuring the <filename>ld.so</filename> -- for FreeBSD
2.2-RELEASE onlyThis section applies only to FreeBSD 2.2-RELEASE and later.
Those running 2.1-STABLE should skip this section.Finally, if you run FreeBSD 2.2-RELEASE you must make sure
that you have the Linux runtime linker and its config files on
your system. You should copy these files from the Linux system
to their appropriate place on your FreeBSD system (to the
/compat/linux tree):
/compat/linux/lib/ld.so
/compat/linux/etc/ld.so.configIf you do not have access to a Linux system, you should get
the extra files you need from various ftp sites. Information on
where to look for the various files is appended below. For now,
let us assume you know where to get the files.Retrieve the following files (all from the same ftp site to
avoid any version mismatches), and install them under
/compat/linux (i.e.
/foo/bar is installed as
/compat/linux/foo/bar):
/sbin/ldconfig /usr/bin/ldd /lib/libc.so.x.y.z
/lib/ld.soldconfig and ldd do not necessarily need to be under
/compat/linux; you can install them
elsewhere in the system too. Just make sure they do not conflict
with their FreeBSD counterparts. A good idea would be to install
them in /usr/local/bin as ldconfig-linux
and ldd-linux.Create the file
/compat/linux/etc/ld.so.conf, containing
the directories in which the Linux runtime linker should look
for shared libs. It is a plain text file, containing a directory
name on each line. /lib and
/usr/lib are standard, you could add the
following:
/usr/X11/lib /usr/local/libWhen a linux binary opens a library such as
/lib/libc.so the emulator maps the name to
/compat/linux/lib/libc.so internally. All
linux libraries should be installed under /compat/linux (e.g.
/compat/linux/lib/libc.so,
/compat/linux/usr/X11/lib/libX11.so, etc.)
in order for the emulator to find them.Those running FreeBSD 2.2-RELEASE should run the Linux
ldconfig program.
% cd /compat/linux/lib % /compat/linux/sbin/ldconfig
Ldconfig is statically linked, so it does not need any
shared libraries to run. It creates the file
/compat/linux/etc/ld.so.cache which
contains the names of all the shared libraries and should be
rerun to recreate this file whenever you install additional
shared libraries.On 2.1-STABLE do not install
/compat/linux/etc/ld.so.cache or run
ldconfig; in 2.1-STABLE the syscalls are implemented differently
and ldconfig is not needed or used.You should now be set up for Linux binaries which only need
a shared libc. You can test this by running the Linux ldd on
itself. Supposing that you have it installed as ldd-linux, it
should produce something like:
% ldd-linux `which ldd-linux` libc.so.4 (DLL Jump
4.5pl26) => /lib/libc.so.4.6.29This being done, you are ready to install new Linux
binaries. Whenever you install a new Linux program, you should
check if it needs shared libraries, and if so, whether you have
them installed in the /compat/linux tree.
To do this, you run the Linux version ldd on the new program,
and watch its output. ldd (see also the manual page for ldd1)
will print a list of shared libraries that the program depends
on, in the form majorname (jumpversion) => fullname.If it prints "not found" instead of fullname it means that
you need an extra library. The library needed is shown in
majorname and will be of the form libXXXX.so.N. You will need to
find a libXXXX.so.N.mm on a Linux ftp site, and install it on
your system. The XXXX (name) and N (major revision number)
should match; the minor number(s) mm are less important, though
it is advised to take the most recent version.Configuring the host name resolverIf DNS does not work or you get the messages
resolv+: "bind" is an invalid keyword resolv+: "hosts"
is an invalid keywordthen you need to configure a
/compat/linux/etc/host.conf file containing:
order hosts, bind multi onwhere the order here specifies that
/etc/hosts is searched first and DNS is
searched second. When
/compat/linux/etc/host.conf is not installed
linux applications find FreeBSD's
/etc/host.conf and complain about the
incompatible FreeBSD syntax. You should remove `bind,' if you
have not configured a name-server using the
/etc/resolv.conf file.Lastly, those who run 2.1-STABLE need to set an the
RESOLV_HOST_CONF environment variable so that applications will
know how to search the host tables. If you run FreeBSD
2.2-RELEASE, you can skip this. For the
/bin/csh shell use:
setenv RESOLV_HOST_CONF
/compat/linux/etc/host.confFor /bin/sh use:
RESOLV_HOST_CONF=/compat/linux/etc/host.conf; export
RESOLV_HOST_CONFFinding the necessary filesThe information below is valid as of the time this document
was written, but certain details such as names of ftp sites,
directories and distribution names may have changed by the time
you read this.Linux is distributed by several groups that make their own set
of binaries that they distribute. Each distribution has its own
name, like Slackware or Yggdrasil. The distributions are
available on a lot of ftp sites. Sometimes the files are unpacked,
and you can get the individual files you need, but mostly they are
stored in distribution sets, usually consisting of subdirectories
with gzipped tar files in them. The primary ftp sites for the
distributions are:
sunsite.unc.edu:/pub/Linux/distributions
tsx-11.mit.edu:/pub/linux/distributionsSome European mirrors:
ftp.luth.se:/pub/linux/distributions
ftp.demon.co.uk:/pub/linux/distributions
src.doc.ic.ac.uk:/packages/linux/distributionsFor simplicity, let us concentrate on Slackware here. This
distribution consists of a number of subdirectories, containing
separate packages. Normally, they are controlled by an install
program, but you can retrieve files by hand too. First of all,
you will need to look in the contents subdir of the
distribution. You will find a lot of small text files here
describing the contents of the separate packages. The fastest way
to look something up is to retrieve all the files in the contents
subdirectory, and grep through them for the file you need. Here is
an example of a list of files that you might need, and in which
contents-file you will find it by grepping through them:
So, in this case, you will need the packages ldso, shlibs,
xf_lib and oldlibs. In each of the contents-files for these
packages, look for a line saying PACKAGE LOCATION, it will
tell you on which disk the package is, in our case it will tell
us in which subdirectory we need to look. For our example, we
would find the following locations:
Walnut Creek CDROM 4041 Pike Lane, Suite F Concord CA 94520 USA Phone: +1 925
674-0783 Fax: +1 925 674-0821 Email:
info@cdrom.com WWW: http://www.cdrom.com/
FTP SitesThe official sources for FreeBSD are available via anonymous FTP
from:
ftp://ftp.FreeBSD.ORG/pub/FreeBSD.
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.,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
.ArgentinaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.ar.FreeBSD.ORG/pub/FreeBSDAustraliaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.au.FreeBSD.ORG/pub/FreeBSDftp://ftp2.au.FreeBSD.ORG/pub/FreeBSDftp://ftp3.au.FreeBSD.ORG/pub/FreeBSDftp://ftp4.au.FreeBSD.ORG/pub/FreeBSDBrazilIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDftp://ftp2.br.FreeBSD.ORG/pub/FreeBSDftp://ftp3.br.FreeBSD.ORG/pub/FreeBSDftp://ftp4.br.FreeBSD.ORG/pub/FreeBSDftp://ftp5.br.FreeBSD.ORG/pub/FreeBSDftp://ftp6.br.FreeBSD.ORG/pub/FreeBSDftp://ftp7.br.FreeBSD.ORG/pub/FreeBSDCanadaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.ca.FreeBSD.ORG/pub/FreeBSDCzech Republicftp://sunsite.mff.cuni.cz/OS/FreeBSD Contact: jj@sunsite.mff.cuni.cz.
DenmarkIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.dk.freeBSD.ORG/pub/FreeBSDEstoniaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.ee.freebsd.ORG/pub/FreeBSDFinlandIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.fi.freebsd.ORG/pub/FreeBSDFranceftp://ftp.ibp.fr/pub/FreeBSD Contact: Remy.Card@ibp.fr.
GermanyIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.de.FreeBSD.ORG/pub/FreeBSDftp://ftp2.de.FreeBSD.ORG/pub/FreeBSDftp://ftp3.de.FreeBSD.ORG/pub/FreeBSDftp://ftp4.de.FreeBSD.ORG/pub/FreeBSDftp://ftp5.de.FreeBSD.ORG/pub/FreeBSDftp://ftp6.de.FreeBSD.ORG/pub/FreeBSDftp://ftp7.de.FreeBSD.ORG/pub/FreeBSDHong Kongftp://ftp.hk.super.net/pub/FreeBSD Contact: ftp-admin@HK.Super.NET.
IrelandIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.ie.FreeBSD.ORG/pub/FreeBSDIsraelIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.il.FreeBSD.ORG/pub/FreeBSDftp://ftp2.il.FreeBSD.ORG/pub/FreeBSDJapanIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp3.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp4.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp5.jp.FreeBSD.ORG/pub/FreeBSDftp://ftp6.jp.FreeBSD.ORG/pub/FreeBSDKoreaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.kr.FreeBSD.ORG/pub/FreeBSDftp://ftp2.kr.FreeBSD.ORG/pub/FreeBSDNetherlandsIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.nl.freebsd.ORG/pub/FreeBSDPolandIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.pl.freebsd.ORG/pub/FreeBSDPortugalIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.pt.freebsd.org/pub/FreeBSDftp://ftp2.pt.freebsd.org/pub/FreeBSDRussiaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.ru.freebsd.org/pub/FreeBSDftp://ftp2.ru.freebsd.org/pub/FreeBSDftp://ftp3.ru.freebsd.org/pub/FreeBSDSouth AfricaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.za.FreeBSD.ORG/pub/FreeBSDftp://ftp2.za.FreeBSD.ORG/pub/FreeBSDftp://ftp3.za.FreeBSD.ORG/pub/FreeBSDSloveniaIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.si.freebsd.ORG/pub/FreeBSDSwedenIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.se.freebsd.ORG/pub/FreeBSDTaiwanIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp2.tw.FreeBSD.ORG/pub/FreeBSDftp://ftp3.tw.FreeBSD.ORG/pub/FreeBSDThailandftp://ftp.nectec.or.th/pub/FreeBSD Contact: ftpadmin@ftp.nectec.or.th.
Ukraineftp://ftp.ua.FreeBSD.ORG/pub/FreeBSD Contact: archer@lucky.net.
UKIn case of problems, please contact the hostmaster
for this domain.ftp://ftp.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp2.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp3.uk.FreeBSD.ORG/pub/FreeBSDftp://ftp4.uk.FreeBSD.ORG/pub/FreeBSDUSAIn case of problems, please contact the hostmaster for
this domain.ftp://ftp.FreeBSD.ORG/pub/FreeBSDftp://ftp2.FreeBSD.ORG/pub/FreeBSDftp://ftp3.FreeBSD.ORG/pub/FreeBSDftp://ftp4.FreeBSD.ORG/pub/FreeBSDftp://ftp5.FreeBSD.ORG/pub/FreeBSDftp://ftp6.FreeBSD.ORG/pub/FreeBSDThe latest versions of export-restricted code for FreeBSD (2.0C
or later) (eBones and secure) are being made available at the
following locations. If you are outside the U.S. or Canada, please
get secure (DES) and eBones (Kerberos) from one of the following
foreign distribution sites:South AfricaHostmaster for this domain.ftp://ftp.internat.FreeBSD.ORG/pub/FreeBSDftp://ftp2.internat.FreeBSD.ORG/pub/FreeBSDBrazilHostmaster
for this domain.ftp://ftp.br.FreeBSD.ORG/pub/FreeBSDFinlandftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Contact: count@nic.funet.fi.
CTM Sites/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 sourceftp://ftp.freebsd.org/pub/FreeBSD/CTMGermany, Trierftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTMSouth Africa, backup server for old
deltasftp://ftp.internat.freebsd.org/pub/FreeBSD/CTMTaiwan/R.O.C, Chiayiftp://ctm.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm2.tw.freebsd.org/pub/FreeBSD/CTMftp://ctm3.tw.freebsd.org/pub/freebsd/CTMIf 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.CVSup Sites servers for FreeBSD are
running at the following sites:Argentinacvsup.ar.FreeBSD.ORG (maintainer)Australiacvsup.au.FreeBSD.ORG (maintainer)Brazilcvsup.br.FreeBSD.ORG (maintainer)Canadacvsup.ca.FreeBSD.ORG (maintainer)Estoniacvsup.ee.FreeBSD.ORG (maintainer)Finlandcvsup.fi.FreeBSD.ORG (maintainer)Germanycvsup.de.FreeBSD.ORG (maintainer)cvsup2.de.FreeBSD.ORG (maintainer)cvsup3.de.FreeBSD.ORG (maintainer)Japancvsup.jp.FreeBSD.ORG (maintainer)cvsup2.jp.FreeBSD.ORG (maintainer)Netherlandscvsup.nl.FreeBSD.ORG (maintainer)Norwaycvsup.no.FreeBSD.ORG (maintainer)Russiacvsup.ru.FreeBSD.ORG (maintainer)South Africacvsup.za.FreeBSD.ORG (maintainer)cvsup2.za.FreeBSD.ORG (maintainer)Taiwancvsup.tw.FreeBSD.ORG (maintainer)Ukrainecvsup2.ua.FreeBSD.ORG (maintainer)United Kingdomcvsup.uk.FreeBSD.ORG (maintainer)USAcvsup.FreeBSD.ORG (maintainer)cvsup2.FreeBSD.ORG (maintainer)cvsup3.FreeBSD.ORG (maintainer)The export-restricted code for FreeBSD (eBones and secure) is
available via CVSup at the following international repository.
Please use this site to get the export-restricted code, if you are
outside the USA or Canada.South Africacvsup.internat.FreeBSD.ORG (maintainer)The following CVSup site is especially designed for users. Unlike the other CVSup mirrors,
it is kept up-to-date by CTM. That means if you CVSup cvs-all with release=cvs
from this site, you get a version of the repository (including the
inevitable .ctm_status file) which is
suitable for being updated using the CTM cvs-cur deltas. This allows users who track
the entire cvs-all tree to go from
CVSup to CTM without having to rebuild their repository from scratch
using a fresh CTM base delta.This special feature only works for the cvs-all distribution with
cvs as the release tag. CVSupping any other
distribution and/or release will get you the specified
distribution, but it will not be suitable for CTM updating.Because the current version of CTM does not preserve the
timestamps of files, the timestamps at this mirror site are not
the same as those at other mirror sites. Switching between this
site and other sites is not recommended. It will work correctly,
but will be somewhat inefficient.Germanyctm.FreeBSD.ORG (maintainer)BibliographyWhile the manual pages provide the definitive reference for
individual pieces of the FreeBSD operating system, they are notorious
for not illustrating how to put the pieces together to make the whole
operating system run smoothly. For this, there is no substitute for a
good book on UNIX system administration and a good users'
manual.Books & Magazines Specific to FreeBSDInternational books &
Magazines:Using
FreeBSD (in Chinese).FreeBSD for PC 98'ers (in Japanese), published by SHUWA
System Co, LTD. ISBN 4-87966-468-5 C3055 P2900E.FreeBSD (in Japanese), published by CUTT. ISBN
4-906391-22-2 C3055 P2400E.Complete Introduction to FreeBSD (in Japanese), published by Shoeisha Co., Ltd. ISBN 4-88135-473-6 P3600E.Personal UNIX Starter Kit FreeBSD (in Japanese), published by ASCII. ISBN 4-7561-1733-3 P3000E.FreeBSD Handbook (Japanese translation), published by
ASCII. ISBN
4-7561-1580-2 P3800E.English language books &
Magazines:The
Complete FreeBSD, published by Walnut Creek
CDROM.Users' GuidesComputer Systems Research Group, UC Berkeley. 4.4BSD User's Reference Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-075-9Computer Systems Research Group, UC Berkeley. 4.4BSD User's Supplementary Documents.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-076-7UNIX in a Nutshell. O'Reilly
& Associates, Inc., 1990. ISBN
093717520XMui, Linda. What You Need To Know When You Can't
Find Your UNIX System Administrator. O'Reilly
& Associates, Inc., 1995. ISBN 1-56592-104-6
Ohio State
University has written a UNIX Introductory Course which is available online in HTML and postscript format.Administrators' GuidesAlbitz, Paul and Liu, Cricket. DNS and
BIND, 2nd Ed. O'Reilly & Associates, Inc.,
1997. ISBN 1-56592-236-0 Computer Systems Research Group, UC Berkeley. 4.4BSD System Manager's Manual. O'Reilly
& Associates, Inc., 1994. ISBN
1-56592-080-5Costales, Brian, et al. Sendmail, 2nd
Ed. O'Reilly & Associates, Inc., 1997. ISBN
1-56592-222-0 Frisch, Æleen. Essential System
Administration, 2nd Ed. O'Reilly &
Associates, Inc., 1995. ISBN 1-56592-127-5
Hunt, Craig. TCP/IP Network
Administration. O'Reilly & Associates, Inc.,
1992. ISBN 0-937175-82-XNemeth, Evi. UNIX System Administration
Handbook. 2nd ed. Prentice Hall, 1995. ISBN 0131510517Stern, Hal Managing NFS and NIS
O'Reilly & Associates, Inc., 1991. ISBN
0-937175-75-7Programmers' GuidesAsente, Paul. X Window System
Toolkit. Digital Press. ISBN
1-55558-051-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Reference Manual.
O'Reilly & Associates, Inc., 1994. ISBN
1-56592-078-3Computer Systems Research Group, UC Berkeley. 4.4BSD Programmer's Supplementary
Documents. O'Reilly & Associates, Inc., 1994.
ISBN 1-56592-079-1Ellis, Margaret A. and Stroustrup, Bjarne. The
Annotated C++ Reference Manual. Addison-Wesley,
1990. ISBN 0-201-51459-1Harbison, Samuel P. and Steele, Guy L. Jr. C: A
Reference Manual. 4rd ed. Prentice Hall, 1995.
ISBN 0-13-326224-3Kernighan, Brian and Dennis M. Ritchie. The C
Programming Language.. PTR Prentice Hall, 1988.
ISBN 0-13-110362-9Lehey, Greg. Port UNIX Software.
O'Reilly & Associates, Inc., 1995. ISBN
1-56592-126-7Plauger, P. J. The Standard C
Library. Prentice Hall, 1992. ISBN
0-13-131509-9Stevens, W. Richard. Advanced Programming in the
UNIX Environment. Reading, Mass. :
Addison-Wesley, 1992 ISBN 0-201-56317-7Stevens, W. Richard. UNIX Network
Programming. PTR Prentice Hall, 1990. ISBN 0-13-949876-1Wells, Bill. Writing Serial Drivers for UNIX.
Dr. Dobb's Journal. 19(15), December
1994. pp68-71, 97-99.Operating System InternalsAndleigh, Prabhat K. UNIX System
Architecture. Prentice-Hall, Inc., 1990. ISBN 0-13-949843-5Jolitz, William. Porting UNIX to the 386. Dr.
Dobb's Journal. January 1991-July 1992.Leffler, Samuel J., Marshall Kirk McKusick, Michael J
Karels and John Quarterman The Design and
Implementation of the 4.3BSD UNIX Operating
System. Reading, Mass. : Addison-Wesley,
1989. ISBN 0-201-06196-1Leffler, Samuel J., Marshall Kirk McKusick, The
Design and Implementation of the 4.3BSD UNIX Operating
System: Answer Book. Reading, Mass. :
Addison-Wesley, 1991. ISBN 0-201-54629-9McKusick, Marshall Kirk, Keith Bostic, Michael J Karels,
and John Quarterman. The Design and Implementation
of the 4.4BSD Operating System. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-54979-4Stevens, W. Richard. TCP/IP Illustrated, Volume
1: The Protocols. Reading, Mass. :
Addison-Wesley, 1996. ISBN 0-201-63346-9Stevens, W. Richard. TCP/IP Illustrated, Volume
3: TCP for Transactions, HTTP, NNTP and the UNIX Domain
Protocols. Reading, Mass. : Addison-Wesley,
1996. ISBN 0-201-63495-3Vahalia, Uresh. UNIX Internals -- The New
Frontiers. Prentice Hall, 1996. ISBN
0-13-101908-2Wright, Gary R. and W. Richard Stevens. TCP/IP
Illustrated, Volume 2: The Implementation.
Reading, Mass. : Addison-Wesley, 1995. ISBN
0-201-63354-XSecurity ReferenceCheswick, William R. and Steven M. Bellovin.
Firewalls and Internal Security: Repelling the Wily
Hacker. Reading, Mass. : Addison-Wesley,
1995. ISBN 0-201-63357-4 Garfinkel, Simson and Gene Spafford. Practical
UNIX Security. 2nd Ed. O'Reilly & Associates,
Inc., 1996. ISBN 1-56592-148-8 Garfinkel, Simson. PGP Pretty Good
Privacy O'Reilly & Associates, Inc., 1995.
ISBN 1-56592-098-8 Hardware ReferenceAnderson, Don and Tom Shanley. Pentium Processor
System Architecture. 2nd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40992-5Ferraro, Richard F. Programmer's Guide to the
EGA, VGA, and Super VGA Cards. 3rd ed. Reading,
Mass. : Addison-Wesley, 1995. ISBN
0-201-62490-7Shanley, Tom. 80486 System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40994-1Shanley, Tom. ISA System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40996-8Shanley, Tom. PCI System
Architecture. 3rd ed. Reading, Mass. :
Addison-Wesley, 1995. ISBN 0-201-40993-3Van Gilluwe, Frank. The Undocumented
PC. Reading, Mass: Addison-Wesley Pub. Co.,
1994. ISBN 0-201-62277-7UNIX HistoryLion, John Lion's Commentary on UNIX, 6th Ed.
With Source Code. ITP Media Group, 1996. ISBN 1573980137Raymond, Eric s. The New Hacker's Dictonary, 3rd
edition. MIT Press, 1996. ISBN
0-262-68092-0 Also known as the Jargon
FileSalus, Peter H. A quarter century of
UNIX. Addison-Wesley Publishing Company, Inc.,
1994. ISBN 0-201-54777-5Simon Garfinkel, Daniel Weise, Steven Strassmann.
The UNIX-HATERS Handbook. IDG Books
Worldwide, Inc., 1994. ISBN 1-56884-203-1Don Libes, Sandy Ressler Life with
UNIX - special edition. Prentice-Hall, Inc.,
1989. ISBN 0-13-536657-7The BSD family tree. 1997. http://www.de.freebsd.org/de/ftp/unix-stammbaum or local on a FreeBSD-current machine.The BSD Release Announcements
collection. 1997. http://www.de.FreeBSD.ORG/de/ftp/releases/Networked Computer Science Technical Reports
Library. http://www.ncstrl.org/Magazines and JournalsThe C/C++ Users Journal. R&D
Publications Inc. ISSN 1075-2838Sys Admin - The Journal for UNIX System
Administrators Miller Freeman, Inc., ISSN
1061-2688Resources on the InternetContributed by &a.jkh;.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 listsThough 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 summaryGeneral lists: The following are
general lists which anyone is free to join: List
Purpose
---------------------------------------------------------------------- freebsd-announce Important events and project milestones freebsd-bugs Bug reports freebsd-chat Non-technical items related to the FreeBSD community freebsd-current Discussion concerning the use of FreeBSD-current freebsd-stable Discussion concerning the use of FreeBSD-stable freebsd-isp Issues for Internet Service Providers using FreeBSD freebsd-jobs FreeBSD employment and consulting opportunities freebsd-questions User questionsTechnical 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-doc The FreeBSD Documentation project 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-isdn ISDN developers freebsd-java Java developers and people porting JDKs to FreeBSD freebsd-mobile Discussions about mobile computing freebsd-multimedia Multimedia discussion freebsd-platforms Concerning ports to non-Intel architecture platforms freebsd-ports Discussion of the ports collection freebsd-scsi The SCSI subsystem freebsd-security Security issues freebsd-smp Design discussions for [A]Symmetric MultiProcessing freebsd-sparc Porting FreeBSD to Sparc systems.Limited lists: The following
lists require approval from core@FreeBSD.ORG to join,
though anyone is free to send messages to them which fall within
the scope of their charters. It is also a good idea establish a
presence in the technical lists before asking to join one of these
limited lists. List Purpose
---------------------------------------------------------------------- freebsd-admin Administrative issues freebsd-arch Architecture and design discussions freebsd-core FreeBSD core team freebsd-hubs People running mirror sites (infrastructural support) freebsd-install Installation development freebsd-security-notifications Security notifications freebsd-user-groups User group coordinationCVS 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 name Source area Area
Description (source for)
---------------------------------------------------------------------- cvs-CVSROOT /usr/src/[A-Z]* Top level /usr/src file changes cvs-all /usr/src All changes to the tree (superset) cvs-bin /usr/src/bin System binaries cvs-etc /usr/src/etc System files cvs-games /usr/src/games Games cvs-gnu /usr/src/gnu GPL'd utilities cvs-include /usr/src/include Include files cvs-kerberosIV /usr/src/kerberosIV Kerberos encryption code cvs-lib /usr/src/lib System libraries cvs-libexec /usr/src/libexec System binaries cvs-ports /usr/ports Ported software cvs-sbin /usr/src/sbin System binaries cvs-share /usr/src/share System shared files cvs-sys /usr/src/sys Kernel cvs-usrbin /usr/src/usr.bin Use binaries cvs-usrsbin /usr/src/usr.sbin System binariesHow to subscribeAll 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:
% 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 (note: this is more efficient if you have several
interested parties at one site, and highly appreciated by us!),
you would do something like:
% 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:
% 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 the high points then it is
suggested that you join freebsd-announce, which is intended only
for infrequent traffic.List chartersAllFreeBSD 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, 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
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 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-AFSAndrew File System
This list is for discussion on porting and using AFS from
CMU/TransarcFREEBSD-ADMINAdministrative issues This list is purely for discussion of freebsd.org
related issues and to report problems or abuse of project
resources. It is a closed list, though anyone may report
a problem (with our systems!) to it.FREEBSD-ANNOUNCEImportant 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-ARCHArchitecture and design
discussions This is the mailing
list for people discussing FreeBSD architectural issues.
It is a closed list, and not for general
subscription.FREEBSD-BUGSBug reports This is
the mailing list for reporting bugs in FreeBSD Whenever
possible, bugs should be submitted using the send-pr1
command or the WEB
interface to it.FREEBSD-CHATNon 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-COREFreeBSD 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-CURRENTDiscussions 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-DIGESTDiscussions 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. The
average digest size is about 40kB. This list is Read-Only and should not be posted
to.FREEBSD-STABLEDiscussions 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-DOCDocumentation project This mailing list belongs to the FreeBSD Doc Project
and is for the discussion of documentation related issues
and projects.FREEBSD-FSFilesystems
Discussions concerning FreeBSD filesystems. This is a
technical mailing list for which strictly technical
content is expected.FREEBSD-ISDNISDN Communications
This is the mailing list for people discussing the
development of ISDN support for FreeBSD.FREEBSD-JAVAJava 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-HACKERSTechnical 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-DIGESTTechnical 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. The average digest size is about 40kB.
This list is Read-Only and
should not be posted to.FREEBSD-HARDWAREGeneral 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-INSTALLInstallation discussion This mailing list is for discussing FreeBSD
installation development for the future releases and is
closed.FREEBSD-ISPIssues 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-MULTIMEDIAMultimedia discussions This is a forum about multimedia applications using
FreeBSD. Discussion center around multimedia applications,
their installation, their development and their support
within FreeBSD This is a technical mailing list for which
strictly technical content is expected.FREEBSD-PLATFORMSPorting 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-PORTSDiscussion 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-QUESTIONSUser 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-DIGESTUser 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. The average digest size is about
40kB.FREEBSD-SCSISCSI 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-SECURITYSecurity 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-NOTIFICATIONSSecurity Notifications Notifications of FreeBSD security problems and fixes.
This is not a discussion list. The discussion list is
FreeBSD-security.FREEBSD-USER-GROUPSUser 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. It is a closed list.Usenet newsgroupsIn 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.oz.au>.BSD specific newsgroupscomp.unix.bsd.freebsd.announcecomp.unix.bsd.freebsd.miscOther Unix newsgroups of interestcomp.unixcomp.unix.questionscomp.unix.admincomp.unix.programmercomp.unix.shellcomp.unix.user-friendlycomp.security.unixcomp.sources.unixcomp.unix.advocacycomp.unix.misccomp.os.386bsd.announccomp.os.386bsd.appcomp.os.386bsd.bugscomp.os.386bsd.developmentcomp.os.386bsd.misccomp.os.386bsd.questionscomp.bugs.4bsdcomp.bugs.4bsd.ucb-fixescomp.unix.bsdX Window Systemcomp.windows.x.i386unixcomp.windows.xcomp.windows.x.appscomp.windows.x.announcecomp.windows.x.intrinsicscomp.windows.x.motifcomp.windows.x.pexcomp.emulators.ms-windows.wineWorld Wide Web servershttp://www.FreeBSD.ORG/ .http://www.au.freebsd.org/FreeBSD/ .http://www.br.freebsd.org/ .http://www.ca.freebsd.org/ .http://sunsite.mff.cuni.cz/www.freebsd.org/.http://sunsite.auc.dk/www.freebsd.org/ .http://www.ee.freebsd.org/ .http://www.fi.freebsd.org/ .http://www.de.freebsd.org/ .http://www.ie.freebsd.org/ .http://www.jp.freebsd.org/ .http://www.kr.freebsd.org/ .http://www.nl.freebsd.org/ .http://www.pt.freebsd.org/ .http://www.se.freebsd.org/www.freebsd.org/ .http://www.tw.freebsd.org/freebsd.html .http://www2.ua.freebsd.org/ .FreeBSD Project StaffThe FreeBSD Project is managed and operated by the following
groups of people:The FreeBSD Core TeamThe FreeBSD core team constitutes the project's Board of
Directors, responsible for deciding the project's overall goals
and direction as well as managing of the FreeBSD project landscape.(in alphabetical order by last name):&a.asami;&a.jmb;&a.ache;&a.dyson;&a.bde;&a.gibbs;&a.davidg;&a.jkh;&a.phk;&a.rich;&a.gpalmer;&a.jdp;&a.guido;&a.sos;&a.peter;&a.wollman;&a.joerg;The FreeBSD DevelopersThese are the people who have commit privileges and do the
engineering work on the FreeBSD source tree. All core team members
and most FreeBSD Documentation project personnel are also
developers.&a.mbarkah;&a.stb;&a.jb;&a.torstenb;&a.danny;&a.charnier;&a.kjc;&a.gclarkii;&a.cracauer;&a.adam;&a.dufault;&a.uhclem;&a.tegge;&a.eivind;&a.julian;&a.rse; &a.se; &a.sef;&a.fenner;&a.jfieber;&a.jfitz;&a.lars;&a.scrappy;&a.tg;&a.brandon;&a.graichen;&a.jgreco;&a.rgrimes;&a.jmg;&a.hanai;&a.ahasty;&a.jhay;&a.helbig;&a.erich;&a.hsu;&a.itojun;&a.ugen;&a.gj;&a.nsj;&a.ljo;&a.kato;&a.andreas;&a.imp;&a.smace;&a.mckay;&a.jlemon;&a.tedm;&a.amurai;&a.markm;&a.max;&a.alex;&a.davidn;&a.obrien;&a.fsmp; &a.smpatel;&a.wpaul; &a.jmacd; &a.steve; &a.mpp;&a.dfr; &a.jraynard;&a.darrenr;&a.csgr;&a.martin;&a.paul;&a.roberto;&a.chuckr;&a.dima;&a.wosch;&a.ats;&a.jseger;&a.vanilla;&a.msmith;&a.brian; &a.stark;&a.karl;&a.cwt;&a.pst;&a.hoek;&a.swallace;&a.nate;&a.yokota;&a.jmz; &a.hosokawa; The FreeBSD Documentation Project
The FreeBSD
Documentation Project is responsible for a number of
different services, each service being run by an individual and his
deputies (if any):Documentation Project Manager&a.jfieber;Webmaster&a.mbarkah;Deputy: &a.paul;Handbook & FAQ Editor&a.faq;Build Engineer&a.paul;Deputy: &a.dave;Mirror Manager&a.ulf;Deputy: &a.john;News Editor&a.nsj;Deputy: &a.john;Gallery and Commercial Editor&a.nsj;Deputy: &a.cawimm;Style Police & Art Director&a.dave;Deputy: &a.opsys;Database Engineer&a.mayo;Deputy: &a.cracauer;CGI Engineer&a.cracauer;Deputy: &a.stb;Bottle Washing&a.nsj;Drying plates: &a.nik;Who Is Responsible for WhatPrincipal Architect&a.davidg; Documentation Project Manager&a.jfieber;Internationalization&a.ache; Networking&a.wollman; Postmaster&a.jmb; Release Coordinator&a.jkh; Public Relations & Corporate
Liaison&a.jkh; Security Officer&a.guido;Source Repository ManagersPrincipal: &a.peter; Assistant: &a.jdp; International (Crypto): &a.markm;Ports Manager&a.asami; XFree86 Project, Inc. Liaison&a.rich; Usenet Support&a.joerg;GNATS Administrator&a.steve;PGP keys In case you need to verify a signature or send encrypted email to
one of the officers or core team members a number of keys are
provided here for your convenience.OfficersFreeBSD Security Officer <security-officer@freebsd.org>
FreeBSD Security Officer
<security-officer@freebsd.org> Fingerprint = 41 08 4E BB
DB 41 60 71 F9 E5 0E 98 73 AF 3F 11 -----BEGIN PGP PUBLIC KEY
BLOCK----- Version: 2.6.3i
mQCNAzF7MY4AAAEEAK7qBgPuBejER5HQbQlsOldk3ZVWXlRj54raz3IbuAUrDrQL h3g57T9QY++f3Mot2LAf5lDJbsMfWrtwPrPwCCFRYQd6XH778a+l4ju5axyjrt/L Ciw9RrOC+WaPv3lIdLuqYge2QRC1LvKACIPNbIcgbnLeRGLovFUuHi5z0oilAAUR tDdGcmVlQlNEIFNlY3VyaXR5IE9mZmljZXIgPHNlY3VyaXR5LW9mZmljZXJAZnJl ZWJzZC5vcmc+iQCVAwUQMX6yrOJgpPLZnQjrAQHyowQA1Nv2AY8vJIrdp2ttV6RU tZBYnI7gTO3sFC2bhIHsCvfVU3JphfqWQ7AnTXcD2yPjGcchUfc/EcL1tSlqW4y7 PMP4GHZp9vHog1NAsgLC9Y1P/1cOeuhZ0pDpZZ5zxTo6TQcCBjQA6KhiBFP4TJql 3olFfPBh3B/Tu3dqmEbSWpuJAJUDBRAxez3C9RVb+45ULV0BAak8A/9JIG/jRJaz QbKom6wMw852C/Z0qBLJy7KdN30099zMjQYeC9PnlkZ0USjQ4TSpC8UerYv6IfhV nNY6gyF2Hx4CbEFlopnfA1c4yxtXKti1kSN6wBy/ki3SmqtfDhPQ4Q31p63cSe5A 3aoHcjvWuqPLpW4ba2uHVKGP3g7SSt6AOYkAlQMFEDF8mz0ff6kIA1j8vQEBmZcD /REaUPDRx6qr1XRQlMs6pfgNKEwnKmcUzQLCvKBnYYGmD5ydPLxCPSFnPcPthaUb 5zVgMTjfjS2fkEiRrua4duGRgqN4xY7VRAsIQeMSITBOZeBZZf2oa9Ntidr5PumS 9uQ9bvdfWMpsemk2MaRG9BSoy5Wvy8VxROYYUwpT8Cf2iQCVAwUQMXsyqWtaZ42B sqd5AQHKjAQAvolI30Nyu3IyTfNeCb/DvOe9tlOn/o+VUDNJiE/PuBe1s2Y94a/P BfcohpKC2kza3NiW6lLTp00OWQsuu0QAPc02vYOyseZWy4y3Phnw60pWzLcFdemT 0GiYS5Xm1o9nAhPFciybn9j1q8UadIlIq0wbqWgdInBT8YI/l4f5sf6JAJUDBRAx ezKXVS4eLnPSiKUBAc5OBACIXTlKqQC3B53qt7bNMV46m81fuw1PhKaJEI033mCD ovzyEFFQeOyRXeu25Jg9Bq0Sn37ynISucHSmt2tUD5W0+p1MUGyTqnfqejMUWBzO v4Xhp6a8RtDdUMBOTtro16iulGiRrCKxzVgEl4i+9Z0ZiE6BWlg5AetoF5n3mGk1 lw== =ipyA -----END PGP PUBLIC KEY BLOCK-----&a.imp;Warner Losh <imp@village.org> aka
<imp@freebsd.org> Fingerprint = D4 31 FD B9 F7 90 17 E8
37 C5 E7 7F CF A6 C1 B9 -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzDzTiAAAAEEAK8D7KWEbVFUrmlqhUEnAvphNIqHEbqqT8s+c5f5c2uHtlcH V4mV2TlUaDSVBN4+/D70oHmZc4IgiQwMPCWRrSezg9z/MaKlWhaslc8YT6Xc1q+o EP/fAdKUrq49H0QQbkQk6Ks5wKW6v9AOvdmsS6ZJEcet6d9G4dxynu/2qPVhAAUR tCBNLiBXYXJuZXIgTG9zaCA8aW1wQHZpbGxhZ2Uub3JnPokAlQMFEDM/SK1VLh4u c9KIpQEBFPsD/1n0YuuUPvD4CismZ9bx9M84y5sxLolgFEfP9Ux196ZSeaPpkA0g C9YX/IyIy5VHh3372SDWN5iVSDYPwtCmZziwIV2YxzPtZw0nUu82P/Fn8ynlCSWB 5povLZmgrWijTJdnUWI0ApVBUTQoiW5MyrNN51H3HLWXGoXMgQFZXKWYiQCVAwUQ MzmhkfUVW/uOVC1dAQG3+AP/T1HL/5EYF0ij0yQmNTzt1cLt0b1e3N3zN/wPFFWs BfrQ+nsv1zw7cEgxLtktk73wBGM9jUIdJu8phgLtl5a0m9UjBq5oxrJaNJr6UTxN a+sFkapTLT1g84UFUO/+8qRB12v+hZr2WeXMYjHAFUT18mp3xwjW9DUV+2fW1Wag YDKJAJUDBRAzOYK1s1pi61mfMj0BARBbA/930CHswOF0HIr+4YYUs1ejDnZ2J3zn icTZhl9uAfEQq++Xor1x476j67Z9fESxyHltUxCmwxsJ1uOJRwzjyEoMlyFrIN4C dE0C8g8BF+sRTt7VLURLERvlBvFrVZueXSnXvmMoWFnqpSpt3EmN6TNaLe8Cm87a k6EvQy0dpnkPKokAlQMFEDD9Lorccp7v9qj1YQEBrRUD/3N4cCMWjzsIFp2Vh9y+ RzUrblyF84tJyA7Rr1p+A7dxf7je3Zx5QMEXosWL1WGnS5vC9YH2WZwv6sCU61gU rSy9z8KHlBEHh+Z6fdRMrjd9byPf+n3cktT0NhS23oXB1ZhNZcB2KKhVPlNctMqO 3gTYx+Nlo6xqjR+J2NnBYU8p =7fQV -----END PGP PUBLIC KEY BLOCK-----Core Team members&a.asami;Satoshi Asami <asami@cs.berkeley.edu> aka
<asami@FreeBSD.ORG> Fingerprint = EB 3C 68 9E FB 6C EB
3F DB 2E 0F 10 8F CE 79 CA -----BEGIN PGP PUBLIC KEY
BLOCK----- Version: 2.6.2
mQCNAzPVyoQAAAEEAL7W+kipxB171Z4SVyyL9skaA7hG3eRsSOWk7lfvfUBLtPog f3OKwrApoc/jwLf4+Qpdzv5DLEt/6Hd/clskhJ+q1gMNHyZ5ABmUxrTRRNvJMTrb 3fPU3oZj7sL/MyiFaT1zF8EaMP/iS2ZtcFsbYOqGeA8E/58uk4NA0SoeCNiJAAUR tCVTYXRvc2hpIEFzYW1pIDxhc2FtaUBjcy5iZXJrZWxleS5lZHU+iQCVAwUQM/AT +EqGN2HYnOMZAQF11QP/eSXb2FuTb1yX5yoo1Im8YnIk1SEgCGbyEbOMMBznVNDy 5g2TAD0ofLxPxy5Vodjg8rf+lfMVtO5amUH6aNcORXRncE83T10JmeM6JEp0T6jw zOHKz8jRzygYLBayGsNIJ4BGxa4LeaGxJpO1ZEvRlNkPH/YEXK5oQmq9/DlrtYOJ AEUDBRAz42JT8ng6GBbVvu0BAU8nAYCsJ8PiJpRUGlrz6rxjX8hqM1v3vqFHLcG+ G52nVMBSy+RZBgzsYIPwI5EZtWAKb22JAJUDBRAz4QBWdbtuOHaj97EBAaQPA/46 +NLUp+Wubl90JoonoXocwAg88tvAUVSzsxPXj0lvypAiSI2AJKsmn+5PuQ+/IoQy lywRsxiQ5GD7C72SZ1yw2WI9DWFeAi+qa4b8n9fcLYrnHpyCY+zxEpu4pam8FJ7H JocEUZz5HRoKKOLHErzXDiuTkkm72b1glmCqAQvnB4kAlQMFEDPZ3gyDQNEqHgjY iQEBFfUEALu2C0uo+1Z7C5+xshWRYY5xNCzK20O6bANVJ+CO2fih96KhwsMof3lw fDso5HJSwgFd8WT/sR+Wwzz6BAE5UtgsQq5GcsdYQuGI1yIlCYUpDp5sgswNm+OA bX5a+r4F/ZJqrqT1J56Mer0VVsNfe5nIRsjd/rnFAFVfjcQtaQmjiQCVAwUQM9uV mcdm8Q+/vPRJAQELHgP9GqNiMpLQlZig17fDnCJ73P0e5t/hRLFehZDlmEI2TK7j Yeqbw078nZgyyuljZ7YsbstRIsWVCxobX5eH1kX+hIxuUqCAkCsWUY4abG89kHJr XGQn6X1CX7xbZ+b6b9jLK+bJKFcLSfyqR3M2eCyscSiZYkWKQ5l3FYvbUzkeb6K0 IVNhdG9zaGkgQXNhbWkgPGFzYW1pQEZyZWVCU0QuT1JHPg== =39SC -----END PGP PUBLIC KEY BLOCK-----&a.jmb;Jonathan M. Bresler <jmb@FreeBSD.org> Key
fingerprint = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E
FB -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNA3x ffUVW/uOVC1dAQHGdAQAgsnYklBtVUdGuQwXB3bYp9omTD7CVD0aibVrz+lXiPDh aTVkOC1uhEwL59+R8VdpAnEDMobdZDA/ihCc+6/FW/eE0uyrWZzb5Ng9V1MfC6HI +sXpeXPy585Z56ewadV2yY9rvzcwmmUNHmAXT/5O0S2AWB0EJZ+cewTrokSTVVOJ AJUDBRA0C3EoVS4eLnPSiKUBASb+A/95g6w9DDPRGDlbsl4pN1BlSPKrmDQPRK1X C3bddDY2HNelSNhzp2FYD0WoN1re1vMJV0oaaJHwv7wjbe3+SYEX/IdmtfzI0MbZ Q/uPybPJOxi2ud6C6J+mEGJN9iBCnsaCz8CETuC9gR1mtxsxySUj9mk0fxKfdP6S 3QDrv6CQ1IkAlQMFEDKsi9CzWmLrWZ8yPQEBduUD/RhV4Qa89rYls9vtIFm6XBjZ 8mW37FYxeqIxg3ZrIyTMlghsOPV0f7zymCCWPRGKOLePRiGo0ZCEkDTYiM9tnwQI 09rmPWJb50yfTSZXjHx6+Hcm6O6BCmDFloo0Mxo6n9pvMH/TmmqHxCsAV+p8XEWy rMZvwVSynMxmJd17Y5HLtBNKb25hdGhhbiBNLiBCcmVzbGVyiQCVAwUQMbYtYQHb XdKX5jjdAQHEHwP/fEaQoTi7zKD1U/5kW2YPIBUyMTpLiO9QOr4stYjJvhHh4Ejw fGvMIhbFrPKtxSNH1s3m4jAXKXiQBDCz17IIzL4n8dlunxNGE5MHcsmpWzggyIg4 zbPqPOcg4gLFEWsEkr2o0akwzIGa3tbCvC+ITaX/rdlWV1jaQjTqSNyPZBM= =RV56 -----END PGP PUBLIC KEY BLOCK-----&a.ache;Andrey A. Chernov <ache@FreeBSD.org> aka
<ache@nagual.pp.ru> Key fingerprint = 33 03 9F 48 33 7B
4A 15 63 48 88 0A C4 97 FD 49 -----BEGIN PGP PUBLIC KEY
BLOCK----- Version: 2.6.3ia
mQCNAiqUMGQAAAEEAPGhcD6A2Buey5LYz0sphDLpVgOZc/bb9UHAbaGKUAGXmafs Dcb2HnsuYGgX/zrQXuCi/wIGtXcZWB97APtKOhFsZnPinDR5n/dde/mw9FnuhwqD m+rKSL1HlN0z/Msa5y7g16760wHhSR6NoBSEG5wQAHIMMq7Q0uJgpPLZnQjrAAUT tCVBbmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucHAucnU+iQCVAwUQM2Ez u+JgpPLZnQjrAQEyugP8DPnS8ixJ5OeuYgPFQf5sy6l+LrB6hyaS+lgsUPahWjNY cnaDmfda/q/BV5d4+y5rlQe/pjnYG7/yQuAR3jhlXz8XDrqlBOnW9AtYjDt5rMfJ aGFTGXAPGZ6k6zQZE0/YurT8ia3qjvuZm3Fw4NJrHRx7ETHRvVJDvxA6Ggsvmr20 JEFuZHJleSBBLiBDaGVybm92IDxhY2hlQEZyZWVCU0Qub3JnPokAlQMFEDR5uVbi YKTy2Z0I6wEBLgED/2mn+hw4/3peLx0Sb9LNx//NfCCkVefSf2G9Qwhx6dvwbX7h mFca97h7BQN4GubU1Z5Ffs6TeamSBrotBYGmOCwvJ6S9WigF9YHQIQ3B4LEjskAt pcjU583y42zM11kkvEuQU2Gde61daIylJyOxsgpjSWpkxq50fgY2kLMfgl/ftCZB bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuaWV0enNjaGUubmV0PokAlQMFEDR5svDi YKTy2Z0I6wEBOTQD/0OTCAXIjuak363mjERvzSkVsNtIH9hA1l0w6Z95+iH0fHrW xXKT0vBZE0y0Em+S3cotLL0bMmVE3F3D3GyxhBVmgzjyx0NYNoiQjYdi+6g/PV30 Cn4vOO6hBBpSyI6vY6qGNqcsawuRtHNvK/53MpOfKwSlICEBYQimcZhkci+EtCJB bmRyZXkgQS4gQ2hlcm5vdiA8YWNoZUBuYWd1YWwucnU+iQCVAwUQMcm5HeJgpPLZ nQjrAQHwvQP9GdmAf1gdcuayHEgNkc11macPH11cwWjYjzA2YoecFMGV7iqKK8QY rr1MjbGXf8DAG8Ubfm0QbI8Lj8iG3NgqIru0c72UuHGSn/APfGGG0AtPX5UK/k7B gI0Ca2po6NA5nrSp8tDsdEz/4gyea84RXl2prtTf5Jj07hflbRstGXK0MkFuZHJl eSBBLiBDaGVybm92LCBCbGFjayBNYWdlIDxhY2hlQGFzdHJhbC5tc2suc3U+iQCV AwUQMCsAo5/rGryoL8h3AQHq1QQAidyNFqA9hvrmMcjpY7csJVFlGvj574Wj4GPa o3pZeuQaMBmsWqaXLYnWU/Aldb6kTz6+nRcQX50zFH0THSPfApwEW7yybSTI5apJ mWT3qhKN2vmLNg2yNzhqLTzHLD1lH3i1pfQq8WevrNfjLUco5S/VuekTma/osnzC Cw7fQzCJAJUDBRAwKvwoa1pnjYGyp3kBARihBACoXr3qfG65hFCyKJISmjOvaoGr anxUIkeDS0yQdTHzhQ+dwB1OhhK15E0Nwr0MKajLMm90n6+Zdb5y/FIjpPriu8dI rlHrWZlewa88eEDM+Q/NxT1iYg+HaKDAE171jmLpSpCL0MiJtO0i36L3ekVD7Hv8 vffOZHPSHirIzJOZTYkAlQMFEDAau6zFLUdtDb+QbQEBQX8D/AxwkYeFaYxZYMFO DHIvSk23hAsjCmUA2Uil1FeWAusb+o8xRfPDc7TnosrIifJqbF5+fcHCG5VSTGlh Bhd18YWUeabf/h9O2BsQX55yWRuB2x3diJ1xI/VVdG+rxlMCmE4ZR1Tl9x+Mtun9 KqKVpB39VlkCBYQ3hlgNt/TJUY4riQCVAwUQMBHMmyJRltlmbQBRAQFQkwP/YC3a hs3ZMMoriOlt3ZxGNUUPTF7rIER3j+c7mqGG46dEnDB5sUrkzacpoLX5sj1tGR3b vz9a4vmk1Av3KFNNvrZZ3/BZFGpq3mCTiAC9zsyNYQ8L0AfGIUO5goCIjqwOTNQI AOpNsJ5S+nMAkQB4YmmNlI6GTb3D18zfhPZ6uciJAJUCBRAwD0sl4uW74fteFRkB AWsAA/9NYqBRBKbmltQDpyK4+jBAYjkXBJmARFXKJYTlnTgOHMpZqoVyW96xnaa5 MzxEiu7ZWm5oL10QDIp1krkBP2KcmvfSMMHb5aGCCQc2/P8NlfXAuHtNGzYiI0UA Iwi8ih/S1liVfvnqF9uV3d3koE7VsQ9OA4Qo0ZL2ggW+/gEaYIkAlQMFEDAOz6qx /IyHe3rl4QEBIvYD/jIr8Xqo/2I5gncghSeFR01n0vELFIvaF4cHofGzyzBpYsfA +6pgFI1IM+LUF3kbUkAY/2uSf9U5ECcaMCTWCwVgJVO+oG075SHEM4buhrzutZiM 1dTyTaepaPpTyRMUUx9ZMMYJs7sbqLId1eDwrJxUPhrBNvf/w2W2sYHSY8cdiQCV AwUQMAzqgHcdkq6JcsfBAQGTxwQAtgeLFi2rhSOdllpDXUwz+SS6bEjFTWgRsWFM y9QnOcqryw7LyuFmWein4jasjY033JsODfWQPiPVNA3UEnXVg9+n8AvNMPO8JkRv Cn1eNg0VaJy9J368uArio93agd2Yf/R5r+QEuPjIssVk8hdcy/luEhSiXWf6bLMV HEA0J+OJAJUDBRAwDUi+4mCk8tmdCOsBAatBBACHB+qtW880seRCDZLjl/bT1b14 5po60U7u6a3PEBkY0NA72tWDQuRPF/Cn/0+VdFNxQUsgkrbwaJWOoi0KQsvlOm3R rsxKbn9uvEKLxExyKH3pxp76kvz/lEWwEeKvBK+84Pb1lzpG3W7u2XDfi3VQPTi3 5SZMAHc6C0Ct/mjNlYkAlQMFEDAMrPD7wj+NsTMUOQEBJckD/ik4WsZzm2qOx9Fw erGq7Zwchc+Jq1YeN5PxpzqSf4AG7+7dFIn+oe6X2FcIzgbYY+IfmgJIHEVjDHH5 +uAXyb6l4iKc89eQawO3t88pfHLJWbTzmnvgz2cMrxt94HRvgkHfvcpGEgbyldq6 EB33OunazFcfZFRIcXk1sfyLDvYE =1ahV -----END PGP PUBLIC KEY BLOCK-----&a.jkh;Jordan K. Hubbard <jkh@FreeBSD.org> Fingerprint =
3C F2 27 7E 4A 6C 09 0A 4B C9 47 CD 4F 4D 0B 20 -----BEGIN
PGP PUBLIC KEY BLOCK----- Version: 2.6.2i
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokAlQMFEDF75D1r WmeNgbKneQEBXtcD+gJIv8JzZRKlDZyTCQanK8iRgE+zMhxptI0kDObaGxT1BrpY 4/EPyiUN10G4k2Jb+DOc8Lg2xDQ3xmvgipFf9NMNV/ThaEuZ3wA31I6tW/arQEqB Tp8u6T3v20m62t7Afo9HaoE6MBpHQUk2TilxgAd5P57sporL3pgW9YojIO9ziQCV AwUQMXyV2h9/qQgDWPy9AQEMfgP/RmbSg2WlesATUQ4WuanjcdREduKPyfQatrXD 2xt+jg9X78dTyiNN1YvLqvT6msfs04MKSC0hA2mou6ozw8Xak+1QmP0fBOZKp9pP 8szO188Do9ByzJPvHF1eXT7jFMOXVq8ZIl9iwjxcIDLzlxOz49DC7LO6AT+LKQk7 UGeP+lqJAJUDBRAxe+UG9RVb+45ULV0BAXZ9A/9F9gLpGukVNkeOjaqxQdJGTS+a xh/Abk0c/nKhAEyxpAl5JyQ3ifYk6BHhPvlTi9LrZoXGA8sk/eU4eRTZVzvGEC4G +xsavlE/xzku8855QTLPpkCunUpQeu1wzaIrUUE6Zjh05imFbJYyQOBgTFpuqWsC rsUpl+2mr8IGIxG5rA== =LW9i -----END PGP PUBLIC KEY BLOCK-----&a.phk;Poul-Henning Kamp <phk@FreeBSD.org> Fingerprint =
A3 F3 88 28 2F 9B 99 A2 49 F4 E2 FA 5A 78 8B 3E -----BEGIN
PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia
mQCNAzAdpMIAAAEEALHDgrFUwhZtb7PbXg3upELoDVEUPFRwnmpJH1rRqyROUGcI ooVe7u+FQlIs5OsXK8ECs/5Wpe2UrZSzHvjwBYOND5H42YtI5UULZLRCo5bFfTVA K9Rpo5icfTsYihrzU2nmnycwFMk+jYXyT/ZDYWDP/BM9iLjj0x9/qQgDWPy9AAUR tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDMGK9qz WmLrWZ8yPQEB4iED/18bQVhV2gUYFSxIUTaUtO2HVPi7GRpSzmXoTfS+FJyRR0ED zTqTHstoBe2PeWgTsOf9cUub5UKcJkRQp7VrJv4Kncyuq7pX69a+QMveCzuUwAur nDbt/emOL6NU8g9Uk50QuOuipb5rULQLRRoF5TkViy/VES83ERXdYQ9Ml3fWiQCV AwUQMX6NfWtaZ42Bsqd5AQEKsgP+L+uLz95dRdEmnZ+omrO+tYZM/0jHU7i8yC5q H0gguKOCljI4liR7NkqKONUJWYtfsTB81d9iSosBZRrTx6i/hB8l8kOB975n/f9S hftFwmjLYCNMFlDM4j0kySvMV20UZjAyv9BeE51VWlIZ5n/oeSuzul3Znow02tF/ zVnInJiJAJUDBRAxfJXn9RVb+45ULV0BAXJ8A/9K6NT6VLZZC5q3g7bBk5DWuzBS 3oK2Ebww6xzsD2R9edltoz1J3GPngK0CWpHh4kw5iTaRWoC2YJYRNG6icnGvlMAl 1/urqQHJVhxATINm8oljDKsj1RBJ6VKBzNbCJIHTVpX0AJoqUQX2Idi8goFr0fAm 7cD2CBb1JhoAdzEfO4kAlQMFEDFLHlwff6kIA1j8vQEBj5MD/1hA8hJdhpL7mvQj rTAIn6Ldr08Lr1lqTaKSBMdCL3suGlW0Sw/dIBgicPDhgxLahT3DVfGiIst32FSl xmWY7wine80X4TZkJ9Hiw3Mpqtjl92j6zHNq0ZZE+CceNubpEdYLDqokAIMPdWlo WPHZcPxCs5PKI5udseFYF2gQAjI2iQCVAwUQMTlDoO9huekR1Y7VAQGy+AP/Rzp+ UGtJavbSiPx5EnXOXxkA/+ulXQgQG9vdkWwewkvxDNOzHW3KkUWCGtPtIMENznbF j3QlYB+USIaf1ogvlD5EdXGPDfTINpE8CX2WXzajfgYFpYETDzduwjoWDZfEN9zZ fQqQS62VgAReOIz3k9BL708z/+WUO0++RLGCmImJAJUDBRAw5q8kAPLZCeu7G0EB AT3bBACwo+r9TgbiSyyU5cZpq5KgGT1c7eUHXjtxKmtrXD1nFNJ6j7x2DM2XGe6B YOfDWbFq4UkEAyAeXviuuUP4enQu1v2g7JGXeuI8bRM519pLdPzDq/DnbA4rNStn /SkH7awMfNSplcFuE6rc5ezVkw17eOHzDrYmwsFavL9gxZEycg== =Q45T -----END PGP PUBLIC KEY BLOCK-----&a.rich;Rich Murphey <rich@FreeBSD.org> fingerprint = AF
A0 60 C4 84 D6 0C 73 D1 EF C0 E9 9D 21 DB E4 -----BEGIN PGP
PUBLIC KEY BLOCK----- Version: 2.6.2
mQCNAy97V+MAAAEEALiNM3FCwm3qrCe81E20UOSlNclOWfZHNAyOyj1ahHeINvo1 FBF2Gd5Lbj0y8SLMno5yJ6P4F4r+x3jwHZrzAIwMs/lxDXRtB0VeVWnlj6a3Rezs wbfaTeSVyh5JohEcKdoYiMG5wjATOwK/NAwIPthB1RzRjnEeer3HI3ZYNEOpAAUR tCRSaWNoIE11cnBoZXkgPHJpY2hAbGFtcHJleS51dG1iLmVkdT6JAJUDBRAve15W vccjdlg0Q6kBAZTZBACcNd/LiVnMFURPrO4pVRn1sVQeokVX7izeWQ7siE31Iy7g Sb97WRLEYDi686osaGfsuKNA87Rm+q5F+jxeUV4w4szoqp60gGvCbD0KCB2hWraP /2s2qdVAxhfcoTin/Qp1ZWvXxFF7imGA/IjYIfB42VkaRYu6BwLEm3YAGfGcSw== =QoiM -----END PGP PUBLIC KEY BLOCK-----&a.jdp;John D. Polstra <jdp@polstra.com> Fingerprint = 54
3A 90 59 6B A4 9D 61 BF 1D 03 09 35 8D F6 0D -----BEGIN PGP
PUBLIC KEY BLOCK----- Version: 2.6.2
mQCNAzMElMEAAAEEALizp6ZW9QifQgWoFmG3cXhzQ1+Gt+a4S1adC/TdHdBvw1M/ I6Ok7TC0dKF8blW3VRgeHo4F3XhGn+n9MqIdboh4HJC5Iiy63m98sVLJSwyGO4oM dkEGyyCLxqP6h/DU/tzNBdqFzetGtYvU4ftt3RO0a506cr2CHcdm8Q+/vPRJAAUR tCFKb2huIEQuIFBvbHN0cmEgPGpkcEBwb2xzdHJhLmNvbT6JAJUDBRAzBNBE9RVb +45ULV0BAWgiA/0WWO3+c3qlptPCHJ3DFm6gG/qNKsY94agL/mHOr0fxMP5l2qKX O6a1bWkvGoYq0EwoKGFfn0QeHiCl6jVi3CdBX+W7bObMcoi+foqZ6zluOWBC1Jdk WQ5/DeqQGYXqbYjqO8voCScTAPge3XlMwVpMZTv24u+nYxtLkE0ZcwtY9IkAlQMF EDMEt/DHZvEPv7z0SQEBXh8D/2egM5ckIRpGz9kcFTDClgdWWtlgwC1iI2p9gEhq aufy+FUJlZS4GSQLWB0BlrTmDC9HuyQ+KZqKFRbVZLyzkH7WFs4zDmwQryLV5wkN C4BRRBXZfWy8s4+zT2WQD1aPO+ZsgRauYLkJgTvXTPU2JCN62Nsd8R7bJS5tuHEm 7HGmiQCVAwUQMwSvHB9/qQgDWPy9AQFAhAQAgJ1AlbKITrEoJ0+pLIsov3eQ348m SVHEBGIkU3Xznjr8NzT9aYtq4TIzt8jplqP3QoV1ka1yYpZf0NjvfZ+ffYp/sIaU wPbEpgtmHnVWJAebMbNs/Ad1w8GDvxEt9IaCbMJGZnHmfnEqOBIxF7VBDPHHoJxM V31K/PIoYsHAy5w= =cHFa -----END PGP PUBLIC KEY BLOCK-----&a.guido;Guido van Rooij <guido@gvr.win.tue.nl> Fingerprint
= 16 79 09 F3 C0 E4 28 A7 32 62 FA F6 60 31 C0 ED -----BEGIN
PGP PUBLIC KEY BLOCK----- Version: 2.6.2
mQCNAzGeO84AAAEEAKKAY91Na//DXwlUusr9GVESSlVwVP6DyH1wcZXhfN1fyZHq SwhMCEdHYoojQds+VqD1iiZQvv1RLByBgj622PDAPN4+Z49HjGs7YbZsUNuQqPPU wRPpP6ty69x1hPKq1sQIB5MS4radpCM+4wbZbhxv7l4rP3RWUbNaYutZnzI9AAUR tCZHdWlkbyB2YW4gUm9vaWogPGd1aWRvQGd2ci53aW4udHVlLm5sPokAlQMFEDMG Hcgff6kIA1j8vQEBbYgD/jm9xHuUuY+iXDkOzpCXBYACYEZDV913MjtyBAmaVqYo Rh5HFimkGXe+rCo78Aau0hc57fFMTsJqnuWEqVt3GRq28hSK1FOZ7ni9/XibHcmN rt2yugl3hYpClijo4nrDL1NxibbamkGW/vFGcljS0jqXz6NDVbGx5Oo7HBByxByz iQCVAwUQMhmtVjt/x7zOdmsfAQFuVQQApsVUTigT5YWjQA9Nd5Z0+a/oVtZpyw5Z OljLJP3vqJdMa6TidhfcatjHbFTve5x1dmjFgMX/MQTd8zf/+Xccy/PX4+lnKNpP eSf1Y4aK+E8KHmBGd6GzX6CIboyGYLS9e3kGnN06F2AQtaLyJFgQ71wRaGuyKmQG FwTn7jiKb1aJAJUDBRAyEOLXPt3iN6QQUSEBATwQA/9jqu0Nbk154+Pn+9mJX/YT fYR2UqK/5FKCqgL5Nt/Deg2re0zMD1f8F9Dj6vuAAxq8hnOkIHKlWolMjkRKkzJi mSPEWl3AuHJ31k948J8it4f8kq/o44usIA2KKVMlI63Q/rmNdfWCyiYQEVGcRbTm GTdZIHYCOgV5dOo4ebFqgYkAlQMFEDIE1nMEJn15jgpJ0QEBW6kEAKqN8XSgzTqf CrxFXT07MlHhfdbKUTNUoboxCGCLNW05vf1A8F5fdE5i14LiwkldWIzPxWD+Sa3L fNPCfCZTaCiyGcLyTzVfBHA18MBAOOX6JiTpdcm22jLGUWBf/aJK3yz/nfbWntd/ LRHysIdVp29lP5BF+J9/Lzbb/9LxP1taiQCVAwUQMgRXZ44CzbsJWQz9AQFf7gP/ Qa2FS5S6RYKG3rYanWADVe/ikFV2lxuM1azlWbsmljXvKVWGe6cV693nS5lGGAjx lbd2ADwXjlkNhv45HLWFm9PEveO9Jjr6tMuXVt8N2pxiX+1PLUN9CtphTIU7Yfjn s6ryZZfwGHSfIxNGi5ua2SoXhg0svaYnxHxXmOtH24iJAJUDBRAyAkpV8qaAEa3W TBkBARfQBAC+S3kbulEAN3SI7/A+A/dtl9DfZezT9C4SRBGsl2clQFMGIXmMQ/7v 7lLXrKQ7U2zVbgNfU8smw5h2vBIL6f1PyexSmc3mz9JY4er8KeZpcf6H0rSkHl+i d7TF0GvuTdNPFO8hc9En+GG6QHOqbkB4NRZ6cwtfwUMhk2FHXBnjF4kAlQMFEDH5 FFukUJAsCdPmTQEBe74EAMBsxDnbD9cuI5MfF/QeTNEG4BIVUZtAkDme4Eg7zvsP d3DeJKCGeNjiCWYrRTCGwaCWzMQk+/+MOmdkI6Oml+AIurJLoHceHS9jP1izdP7f N2jkdeJSBsixunbQWtUElSgOQQ4iF5kqwBhxtOfEP/L9QsoydRMR1yB6WPD75H7V iQCVAwUQMZ9YNGtaZ42Bsqd5AQH0PAQAhpVlAc3ZM/KOTywBSh8zWKVlSk3q/zGn k7hJmFThnlhH1723+WmXE8aAPJi+VXOWJUFQgwELJ6R8jSU2qvk2m1VWyYSqRKvc VRQMqT2wjss0GE1Ngg7tMrkRHT0il7E2xxIb8vMrIwmdkbTfYqBUhhGnsWPHZHq7 MoA1/b+rK7CJAJUDBRAxnvXh3IDyptUyfLkBAYTDA/4mEKlIP/EUX2Zmxgrd/JQB hqcQlkTrBAaDOnOqe/4oewMKR7yaMpztYhJs97i03Vu3fgoLhDspE55ooEeHj0r4 cOdiWfYDsjSFUYSPNVhW4OSruMA3c29ynMqNHD7hpr3rcCPUi7J2RncocOcCjjK2 BQb/9IAUNeK4C9gPxMEZLokAlQMFEDGeO86zWmLrWZ8yPQEBEEID/2fPEUrSX3Yk j5TJPFZ9MNX0lEo7AHYjnJgEbNI4pYm6C3PnMlsYfCSQDHuXmRQHAOWSdwOLvCkN F8eDaF3M6u0urgeVJ+KVUnTz2+LZoZs12XSZKCte0HxjbvPpWMTTrYyimGezH79C mgDVjsHaYOx3EXF0nnDmtXurGioEmW1J =mSvM -----END PGP PUBLIC KEY BLOCK-----&a.peter;Peter Wemm <peter@FreeBSD.org> aka
<peter@spinner.dialix.com> aka
<peter@haywire.dialix.com> aka
<peter@perth.dialix.oz.au> Key fingerprint = 47 05 04 CA
4C EE F8 93 F6 DB 02 92 6D F5 58 8A -----BEGIN PGP PUBLIC KEY
BLOCK----- Version: 2.6.3ia
mQCNAy9/FJwAAAEEALxs9dE9tFd0Ru1TXdq301KfEoe5uYKKuldHRBOacG2Wny6/ W3Ill57hOi2+xmq5X/mHkapywxvy4cyLdt31i4GEKDvxpDvEzAYcy2n9dIup/eg2 kEhRBX9G5k/LKM4NQsRIieaIEGGgCZRm0lINqw495aZYrPpO4EqGN2HYnOMZAAUT tCVQZXRlciBXZW1tIDxwZXRlckBoYXl3aXJlLmRpYWxpeC5jb20+iQCVAwUQMwWT cXW7bjh2o/exAQEFkQP+LIx5zKlYp1uR24xGApMFNrNtjh+iDIWnxxb2M2Kb6x4G 9z6OmbUCoDTGrX9SSL2Usm2RD0BZfyv9D9QRWC2TSOPkPRqQgIycc11vgbLolJJN eixqsxlFeKLGEx9eRQCCbo3dQIUjc2yaOe484QamhsK1nL5xpoNWI1P9zIOpDiGJ AJUDBRAxsRPqSoY3Ydic4xkBAbWLA/9q1Fdnnk4unpGQsG31Qbtr4AzaQD5m/JHI 4gRmSmbj6luJMgNG3fpO06Gd/Z7uxyCJB8pTst2a8C/ljOYZxWT+5uSzkQXeMi5c YcI1sZbUpkHtmqPW623hr1PB3ZLA1TIcTbQW+NzJsxQ1Pc6XG9fGkT9WXQW3Xhet AP+juVTAhLQlUGV0ZXIgV2VtbSA8cGV0ZXJAcGVydGguZGlhbGl4Lm96LmF1PokA lQMFEDGxFCFKhjdh2JzjGQEB6XkD/2HOwfuFrnQUtdwFPUkgtEqNeSr64jQ3Maz8 xgEtbaw/ym1PbhbCk311UWQq4+izZE2xktHTFClJfaMnxVIfboPyuiSF99KHiWnf /Gspet0S7m/+RXIwZi1qSqvAanxMiA7kKgFSCmchzas8TQcyyXHtn/gl9v0khJkb /fv3R20btB5QZXRlciBXZW1tIDxwZXRlckBGcmVlQlNELm9yZz6JAJUDBRAxsRJd SoY3Ydic4xkBAZJUA/4i/NWHz5LIH/R4IF/3V3LleFyMFr5EPFY0/4mcv2v+ju9g brOEM/xd4LlPrx1XqPeZ74JQ6K9mHR64RhKR7ZJJ9A+12yr5dVqihe911KyLKab9 4qZUHYi36WQu2VtLGnw/t8Jg44fQSzbBF5q9iTzcfNOYhRkSD3BdDrC3llywO7Ql UGV0ZXIgV2VtbSA8cGV0ZXJAc3Bpbm5lci5kaWFsaXguY29tPokAlQMFEDGxEi1K hjdh2JzjGQEBdA4EAKmNFlj8RF9HQsoI3UabnvYqAWN5wCwEB4u+Zf8zq6OHic23 TzoK1SPlmSdBE1dXXQGS6aiDkLT+xOdeewNs7nfUIcH/DBjSuklAOJzKliXPQW7E kuKNwy4eq5bl+j3HB27i+WBXhn6OaNNQY674LGaR41EGq44Wo5ATcIicig/z =gv+h -----END PGP PUBLIC KEY BLOCK-----&a.joerg;Type Bits/KeyID Date User ID pub 1024/76A3F7B1
1996/04/27 Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Key fingerprint = DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12
D6 4E Joerg Wunsch <joerg_wunsch@interface-business.de>
Joerg Wunsch <j@uriah.heep.sax.de> Joerg Wunsch
<j@interface-business.de> -----BEGIN PGP PUBLIC KEY
BLOCK----- Version: 2.6.3ia
mQCNAzGCFeAAAAEEAKmRBU2Nvc7nZy1Ouid61HunA/5hF4O91cXm71/KPaT7dskz q5sFXvPJPpawwvqHPHfEbAK42ZaywyFp59L1GaYj87Pda+PlAYRJyY2DJl5/7JPe ziq+7B8MdvbX6D526sdmcR+jPXPbHznASjkx9DPmK+7TgFujyXW7bjh2o/exAAUR tC1Kb2VyZyBXdW5zY2ggPGpvZXJnX3d1bnNjaEB1cmlhaC5oZWVwLnNheC5kZT6J AJUDBRA0FFkBs1pi61mfMj0BAfDCA/oCfkjrhvRwRCpSL8klJ1YDoUJdmw+v4nJc pw3OpYXbwKOPLClsE7K3KCQscHel7auf91nrekAwbrXv9Clp0TegYeAQNjw5vZ9f L6UZ5l3fH8E2GGA7+kqgNWs1KxAnG5GdUvJ9viyrWm8dqWRGo+loDWlZ12L2OgAD fp7jVZTI1okAlQMFEDQPrLoff6kIA1j8vQEB2XQEAK/+SsQPCT/X4RB/PBbxUr28 GpGJMn3AafAaA3plYw3nb4ONbqEw9tJtofAn4UeGraiWw8nHYR2DAzoAjR6OzuX3 TtUV+57BIzrTPHcNkb6h8fPuHU+dFzR+LNoPaGJsFeov6w+Ug6qS9wa5FGDAgaRo LHSyBxcRVoCbOEaS5S5EiQCVAwUQM5BktWVgqaw0+fnVAQGKPwP+OiWho3Zm2GKp lEjiZ5zx3y8upzb+r1Qutb08jr2Ewja04hLg0fCrt6Ad3DoVqxe4POghIpmHM4O4 tcW92THQil70CLzfCxtfUc6eDzoP3krD1/Gwpm2hGrmYA9b/ez9+r2vKBbnUhPmC glx5pf1IzHU9R2XyQz9Xu7FI2baOSZqJAJUDBRAyCIWZdbtuOHaj97EBAVMzA/41 VIph36l+yO9WGKkEB+NYbYOz2W/kyi74kXLvLdTXcRYFaCSZORSsQKPGNMrPZUoL oAKxE25AoCgl5towqr/sCcu0A0MMvJddUvlQ2T+ylSpGmWchqoXCN7FdGyxrZ5zz xzLIvtcio6kaHd76XxyJpltCASupdD53nEtxnu8sRrQxSm9lcmcgV3Vuc2NoIDxq b2VyZ193dW5zY2hAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokAlQMFEDIIhfR1u244 dqP3sQEBWoID/RhBm+qtW+hu2fqAj9d8CVgEKJugrxZIpXuCKFvO+bCgQtogt9EX +TJh4s8UUdcFkyEIu8CT2C3Rrr1grvckfxvrTgzSzvtYyv1072X3GkVY+SlUMBMA rdl1qNW23oT7Q558ajnsaL065XJ5m7HacgTTikiofYG8i1s7TrsEeq6PtCJKb2Vy ZyBXdW5zY2ggPGpAdXJpYWguaGVlcC5zYXguZGU+iQCVAwUQMaS91D4gHQUlG9CZ AQGYOwQAhPpiobK3d/fz+jWrbQgjkoO+j39glYGXb22+6iuEprFRs/ufKYtjljNT NK3B4DWSkyIPawcuO4Lotijp6jke2bsjFSSashGWcsJlpnwsv7EeFItT3oWTTTQQ ItPbtNyLW6M6xB+jLGtaAvJqfOlzgO9BLfHuA2LY+WvbVW447SWJAJUDBRAxqWRs dbtuOHaj97EBAXDBA/49rzZB5akkTSbt/gNd38OJgC+H8N5da25vV9dD3KoAvXfW fw7OxIsxvQ/Ab+rJmukrrWxPdsC+1WU1+1rGa4PvJp/VJRDes2awGrn+iO7/cQoS IVziC27JpcbvjLvLVcBIiy1yT/RvJ+87a3jPRHt3VFGcpFh4KykxxSNiyGygl4kA lQMFEDGCUB31FVv7jlQtXQEB5KgD/iIJZe5lFkPr2B/Cr7BKMVBot1/JSu05NsHg JZ3uK15w4mVtNPZcFi/dKbn+qRM6LKDFe/GF0HZD/ZD1FJt8yQjzF2w340B+F2GG EOwnClqZDtEAqnIBzM/ECQQqH+6Bi8gpkFZrFgg5eON7ikqmusDnOlYStM/CBfgp SbR8kDmFtCZKb2VyZyBXdW5zY2ggPGpAaW50ZXJmYWNlLWJ1c2luZXNzLmRlPokA lQMFEDHioSdlYKmsNPn51QEByz8D/10uMrwP7MdaXnptd1XNFhpaAPYTVAOcaKlY OGI/LLR9PiU3FbqXO+7INhaxFjBxa0Tw/p4au5Lq1+Mx81edHniJZNS8tz3I3goi jIC3+jn2gnVAWnK5UZUTUVUn/JLVk/oSaIJNIMMDaw4J9xPVVkb+Fh1A+XqtPsVa YESrNp0+iQCVAwUQMwXkzcdm8Q+/vPRJAQEA4QQAgNNX1HFgXrMetDb+w6yEGQDk JCDAY9b6mA2HNeKLQAhsoZl4HwA1+iuQaCgo3lyFC+1Sf097OUTs74z5X1vCedqV oFw9CxI3xuctt3pJCbbN68flOlnq0WdYouWWGlFwLlh5PEy//VtwX9lqgsizlhzi t+fX6BT4BgKi5baDhrWJAJUDBRAyCKveD9eCJxX4hUkBAebMA/9mRPy6K6i7TX2R jUKSl2p5oYrXPk12Zsw4ijuktslxzQhOCyMSCGK2UEC4UM9MXp1H1JZQxN/DcfnM 7VaUt+Ve0wZ6DC9gBSHJ1hKVxHe5XTj26mIr4rcXNy2XEDMK9QsnBxIAZnBVTjSO LdhqqSMp3ULLOpBlRL2RYrqi27IXr4kAlQMFEDGpbnd1u244dqP3sQEBJnQD/RVS Azgf4uorv3fpbosI0LE3LUufAYGBSJNJnskeKyudZkNkI5zGGDwVneH/cSkKT4OR ooeqcTBxKeMaMuXPVl30QahgNwWjfuTvl5OZ8orsQGGWIn5FhqYXsKkjEGxIOBOf vvlVQ0UbcR0N2+5F6Mb5GqrXZpIesn7jFJpkQKPU =97h7 -----END PGP PUBLIC KEY BLOCK-----