diff --git a/en_US.ISO8859-1/articles/contributing/article.sgml b/en_US.ISO8859-1/articles/contributing/article.sgml
index 20f221851f..0570de192f 100644
--- a/en_US.ISO8859-1/articles/contributing/article.sgml
+++ b/en_US.ISO8859-1/articles/contributing/article.sgml
@@ -1,5804 +1,5804 @@
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;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.eivind;Fix the union file system. Coordinator: &a.dg;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;New bus architecture. Coordinator: &a.newbus;Port existing ISA drivers to new architecture.Move all interrupt-management code to appropriate parts of
the bus drivers.Port PCI subsystem to new architecture. Coordinator:
&a.dfr;Figure out the right way to handle removable devices and
then use that as a substrate on which PC-Card and CardBus
support can be implemented.Resolve the probe/attach priority issue once and for
all.Move any remaining buses over to the new
architecture.Kernel issues. Overall coordination: &a.hackers;Add more pro-active security infrastructure. Overall
coordination: &a.security;Build something like Tripwire(TM) into the kernel, with a
remote and local part. There are a number of cryptographic
issues to getting this right; contact the coordinator for
details. Coordinator: &a.eivind;Make the entire kernel use suser()
instead of comparing to 0. It is presently using about half
of each. Coordinator: &a.eivind;Split securelevels into different parts, to allow an
administrator to throw away those privileges he can throw
away. Setting the overall securelevel needs to have the same
effect as now, obviously. Coordinator: &a.eivind;Make it possible to upload a list of “allowed
program” to BPF, and then block BPF from accepting other
programs. This would allow BPF to be used e.g. for DHCP,
without allowing an attacker to start snooping the local
network.Update the security checker script. We should at least
grab all the checks from the other BSD derivatives, and add
checks that a system with securelevel increased also have
reasonable flags on the relevant parts. Coordinator:
&a.eivind;Add authorization infrastructure to the kernel, to allow
different authorization policies. Part of this could be done
by modifying suser(). Coordinator:
&a.eivind;Add code to the NFS layer so that you cannot
chdir("..") out of an NFS partition. E.g.,
/usr is a UFS partition with
/usr/src NFS exported. Now it is
possible to use the NFS filehandle for
/usr/src to get access to
/usr.Medium priority tasksThe following tasks need to be done, but not with any particular
urgency:Full KLD based driver support/Configuration Manager.Write a configuration manager (in the 3rd stage boot?)
that probes your hardware in a sane manner, keeps only the
KLDs required for your hardware, etc.PCMCIA/PCCARD. Coordinators: &a.msmith; 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.msmith; 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 N items are from Terry Lambert
terry@lambert.orgNetWare 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.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).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 &ng.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!Work through the PR databaseThe FreeBSD PR
list shows all the current active problem reports and
requests for enhancement that have been submitted by FreeBSD users.
Look through the open PRs, and see if anything there takes your
interest. Some of these might be very simple tasks, that just need an
extra pair of eyes to look over them and confirm that the fix in the
PR is a good one. Others might be much more complex.Start with the PRs that have not been assigned to anyone else, but
if one them is assigned to someone else, but it looks like something
you can handle, e-mail the person it is assigned to and ask if you can
work on it—they might already have a patch ready to be tested,
or further ideas that you can discuss with them.How to ContributeContributions to the system generally fall into one or more of the
following 6 categories:Bug reports and general commentaryAn 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 mailing lists 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 &man.send-pr.1; program 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.
When including patches, do not use cut-and-paste
because cut-and-paste turns tabs into spaces and makes them unusable.
Consider compressing patches and using &man.uuencode.1; if they exceed
20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/.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 &man.send-pr.1; 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 Bug Reports and General
Commentary.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 Staying current with FreeBSD 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 &man.diff.1;
command, with the “context diff” form
being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; 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 &man.diff.1; for more
details.Once you have a set of diffs (which you may test with the
&man.patch.1; command), you should submit them for inclusion with
FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary.
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 &man.uuencode.1; 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 &man.send-pr.1;. 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.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(c)(3) (charitable)
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.dg;
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 Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO box
can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to &a.jkh,
either via email or to the FreeBSD, Inc. postal address given above.
If you do not wish to be listed in our donors 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.dg;
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
admin@FreeBSD.org 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:&a.mbarkah and his employer,
Hemisphere Online, donated a Pentium Pro
(P6) 200Mhz CPUASA
Computers donated a Tyan 1662
motherboard.Joe McGuckin joe@via.net of ViaNet Communications donated
a Kingston ethernet controller.Jack O'Neill jack@diamond.xtalwind.net
donated an NCR 53C875 SCSI controller
card.Ulf Zimmermann ulf@Alameda.net 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 Anderson
ANDRSN@HOOVER.STANFORD.EDU&a.dillonEpilogue Technology
Corporation&a.sefDon Scott WildeGianmarco Giovannelli
gmarco@masternet.itJosef C. Grosch joeg@truenorth.orgRobert T. Morris&a.chuckrKenneth P. Stox ken@stox.sa.enteract.com of
Imaginary Landscape,
LLC.Dmitry S. Kohmanyuk dk@dog.farm.orgLaser5 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.BuffNETPacific
SolutionsSiemens AG
via Andre
AlbsmeierChris SilvaHardware 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.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 kuku@FreeBSD.org 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 history 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
doscmd command.Core Team AlumniThe following people were members of the FreeBSD core team during
the periods indicated. We thank them for their past efforts in the
service of the FreeBSD project.In rough chronological order:&a.guido (1995 - 1999)&a.dyson (1993 - 1998)&a.nate (1992 - 1996)&a.rgrimes (1992 - 1995)Andreas Schulz (1992 - 1995)&a.csgr (1993 - 1995)&a.paul (1992 - 1995)&a.smace (1993 - 1994)Andrew Moore (1993 - 1994)Christoph Robitschko (1993 - 1994)J. T. Conklin (1992 - 1993)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 and OpenBSD that have been
integrated into FreeBSD as well, and we would therefore like to thank
all the contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAMAGAI Yoshiji amagai@nue.orgAaron Bornstein aaronb@j51.comAaron Smith aaron@mutex.orgAchim Patzner ap@noses.comAda T Lim ada@bsd.orgAdam Baran badam@mw.mil.plAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian Colley aecolley@ois.ieAdrian Hall adrian@ibmpcug.co.ukAdrian Mariano adrian@cam.cornell.eduAdrian Steinmann ast@marabu.chAdam Strohl troll@digitalspark.netAdrian T. Filipi-Martin
atf3r@agate.cs.virginia.eduAjit Thyagarajan unknownAkio Morita
amorita@meadow.scphys.kyoto-u.ac.jpAkira SAWADA unknownAkira Watanabe
akira@myaw.ei.meisei-u.ac.jpAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker
A.C.P.M.Kalker@student.utwente.nlAlan Bawden alan@curry.epilogue.comAlec Wolman wolman@cs.washington.eduAled Morris aledm@routers.co.ukAlex garbanzo@hooked.netAlex D. Chen
dhchen@Canvas.dorm7.nccu.edu.twAlex G. Bulushev bag@demos.suAlex Le Heux alexlh@funk.orgAlex Perel veers@disturbed.netAlexander B. Povolotsky tarkhil@mgt.msk.ruAlexander Leidinger
netchild@wurzelausix.CS.Uni-SB.DEAlexander Langer alex@cichlids.comAlexandre Snarskii snar@paranoia.ruAlistair G. Crooks agc@uts.amdahl.comAllan Saddi asaddi@philosophysw.comAllen Campbell allenc@verinet.comAmakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jpAmancio Hasty hasty@star-gate.comAmir Farah amir@comtrol.comAmy Baron amee@beer.orgAnatoly A. Orehovsky tolik@mpeks.tomsk.suAnatoly Vorobey mellon@pobox.comAnders Nordby nickerne@nome.noAnders Thulin Anders.X.Thulin@telia.seAndras Olah olah@cs.utwente.nlAndre Albsmeier
Andre.Albsmeier@mchp.siemens.deAndre Oppermann andre@pipeline.chAndreas Haakh ah@alman.robin.deAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndreas Schulz unknownAndreas Wetzel mickey@deadline.snafu.deAndreas Wrede andreas@planix.comAndres Vega Garcia unknownAndrew Atrens atreand@statcan.caAndrew Boothman andrew@cream.orgAndrew Gillham gillham@andrews.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew J. Korty ajk@purdue.eduAndrew L. Moore alm@mclink.comAndrew McRae amcrae@cisco.comAndrew Stevenson andrew@ugh.net.auAndrew Timonin tim@pool1.convey.ruAndrew V. Stesin stesin@elvisti.kiev.uaAndrew Webster awebster@dataradio.comAndrey Zakhvatov andy@icc.surw.chel.suAndy Farkas andyf@speednet.com.auAndy Valencia ajv@csd.mot.comAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.comAnton Berezin tobez@plab.ku.dkAntti Kaipila anttik@iki.fiAre Bryne are.bryne@communique.noAri Suutari ari@suutari.iki.fiArjan de Vet devet@IAEhv.nlArne Henrik Juul arnej@Lise.Unit.NOAssar Westerlund assar@sics.seAtsushi Furuta furuta@sra.co.jpAtsushi Murai amurai@spec.co.jpBakul Shah bvs@bitblocks.comBarry Bierbauch pivrnec@vszbr.czBarry Lustig barry@ictv.comBen Hutchinson benhutch@xfiles.org.ukBen Jackson unknownBen Smithurst ben@scientia.demon.co.ukBen Walter bwalter@itachi.swcp.comBenjamin Lewis bhlewis@gte.netBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBill Trost trost@cloud.rain.comBlaz Zupan blaz@amis.netBob Van Valzah Bob@whitebarn.comBob Willcox bob@luke.pmr.comBoris Staeblow balu@dva.in-berlin.deBoyd R. Faulkner faulkner@asgard.bga.comBrad Karp karp@eecs.harvard.eduBradley Dunn bradley@dunn.orgBrandon Fosdick bfoz@glue.umd.eduBrandon Gillespie brandon@roguetrader.com&a.wlloydBob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Lymn blymn@mulga.awadi.com.AUBrett Taylor
brett@peloton.physics.montana.eduBrian Campbell brianc@pobox.comBrian Clapper bmc@willscreek.comBrian Cully shmit@kublai.comBrian Handy
handy@lambic.space.lockheed.comBrian Litzinger brian@MediaCity.comBrian McGovern bmcgover@cisco.comBrian Moore ziff@houdini.eecs.umich.eduBrian R. Haug haug@conterra.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce A. Mah bmah@ca.sandia.govBruce Albrecht bruce@zuhause.mn.orgBruce Gingery bgingery@gtcs.comBruce J. Keeler loodvrij@gridpoint.comBruce Murphy packrat@iinet.net.auBruce Walter walter@fortean.comCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCarl Mascott cmascott@world.std.comCasper casper@acc.amCastor Fu castor@geocast.comCejka Rudolf cejkar@dcse.fee.vutbr.czChain Lee chain@110.netCharles Hannum mycroft@ai.mit.eduCharles Henrich henrich@msu.eduCharles Mott cmott@srv.netCharles Owens owensc@enc.eduChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChiharu Shibata chi@bd.mbn.or.jpChip Norkus unknownChoi Jun Ho junker@jazz.snu.ac.krChris Csanady cc@tarsier.ca.sandia.govChris Dabrowski chris@vader.orgChris Dillon cdillon@wolves.k12.mo.usChris Shenton
cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer
cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristian Weisgerber
naddy@bigeye.rhein-neckar.deChristoph P. Kukulies kuku@FreeBSD.orgChristoph Robitschko
chmr@edvz.tu-graz.ac.atChristoph Weber-Fahr
wefa@callcenter.systemhaus.netChristopher G. Demetriou
cgd@postgres.berkeley.eduChristopher T. Johnson
cjohnson@neunacht.netgsi.comChrisy Luke chrisy@flix.netChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGColman Reilly careilly@tcd.ieConrad Sabatier conrads@neosoft.comCoranth Gryphon gryphon@healer.comCornelis van der Laan
nils@guru.ims.uni-stuttgart.deCove Schneider cove@brazil.nbn.comCraig Leres leres@ee.lbl.govCraig Loomis unknownCraig Metz cmetz@inner.netCraig Spannring cts@internetcds.comCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comCy Schubert cschuber@uumail.gov.bc.caDI. Christian Gusenbauer
cg@scotty.edvz.uni-linz.ac.atDai Ishijima ishijima@tri.pref.osaka.jpDaisuke Watanabe NU7D-WTNB@asahi-net.or.jpDamian Hamill damian@cablenet.netDan Cross tenser@spitfire.ecsel.psu.eduDan Lukes dan@obluda.czDan Nelson dnelson@emsphone.comDan Walters hannibal@cyberstation.netDaniel M. Eischen
deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDaniel Poirot poirot@aio.jsc.nasa.govDaniel Rock rock@cs.uni-sb.deDanny Egen unknownDanny J. Zerkel dzerkel@phofarm.comDarren Reed avalon@coombs.anu.edu.auDave Adkins adkin003@tc.umn.eduDave Andersen angio@aros.netDave Blizzard dblizzar@sprynet.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Cornejo dave@dogwood.comDave Edmondson davided@sco.comDave Glowacki dglo@ssec.wisc.eduDave Marquardt marquard@austin.ibm.comDave Tweten tweten@FreeBSD.orgDavid A. Adkins adkin003@tc.umn.eduDavid A. Bader dbader@umiacs.umd.eduDavid Borman dab@bsdi.comDavid Dawes dawes@XFree86.orgDavid Filo filo@yahoo.comDavid Holland dholland@eecs.harvard.eduDavid Holloway daveh@gwythaint.tamis.comDavid Horwitt dhorwitt@ucsd.eduDavid Hovemeyer daveho@infocom.comDavid Jones dej@qpoint.torfree.netDavid Kelly dkelly@tomcat1.tbe.comDavid Kulp dkulp@neomorphic.comDavid L. Nugent davidn@blaze.net.auDavid Leonard d@scry.dstc.edu.auDavid Malone dwmalone@maths.tcd.ieDavid Muir Sharnoff muir@idiom.comDavid S. Miller davem@jenolan.rutgers.eduDavid Wolfskill dhw@whistle.comDean Gaudet dgaudet@arctic.orgDean Huxley dean@fsa.caDenis Fortin unknownDennis Glatting
dennis.glatting@software-munitions.comDenton Gentry denny1@home.comDerek Inksetter derek@saidev.comDima Sivachenko dima@Chg.RUDirk Keunecke dk@panda.rhein-main.deDirk Nehrling nerle@pdv.deDmitry Khrustalev dima@xyzzy.machaon.ruDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDominik Brettnacher domi@saargate.deDominik Rother dr@domix.deDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Morrison dmorrisn@u.washington.eduDon Yuniskis dgy@rtd.comDonald Maddox dmaddox@conterra.comDoug Barton studded@dal.netDouglas Ambrisko ambrisko@whistle.comDouglas Carmichael dcarmich@mcs.comDouglas Crosher dtc@scrooge.ee.swin.oz.auDrew Derbyshire ahd@kew.comDuncan Barclay dmlb@ragnet.demon.co.ukDustin Sallings dustin@spy.netEckart "Isegrim" Hofmann
Isegrim@Wunder-Nett.orgEd Gold
vegold01@starbase.spd.louisville.eduEd Hudson elh@p5.spnet.comEdward Wang edward@edcom.comEdwin Groothus edwin@nwm.wan.philips.comEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectElmar Bartel
bartel@informatik.tu-muenchen.deEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Haug ejh@slustl.slu.eduEric J. Schwertfeger eric@cybernut.comEric L. Hernes erich@lodgenet.comEric P. Scott eps@sirius.comEric Sprinkle eric@ennovatenetworks.comErich Stefan Boleyn erich@uruk.orgErik E. Rantapaa rantapaa@math.umn.eduErik H. Moe ehm@cris.comErnst Winter ewinter@lobo.muc.deEspen Skoglund espensk@stud.cs.uit.no>Eugene M. Kim astralblue@usa.netEugene Radchenko genie@qsar.chem.msu.suEvan Champion evanc@synapse.netFaried Nawaz fn@Hungry.COMFlemming Jacobsen fj@tfs.comFong-Ching Liaw fong@juniper.netFrancis M J Hsieh mjshieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan
frankch@waru.life.nthu.edu.twFrank Durda IV uhclem@nemesis.lonestar.orgFrank MacLachlan fpm@n2.netFrank Nobis fn@Radio-do.deFrank Volf volf@oasis.IAEhv.nlFrank ten Wolde franky@pinewood.nlFrank van der Linden frank@fwi.uva.nlFred Cawthorne fcawth@jjarray.umn.eduFred Gilham gilham@csl.sri.comFred Templin templin@erg.sri.comFrederick Earl Gray fgray@rice.eduFUJIMOTO Kensaku
fujimoto@oscar.elec.waseda.ac.jpFUJISHIMA Satsuki k5@respo.or.jpFURUSAWA Kazuhisa
furusawa@com.cs.osakafu-u.ac.jpGabor Kincses gabor@acm.orgGabor Zahemszky zgabor@CoDe.huG. Adam Stanislavadam@whizkidtech.netGarance A Drosehn gad@eclipse.its.rpi.eduGareth McCaughan gjm11@dpmms.cam.ac.ukGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGary J. garyj@rks32.pcs.dec.comGary Kline kline@thought.orgGaspar Chilingarov nightmar@lemming.acc.amGea-Suan Lin gsl@tpts4.seed.net.twGeoff Rehmet csgr@alpha.ru.ac.zaGeorg Wagner georg.wagner@ubs.comGerard Roudier groudier@club-internet.frGianmarco Giovannelli
gmarco@giovannelli.itGil Kloepfer Jr. gil@limbic.ssdl.comGilad Rom rom_glsa@ein-hashofet.co.ilGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGiles Lean giles@nemeton.com.auGlen Foster gfoster@gfoster.comGlenn Johnson gljohns@bellsouth.netGodmar Back gback@facility.cs.utah.eduGoran Hammarback goran@astro.uu.seGord Matzigkeit gord@enci.ucalgary.caGordon Greeff gvg@uunet.co.zaGraham Wheeler gram@cdsec.comGreg A. Woods woods@zeus.leitch.comGreg Ansley gja@ansley.comGreg Troxel gdt@ir.bbn.comGreg Ungerer gerg@stallion.oz.auGregory Bond gnb@itga.com.auGregory D. Moncreaff
moncrg@bt340707.res.ray.comGuy Harris guy@netapp.comGuy Helmer ghelmer@cs.iastate.eduHAMADA Naoki hamada@astec.co.jpHONDA Yasuhiro
honda@kashio.info.mie-u.ac.jpHOSOBUCHI Noriyuki hoso@buchi.tama.or.jpHannu Savolainen hannu@voxware.pp.fiHans Huebner hans@artcom.deHans Petter Bieker zerium@webindex.noHans Zuidam hans@brandinnovators.comHarlan Stenn Harlan.Stenn@pfcs.comHarold Barker hbarker@dsms.comHavard Eidnes
Havard.Eidnes@runit.sintef.noHeikki Suonsivu hsu@cs.hut.fiHeiko W. Rupp unknownHelmut F. Wirth hfwirth@ping.atHenrik Vestergaard Draboel
hvd@terry.ping.dkHerb Peyerl hpeyerl@NetBSD.orgHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jpHideki Yamamoto hyama@acm.orgHideyuki Suzuki
hideyuki@sat.t.u-tokyo.ac.jpHirayama Issei iss@mail.wbs.ne.jpHiroaki Sakai sakai@miya.ee.kagu.sut.ac.jpHiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jpHironori Ikura hikura@kaisei.orgHiroshi Nishikawa nis@pluto.dti.ne.jpHiroya Tsubakimoto unknownHolger Veit Holger.Veit@gmd.deHolm Tiffe holm@geophysik.tu-freiberg.deHorance Chou
horance@freedom.ie.cycu.edu.twHorihiro Kumagai kuma@jp.FreeBSD.orgHOTARU-YA hotaru@tail.netHr.Ladavac lada@ws2301.gud.siemens.co.atHubert Feyrer hubertf@NetBSD.ORGHugh F. Mahon hugh@nsmdserv.cnd.hp.comHugh Mahon h_mahon@fc.hp.comHung-Chi Chu hcchu@r350.ee.ntu.edu.twIMAI Takeshi take-i@ceres.dti.ne.jpIMAMURA Tomoaki
tomoak-i@is.aist-nara.ac.jpIan Dowse iedowse@maths.tcd.ieIan Holland ianh@tortuga.com.auIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Khasilev igor@jabber.paco.odessa.uaIgor Roshchin str@giganda.komkon.orgIgor Sviridov siac@ua.netIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIlya V. Komarov mur@lynx.ruIssei Suzuki issei@jp.FreeBSD.orgItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. Bryant jbryant@argus.flash.netJ. David Lowe lowe@saturn5.comJ. Han hjh@best.comJ. Hawk jhawk@MIT.EDUJ.T. Conklin jtc@cygnus.comJ.T. Jang keith@email.gcn.net.twJack jack@zeus.xtalwind.netJacob Bohn Lorensen jacob@jblhome.ping.mkJagane D Sundar jagane@netcom.comJake Burkholder jake@checker.orgJake Hamby jehamby@lightside.comJames Clark jjc@jclark.comJames D. Stewart jds@c4systm.comJames Jegers jimj@miller.cs.uwm.eduJames Raynard
fhackers@jraynard.demon.co.ukJames T. Liu jtliu@phlebas.rockefeller.eduJames da Silva jds@cs.umd.eduJan Conard
charly@fachschaften.tu-muenchen.deJan Koum jkb@FreeBSD.orgJanick Taillandier
Janick.Taillandier@ratp.frJanusz Kokot janek@gaja.ipan.lublin.plJarle Greipsland jarle@idt.unit.noJason Garman init@risen.orgJason Thorpe thorpej@NetBSD.orgJason Wright jason@OpenBSD.orgJason Young
doogie@forbidden-donut.anet-stl.comJavier Martin Rueda jmrueda@diatel.upm.esJay Fenlason hack@datacube.comJaye Mathisen mrcpu@cdsnet.netJeff Bartig jeffb@doit.wisc.eduJeff Forys jeff@forys.cranbury.nj.usJeff Kletsky Jeff@Wagsky.comJeffrey Evans evans@scnc.k12.mi.usJeffrey Wheat jeff@cetlink.netJens Schweikhardt schweikh@noc.dfn.dJeremy Allison jallison@whistle.comJeremy Chatfield jdc@xinside.comJeremy Lea reg@shale.csir.co.zaJeremy Prior unknownJeroen Ruigrok/Asmodai asmodai@wxs.nlJesse Rosenstock jmr@ugcs.caltech.eduJian-Da Li jdli@csie.nctu.edu.twJim Babb babb@FreeBSD.orgJim Binkley jrb@cs.pdx.eduJim Carroll jim@carroll.comJim Flowers jflowers@ezo.netJim Leppek jleppek@harris.comJim Lowe james@cs.uwm.eduJim Mattson jmattson@sonic.netJim Mercer jim@komodo.reptiles.orgJim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld.orgJin Guojun jin@george.lbl.govJoachim Kuebart unknownJoao Carlos Mendes Luis jonny@jonny.eng.brJochen Pohl jpo.drs@sni.deJoe "Marcus" Clarke marcus@miami.eduJoe Abley jabley@clear.co.nzJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoe Orthoefer j_orthoefer@tia.netJoe Traister traister@mojozone.orgJoel Faedi Joel.Faedi@esial.u-nancy.frJoel Ray Holveck joelh@gnu.orgJoel Sutton sutton@aardvark.apana.org.auJohan Granlund johan@granlund.nuJohan Karlsson k@numeri.campus.luth.seJohan Larsson johan@moon.campus.luth.seJohann Tonsing jtonsing@mikom.csir.co.zaJohannes Helander unknownJohannes Stille unknownJohn Baldwin jobaldwi@vt.eduJohn Beckett jbeckett@southern.eduJohn Beukema jbeukema@hk.super.netJohn Brezak unknownJohn Capo jc@irbs.comJohn F. Woods jfw@jfwhome.funhouse.comJohn Goerzen
jgoerzen@alexanderwohl.complete.orgJohn Hay jhay@mikom.csir.co.zaJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Kohl unknownJohn Lind john@starfire.mn.orgJohn Mackin john@physiol.su.oz.auJohn P johnp@lodgenet.comJohn Perry perry@vishnu.alias.netJohn Preisler john@vapornet.comJohn Rochester jr@cs.mun.caJohn Sadler john_sadler@alum.mit.eduJohn Saunders john@pacer.nlc.net.auJohn W. DeBoskey jwd@unx.sas.comJohn Wehle john@feith.comJohn Woods jfw@eddie.mit.eduJon Morgan morgan@terminus.trailblazer.comJonathan H N Chin jc254@newton.cam.ac.ukJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJorge Goncalves j@bug.fe.up.ptJorge M. Goncalves ee96199@tom.fe.up.ptJos Backus jbackus@plex.nlJose M. Alcaide jose@we.lc.ehu.esJose Marques jose@nobody.orgJosef Grosch
jgrosch@superior.mooseriver.comJosef Karthauser joe@uk.FreeBSD.orgJoseph Stein joes@wstein.comJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJukka A. Ukkonen jua@iki.fiJulian Assange proff@suburbia.netJulian Coleman j.d.coleman@ncl.ac.uk&a.jhsJulian Jenkins kaveman@magna.com.auJunichi Satoh junichi@jp.FreeBSD.orgJunji SAKAI sakai@jp.FreeBSD.orgJunya WATANABE junya-w@remus.dti.ne.jpK.Higashino a00303@cc.hc.keio.ac.jpKUNISHIMA Takeo kunishi@c.oka-pu.ac.jpKai Vorma vode@snakemail.hut.fiKaleb S. Keithley kaleb@ics.comKaneda Hiloshi vanitas@ma3.seikyou.ne.jpKapil Chowksey kchowksey@hss.hns.comKarl Denninger karl@mcs.comKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comKato Takenori
kato@eclogite.eps.nagoya-u.ac.jpKATO Tsuguru tkato@prontomail.ne.jpKawanobe Koh kawanobe@st.rim.or.jpKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKazuo Horikawa horikawa@jp.FreeBSD.orgKees Jan Koster kjk1@ukc.ac.ukKeith Bostic bostic@bostic.comKeith E. Walker unknownKeith Moore unknownKeith Sklower unknownKelly Yancey kbyanc@posi.netKen Hornstein unknownKen Key key@cs.utk.eduKen Mayer kmayer@freegate.comKenji Saito marukun@mx2.nisiq.netKenji Tomita tommyk@da2.so-net.or.jpKenneth Furge kenneth.furge@us.endress.comKenneth Monville desmo@bandwidth.orgKenneth R. Westerback krw@tcn.netKenneth Stailey kstailey@gnu.ai.mit.eduKent Talarico kent@shipwreck.tsoft.netKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKevin Bracey kbracey@art.acorn.co.ukKevin Day toasty@dragondata.comKevin Lahey kml@nas.nasa.govKevin Lokevlo@hello.com.twKevin Street street@iname.comKevin Van Maren vanmaren@fast.cs.utah.eduKiroh HARADA kiroh@kh.rim.or.jpKlaus Klein kleink@layla.inka.deKlaus-J. Wolf Yanestra@t-online.deKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.suKouichi Hirabayashi kh@mogami-wire.co.jpKurt D. Zeilenga Kurt@Boolean.NETKurt Olsen kurto@tiny.mcs.usu.eduL. Jonas Olsson
ljo@ljo-slip.DIALIN.CWRU.EduLars Köller
Lars.Koeller@Uni-Bielefeld.DELarry Altneu larry@ALR.COMLaurence Lopez lopez@mv.mv.comLee Cremeans lcremean@tidalwave.netLiang Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twLon Willett lon%softt.uucp@math.utah.eduLouis A. Mamakos louie@TransSys.COMLouis Mamakos loiue@TransSys.comLucas James Lucas.James@ldjpc.apana.org.auLyndon Nerenberg lyndon@orthanc.comM.C. Wong unknownMANTANI Nobutaka nobutaka@nobutaka.comMIHIRA Sanpei Yoshiro sanpei@sanpei.orgMITA Yoshio mita@jp.FreeBSD.orgMITSUNAGA Noriaki
mitchy@er.ams.eng.osaka-u.ac.jpMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMagnus Enbom dot@tinto.campus.luth.seMahesh Neelakanta mahesh@gcomm.comMakoto MATSUSHITA matusita@jp.FreeBSD.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jpMalte Lance malte.lance@gmx.netManu Iyengar
iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMarc van Woerkom van.woerkom@netcologne.deMarcel Moolenaar marcel@scc.nlMario Sergio Fujikawa Ferreira
lioux@gns.com.brMark Andrews unknownMark Cammidge mark@gmtunx.ee.uct.ac.zaMark Diekhans markd@grizzly.comMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Mayo markm@vmunix.comMark Thompson thompson@tgsoft.comMark Tinguely tinguely@plains.nodak.eduMark Treacy unknownMark Valentine mark@linus.demon.co.ukMartin BirgmeierMartin Ibert mib@ppe.bb-data.deMartin Kammerhofer dada@sbox.tu-graz.ac.atMartin Renters martin@tdc.on.caMartti Kuparinen
martti.kuparinen@ericsson.comMasachika ISHIZUKA
ishizuka@isis.min.ntt.jpMas.TAKEMURA unknownMasafumi NAKANE max@wide.ad.jpMasahiro Sekiguchi
seki@sysrap.cs.fujitsu.co.jpMasanobu Saitoh msaitoh@spa.is.uec.ac.jpMasanori Kanaoka kana@saijo.mke.mei.co.jpMasanori Kiriake seiken@ARGV.ACMasatoshi TAMURA
tamrin@shinzan.kuee.kyoto-u.ac.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas matt@3am-software.comMatt White mwhite+@CMU.EDUMatthew C. Mead mmead@Glock.COMMatthew Cashdollar mattc@rfcnet.comMatthew Flatt mflatt@cs.rice.eduMatthew Fuller fullermd@futuresouth.comMatthew Stein matt@bdd.netMatthias Pfaller leo@dachau.marco.deMatthias Scheler tron@netbsd.orgMattias Gronlund
Mattias.Gronlund@sa.erisoft.seMattias Pantzare pantzer@ludd.luth.seMaurice Castro
maurice@planet.serc.rmit.edu.auMax Euston meuston@jmrodgers.comMax Khon fjoe@husky.iclub.nsu.ruMaxim Bolotin max@rsu.ruMaxim V. Sobolev sobomax@altavista.netMicha Class
michael_class@hpbbse.bbn.hp.comMichael Butler imb@scgt.oz.auMichael Butschky butsch@computi.erols.comMichael Clay mclay@weareb.orgMichael Elbel me@FreeBSD.orgMichael Galassi nerd@percival.rain.comMichael Hancock michaelh@cet.co.jpMichael Hohmuth hohmuth@inf.tu-dresden.deMichael Perlman canuck@caam.rice.eduMichael Petry petry@netwolf.NetMasters.comMichael Reifenberger root@totum.plaut.deMichael Sardo jaeger16@yahoo.comMichael Searle searle@longacre.demon.co.ukMichal Listos mcl@Amnesiac.123.orgMichio Karl Jinbo
karl@marcer.nagaokaut.ac.jpMiguel Angel Sagreras
msagre@cactus.fi.uba.arMihoko Tanaka m_tonaka@pa.yokogawa.co.jpMika Nystrom mika@cs.caltech.eduMikael Hybsch micke@dynas.seMikael Karpberg
karpen@ocean.campus.luth.seMike Del repenting@hotmail.comMike Durian durian@plutotech.comMike Durkin mdurkin@tsoft.sf-bay.orgMike E. Matsnev mike@azog.cs.msu.suMike Evans mevans@candle.comMike Grupenhoff kashmir@umiacs.umd.eduMike Hibler mike@marker.cs.utah.eduMike Karels unknownMike McGaughey mmcg@cs.monash.edu.auMike Meyer mwm@shiva.the-park.comMike Mitchell mitchell@ref.tfs.comMike Murphy mrm@alpharel.comMike Peck mike@binghamton.eduMike Spengler mks@msc.eduMikhail A. Sokolov mishania@demos.suMikhail Teterin mi@aldan.ziplink.netMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMitsuru IWASAKI iwasaki@pc.jaring.myMitsuru Yoshida mitsuru@riken.go.jpMonte Mitzelfelt monte@gonefishing.orgMorgan Davis root@io.cts.comMostyn Lewis mostyn@mrl.comMotomichi Matsuzaki mzaki@e-mail.ne.jpMotoyuki Kasahara m-kasahr@sra.co.jpMotoyuki Konno motoyuki@snipe.rim.or.jpMurray Stokely murray@cdrom.comN.G.Smith ngs@sesame.hensa.ac.ukNAGAO Tadaaki nagao@cs.titech.ac.jpNAKAJI Hiroyuki
nakaji@tutrp.tut.ac.jpNAKAMURA Kazushi nkazushi@highway.or.jpNAKAMURA Motonori
motonori@econ.kyoto-u.ac.jpNIIMI Satoshi sa2c@and.or.jpNOKUBI Hirotaka h-nokubi@yyy.or.jpNadav Eiron nadav@barcode.co.ilNanbor Wang nw1@cs.wustl.eduNaofumi Honda
honda@Kururu.math.sci.hokudai.ac.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNathan Ahlstrom nrahlstr@winternet.comNathan Dorfman nathan@rtfm.netNeal Fachan kneel@ishiboo.comNeil Blakey-Milner nbm@rucus.ru.ac.zaNiall Smart rotel@indigo.ieNick Barnes Nick.Barnes@pobox.comNick Handel nhandel@NeoSoft.comNick Hilliard nick@foobar.org&a.nsayer;Nick Williams njw@cs.city.ac.ukNickolay N. Dudorov nnd@itfs.nsk.suNiklas Hallqvist niklas@filippa.appli.seNisha Talagala nisha@cs.berkeley.eduNo Name ZW6T-KND@j.asahi-net.or.jpNo Name adrian@virginia.eduNo Name alex@elvisti.kiev.uaNo Name anto@netscape.netNo Name bobson@egg.ics.nitch.ac.jpNo Name bovynf@awe.beNo Name burg@is.ge.comNo Name chris@gnome.co.ukNo Name colsen@usa.netNo Name coredump@nervosa.comNo Name dannyman@arh0300.urh.uiuc.eduNo Name davids@SECNET.COMNo Name derek@free.orgNo Name devet@adv.IAEhv.nlNo Name djv@bedford.netNo Name dvv@sprint.netNo Name enami@ba2.so-net.or.jpNo Name flash@eru.tubank.msk.suNo Name flash@hway.ruNo Name fn@pain.csrv.uidaho.eduNo Name gclarkii@netport.neosoft.comNo Name gordon@sheaky.lonestar.orgNo Name graaf@iae.nlNo Name greg@greg.rim.or.jpNo Name grossman@cygnus.comNo Name gusw@fub46.zedat.fu-berlin.deNo Name hfir@math.rochester.eduNo Name hnokubi@yyy.or.jpNo Name iaint@css.tuu.utas.edu.auNo Name invis@visi.comNo Name ishisone@sra.co.jpNo Name iverson@lionheart.comNo Name jpt@magic.netNo Name junker@jazz.snu.ac.krNo Name k-sugyou@ccs.mt.nec.co.jpNo Name kenji@reseau.toyonaka.osaka.jpNo Name kfurge@worldnet.att.netNo Name lh@aus.orgNo Name lhecking@nmrc.ucc.ieNo Name mrgreen@mame.mu.oz.auNo Name nakagawa@jp.FreeBSD.orgNo Name ohki@gssm.otsuka.tsukuba.ac.jpNo Name owaki@st.rim.or.jpNo Name pechter@shell.monmouth.comNo Name pete@pelican.pelican.comNo Name pritc003@maroon.tc.umn.eduNo Name risner@stdio.comNo Name roman@rpd.univ.kiev.uaNo Name root@ns2.redline.ruNo Name root@uglabgw.ug.cs.sunysb.eduNo Name stephen.ma@jtec.com.auNo Name sumii@is.s.u-tokyo.ac.jpNo Name takas-su@is.aist-nara.ac.jpNo Name tamone@eig.unige.chNo Name tjevans@raleigh.ibm.comNo Name tony-o@iij.ad.jp amurai@spec.co.jpNo Name torii@tcd.hitachi.co.jpNo Name uenami@imasy.or.jpNo Name uhlar@netlab.skNo Name vode@hut.fiNo Name wlloyd@mpd.caNo Name wlr@furball.wellsfargo.comNo Name wmbfmk@urc.tue.nlNo Name yamagata@nwgpc.kek.jpNo Name ziggy@ryan.orgNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru
kogane@koganemaru.co.jpNorio Suzuki nosuzuki@e-mail.ne.jpNoritaka Ishizumi graphite@jp.FreeBSD.orgNoriyuki Soda soda@sra.co.jpOh Junseon hollywar@mail.holywar.netOlaf Wagner wagner@luthien.in-berlin.deOleg Sharoiko os@rsu.ruOleg V. Volkov rover@lglobus.ruOliver Breuninger ob@seicom.NETOliver Friedrichs oliver@secnet.comOliver Fromme
oliver.fromme@heim3.tu-clausthal.deOliver Laumann
net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.comOlof Johansson offe@ludd.luth.seOsokin Sergey aka oZZ ozz@FreeBSD.org.ruPace Willisson pace@blitz.comPaco Rosich rosich@modico.eleinf.uv.esPalle Girgensohn girgen@partitur.seParag Patel parag@cgt.comPascal Pederiva pascal@zuo.dec.comPasvorn Boonmark boonmark@juniper.netPatrick Gardella patrick@cre8tivegroup.comPatrick Hausen unknownPaul Antonov apg@demos.suPaul F. Werkowski unknownPaul Fox pgf@foxharp.boston.ma.usPaul Koch koch@thehub.com.auPaul Kranenburg pk@NetBSD.orgPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPaul S. LaFollette, Jr. unknownPaul Saab paul@mu.orgPaul Sandys myj@nyct.netPaul T. Root proot@horton.iaces.comPaul Vixie paul@vix.comPaulo Menezes paulo@isr.uc.ptPaulo Menezes pm@dee.uc.ptPedro A M Vazquez vazquez@IQM.Unicamp.BRPedro Giffuni giffunip@asme.orgPete Bentley pete@demon.netPeter Childs pjchilds@imforei.apana.org.auPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Jeremy perer.jeremy@alcatel.com.auPeter M. Chen pmchen@eecs.umich.eduPeter Much peter@citylink.dinoex.sub.orgPeter Olsson unknownPeter Philipp pjp@bsd-daemon.netPeter Stubbs PETERS@staidan.qld.edu.auPhil Maker pjm@cs.ntu.edu.auPhil Sutherland
philsuth@mycroft.dialix.oz.auPhil Taylor phil@zipmail.co.ukPhilip Musumeci philip@rmit.edu.auPierre Y. Dampure pierre.dampure@k2c.co.ukPius Fischer pius@ienet.comPomegranate daver@flag.blackened.netPowerdog Industries
kevin.ruddy@powerdog.comR. Kym HorsellRajesh Vaidheeswarran rv@fore.comRalf Friedl friedl@informatik.uni-kl.deRandal S. Masutani randal@comtest.comRandall Hopper rhh@ct.picker.comRandall W. Dean rwd@osf.orgRandy Bush rbush@bainbridge.verio.netReinier Bezuidenhout
rbezuide@mikom.csir.co.zaRemy Card Remy.Card@masi.ibp.frRicardas Cepas rch@richard.eu.orgRiccardo Veraldi veraldi@cs.unibo.itRichard Henderson richard@atheist.tamu.eduRichard Hwang rhwang@bigpanda.comRichard Kiss richard@homemail.comRichard J Kuhns rjk@watson.grauel.comRichard M. Neswold
rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Straka straka@user1.inficad.comRichard Tobin richard@cogsci.ed.ac.ukRichard Wackerbarth rkw@Dataplex.NETRichard Winkel rich@math.missouri.eduRichard Wiwatowski rjwiwat@adelaide.on.netRick Macklem rick@snowhite.cis.uoguelph.caRick Macklin unknownRob Austein sra@epilogue.comRob Mallory rmallory@qualcomm.comRob Snow rsnow@txdirect.netRobert Crowe bob@speakez.comRobert D. Thrush rd@phoenix.aii.comRobert Eckardt
roberte@MEP.Ruhr-Uni-Bochum.deRobert Sanders rsanders@mindspring.comRobert Sexton robert@kudra.comRobert Shady rls@id.netRobert Swindells swindellsr@genrad.co.ukRobert Watson robert@cyrus.watson.orgRobert Withrow witr@rwwa.comRobert Yoder unknownRobin Carey
robin@mailgate.dtc.rankxerox.co.ukRoger Hardiman roger@cs.strath.ac.ukRoland Jesse jesse@cs.uni-magdeburg.deRon Bickers rbickers@intercenter.netRon Lenk rlenk@widget.xmission.comRonald Kuehn kuehn@rz.tu-clausthal.deRudolf Cejka unknownRuslan Belkin rus@home2.UA.netRuslan Ermilov ru@ucb.crimea.uaRuslan Shevchenko rssh@cam.grad.kiev.uaRussell L. Carter rcarter@pinyon.orgRussell Vincent rv@groa.uct.ac.zaRyan Younce ryany@pobox.comRyuichiro IMURA imura@cs.titech.ac.jpSANETO Takanori sanewo@strg.sony.co.jpSAWADA Mizuki miz@qb3.so-net.ne.jpSUGIMURA Takashi sugimura@jp.FreeBSD.orgSURANYI Peter
suranyip@jks.is.tsukuba.ac.jpSakai Hiroaki sakai@miya.ee.kagu.sut.ac.jpSakari Jalovaara sja@tekla.fiSam Hartman hartmans@mit.eduSamuel Lam skl@ScalableNetwork.comSamuele Zannoli zannoli@cs.unibo.itSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoh Junichi junichi@astec.co.jpScot Elliott scot@poptart.orgScot W. Hetzel hetzels@westbend.netScott A. Kenney saken@rmta.ml.orgScott Blachowicz
scott.blachowicz@seaslug.orgScott Burris scott@pita.cns.ucla.eduScott Hazen Mueller scott@zorch.sf-bay.orgScott Michel scottm@cs.ucla.eduScott Mitchel scott@uk.FreeBSD.orgScott Reynolds scott@clmqt.marquette.mi.usSebastian Strollo seb@erix.ericsson.seSerge A. Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSergei Chechetkin
csl@whale.sunbay.crimea.uaSergei S. Laskavy laskavy@pc759.cs.msu.suSergey Gershtein sg@mplik.ruSergey Kosyakov ks@itp.ac.ruSergey Potapov sp@alkor.ruSergey Shkonda serg@bcs.zp.uaSergey V.Dorokhov svd@kbtelecom.nalnet.ruSergio Lenzi lenzi@bsi.com.brShaun Courtney shaun@emma.eng.uct.ac.zaShawn M. Carey smcarey@mailbox.syr.eduShigio Yamaguchi shigio@tamacom.comShinya Esu esu@yk.rim.or.jpShuichi Tanaka stanaka@bb.mbn.or.jpShunsuke Akiyama akiyama@jp.FreeBSD.orgSimon simon@masi.ibp.frSimon Burge simonb@telstra.com.auSimon J Gerraty sjg@melb.bull.oz.auSimon Marlow simonm@dcs.gla.ac.ukSimon Shapiro shimon@simon-shapiro.orgSin'ichiro MIYATANI siu@phaseone.co.jpSlaven Rezic eserte@cs.tu-berlin.deSoochon Radee slr@mitre.orgSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comSoren S. Jorvang soren@dt.dkStefan Bethke stb@hanse.deStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan Petri unknownStefan `Sec` Zehl sec@42.orgSteinar Haug sthaug@nethelp.noStephane E. Potvin sepotvin@videotron.caStephane Legrand stephane@lituus.frStephen Clawson
sclawson@marker.cs.utah.eduStephen F. Combs combssf@salem.ge.comStephen Farrell stephen@farrell.orgStephen Hocking sysseh@devetir.qld.gov.auStephen J. Roznowski sjr@home.netStephen McKay syssgm@devetir.qld.gov.auStephen Melvin melvin@zytek.comSteve Bauer sbauer@rock.sdsmt.eduSteve Coltrin spcoltri@io.comSteve Deering unknownSteve Gerakines steve2@genesis.tiac.netSteve Gericke steveg@comtrol.comSteve Piette steve@simon.chi.il.USSteve Schwarz schwarz@alpharel.comSteven G. Kargl
kargl@troutmask.apl.washington.eduSteven H. Samorodin samorodi@NUXI.comSteven McCanne mccanne@cs.berkeley.eduSteven Plite splite@purdue.eduSteven Wallace unknownStuart Henderson
stuart@internationalschool.co.ukSue Blake sue@welearn.com.auSugimoto Sadahiro ixtl@komaba.utmc.or.jpSugiura Shiro ssugiura@duo.co.jpSujal Patel smpatel@wam.umd.eduSune Stjerneby stjerneby@usa.netSuzuki Yoshiaki
zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakahiro Yugawa yugawa@orleans.rim.or.jpTakanori Watanabe
takawata@shidahara1.planet.sci.kobe-u.ac.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeru NAIKI naiki@bfd.es.hokudai.ac.jpTakeshi Amaike amaike@iri.co.jpTakeshi MUTOH mutoh@info.nara-k.ac.jpTakeshi Ohashi
ohashi@mickey.ai.kyutech.ac.jpTakeshi WATANABE
watanabe@crayon.earth.s.kobe-u.ac.jpTakuya SHIOZAKI
tshiozak@makino.ise.chuo-u.ac.jpTatoku Ogaito tacha@tera.fukui-med.ac.jpTatsumi HOSOKAWA hosokawa@jp.FreeBSD.orgTed Buswell tbuswell@mediaone.netTed Faber faber@isi.eduTed Lemon mellon@isc.orgTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo de Raadt deraadt@OpenBSD.orgThomas thomas@mathematik.uni-Bremen.deThomas D. Dean tomdean@ix.netcom.comThomas David Rivers rivers@dignus.comThomas G. McWilliams tgm@netcom.comThomas Gellekum
thomas@ghpc8.ihf.rwth-aachen.deThomas Graichen
graichen@omega.physik.fu-berlin.deThomas König
Thomas.Koenig@ciw.uni-karlsruhe.deThomas Ptacek unknownThomas A. Stephens tas@stephens.orgThomas Stromberg tstrombe@rtci.comThomas Valentino Crimi
tcrimi+@andrew.cmu.eduThomas Wintergerst thomas@lemur.nord.deÞórður Ívarsson
totii@est.isTim Kientzle kientzle@netcom.comTim Singletary
tsingle@sunland.gsfc.nasa.govTim Wilkinson tim@sarc.city.ac.ukTimo J. Rinne tri@iki.fiTodd Miller millert@openbsd.orgTom root@majestix.cmr.noTom tom@sdf.comTom Gray - DCA dcasba@rain.orgTom Jobbins tom@tom.tjTom Pusateri pusateri@juniper.netTom Rush tarush@mindspring.comTom Samplonius tom@misery.sdf.comTomohiko Kurahashi
kura@melchior.q.t.u-tokyo.ac.jpTony Kimball alk@Think.COMTony Li tli@jnx.comTony Lynn wing@cc.nsysu.edu.twTony Maher tonym@angis.org.auTorbjorn Granlund tege@matematik.su.seToshihiko ARAI toshi@tenchi.ne.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpToshihiro Kanda candy@kgc.co.jpToshiomi Moriki
Toshiomi.Moriki@ma1.seikyou.ne.jpTrefor S. trefor@flevel.co.ukTrevor Blackwell tlb@viaweb.comURATA Shuichiro s-urata@nmit.tmg.nec.co.jpUdo Schweigert ust@cert.siemens.deUgo Paternostro paterno@dsi.unifi.itUlf Kieber kieber@sax.deUlli Linzen ulli@perceval.camelot.deUstimenko Semen semen@iclub.nsu.ruUwe Arndt arndt@mailhost.uni-koblenz.deVadim Chekan vadim@gc.lviv.uaVadim Kolontsov vadim@tversu.ac.ruVadim Mikhailov mvp@braz.ruVan Jacobson van@ee.lbl.govVasily V. Grechishnikov
bazilio@ns1.ied-vorstu.ac.ruVasim Valejev vasim@uddias.diaspro.comVernon J. Schryver vjs@mica.denver.sgi.comVic Abell abe@cc.purdue.eduVille Eerola ve@sci.fiVincent Poy vince@venus.gaianet.netVincenzo Capuano
VCAPUANO@vmprofs.esoc.esa.deVirgil Champlin champlin@pa.dec.comVladimir A. Jakovenko
vovik@ntu-kpi.kiev.uaVladimir Kushnir kushn@mail.kar.netVsevolod Lobko seva@alex-ua.comW. Gerald Hicks wghicks@bellsouth.netW. Richard Stevens rstevens@noao.eduWalt Howard howard@ee.utah.eduWarren Toomey wkt@csadfa.cs.adfa.oz.auWayne Scott wscott@ichips.intel.comWerner Griessl
werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWietse Venema wietse@wzv.win.tue.nlWilfredo Sanchez wsanchez@apple.comWiljo Heinen wiljo@freeside.ki.open.deWilko Bulte wilko@yedi.iaf.nlWill Andrews andrews@technologist.comWillem Jan Withagen wjw@surf.IAE.nlWilliam Jolitz withheldWilliam Liao william@tale.netWojtek Pilorz
wpilorz@celebris.bdk.lublin.plWolfgang Helbig helbig@ba-stuttgart.deWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@FreeBSD.orgWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYarema yds@ingress.comYaroslav Terletsky ts@polynet.lviv.uaYasuhito FUTATSUKI futatuki@fureai.or.jpYasuhiro Fukama yasuf@big.or.jpYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYixin Jin yjin@rain.cs.ucla.eduYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshihiko OHTA yohta@bres.tsukuba.ac.jpYoshihisa NAKAGAWA
y-nakaga@ccs.mt.nec.co.jpYoshikazu Goto gotoh@ae.anritsu.co.jpYoshimasa Ohnishi
ohnishi@isc.kyutech.ac.jpYoshishige Arai ryo2@on.rim.or.jpYuichi MATSUTAKA matutaka@osa.att.ne.jpYujiro MIYATA
miyata@bioele.nuee.nagoya-u.ac.jpYukihiro Nakai nacai@iname.comYusuke Nawano azuki@azkey.orgYuu Yashiki s974123@cc.matsuyama-u.ac.jpYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nlYves Fonk yves@dutncp8.tn.tudelft.nlZach Heilig zach@gaffaneys.comZahemszhky Gabor zgabor@code.huZhong Ming-Xun zmx@mail.CDPA.nsysu.edu.twarci vega@sophia.inria.frder Mouse mouse@Collatz.McRCIM.McGill.EDUfrf frf@xocolatl.comEge Rekk aagero@aage.priv.no386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou
cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko
chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens
felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes
Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse
lohse@tech7.informatik.uni-hamburg.deJörg Wunsch
joerg_wunsch@uriah.heep.sax.deJohn DysonJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@FreeBSD.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland
philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.orgRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
index 7049bed32e..255324a762 100644
--- a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
+++ b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
@@ -1,597 +1,597 @@
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
&man.dumpon.8; command. The best way to use &man.dumpon.8; is to set
the dumpdev variable in
/etc/rc.conf. Typically you want to specify one of
the swap devices specified in /etc/fstab. Dumps to
non-swap devices, tapes for example, are currently not supported. Config
your kernel using config -g. See Kernel Configuration for details on
configuring the FreeBSD kernel.Use the &man.dumpon.8; 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 &man.swapon.8;). 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
-g 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:&prompt.root; fsck -p
&prompt.root; mount -a -t ufs # so your file system for /var/crash is writable
&prompt.root; savecore -N /kernel.panicked /var/crash
&prompt.root; exit # ...to multi-userThis instructs &man.savecore.8; 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.debugexec-file /var/crash/kernel.0core-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:&prompt.root; cd /sys/compile/URIAH
3:&prompt.root; 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:&prompt.root; exit
78:exit
79:
80:Script done on Fri Dec 30 23:18:04 1994Comments 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.)Debugging a crash dump with DDDExamining a kernel crash dump with a graphical debugger like
ddd is also possible. Add the
option to the ddd command line you would use
normally. For example;&prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0You should then be able to go about looking at the crash dump using
ddd's graphical interface.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 config directory
(/usr/src/sys/arch/conf)
and edit your configuration file. Uncomment (or add, if it does not
exist) the following line
makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbolsRebuild 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 &man.size.1; 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-stepping 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 Kernel Configuration 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-nameb 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:cTo 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, usedeldel address-expressionThe 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 bTo single-step the kernel, try:sThis 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,40x/hd db_symtab_spacex/bc termbuf,10x/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 ,10Similarly, 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 0w/w 0xf0010030 0 0The 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 regAlternatively, 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 &man.ps.1; 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)Which 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:helpHowever, it is highly recommended to have a printed copy of the
&man.ddb.4; 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 is
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:&prompt.user; 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:&prompt.root; cd /usr/src/lkm/linux
&prompt.root; 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:&prompt.root; linux
&prompt.root; 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.
diff --git a/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml
index 83cf490b8a..78c96d8a32 100644
--- a/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml
+++ b/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml
@@ -1,391 +1,391 @@
Source Tree Guidelines and PoliciesContributed by &a.phk;.This chapter documents various guidelines and policies in force for
the FreeBSD source tree.MAINTAINER on MakefilesJune 1996.If a particular portion of the FreeBSD distribution is being
maintained by a person or group of persons, they can communicate this
fact to the world by adding a
MAINTAINER= email-addresses
line to the Makefiles covering this portion of the
source tree.The semantics of this are as follows:The maintainer owns and is responsible for that code. This means
that he is responsible for fixing bugs and answer problem reports
pertaining to that piece of the code, and in the case of contributed
software, for tracking new versions, as appropriate.Changes to directories which have a maintainer defined shall be sent
to the maintainer for review before being committed. Only if the
maintainer does not respond for an unacceptable period of time, to
several emails, will it be acceptable to commit changes without review
by the maintainer. However, it is suggested that you try and have the
changes reviewed by someone else if at all possible.It is of course not acceptable to add a person or group as
maintainer unless they agree to assume this duty. On the other hand it
doesn't have to be a committer and it can easily be a group of
people.Contributed SoftwareContributed by &a.phk; and &a.obrien;. June 1996.Some parts of the FreeBSD distribution consist of software that is
actively being maintained outside the FreeBSD project. For historical
reasons, we call this contributed software. Some
examples are perl, gcc and patch.Over the last couple of years, various methods have been used in
dealing with this type of software and all have some number of
advantages and drawbacks. No clear winner has emerged.Since this is the case, after some debate one of these methods has
been selected as the “official” method and will be required
for future imports of software of this kind. Furthermore, it is
strongly suggested that existing contributed software converge on this
model over time, as it has significant advantages over the old method,
including the ability to easily obtain diffs relative to the
“official” versions of the source by everyone (even without
cvs access). This will make it significantly easier to return changes
to the primary developers of the contributed software.Ultimately, however, it comes down to the people actually doing the
work. If using this model is particularly unsuited to the package being
dealt with, exceptions to these rules may be granted only with the
approval of the core team and with the general consensus of the other
developers. The ability to maintain the package in the future will be a
key issue in the decisions.Because of some unfortunate design limitations with the RCS file
format and CVS's use of vendor branches, minor, trivial and/or
cosmetic changes are strongly discouraged on
files that are still tracking the vendor branch. “Spelling
fixes” are explicitly included here under the
“cosmetic” category and are to be avoided for files with
revision 1.1.x.x. The repository bloat impact from a single character
change can be rather dramatic.The Tcl embedded programming
language will be used as example of how this model works:src/contrib/tcl contains the source as
distributed by the maintainers of this package. Parts that are entirely
not applicable for FreeBSD can be removed. In the case of Tcl, the
mac, win and
compat subdirectories were eliminated before the
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 and without RCS keyword expansion) with as few
FreeBSD-specific changes as possible. The 'easy-import' tool on
freefall will assist in doing the import, but if there are any doubts on
how to go about it, it is imperative that you ask first and not blunder
ahead and hope it “works out”. CVS is not forgiving of
import accidents and a fair amount of effort is required to back out
major mistakes.Because of the previously mentioned design limitations with CVS's
vendor branches, it is required that “official” patches from
the vendor be applied to the original distributed sources and the result
re-imported onto the vendor branch again. Official patches should never
be patched into the FreeBSD checked out version and "committed", as this
destroys the vendor branch coherency and makes importing future versions
rather difficult as there will be conflicts.Since many packages contain files that are meant for compatibility
with other architectures and environments that FreeBSD, it is
permissible to remove parts of the distribution tree that are of no
interest to FreeBSD in order to save space. Files containing copyright
notices and release-note kind of information applicable to the remaining
files shall not be removed.If it seems easier, the 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 outWhere the original distribution was obtained from and/or the
official master site.Where to send patches back to the original authorsPerhaps an overview of the FreeBSD-specific changes that have
been made.However, please do not import FREEBSD-upgrade
with the contributed source. Rather you should cvs add
FREEBSD-upgrade ; cvs ci after the initial import. Example
wording from src/contrib/cpio is below:
This directory contains virgin sources of the original distribution files
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
the files in this directory via patches and a cvs commit. New versions or
official-patch versions must be imported. Please remember to import with
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
For the import of GNU cpio 2.4.2, the following files were removed:
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
To upgrade to a newer version of cpio, when it is available:
1. Unpack the new version into an empty directory.
[Do not make ANY changes to the files.]
2. Remove the files listed above and any others that don't apply to
FreeBSD.
3. Use the command:
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
For example, to do the import of version 2.4.2, I typed:
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Follow the instructions printed out in step 3 to resolve any
conflicts between local FreeBSD changes and the newer version.
Do not, under any circumstances, deviate from this procedure.
To make local changes to cpio, simply patch and commit to the main
branch (aka HEAD). Never make local changes on the GNU branch.
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
inclusion in the next vendor release.
obrien@FreeBSD.org - 30 March 1997Encumbered filesIt might occasionally be necessary to include an encumbered file in
the FreeBSD source tree. For example, if a device requires a small
piece of binary code to be loaded to it before the device will operate,
and we do not have the source to that code, then the binary file is said
to be encumbered. The following policies apply to including encumbered
files in the FreeBSD source tree.Any file which is interpreted or executed by the system CPU(s)
and not in source format is encumbered.Any file with a license more restrictive than BSD or GNU is
encumbered.A file which contains downloadable binary data for use by the
hardware is not encumbered, unless (1) or (2) apply to it. It must
be stored in an architecture neutral ASCII format (file2c or
uuencoding is recommended).Any encumbered file requires specific approval from the Core team before it is added to the
CVS repository.Encumbered files go in src/contrib or
src/sys/contrib.The entire module should be kept together. There is no point in
splitting it, unless there is code-sharing with non-encumbered
code.Object files are named
arch/filename.o.uu>.Kernel files;Should always be referenced in
conf/files.* (for build simplicity).Should always be in LINT, but the Core team decides per case if it
should be commented out or not. The Core team can, of course, change
their minds later on.The Release Engineer
decides whether or not it goes in to the release.User-land files;The Core team decides if
the code should be part of make world.The Release Engineer
decides if it goes in to the release.Shared LibrariesContributed 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.
diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
index 8f3ecfdc06..a96cc080df 100644
--- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
@@ -1,934 +1,934 @@
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:hostdefault gatewayinterfaceLocal2Local1ethernetLocal1T1-GWPPPA 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
&man.traceroute.8; command. It is equally useful if you cannot seem
to make a connection to a remote machine (i.e. &man.ping.8;
fails).The &man.traceroute.8; 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
&man.traceroute.8;.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 0As a manual mount command on freebox:&prompt.root; 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 0As a manual mount command on fastws:&prompt.root; 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 InstructionsFind 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:helpprint help listip
print/set client's IP addressserver
print/set bootp/tftp server addressnetmask
print/set netmaskhostname nameprint/set hostnamekernel
print/set kernel namerootfs
print/set root filesystemswapfs
print/set swap filesystemswapsize
set diskless swapsize in Kbytesdiskbootboot from diskautobootcontinue boot processtrans
|turn transceiver on|offflags
set boot flagsA typical completely diskless cfg file might contain:
rootfs 192.1.2.3:/rootfs/myclient
swapfs 192.1.2.3:/swapfs
swapsize 20000
hostname myclient.mydomainA 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.mydomainAnd 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:&prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000Also, 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:&prompt.root; chmod 0600 /swapfs/swap.192.1.2.4Unpack 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 / and /usr
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 CardsContributed by &a.hm;.This section is really only relevant to ISDN users in countries
where the DSS1/Q.931 ISDN standard is supported.Some growing number of PC ISDN cards are supported under FreeBSD
2.2.x and up by the isdn4bsd driver package. It is still under
development but the reports show that it is successfully used all over
Europe.The latest isdn4bsd version is available from ftp://isdn4bsd@ftp.consol.de/pub/,
the main isdn4bsd ftp site (you have to log in as user
isdn4bsd , give your mail address as the password
and change to the pub directory. Anonymous ftp
as user ftp or anonymous
will not give the desired result).Isdn4bsd allows you to connect to other ISDN routers using either
IP over raw HDLC or by using synchronous PPP. A telephone answering
machine application is also available.Many ISDN PC cards are supported, mostly the ones with a Siemens
ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola,
Cologne Chip Designs) is currently under development. For an
up-to-date list of supported cards, please have a look at the README
file.In case you are interested in adding support for a different ISDN
protocol, a currently unsupported ISDN PC card or otherwise enhancing
isdn4bsd, please get in touch with hm@kts.org.A majordomo maintained mailing list is available. To join the
list, send mail to majordomo@FreeBSD.org and
specify:
subscribe freebsd-isdnin 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 PPP 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 PPP option, not the user-land iijPPP.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 serial ports
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 lineIf 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.
diff --git a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml
index 2b8fe22c2a..a86cfe5598 100644
--- a/en_US.ISO8859-1/books/handbook/backups/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/backups/chapter.sgml
@@ -1,621 +1,621 @@
BackupsIssues of hardware compatibility are among the most troublesome in the
computer industry today and FreeBSD is by no means immune to trouble. In
this respect, FreeBSD's advantage of being able to run on inexpensive
commodity PC hardware is also its liability when it comes to support for
the amazing variety of components on the market. While it would be
impossible to provide a exhaustive listing of hardware that FreeBSD
supports, this section serves as a catalog of the device drivers included
with FreeBSD and the hardware each drivers supports. Where possible and
appropriate, notes about specific products are included. You may also
want to refer to the kernel
configuration file section in this handbook for a list of
supported devices.As FreeBSD is a volunteer project without a funded testing department,
we depend on you, the user, for much of the information contained in this
catalog. If you have direct experience of hardware that does or does not
work with FreeBSD, please let us know by sending e-mail to the &a.doc;.
Questions about supported hardware should be directed to the &a.questions
(see Mailing Lists for more
information). When submitting information or asking a question, please
remember to specify exactly what version of FreeBSD you are using and
include as many details of your hardware as possible.* What about backups to floppies?Tape MediaThe major tape media are the 4mm, 8mm, QIC, mini-cartridge and
DLT.4mm (DDS: Digital Data Storage)4mm tapes are replacing QIC as the workstation backup media of
choice. This trend accelerated greatly when Conner purchased Archive,
a leading manufacturer of QIC drives, and then stopped production of
QIC drives. 4mm drives are small and quiet but do not have the
reputation for reliability that is enjoyed by 8mm drives. The
cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51
x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short
head life for the same reason, both use helical scan.Data thruput on these drives starts ~150kB/s, peaking at ~500kB/s.
Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware
compression, available with most of these drives, approximately
doubles the capacity. Multi-drive tape library units can have 6
drives in a single cabinet with automatic tape changing. Library
capacities reach 240 GB.4mm drives, like 8mm drives, use helical-scan. All the benefits
and drawbacks of helical-scan apply to both 4mm and 8mm drives.Tapes should be retired from use after 2,000 passes or 100 full
backups.8mm (Exabyte)8mm tapes are the most common SCSI tape drives; they are the best
choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm
tape drive. 8mm drives are reliable, convenient and quiet. Cartridges
are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm).
One downside of 8mm tape is relatively short head and tape life due to
the high rate of relative motion of the tape across the heads.Data thruput ranges from ~250kB/s to ~500kB/s. Data sizes start
at 300 MB and go up to 7 GB. Hardware compression, available with
most of these drives, approximately doubles the capacity. These
drives are available as single units or multi-drive tape libraries
with 6 drives and 120 tapes in a single cabinet. Tapes are changed
automatically by the unit. Library capacities reach 840+ GB.Data is recorded onto the tape using helical-scan, the heads are
positioned at an angle to the media (approximately 6 degrees). The
tape wraps around 270 degrees of the spool that holds the heads. The
spool spins while the tape slides over the spool. The result is a
high density of data and closely packed tracks that angle across the
tape from one edge to the other.QICQIC-150 tapes and drives are, perhaps, the most common tape drive
and media around. QIC tape drives are the least expensive "serious"
backup drives. The downside is the cost of media. QIC tapes are
expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB
data storage. But, if your needs can be satisfied with a half-dozen
tapes, QIC may be the correct choice. QIC is the
most common tape drive. Every site has a QIC
drive of some density or another. Therein lies the rub, QIC has a
large number of densities on physically similar (sometimes identical)
tapes. QIC drives are not quiet. These drives audibly seek before
they begin to record data and are clearly audible whenever reading,
writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x
10.2 x 1.7 mm). Mini-cartridges, which
also use 1/4" wide tape are discussed separately. Tape libraries and
changers are not available.Data thruput ranges from ~150kB/s to ~500kB/s. Data capacity
ranges from 40 MB to 15 GB. Hardware compression is available on many
of the newer QIC drives. QIC drives are less frequently installed;
they are being supplanted by DAT drives.Data is recorded onto the tape in tracks. The tracks run along
the long axis of the tape media from one end to the other. The number
of tracks, and therefore the width of a track, varies with the tape's
capacity. Most if not all newer drives provide backward-compatibility
at least for reading (but often also for writing). QIC has a good
reputation regarding the safety of the data (the mechanics are simpler
and more robust than for helical scan drives).Tapes should be retired from use after 5,000 backups.* Mini-CartridgeDLTDLT has the fastest data transfer rate of all the drive types
listed here. The 1/2" (12.5mm) tape is contained in a single spool
cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a
swinging gate along one entire side of the cartridge. The drive
mechanism opens this gate to extract the tape leader. The tape leader
has an oval hole in it which the drive uses to "hook" the tape. The
take-up spool is located inside the tape drive. All the other tape
cartridges listed here (9 track tapes are the only exception) have
both the supply and take-up spools located inside the tape cartridge
itself.Data thruput is approximately 1.5MB/s, three times the thruput of
4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB
for a single drive. Drives are available in both multi-tape changers
and multi-tape, multi-drive tape libraries containing from 5 to 900
tapes over 1 to 20 drives, providing from 50GB to 9TB of
storage.Data is recorded onto the tape in tracks parallel to the direction
of travel (just like QIC tapes). Two tracks are written at once.
Read/write head lifetimes are relatively long; once the tape stops
moving, there is no relative motion between the heads and the
tape.Using a new tape for the first timeThe first time that you try to read or write a new, completely
blank tape, the operation will fail. The console messages should be
similar to:sa0(ncr1:4:0): NOT READY asc:4,1
sa0(ncr1:4:0): Logical unit is in process of becoming readyThe tape does not contain an Identifier Block (block number 0).
All QIC tape drives since the adoption of QIC-525 standard write an
Identifier Block to the tape. There are two solutions:mt fsf 1 causes the tape drive to write an
Identifier Block to the tape.Use the front panel button to eject the tape.Re-insert the tape and &man.dump.8; data to the tape.&man.dump.8; will report DUMP: End of tape
detected and the console will show: HARDWARE
FAILURE info:280 asc:80,96rewind the tape using: mt rewindSubsequent tape operations are successful.Backup ProgramsThe three major programs are
&man.dump.8;,
&man.tar.1;,
and
&man.cpio.1;.Dump and Restore&man.dump.8; and &man.restore.8; are the traditional Unix backup
programs. They operate on the drive as a collection of disk blocks,
below the abstractions of files, links and directories that are
created by the filesystems. &man.dump.8; backs up devices, entire
filesystems, not parts of a filesystem and not directory trees that
span more than one filesystem, using either soft links &man.ln.1; or
mounting one filesystem onto another. &man.dump.8; does not write
files and directories to tape, but rather writes the data blocks that
are the building blocks of files and directories. &man.dump.8; has
quirks that remain from its early days in Version 6 of ATT Unix (circa
1975). The default parameters are suitable for 9-track tapes (6250
bpi), not the high-density media available today (up to 62,182 ftpi).
These defaults must be overridden on the command line to utilize the
capacity of current tape drives.&man.rdump.8; and &man.rrestore.8; backup data across the network
to a tape drive attached to another computer. Both programs rely upon
&man.rcmd.3; and &man.ruserok.3; to access the remote tape drive.
Therefore, the user performing the backup must have
rhosts access to the remote computer. The
arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use
on the remote computer. (e.g. When rdump'ing from
a FreeBSD computer to an Exabyte tape drive connected to a Sun called
komodo, use: /sbin/rdump 0dsbfu 54000 13000
126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there
are security implications to allowing rhosts
commands. Evaluate your situation carefully.Tar&man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975).
&man.tar.1; operates in cooperation with the filesystem; &man.tar.1;
writes files and directories to tape. &man.tar.1; does not support the
full range of options that are available from &man.cpio.1;, but
&man.tar.1; does not require the unusual command pipeline that
&man.cpio.1; uses.Most versions of &man.tar.1; do not support backups across the
network. The GNU version of &man.tar.1;, which FreeBSD utilizes,
supports remote devices using the same syntax as &man.rdump.8;. To
&man.tar.1; to an Exabyte tape drive connected to a Sun called
komodo, use: /usr/bin/tar cf
komodo:/dev/nrsa8 . 2>&1. For versions without remote
device support, you can use a pipeline and &man.rsh.1; to send the
data to a remote tape drive. (XXX add an example command)Cpio&man.cpio.1; is the original Unix file interchange tape program
for magnetic media. &man.cpio.1; has options (among many others) to
perform byte-swapping, write a number of different archives format,
and pipe the data to other programs. This last feature makes
&man.cpio.1; and excellent choice for installation media.
&man.cpio.1; does not know how to walk the directory tree and a list
of files must be provided through stdin.&man.cpio.1; does not support backups across the network. You can
use a pipeline and &man.rsh.1; to send the data to a remote tape
drive. (XXX add an example command)Pax&man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and
&man.cpio.1;. Over the years the various versions of &man.tar.1;
and &man.cpio.1; have gotten slightly incompatible. So rather than
fight it out to fully standardize them, POSIX created a new archive
utility. &man.pax.1; attempts to read and write many of the various
&man.cpio.1; and &man.tar.1; formats, plus new formats of its own.
Its command set more resembles &man.cpio.1; than &man.tar.1;.AmandaAmanda
(Advanced Maryland Network Disk Archiver) is a client/server backup
system, rather than a single program. An Amanda server will backup to
a single tape drive any number of computers that have Amanda clients
and network communications with the Amanda server. A common problem
at locations with a number of large disks is the length of time
required to backup to data directly to tape exceeds the amount of time
available for the task. Amanda solves this problem. Amanda can use a
"holding disk" to backup several filesystems at the same time. Amanda
creates "archive sets": a group of tapes used over a period of time to
create full backups of all the filesystems listed in Amanda's
configuration file. The "archive set" also contains nightly
incremental (or differential) backups of all the filesystems.
Restoring a damaged filesystem requires the most recent full backup
and the incremental backups.The configuration file provides fine control backups and the
network traffic that Amanda generates. Amanda will use any of the
above backup programs to write the data to tape. Amanda is available
as either a port or a package, it is not installed by default.Do nothing“Do nothing” is not a computer program, but it is the
most widely used backup strategy. There are no initial costs. There
is no backup schedule to follow. Just say no. If something happens
to your data, grin and bear it!If your time and your data is worth little to nothing, then
“Do nothing” is the most suitable backup program for your
computer. But beware, Unix is a useful tool, you may find that within
six months you have a collection of files that are valuable to
you.“Do nothing” is the correct backup method for
/usr/obj and other directory trees that can be
exactly recreated by your computer. An example is the files that
comprise these handbook pages-they have been generated from
SGML input files. Creating backups of these
HTML files is not necessary. The
SGML source files are backed up regularly.Which Backup Program is Best?&man.dump.8; Period. Elizabeth D. Zwicky
torture tested all the backup programs discussed here. The clear
choice for preserving all your data and all the peculiarities of Unix
filesystems is &man.dump.8;. Elizabeth created filesystems containing
a large variety of unusual conditions (and some not so unusual ones)
and tested each program by do a backup and restore of that
filesystems. The peculiarities included: files with holes, files with
holes and a block of nulls, files with funny characters in their
names, unreadable and unwritable files, devices, files that change
size during the backup, files that are created/deleted during the
backup and more. She presented the results at LISA V in Oct. 1991.
See torture-testing
Backup and Archive Programs.Emergency Restore ProcedureBefore the DisasterThere are only four steps that you need to perform in
preparation for any disaster that may occur.First, print the disklabel from each of your disks
(e.g. disklabel da0 | lpr), your filesystem table
(/etc/fstab) and all boot messages, two copies of
each.Second, determine that the boot and fixit floppies
(boot.flp and fixit.flp)
have all your devices. The easiest way to check is to reboot your
machine with the boot floppy in the floppy drive and check the boot
messages. If all your devices are listed and functional, skip on to
step three.Otherwise, you have to create two custom bootable floppies which
has a kernel that can mount your all of your disks and access your
tape drive. These floppies must contain:
&man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and
whichever backup program you use. These programs must be statically
linked. If you use &man.dump.8;, the floppy must contain
&man.restore.8;.Third, create backup tapes regularly. Any changes that you make
after your last backup may be irretrievably lost. Write-protect the
backup tapes.Fourth, test the floppies (either boot.flp
and fixit.flp or the two custom bootable
floppies you made in step two.) and backup tapes. Make notes of the
procedure. Store these notes with the bootable floppy, the
printouts and the backup tapes. You will be so distraught when
restoring that the notes may prevent you from destroying your backup
tapes (How? In place of tar xvf /dev/rsa0, you
might accidently type tar cvf /dev/rsa0 and
over-write your backup tape).For an added measure of security, make bootable floppies and two
backup tapes each time. Store one of each at a remote location. A
remote location is NOT the basement of the same office building. A
number of firms in the World Trade Center learned this lesson the
hard way. A remote location should be physically separated from
your computers and disk drives by a significant distance.An example script for creating a bootable floppy:
/mnt/sbin/init
gzip -c -best /sbin/fsck > /mnt/sbin/fsck
gzip -c -best /sbin/mount > /mnt/sbin/mount
gzip -c -best /sbin/halt > /mnt/sbin/halt
gzip -c -best /sbin/restore > /mnt/sbin/restore
gzip -c -best /bin/sh > /mnt/bin/sh
gzip -c -best /bin/sync > /mnt/bin/sync
cp /root/.profile /mnt/root
cp -f /dev/MAKEDEV /mnt/dev
chmod 755 /mnt/dev/MAKEDEV
chmod 500 /mnt/sbin/init
chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt
chmod 555 /mnt/bin/sh /mnt/bin/sync
chmod 6555 /mnt/sbin/restore
#
# create the devices nodes
#
cd /mnt/dev
./MAKEDEV std
./MAKEDEV da0
./MAKEDEV da1
./MAKEDEV da2
./MAKEDEV sa0
./MAKEDEV pty0
cd /
#
# create minimum filesystem table
#
cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd <After the DisasterThe key question is: did your hardware survive? You have been
doing regular backups so there is no need to worry about the
software.If the hardware has been damaged. First, replace those parts
that have been damaged.If your hardware is okay, check your floppies. If you are using
a custom boot floppy, boot single-user (type -s
at the boot: prompt). Skip the following
paragraph.If you are using the boot.flp and
fixit.flp floppies, keep reading. Insert the
boot.flp floppy in the first floppy drive and
boot the computer. The original install menu will be displayed on
the screen. Select the Fixit--Repair mode with CDROM or
floppy. option. Insert the
fixit.flp when prompted.
restore and the other programs that you need are
located in /mnt2/stand.Recover each filesystem separately.Try to &man.mount.8; (e.g. mount /dev/da0a
/mnt) the root partition of your first disk. If the
disklabel was damaged, use &man.disklabel.8; to re-partition and
label the disk to match the label that your printed and saved. Use
&man.newfs.8; to re-create the filesystems. Re-mount the root
partition of the floppy read-write (mount -u -o rw
/mnt). Use your backup program and backup tapes to
recover the data for this filesystem (e.g. restore vrf
/dev/sa0). Unmount the filesystem (e.g. umount
/mnt) Repeat for each filesystem that was
damaged.Once your system is running, backup your data onto new tapes.
Whatever caused the crash or data loss may strike again. An another
hour spent now, may save you from further distress later.* I did not prepare for the Disaster, What Now?
diff --git a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml
index d0563703f7..81bc59f689 100644
--- a/en_US.ISO8859-1/books/handbook/basics/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/basics/chapter.sgml
@@ -1,139 +1,139 @@
Unix BasicsThe Online ManualThe most comprehensive documentation on FreeBSD is in the form of
man pages. Nearly every program on the system
comes with a short reference manual explaining the basic operation and
various arguments. These manuals can be view with the
man command. Use of the man
command is simple:&prompt.user; man commandcommand is the name of the command you
wish to learn about. For example, to learn more about
ls command type:&prompt.user; man lsThe online manual is divided up into numbered sections:User commandsSystem calls and error numbersFunctions in the C librariesDevice driversFile formatsGames and other diversionsMiscellaneous informationSystem maintenance and operation commandsKernel developersIn some cases, the same topic may appear in more than one section of
the on-line manual. For example, there is a chmod
user command and a chmod() system call. In this
case, you can tell the man command which one you want
by specifying the section:&prompt.user; man 1 chmodThis will display the manual page for the user command
chmod. References to a particular section of the
on-line manual are traditionally placed in parenthesis in written
documentation, so &man.chmod.1; refers to the
chmod user command and &man.chmod.2; refers to the
system call.This is fine if you know the name of the command and simply wish to
know how to use it, but what if you cannot recall the command name? You
can use man to search for keywords in the command
descriptions by using the
switch:&prompt.user; man -k mailWith this command you will be presented with a list of commands that
have the keyword “mail” in their descriptions. This is
actually functionally equivalent to using the apropos
command.So, you are looking at all those fancy commands in
/usr/bin but do not even have the faintest idea
what most of them actually do? Simply do a
&prompt.user; cd /usr/bin; man -f *
or
&prompt.user; cd /usr/bin; whatis *
which does the same thing.GNU Info FilesFreeBSD includes many applications and utilities produced by the
Free Software Foundation (FSF). In addition to man pages, these
programs come with more extensive hypertext documents called
“info” files which can be viewed with the
info command or, if you installed
emacs, the info mode of
emacs.To use the &man.info.1; command, simply type:&prompt.user; infoFor a brief introduction, type h. For a
quick command reference, type ?.
diff --git a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
index 3666b3bc11..872cb4615c 100644
--- a/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/bibliography/chapter.sgml
@@ -1,478 +1,478 @@
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.FreeBSD mit Methode (in German), published by Computer und
Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0.FreeBSD Install and Utilization Manual (in Japanese), published by Mainichi Communications Inc..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-6Ohio State
University has written a UNIX
Introductory Course which is available online in HTML and
postscript format.Jpman Project, Japan
FreeBSD Users Group. FreeBSD User's
Reference Manual (Japanese translation). Mainichi Communications
Inc., 1998. ISBN4-8399-0088-4 P3800E.Administrators' GuidesAlbitz, Paul and Liu, Cricket. DNS and
BIND, 2nd Ed. O'Reilly & Associates, Inc., 1997.
ISBN 1-56592-236-0Computer 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-0Frisch, Æleen. Essential System
Administration, 2nd Ed. O'Reilly & Associates,
Inc., 1995. ISBN 1-56592-127-5Hunt, 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-7Jpman Project, Japan
FreeBSD Users Group. FreeBSD System
Administrator's Manual (Japanese translation). Mainichi Communications
Inc., 1998. ISBN4-8399-0109-0 P3300E.Programmers' 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-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. Porting 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. 2nd Ed, PTR Prentice Hall, 1998. ISBN
0-13-490012-XWells, 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-9Schimmel, Curt. Unix Systems for Modern
Architectures. Reading, Mass. : Addison-Wesley, 1994.
ISBN 0-201-63338-8Stevens, 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 Internet Security: Repelling the Wily Hacker.
Reading, Mass. : Addison-Wesley, 1995. ISBN
0-201-63357-4Garfinkel, Simson and Gene Spafford. Practical UNIX
Security. 2nd Ed. O'Reilly & Associates, Inc.,
1996. ISBN 1-56592-148-8Garfinkel, Simson. PGP Pretty Good
Privacy O'Reilly & Associates, Inc., 1995. ISBN
1-56592-098-8Hardware 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-7Intel Corporation publishes documentation on their CPUs,
chipsets and standards on their developer web site,
usually as PDF files.Shanley, 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 Dictionary, 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. ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree 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/Old BSD releases from the Computer Systems Research
group (CSRG). http://www.mckusick.com/csrg/:
The 4CD set covers all BSD versions from 1BSD to 4.4BSD and
4.4BSD-Lite2 (but not 2.11BSD, unfortunately). As well, the last
disk holds the final sources plus the SCCS files.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-2688
diff --git a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
index ad51a1de65..15d5bdb3d7 100644
--- a/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/contrib/chapter.sgml
@@ -1,5804 +1,5804 @@
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;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.eivind;Fix the union file system. Coordinator: &a.dg;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;New bus architecture. Coordinator: &a.newbus;Port existing ISA drivers to new architecture.Move all interrupt-management code to appropriate parts of
the bus drivers.Port PCI subsystem to new architecture. Coordinator:
&a.dfr;Figure out the right way to handle removable devices and
then use that as a substrate on which PC-Card and CardBus
support can be implemented.Resolve the probe/attach priority issue once and for
all.Move any remaining buses over to the new
architecture.Kernel issues. Overall coordination: &a.hackers;Add more pro-active security infrastructure. Overall
coordination: &a.security;Build something like Tripwire(TM) into the kernel, with a
remote and local part. There are a number of cryptographic
issues to getting this right; contact the coordinator for
details. Coordinator: &a.eivind;Make the entire kernel use suser()
instead of comparing to 0. It is presently using about half
of each. Coordinator: &a.eivind;Split securelevels into different parts, to allow an
administrator to throw away those privileges he can throw
away. Setting the overall securelevel needs to have the same
effect as now, obviously. Coordinator: &a.eivind;Make it possible to upload a list of “allowed
program” to BPF, and then block BPF from accepting other
programs. This would allow BPF to be used e.g. for DHCP,
without allowing an attacker to start snooping the local
network.Update the security checker script. We should at least
grab all the checks from the other BSD derivatives, and add
checks that a system with securelevel increased also have
reasonable flags on the relevant parts. Coordinator:
&a.eivind;Add authorization infrastructure to the kernel, to allow
different authorization policies. Part of this could be done
by modifying suser(). Coordinator:
&a.eivind;Add code to the NFS layer so that you cannot
chdir("..") out of an NFS partition. E.g.,
/usr is a UFS partition with
/usr/src NFS exported. Now it is
possible to use the NFS filehandle for
/usr/src to get access to
/usr.Medium priority tasksThe following tasks need to be done, but not with any particular
urgency:Full KLD based driver support/Configuration Manager.Write a configuration manager (in the 3rd stage boot?)
that probes your hardware in a sane manner, keeps only the
KLDs required for your hardware, etc.PCMCIA/PCCARD. Coordinators: &a.msmith; 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.msmith; 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 N items are from Terry Lambert
terry@lambert.orgNetWare 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.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).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 &ng.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!Work through the PR databaseThe FreeBSD PR
list shows all the current active problem reports and
requests for enhancement that have been submitted by FreeBSD users.
Look through the open PRs, and see if anything there takes your
interest. Some of these might be very simple tasks, that just need an
extra pair of eyes to look over them and confirm that the fix in the
PR is a good one. Others might be much more complex.Start with the PRs that have not been assigned to anyone else, but
if one them is assigned to someone else, but it looks like something
you can handle, e-mail the person it is assigned to and ask if you can
work on it—they might already have a patch ready to be tested,
or further ideas that you can discuss with them.How to ContributeContributions to the system generally fall into one or more of the
following 6 categories:Bug reports and general commentaryAn 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 mailing lists 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 &man.send-pr.1; program 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.
When including patches, do not use cut-and-paste
because cut-and-paste turns tabs into spaces and makes them unusable.
Consider compressing patches and using &man.uuencode.1; if they exceed
20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/.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 &man.send-pr.1; 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 Bug Reports and General
Commentary.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 Staying current with FreeBSD 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 &man.diff.1;
command, with the “context diff” form
being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; 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 &man.diff.1; for more
details.Once you have a set of diffs (which you may test with the
&man.patch.1; command), you should submit them for inclusion with
FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary.
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 &man.uuencode.1; 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 &man.send-pr.1;. 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.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(c)(3) (charitable)
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.dg;
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 Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO box
can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to &a.jkh,
either via email or to the FreeBSD, Inc. postal address given above.
If you do not wish to be listed in our donors 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.dg;
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
admin@FreeBSD.org 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:&a.mbarkah and his employer,
Hemisphere Online, donated a Pentium Pro
(P6) 200Mhz CPUASA
Computers donated a Tyan 1662
motherboard.Joe McGuckin joe@via.net of ViaNet Communications donated
a Kingston ethernet controller.Jack O'Neill jack@diamond.xtalwind.net
donated an NCR 53C875 SCSI controller
card.Ulf Zimmermann ulf@Alameda.net 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 Anderson
ANDRSN@HOOVER.STANFORD.EDU&a.dillonEpilogue Technology
Corporation&a.sefDon Scott WildeGianmarco Giovannelli
gmarco@masternet.itJosef C. Grosch joeg@truenorth.orgRobert T. Morris&a.chuckrKenneth P. Stox ken@stox.sa.enteract.com of
Imaginary Landscape,
LLC.Dmitry S. Kohmanyuk dk@dog.farm.orgLaser5 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.BuffNETPacific
SolutionsSiemens AG
via Andre
AlbsmeierChris SilvaHardware 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.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 kuku@FreeBSD.org 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 history 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
doscmd command.Core Team AlumniThe following people were members of the FreeBSD core team during
the periods indicated. We thank them for their past efforts in the
service of the FreeBSD project.In rough chronological order:&a.guido (1995 - 1999)&a.dyson (1993 - 1998)&a.nate (1992 - 1996)&a.rgrimes (1992 - 1995)Andreas Schulz (1992 - 1995)&a.csgr (1993 - 1995)&a.paul (1992 - 1995)&a.smace (1993 - 1994)Andrew Moore (1993 - 1994)Christoph Robitschko (1993 - 1994)J. T. Conklin (1992 - 1993)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 and OpenBSD that have been
integrated into FreeBSD as well, and we would therefore like to thank
all the contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAMAGAI Yoshiji amagai@nue.orgAaron Bornstein aaronb@j51.comAaron Smith aaron@mutex.orgAchim Patzner ap@noses.comAda T Lim ada@bsd.orgAdam Baran badam@mw.mil.plAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian Colley aecolley@ois.ieAdrian Hall adrian@ibmpcug.co.ukAdrian Mariano adrian@cam.cornell.eduAdrian Steinmann ast@marabu.chAdam Strohl troll@digitalspark.netAdrian T. Filipi-Martin
atf3r@agate.cs.virginia.eduAjit Thyagarajan unknownAkio Morita
amorita@meadow.scphys.kyoto-u.ac.jpAkira SAWADA unknownAkira Watanabe
akira@myaw.ei.meisei-u.ac.jpAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker
A.C.P.M.Kalker@student.utwente.nlAlan Bawden alan@curry.epilogue.comAlec Wolman wolman@cs.washington.eduAled Morris aledm@routers.co.ukAlex garbanzo@hooked.netAlex D. Chen
dhchen@Canvas.dorm7.nccu.edu.twAlex G. Bulushev bag@demos.suAlex Le Heux alexlh@funk.orgAlex Perel veers@disturbed.netAlexander B. Povolotsky tarkhil@mgt.msk.ruAlexander Leidinger
netchild@wurzelausix.CS.Uni-SB.DEAlexander Langer alex@cichlids.comAlexandre Snarskii snar@paranoia.ruAlistair G. Crooks agc@uts.amdahl.comAllan Saddi asaddi@philosophysw.comAllen Campbell allenc@verinet.comAmakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jpAmancio Hasty hasty@star-gate.comAmir Farah amir@comtrol.comAmy Baron amee@beer.orgAnatoly A. Orehovsky tolik@mpeks.tomsk.suAnatoly Vorobey mellon@pobox.comAnders Nordby nickerne@nome.noAnders Thulin Anders.X.Thulin@telia.seAndras Olah olah@cs.utwente.nlAndre Albsmeier
Andre.Albsmeier@mchp.siemens.deAndre Oppermann andre@pipeline.chAndreas Haakh ah@alman.robin.deAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndreas Schulz unknownAndreas Wetzel mickey@deadline.snafu.deAndreas Wrede andreas@planix.comAndres Vega Garcia unknownAndrew Atrens atreand@statcan.caAndrew Boothman andrew@cream.orgAndrew Gillham gillham@andrews.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew J. Korty ajk@purdue.eduAndrew L. Moore alm@mclink.comAndrew McRae amcrae@cisco.comAndrew Stevenson andrew@ugh.net.auAndrew Timonin tim@pool1.convey.ruAndrew V. Stesin stesin@elvisti.kiev.uaAndrew Webster awebster@dataradio.comAndrey Zakhvatov andy@icc.surw.chel.suAndy Farkas andyf@speednet.com.auAndy Valencia ajv@csd.mot.comAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.comAnton Berezin tobez@plab.ku.dkAntti Kaipila anttik@iki.fiAre Bryne are.bryne@communique.noAri Suutari ari@suutari.iki.fiArjan de Vet devet@IAEhv.nlArne Henrik Juul arnej@Lise.Unit.NOAssar Westerlund assar@sics.seAtsushi Furuta furuta@sra.co.jpAtsushi Murai amurai@spec.co.jpBakul Shah bvs@bitblocks.comBarry Bierbauch pivrnec@vszbr.czBarry Lustig barry@ictv.comBen Hutchinson benhutch@xfiles.org.ukBen Jackson unknownBen Smithurst ben@scientia.demon.co.ukBen Walter bwalter@itachi.swcp.comBenjamin Lewis bhlewis@gte.netBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBill Trost trost@cloud.rain.comBlaz Zupan blaz@amis.netBob Van Valzah Bob@whitebarn.comBob Willcox bob@luke.pmr.comBoris Staeblow balu@dva.in-berlin.deBoyd R. Faulkner faulkner@asgard.bga.comBrad Karp karp@eecs.harvard.eduBradley Dunn bradley@dunn.orgBrandon Fosdick bfoz@glue.umd.eduBrandon Gillespie brandon@roguetrader.com&a.wlloydBob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Lymn blymn@mulga.awadi.com.AUBrett Taylor
brett@peloton.physics.montana.eduBrian Campbell brianc@pobox.comBrian Clapper bmc@willscreek.comBrian Cully shmit@kublai.comBrian Handy
handy@lambic.space.lockheed.comBrian Litzinger brian@MediaCity.comBrian McGovern bmcgover@cisco.comBrian Moore ziff@houdini.eecs.umich.eduBrian R. Haug haug@conterra.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce A. Mah bmah@ca.sandia.govBruce Albrecht bruce@zuhause.mn.orgBruce Gingery bgingery@gtcs.comBruce J. Keeler loodvrij@gridpoint.comBruce Murphy packrat@iinet.net.auBruce Walter walter@fortean.comCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCarl Mascott cmascott@world.std.comCasper casper@acc.amCastor Fu castor@geocast.comCejka Rudolf cejkar@dcse.fee.vutbr.czChain Lee chain@110.netCharles Hannum mycroft@ai.mit.eduCharles Henrich henrich@msu.eduCharles Mott cmott@srv.netCharles Owens owensc@enc.eduChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChiharu Shibata chi@bd.mbn.or.jpChip Norkus unknownChoi Jun Ho junker@jazz.snu.ac.krChris Csanady cc@tarsier.ca.sandia.govChris Dabrowski chris@vader.orgChris Dillon cdillon@wolves.k12.mo.usChris Shenton
cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer
cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristian Weisgerber
naddy@bigeye.rhein-neckar.deChristoph P. Kukulies kuku@FreeBSD.orgChristoph Robitschko
chmr@edvz.tu-graz.ac.atChristoph Weber-Fahr
wefa@callcenter.systemhaus.netChristopher G. Demetriou
cgd@postgres.berkeley.eduChristopher T. Johnson
cjohnson@neunacht.netgsi.comChrisy Luke chrisy@flix.netChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGColman Reilly careilly@tcd.ieConrad Sabatier conrads@neosoft.comCoranth Gryphon gryphon@healer.comCornelis van der Laan
nils@guru.ims.uni-stuttgart.deCove Schneider cove@brazil.nbn.comCraig Leres leres@ee.lbl.govCraig Loomis unknownCraig Metz cmetz@inner.netCraig Spannring cts@internetcds.comCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comCy Schubert cschuber@uumail.gov.bc.caDI. Christian Gusenbauer
cg@scotty.edvz.uni-linz.ac.atDai Ishijima ishijima@tri.pref.osaka.jpDaisuke Watanabe NU7D-WTNB@asahi-net.or.jpDamian Hamill damian@cablenet.netDan Cross tenser@spitfire.ecsel.psu.eduDan Lukes dan@obluda.czDan Nelson dnelson@emsphone.comDan Walters hannibal@cyberstation.netDaniel M. Eischen
deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDaniel Poirot poirot@aio.jsc.nasa.govDaniel Rock rock@cs.uni-sb.deDanny Egen unknownDanny J. Zerkel dzerkel@phofarm.comDarren Reed avalon@coombs.anu.edu.auDave Adkins adkin003@tc.umn.eduDave Andersen angio@aros.netDave Blizzard dblizzar@sprynet.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Cornejo dave@dogwood.comDave Edmondson davided@sco.comDave Glowacki dglo@ssec.wisc.eduDave Marquardt marquard@austin.ibm.comDave Tweten tweten@FreeBSD.orgDavid A. Adkins adkin003@tc.umn.eduDavid A. Bader dbader@umiacs.umd.eduDavid Borman dab@bsdi.comDavid Dawes dawes@XFree86.orgDavid Filo filo@yahoo.comDavid Holland dholland@eecs.harvard.eduDavid Holloway daveh@gwythaint.tamis.comDavid Horwitt dhorwitt@ucsd.eduDavid Hovemeyer daveho@infocom.comDavid Jones dej@qpoint.torfree.netDavid Kelly dkelly@tomcat1.tbe.comDavid Kulp dkulp@neomorphic.comDavid L. Nugent davidn@blaze.net.auDavid Leonard d@scry.dstc.edu.auDavid Malone dwmalone@maths.tcd.ieDavid Muir Sharnoff muir@idiom.comDavid S. Miller davem@jenolan.rutgers.eduDavid Wolfskill dhw@whistle.comDean Gaudet dgaudet@arctic.orgDean Huxley dean@fsa.caDenis Fortin unknownDennis Glatting
dennis.glatting@software-munitions.comDenton Gentry denny1@home.comDerek Inksetter derek@saidev.comDima Sivachenko dima@Chg.RUDirk Keunecke dk@panda.rhein-main.deDirk Nehrling nerle@pdv.deDmitry Khrustalev dima@xyzzy.machaon.ruDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDominik Brettnacher domi@saargate.deDominik Rother dr@domix.deDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Morrison dmorrisn@u.washington.eduDon Yuniskis dgy@rtd.comDonald Maddox dmaddox@conterra.comDoug Barton studded@dal.netDouglas Ambrisko ambrisko@whistle.comDouglas Carmichael dcarmich@mcs.comDouglas Crosher dtc@scrooge.ee.swin.oz.auDrew Derbyshire ahd@kew.comDuncan Barclay dmlb@ragnet.demon.co.ukDustin Sallings dustin@spy.netEckart "Isegrim" Hofmann
Isegrim@Wunder-Nett.orgEd Gold
vegold01@starbase.spd.louisville.eduEd Hudson elh@p5.spnet.comEdward Wang edward@edcom.comEdwin Groothus edwin@nwm.wan.philips.comEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectElmar Bartel
bartel@informatik.tu-muenchen.deEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Haug ejh@slustl.slu.eduEric J. Schwertfeger eric@cybernut.comEric L. Hernes erich@lodgenet.comEric P. Scott eps@sirius.comEric Sprinkle eric@ennovatenetworks.comErich Stefan Boleyn erich@uruk.orgErik E. Rantapaa rantapaa@math.umn.eduErik H. Moe ehm@cris.comErnst Winter ewinter@lobo.muc.deEspen Skoglund espensk@stud.cs.uit.no>Eugene M. Kim astralblue@usa.netEugene Radchenko genie@qsar.chem.msu.suEvan Champion evanc@synapse.netFaried Nawaz fn@Hungry.COMFlemming Jacobsen fj@tfs.comFong-Ching Liaw fong@juniper.netFrancis M J Hsieh mjshieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan
frankch@waru.life.nthu.edu.twFrank Durda IV uhclem@nemesis.lonestar.orgFrank MacLachlan fpm@n2.netFrank Nobis fn@Radio-do.deFrank Volf volf@oasis.IAEhv.nlFrank ten Wolde franky@pinewood.nlFrank van der Linden frank@fwi.uva.nlFred Cawthorne fcawth@jjarray.umn.eduFred Gilham gilham@csl.sri.comFred Templin templin@erg.sri.comFrederick Earl Gray fgray@rice.eduFUJIMOTO Kensaku
fujimoto@oscar.elec.waseda.ac.jpFUJISHIMA Satsuki k5@respo.or.jpFURUSAWA Kazuhisa
furusawa@com.cs.osakafu-u.ac.jpGabor Kincses gabor@acm.orgGabor Zahemszky zgabor@CoDe.huG. Adam Stanislavadam@whizkidtech.netGarance A Drosehn gad@eclipse.its.rpi.eduGareth McCaughan gjm11@dpmms.cam.ac.ukGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGary J. garyj@rks32.pcs.dec.comGary Kline kline@thought.orgGaspar Chilingarov nightmar@lemming.acc.amGea-Suan Lin gsl@tpts4.seed.net.twGeoff Rehmet csgr@alpha.ru.ac.zaGeorg Wagner georg.wagner@ubs.comGerard Roudier groudier@club-internet.frGianmarco Giovannelli
gmarco@giovannelli.itGil Kloepfer Jr. gil@limbic.ssdl.comGilad Rom rom_glsa@ein-hashofet.co.ilGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGiles Lean giles@nemeton.com.auGlen Foster gfoster@gfoster.comGlenn Johnson gljohns@bellsouth.netGodmar Back gback@facility.cs.utah.eduGoran Hammarback goran@astro.uu.seGord Matzigkeit gord@enci.ucalgary.caGordon Greeff gvg@uunet.co.zaGraham Wheeler gram@cdsec.comGreg A. Woods woods@zeus.leitch.comGreg Ansley gja@ansley.comGreg Troxel gdt@ir.bbn.comGreg Ungerer gerg@stallion.oz.auGregory Bond gnb@itga.com.auGregory D. Moncreaff
moncrg@bt340707.res.ray.comGuy Harris guy@netapp.comGuy Helmer ghelmer@cs.iastate.eduHAMADA Naoki hamada@astec.co.jpHONDA Yasuhiro
honda@kashio.info.mie-u.ac.jpHOSOBUCHI Noriyuki hoso@buchi.tama.or.jpHannu Savolainen hannu@voxware.pp.fiHans Huebner hans@artcom.deHans Petter Bieker zerium@webindex.noHans Zuidam hans@brandinnovators.comHarlan Stenn Harlan.Stenn@pfcs.comHarold Barker hbarker@dsms.comHavard Eidnes
Havard.Eidnes@runit.sintef.noHeikki Suonsivu hsu@cs.hut.fiHeiko W. Rupp unknownHelmut F. Wirth hfwirth@ping.atHenrik Vestergaard Draboel
hvd@terry.ping.dkHerb Peyerl hpeyerl@NetBSD.orgHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jpHideki Yamamoto hyama@acm.orgHideyuki Suzuki
hideyuki@sat.t.u-tokyo.ac.jpHirayama Issei iss@mail.wbs.ne.jpHiroaki Sakai sakai@miya.ee.kagu.sut.ac.jpHiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jpHironori Ikura hikura@kaisei.orgHiroshi Nishikawa nis@pluto.dti.ne.jpHiroya Tsubakimoto unknownHolger Veit Holger.Veit@gmd.deHolm Tiffe holm@geophysik.tu-freiberg.deHorance Chou
horance@freedom.ie.cycu.edu.twHorihiro Kumagai kuma@jp.FreeBSD.orgHOTARU-YA hotaru@tail.netHr.Ladavac lada@ws2301.gud.siemens.co.atHubert Feyrer hubertf@NetBSD.ORGHugh F. Mahon hugh@nsmdserv.cnd.hp.comHugh Mahon h_mahon@fc.hp.comHung-Chi Chu hcchu@r350.ee.ntu.edu.twIMAI Takeshi take-i@ceres.dti.ne.jpIMAMURA Tomoaki
tomoak-i@is.aist-nara.ac.jpIan Dowse iedowse@maths.tcd.ieIan Holland ianh@tortuga.com.auIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Khasilev igor@jabber.paco.odessa.uaIgor Roshchin str@giganda.komkon.orgIgor Sviridov siac@ua.netIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIlya V. Komarov mur@lynx.ruIssei Suzuki issei@jp.FreeBSD.orgItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. Bryant jbryant@argus.flash.netJ. David Lowe lowe@saturn5.comJ. Han hjh@best.comJ. Hawk jhawk@MIT.EDUJ.T. Conklin jtc@cygnus.comJ.T. Jang keith@email.gcn.net.twJack jack@zeus.xtalwind.netJacob Bohn Lorensen jacob@jblhome.ping.mkJagane D Sundar jagane@netcom.comJake Burkholder jake@checker.orgJake Hamby jehamby@lightside.comJames Clark jjc@jclark.comJames D. Stewart jds@c4systm.comJames Jegers jimj@miller.cs.uwm.eduJames Raynard
fhackers@jraynard.demon.co.ukJames T. Liu jtliu@phlebas.rockefeller.eduJames da Silva jds@cs.umd.eduJan Conard
charly@fachschaften.tu-muenchen.deJan Koum jkb@FreeBSD.orgJanick Taillandier
Janick.Taillandier@ratp.frJanusz Kokot janek@gaja.ipan.lublin.plJarle Greipsland jarle@idt.unit.noJason Garman init@risen.orgJason Thorpe thorpej@NetBSD.orgJason Wright jason@OpenBSD.orgJason Young
doogie@forbidden-donut.anet-stl.comJavier Martin Rueda jmrueda@diatel.upm.esJay Fenlason hack@datacube.comJaye Mathisen mrcpu@cdsnet.netJeff Bartig jeffb@doit.wisc.eduJeff Forys jeff@forys.cranbury.nj.usJeff Kletsky Jeff@Wagsky.comJeffrey Evans evans@scnc.k12.mi.usJeffrey Wheat jeff@cetlink.netJens Schweikhardt schweikh@noc.dfn.dJeremy Allison jallison@whistle.comJeremy Chatfield jdc@xinside.comJeremy Lea reg@shale.csir.co.zaJeremy Prior unknownJeroen Ruigrok/Asmodai asmodai@wxs.nlJesse Rosenstock jmr@ugcs.caltech.eduJian-Da Li jdli@csie.nctu.edu.twJim Babb babb@FreeBSD.orgJim Binkley jrb@cs.pdx.eduJim Carroll jim@carroll.comJim Flowers jflowers@ezo.netJim Leppek jleppek@harris.comJim Lowe james@cs.uwm.eduJim Mattson jmattson@sonic.netJim Mercer jim@komodo.reptiles.orgJim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld.orgJin Guojun jin@george.lbl.govJoachim Kuebart unknownJoao Carlos Mendes Luis jonny@jonny.eng.brJochen Pohl jpo.drs@sni.deJoe "Marcus" Clarke marcus@miami.eduJoe Abley jabley@clear.co.nzJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoe Orthoefer j_orthoefer@tia.netJoe Traister traister@mojozone.orgJoel Faedi Joel.Faedi@esial.u-nancy.frJoel Ray Holveck joelh@gnu.orgJoel Sutton sutton@aardvark.apana.org.auJohan Granlund johan@granlund.nuJohan Karlsson k@numeri.campus.luth.seJohan Larsson johan@moon.campus.luth.seJohann Tonsing jtonsing@mikom.csir.co.zaJohannes Helander unknownJohannes Stille unknownJohn Baldwin jobaldwi@vt.eduJohn Beckett jbeckett@southern.eduJohn Beukema jbeukema@hk.super.netJohn Brezak unknownJohn Capo jc@irbs.comJohn F. Woods jfw@jfwhome.funhouse.comJohn Goerzen
jgoerzen@alexanderwohl.complete.orgJohn Hay jhay@mikom.csir.co.zaJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Kohl unknownJohn Lind john@starfire.mn.orgJohn Mackin john@physiol.su.oz.auJohn P johnp@lodgenet.comJohn Perry perry@vishnu.alias.netJohn Preisler john@vapornet.comJohn Rochester jr@cs.mun.caJohn Sadler john_sadler@alum.mit.eduJohn Saunders john@pacer.nlc.net.auJohn W. DeBoskey jwd@unx.sas.comJohn Wehle john@feith.comJohn Woods jfw@eddie.mit.eduJon Morgan morgan@terminus.trailblazer.comJonathan H N Chin jc254@newton.cam.ac.ukJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJorge Goncalves j@bug.fe.up.ptJorge M. Goncalves ee96199@tom.fe.up.ptJos Backus jbackus@plex.nlJose M. Alcaide jose@we.lc.ehu.esJose Marques jose@nobody.orgJosef Grosch
jgrosch@superior.mooseriver.comJosef Karthauser joe@uk.FreeBSD.orgJoseph Stein joes@wstein.comJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJukka A. Ukkonen jua@iki.fiJulian Assange proff@suburbia.netJulian Coleman j.d.coleman@ncl.ac.uk&a.jhsJulian Jenkins kaveman@magna.com.auJunichi Satoh junichi@jp.FreeBSD.orgJunji SAKAI sakai@jp.FreeBSD.orgJunya WATANABE junya-w@remus.dti.ne.jpK.Higashino a00303@cc.hc.keio.ac.jpKUNISHIMA Takeo kunishi@c.oka-pu.ac.jpKai Vorma vode@snakemail.hut.fiKaleb S. Keithley kaleb@ics.comKaneda Hiloshi vanitas@ma3.seikyou.ne.jpKapil Chowksey kchowksey@hss.hns.comKarl Denninger karl@mcs.comKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comKato Takenori
kato@eclogite.eps.nagoya-u.ac.jpKATO Tsuguru tkato@prontomail.ne.jpKawanobe Koh kawanobe@st.rim.or.jpKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKazuo Horikawa horikawa@jp.FreeBSD.orgKees Jan Koster kjk1@ukc.ac.ukKeith Bostic bostic@bostic.comKeith E. Walker unknownKeith Moore unknownKeith Sklower unknownKelly Yancey kbyanc@posi.netKen Hornstein unknownKen Key key@cs.utk.eduKen Mayer kmayer@freegate.comKenji Saito marukun@mx2.nisiq.netKenji Tomita tommyk@da2.so-net.or.jpKenneth Furge kenneth.furge@us.endress.comKenneth Monville desmo@bandwidth.orgKenneth R. Westerback krw@tcn.netKenneth Stailey kstailey@gnu.ai.mit.eduKent Talarico kent@shipwreck.tsoft.netKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKevin Bracey kbracey@art.acorn.co.ukKevin Day toasty@dragondata.comKevin Lahey kml@nas.nasa.govKevin Lokevlo@hello.com.twKevin Street street@iname.comKevin Van Maren vanmaren@fast.cs.utah.eduKiroh HARADA kiroh@kh.rim.or.jpKlaus Klein kleink@layla.inka.deKlaus-J. Wolf Yanestra@t-online.deKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.suKouichi Hirabayashi kh@mogami-wire.co.jpKurt D. Zeilenga Kurt@Boolean.NETKurt Olsen kurto@tiny.mcs.usu.eduL. Jonas Olsson
ljo@ljo-slip.DIALIN.CWRU.EduLars Köller
Lars.Koeller@Uni-Bielefeld.DELarry Altneu larry@ALR.COMLaurence Lopez lopez@mv.mv.comLee Cremeans lcremean@tidalwave.netLiang Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twLon Willett lon%softt.uucp@math.utah.eduLouis A. Mamakos louie@TransSys.COMLouis Mamakos loiue@TransSys.comLucas James Lucas.James@ldjpc.apana.org.auLyndon Nerenberg lyndon@orthanc.comM.C. Wong unknownMANTANI Nobutaka nobutaka@nobutaka.comMIHIRA Sanpei Yoshiro sanpei@sanpei.orgMITA Yoshio mita@jp.FreeBSD.orgMITSUNAGA Noriaki
mitchy@er.ams.eng.osaka-u.ac.jpMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMagnus Enbom dot@tinto.campus.luth.seMahesh Neelakanta mahesh@gcomm.comMakoto MATSUSHITA matusita@jp.FreeBSD.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jpMalte Lance malte.lance@gmx.netManu Iyengar
iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMarc van Woerkom van.woerkom@netcologne.deMarcel Moolenaar marcel@scc.nlMario Sergio Fujikawa Ferreira
lioux@gns.com.brMark Andrews unknownMark Cammidge mark@gmtunx.ee.uct.ac.zaMark Diekhans markd@grizzly.comMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Mayo markm@vmunix.comMark Thompson thompson@tgsoft.comMark Tinguely tinguely@plains.nodak.eduMark Treacy unknownMark Valentine mark@linus.demon.co.ukMartin BirgmeierMartin Ibert mib@ppe.bb-data.deMartin Kammerhofer dada@sbox.tu-graz.ac.atMartin Renters martin@tdc.on.caMartti Kuparinen
martti.kuparinen@ericsson.comMasachika ISHIZUKA
ishizuka@isis.min.ntt.jpMas.TAKEMURA unknownMasafumi NAKANE max@wide.ad.jpMasahiro Sekiguchi
seki@sysrap.cs.fujitsu.co.jpMasanobu Saitoh msaitoh@spa.is.uec.ac.jpMasanori Kanaoka kana@saijo.mke.mei.co.jpMasanori Kiriake seiken@ARGV.ACMasatoshi TAMURA
tamrin@shinzan.kuee.kyoto-u.ac.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas matt@3am-software.comMatt White mwhite+@CMU.EDUMatthew C. Mead mmead@Glock.COMMatthew Cashdollar mattc@rfcnet.comMatthew Flatt mflatt@cs.rice.eduMatthew Fuller fullermd@futuresouth.comMatthew Stein matt@bdd.netMatthias Pfaller leo@dachau.marco.deMatthias Scheler tron@netbsd.orgMattias Gronlund
Mattias.Gronlund@sa.erisoft.seMattias Pantzare pantzer@ludd.luth.seMaurice Castro
maurice@planet.serc.rmit.edu.auMax Euston meuston@jmrodgers.comMax Khon fjoe@husky.iclub.nsu.ruMaxim Bolotin max@rsu.ruMaxim V. Sobolev sobomax@altavista.netMicha Class
michael_class@hpbbse.bbn.hp.comMichael Butler imb@scgt.oz.auMichael Butschky butsch@computi.erols.comMichael Clay mclay@weareb.orgMichael Elbel me@FreeBSD.orgMichael Galassi nerd@percival.rain.comMichael Hancock michaelh@cet.co.jpMichael Hohmuth hohmuth@inf.tu-dresden.deMichael Perlman canuck@caam.rice.eduMichael Petry petry@netwolf.NetMasters.comMichael Reifenberger root@totum.plaut.deMichael Sardo jaeger16@yahoo.comMichael Searle searle@longacre.demon.co.ukMichal Listos mcl@Amnesiac.123.orgMichio Karl Jinbo
karl@marcer.nagaokaut.ac.jpMiguel Angel Sagreras
msagre@cactus.fi.uba.arMihoko Tanaka m_tonaka@pa.yokogawa.co.jpMika Nystrom mika@cs.caltech.eduMikael Hybsch micke@dynas.seMikael Karpberg
karpen@ocean.campus.luth.seMike Del repenting@hotmail.comMike Durian durian@plutotech.comMike Durkin mdurkin@tsoft.sf-bay.orgMike E. Matsnev mike@azog.cs.msu.suMike Evans mevans@candle.comMike Grupenhoff kashmir@umiacs.umd.eduMike Hibler mike@marker.cs.utah.eduMike Karels unknownMike McGaughey mmcg@cs.monash.edu.auMike Meyer mwm@shiva.the-park.comMike Mitchell mitchell@ref.tfs.comMike Murphy mrm@alpharel.comMike Peck mike@binghamton.eduMike Spengler mks@msc.eduMikhail A. Sokolov mishania@demos.suMikhail Teterin mi@aldan.ziplink.netMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMitsuru IWASAKI iwasaki@pc.jaring.myMitsuru Yoshida mitsuru@riken.go.jpMonte Mitzelfelt monte@gonefishing.orgMorgan Davis root@io.cts.comMostyn Lewis mostyn@mrl.comMotomichi Matsuzaki mzaki@e-mail.ne.jpMotoyuki Kasahara m-kasahr@sra.co.jpMotoyuki Konno motoyuki@snipe.rim.or.jpMurray Stokely murray@cdrom.comN.G.Smith ngs@sesame.hensa.ac.ukNAGAO Tadaaki nagao@cs.titech.ac.jpNAKAJI Hiroyuki
nakaji@tutrp.tut.ac.jpNAKAMURA Kazushi nkazushi@highway.or.jpNAKAMURA Motonori
motonori@econ.kyoto-u.ac.jpNIIMI Satoshi sa2c@and.or.jpNOKUBI Hirotaka h-nokubi@yyy.or.jpNadav Eiron nadav@barcode.co.ilNanbor Wang nw1@cs.wustl.eduNaofumi Honda
honda@Kururu.math.sci.hokudai.ac.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNathan Ahlstrom nrahlstr@winternet.comNathan Dorfman nathan@rtfm.netNeal Fachan kneel@ishiboo.comNeil Blakey-Milner nbm@rucus.ru.ac.zaNiall Smart rotel@indigo.ieNick Barnes Nick.Barnes@pobox.comNick Handel nhandel@NeoSoft.comNick Hilliard nick@foobar.org&a.nsayer;Nick Williams njw@cs.city.ac.ukNickolay N. Dudorov nnd@itfs.nsk.suNiklas Hallqvist niklas@filippa.appli.seNisha Talagala nisha@cs.berkeley.eduNo Name ZW6T-KND@j.asahi-net.or.jpNo Name adrian@virginia.eduNo Name alex@elvisti.kiev.uaNo Name anto@netscape.netNo Name bobson@egg.ics.nitch.ac.jpNo Name bovynf@awe.beNo Name burg@is.ge.comNo Name chris@gnome.co.ukNo Name colsen@usa.netNo Name coredump@nervosa.comNo Name dannyman@arh0300.urh.uiuc.eduNo Name davids@SECNET.COMNo Name derek@free.orgNo Name devet@adv.IAEhv.nlNo Name djv@bedford.netNo Name dvv@sprint.netNo Name enami@ba2.so-net.or.jpNo Name flash@eru.tubank.msk.suNo Name flash@hway.ruNo Name fn@pain.csrv.uidaho.eduNo Name gclarkii@netport.neosoft.comNo Name gordon@sheaky.lonestar.orgNo Name graaf@iae.nlNo Name greg@greg.rim.or.jpNo Name grossman@cygnus.comNo Name gusw@fub46.zedat.fu-berlin.deNo Name hfir@math.rochester.eduNo Name hnokubi@yyy.or.jpNo Name iaint@css.tuu.utas.edu.auNo Name invis@visi.comNo Name ishisone@sra.co.jpNo Name iverson@lionheart.comNo Name jpt@magic.netNo Name junker@jazz.snu.ac.krNo Name k-sugyou@ccs.mt.nec.co.jpNo Name kenji@reseau.toyonaka.osaka.jpNo Name kfurge@worldnet.att.netNo Name lh@aus.orgNo Name lhecking@nmrc.ucc.ieNo Name mrgreen@mame.mu.oz.auNo Name nakagawa@jp.FreeBSD.orgNo Name ohki@gssm.otsuka.tsukuba.ac.jpNo Name owaki@st.rim.or.jpNo Name pechter@shell.monmouth.comNo Name pete@pelican.pelican.comNo Name pritc003@maroon.tc.umn.eduNo Name risner@stdio.comNo Name roman@rpd.univ.kiev.uaNo Name root@ns2.redline.ruNo Name root@uglabgw.ug.cs.sunysb.eduNo Name stephen.ma@jtec.com.auNo Name sumii@is.s.u-tokyo.ac.jpNo Name takas-su@is.aist-nara.ac.jpNo Name tamone@eig.unige.chNo Name tjevans@raleigh.ibm.comNo Name tony-o@iij.ad.jp amurai@spec.co.jpNo Name torii@tcd.hitachi.co.jpNo Name uenami@imasy.or.jpNo Name uhlar@netlab.skNo Name vode@hut.fiNo Name wlloyd@mpd.caNo Name wlr@furball.wellsfargo.comNo Name wmbfmk@urc.tue.nlNo Name yamagata@nwgpc.kek.jpNo Name ziggy@ryan.orgNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru
kogane@koganemaru.co.jpNorio Suzuki nosuzuki@e-mail.ne.jpNoritaka Ishizumi graphite@jp.FreeBSD.orgNoriyuki Soda soda@sra.co.jpOh Junseon hollywar@mail.holywar.netOlaf Wagner wagner@luthien.in-berlin.deOleg Sharoiko os@rsu.ruOleg V. Volkov rover@lglobus.ruOliver Breuninger ob@seicom.NETOliver Friedrichs oliver@secnet.comOliver Fromme
oliver.fromme@heim3.tu-clausthal.deOliver Laumann
net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.comOlof Johansson offe@ludd.luth.seOsokin Sergey aka oZZ ozz@FreeBSD.org.ruPace Willisson pace@blitz.comPaco Rosich rosich@modico.eleinf.uv.esPalle Girgensohn girgen@partitur.seParag Patel parag@cgt.comPascal Pederiva pascal@zuo.dec.comPasvorn Boonmark boonmark@juniper.netPatrick Gardella patrick@cre8tivegroup.comPatrick Hausen unknownPaul Antonov apg@demos.suPaul F. Werkowski unknownPaul Fox pgf@foxharp.boston.ma.usPaul Koch koch@thehub.com.auPaul Kranenburg pk@NetBSD.orgPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPaul S. LaFollette, Jr. unknownPaul Saab paul@mu.orgPaul Sandys myj@nyct.netPaul T. Root proot@horton.iaces.comPaul Vixie paul@vix.comPaulo Menezes paulo@isr.uc.ptPaulo Menezes pm@dee.uc.ptPedro A M Vazquez vazquez@IQM.Unicamp.BRPedro Giffuni giffunip@asme.orgPete Bentley pete@demon.netPeter Childs pjchilds@imforei.apana.org.auPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Jeremy perer.jeremy@alcatel.com.auPeter M. Chen pmchen@eecs.umich.eduPeter Much peter@citylink.dinoex.sub.orgPeter Olsson unknownPeter Philipp pjp@bsd-daemon.netPeter Stubbs PETERS@staidan.qld.edu.auPhil Maker pjm@cs.ntu.edu.auPhil Sutherland
philsuth@mycroft.dialix.oz.auPhil Taylor phil@zipmail.co.ukPhilip Musumeci philip@rmit.edu.auPierre Y. Dampure pierre.dampure@k2c.co.ukPius Fischer pius@ienet.comPomegranate daver@flag.blackened.netPowerdog Industries
kevin.ruddy@powerdog.comR. Kym HorsellRajesh Vaidheeswarran rv@fore.comRalf Friedl friedl@informatik.uni-kl.deRandal S. Masutani randal@comtest.comRandall Hopper rhh@ct.picker.comRandall W. Dean rwd@osf.orgRandy Bush rbush@bainbridge.verio.netReinier Bezuidenhout
rbezuide@mikom.csir.co.zaRemy Card Remy.Card@masi.ibp.frRicardas Cepas rch@richard.eu.orgRiccardo Veraldi veraldi@cs.unibo.itRichard Henderson richard@atheist.tamu.eduRichard Hwang rhwang@bigpanda.comRichard Kiss richard@homemail.comRichard J Kuhns rjk@watson.grauel.comRichard M. Neswold
rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Straka straka@user1.inficad.comRichard Tobin richard@cogsci.ed.ac.ukRichard Wackerbarth rkw@Dataplex.NETRichard Winkel rich@math.missouri.eduRichard Wiwatowski rjwiwat@adelaide.on.netRick Macklem rick@snowhite.cis.uoguelph.caRick Macklin unknownRob Austein sra@epilogue.comRob Mallory rmallory@qualcomm.comRob Snow rsnow@txdirect.netRobert Crowe bob@speakez.comRobert D. Thrush rd@phoenix.aii.comRobert Eckardt
roberte@MEP.Ruhr-Uni-Bochum.deRobert Sanders rsanders@mindspring.comRobert Sexton robert@kudra.comRobert Shady rls@id.netRobert Swindells swindellsr@genrad.co.ukRobert Watson robert@cyrus.watson.orgRobert Withrow witr@rwwa.comRobert Yoder unknownRobin Carey
robin@mailgate.dtc.rankxerox.co.ukRoger Hardiman roger@cs.strath.ac.ukRoland Jesse jesse@cs.uni-magdeburg.deRon Bickers rbickers@intercenter.netRon Lenk rlenk@widget.xmission.comRonald Kuehn kuehn@rz.tu-clausthal.deRudolf Cejka unknownRuslan Belkin rus@home2.UA.netRuslan Ermilov ru@ucb.crimea.uaRuslan Shevchenko rssh@cam.grad.kiev.uaRussell L. Carter rcarter@pinyon.orgRussell Vincent rv@groa.uct.ac.zaRyan Younce ryany@pobox.comRyuichiro IMURA imura@cs.titech.ac.jpSANETO Takanori sanewo@strg.sony.co.jpSAWADA Mizuki miz@qb3.so-net.ne.jpSUGIMURA Takashi sugimura@jp.FreeBSD.orgSURANYI Peter
suranyip@jks.is.tsukuba.ac.jpSakai Hiroaki sakai@miya.ee.kagu.sut.ac.jpSakari Jalovaara sja@tekla.fiSam Hartman hartmans@mit.eduSamuel Lam skl@ScalableNetwork.comSamuele Zannoli zannoli@cs.unibo.itSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoh Junichi junichi@astec.co.jpScot Elliott scot@poptart.orgScot W. Hetzel hetzels@westbend.netScott A. Kenney saken@rmta.ml.orgScott Blachowicz
scott.blachowicz@seaslug.orgScott Burris scott@pita.cns.ucla.eduScott Hazen Mueller scott@zorch.sf-bay.orgScott Michel scottm@cs.ucla.eduScott Mitchel scott@uk.FreeBSD.orgScott Reynolds scott@clmqt.marquette.mi.usSebastian Strollo seb@erix.ericsson.seSerge A. Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSergei Chechetkin
csl@whale.sunbay.crimea.uaSergei S. Laskavy laskavy@pc759.cs.msu.suSergey Gershtein sg@mplik.ruSergey Kosyakov ks@itp.ac.ruSergey Potapov sp@alkor.ruSergey Shkonda serg@bcs.zp.uaSergey V.Dorokhov svd@kbtelecom.nalnet.ruSergio Lenzi lenzi@bsi.com.brShaun Courtney shaun@emma.eng.uct.ac.zaShawn M. Carey smcarey@mailbox.syr.eduShigio Yamaguchi shigio@tamacom.comShinya Esu esu@yk.rim.or.jpShuichi Tanaka stanaka@bb.mbn.or.jpShunsuke Akiyama akiyama@jp.FreeBSD.orgSimon simon@masi.ibp.frSimon Burge simonb@telstra.com.auSimon J Gerraty sjg@melb.bull.oz.auSimon Marlow simonm@dcs.gla.ac.ukSimon Shapiro shimon@simon-shapiro.orgSin'ichiro MIYATANI siu@phaseone.co.jpSlaven Rezic eserte@cs.tu-berlin.deSoochon Radee slr@mitre.orgSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comSoren S. Jorvang soren@dt.dkStefan Bethke stb@hanse.deStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan Petri unknownStefan `Sec` Zehl sec@42.orgSteinar Haug sthaug@nethelp.noStephane E. Potvin sepotvin@videotron.caStephane Legrand stephane@lituus.frStephen Clawson
sclawson@marker.cs.utah.eduStephen F. Combs combssf@salem.ge.comStephen Farrell stephen@farrell.orgStephen Hocking sysseh@devetir.qld.gov.auStephen J. Roznowski sjr@home.netStephen McKay syssgm@devetir.qld.gov.auStephen Melvin melvin@zytek.comSteve Bauer sbauer@rock.sdsmt.eduSteve Coltrin spcoltri@io.comSteve Deering unknownSteve Gerakines steve2@genesis.tiac.netSteve Gericke steveg@comtrol.comSteve Piette steve@simon.chi.il.USSteve Schwarz schwarz@alpharel.comSteven G. Kargl
kargl@troutmask.apl.washington.eduSteven H. Samorodin samorodi@NUXI.comSteven McCanne mccanne@cs.berkeley.eduSteven Plite splite@purdue.eduSteven Wallace unknownStuart Henderson
stuart@internationalschool.co.ukSue Blake sue@welearn.com.auSugimoto Sadahiro ixtl@komaba.utmc.or.jpSugiura Shiro ssugiura@duo.co.jpSujal Patel smpatel@wam.umd.eduSune Stjerneby stjerneby@usa.netSuzuki Yoshiaki
zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakahiro Yugawa yugawa@orleans.rim.or.jpTakanori Watanabe
takawata@shidahara1.planet.sci.kobe-u.ac.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeru NAIKI naiki@bfd.es.hokudai.ac.jpTakeshi Amaike amaike@iri.co.jpTakeshi MUTOH mutoh@info.nara-k.ac.jpTakeshi Ohashi
ohashi@mickey.ai.kyutech.ac.jpTakeshi WATANABE
watanabe@crayon.earth.s.kobe-u.ac.jpTakuya SHIOZAKI
tshiozak@makino.ise.chuo-u.ac.jpTatoku Ogaito tacha@tera.fukui-med.ac.jpTatsumi HOSOKAWA hosokawa@jp.FreeBSD.orgTed Buswell tbuswell@mediaone.netTed Faber faber@isi.eduTed Lemon mellon@isc.orgTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo de Raadt deraadt@OpenBSD.orgThomas thomas@mathematik.uni-Bremen.deThomas D. Dean tomdean@ix.netcom.comThomas David Rivers rivers@dignus.comThomas G. McWilliams tgm@netcom.comThomas Gellekum
thomas@ghpc8.ihf.rwth-aachen.deThomas Graichen
graichen@omega.physik.fu-berlin.deThomas König
Thomas.Koenig@ciw.uni-karlsruhe.deThomas Ptacek unknownThomas A. Stephens tas@stephens.orgThomas Stromberg tstrombe@rtci.comThomas Valentino Crimi
tcrimi+@andrew.cmu.eduThomas Wintergerst thomas@lemur.nord.deÞórður Ívarsson
totii@est.isTim Kientzle kientzle@netcom.comTim Singletary
tsingle@sunland.gsfc.nasa.govTim Wilkinson tim@sarc.city.ac.ukTimo J. Rinne tri@iki.fiTodd Miller millert@openbsd.orgTom root@majestix.cmr.noTom tom@sdf.comTom Gray - DCA dcasba@rain.orgTom Jobbins tom@tom.tjTom Pusateri pusateri@juniper.netTom Rush tarush@mindspring.comTom Samplonius tom@misery.sdf.comTomohiko Kurahashi
kura@melchior.q.t.u-tokyo.ac.jpTony Kimball alk@Think.COMTony Li tli@jnx.comTony Lynn wing@cc.nsysu.edu.twTony Maher tonym@angis.org.auTorbjorn Granlund tege@matematik.su.seToshihiko ARAI toshi@tenchi.ne.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpToshihiro Kanda candy@kgc.co.jpToshiomi Moriki
Toshiomi.Moriki@ma1.seikyou.ne.jpTrefor S. trefor@flevel.co.ukTrevor Blackwell tlb@viaweb.comURATA Shuichiro s-urata@nmit.tmg.nec.co.jpUdo Schweigert ust@cert.siemens.deUgo Paternostro paterno@dsi.unifi.itUlf Kieber kieber@sax.deUlli Linzen ulli@perceval.camelot.deUstimenko Semen semen@iclub.nsu.ruUwe Arndt arndt@mailhost.uni-koblenz.deVadim Chekan vadim@gc.lviv.uaVadim Kolontsov vadim@tversu.ac.ruVadim Mikhailov mvp@braz.ruVan Jacobson van@ee.lbl.govVasily V. Grechishnikov
bazilio@ns1.ied-vorstu.ac.ruVasim Valejev vasim@uddias.diaspro.comVernon J. Schryver vjs@mica.denver.sgi.comVic Abell abe@cc.purdue.eduVille Eerola ve@sci.fiVincent Poy vince@venus.gaianet.netVincenzo Capuano
VCAPUANO@vmprofs.esoc.esa.deVirgil Champlin champlin@pa.dec.comVladimir A. Jakovenko
vovik@ntu-kpi.kiev.uaVladimir Kushnir kushn@mail.kar.netVsevolod Lobko seva@alex-ua.comW. Gerald Hicks wghicks@bellsouth.netW. Richard Stevens rstevens@noao.eduWalt Howard howard@ee.utah.eduWarren Toomey wkt@csadfa.cs.adfa.oz.auWayne Scott wscott@ichips.intel.comWerner Griessl
werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWietse Venema wietse@wzv.win.tue.nlWilfredo Sanchez wsanchez@apple.comWiljo Heinen wiljo@freeside.ki.open.deWilko Bulte wilko@yedi.iaf.nlWill Andrews andrews@technologist.comWillem Jan Withagen wjw@surf.IAE.nlWilliam Jolitz withheldWilliam Liao william@tale.netWojtek Pilorz
wpilorz@celebris.bdk.lublin.plWolfgang Helbig helbig@ba-stuttgart.deWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@FreeBSD.orgWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYarema yds@ingress.comYaroslav Terletsky ts@polynet.lviv.uaYasuhito FUTATSUKI futatuki@fureai.or.jpYasuhiro Fukama yasuf@big.or.jpYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYixin Jin yjin@rain.cs.ucla.eduYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshihiko OHTA yohta@bres.tsukuba.ac.jpYoshihisa NAKAGAWA
y-nakaga@ccs.mt.nec.co.jpYoshikazu Goto gotoh@ae.anritsu.co.jpYoshimasa Ohnishi
ohnishi@isc.kyutech.ac.jpYoshishige Arai ryo2@on.rim.or.jpYuichi MATSUTAKA matutaka@osa.att.ne.jpYujiro MIYATA
miyata@bioele.nuee.nagoya-u.ac.jpYukihiro Nakai nacai@iname.comYusuke Nawano azuki@azkey.orgYuu Yashiki s974123@cc.matsuyama-u.ac.jpYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nlYves Fonk yves@dutncp8.tn.tudelft.nlZach Heilig zach@gaffaneys.comZahemszhky Gabor zgabor@code.huZhong Ming-Xun zmx@mail.CDPA.nsysu.edu.twarci vega@sophia.inria.frder Mouse mouse@Collatz.McRCIM.McGill.EDUfrf frf@xocolatl.comEge Rekk aagero@aage.priv.no386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou
cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko
chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens
felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes
Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse
lohse@tech7.informatik.uni-hamburg.deJörg Wunsch
joerg_wunsch@uriah.heep.sax.deJohn DysonJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@FreeBSD.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland
philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.orgRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
index 0889a7e540..b5f4b3d7b4 100644
--- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml
@@ -1,2482 +1,2482 @@
The 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 not?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-currentJoin 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 important bulletins which
may be critical to your system's continued health.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 CTM facility. Unless
you have a good TCP/IP connection at a flat rate, this is
the way to do it.Use the cvsup program with
this
supfile. This is the second most recommended
method, since it allows you to grab the entire collection
once and then only what has changed from then on. Many people
run cvsup from cron and keep their sources up-to-date
automatically. For a fairly easy interface to this, simply
type:
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/lexYou can do:
ftp>cd usr.binftp>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 make world the first time
through as part of the upgrading process. Reading the &a.current;
will keep you up-to-date on other bootstrapping procedures that
sometimes become necessary as we move towards the next
release.Be active! If you are running 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 FreeBSD-current).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-stableJoin 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.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-stable
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.If you are installing a new system and want it to be as stable
as possible, you can simply grab the latest dated branch snapshot
from ftp://releng3.FreeBSD.org/pub/FreeBSD/
and install it like any other release.If you are already running a previous release of 2.2 and wish
to upgrade via sources then you can easily do so from ftp.FreeBSD.org. This can be done in one
of three ways:Use the CTM facility. Unless
you have a good TCP/IP connection at a flat rate, this is
the way to do it.Use the cvsup program with
this
supfile. This is the second most recommended
method, since it allows you to grab the entire collection
once and then only what has changed from then on. Many people
run cvsup from cron to keep their sources up-to-date
automatically. For a fairly easy interface to this, simply
type;
The FreeBSD mirror
sites database is more accurate than the mirror listing in the
handbook, as it gets its information form the DNS rather than relying on
static lists of hosts.Additionally, FreeBSD is available via anonymous FTP from the
following mirror sites. If you choose to obtain FreeBSD via anonymous
FTP, please try to use a site near you.Argentina,
Australia,
Brazil,
Canada,
China,
Czech Republic,
Denmark,
Estonia,
Finland,
France,
Germany,
Hong Kong,
Ireland,
Israel,
Japan,
Korea,
Netherlands,
New Zealand,
Poland,
Portugal,
Russia,
Saudi Arabia,
South Africa,
Spain,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
UK,
Ukraine,
USA.ArgentinaIn case of problems, please contact the hostmaster
hostmaster@ar.FreeBSD.org for this domain.ftp://ftp.ar.FreeBSD.org/pub/FreeBSDAustraliaIn case of problems, please contact the hostmaster
hostmaster@au.FreeBSD.org 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
hostmaster@br.FreeBSD.org 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
hostmaster@ca.FreeBSD.org for this domain.ftp://ftp.ca.FreeBSD.org/pub/FreeBSDChinaIn case of problems, please contact the hostmaster
phj@cn.FreeBSD.org for this domain.ftp://ftp.cn.FreeBSD.org/pub/FreeBSDCzech RepublicIn case of problems, please contact the hostmaster
hostmaster@cz.FreeBSD.org for this domain.ftp://ftp.cz.FreeBSD.org Contact: calda@dzungle.ms.mff.cuni.czftp://sunsite.mff.cuni.cz/OS/FreeBSD Contact: jj@sunsite.mff.cuni.cz.DenmarkIn case of problems, please contact the hostmaster
hostmaster@dk.FreeBSD.org for this domain.ftp://ftp.dk.freeBSD.ORG/pub/FreeBSDEstoniaIn case of problems, please contact the hostmaster
hostmaster@ee.FreeBSD.org for this domain.ftp://ftp.ee.FreeBSD.org/pub/FreeBSDFinlandIn case of problems, please contact the hostmaster
hostmaster@fi.FreeBSD.org for this domain.ftp://ftp.fi.FreeBSD.org/pub/FreeBSDFranceIn case of problems, please contact the hostmaster
hostmaster@fr.FreeBSD.org for this domain.ftp://ftp.fr.FreeBSD.org/pub/FreeBSDftp://ftp2.fr.FreeBSD.org/pub/FreeBSDftp://ftp3.fr.FreeBSD.org/pub/FreeBSDGermanyIn case of problems, please contact the hostmaster
hostmaster@de.FreeBSD.org 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
hostmaster@ie.FreeBSD.org for this domain.ftp://ftp.ie.FreeBSD.org/pub/FreeBSDIsraelIn case of problems, please contact the hostmaster
hostmaster@il.FreeBSD.org for this domain.ftp://ftp.il.FreeBSD.org/pub/FreeBSDftp://ftp2.il.FreeBSD.org/pub/FreeBSDJapanIn case of problems, please contact the hostmaster
hostmaster@jp.FreeBSD.org 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
hostmaster@kr.FreeBSD.org for this domain.ftp://ftp.kr.FreeBSD.org/pub/FreeBSDftp://ftp2.kr.FreeBSD.org/pub/FreeBSDftp://ftp3.kr.FreeBSD.org/pub/FreeBSDftp://ftp4.kr.FreeBSD.org/pub/FreeBSDftp://ftp5.kr.FreeBSD.org/pub/FreeBSDftp://ftp6.kr.FreeBSD.org/pub/FreeBSDNetherlandsIn case of problems, please contact the hostmaster
hostmaster@nl.FreeBSD.org for this domain.ftp://ftp.nl.FreeBSD.org/pub/FreeBSDNew ZealandIn case of problems, please contact the hostmaster
hostmaster@nz.FreeBSD.org for this domain.ftp://ftp.nz.FreeBSD.org/pub/FreeBSDPolandIn case of problems, please contact the hostmaster
hostmaster@pl.FreeBSD.org for this domain.ftp://ftp.pl.FreeBSD.org/pub/FreeBSDPortugalIn case of problems, please contact the hostmaster
hostmaster@pt.FreeBSD.org for this domain.ftp://ftp.pt.FreeBSD.org/pub/FreeBSDftp://ftp2.pt.FreeBSD.org/pub/FreeBSDRussiaIn case of problems, please contact the hostmaster
hostmaster@ru.FreeBSD.org for this domain.ftp://ftp.ru.FreeBSD.org/pub/FreeBSDftp://ftp2.ru.FreeBSD.org/pub/FreeBSDftp://ftp3.ru.FreeBSD.org/pub/FreeBSDftp://ftp4.ru.FreeBSD.org/pub/FreeBSDSaudi ArabiaIn case of problems, please contact
ftpadmin@isu.net.saftp://ftp.isu.net.sa/pub/mirrors/ftp.freebsd.orgSouth AfricaIn case of problems, please contact the hostmaster
hostmaster@za.FreeBSD.org for this domain.ftp://ftp.za.FreeBSD.org/pub/FreeBSDftp://ftp2.za.FreeBSD.org/pub/FreeBSDftp://ftp3.za.FreeBSD.org/pub/FreeBSDSlovak RepublicIn case of problems, please contact the hostmaster
hostmaster@sk.FreeBSD.org for this domain.ftp://ftp.sk.FreeBSD.org/pub/FreeBSDSloveniaIn case of problems, please contact the hostmaster
hostmaster@si.FreeBSD.org for this domain.ftp://ftp.si.FreeBSD.org/pub/FreeBSDSpainIn case of problems, please contact the hostmaster
hostmaster@es.FreeBSD.org for this domain.ftp://ftp.es.FreeBSD.org/pub/FreeBSDSwedenIn case of problems, please contact the hostmaster
hostmaster@se.FreeBSD.org for this domain.ftp://ftp.se.FreeBSD.org/pub/FreeBSDftp://ftp2.se.FreeBSD.org/pub/FreeBSDftp://ftp3.se.FreeBSD.org/pub/FreeBSDTaiwanIn case of problems, please contact the hostmaster
hostmaster@tw.FreeBSD.org 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: freebsd-mnt@lucky.net.UKIn case of problems, please contact the hostmaster
hostmaster@uk.FreeBSD.org 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
hostmaster@FreeBSD.org 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 hostmaster@internat.FreeBSD.org for
this domain.ftp://ftp.internat.FreeBSD.org/pub/FreeBSDftp://ftp2.internat.FreeBSD.org/pub/FreeBSDBrazilHostmaster hostmaster@br.FreeBSD.org for this
domain.ftp://ftp.br.FreeBSD.org/pub/FreeBSDFinlandftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Contact: count@nic.funet.fi.CTM SitesCTM/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/development/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 SitesCVSup servers for FreeBSD are running
at the following sites:Argentinacvsup.ar.FreeBSD.org (maintainer
msagre@cactus.fi.uba.ar)Australiacvsup.au.FreeBSD.org (maintainer
dawes@physics.usyd.edu.au)Brazilcvsup.br.FreeBSD.org (maintainer
cvsup@cvsup.br.FreeBSD.org)cvsup2.br.FreeBSD.org (maintainer
tps@ti.sk)Canadacvsup.ca.FreeBSD.org (maintainer
dan@jaded.net)Chinacvsup.cn.FreeBSD.org (maintainer
phj@cn.FreeBSD.org)Czech Republiccvsup.cz.FreeBSD.org (maintainer
cejkar@dcse.fee.vutbr.cz)Denmarkcvsup.dk.FreeBSD.org (maintainer
jesper@skriver.dk)Estoniacvsup.ee.FreeBSD.org (maintainer
taavi@uninet.ee)Finlandcvsup.fi.FreeBSD.org (maintainer
count@key.sms.fi)cvsip2.fi.FreeBSD.org (maintainer
count@key.sms.fi)Francecvsup.fr.FreeBSD.org (maintainer
hostmaster@fr.FreeBSD.org)Germanycvsup.de.FreeBSD.org (maintainer
wosch@FreeBSD.org)cvsup2.de.FreeBSD.org (maintainer
petzi@FreeBSD.org)cvsup3.de.FreeBSD.org (maintainer
ag@leo.org)Icelandcvsup.is.FreeBSD.org (maintainer
adam@veda.is)Japancvsup.jp.FreeBSD.org (maintainer
simokawa@sat.t.u-tokyo.ac.jp)cvsup2.jp.FreeBSD.org (maintainer
max@FreeBSD.org)cvsup3.jp.FreeBSD.org (maintainer
shige@cin.nihon-u.ac.jp)cvsup4.jp.FreeBSD.org (maintainer
cvsup-admin@ftp.media.kyoto-u.ac.jp)cvsup5.jp.FreeBSD.org (maintainer
cvsup@imasy.or.jp)Koreacvsup.kr.FreeBSD.org (maintainer
cjh@kr.FreeBSD.org)Netherlandscvsup.nl.FreeBSD.org (maintainer
xaa@xaa.iae.nl)Norwaycvsup.no.FreeBSD.org (maintainer
Tor.Egge@idt.ntnu.no)Polandcvsup.pl.FreeBSD.org (maintainer
Mariusz@kam.pl)Russiacvsup.ru.FreeBSD.org (maintainer
mishania@demos.su)cvsup2.ru.FreeBSD.org (maintainer
dv@dv.ru)Spaincvsup.es.FreeBSD.org (maintainer
jesusr@FreeBSD.org)Swedencvsup.se.FreeBSD.org (maintainer
pantzer@ludd.luth.se)Slovak Republiccvsup.sk.FreeBSD.org (maintainer
tps@tps.sk)cvsup2.sk.FreeBSD.org (maintainer
tps@tps.sk)South Africacvsup.za.FreeBSD.org (maintainer
markm@FreeBSD.org)cvsup2.za.FreeBSD.org (maintainer
markm@FreeBSD.org)Taiwancvsup.tw.FreeBSD.org (maintainer
jdli@freebsd.csie.nctu.edu.tw)Ukrainecvsup2.ua.FreeBSD.org (maintainer
freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.org (maintainer
joe@pavilion.net)cvsup2.uk.FreeBSD.org (maintainer
brian@FreeBSD.org)USAcvsup1.FreeBSD.org (maintainer
skynyrd@opus.cts.cwu.edu), Washington
statecvsup2.FreeBSD.org (maintainer
jdp@FreeBSD.org), Californiacvsup3.FreeBSD.org (maintainer
wollman@FreeBSD.org), Massachusettscvsup5.FreeBSD.org (maintainer
ck@adsu.bellsouth.com), Georgiacvsup6.FreeBSD.org (maintainer
jdp@FreeBSD.org), FloridaThe 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
markm@FreeBSD.org)The following CVSup site is especially
designed for CTM users. Unlike the other
CVSup mirrors, it is kept up-to-date by CTM.
That means if you CVSupcvs-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 CTMcvs-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
blank@fox.uni-trier.de)AFS SitesAFS servers for FreeBSD are running at the following sites;SwedenThe path to the files are:
/afs/stacken.kth.se/ftp/pub/FreeBSD
stacken.kth.se # Stacken Computer Club, KTH, Sweden
130.237.234.43 #hot.stacken.kth.se
130.237.237.230 #fishburger.stacken.kth.se
130.237.234.3 #milko.stacken.kth.seMaintainer ftp@stacken.kth.se
diff --git a/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml b/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
index 53e2f8a6d6..2ce4e58551 100644
--- a/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml
@@ -1,624 +1,624 @@
PGP keysIn 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>
f16 Fingerprint16 = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0i for non-commercial use
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNbtI
gAHbXdKX5jjdAQHamQP+OQr10QRknamIPmuHmFYJZ0jU9XPIvTTMuOiUYLcXlTdn
GyTUuzhbEywgtOldW2V5iA8platXThtqC68NsnN/xQfHA5xmFXVbayNKn8H5stDY
2s/4+CZ06mmJfqYmONF1RCbUk/M84rVT3Gn2tydsxFh4Pm32lf4WREZWRiLqmw+J
AJUDBRA0DfF99RVb+45ULV0BAcZ0BACCydiSUG1VR0a5DBcHdtin2iZMPsJUPRqJ
tWvP6VeI8OFpNWQ4LW6ETAvn35HxV2kCcQMyht1kMD+KEJz7r8Vb94TS7KtZnNvk
2D1XUx8Locj6xel5c/Lnzlnnp7Bp1XbJj2u/NzCaZQ0eYBdP/k7RLYBYHQQln5x7
BOuiRJNVU4kAlQMFEDQLcShVLh4uc9KIpQEBJv4D/3mDrD0MM9EYOVuyXik3UGVI
8quYNA9ErVcLdt10NjYc16VI2HOnYVgPRag3Wt7W8wlXShpokfC/vCNt7f5JgRf8
h2a1/MjQxtlD+4/Js8k7GLa53oLon6YQYk32IEKexoLPwIRO4L2BHWa3GzHJJSP2
aTR/Ep90/pLdAOu/oJDUiQCVAwUQMqyL0LNaYutZnzI9AQF25QP9GFXhBrz2tiWz
2+0gWbpcGNnyZbfsVjF6ojGDdmsjJMyWCGw49XR/vPKYIJY9EYo4t49GIajRkISQ
NNiIz22fBAjT2uY9YlvnTJ9NJleMfHr4dybo7oEKYMWWijQzGjqf2m8wf9OaaofE
KwBX6nxcRbKsxm/BVLKczGYl3XtjkcuJAJUDBRA1ol5TZWCprDT5+dUBATzXA/9h
/ZUuhoRKTWViaistGJfWi26FB/Km5nDQBr/Erw3XksQCMwTLyEugg6dahQ1u9Y5E
5tKPxbB69eF+7JXVHE/z3zizR6VL3sdRx74TPacPsdhZRjChEQc0htLLYAPkJrFP
VAzAlSlm7qd+MXf8fJovQs6xPtZJXukQukPNlhqZ94kAPwMFEDSH/kF4tXKgazlt
bxECfk4AoO+VaFVfguUkWX10pPSSfvPyPKqiAJ4xn8RSIe1ttmnqkkDMhLh00mKj
lLQuSm9uYXRoYW4gTS4gQnJlc2xlciA8Sm9uYXRoYW4uQnJlc2xlckBVU2kubmV0
PokAlQMFEDXbdSkB213Sl+Y43QEBV/4D/RLJNTrtAqJ1ATxXWv9g8Cr3/YF0GTmx
5dIrJOpBup7eSSmiM/BL9Is4YMsoVbXCI/8TqA67TMICvq35PZU4wboQB8DqBAr+
gQ8578M7Ekw1OAF6JXY6AF2P8k7hMcVBcVOACELPT/NyPNByG5QRDoNmlsokJaWU
/2ls4QSBZZlb
=zbCw
-----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.3ia
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokBFQMFEDXCTXQM
j46yp4IfPQEBwO8IAIN0J09AXBf86dFUTFGcAMrEQqOF5IL+KGorAjzuYxERhKfD
ZV7jA+sCQqxkWfcVcE20kVyVYqzZIkio9a5zXP6TwA247JkPt54S1PmMDYHNlRIY
laXlNoji+4q3HP2DfHqXRT2859rYpm/fG/v6pWkos5voPKcZ2OFEp9W+Ap88oqw+
5rx4VetZNJq1Epmis4INj6XqNqj85+MOOIYE+f445ohDM6B/Mxazd6cHFGGIR+az
VjZ6lCDMLjzhB5+FqfrDLYuMjqkMTR5z9DL+psUvPlCkYbQ11NEWtEmiIWjUcNJN
GCxGzv5bXk0XPu3ADwbPkFE2usW1cSM7AQFiwuyJAJUDBRAxe+Q9a1pnjYGyp3kB
AV7XA/oCSL/Cc2USpQ2ckwkGpyvIkYBPszIcabSNJAzm2hsU9Qa6WOPxD8olDddB
uJNiW/gznPC4NsQ0N8Zr4IqRX/TTDVf04WhLmd8AN9SOrVv2q0BKgU6fLuk979tJ
utrewH6PR2qBOjAaR0FJNk4pcYAHeT+e7KaKy96YFvWKIyDvc4kAlQMFEDF8ldof
f6kIA1j8vQEBDH4D/0Zm0oNlpXrAE1EOFrmp43HURHbij8n0Gra1w9sbfo4PV+/H
U8ojTdWLy6r0+prH7NODCkgtIQNpqLuqM8PF2pPtUJj9HwTmSqfaT/LMztfPA6PQ
csyT7xxdXl0+4xTDl1avGSJfYsI8XCAy85cTs+PQwuyzugE/iykJO1Bnj/paiQCV
AwUQMXvlBvUVW/uOVC1dAQF2fQP/RfYC6RrpFTZHjo2qsUHSRk0vmsYfwG5NHP5y
oQBMsaQJeSckN4n2JOgR4T75U4vS62aFxgPLJP3lOHkU2Vc7xhAuBvsbGr5RP8c5
LvPOeUEyz6ZArp1KUHrtcM2iK1FBOmY4dOYphWyWMkDgYExabqlrAq7FKZftpq/C
BiMRuaw=
=C/Jw
-----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
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDQQ0aZ1
u244dqP3sQEBu4ID/jXFFeJgs2MdTDNOZM/FbfDhI4qxAbYUsqS3+Ra16yd8Wd/A
jV+IHJE2NomFWl8UrUjCGinXiwzPgK1OfFJrS9Og1wQLvAl0X84BA8MTP9BQr4w7
6I/RbksgUSrVCIO8MJwlydjSPocWGBeXlVjbZxXzyuJk7H+TG+zuI5BuBcNIiQCV
AwUQMwYr2rNaYutZnzI9AQHiIQP/XxtBWFXaBRgVLEhRNpS07YdU+LsZGlLOZehN
9L4UnJFHQQPNOpMey2gF7Y95aBOw5/1xS5vlQpwmRFCntWsm/gqdzK6rulfr1r5A
y94LO5TAC6ucNu396Y4vo1TyD1STnRC466KlvmtQtAtFGgXlORWLL9URLzcRFd1h
D0yXd9aJAJUDBRAxfo19a1pnjYGyp3kBAQqyA/4v64vP3l1F0Sadn6ias761hkz/
SMdTuLzILmofSCC4o4KWMjiWJHs2Soo41QlZi1+xMHzV32JKiwFlGtPHqL+EHyXy
Q4H3vmf9/1KF+0XCaMtgI0wWUMziPSTJK8xXbRRmMDK/0F4TnVVaUhnmf+h5K7O6
XdmejDTa0X/NWcicmIkAlQMFEDF8lef1FVv7jlQtXQEBcnwD/0ro1PpUtlkLmreD
tsGTkNa7MFLegrYRvDDrHOwPZH152W2jPUncY+eArQJakeHiTDmJNpFagLZglhE0
bqJyca+UwCXX+6upAclWHEBMg2byiWMMqyPVEEnpUoHM1sIkgdNWlfQAmipRBfYh
2LyCgWvR8CbtwPYIFvUmGgB3MR87iQCVAwUQMUseXB9/qQgDWPy9AQGPkwP/WEDy
El2Gkvua9COtMAifot2vTwuvWWpNopIEx0Ivey4aVbRLD90gGCJw8OGDEtqFPcNV
8aIiy3fYVKXGZZjvCKd7zRfhNmQn0eLDcymq2OX3aPrMc2rRlkT4Jx425ukR1gsO
qiQAgw91aWhY8dlw/EKzk8ojm52x4VgXaBACMjaJAJUDBRAxOUOg72G56RHVjtUB
AbL4A/9HOn5Qa0lq9tKI/HkSdc5fGQD/66VdCBAb292RbB7CS/EM07MdbcqRRYIa
0+0gwQ3OdsWPdCVgH5RIhp/WiC+UPkR1cY8N9Mg2kTwJfZZfNqN+BgWlgRMPN27C
OhYNl8Q33Nl9CpBLrZWABF44jPeT0EvvTzP/5ZQ7T75EsYKYiYkAlQMFEDDmryQA
8tkJ67sbQQEBPdsEALCj6v1OBuJLLJTlxmmrkqAZPVzt5QdeO3Eqa2tcPWcU0nqP
vHYMzZcZ7oFg58NZsWrhSQQDIB5e+K65Q/h6dC7W/aDskZd64jxtEznX2kt0/MOr
8OdsDis1K2f9KQftrAx81KmVwW4Tqtzl7NWTDXt44fMOtibCwVq8v2DFkTJy
=JKbP
-----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-----Developers&a.wosch;
Type Bits/KeyID Date User ID
pub 1024/2B7181AD 1997/08/09 Wolfram Schneider <wosch@FreeBSD.org>
Key fingerprint = CA 16 91 D9 75 33 F1 07 1B F0 B4 9F 3E 95 B6 09
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzPs+aEAAAEEAJqqMm2I9CxWMuHDvuVO/uh0QT0az5ByOktwYLxGXQmqPG1G
Q3hVuHWYs5Vfm/ARU9CRcVHFyqGQ3LepoRhDHk+JcASHan7ptdFsz7xk1iNNEoe0
vE2rns38HIbiyQ/2OZd4XsyhFOFtExNoBuyDyNoe3HbHVBQT7TmN/mkrcYGtAAUR
tCVXb2xmcmFtIFNjaG5laWRlciA8d29zY2hARnJlZUJTRC5vcmc+iQCVAwUQNxnH
AzmN/mkrcYGtAQF5vgP/SLOiI4AwuPHGwUFkwWPRtRzYSySXqwaPCop5mVak27wk
pCxGdzoJO2UgcE812Jt92Qas91yTT0gsSvOVNATaf0TM3KnKg5ZXT1QIzYevWtuv
2ovAG4au3lwiFPDJstnNAPcgLF3OPni5RCUqBjpZFhb/8YDfWYsMcyn4IEaJKre0
JFdvbGZyYW0gU2NobmVpZGVyIDxzY2huZWlkZXJAemliLmRlPokAlQMFEDcZxu85
jf5pK3GBrQEBCRgD/jPj1Ogx4O769soiguL1XEHcxhqtrpKZkKwxmDLRa0kJFwLp
bBJ3Qz3vwaB7n5gQU0JiL1B2M7IxVeHbiIV5pKp7FD248sm+HZvBg6aSnCg2JPUh
sHd1tK5X4SB5cjFt3Cj0LIN9/c9EUxm3SoML9bovmze60DckErrRNOuTk1IntCJX
b2xmcmFtIFNjaG5laWRlciA8d29zY2hAYXBmZWwuZGU+iQEVAwUQNmfWXAjJLLJO
sC7dAQEASAgAnE4g2fwMmFkQy17ATivljEaDZN/m0GdXHctdZ8CaPrWk/9/PTNK+
U6xCewqIKVwtqxVBMU1VpXUhWXfANWCB7a07D+2GrlB9JwO5NMFJ6g0WI/GCUXjC
xb3NTkNsvppL8Rdgc8wc4f23GG4CXVggdTD2oUjUH5Bl7afgOT4xLPAqePhS7hFB
UnMsbA94OfxPtHe5oqyaXt6cXH/SgphRhzPPZq0yjg0Ef+zfHVamvZ6Xl2aLZmSv
Cc/rb0ShYDYi39ly9OPPiBPGbSVw2Gg804qx3XAKiTFkLsbYQnRt7WuCPsOVjFkf
CbQS31TaclOyzenZdCAezubGIcrJAKZjMIkAlQMFEDPs+aE5jf5pK3GBrQEBlIAD
/3CRq6P0m1fi9fbPxnptuipnoFB/m3yF6IdhM8kSe4XlXcm7tS60gxQKZgBO3bDA
5QANcHdl41Vg95yBAZepPie6iQeAAoylRrONeIy6XShjx3S0WKmA4+C8kBTL+vwa
UqF9YJ1qesZQtsXlkWp/Z7N12RkueVAVQ7wRPwfnz6E3tC5Xb2xmcmFtIFNjaG5l
aWRlciA8d29zY2hAcGFua2UuZGUuZnJlZWJzZC5vcmc+iQCVAwUQNxnEqTmN/mkr
cYGtAQFnpQP9EpRZdG6oYN7d5abvIMN82Z9x71a4QBER+R62mU47wqdRG2b6jMMh
3k07b2oiprVuPhRw/GEPPQevb6RRT6SD9CPYAGfK3MDE8ZkMj4d+7cZDRJQ35sxv
gAzQwuA9l7kS0mt5jFRPcEg5/KpuyehRLckjx8jpEM7cEJDHXhBIuVg=
=3V1R
-----END PGP PUBLIC KEY BLOCK-----&a.brian;
Type Bits/KeyID Date User ID
pub 1024/666A7421 1997/04/30 Brian Somers <brian@awfulhak.org>
Key fingerprint = 2D 91 BD C2 94 2C 46 8F 8F 09 C4 FC AD 12 3B 21
Brian Somers <brian@uk.FreeBSD.org>
Brian Somers <brian@OpenBSD.org>
Brian Somers <brian@FreeBSD.org>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzNmogUAAAEEALdsjVsV2dzO8UU4EEo7z3nYuvB2Q6YJ8sBUYjB8/vfR5oZ9
7aEQjgY5//pXvS30rHUB9ghk4kIFSljzeMudE0K2zH5n2sxpLbBKWZRDLS7xnrDC
I3j9CNKwQBzMPs0fUT46gp96nf1X8wPiJXkDUEia/c0bRbXlLw7tvOdmanQhAAUR
tCFCcmlhbiBTb21lcnMgPGJyaWFuQGF3ZnVsaGFrLm9yZz6JAJUDBRA3Fjs4H3+p
CANY/L0BAZOxBACTZ1zPdaJzEdT4AfrebQbaU4ytEeodnVXZIkc8Il+LDlDOUAIe
k5PgnHTRM4yiwcZuYQrCDRFgdOofcFfRo0PD7mGFzd22qPGmbvHiDBCYCyhlkPXW
IDeoA1cX77JlU1NFdy0dZwuX7csaMlpjCkOPc7+856mr6pQi48zj7yZtrYkAlQMF
EDcUqZ2dZ0EADG4SFQEBEm0EAL2bBNc4vpxPrg3ATdZ/PekpL6lYj3s9pBf8f7eY
LXq438A/ywiWkrL74gXxcZ2Ey9AHZW+rbJPzUbrfMAgP3uWobeSvDyKRo1wtKnTY
Hy+OEIbBIHDmIUuK3L7KupBf7WAI46Q7fnyz0txvtRruDjvfoyl9/TSRfIKcaw2a
INh7iQCVAwUQNwyWpmdKPfFUsXG5AQEIrAQAmukv2u9ihcnO2Zaak265I+gYozu+
biAngdXNfhTGMeExFzdzQ8Qe7EJugMpIDEkJq2goY35sGitD+ogSVWECjcVbHIAP
M2u9axFGlK7fDOmmkH2ZWDMtwx2I5dZps3q2g9mY2O9Az5Yokp7GW7viSpWXHTRH
xOsuY6aze71U7RWJAHUDBRA3DAEvDuwDH3697LEBAWRHAv9XXkub6mir/DCxzKI2
AE3tek40lRfU6Iukjl/uzT9GXcL3uEjIewiPTwN+k4IL+qcCEdv8WZgv/tO45r59
IZQsicNaSAsKX/6Cxha6Hosg1jw4rjdyz13rgYRi/nreq5mJAJUDBRA2r0CM9p+f
Pnxlu7UBAYObA/40s5SwEpXTrePO78AoUFEa5Z4bgyxkpT7BVbq6m/oQtK509Xe2
M2y0XTLkd86oXpjyKzGzWq8T6ZTKNdF9+5LhS2ylJytdPq1AjDk2BocffWX4+pXn
RPiC6XcNdYGiQL8OTHvZESYQDiHeMfwA8WdMzFK1R80nJMwANYXjJJrLzYkAlQMF
EDNt51zvs7EFZlNtbQEBW0UD/jZB6UDdEFdhS0hxgahv5CxaQDWQbIEpAY9JL1yg
d1RWMKUFGXdRkWZmHEA4NvtwFFeam/HZm4yuGf8yldMyo84loTcVib7lKh4CumGx
FT5Pxeh/F8u9EeQzclRFSMhVl0BA2/HEGyjw0kbkprI/RD3pXD7ewTAUrj2O3XhE
InLgiQCVAwUQM3O9vWyr6JZzEUkFAQF9nAP9Hco0V/3Kl70N5ryPVgh41nUTd7Td
6fUjx8yPoSZLX8vVZ8XMyd8ULFmzsmA+2QG4HcKo/x/4s50O3o8c+o1qSYj0Tp+K
4Z8lneMVlgBNdrRcq4ijEgk0qGqSlsXyLElkVPEXAADBVgzf6yqvipDwXNVzl6e3
GPLE8U2TAnBFZX6JAJUDBRAzZqIFDu2852ZqdCEBATsuBACI3ofP7N3xuHSc7pWL
NsnFYVEc9utBaclcagxjLLzwPKzMBcLjNGyGXIZQNB0d4//UMUJcMS7vwZ8MIton
VubbnJVHuQvENloRRARtarF+LC7OLMCORrGtbt0FtYgvBaqtgXlNcKXD6hRT+ghR
bi3q34akA7Xw8tiFIxdVgSusALQjQnJpYW4gU29tZXJzIDxicmlhbkB1ay5GcmVl
QlNELm9yZz6JAJUDBRA3FLWcnWdBAAxuEhUBAcYYBACos9nKETuaH+z2h0Ws+IIY
mN9FEm8wpPUcQmX5GFhfBUQ+rJbflzv0jJ/f2ac9qJHgIIAlJ3pMkfMpU8UYHEuo
VCe4ZTU5sr4ZdBaF9kpm2OriFgZwIv4QAi7dCMu9ZwGRtZ3+z3DQsVSagucjZTIe
yTUR6K+7E3YXANQjOdqFZYkAlQMFEDcUpeQO7bznZmp0IQEB4HED/Ru3NjwWO1gl
xEiLTzRpU31Rh1Izw1lhVMVJkLAGBw9ieSkjvdIkuhqV1i+W4wKBClT0UOE28Kjp
WbBKPFIASRYzN4ySwpprsG5H45EFQosovYG/HPcMzXU2GMj0iwVTxnMq7I8oH588
ExHqfEN2ARD3ngmB2499ruyGl26pW/BftCBCcmlhbiBTb21lcnMgPGJyaWFuQE9w
ZW5CU0Qub3JnPokAlQMFEDcUtW6dZ0EADG4SFQEBQwsD/j9B/lkltIdnQdjOqR/b
dOBgJCtUf905y6kD+k4kbxeT1YAaA65KJ2o/Zj+i+69F2+BUJ/3kYB7prKwut2h0
ek1ZtncGxoAsQdFJ5JSeMkwUZ5qtGeCmVPb59+KPq3nU6p3RI8Bn77FzK//Qy+IW
/WFVJbf/6NCNCbyRiRjPbGl/iQCVAwUQNxSlyA7tvOdmanQhAQFzMAP/dvtsj3yB
C+seiy6fB/nS+NnKBoff3Ekv57FsZraGt4z9n4sW61eywaiRzuKlhHqrDE17STKa
fBOaV1Ntl7js7og5IFPWNlVh1cK+spDmd655D8pyshziDF6fSAsqGfTn35xl23Xj
O20MMK44j4I5V6rEyUDBDrmX49J56OFkfwa0IEJyaWFuIFNvbWVycyA8YnJpYW5A
RnJlZUJTRC5vcmc+iQCVAwUQNxS1Y51nQQAMbhIVAQHPBQP+IMUlE4DtEvSZFtG4
YK9usfHSkStIafh/F/JzSsqdceLZgwcuifbemw79Rhvqhp0Cyp7kuI2kHO3a19kZ
3ZXlDl3VDg41SV/Z5LzNw9vaZKuF/vtGaktOjac5E5aznWGIA5czwsRgydEOcd8O
VPMUMrdNWRI6XROtnbZaRSwmD8aJAJUDBRA3FKWuDu2852ZqdCEBAWVJA/4x3Mje
QKV+KQoO6mOyoIcD4GK1DjWDvNHGujJbFGBmARjr/PCm2cq42cPzBxnfRhCfyEvN
aesNB0NjLjRU/m7ziyVn92flAzHqqmU36aEdqooXUY2T3vOYzo+bM7VtInarG1iU
qw1G19GgXUwUkPvy9+dNIM/aYoI/e0Iv3P9uug==
=R3k0
-----END PGP PUBLIC KEY BLOCK-----
diff --git a/en_US.ISO8859-1/books/handbook/policies/chapter.sgml b/en_US.ISO8859-1/books/handbook/policies/chapter.sgml
index 83cf490b8a..78c96d8a32 100644
--- a/en_US.ISO8859-1/books/handbook/policies/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/policies/chapter.sgml
@@ -1,391 +1,391 @@
Source Tree Guidelines and PoliciesContributed by &a.phk;.This chapter documents various guidelines and policies in force for
the FreeBSD source tree.MAINTAINER on MakefilesJune 1996.If a particular portion of the FreeBSD distribution is being
maintained by a person or group of persons, they can communicate this
fact to the world by adding a
MAINTAINER= email-addresses
line to the Makefiles covering this portion of the
source tree.The semantics of this are as follows:The maintainer owns and is responsible for that code. This means
that he is responsible for fixing bugs and answer problem reports
pertaining to that piece of the code, and in the case of contributed
software, for tracking new versions, as appropriate.Changes to directories which have a maintainer defined shall be sent
to the maintainer for review before being committed. Only if the
maintainer does not respond for an unacceptable period of time, to
several emails, will it be acceptable to commit changes without review
by the maintainer. However, it is suggested that you try and have the
changes reviewed by someone else if at all possible.It is of course not acceptable to add a person or group as
maintainer unless they agree to assume this duty. On the other hand it
doesn't have to be a committer and it can easily be a group of
people.Contributed SoftwareContributed by &a.phk; and &a.obrien;. June 1996.Some parts of the FreeBSD distribution consist of software that is
actively being maintained outside the FreeBSD project. For historical
reasons, we call this contributed software. Some
examples are perl, gcc and patch.Over the last couple of years, various methods have been used in
dealing with this type of software and all have some number of
advantages and drawbacks. No clear winner has emerged.Since this is the case, after some debate one of these methods has
been selected as the “official” method and will be required
for future imports of software of this kind. Furthermore, it is
strongly suggested that existing contributed software converge on this
model over time, as it has significant advantages over the old method,
including the ability to easily obtain diffs relative to the
“official” versions of the source by everyone (even without
cvs access). This will make it significantly easier to return changes
to the primary developers of the contributed software.Ultimately, however, it comes down to the people actually doing the
work. If using this model is particularly unsuited to the package being
dealt with, exceptions to these rules may be granted only with the
approval of the core team and with the general consensus of the other
developers. The ability to maintain the package in the future will be a
key issue in the decisions.Because of some unfortunate design limitations with the RCS file
format and CVS's use of vendor branches, minor, trivial and/or
cosmetic changes are strongly discouraged on
files that are still tracking the vendor branch. “Spelling
fixes” are explicitly included here under the
“cosmetic” category and are to be avoided for files with
revision 1.1.x.x. The repository bloat impact from a single character
change can be rather dramatic.The Tcl embedded programming
language will be used as example of how this model works:src/contrib/tcl contains the source as
distributed by the maintainers of this package. Parts that are entirely
not applicable for FreeBSD can be removed. In the case of Tcl, the
mac, win and
compat subdirectories were eliminated before the
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 and without RCS keyword expansion) with as few
FreeBSD-specific changes as possible. The 'easy-import' tool on
freefall will assist in doing the import, but if there are any doubts on
how to go about it, it is imperative that you ask first and not blunder
ahead and hope it “works out”. CVS is not forgiving of
import accidents and a fair amount of effort is required to back out
major mistakes.Because of the previously mentioned design limitations with CVS's
vendor branches, it is required that “official” patches from
the vendor be applied to the original distributed sources and the result
re-imported onto the vendor branch again. Official patches should never
be patched into the FreeBSD checked out version and "committed", as this
destroys the vendor branch coherency and makes importing future versions
rather difficult as there will be conflicts.Since many packages contain files that are meant for compatibility
with other architectures and environments that FreeBSD, it is
permissible to remove parts of the distribution tree that are of no
interest to FreeBSD in order to save space. Files containing copyright
notices and release-note kind of information applicable to the remaining
files shall not be removed.If it seems easier, the 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 outWhere the original distribution was obtained from and/or the
official master site.Where to send patches back to the original authorsPerhaps an overview of the FreeBSD-specific changes that have
been made.However, please do not import FREEBSD-upgrade
with the contributed source. Rather you should cvs add
FREEBSD-upgrade ; cvs ci after the initial import. Example
wording from src/contrib/cpio is below:
This directory contains virgin sources of the original distribution files
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
the files in this directory via patches and a cvs commit. New versions or
official-patch versions must be imported. Please remember to import with
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
For the import of GNU cpio 2.4.2, the following files were removed:
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
To upgrade to a newer version of cpio, when it is available:
1. Unpack the new version into an empty directory.
[Do not make ANY changes to the files.]
2. Remove the files listed above and any others that don't apply to
FreeBSD.
3. Use the command:
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
For example, to do the import of version 2.4.2, I typed:
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Follow the instructions printed out in step 3 to resolve any
conflicts between local FreeBSD changes and the newer version.
Do not, under any circumstances, deviate from this procedure.
To make local changes to cpio, simply patch and commit to the main
branch (aka HEAD). Never make local changes on the GNU branch.
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
inclusion in the next vendor release.
obrien@FreeBSD.org - 30 March 1997Encumbered filesIt might occasionally be necessary to include an encumbered file in
the FreeBSD source tree. For example, if a device requires a small
piece of binary code to be loaded to it before the device will operate,
and we do not have the source to that code, then the binary file is said
to be encumbered. The following policies apply to including encumbered
files in the FreeBSD source tree.Any file which is interpreted or executed by the system CPU(s)
and not in source format is encumbered.Any file with a license more restrictive than BSD or GNU is
encumbered.A file which contains downloadable binary data for use by the
hardware is not encumbered, unless (1) or (2) apply to it. It must
be stored in an architecture neutral ASCII format (file2c or
uuencoding is recommended).Any encumbered file requires specific approval from the Core team before it is added to the
CVS repository.Encumbered files go in src/contrib or
src/sys/contrib.The entire module should be kept together. There is no point in
splitting it, unless there is code-sharing with non-encumbered
code.Object files are named
arch/filename.o.uu>.Kernel files;Should always be referenced in
conf/files.* (for build simplicity).Should always be in LINT, but the Core team decides per case if it
should be commented out or not. The Core team can, of course, change
their minds later on.The Release Engineer
decides whether or not it goes in to the release.User-land files;The Core team decides if
the code should be part of make world.The Release Engineer
decides if it goes in to the release.Shared LibrariesContributed 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.
diff --git a/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml b/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml
index 1a3c352e3a..abb5058d42 100644
--- a/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml
@@ -1,2488 +1,2488 @@
PPP and SLIPIf your connection to the Internet is through a modem, or you wish to
provide other people with dialup connections to the Internet using
FreeBSD, you have the option of using PPP or SLIP. Furthermore, two
varieties of PPP are provided: user (sometimes
referred to as iijppp) and
kernel. The procedures for configuring both types of
PPP, and for setting up SLIP are described in this chapter.Setting up User PPPUser PPP was introduced to FreeBSD in release 2.0.5 as an addition
to the existing kernel implementation of PPP. So, what is different
about this new PPP that warrants its addition? To quote from the manual
page:
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.There are a large number of enhancements in version 2 of ppp. You
can discover what version you have by running ppp with no arguments and
typing show version at the prompt. It is a simple
matter to upgrade to the latest version of ppp (under any version of
FreeBSD) by downloading the latest archive via www.Awfulhak.org.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 addresses of one or more nameservers. Normally, you
will be given two IP numbers. You must have
this information for PPP version 1.x
unless you run your own nameserver. From version 2 onwards,
PPP supports nameserver address
negotiation. If your ISP supports this, then using the command
enable dns in your config file will tell
PPP to set the nameservers for
you.The following information may have been supplied by your ISP, but
is not strictly necessary:The IP address of your ISP's gateway. The gateway is the
machine to which you will connect and will be set up as your
default route. If your ISP hasn't given you
this number, we can make one up and your ISP's PPP server will
tell us the correct value when we connect.This IP number is referred to as HISADDR
by ppp.Your ISP's netmask. If your ISP hasn't given you this
information, you can safely use a netmask of 255.255.255.0.If your ISP allocates you a static IP address and hostname
then you can enter this information. Otherwise, we simply let the
peer assign whatever IP number it sees fit.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 1
in 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 Configuring the FreeBSD Kernel section
for more information on kernel configuration.You can check how many tunnel devices your current kernel has by
typing the following:&prompt.root; ifconfig -a
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff
tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff
tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500This case shows four tunnel devices, two of which are currently
configured and being used. It should be noted that the
RUNNING flag above indicates that the interface has
been used at some point—it is not an error if your interface
does not show up as RUNNING.If 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
&man.modload.8; and &man.lkm.4; pages for further details.You may also wish to take this opportunity to configure a
firewall. Details can be found in the Firewalls 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:&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tun0If you require 16 tunnel devices in your kernel, you will need to
create more than just tun0:&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tun15Also, to confirm that the kernel is configured correctly, the
following command should give the indicated output:&prompt.root; ifconfig tun0
tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500The RUNNING flag may not yet be set, in which
case you will see:&prompt.root; ifconfig tun0
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500Name 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 (in this
order):
hosts
bindThese 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 /etc/hosts(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 /etc/resolv.conf 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.If you are running PPP version 2 or greater, the enable
dns command will tell PPP to request that your ISP
confirms the nameserver values. If your ISP supplies different
addresses (or if there are no nameserver lines in
/etc/resolv.conf), PPP will rewrite the file
with the ISP-supplied values.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 addressesYou will need to create a configuration file called
/etc/ppp/ppp.conf. It should look similar to
the example below.Lines that end in a : start in the first
column, all other lines should be indented as shown using spaces
or tabs.
1 default:
2 set device /dev/cuaa0
3 set speed 115200
4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT"
5 provider:
6 set phone "(0123) 456 7890"
7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp"
8 set timeout 300
9 set ifaddr x.x.x.xy.y.y.y 255.255.255.0 0.0.0.0
10 add default HISADDR
11 enable dnsDo 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 &man.chat.8; program. Refer to the
manual page for information on the features of this
language.Line 5:Identifies an entry for a provider called
“provider”.Line 6:Sets the phone number for this provider. Multiple phone
numbers may be specified using the : or
| character as a separator. The difference
between these separators is described in &man.ppp.8;.
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.
When you write this script for the first time, you should
enable “chat” logging to ensure that the
conversation is going as expected.If you're using PAP or CHAP, there will be no login at
this point, so your login string can be left blank. See PAP and CHAP
authentication for further details.Line 8: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:Sets the interface addresses. The string
x.x.x.x should be replaced by the
IP address that your provider has allocated to you. The
string y.y.y.y should be replaced
by the IP address that your ISP indicated for their gateway
(the machine to which you connect). If your ISP hasn't given
you a gateway address, use 10.0.0.2/0. If you need to use a
“guessed” address, make sure that you create an
entry in /etc/ppp/ppp.linkup as per the
instructions for PPP and
Dynamic IP addresses. If this line is omitted,
ppp cannot run in or
mode.Line 10:Adds a default route to your 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.Line 11:This line tells PPP to ask your ISP to confirm that your
nameserver addresses are correct. If your ISP supports this
facility, PPP can then update
/etc/resolv.conf with the correct
nameserver entries.It is not necessary to add an entry to
ppp.linkup when you have a static IP address as
your routing table entries are already correct before you connect.
You may however wish to create an entry to invoke programs after
connection. This is explained later with the sendmail
example.Example configuration files can be found in the
/etc/ppp directory.PPP and Dynamic IP addressesIf 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 PPP and Static IP addresses,
with the following change:
9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0Again, do not include the line numbers, they are just for
reference in this discussion. Indentation of at least one space is
required.Line 9:The number after the / character is the
number of bits of the address that ppp will insist on. You
may wish to use IP numbers more appropriate to your
circumstances, but the above example will always work.The last argument (0.0.0.0) tells PPP
to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use
0.0.0.0 as the first argument to
set ifaddr as it prevents PPP from setting
up an initial route in mode.If you are running version 1.x of PPP, you will also need to
create an entry in /etc/ppp/ppp.linkup.
ppp.linkup is used after a connection has been
established. At this point, ppp will know what
IP addresses should really be used. The
following entry will delete the existing bogus routes, and create
correct ones:
1 provider:
2 delete ALL
3 add 0 0 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.Version 2 of PPP introduces “sticky routes”. Any
add or delete lines that
contain MYADDR or HISADDR will
be remembered, and any time the actual values of
MYADDR or HISADDR change, the
routes will be re-applied. This removes the necessity of repeating
these lines in ppp.linkup.Receiving incoming calls with pppThis section describes setting up ppp in a
server role.When you configure ppp to receive incoming
calls on a machine connected to a LAN, you must decide if you wish
to forward packets to the LAN. If you do, you should allocate the
peer an IP number from your LAN's subnet, and use the command
enable proxy
in your ppp.conf file. You should also confirm
that the /etc/rc.conf file (this file used to
be called /etc/sysconfig) contains the
following:
gateway=YESWhich getty?Configuring FreeBSD for Dialup
Services 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 Mgetty and
AutoPPP 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.You will also need to give them access to one or more sections
of the configuration file using the allow
command:
allow users fred maryIf this command is used in the default
section, it gives the specified users access to everything.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:&prompt.root; ln -s 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 .rhosts
which 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:&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred
&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam
&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-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 proxyThe indenting is important.The default: section is loaded for each
session. For each dialup line enabled in
/etc/ttys create an entry similar to the one
for ttyd0: above. Each line should get a
unique IP address from your pool of IP addresses for dynamic
users.Setting up 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 AutoPPPConfiguring 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
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.
pap:
enable pap
set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40
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/password file.If you wish to assign some users a static IP number, you can
specify the number as the third argument in
/etc/ppp/ppp.secret. See
/etc/ppp/ppp.secret.sample for
examples.MS extensionsIt is possible to configure PPP to supply DNS and NetBIOS
nameserver addresses on demand.To enable these extensions with PPP version 1.x, the
following lines might be added to the relevant section of
/etc/ppp/ppp.conf.
enable msext
set ns 203.14.100.1 203.14.100.2
set nbns 203.14.100.5And for PPP version 2 and above:
accept dns
set dns 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.In version 2 and above, if the set dns
line is omitted, PPP will use the values found in
/etc/resolv.conf.PAP and CHAP authenticationSome ISPs set their system up so that the authentication part of
your connection is done using either of the PAP or CHAP
authentication mechanisms. If this is the case, your ISP will not
give a login: prompt when you connect, but will
start talking PPP immediately.PAP is less secure than CHAP, but security is not normally an
issue here as passwords, although being sent as plain text with PAP,
are being transmitted down a serial line only. There's not much room
for crackers to “eavesdrop”.Referring back to the PPP and
Static IP addresses or PPP and Dynamic IP addresses
sections, the following alterations must be made:
7 set login
…
12 set authname MyUserName
13 set authkey 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 12:This line specifies your PAP/CHAP user name. You will
need to insert the correct value for
MyUserName.Line 13: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 both accepted by default.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
diagnostic port has been set up. To do this, add the following line
to your configuration:
set server /var/run/ppp-tun%d DiagnosticPassword 0177This will tell PPP to listen to the specified unix-domain
socket, asking clients for the specified password before allowing
access. The %d in the name is replaced with the
tun device number that is in use.Once a socket has been set up, the
&man.pppctl.8; program may be used in scripts that wish to
manipulate the running program.Final system configurationYou 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:&prompt.root; /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&prompt.root; 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&prompt.root; 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
&man.vipw.8; program).Create a profile in this users home directory that runs
ppp -direct direct-server or similar.Create an entry in /etc/ppp/ppp.conf.
The direct-server example should
suffice.Create an entry in
/etc/ppp/ppp.linkup.Update your /etc/rc.conf (or
sysconfig) file.AcknowledgmentsThis section of the handbook was last updated on Monday Aug 10,
1998 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:&prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty0119200Use 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 serve must supply your IP address.
# if the remote host doesn't send your IP during
# IPCP negotiation, remove this option
passive # wait for LCP packets
domain <your.domain> # put your domain name here
: # put the IP of remote PPP host here
# it will be used to route packets via PPP link
# if you didn't specified the noipdefault option
# change this line to <local_ip>:<remote_ip>
defaultroute # put this if you want that PPP server will be
# your default router/etc/ppp/login.chat.script:(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 is&prompt.root; pppdThis 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 to /dev/modem from
/dev/cuaa1, and only use the modem name in my
configuration files. It can become quite cumbersome when you need to
fix a bunch of files in /etc and
.kermrc's all over the system!/dev/cuaa0 is COM1,
cuaa1 is COM2,
etc.Make sure you have
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 ns2By 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.domainYou 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=NOto:
defaultrouter=slip-gatewayMake a file /etc/resolv.conf which
contains:
domain HIP.Berkeley.EDU
nameserver 128.32.136.9
nameserver 128.32.136.12As 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:&prompt.root; slattach -h -c -s 115200 /dev/modemIf 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
&prompt.root; 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:&prompt.root; 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:&prompt.root; netstat -r
Routing tables
Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks:
(root node)
(root node)
Route Tree for Protocol Family inet:
(root node) =>
default inr-3.Berkeley.EDU UG 8 224515 sl0 - -
localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438
inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - -
silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438
(root node)(this is after transferring a bunch of files, your numbers
should be smaller).Setting up a SLIP 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
&man.sio.4; for information on the serial port device driver and
&man.ttys.5;, &man.gettytab.5;, &man.getty.8;, & &man.init.8;
for information relevant to configuring the system to accept logins on
modems, and perhaps &man.stty.1; for information on setting serial
port parameters (such as clocal for
directly-connected serial interfaces).Quick 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/sliploginWhen 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 &man.syslogd.8; and
&man.syslog.conf.5, and perhaps check
/etc/syslog.conf to see to which files
syslogd is logging).OK, enough of the examples — let us dive into setting up
the system.Kernel 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 2This is the line that defines the number of SLIP devices available
in the kernel; the number at the end of the line is the maximum number
of SLIP connections that may be operating simultaneously.Please refer to Configuring the
FreeBSD Kernel for help in reconfiguring your kernel.Sliplogin ConfigurationAs mentioned earlier, there are three files in the
/etc/sliphome directory that are part of the
configuration for /usr/sbin/sliplogin (see
&man.sliplogin.8; for the actual manual page for
sliplogin): slip.hosts, which
defines the SLIP users & their associated IP addresses;
slip.login, which usually just configures the
SLIP interface; and (optionally) slip.logout,
which undoes slip.login's effects when the serial
connection is terminated.slip.hosts Configuration/etc/sliphome/slip.hosts contains lines
which have at least four items, separated by whitespace:SLIP user's login IDLocal address (local to the SLIP server) of the SLIP
linkRemote address of the SLIP linkNetwork 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:
#
# login local-addr remote-addr mask opt1 opt2
# (normal,compress,noicmp)
#
Shelmerg dc-slip sl-helmerg 0xfffffc00 autocompAt the end of the line is one or more of the options. — no header compression — compress headers — compress headers if the
remote end allows it — disable ICMP packets (so any
“ping” packets will be dropped instead of using up
your bandwidth)Note that sliplogin under early releases of
FreeBSD 2 ignored the options that FreeBSD 1.x recognized, so the
options , ,
, and had no effect
until support was added in FreeBSD 2.2 (unless your
slip.login script included code to make use of
the flags).Your choice of local and remote addresses for your SLIP links
depends on whether you are going to dedicate a TCP/IP subnet or if
you are going to use “proxy ARP” on your SLIP server (it
is not “true” proxy ARP, but that is the terminology
used in this document to describe it). If you are not sure which
method to select or how to assign IP addresses, please refer to the
TCP/IP books referenced in the slips-prereqs section and/or
consult your IP network manager.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
&man.arp.8; to manage the proxy-ARP entries in the SLIP server's
ARP table.slip.login ConfigurationThe typical /etc/sliphome/slip.login file
looks like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 inet $4 $5 netmask $6This slip.login file merely
ifconfig's the appropriate SLIP interface with
the local and remote addresses and network mask of the SLIP
interface.If you have decided to use the “proxy ARP” method
(instead of using a separate subnet for your SLIP clients), your
/etc/sliphome/slip.login file will need to look
something like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 inet $4 $5 netmask $6
# Answer ARP requests for the SLIP client with our Ethernet addr
/usr/sbin/arp -s $5 00:11:22:33:44:55 pubThe 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 116This indicates that this particular system's Ethernet MAC
address is 00:02:c1:28:5f:4a — the
periods in the Ethernet MAC address given by netstat
-i must be changed to colons and leading zeros should be
added to each single-digit hexadecimal number to convert the address
into the form that
&man.arp.8; desires; see the manual page on &man.arp.8; for
complete information on usage.When you create /etc/sliphome/slip.login
and /etc/sliphome/slip.logout, the
“execute” bit (ie, chmod 755
/etc/sliphome/slip.login /etc/sliphome/slip.logout)
must be set, or sliplogin will be unable to
execute it.slip.logout Configuration/etc/sliphome/slip.logout is not strictly
needed (unless you are implementing “proxy ARP”), but if
you decide to create it, this is an example of a basic
slip.logout script:
#!/bin/sh -
#
# slip.logout
#
# logout file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 downIf you are using “proxy ARP”, you will want to have
/etc/sliphome/slip.logout remove the ARP entry
for the SLIP client:
#!/bin/sh -
#
# @(#)slip.logout
#
# logout file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 down
# Quit answering ARP requests for the SLIP client
/usr/sbin/arp -d $5The arp -d $5 removes the ARP entry that
the “proxy ARP” slip.login added
when the SLIP client logged in.It bears repeating: make sure
/etc/sliphome/slip.logout has the execute
bit set for after you create it (ie, chmod
755 /etc/sliphome/slip.logout).Routing 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 ports
collection 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:
#
# 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 ;
} ;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 SeriniPiero@Strider.Inet.IT
diff --git a/en_US.ISO8859-1/books/handbook/printing/chapter.sgml b/en_US.ISO8859-1/books/handbook/printing/chapter.sgml
index 615765ce16..918b4132e0 100644
--- a/en_US.ISO8859-1/books/handbook/printing/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/printing/chapter.sgml
@@ -1,4665 +1,4665 @@
PrintingContributed by &a.kelly; 30 September
1995In order to use printers with FreeBSD, you will need to set them up to
work with the Berkeley line printer spooling system, also known as the LPD
spooling system. It is the standard printer control system in FreeBSD.
This section introduces the LPD spooling system, often simply called
LPD.If you are already familiar with LPD or another printer spooling
system, you may wish to skip to section Setting up the spooling
system.What the Spooler DoesLPD controls everything about a host's printers. It is responsible
for a number of things:It controls access to attached printers and printers attached to
other hosts on the network.It enables users to submit files to be printed; these
submissions are known as jobs.It prevents multiple users from accessing a printer at the same
time by maintaining a queue for each
printer.It can print header pages (also known as
banner or burst pages) so
users can easily find jobs they have printed in a stack of
printouts.It takes care of communications parameters for printers
connected on serial ports.It can send jobs over the network to another LPD spooler on
another host.It can run special filters to format jobs to be printed for
various printer languages or printer capabilities.It can account for printer usage.Through a configuration file, and by providing the special filter
programs, you can enable the LPD system to do all or some subset of the
above for a great variety of printer hardware.Why You Should Use the SpoolerIf you are the sole user of your system, you may be wondering why
you should bother with the spooler when you do not need access control,
header pages, or printer accounting. While it is possible to enable
direct access to a printer, you should use the spooler anyway
sinceLPD prints jobs in the background; you do not have to wait for
data to be copied to the printer.LPD can conveniently run a job to be printed through filters to
add date/time headers or convert a special file format (such as a
TeX DVI file) into a format the printer will understand. You will
not have to do these steps manually.Many free and commercial programs that provide a print feature
usually expect to talk to the spooler on your system. By setting up
the spooling system, you will more easily support other software you
may later add or already have.Setting Up the Spooling SystemTo use printers with the LPD spooling system, you will need to set
up both your printer hardware and the LPD software. This document
describes two levels of setup:See section Simple Printer
Setup to learn how to connect a printer, tell LPD how to
communicate with it, and print plain text files to the
printer.See section Advanced Printer
Setup to find out how to print a variety of special file
formats, to print header pages, to print across a network, to
control access to printers, and to do printer accounting.Simple Printer SetupThis section tells how to configure printer hardware and the LPD
software to use the printer. It teaches the basics:Section Hardware Setup
gives some hints on connecting the printer to a port on your
computer.Section Software Setup
shows how to setup the LPD spooler configuration file
/etc/printcap.If you are setting up a printer that uses a network protocol to
accept data to print instead of a serial or parallel interface, see
Printers With Networked
Data Stream Interaces.Although this section is called “Simple Printer Setup,”
it is actually fairly complex. Getting the printer to work with your
computer and the LPD spooler is the hardest part. The advanced options
like header pages and accounting are fairly easy once you get the
printer working.Hardware SetupThis section tells about the various ways you can connect a
printer to your PC. It talks about the kinds of ports and cables, and
also the kernel configuration you may need to enable FreeBSD to speak
to the printer.If you have already connected your printer and have successfully
printed with it under another operating system, you can probably skip
to section Software
Setup.Ports and CablesNearly all printers you can get for a PC today support one or
both of the following interfaces:Serial interfaces use a serial port on
your computer to send data to the printer. Serial interfaces
are common in the computer industry and cables are readily
available and also easy to construct. Serial interfaces
sometimes need special cables and might require you to configure
somewhat complex communications options.Parallel interfaces use a parallel port
on your computer to send data to the printer. Parallel
interfaces are common in the PC market. Cables are readily
available but more difficult to construct by hand. There are
usually no communications options with parallel interfaces,
making their configuration exceedingly simple.Parallel interfaces are sometimes known as
“Centronics” interfaces, named after the connector
type on the printer.In general, serial interfaces are slower than parallel
interfaces. Parallel interfaces usually offer just one-way
communication (computer to printer) while serial gives you two-way.
Many newer parallel ports can also receive data from the printer,
but only few printers need to send data back to the computer. And
FreeBSD does not support two-way parallel communication yet.Usually, the only time you need two-way communication with the
printer is if the printer speaks PostScript. PostScript printers
can be very verbose. In fact, PostScript jobs are actually programs
sent to the printer; they need not produce paper at all and may
return results directly to the computer. PostScript also uses
two-way communication to tell the computer about problems, such as
errors in the PostScript program or paper jams. Your users may be
appreciative of such information. Furthermore, the best way to do
effective accounting with a PostScript printer requires two-way
communication: you ask the printer for its page count (how many
pages it has printed in its lifetime), then send the user's job,
then ask again for its page count. Subtract the two values and you
know how much paper to charge the user.So, which interface should you use?If you need two-way communication, use a serial port.
FreeBSD does not yet support two-way communication over a
parallel port.If you do not need two-way communication and can pick
parallel or serial, prefer the parallel interface. It keeps a
serial port free for other peripherals—such as a terminal
or a modem—and is faster most of the time. It is also
easier to configure.Finally, use whatever works.Parallel PortsTo hook up a printer using a parallel interface, connect the
Centronics cable between the printer and the computer. The
instructions that came with the printer, the computer, or both
should give you complete guidance.Remember which parallel port you used on the computer. The
first parallel port is /dev/lpt0 to FreeBSD;
the second is /dev/lpt1, and so on.Serial PortsTo hook up a printer using a serial interface, connect the
proper serial cable between the printer and the computer. The
instructions that came with the printer, the computer, or both
should give you complete guidance.If you are unsure what the “proper serial cable” is,
you may wish to try one of the following alternatives:A modem cable connects each pin of the
connector on one end of the cable straight through to its
corresponding pin of the connector on the other end. This type
of cable is also known as a “DTE-to-DCE”
cable.A null-modem cable connects some pins
straight through, swaps others (send data to receive data, for
example), and shorts some internally in each connector hood.
This type of cable is also known as a “DTE-to-DTE”
cable.A serial printer cable, required for
some unusual printers, is like the null modem cable, but sends
some signals to their counterparts instead of being internally
shorted.You should also set up the communications parameters for the
printer, usually through front-panel controls or DIP switches on the
printer. Choose the highest bps (bits per second, sometimes
baud rate) rate that both your computer and the
printer can support. Choose 7 or 8 data bits; none, even, or odd
parity; and 1 or 2 stop bits. Also choose a flow control protocol:
either none, or XON/XOFF (also known as “in-band” or
“software”) flow control. Remember these settings for
the software configuration that follows.Software SetupThis section describes the software setup necessary to print
with the LPD spooling system in FreeBSD.Here is an outline of the steps involved:Configure your kernel, if necessary, for the port you are
using for the printer; section Kernel Configuration tells you
what you need to do.Set the communications mode for the parallel port, if you are
using a parallel port; section Setting the Communication
Mode for the Parallel Port gives details.Test if the operating system can send data to the printer.
Section Checking Printer
Communications gives some suggestions on how to do
this.Set up LPD for the printer by modifying the file
/etc/printcap. Section The /etc/printcap File shows
you how.Kernel ConfigurationThe operating system kernel is compiled to work with a specific
set of devices. The serial or parallel interface for your printer
is a part of that set. Therefore, it might be necessary to add
support for an additional serial or parallel port if your kernel is
not already configured for one.To find out if the kernel you are currently using supports a
serial interface, type:&prompt.root; dmesg | grep sioNWhere N is the number of the serial
port, starting from zero. If you see output similar to the
following:sio2 at 0x3e8-0x3ef irq 5 on isa
sio2: type 16550Athen the kernel supports the port.To find out if the kernel supports a parallel interface,
type:&prompt.root; dmesg | grep lptNWhere N is the number of the parallel
port, starting from zero. If you see output similar to the
following lpt0 at 0x378-0x37f on isa then the
kernel supports the port.You might have to reconfigure your kernel in order for the
operating system to recognize and use the parallel or serial port
you are using for the printer.To add support for a serial port, see the section on kernel
configuration. To add support for a parallel port, see that section
and the section that follows.Adding /dev Entries for the PortsEven though the kernel may support communication along a
serial or parallel port, you will still need a software interface
through which programs running on the system can send and receive
data. That is what entries in the /dev
directory are for.To add a /dev entry for a
port:Become root with the &man.su.1; command. Enter the root
password when prompted.Change to the /dev directory:&prompt.root; cd /devType:&prompt.root; ./MAKEDEV portWhere port is the device entry
for the port you want to make. Use lpt0
for the first parallel port, lpt1 for the
second, and so on; use ttyd0 for the first
serial port, ttyd1 for the second, and so
on.Type:&prompt.root; ls -l portto make sure the device entry got created.Setting the Communication Mode for the Parallel PortWhen you are using the parallel interface, you can choose
whether FreeBSD should use interrupt-driven or polled
communication with the printer.The interrupt-driven method is the
default with the GENERIC kernel. With this method, the
operating system uses an IRQ line to determine when the
printer is ready for data.The polled method directs the
operating system to repeatedly ask the printer if it is ready
for more data. When it responds ready, the kernel sends more
data.The interrupt-driven method is somewhat faster but uses up a
precious IRQ line. You should use whichever one works.You can set the communications mode in two ways: by
configuring the kernel or by using the &man.lptcontrol.8;
program.To set the communications mode by configuring the
kernel:Edit your kernel configuration file. Look for or add an
lpt0 entry. If you are setting up the
second parallel port, use lpt1 instead.
Use lpt2 for the third port, and so
on.If you want interrupt-driven mode, add the
irq specifier:
device lpt0 at isa? port? tty irq N vector lptintrWhere N is the IRQ number
for your computer's parallel port.If you want polled mode, do not add the
irq specifier:
device lpt0 at isa? port? tty vector lptintrSave the file. Then configure, build, and install the
kernel, then reboot. See kernel
configuration for more details.To set the communications mode with
&man.lptcontrol.8;:Type:&prompt.root; lptcontrol -i -u Nto set interrupt-driven mode for
lptN.Type:&prompt.root; lptcontrol -p -u Nto set polled-mode for
lptN.You could put these commands in your
/etc/rc.local file to set the mode each time
your system boots. See &man.lptcontrol.8; for more
information.Checking Printer CommunicationsBefore proceeding to configure the spooling system, you should
make sure the operating system can successfully send data to your
printer. It is a lot easier to debug printer communication and
the spooling system separately.To test the printer, we will send some text to it. For
printers that can immediately print characters sent to them,
the program &man.lptest.1; is perfect: it generates all 96
printable ASCII characters in 96 lines.For a PostScript (or other language-based) printer, we will
need a more sophisticated test. A small PostScript program, such
as the following, will suffice:
%!PS
100 100 moveto 300 300 lineto stroke
310 310 moveto /Helvetica findfont 12 scalefont setfont
(Is this thing working?) show
showpageWhen this document refers to a printer language, I am
assuming a language like PostScript, and not Hewlett Packard's
PCL. Although PCL has great functionality, you can intermingle
plain text with its escape sequences. PostScript cannot directly
print plain text, and that is the kind of printer language for
which we must make special accommodations.Checking a Parallel PrinterThis section tells you how to check if FreeBSD can
communicate with a printer connected to a parallel port.To test a printer on a parallel
port:Become root with &man.su.1;.Send data to the printer.If the printer can print plain text, then use
&man.lptest.1;. Type:&prompt.root; lptest > /dev/lptNWhere N is the number of
the parallel port, starting from zero.If the printer understands PostScript or other
printer language, then send a small program to the
printer. Type:&prompt.root; cat > /dev/lptNThen, line by line, type the program
carefully as you cannot edit a line
once you have pressed RETURN or ENTER. When you have
finished entering the program, press CONTROL+D, or
whatever your end of file key is.Alternatively, you can put the program in a file and
type:&prompt.root; cat file > /dev/lptNWhere file is the name of
the file containing the program you want to send to the
printer.You should see something print. Do not worry if the text
does not look right; we will fix such things later.Checking a Serial PrinterThis section tells you how to check if FreeBSD can
communicate with a printer on a serial port.To test a printer on a serial
port:Become root with &man.su.1;.Edit the file /etc/remote. Add the
following entry:
printer:dv=/dev/port:br#bps-rate:pa=parityWhere port is the device
entry for the serial port (ttyd0,
ttyd1, etc.),
bps-rate is the bits-per-second
rate at which the printer communicates, and
parity is the parity required by
the printer (either even,
odd, none, or
zero).Here is a sample entry for a printer connected via a
serial line to the third serial port at 19200 bps with no
parity:
printer:dv=/dev/ttyd2:br#19200:pa=noneConnect to the printer with &man.tip.1;. Type:&prompt.root; tip printerIf this step does not work, edit the file
/etc/remote again and try using
/dev/cuaaN
instead of
/dev/ttydN.Send data to the printer.If the printer can print plain text, then use
&man.lptest.1;. Type:~$lptestIf the printer understands PostScript or other
printer language, then send a small program to the
printer. Type the program, line by line, very
carefully as backspacing or other editing
keys may be significant to the printer. You may also
need to type a special end-of-file key for the printer
so it knows it received the whole program. For
PostScript printers, press CONTROL+D.Alternatively, you can put the program in a file and
type:~>fileWhere file is the name of
the file containing the program. After
&man.tip.1; sends the file, press any required
end-of-file key.You should see something print. Do not worry if the text
does not look right; we will fix that later.Enabling the Spooler: The /etc/printcap
FileAt this point, your printer should be hooked up, your kernel
configured to communicate with it (if necessary), and you have been
able to send some simple data to the printer. Now, we are ready to
configure LPD to control access to your printer.You configure LPD by editing the file
/etc/printcap. The LPD spooling system reads
this file each time the spooler is used, so updates to the file take
immediate effect.The format of the &man.printcap.5; file is straightforward. Use
your favorite text editor to make changes to
/etc/printcap. The format is identical to
other capability files like
/usr/share/misc/termcap and
/etc/remote. For complete information about
the format, see the &man.cgetent.3;.The simple spooler configuration consists of the following
steps:Pick a name (and a few convenient aliases) for the printer,
and put them in the /etc/printcap file; see
Naming the
Printer.Turn off header pages (which are on by default) by inserting
the sh capability; see Suppressing Header
Pages.Make a spooling directory, and specify its location with the
sd capability; see Making the Spooling
Directory.Set the /dev entry to use for the
printer, and note it in /etc/printcap with
the lp capability; see Identifying the Printer
Device. Also, if the printer is on a serial port, set
up the communication parameters with the fs,
fc, xs, and
xc capabilities; see Configuring Spooler
Communications Parameters.Install a plain text input filter; see Installing the Text
FilterTest the setup by printing something with the
&man.lpr.1; command; see Trying It Out and Troubleshooting.Language-based printers, such as PostScript printers, cannot
directly print plain text. The simple setup outlined above and
described in the following sections assumes that if you are
installing such a printer you will print only files that the
printer can understand.Users often expect that they can print plain text to any of the
printers installed on your system. Programs that interface to LPD
to do their printing usually make the same assumption. If you are
installing such a printer and want to be able to print jobs in the
printer language and print plain text jobs, you
are strongly urged to add an additional step to the simple setup
outlined above: install an automatic plain-text-to-PostScript (or
other printer language) conversion program. Section Accommodating Plain Text
Jobs on PostScript Printers tells how to do this.Naming the PrinterThe first (easy) step is to pick a name for your printer. It
really does not matter whether you choose functional or whimsical
names since you can also provide a number aliases for the
printer.At least one of the printers specified in the
/etc/printcap should have the alias
lp. This is the default printer's name. If
users do not have the PRINTER environment variable
nor specify a printer name on the command line of any of the LPD
commands, then lp will be the default printer
they get to use.Also, it is common practice to make the last alias for a
printer be a full description of the printer, including make and
model.Once you have picked a name and some common aliases, put them
in the /etc/printcap file. The name of the
printer should start in the leftmost column. Separate each alias
with a vertical bar and put a colon after the last alias.In the following example, we start with a skeletal
/etc/printcap that defines two printers (a
Diablo 630 line printer and a Panasonic KX-P4455 PostScript laser
printer):
#
# /etc/printcap for host rose
#
rattan|line|diablo|lp|Diablo 630 Line Printer:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:In this example, the first printer is named
rattan and has as aliases
line, diablo,
lp, and Diablo 630 Line
Printer. Since it has the alias
lp, it is also the default printer. The second
is named bamboo, and has as aliases
ps, PS,
S, panasonic, and
Panasonic KX-P4455 PostScript v51.4.Suppressing Header PagesThe LPD spooling system will by default print a
header page for each job. The header page
contains the user name who requested the job, the host from which
the job came, and the name of the job, in nice large letters.
Unfortunately, all this extra text gets in the way of debugging
the simple printer setup, so we will suppress header pages.To suppress header pages, add the sh
capability to the entry for the printer in
/etc/printcap. Here is the example
/etc/printcap with sh
added:
#
# /etc/printcap for host rose - no header pages anywhere
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:Note how we used the correct format: the first line starts in
the leftmost column, and subsequent lines are indented with a
single TAB. Every line in an entry except the last ends in a
backslash character.Making the Spooling DirectoryThe next step in the simple spooler setup is to make a
spooling directory, a directory where print
jobs reside until they are printed, and where a number of other
spooler support files live.Because of the variable nature of spooling directories, it is
customary to put these directories under
/var/spool. It is not necessary to backup
the contents of spooling directories, either. Recreating them is
as simple as running &man.mkdir.1;.It is also customary to make the directory with a name that is
identical to the name of the printer, as shown below:&prompt.root; mkdir /var/spool/printer-nameHowever, if you have a lot of printers on your network, you
might want to put the spooling directories under a single
directory that you reserve just for printing with LPD. We will do
this for our two example printers rattan and
bamboo:&prompt.root; mkdir /var/spool/lpd
&prompt.root; mkdir /var/spool/lpd/rattan
&prompt.root; mkdir /var/spool/lpd/bambooIf you are concerned about the privacy of jobs that users
print, you might want to protect the spooling directory so it is
not publicly accessible. Spooling directories should be owned
and be readable, writable, and searchable by user daemon and
group daemon, and no one else. We will do this for our example
printers:&prompt.root; chown daemon.daemon /var/spool/lpd/rattan
&prompt.root; chown daemon.daemon /var/spool/lpd/bamboo
&prompt.root; chmod 770 /var/spool/lpd/rattan
&prompt.root; chmod 770 /var/spool/lpd/bambooFinally, you need to tell LPD about these directories using
the /etc/printcap file. You specify the
pathname of the spooling directory with the sd
capability:
#
# /etc/printcap for host rose - added spooling directories
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:Note that the name of the printer starts in the first column
but all other entries describing the printer should be indented
with a tab and each line escaped with a backslash.If you do not specify a spooling directory with
sd, the spooling system will use
/var/spool/lpd as a default.Identifying the Printer DeviceIn section Adding /dev
Entries for the Ports, we identified which entry in the
/dev directory FreeBSD will use to
communicate with the printer. Now, we tell LPD that information.
When the spooling system has a job to print, it will open the
specified device on behalf of the filter program (which is
responsible for passing data to the printer).List the /dev entry pathname in the
/etc/printcap file using the
lp capability.In our running example, let us assume that
rattan is on the first parallel port, and
bamboo is on a sixth serial port; here are the
additions to /etc/printcap:
#
# /etc/printcap for host rose - identified what devices to use
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:If you do not specify the lp capability for
a printer in your /etc/printcap file, LPD
uses /dev/lp as a default.
/dev/lp currently does not exist in
FreeBSD.If the printer you are installing is connected to a parallel
port, skip to the section Installing the Text Filter.
Otherwise, be sure to follow the instructions in the next
section.Configuring Spooler Communication ParametersFor printers on serial ports, LPD can set up the bps rate,
parity, and other serial communication parameters on behalf of the
filter program that sends data to the printer. This is
advantageous since:It lets you try different communication parameters by
simply editing the /etc/printcap file;
you do not have to recompile the filter program.It enables the spooling system to use the same filter
program for multiple printers which may have different serial
communication settings.The following /etc/printcap capabilities
control serial communication parameters of the device listed in
the lp capability:br#bps-rateSets the communications speed of the device to
bps-rate, where
bps-rate can be 50, 75, 110, 134,
150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, or
38400 bits-per-second.fc#clear-bitsClears the flag bits
clear-bits in the
sgttyb structure after opening
the device.fs#set-bitsSets the flag bits set-bits
in the sgttyb structure.xc#clear-bitsClears local mode bits
clear-bits after opening the
device.xs#set-bitsSets local mode bits
set-bits.For more information on the bits for the
fc, fs,
xc, and xs capabilities, see
the file
/usr/include/sys/ioctl_compat.h.When LPD opens the device specified by the
lp capability, it reads the flag bits in the
sgttyb structure; it clears any bits in the
fc capability, then sets bits in the
fs capability, then applies the resultant
setting. It does the same for the local mode bits as well.Let us add to our example printer on the sixth serial port.
We will set the bps rate to 38400. For the flag bits, we will set
the TANDEM, ANYP, LITOUT, FLUSHO, and PASS8 flags. For the local
mode bits, we will set the LITOUT and PASS8 flags:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:fs#0x82000c1:xs#0x820:Installing the Text FilterWe are now ready to tell LPD what text filter to use to send
jobs to the printer. A text filter, also
known as an input filter, is a program that
LPD runs when it has a job to print. When LPD runs the text
filter for a printer, it sets the filter's standard input to the
job to print, and its standard output to the printer device
specified with the lp capability. The filter
is expected to read the job from standard input, perform any
necessary translation for the printer, and write the results to
standard output, which will get printed. For more information on
the text filter, see section Filters.For our simple printer setup, the text filter can be a small
shell script that just executes /bin/cat to
send the job to the printer. FreeBSD comes with another filter
called lpf that handles backspacing and
underlining for printers that might not deal with such character
streams well. And, of course, you can use any other filter
program you want. The filter lpf is described
in detail in section lpf: a
Text Filter.First, let us make the shell script
/usr/local/libexec/if-simple be a simple text
filter. Put the following text into that file with your favorite
text editor:
#!/bin/sh
#
# if-simple - Simple text input filter for lpd
# Installed in /usr/local/libexec/if-simple
#
# Simply copies stdin to stdout. Ignores all filter arguments.
/bin/cat && exit 0
exit 2Make the file executable:&prompt.root; chmod 555 /usr/local/libexec/if-simpleAnd then tell LPD to use it by specifying it with the
if capability in
/etc/printcap. We will add it to the two
printers we have so far in the example
/etc/printcap:
#
# /etc/printcap for host rose - added text filter
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\
:if=/usr/local/libexec/if-simple:Trying It OutYou have reached the end of the simple LPD setup.
Unfortunately, congratulations are not quite yet in order, since
we still have to test the setup and correct any problems. To test
the setup, try printing something. To print with the LPD system,
you use the command &man.lpr.1;,
which submits a job for printing.You can combine &man.lpr.1; with the &man.lptest.1; program,
introduced in section Checking
Printer Communications to generate some test text.To test the simple LPD setup:Type:&prompt.root; lptest 20 5 | lpr -Pprinter-nameWhere printer-name is a the name of
a printer (or an alias) specified in
/etc/printcap. To test the default printer,
type &man.lpr.1; without any
argument. Again, if you are testing a printer
that expects PostScript, send a PostScript program in that
language instead of using &man.lptest.1;. You can do so by
putting the program in a file and typing lpr
file.For a PostScript printer, you should get the results of the
program. If you are using &man.lptest.1;, then your results
should look like the following:
!"#$%&'()*+,-./01234
"#$%&'()*+,-./012345
#$%&'()*+,-./0123456
$%&'()*+,-./01234567
%&'()*+,-./012345678To further test the printer, try downloading larger programs
(for language-based printers) or running &man.lptest.1; with
different arguments. For example, lptest 80 60
will produce 60 lines of 80 characters each.If the printer did not work, see the next section, Troubleshooting.TroubleshootingAfter performing the simple test with &man.lptest.1;, you
might have gotten one of the following results instead of the
correct printout:It worked, after awhile; or, it did not eject a full
sheet.The printer printed the above, but it sat for awhile and
did nothing. In fact, you might have needed to press a
PRINT REMAINING or FORM FEED button on the printer to get
any results to appear.If this is the case, the printer was probably waiting to
see if there was any more data for your job before it
printed anything. To fix this problem, you can have the
text filter send a FORM FEED character (or whatever is
necessary) to the printer. This is usually sufficient to
have the printer immediately print any text remaining in its
internal buffer. It is also useful to make sure each print
job ends on a full sheet, so the next job does not start
somewhere on the middle of the last page of the previous
job.The following replacement for the shell script
/usr/local/libexec/if-simple prints a
form feed after it sends the job to the printer:
#!/bin/sh
#
# if-simple - Simple text input filter for lpd
# Installed in /usr/local/libexec/if-simple
#
# Simply copies stdin to stdout. Ignores all filter arguments.
# Writes a form feed character (\f) after printing job.
/bin/cat && printf "\f" && exit 0
exit 2It produced the “staircase effect.”You got the following on paper:
!"#$%&'()*+,-./01234
"#$%&'()*+,-./012345
#$%&'()*+,-./0123456You have become another victim of the
staircase effect, caused by conflicting
interpretations of what characters should indicate a
new-line. UNIX-style operating systems use a single
character: ASCII code 10, the line feed (LF). MS-DOS, OS/2,
and others uses a pair of characters, ASCII code 10
and ASCII code 13 (the carriage return
or CR). Many printers use the MS-DOS convention for
representing new-lines.When you print with FreeBSD, your text used just the
line feed character. The printer, upon seeing a line feed
character, advanced the paper one line, but maintained the
same horizontal position on the page for the next character
to print. That is what the carriage return is for: to move
the location of the next character to print to the left edge
of the paper.Here is what FreeBSD wants your printer to do:Printer received CRPrinter prints CRPrinter received LFPrinter prints CR + LFHere are some ways to achieve this:Use the printer's configuration switches or control
panel to alter its interpretation of these characters.
Check your printer's manual to find out how to do
this.If you boot your system into other operating
systems besides FreeBSD, you may have to
reconfigure the printer to use a
an interpretation for CR and LF characters that those
other operating systems use. You might prefer one of
the other solutions, below.Have FreeBSD's serial line driver automatically
convert LF to CR+LF. Of course, this works with
printers on serial ports only. To
enable this feature, set the CRMOD bit in
fs capability in the
/etc/printcap file for the
printer.Send an escape code to the
printer to have it temporarily treat LF characters
differently. Consult your printer's manual for escape
codes that your printer might support. When you find
the proper escape code, modify the text filter to send
the code first, then send the print job.Here is an example text filter for printers that
understand the Hewlett-Packard PCL escape codes. This
filter makes the printer treat LF characters as a LF and
CR; then it sends the job; then it sends a form feed to
eject the last page of the job. It should work with
nearly all Hewlett Packard printers.
#!/bin/sh
#
# hpif - Simple text input filter for lpd for HP-PCL based printers
# Installed in /usr/local/libexec/hpif
#
# Simply copies stdin to stdout. Ignores all filter arguments.
# Tells printer to treat LF as CR+LF. Ejects the page when done.
printf "\033&k2G" && cat && printf "\033&l0H" && exit 0
exit 2Here is an example
/etc/printcap from a host called
orchid. It has a single printer attached to its first
parallel port, a Hewlett Packard LaserJet 3Si named
teak. It is using the above script as
its text filter:
#
# /etc/printcap for host orchid
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/hpif:It overprinted each line.The printer never advanced a line. All of the lines of
text were printed on top of each other on one line.This problem is the “opposite” of the
staircase effect, described above, and is much rarer.
Somewhere, the LF characters that FreeBSD uses to end a line
are being treated as CR characters to return the print
location to the left edge of the paper, but not also down a
line.Use the printer's configuration switches or control
panel to enforce the following interpretation of LF and CR
characters:Printer receivesPrinter printsCRCRLFCR + LFThe printer lost characters.While printing, the printer did not print a few
characters in each line. The problem might have gotten
worse as the printer ran, losing more and more
characters.The problem is that the printer cannot keep up with the
speed at which the computer sends data over a serial line.
(This problem should not occur with printers on parallel
ports.) There are two ways to overcome the problem:If the printer supports XON/XOFF flow control, have
FreeBSD use it by specifying the TANDEM bit in the
fs capability.If the printer supports carrier flow control,
specify the MDMBUF bit in the fs
capability. Make sure the cable connecting the printer
to the computer is correctly wired for carrier flow
control.If the printer does not support any flow control,
use some combination of the NLDELAY, TBDELAY, CRDELAY,
VTDELAY, and BSDELAY bits in the fs
capability to add appropriate delays to the stream of
data sent to the printer.It printed garbage.The printer printed what appeared to be random garbage,
but not the desired text.This is usually another symptom of incorrect
communications parameters with a serial printer.
Double-check the bps rate in the br
capability, and the parity bits in the fs
and fc capabilities; make sure the
printer is using the same settings as specified in the
/etc/printcap file.Nothing happened.If nothing happened, the problem is probably within
FreeBSD and not the hardware. Add the log file
(lf) capability to the entry for the
printer you are debugging in the
/etc/printcap file. For example, here
is the entry for rattan, with the
lf capability:
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:\
:lf=/var/log/rattan.logThen, try printing again. Check the log file (in our
example, /var/log/rattan.log) to see
any error messages that might appear. Based on the messages
you see, try to correct the problem.If you do not specify a lf
capability, LPD uses /dev/console as a
default.Using PrintersThis section tells you how to use printers you have setup with
FreeBSD. Here is an overview of the user-level commands:&man.lpr.1;Print jobs&man.lpq.1;Check printer queues&man.lprm.1;Remove jobs from a printer's queueThere is also an administrative command, &man.lpc.8;, described in
the section Administrating the LPD
Spooler, used to control printers and their queues.All three of the commands &man.lpr.1;, &man.lprm.1;, and &man.lpq.1;
accept an option to specify on which
printer/queue to operate, as listed in the
/etc/printcap file. This enables you to submit,
remove, and check on jobs for various printers. If you do not use the
option, then these commands use the printer
specified in the PRINTER environment variable. Finally,
if you do not have a PRINTER environment variable, these
commands default to the printer named lp.Hereafter, the terminology default printer
means the printer named in the PRINTER environment
variable, or the printer named lp when there is no
PRINTER environment variable.Printing JobsTo print files, type:&prompt.user; lpr filename...This prints each of the listed files to the default printer. If
you list no files, &man.lpr.1; reads data to
print from standard input. For example, this command prints some
important system files:&prompt.user; lpr /etc/host.conf /etc/hosts.equivTo select a specific printer, type:&prompt.user; lpr -P printer-namefilename...This example prints a long listing of the current directory to the
printer named rattan:&prompt.user; ls -l | lpr -P rattanBecause no files were listed for the
&man.lpr.1; command, lpr read the data to print
from standard input, which was the output of the ls
-l command.The &man.lpr.1; command can also accept a wide variety of options
to control formatting, apply file conversions, generate multiple
copies, and so forth. For more information, see the section Printing Options.Checking JobsWhen you print with &man.lpr.1;, the data you wish to print is put
together in a package called a “print job”, which is sent
to the LPD spooling system. Each printer has a queue of jobs, and
your job waits in that queue along with other jobs from yourself and
from other users. The printer prints those jobs in a first-come,
first-served order.To display the queue for the default printer, type &man.lpq.1;.
For a specific printer, use the option. For
example, the command
&prompt.user; lpq -P bamboo
shows the queue for the printer named bamboo. Here
is an example of the output of the lpq
command:bamboo is ready and printing
Rank Owner Job Files Total Size
active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes
2nd kelly 10 (standard input) 1635 bytes
3rd mary 11 ... 78519 bytesThis shows three jobs in the queue for bamboo.
The first job, submitted by user kelly, got assigned “job
number” 9. Every job for a printer gets a unique job number.
Most of the time you can ignore the job number, but you will need it
if you want to cancel the job; see section Removing Jobs for details.Job number nine consists of two files; multiple files given on the
&man.lpr.1; command line are treated as part of a single job. It
is the currently active job (note the word active
under the “Rank” column), which means the printer should
be currently printing that job. The second job consists of data
passed as the standard input to the &man.lpr.1; command. The third
job came from user mary; it is a much larger
job. The pathname of the files she's trying to print is too long to
fit, so the &man.lpq.1; command just shows three dots.The very first line of the output from &man.lpq.1; is also useful:
it tells what the printer is currently doing (or at least what LPD
thinks the printer is doing).The &man.lpq.1; command also support a option
to generate a detailed long listing. Here is an example of
lpq -l:waiting for bamboo to become ready (offline ?)
kelly: 1st [job 009rose]
/etc/host.conf 73 bytes
/etc/hosts.equiv 15 bytes
kelly: 2nd [job 010rose]
(standard input) 1635 bytes
mary: 3rd [job 011rose]
/home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytesRemoving JobsIf you change your mind about printing a job, you can remove the
job from the queue with the &man.lprm.1; command. Often, you can
even use &man.lprm.1; to remove an active job, but some or all of the
job might still get printed.To remove a job from the default printer, first use
&man.lpq.1; to find the job number. Then type:&prompt.user; lprm job-numberTo remove the job from a specific printer, add the
option. The following command removes job number
10 from the queue for the printer bamboo:&prompt.user; lprm -P bamboo 10The &man.lprm.1; command has a few shortcuts:lprm -Removes all jobs (for the default printer) belonging to
you.lprm userRemoves all jobs (for the default printer) belonging to
user. The superuser can remove other
users' jobs; you can remove only your own jobs.lprmWith no job number, user name, or
appearing on the command line,
&man.lprm.1; removes the currently active job on the
default printer, if it belongs to you. The superuser can remove
any active job.Just use the option with the above shortcuts
to operate on a specific printer instead of the default. For example,
the following command removes all jobs for the current user in the
queue for the printer named rattan:&prompt.user; lprm -P rattan -If you are working in a networked environment, &man.lprm.1; will
let you remove jobs only from the
host from which the jobs were submitted, even if the same printer is
available from other hosts. The following command sequence
demonstrates this:&prompt.user; lpr -P rattan myfile
&prompt.user; rlogin orchid
&prompt.user; lpq -P rattan
Rank Owner Job Files Total Size
active seeyan 12 ... 49123 bytes
2nd kelly 13 myfile 12 bytes
&prompt.user; lprm -P rattan 13
rose: Permission denied
&prompt.user; logout
&prompt.user; lprm -P rattan 13
dfA013rose dequeued
cfA013rose dequeued
Beyond Plain Text: Printing OptionsThe &man.lpr.1; command supports a number of options that control
formatting text, converting graphic and other file formats, producing
multiple copies, handling of the job, and more. This section
describes the options.Formatting and Conversion OptionsThe following &man.lpr.1; options control formatting of the
files in the job. Use these options if the job does not contain
plain text or if you want plain text formatted through the
&man.pr.1; utility.For example, the following command prints a DVI file (from the
TeX typesetting system) named fish-report.dvi
to the printer named bamboo:&prompt.user; lpr -P bamboo -d fish-report.dviThese options apply to every file in the job, so you cannot mix
(say) DVI and ditroff files together in a job. Instead, submit the
files as separate jobs, using a different conversion option for each
job.All of these options except and
require conversion filters installed for the
destination printer. For example, the option
requires the DVI conversion filter. Section Conversion
Filters gives details.Print cifplot files.Print DVI files.Print FORTRAN text files.Print plot data.Indent the output by number
columns; if you omit number, indent
by 8 columns. This option works only with certain conversion
filters.Do not put any space between the and
the number.Print literal text data, including control
characters.Print ditroff (device independent troff) data.-pFormat plain text with &man.pr.1; before printing. See
&man.pr.1; for more information.Use title on the
&man.pr.1; header instead of the file name. This option has
effect only when used with the
option.Print troff data.Print raster data.Here is an example: this command prints a nicely formatted
version of the &man.ls.1; manual page on the default printer:&prompt.user; zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -tThe &man.zcat.1; command uncompresses the source of the&man.ls.1; manual page and passes it to the &man.troff.1;
command, which formats that source and makes GNU troff output and
passes it to &man.lpr.1;, which submits the job to the LPD spooler.
Because we used the option to&man.lpr.1;, the spooler will convert the GNU troff output into
a format the default printer can understand when it prints the
job.Job Handling OptionsThe following options to &man.lpr.1; tell LPD to handle the job
specially:-# copiesProduce a number of copies of
each file in the job instead of just one copy. An
administrator may disable this option to reduce printer
wear-and-tear and encourage photocopier usage. See section
Restricting
Multiple Copies.This example prints three copies of
parser.c followed by three copies of
parser.h to the default printer:&prompt.user; lpr -#3 parser.c parser.h-mSend mail after completing the print job. With this
option, the LPD system will send mail to your account when it
finishes handling your job. In its message, it will tell you
if the job completed successfully or if there was an error,
and (often) what the error was.-sDo not copy the files to the spooling directory, but make
symbolic links to them instead.If you are printing a large job, you probably want to use
this option. It saves space in the spooling directory (your
job might overflow the free space on the filesystem where the
spooling directory resides). It saves time as well since LPD
will not have to copy each and every byte of your job to the
spooling directory.There is a drawback, though: since LPD will refer to the
original files directly, you cannot modify or remove them
until they have been printed.If you are printing to a remote printer, LPD will
eventually have to copy files from the local host to the
remote host, so the option will save
space only on the local spooling directory, not the remote.
It is still useful, though.-rRemove the files in the job after copying them to the
spooling directory, or after printing them with the
option. Be careful with this
option!Header Page OptionsThese options to &man.lpr.1; adjust the text that normally
appears on a job's header page. If header pages are suppressed for
the destination printer, these options have no effect. See section
Header Pages
for information about setting up header pages.-C textReplace the hostname on the header page with
text. The hostname is normally the
name of the host from which the job was submitted.-J textReplace the job name on the header page with
text. The job name is normally the
name of the first file of the job, or
stdin if you are printing standard
input.-hDo not print any header page.At some sites, this option may have no effect due to the
way header pages are generated. See Header
Pages for details.Administrating PrintersAs an administrator for your printers, you have had to install,
set up, and test them. Using the &man.lpc.8; command, you
can interact with your printers in yet more ways. With &man.lpc.8;,
you canStart and stop the printersEnable and disable their queuesRearrange the order of the jobs in each queue.First, a note about terminology: if a printer is
stopped, it will not print anything in its queue.
Users can still submit jobs, which will wait in the queue until the
printer is started or the queue is
cleared.If a queue is disabled, no user (except root)
can submit jobs for the printer. An enabled
queue allows jobs to be submitted. A printer can be
started for a disabled queue, in which case it
will continue to print jobs in the queue until the queue is
empty.In general, you have to have root privileges to use the
&man.lpc.8; command. Ordinary users can use the &man.lpc.8; command
to get printer status and to restart a hung printer only.Here is a summary of the &man.lpc.8; commands. Most of the
commands takes a printer-name argument to
tell on which printer to operate. You can use all
for the printer-name to mean all printers
listed in /etc/printcap.abort
printer-nameCancel the current job and stop the printer. Users can
still submit jobs if the queue's enabled.clean
printer-nameRemove old files from the printer's spooling directory.
Occasionally, the files that make up a job are not properly
removed by LPD, particularly if there have been errors during
printing or a lot of administrative activity. This command
finds files that do not belong in the spooling directory and
removes them.disable
printer-nameDisable queuing of new jobs. If the printer's started, it
will continue to print any jobs remaining in the queue. The
superuser (root) can always submit jobs, even to a disabled
queue.This command is useful while you are testing a new printer
or filter installation: disable the queue and submit jobs as
root. Other users will not be able to submit jobs until you
complete your testing and re-enable the queue with the
enable command.down printer-namemessageTake a printer down. Equivalent to
disable followed by stop.
The message appears as the printer's
status whenever a user checks the printer's queue with
&man.lpq.1; or status with lpc
status.enable
printer-nameEnable the queue for a printer. Users can submit jobs but
the printer will not print anything until it is started.help
command-namePrint help on the command
command-name. With no
command-name, print a summary of the
commands available.restart
printer-nameStart the printer. Ordinary users can use this command if
some extraordinary circumstance hangs LPD, but they cannot start
a printer stopped with either the stop or
down commands. The
restart command is equivalent to
abort followed by
start.start
printer-nameStart the printer. The printer will print jobs in its
queue.stop
printer-nameStop the printer. The printer will finish the current job
and will not print anything else in its queue. Even though the
printer is stopped, users can still submit jobs to an enabled
queue.topq printer-namejob-or-usernameRearrange the queue for
printer-name by placing the jobs with
the listed job numbers or the jobs
belonging to username at the top of
the queue. For this command, you cannot use
all as the
printer-name.up
printer-nameBring a printer up; the opposite of the
down command. Equivalent to
start followed by
enable.&man.lpc.8; accepts the above commands on the command line. If
you do not enter any commands, &man.lpc.8; enters an interactive mode,
where you can enter commands until you type exit,
quit, or end-of-file.Advanced Printer SetupThis section describes filters for printing specially formatted
files, header pages, printing across networks, and restricting and
accounting for printer usage.FiltersAlthough LPD handles network protocols, queuing, access control,
and other aspects of printing, most of the real
work happens in the filters. Filters are
programs that communicate with the printer and handle its device
dependencies and special requirements. In the simple printer setup,
we installed a plain text filter—an extremely simple one that
should work with most printers (section Installing the Text
Filter).However, in order to take advantage of format conversion, printer
accounting, specific printer quirks, and so on, you should understand
how filters work. It will ultimately be the filter's responsibility
to handle these aspects. And the bad news is that most of the time
you have to provide filters yourself. The good
news is that many are generally available; when they are not, they are
usually easy to write.Also, FreeBSD comes with one,
/usr/libexec/lpr/lpf, that works with many
printers that can print plain text. (It handles backspacing and tabs
in the file, and does accounting, but that is about all it does.)
There are also several filters and filter components in the FreeBSD
ports collection.Here is what you will find in this section:Section How Filters
Work, tries to give an overview of a filter's role in the
printing process. You should read this section to get an
understanding of what is happening “under the hood”
when LPD uses filters. This knowledge could help you anticipate
and debug problems you might encounter as you install more and
more filters on each of your printers.LPD expects every printer to be able to print plain text by
default. This presents a problem for PostScript (or other
language-based printers) which cannot directly print plain text.
Section Accommodating
Plain Text Jobs on PostScript Printers tells you what you
should do to overcome this problem. I recommend reading this
section if you have a PostScript printer.PostScript is a popular output format for many programs. Even
some people (myself included) write PostScript code directly. But
PostScript printers are expensive. Section Simulating PostScript on
Non-PostScript Printers tells how you can further modify
a printer's text filter to accept and print PostScript data on a
non-PostScript printer. I recommend reading
this section if you do not have a PostScript printer.Section Conversion
Filters tells about a way you can automate the conversion
of specific file formats, such as graphic or typesetting data,
into formats your printer can understand. After reading this
section, you should be able to set up your printers such that
users can type lpr -t to print troff data, or
lpr -d to print TeX DVI data, or lpr
-v to print raster image data, and so forth. I
recommend reading this section.Section Output
Filters tells all about a not often used feature of LPD:
output filters. Unless you are printing header pages (see Header Pages),
you can probably skip that section altogether.Section lpf: a Text
Filter describes lpf, a fairly
complete if simple text filter for line printers (and laser
printers that act like line printers) that comes with FreeBSD. If
you need a quick way to get printer accounting working for plain
text, or if you have a printer which emits smoke when it sees
backspace characters, you should definitely consider
lpf.How Filters WorkAs mentioned before, a filter is an executable program started
by LPD to handle the device-dependent part of communicating with the
printer.When LPD wants to print a file in a job, it starts a filter
program. It sets the filter's standard input to the file to print,
its standard output to the printer, and its standard error to the
error logging file (specified in the lf
capability in /etc/printcap, or
/dev/console by default).Which filter LPD starts and the filter's arguments depend on
what is listed in the /etc/printcap file and
what arguments the user specified for the job on the
&man.lpr.1; command line. For example, if the user typed
lpr -t, LPD would start the troff filter, listed
in the tf capability for the destination printer.
If the user wanted to print plain text, it would start the
if filter (this is mostly true: see Output Filters for
details).There are three kinds of filters you can specify in
/etc/printcap:The text filter, confusingly called the
input filter in LPD documentation, handles
regular text printing. Think of it as the default filter. LPD
expects every printer to be able to print plain text by default,
and it is the text filter's job to make sure backspaces, tabs,
or other special characters do not confuse the printer. If you
are in an environment where you have to account for printer
usage, the text filter must also account for pages printed,
usually by counting the number of lines printed and comparing
that to the number of lines per page the printer supports. The
text filter is started with the following argument list:
filter-name-c-wwidth-llength-iindent-n login-h hostacct-file
where
appears if the job's submitted with lpr
-lwidthis the value from the pw (page
width) capability specified in
/etc/printcap, default 132lengthis the value from the pl (page
length) capability, default 66indentis the amount of the indentation from lpr
-i, default 0loginis the account name of the user printing the
filehostis the host name from which the job was
submittedacct-fileis the name of the accounting file from the
af capability.A conversion filter converts a specific
file format into one the printer can render onto paper. For
example, ditroff typesetting data cannot be directly printed,
but you can install a conversion filter for ditroff files to
convert the ditroff data into a form the printer can digest and
print. Section Conversion
Filters tells all about them. Conversion filters also
need to do accounting, if you need printer accounting.
Conversion filters are started with the following arguments:
filter-name-xpixel-width-ypixel-height-n login-h hostacct-file
where pixel-width is the value
from the px capability (default 0) and
pixel-height is the value from the
py capability (default 0).The output filter is used only if there
is no text filter, or if header pages are enabled. In my
experience, output filters are rarely used. Section Output Filters describe
them. There are only two arguments to an output filter:
filter-name-wwidth-llength
which are identical to the text filters and
arguments.Filters should also exit with the
following exit status:exit 0If the filter printed the file successfully.exit 1If the filter failed to print the file but wants LPD to
try to print the file again. LPD will restart a filter if it
exits with this status.exit 2If the filter failed to print the file and does not want
LPD to try again. LPD will throw out the file.The text filter that comes with the FreeBSD release,
/usr/libexec/lpr/lpf, takes advantage of the
page width and length arguments to determine when to send a form
feed and how to account for printer usage. It uses the login, host,
and accounting file arguments to make the accounting entries.If you are shopping for filters, see if they are LPD-compatible.
If they are, they must support the argument lists described above.
If you plan on writing filters for general use, then have them
support the same argument lists and exit codes.Accommodating Plain Text Jobs on PostScript PrintersIf you are the only user of your computer and PostScript (or
other language-based) printer, and you promise to never send plain
text to your printer and to never use features of various programs
that will want to send plain text to your printer, then you do not
need to worry about this section at all.But, if you would like to send both PostScript and plain text
jobs to the printer, then you are urged to augment your printer
setup. To do so, we have the text filter detect if the arriving job
is plain text or PostScript. All PostScript jobs must start with
%! (for other printer languages, see your printer
documentation). If those are the first two characters in the job,
we have PostScript, and can pass the rest of the job directly. If
those are not the first two characters in the file, then the filter
will convert the text into PostScript and print the result.How do we do this?If you have got a serial printer, a great way to do it is to
install lprps. lprps is a
PostScript printer filter which performs two-way communication with
the printer. It updates the printer's status file with verbose
information from the printer, so users and administrators can see
exactly what the state of the printer is (such as toner
low or paper jam). But more
importantly, it includes a program called psif
which detects whether the incoming job is plain text and calls
textps (another program that comes with
lprps) to convert it to PostScript. It then uses
lprps to send the job to the printer.lprps is part of the FreeBSD ports collection
(see The Ports Collection). You can
fetch, build and install it yourself, of course. After installing
lprps, just specify the pathname to the
psif program that is part of
lprps. If you installed lprps
from the ports collection, use the following in the serial
PostScript printer's entry in
/etc/printcap:
:if=/usr/local/libexec/psif:You should also specify the rw capability;
that tells LPD to open the printer in read-write mode.If you have a parallel PostScript printer (and therefore cannot
use two-way communication with the printer, which
lprps needs), you can use the following shell
script as the text filter:
#!/bin/sh
#
# psif - Print PostScript or plain text on a PostScript printer
# Script version; NOT the version that comes with lprps
# Installed in /usr/local/libexec/psif
#
read first_line
first_two_chars=`expr "$first_line" : '\(..\)'`
if [ "$first_two_chars" = "%!" ]; then
#
# PostScript job, print it.
#
echo "$first_line" && cat && printf "\004" && exit 0
exit 2
else
#
# Plain text, convert it, then print it.
#
( echo "$first_line"; cat ) | /usr/local/bin/textps && printf "\004" && exit 0
exit 2
fiIn the above script, textps is a program we
installed separately to convert plain text to PostScript. You can
use any text-to-PostScript program you wish. The FreeBSD ports
collection (see The Ports Collection)
includes a full featured text-to-PostScript program called
a2ps that you might want to investigate.Simulating PostScript on Non-PostScript PrintersPostScript is the de facto standard for
high quality typesetting and printing. PostScript is, however, an
expensive standard. Thankfully, Alladin
Enterprises has a free PostScript work-alike called
Ghostscript that runs with FreeBSD.
Ghostscript can read most PostScript files and can render their
pages onto a variety of devices, including many brands of
non-PostScript printers. By installing Ghostscript and using a
special text filter for your printer, you can make your
non-PostScript printer act like a real PostScript printer.Ghostscript should be in the FreeBSD ports collection, if you
would like to install it from there. You can fetch, build, and
install it quite easily yourself, as well.To simulate PostScript, we have the text filter detect if it is
printing a PostScript file. If it is not, then the filter will pass
the file directly to the printer; otherwise, it will use Ghostscript
to first convert the file into a format the printer will
understand.Here is an example: the following script is a text filter
for Hewlett Packard DeskJet 500 printers. For other printers,
substitute the argument to the
gs (Ghostscript) command. (Type gs
-h to get a list of devices the current installation of
Ghostscript supports.)
#!/bin/sh
#
# ifhp - Print Ghostscript-simulated PostScript on a DeskJet 500
# Installed in /usr/local/libexec/hpif
#
# Treat LF as CR+LF:
#
printf "\033&k2G" || exit 2
#
# Read first two characters of the file
#
read first_line
first_two_chars=`expr "$first_line" : '\(..\)'`
if [ "$first_two_chars" = "%!" ]; then
#
# It is PostScript; use Ghostscript to scan-convert and print it.
#
# Note that PostScript files are actually interpreted programs,
# and those programs are allowed to write to stdout, which will
# mess up the printed output. So, we redirect stdout to stderr
# and then make descriptor 3 go to stdout, and have Ghostscript
# write its output there. Exercise for the clever reader:
# capture the stderr output from Ghostscript and mail it back to
# the user originating the print job.
#
exec 3>&1 1>&2
/usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 \
-sOutputFile=/dev/fd/3 - && exit 0
#
/usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \
&& exit 0
else
#
# Plain text or HP/PCL, so just print it directly; print a form
# at the end to eject the last page.
#
echo $first_line && cat && printf "\033&l0H" && exit 0
fi
exit 2Finally, you need to notify LPD of the filter via the
if capability:
:if=/usr/local/libexec/hpif:That is it. You can type lpr plain.text and
lpr whatever.ps and both should print
successfully.Conversion FiltersAfter completing the simple setup described in Simple Printer Setup, the first
thing you will probably want to do is install conversion filters for
your favorite file formats (besides plain ASCII text).Why Install Conversion Filters?Conversion filters make printing various kinds of files easy.
As an example, suppose we do a lot of work with the TeX
typesetting system, and we have a PostScript printer. Every time
we generate a DVI file from TeX, we cannot print it directly until
we convert the DVI file into PostScript. The command sequence
goes like this:&prompt.user; dvips seaweed-analysis.dvi
&prompt.user; lpr seaweed-analysis.psBy installing a conversion filter for DVI files, we can skip
the hand conversion step each time by having LPD do it for us.
Now, each time we get a DVI file, we are just one step away from
printing it:&prompt.user; lpr -d seaweed-analysis.dviWe got LPD to do the DVI file conversion for us by specifying
the option. Section Formatting and Conversion
Options lists the conversion options.For each of the conversion options you want a printer to
support, install a conversion filter and
specify its pathname in /etc/printcap. A
conversion filter is like the text filter for the simple printer
setup (see section Installing
the Text Filter) except that instead of printing plain
text, the filter converts the file into a format the printer can
understand.Which Conversions Filters Should I Install?You should install the conversion filters you expect to use.
If you print a lot of DVI data, then a DVI conversion filter is in
order. If you have got plenty of troff to print out, then you
probably want a troff filter.The following table summarizes the filters that LPD works
with, their capability entries for the
/etc/printcap file, and how to invoke them
with the lpr command:File type/etc/printcap capabilitylpr optioncifplotcfDVIdfplotgfditroffnfFORTRAN textrftroffrfrastervfplain textifnone, , or
In our example, using lpr -d means the
printer needs a df capability in its entry in
/etc/printcap.Despite what others might contend, formats like FORTRAN text
and plot are probably obsolete. At your site, you can give new
meanings to these or any of the formatting options just by
installing custom filters. For example, suppose you would like to
directly print Printerleaf files (files from the Interleaf desktop
publishing program), but will never print plot files. You could
install a Printerleaf conversion filter under the
gf capability and then educate your users that
lpr -g mean “print Printerleaf
files.”Installing Conversion FiltersSince conversion filters are programs you install outside of
the base FreeBSD installation, they should probably go under
/usr/local. The directory
/usr/local/libexec is a popular location,
since they are specialized programs that only LPD will run;
regular users should not ever need to run them.To enable a conversion filter, specify its pathname under the
appropriate capability for the destination printer in
/etc/printcap.In our example, we will add the DVI conversion filter to the
entry for the printer named bamboo. Here is
the example /etc/printcap file again, with
the new df capability for the printer
bamboo.
#
# /etc/printcap for host rose - added df filter for bamboo
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:The DVI filter is a shell script named
/usr/local/libexec/psdf. Here is that
script:
#!bin/sh
#
# psdf - DVI to PostScript printer filter
# Installed in /usr/local/libexec/psdf
#
# Invoked by lpd when user runs lpr -d
#
exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@"This script runs dvips in filter mode (the
argument) on standard input, which is the job
to print. It then starts the PostScript printer filter
lprps (see section Accommodating Plain
Text Jobs on PostScript Printers) with the arguments LPD
passed to this script. lprps will use those
arguments to account for the pages printed.More Conversion Filter ExamplesSince there is no fixed set of steps to install conversion
filters, let me instead provide more examples. Use these as
guidance to making your own filters. Use them directly, if
appropriate.This example script is a raster (well, GIF file, actually)
conversion filter for a Hewlett Packard LaserJet III-Si
printer:
#!/bin/sh
#
# hpvf - Convert GIF files into HP/PCL, then print
# Installed in /usr/local/libexec/hpvf
PATH=/usr/X11R6/bin:$PATH; export PATH
giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \
&& exit 0 \
|| exit 2It works by converting the GIF file into a portable anymap,
converting that into a portable graymap, converting that into a
portable bitmap, and converting that into LaserJet/PCL-compatible
data.Here is the /etc/printcap file with an
entry for a printer using the above filter:
#
# /etc/printcap for host orchid
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/hpif:\
:vf=/usr/local/libexec/hpvf:The following script is a conversion filter for troff data
from the groff typesetting system for the PostScript printer named
bamboo:
#!/bin/sh
#
# pstf - Convert groff's troff data into PS, then print.
# Installed in /usr/local/libexec/pstf
#
exec grops | /usr/local/libexec/lprps "$@"The above script makes use of lprps again
to handle the communication with the printer. If the printer were
on a parallel port, we would use this script instead:
#!/bin/sh
#
# pstf - Convert groff's troff data into PS, then print.
# Installed in /usr/local/libexec/pstf
#
exec gropsThat is it. Here is the entry we need to add to
/etc/printcap to enable the filter:
:tf=/usr/local/libexec/pstf:Here is an example that might make old hands at FORTRAN blush.
It is a FORTRAN-text filter for any printer that can directly
print plain text. We will install it for the printer
teak:
#!/bin/sh
#
# hprf - FORTRAN text filter for LaserJet 3si:
# Installed in /usr/local/libexec/hprf
#
printf "\033&k2G" && fpr && printf "\033&l0H" && exit 0
exit 2And we will add this line to the
/etc/printcap for the printer
teak to enable this filter:
:rf=/usr/local/libexec/hprf:Here is one final, somewhat complex example. We will add a
DVI filter to the LaserJet printer teak
introduced earlier. First, the easy part: updating
/etc/printcap with the location of the DVI
filter:
:df=/usr/local/libexec/hpdf:Now, for the hard part: making the filter. For that, we need
a DVI-to-LaserJet/PCL conversion program. The FreeBSD ports
collection (see The Ports Collection)
has one: dvi2xx is the name of the package.
Installing this package gives us the program we need,
dvilj2p, which converts DVI into LaserJet IIp,
LaserJet III, and LaserJet 2000 compatible codes.dvilj2p makes the filter
hpdf quite complex since
dvilj2p cannot read from standard input. It
wants to work with a filename. What is worse, the filename has to
end in .dvi so using
/dev/fd/0 for standard input is problematic.
We can get around that problem by linking (symbolically) a
temporary file name (one that ends in .dvi)
to /dev/fd/0, thereby forcing
dvilj2p to read from standard input.The only other fly in the ointment is the fact that we cannot
use /tmp for the temporary link. Symbolic
links are owned by user and group bin. The
filter runs as user daemon. And the
/tmp directory has the sticky bit set. The
filter can create the link, but it will not be able clean up when
done and remove it since the link will belong to a different
user.Instead, the filter will make the symbolic link in the current
working directory, which is the spooling directory (specified by
the sd capability in
/etc/printcap). This is a perfect place for
filters to do their work, especially since there is (sometimes)
more free disk space in the spooling directory than under
/tmp.Here, finally, is the filter:
#!/bin/sh
#
# hpdf - Print DVI data on HP/PCL printer
# Installed in /usr/local/libexec/hpdf
PATH=/usr/local/bin:$PATH; export PATH
#
# Define a function to clean up our temporary files. These exist
# in the current directory, which will be the spooling directory
# for the printer.
#
cleanup() {
rm -f hpdf$$.dvi
}
#
# Define a function to handle fatal errors: print the given message
# and exit 2. Exiting with 2 tells LPD to do not try to reprint the
# job.
#
fatal() {
echo "$@" 1>&2
cleanup
exit 2
}
#
# If user removes the job, LPD will send SIGINT, so trap SIGINT
# (and a few other signals) to clean up after ourselves.
#
trap cleanup 1 2 15
#
# Make sure we are not colliding with any existing files.
#
cleanup
#
# Link the DVI input file to standard input (the file to print).
#
ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0"
#
# Make LF = CR+LF
#
printf "\033&k2G" || fatal "Cannot initialize printer"
#
# Convert and print. Return value from dvilj2p does not seem to be
# reliable, so we ignore it.
#
dvilj2p -M1 -q -e- dfhp$$.dvi
#
# Clean up and exit
#
cleanup
exit 0Automated Conversion: An Alternative To Conversion
FiltersAll these conversion filters accomplish a lot for your
printing environment, but at the cost forcing the user to specify
(on the &man.lpr.1; command line) which one to use.
If your users are not particularly computer literate, having to
specify a filter option will become annoying. What is worse,
though, is that an incorrectly specified filter option may run a
filter on the wrong type of file and cause your printer to spew
out hundreds of sheets of paper.Rather than install conversion filters at all, you might want
to try having the text filter (since it is the default filter)
detect the type of file it has been asked to print and then
automatically run the right conversion filter. Tools such as
file can be of help here. Of course, it will
be hard to determine the differences between
some file types—and, of course, you can
still provide conversion filters just for them.The FreeBSD ports collection has a text filter that performs
automatic conversion called apsfilter. It can
detect plain text, PostScript, and DVI files, run the proper
conversions, and print.Output FiltersThe LPD spooling system supports one other type of filter that
we have not yet explored: an output filter. An output filter is
intended for printing plain text only, like the text filter, but
with many simplifications. If you are using an output filter but no
text filter, then:LPD starts an output filter once for the entire job instead
of once for each file in the job.LPD does not make any provision to identify the start or the
end of files within the job for the output filter.LPD does not pass the user's login or host to the filter, so
it is not intended to do accounting. In fact, it gets only two
arguments:filter-name-wwidth-llengthWhere width is from the
pw capability and
length is from the
pl capability for the printer in
question.Do not be seduced by an output filter's simplicity. If you
would like each file in a job to start on a different page an output
filter will not work. Use a text filter (also
known as an input filter); see section Installing the Text Filter.
Furthermore, an output filter is actually more
complex in that it has to examine the byte stream being
sent to it for special flag characters and must send signals to
itself on behalf of LPD.However, an output filter is necessary if
you want header pages and need to send escape sequences or other
initialization strings to be able to print the header page. (But it
is also futile if you want to charge header
pages to the requesting user's account, since LPD does not give any
user or host information to the output filter.)On a single printer, LPD allows both an output filter and text
or other filters. In such cases, LPD will start the output filter
to print the header page (see section Header Pages)
only. LPD then expects the output filter to stop
itself by sending two bytes to the filter: ASCII 031
followed by ASCII 001. When an output filter sees these two bytes
(031, 001), it should stop by sending SIGSTOP to itself. When LPD's
done running other filters, it will restart the output filter by
sending SIGCONT to it.If there is an output filter but no text
filter and LPD is working on a plain text job, LPD uses the output
filter to do the job. As stated before, the output filter will
print each file of the job in sequence with no intervening form
feeds or other paper advancement, and this is probably
not what you want. In almost all cases, you
need a text filter.The program lpf, which we introduced earlier
as a text filter, can also run as an output filter. If you need a
quick-and-dirty output filter but do not want to write the byte
detection and signal sending code, try lpf. You
can also wrap lpf in a shell script to handle any
initialization codes the printer might require.lpf: a Text FilterThe program /usr/libexec/lpr/lpf that comes
with FreeBSD binary distribution is a text filter (input filter)
that can indent output (job submitted with lpr
-i), allow literal characters to pass (job submitted
with lpr -l), adjust the printing position for
backspaces and tabs in the job, and account for pages printed. It
can also act like an output filter.lpf is suitable for many printing
environments. And although it has no capability to send
initialization sequences to a printer, it is easy to write a shell
script to do the needed initialization and then execute
lpf.In order for lpf to do page accounting
correctly, it needs correct values filled in for the
pw and pl capabilities in the
/etc/printcap file. It uses these values to
determine how much text can fit on a page and how many pages were in
a user's job. For more information on printer accounting, see Accounting for Printer
Usage.Header PagesIf you have lots of users, all of them using
various printers, then you probably want to consider header
pages as a necessary evil.Header pages, also known as banner or
burst pages identify to whom jobs belong after
they are printed. They are usually printed in large, bold letters,
perhaps with decorative borders, so that in a stack of printouts they
stand out from the real documents that comprise users' jobs. They
enable users to locate their jobs quickly. The obvious drawback to a
header page is that it is yet one more sheet that has to be printed
for every job, their ephemeral usefulness lasting not more than a few
minutes, ultimately finding themselves in a recycling bin or rubbish
heap. (Note that header pages go with each job, not each file in a
job, so the paper waste might not be that bad.)The LPD system can provide header pages automatically for your
printouts if your printer can directly print
plain text. If you have a PostScript printer, you will need an
external program to generate the header page; see Header Pages on
PostScript Printers.Enabling Header PagesIn the Simple Printer
Setup, we turned off header pages by specifying
sh (meaning “suppress header”) in the
/etc/printcap file. To enable header pages for
a printer, just remove the sh capability.Sounds too easy, right?You are right. You might have to provide
an output filter to send initialization strings to the printer.
Here is an example output filter for Hewlett Packard PCL-compatible
printers:
#!/bin/sh
#
# hpof - Output filter for Hewlett Packard PCL-compatible printers
# Installed in /usr/local/libexec/hpof
printf "\033&k2G" || exit 2
exec /usr/libexec/lpr/lpfSpecify the path to the output filter in the
of capability. See Output Filters for more
information.Here is an example /etc/printcap file for
the printer teak that we introduced earlier; we
enabled header pages and added the above output filter:
#
# /etc/printcap for host orchid
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/hpif:\
:vf=/usr/local/libexec/hpvf:\
:of=/usr/local/libexec/hpof:Now, when users print jobs to teak, they get
a header page with each job. If users want to spend time searching
for their printouts, they can suppress header pages by submitting
the job with lpr -h; see Header Page Options for
more &man.lpr.1; options.LPD prints a form feed character after the header page. If
your printer uses a different character or sequence of characters
to eject a page, specify them with the ff
capability in /etc/printcap.Controlling Header PagesBy enabling header pages, LPD will produce a long
header, a full page of large letters identifying the
user, host, and job. Here is an example (kelly printed the job
named outline from host rose):
k ll ll
k l l
k l l
k k eeee l l y y
k k e e l l y y
k k eeeeee l l y y
kk k e l l y y
k k e e l l y yy
k k eeee lll lll yyy y
y
y y
yyyy
ll
t l i
t l
oooo u u ttttt l ii n nnn eeee
o o u u t l i nn n e e
o o u u t l i n n eeeeee
o o u u t l i n n e
o o u uu t t l i n n e e
oooo uuu u tt lll iii n n eeee
r rrr oooo ssss eeee
rr r o o s s e e
r o o ss eeeeee
r o o ss e
r o o s s e e
r oooo ssss eeee
Job: outline
Date: Sun Sep 17 11:04:58 1995LPD appends a form feed after this text so the job starts on a
new page (unless you have sf (suppress form
feeds) in the destination printer's entry in
/etc/printcap).If you prefer, LPD can make a short header;
specify sb (short banner) in the
/etc/printcap file. The header page will look
like this:
rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995Also by default, LPD prints the header page first, then the job.
To reverse that, specify hl (header last) in
/etc/printcap.Accounting for Header PagesUsing LPD's built-in header pages enforces a particular paradigm
when it comes to printer accounting: header pages must be
free of charge.Why?Because the output filter is the only external program that will
have control when the header page is printed that could do
accounting, and it is not provided with any user or
host information or an accounting file, so it has no
idea whom to charge for printer use. It is also not enough to just
“add one page” to the text filter or any of the
conversion filters (which do have user and host information) since
users can suppress header pages with lpr -h.
They could still be charged for header pages they did not print.
Basically, lpr -h will be the preferred option of
environmentally-minded users, but you cannot offer any incentive to
use it.It is still not enough to have each of the
filters generate their own header pages (thereby being able to
charge for them). If users wanted the option of suppressing the
header pages with lpr -h, they will still get
them and be charged for them since LPD does not pass any knowledge
of the option to any of the filters.So, what are your options?You can:Accept LPD's paradigm and make header pages free.Install an alternative to LPD, such as LPRng or PLP. Section
Alternatives to the
Standard Spooler tells more about other spooling
software you can substitute for LPD.Write a smart output filter. Normally,
an output filter is not meant to do anything more than
initialize a printer or do some simple character conversion. It
is suited for header pages and plain text jobs (when there is no
text (input) filter). But, if there is a text filter for the
plain text jobs, then LPD will start the output filter only for
the header pages. And the output filter can parse the header
page text that LPD generates to determine what user and host to
charge for the header page. The only other problem with this
method is that the output filter still does not know what
accounting file to use (it is not passed the name of the file
from the af capability), but if you have a
well-known accounting file, you can hard-code that into the
output filter. To facilitate the parsing step, use the
sh (short header) capability in
/etc/printcap. Then again, all that might
be too much trouble, and users will certainly appreciate the
more generous system administrator who makes header pages
free.Header Pages on PostScript PrintersAs described above, LPD can generate a plain text header page
suitable for many printers. Of course, PostScript cannot directly
print plain text, so the header page feature of LPD is
useless—or mostly so.One obvious way to get header pages is to have every conversion
filter and the text filter generate the header page. The filters
should should use the user and host arguments to generate a suitable
header page. The drawback of this method is that users will always
get a header page, even if they submit jobs with lpr
-h.Let us explore this method. The following script takes three
arguments (user login name, host name, and job name) and makes a
simple PostScript header page:
#!/bin/sh
#
# make-ps-header - make a PostScript header page on stdout
# Installed in /usr/local/libexec/make-ps-header
#
#
# These are PostScript units (72 to the inch). Modify for A4 or
# whatever size paper you are using:
#
page_width=612
page_height=792
border=72
#
# Check arguments
#
if [ $# -ne 3 ]; then
echo "Usage: `basename $0` <user> <host> <job>" 1>&2
exit 1
fi
#
# Save these, mostly for readability in the PostScript, below.
#
user=$1
host=$2
job=$3
date=`date`
#
# Send the PostScript code to stdout.
#
exec cat <<EOF
%!PS
%
% Make sure we do not interfere with user's job that will follow
%
save
%
% Make a thick, unpleasant border around the edge of the paper.
%
$border $border moveto
$page_width $border 2 mul sub 0 rlineto
0 $page_height $border 2 mul sub rlineto
currentscreen 3 -1 roll pop 100 3 1 roll setscreen
$border 2 mul $page_width sub 0 rlineto closepath
0.8 setgray 10 setlinewidth stroke 0 setgray
%
% Display user's login name, nice and large and prominent
%
/Helvetica-Bold findfont 64 scalefont setfont
$page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto
($user) show
%
% Now show the boring particulars
%
/Helvetica findfont 14 scalefont setfont
/y 200 def
[ (Job:) (Host:) (Date:) ] {
200 y moveto show /y y 18 sub def }
forall
/Helvetica-Bold findfont 14 scalefont setfont
/y 200 def
[ ($job) ($host) ($date) ] {
270 y moveto show /y y 18 sub def
} forall
%
% That is it
%
restore
showpage
EOFNow, each of the conversion filters and the text filter can call
this script to first generate the header page, and then print the
user's job. Here is the DVI conversion filter from earlier in this
document, modified to make a header page:
#!/bin/sh
#
# psdf - DVI to PostScript printer filter
# Installed in /usr/local/libexec/psdf
#
# Invoked by lpd when user runs lpr -d
#
orig_args="$@"
fail() {
echo "$@" 1>&2
exit 2
}
while getopts "x:y:n:h:" option; do
case $option in
x|y) ;; # Ignore
n) login=$OPTARG ;;
h) host=$OPTARG ;;
*) echo "LPD started `basename $0` wrong." 1>&2
exit 2
;;
esac
done
[ "$login" ] || fail "No login name"
[ "$host" ] || fail "No host name"
( /usr/local/libexec/make-ps-header $login $host "DVI File"
/usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_argsNotice how the filter has to parse the argument list in order to
determine the user and host name. The parsing for the other
conversion filters is identical. The text filter takes a slightly
different set of arguments, though (see section How Filters
Work).As we have mentioned before, the above scheme, though fairly
simple, disables the “suppress header page” option (the
option) to lpr. If users
wanted to save a tree (or a few pennies, if you charge for header
pages), they would not be able to do so, since every filter's going
to print a header page with every job.To allow users to shut off header pages on a per-job basis, you
will need to use the trick introduced in section Accounting for
Header Pages: write an output filter that parses the
LPD-generated header page and produces a PostScript version. If the
user submits the job with lpr -h, then LPD will
not generate a header page, and neither will your output filter.
Otherwise, your output filter will read the text from LPD and send
the appropriate header page PostScript code to the printer.If you have a PostScript printer on a serial line, you can make
use of lprps, which comes with an output filter,
psof, which does the above. Note that
psof does not charge for header pages.Networked PrintingFreeBSD supports networked printing: sending jobs to remote
printers. Networked printing generally refers to two different
things:Accessing a printer attached to a remote host. You install a
printer that has a conventional serial or parallel interface on
one host. Then, you set up LPD to enable access to the printer
from other hosts on the network. Section Printers Installed on
Remote Hosts tells how to do this.Accessing a printer attached directly to a network. The
printer has a network interface in addition (or in place of) a
more conventional serial or parallel interface. Such a printer
might work as follows:It might understand the LPD protocol and can even queue
jobs from remote hosts. In this case, it acts just like a
regular host running LPD. Follow the same procedure in
section Printers
Installed on Remote Hosts to set up such a
printer.It might support a data stream network connection. In this
case, you “attach” the printer to one host on the
network by making that host responsible for spooling jobs and
sending them to the printer. Section Printers with
Networked Data Stream Interfaces gives some
suggestions on installing such printers.Printers Installed on Remote HostsThe LPD spooling system has built-in support for sending jobs to
other hosts also running LPD (or are compatible with LPD). This
feature enables you to install a printer on one host and make it
accessible from other hosts. It also works with printers that have
network interfaces that understand the LPD protocol.To enable this kind of remote printing, first install a printer
on one host, the printer host, using the simple
printer setup described in Simple
Printer Setup. Do any advanced setup in Advanced Printer Setup that you
need. Make sure to test the printer and see if it works with the
features of LPD you have enabled. Also ensure that the
local host has authorization to use the LPD
service in the remote host (see Restricting Jobs
from Remote Printers).If you are using a printer with a network interface that is
compatible with LPD, then the printer host in
the discussion below is the printer itself, and the
printer name is the name you configured for the
printer. See the documentation that accompanied your printer and/or
printer-network interface.Then, on the other hosts you want to have access to the printer,
make an entry in their /etc/printcap files with
the following:Name the entry anything you want. For simplicity, though,
you probably want to use the same name and aliases as on the
printer host.Leave the lp capability blank, explicitly
(:lp=:).Make a spooling directory and specify its location in the
sd capability. LPD will store jobs here
before they get sent to the printer host.Place the name of the printer host in the
rm capability.Place the printer name on the printer
host in the rp
capability.That is it. You do not need to list conversion filters, page
dimensions, or anything else in the
/etc/printcap file.Here is an example. The host rose has two
printers, bamboo and rattan.
We will enable users on the host orchid to print to those printers.
Here is the /etc/printcap file for
orchid (back from section Enabling Header
Pages). It already had the entry for the printer
teak; we have added entries for the two printers
on the host rose:
#
# /etc/printcap for host orchid - added (remote) printers on rose
#
#
# teak is local; it is connected directly to orchid:
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/ifhp:\
:vf=/usr/local/libexec/vfhp:\
:of=/usr/local/libexec/ofhp:
#
# rattan is connected to rose; send jobs for rattan to rose:
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan:
#
# bamboo is connected to rose as well:
#
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:Then, we just need to make spooling directories on
orchid:&prompt.root; mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo
&prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo
&prompt.root; chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bambooNow, users on orchid can print to
rattan and bamboo. If, for
example, a user on orchid typed
&prompt.user; lpr -P bamboo -d sushi-review.dvi
the LPD system on orchid would copy the job to the spooling
directory /var/spool/lpd/bamboo and note that
it was a DVI job. As soon as the host rose has room in its
bamboo spooling directory, the two LPDs would
transfer the file to rose. The file would wait in rose's queue
until it was finally printed. It would be converted from DVI to
PostScript (since bamboo is a PostScript printer) on rose.Printers with Networked Data Stream InterfacesOften, when you buy a network interface card for a printer, you
can get two versions: one which emulates a spooler (the more
expensive version), or one which just lets you send data to it as if
you were using a serial or parallel port (the cheaper version).
This section tells how to use the cheaper version. For the more
expensive one, see the previous section Printers Installed on
Remote Hosts.The format of the /etc/printcap file lets
you specify what serial or parallel interface to use, and (if you
are using a serial interface), what baud rate, whether to use flow
control, delays for tabs, conversion of newlines, and more. But
there is no way to specify a connection to a printer that is
listening on a TCP/IP or other network port.To send data to a networked printer, you need to develop a
communications program that can be called by the text and conversion
filters. Here is one such example: the script
netprint takes all data on standard input and
sends it to a network-attached printer. We specify the hostname of
the printer as the first argument and the port number to which to
connect as the second argument to netprint. Note
that this supports one-way communication only (FreeBSD to printer);
many network printers support two-way communication, and you might
want to take advantage of that (to get printer status, perform
accounting, etc.).
#!/usr/bin/perl
#
# netprint - Text filter for printer attached to network
# Installed in /usr/local/libexec/netprint
#
$#ARGV eq 1 || die "Usage: $0 <printer-hostname> <port-number>";
$printer_host = $ARGV[0];
$printer_port = $ARGV[1];
require 'sys/socket.ph';
($ignore, $ignore, $protocol) = getprotobyname('tcp');
($ignore, $ignore, $ignore, $ignore, $address)
= gethostbyname($printer_host);
$sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address);
socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol)
|| die "Can't create TCP/IP stream socket: $!";
connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!";
while (<STDIN>) { print PRINTER; }
exit 0;We can then use this script in various filters. Suppose we had
a Diablo 750-N line printer connected to the network. The printer
accepts data to print on port number 5100. The host name of the
printer is scrivener. Here is the text filter for the
printer:
#!/bin/sh
#
# diablo-if-net - Text filter for Diablo printer `scrivener' listening
# on port 5100. Installed in /usr/local/libexec/diablo-if-net
#
exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100Restricting Printer UsageThis section gives information on restricting printer usage. The
LPD system lets you control who can access a printer, both locally or
remotely, whether they can print multiple copies, how large their jobs
can be, and how large the printer queues can get.Restricting Multiple CopiesThe LPD system makes it easy for users to print multiple copies
of a file. Users can print jobs with lpr -#5
(for example) and get five copies of each file in the job. Whether
this is a good thing is up to you.If you feel multiple copies cause unnecessary wear and tear on
your printers, you can disable the option to
&man.lpr.1; by adding the sc capability to the
/etc/printcap file. When users submit jobs
with the option, they will see:lpr: multiple copies are not allowedNote that if you have set up access to a printer remotely (see
section Printers
Installed on Remote Hosts), you need the
sc capability on the remote
/etc/printcap files as well, or else users will
still be able to submit multiple-copy jobs by using another
host.Here is an example. This is the
/etc/printcap file for the host
rose. The printer rattan is
quite hearty, so we will allow multiple copies, but the laser
printer bamboo's a bit more delicate, so we will
disable multiple copies by adding the sc
capability:
#
# /etc/printcap for host rose - restrict multiple copies on bamboo
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:Now, we also need to add the sc capability on
the host orchid's
/etc/printcap (and while we are at it, let us
disable multiple copies for the printer
teak):
#
# /etc/printcap for host orchid - no multiple copies for local
# printer teak or remote printer bamboo
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\
:if=/usr/local/libexec/ifhp:\
:vf=/usr/local/libexec/vfhp:\
:of=/usr/local/libexec/ofhp:
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc:By using the sc capability, we prevent the
use of lpr -#, but that still does not prevent
users from running &man.lpr.1;
multiple times, or from submitting the same file multiple times in
one job like this:&prompt.user; lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.signThere are many ways to prevent this abuse (including ignoring
it) which you are free to explore.Restricting Access To PrintersYou can control who can print to what printers by using the UNIX
group mechanism and the rg capability in
/etc/printcap. Just place the users you want
to have access to a printer in a certain group, and then name that
group in the rg capability.Users outside the group (including root) will be greeted with
lpr: Not a member of the restricted group
if they try to print to the controlled printer.As with the sc (suppress multiple copies)
capability, you need to specify rg on remote
hosts that also have access to your printers, if you feel it is
appropriate (see section Printers Installed on
Remote Hosts).For example, we will let anyone access the printer
rattan, but only those in group
artists can use bamboo. Here
is the familiar /etc/printcap for host
rose:
#
# /etc/printcap for host rose - restricted group for bamboo
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:Let us leave the other example
/etc/printcap file (for the host
orchid) alone. Of course, anyone on
orchid can print to bamboo. It
might be the case that we only allow certain logins on
orchid anyway, and want them to have access to the
printer. Or not.There can be only one restricted group per printer.Controlling Sizes of Jobs SubmittedIf you have many users accessing the printers, you probably need
to put an upper limit on the sizes of the files users can submit to
print. After all, there is only so much free space on the
filesystem that houses the spooling directories, and you also need
to make sure there is room for the jobs of other users.LPD enables you to limit the maximum byte size a file in a job
can be with the mx capability. The units are in
BUFSIZ blocks, which are 1024 bytes. If you put a zero for this
capability, there will be no limit on file size; however, if no
mx capability is specified, then a default limit
of 1000 blocks will be used.The limit applies to files in a job, and
not the total job size.LPD will not refuse a file that is larger than the limit you
place on a printer. Instead, it will queue as much of the file up
to the limit, which will then get printed. The rest will be
discarded. Whether this is correct behavior is up for
debate.Let us add limits to our example printers
rattan and bamboo. Since
those artists' PostScript files tend to be large, we will limit them
to five megabytes. We will put no limit on the plain text line
printer:
#
# /etc/printcap for host rose
#
#
# No limit on job size:
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:mx#0:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
#
# Limit of five megabytes:
#
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:Again, the limits apply to the local users only. If you have
set up access to your printers remotely, remote users will not get
those limits. You will need to specify the mx
capability in the remote /etc/printcap files as
well. See section Printers Installed on
Remote Hosts for more information on remote
printing.There is another specialized way to limit job sizes from remote
printers; see section Restricting Jobs
from Remote Printers.Restricting Jobs from Remote PrintersThe LPD spooling system provides several ways to restrict print
jobs submitted from remote hosts:Host restrictionsYou can control from which remote hosts a local LPD
accepts requests with the files
/etc/hosts.equiv and
/etc/hosts.lpd. LPD checks to see if an
incoming request is from a host listed in either one of these
files. If not, LPD refuses the request.The format of these files is simple: one host name per
line. Note that the file
/etc/hosts.equiv is also used by the
&man.ruserok.3; protocol, and affects programs like
&man.rsh.1; and &man.rcp.1;, so be careful.For example, here is the
/etc/hosts.lpd file on the host
rose:
orchid
violet
madrigal.fishbaum.deThis means rose will accept requests from
the hosts orchid, violet,
and madrigal.fishbaum.de. If any
other host tries to access rose's LPD, LPD
will refuse them.Size restrictionsYou can control how much free space there needs to remain
on the filesystem where a spooling directory resides. Make a
file called minfree in the spooling
directory for the local printer. Insert in that file a number
representing how many disk blocks (512 bytes) of free space
there has to be for a remote job to be accepted.This lets you insure that remote users will not fill your
filesystem. You can also use it to give a certain priority to
local users: they will be able to queue jobs long after the
free disk space has fallen below the amount specified in the
minfree file.For example, let us add a minfree
file for the printer bamboo. We examine
/etc/printcap to find the spooling
directory for this printer; here is bamboo's
entry:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:The spooling directory is the given in the
sd capability. We will make three
megabytes (which is 6144 disk blocks) the amount of free disk
space that must exist on the filesystem for LPD to accept
remote jobs:&prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfreeUser restrictionsYou can control which remote users can print to local
printers by specifying the rs capability in
/etc/printcap. When
rs appears in the entry for a
locally-attached printer, LPD will accept jobs from remote
hosts if the user submitting the job also
has an account of the same login name on the local host.
Otherwise, LPD refuses the job.This capability is particularly useful in an environment
where there are (for example) different departments sharing a
network, and some users transcend departmental boundaries. By
giving them accounts on your systems, they can use your
printers from their own departmental systems. If you would
rather allow them to use only your
printers and not your compute resources, you can give them
“token” accounts, with no home directory and a
useless shell like /usr/bin/false.Accounting for Printer UsageSo, you need to charge for printouts. And why not? Paper and ink
cost money. And then there are maintenance costs—printers are
loaded with moving parts and tend to break down. You have examined
your printers, usage patterns, and maintenance fees and have come up
with a per-page (or per-foot, per-meter, or per-whatever) cost. Now,
how do you actually start accounting for printouts?Well, the bad news is the LPD spooling system does not provide
much help in this department. Accounting is highly dependent on the
kind of printer in use, the formats being printed, and
your requirements in charging for printer
usage.To implement accounting, you have to modify a printer's text
filter (to charge for plain text jobs) and the conversion filters (to
charge for other file formats), to count pages or query the printer
for pages printed. You cannot get away with using the simple output
filter, since it cannot do accounting. See section Filters.Generally, there are two ways to do accounting:Periodic accounting is the more common
way, possibly because it is easier. Whenever someone prints a
job, the filter logs the user, host, and number of pages to an
accounting file. Every month, semester, year, or whatever time
period you prefer, you collect the accounting files for the
various printers, tally up the pages printed by users, and charge
for usage. Then you truncate all the logging files, starting with
a clean slate for the next period.Timely accounting is less common,
probably because it is more difficult. This method has the
filters charge users for printouts as soon as they use the
printers. Like disk quotas, the accounting is immediate. You can
prevent users from printing when their account goes in the red,
and might provide a way for users to check and adjust their
“print quotas.” But this method requires some database
code to track users and their quotas.The LPD spooling system supports both methods easily: since you
have to provide the filters (well, most of the time), you also have to
provide the accounting code. But there is a bright side: you have
enormous flexibility in your accounting methods. For example, you
choose whether to use periodic or timely accounting. You choose what
information to log: user names, host names, job types, pages printed,
square footage of paper used, how long the job took to print, and so
forth. And you do so by modifying the filters to save this
information.Quick and Dirty Printer AccountingFreeBSD comes with two programs that can get you set up with
simple periodic accounting right away. They are the text filter
lpf, described in section lpf: a Text Filter, and
&man.pac.8;, a program to gather and total
entries from printer accounting files.As mentioned in the section on filters (Filters), LPD starts
the text and the conversion filters with the name of the accounting
file to use on the filter command line. The filters can use this
argument to know where to write an accounting file entry. The name
of this file comes from the af capability in
/etc/printcap, and if not specified as an
absolute path, is relative to the spooling directory.LPD starts lpf with page width and length
arguments (from the pw and pl
capabilities). lpf uses these arguments to
determine how much paper will be used. After sending the file to
the printer, it then writes an accounting entry in the accounting
file. The entries look like this:
2.00 rose:andy
3.00 rose:kelly
3.00 orchid:mary
5.00 orchid:mary
2.00 orchid:zhangYou should use a separate accounting file for each printer, as
lpf has no file locking logic built into it, and
two lpfs might corrupt each other's entries if
they were to write to the same file at the same time. A easy way to
insure a separate accounting file for each printer is to use
af=acct in /etc/printcap.
Then, each accounting file will be in the spooling directory for a
printer, in a file named acct.When you are ready to charge users for printouts, run the
&man.pac.8; program. Just change to the spooling directory for
the printer you want to collect on and type pac.
You will get a dollar-centric summary like the following: Login pages/feet runs price
orchid:kelly 5.00 1 $ 0.10
orchid:mary 31.00 3 $ 0.62
orchid:zhang 9.00 1 $ 0.18
rose:andy 2.00 1 $ 0.04
rose:kelly 177.00 104 $ 3.54
rose:mary 87.00 32 $ 1.74
rose:root 26.00 12 $ 0.52
total 337.00 154 $ 6.74These are the arguments &man.pac.8; expects:Which printer to summarize.
This option works only if there is an absolute path in the
af capability in
/etc/printcap.Sort the output by cost instead of alphabetically by user
name.Ignore host name in the accounting files. With this
option, user smith on host
alpha is the same user
smith on host gamma.
Without, they are different users.Compute charges with price
dollars per page or per foot instead of the price from the
pc capability in
/etc/printcap, or two cents (the
default). You can specify price as
a floating point number.Reverse the sort order.Make an accounting summary file and truncate the
accounting file.name…Print accounting information for the given user
names only.In the default summary that &man.pac.8; produces, you see the
number of pages printed by each user from various hosts. If, at
your site, host does not matter (because users can use any host),
run pac -m, to produce the following
summary: Login pages/feet runs price
andy 2.00 1 $ 0.04
kelly 182.00 105 $ 3.64
mary 118.00 35 $ 2.36
root 26.00 12 $ 0.52
zhang 9.00 1 $ 0.18
total 337.00 154 $ 6.74To compute the dollar amount due,
&man.pac.8; uses the pc capability in the
/etc/printcap file (default of 200, or 2 cents
per page). Specify, in hundredths of cents, the price per page or
per foot you want to charge for printouts in this capability. You
can override this value when you run &man.pac.8; with the
option. The units for the
option are in dollars, though, not hundredths of cents. For
example,
&prompt.root; pac -p1.50
makes each page cost one dollar and fifty cents. You can really
rake in the profits by using this option.Finally, running pac -s will save the summary
information in a summary accounting file, which is named the same as
the printer's accounting file, but with _sum
appended to the name. It then truncates the accounting file. When
you run &man.pac.8; again, it rereads the
summary file to get starting totals, then adds information from the
regular accounting file.How Can You Count Pages Printed?In order to perform even remotely accurate accounting, you need
to be able to determine how much paper a job uses. This is the
essential problem of printer accounting.For plain text jobs, the problem's not that hard to solve: you
count how many lines are in a job and compare it to how many lines
per page your printer supports. Do not forget to take into account
backspaces in the file which overprint lines, or long logical lines
that wrap onto one or more additional physical lines.The text filter lpf (introduced in lpf: a Text Filter) takes
into account these things when it does accounting. If you are
writing a text filter which needs to do accounting, you might want
to examine lpf's source code.How do you handle other file formats, though?Well, for DVI-to-LaserJet or DVI-to-PostScript conversion, you
can have your filter parse the diagnostic output of
dvilj or dvips and look to see
how many pages were converted. You might be able to do similar
things with other file formats and conversion programs.But these methods suffer from the fact that the printer may not
actually print all those pages. For example, it could jam, run out
of toner, or explode—and the user would still get
charged.So, what can you do?There is only one sure way to do
accurate accounting. Get a printer that can
tell you how much paper it uses, and attach it via a serial line or
a network connection. Nearly all PostScript printers support this
notion. Other makes and models do as well (networked Imagen laser
printers, for example). Modify the filters for these printers to
get the page usage after they print each job and have them log
accounting information based on that value
only. There is no line counting nor
error-prone file examination required.Of course, you can always be generous and make all printouts
free.Alternatives to the Standard SpoolerIf you have been reading straight through this manual, by now you
have learned just about everything there is to know about the LPD
spooling system that comes with FreeBSD. You can probably appreciate
many of its shortcomings, which naturally leads to the question:
“What other spooling systems are out there (and work with
FreeBSD)?”Unfortunately, I have located only two
alternatives—and they are almost identical to each other! They
are:PLP, the Portable Line Printer Spooler SystemPLP was based on software developed by Patrick Powell and then
maintained by an Internet-wide group of developers. The main site
for the software is at ftp://ftp.iona.ie/pub/plp.
There is also a web
page.It is quite similar to the BSD LPD spooler, but boasts a
host of features, including:Better network support, including built-in support for
networked printers, NIS-maintained printcaps, and NFS-mounted
spooling directoriesSophisticated queue management, allowing multiple printers
on a queue, transfer of jobs between queues, and queue
redirectionRemote printer control functionsPrioritization of jobsExpansive security and access optionsLPRngLPRng, which purportedly means “LPR: the Next
Generation” is a complete rewrite of PLP. Patrick Powell
and Justin Mason (the principal maintainer of PLP) collaborated to
make LPRng. The main site for LPRng is ftp://dickory.sdsu.edu/pub/LPRng.AcknowledgmentsI would like to thank the following people who have assisted in the
development of this document:Daniel Eischen
deischen@iworks.interworks.orgFor providing a plethora of HP filter programs for
perusal.&a.jehamby;For the Ghostscript-to-HP filter.&a.jfieber; For debugging why printing from Windows 95 to a FreeBSD
system simulating a PostScript printer with Ghostscript didn't
produce correct output, and suggesting a fix, which is included
herein.Stephen Montgomery-Smith
stephen@math.missouri.eduFor suggesting using "\033&l0H" instead of "\f" to eject
the last page on HP printers; the latter could eject an extra
blank page while the former never does.My wife, Mary Kelly
urquhart@argyre.colorado.eduFor allowing me to spend more time with FreeBSD than
with her.
diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml
index 98e355eea3..3fa8f44a74 100644
--- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml
@@ -1,1612 +1,1612 @@
SecurityDES, MD5, and CryptContributed by &a.wollman; 24 September
1995.In order to protect the security of passwords on UN*X systems from
being easily exposed, passwords have traditionally been scrambled in
some way. Starting with Bell Labs' Seventh Edition Unix, passwords were
encrypted using what the security people call a “one-way hash
function”. That is to say, the password is transformed in such a
way that the original password cannot be regained except by brute-force
searching the space of possible passwords. Unfortunately, the only
secure method that was available to the AT&T researchers at the time
was based on DES, the Data Encryption Standard. This causes only
minimal difficulty for commercial vendors, but is a serious problem for
an operating system like FreeBSD where all the source code is freely
available, because national governments in many places like to place
restrictions on cross-border transport of DES and other encryption
software.So, the FreeBSD team was faced with a dilemma: how could we provide
compatibility with all those UNIX systems out there while still not
running afoul of the law? We decided to take a dual-track approach: we
would make distributions which contained only a non-regulated password
scrambler, and then provide as a separate add-on library the DES-based
password hash. The password-scrambling function was moved out of the C
library to a separate library, called libcrypt
because the name of the C function to implement it is
crypt. In FreeBSD 1.x and some pre-release 2.0
snapshots, the non-regulated scrambler uses an insecure function written
by Nate Williams; in subsequent releases this was replaced by a
mechanism using the RSA Data Security, Inc., MD5 one-way hash function.
Because neither of these functions involve encryption, they are believed
to be exportable from the US and importable into many other
countries.Meanwhile, work was also underway on the DES-based password hash
function. First, a version of the crypt function
which was written outside the US was imported, thus synchronizing the US
and non-US code. Then, the library was modified and split into two; the
DES libcrypt contains only the code involved in
performing the one-way password hash, and a separate
libcipher was created with the entry points to
actually perform encryption. The code was partitioned in this way to
make it easier to get an export license for the compiled library.Recognizing your crypt mechanismIt is fairly easy to recognize whether a particular password
string was created using the DES- or MD5-based hash function. MD5
password strings always begin with the characters
$1$. DES password strings do not have any
particular identifying characteristics, but they are shorter than MD5
passwords, and are coded in a 64-character alphabet which does not
include the $ character, so a relatively short
string which doesn't begin with a dollar sign is very likely a DES
password.Determining which library is being used on your system is fairly
easy for most programs, except for those like init
which are statically linked. (For those programs, the only way is to
try them on a known password and see if it works.) Programs which use
crypt are linked against
libcrypt, which for each type of library is a
symbolic link to the appropriate implementation. For example, on a
system using the DES versions:&prompt.user; ls -l /usr/lib/libcrypt*
lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a
lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0
lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.aOn a system using the MD5-based libraries, the same links will be
present, but the target will be libscrypt rather
than libdescrypt.S/KeyContributed by &a.wollman; 25 September
1995.S/Key is a one-time password scheme based on a one-way hash function
(in our version, this is MD4 for compatibility; other versions have used
MD5 and DES-MAC). S/Key has been a standard part of all FreeBSD
distributions since version 1.1.5, and is also implemented on a large
and growing number of other systems. S/Key is a registered trademark of
Bell Communications Research, Inc.There are three different sorts of passwords which we will talk
about in the discussion below. The first is your usual UNIX-style or
Kerberos password; we will call this a “UNIX password”. The
second sort is the one-time password which is generated by the S/Key
key program and accepted by the
keyinit program and the login prompt; we will call
this a “one-time password”. The final sort of password is
the secret password which you give to the key program
(and sometimes the keyinit program) which it uses to
generate one-time passwords; we will call it a “secret
password” or just unqualified “password”.The secret password does not necessarily have anything to do with
your UNIX password (while they can be the same, this is not
recommended). While UNIX passwords are limited to eight characters in
length, your S/Key secret password can be as long as you like; I use
seven-word phrases. In general, the S/Key system operates completely
independently of the UNIX password system.There are in addition two other sorts of data involved in the S/Key
system; one is called the “seed” or (confusingly)
“key”, and consists of two letters and five digits, and the
other is the “iteration count” and is a number between 100
and 1. S/Key constructs a one-time password from these components by
concatenating the seed and the secret password, then applying a one-way
hash (the RSA Data Security, Inc., MD4 secure hash function)
iteration-count times, and turning the result into six short English
words. The login and su programs
keep track of the last one-time password used, and the user is
authenticated if the hash of the user-provided password is equal to the
previous password. Because a one-way hash function is used, it is not
possible to generate future one-time passwords having overheard one
which was successfully used; the iteration count is decremented after
each successful login to keep the user and login program in sync. (When
you get the iteration count down to 1, it is time to reinitialize
S/Key.)There are four programs involved in the S/Key system which we will
discuss below. The key program accepts an iteration
count, a seed, and a secret password, and generates a one-time password.
The keyinit program is used to initialized S/Key, and
to change passwords, iteration counts, or seeds; it takes either a
secret password, or an iteration count, seed, and one-time password.
The keyinfo program examines the
/etc/skeykeys file and prints out the invoking
user's current iteration count and seed. Finally, the
login and su programs contain the
necessary logic to accept S/Key one-time passwords for authentication.
The login program is also capable of disallowing the
use of UNIX passwords on connections coming from specified
addresses.There are four different sorts of operations we will cover. The
first is using the keyinit program over a secure
connection to set up S/Key for the first time, or to change your
password or seed. The second operation is using the
keyinit program over an insecure connection, in
conjunction with the key program over a secure
connection, to do the same. The third is using the
key program to log in over an insecure connection.
The fourth is using the key program to generate a
number of keys which can be written down or printed out to carry with
you when going to some location without secure connections to anywhere
(like at a conference).Secure connection initializationTo initialize S/Key, change your password, or change your seed
while logged in over a secure connection (e.g., on the console of a
machine), use the keyinit command without any
parameters while logged in as yourself:&prompt.user; keyinit
Updating wollman: ) these will not appear if you
Old key: ha73895 ) have not used S/Key before
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password: ) I typed my pass phrase here
Again secret password: ) I typed it again ID
wollman s/key is 99 ha73896 ) discussed below SAG
HAS FONT GOUT FATE BOOM )There is a lot of information here. At theEnter secret
password: prompt, you should enter some password or phrase
(I use phrases of minimum seven words) which will be needed to
generate login keys. The line starting `ID' gives the parameters of
your particular S/Key instance: your login name, the iteration count,
and seed. When logging in with S/Key, the system will remember these
parameters and present them back to you so you do not have to remember
them. The last line gives the particular one-time password which
corresponds to those parameters and your secret password; if you were
to re-login immediately, this one-time password is the one you would
use.Insecure connection initializationTo initialize S/Key or change your password or seed over an
insecure connection, you will need to already have a secure connection
to some place where you can run the key program;
this might be in the form of a desk accessory on a Macintosh, or a
shell prompt on a machine you trust (we will show the latter). You
will also need to make up an iteration count (100 is probably a good
value), and you may make up your own seed or use a randomly-generated
one. Over on the insecure connection (to the machine you are
initializing), use the keyinit -s command:&prompt.user; keyinit -s
Updating wollman: Old key: kh94741
Reminder you need the 6 English words from the skey command.
Enter sequence count from 1 to 9999:100 ) I typed this
Enter new key [default kh94742]:
s/key 100 kh94742To accept the default seed (which the keyinit
program confusingly calls a key), press return.
Then move over to your secure connection or S/Key desk accessory, and
give it the same parameters:&prompt.user; key 100 kh94742
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
HULL NAY YANG TREE TOUT VETONow switch back over to the insecure connection, and copy the
one-time password generated by key over to the
keyinit program:s/key access password:HULL NAY YANG TREE TOUT VETO
ID wollman s/key is 100 kh94742
HULL NAY YANG TREE TOUT VETOThe rest of the description from the previous section applies here
as well.Diversion: a login promptBefore explaining how to generate one-time passwords, we should go
over an S/Key login prompt:&prompt.user; telnet himalia
Trying 18.26.0.186...
Connected to himalia.lcs.mit.edu.
Escape character is '^]'.
s/key 92 hi52030
Password:Note that, before prompting for a password, the login program
prints out the iteration number and seed which you will need in order
to generate the appropriate key. You will also find a useful feature
(not shown here): if you press return at the password prompt, the
login program will turn echo on, so you can see what you are typing.
This can be extremely useful if you are attempting to type in an S/Key
by hand, such as from a printout.If this machine were configured to disallow UNIX passwords over a
connection from my machine, the prompt would have also included the
annotation (s/key required), indicating that only
S/Key one-time passwords will be accepted.Generating a single one-time passwordNow, to generate the one-time password needed to answer this login
prompt, we use a trusted machine and the key
program. (There are versions of the key program
from DOS and Windows machines, and there is an S/Key desk accessory
for Macintosh computers as well.) The command-line
key program takes as its parameters the iteration
count and seed; you can cut-and-paste right from the login prompt
starting at key to the end of the line.
Thus:&prompt.user; key 92 hi52030 ) pasted from previous section
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
ADEN BED WOLF HAW HOT STUNAnd in the other window:s/key 92 hi52030 ) from previous section
Password:
(turning echo on)
Password:ADEN BED WOLF HAW HOT STUN
Last login: Wed Jun 28 15:31:00 from halloran-eldar.l
[etc.]This is the easiest mechanism if you have a
trusted machine. There is a Java S/Key key applet,
The Java OTP
Calculator, that you can download and run locally on any
Java supporting browser.Generating multiple one-time passwordsSometimes we have to go places where no trusted machines or
connections are available. In this case, it is possible to use the
key command to generate a number of one-time
passwords in the same command; these can then be printed out. For
example:&prompt.user; key -n 25 57 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
33: WALT THY MALI DARN NIT HEAD
34: ASK RICE BEAU GINA DOUR STAG
…
56: AMOS BOWL LUG FAT CAIN INCH
57: GROW HAYS TUN DISH CAR BALMThe requests twenty-five keys in sequence;
the indicates the ending
iteration number; and the rest is as before. Note that these are
printed out in reverse order of eventual use. If
you are really paranoid, you might want to write the results down by
hand; otherwise you can cut-and-paste into lpr.
Note that each line shows both the iteration count and the one-time
password; you may still find it handy to scratch off passwords as you
use them.Restricting use of UNIX passwordsThe configuration file /etc/skey.access can
be used to configure restrictions on the use of UNIX passwords based
on the host name, user name, terminal port, or IP address of a login
session. The complete format of the file is documented in the
&man.skey.access.5; manual page; there are also some security
cautions there which should be read before depending on this file for
security.If there is no /etc/skey.access file (which
is the default state as FreeBSD is shipped), then all users will be
allowed to use UNIX passwords. If the file exists, however, then all
users will be required to use S/Key unless explicitly permitted to do
otherwise by configuration statements in the
skey.access file. In all cases, UNIX passwords
are permitted on the console.Here is a sample configuration file which illustrates the three
most common sorts of configuration statements:
permit internet 18.26.0.0 255.255.0.0
permit user jrl
permit port ttyd0The first line (permit internet) allows users
whose IP source address (which is vulnerable to spoofing) matches the
specified value and mask, to use UNIX passwords. This should not be
considered a security mechanism, but rather, a means to remind
authorized users that they are using an insecure network and need to
use S/Key for authentication.The second line (permit user) allows the
specified user to use UNIX passwords at any time. Generally speaking,
this should only be used for people who are either unable to use the
key program, like those with dumb terminals, or
those who are uneducable.The third line (permit port) allows all users
logging in on the specified terminal line to use UNIX passwords; this
would be used for dial-ups.KerberosContributed by &a.markm; (based on contribution by
&a.md;).Kerberos is a network add-on system/protocol that allows users to
authenticate themselves through the services of a secure server.
Services such as remote login, remote copy, secure inter-system file
copying and other high-risk tasks are made considerably safer and more
controllable.The following instructions can be used as a guide on how to set up
Kerberos as distributed for FreeBSD. However, you should refer to the
relevant manual pages for a complete description.In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite,
distribution, but eBones, which had been previously ported to FreeBSD
1.1.5.1, and was sourced from outside the USA/Canada, and is thus
available to system owners outside those countries.For those needing to get a legal foreign distribution of this
software, please do not get it from a USA or Canada
site. You will get that site in big trouble! A
legal copy of this is available from ftp.internat.FreeBSD.org, which is in South
Africa and an official FreeBSD mirror site.Creating the initial databaseThis is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should change
to the directory /etc/kerberosIV and check that
only the following files are present:&prompt.root; cd /etc/kerberosIV
&prompt.root; ls
README krb.conf krb.realmsIf any additional files (such as principal.*
or master_key) exist, then use the
kdb_destroy command to destroy the old Kerberos
database, of if Kerberos is not running, simply delete the extra
files.You should now edit the krb.conf and
krb.realms files to define your Kerberos realm.
In this case the realm will be GRONDAR.ZA and the
server is grunt.grondar.za. We edit or create
the krb.conf file:&prompt.root; cat krb.conf
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.govIn this case, the other realms do not need to be there. They are
here as an example of how a machine may be made aware of multiple
realms. You may wish to not include them for simplicity.The first line names the realm in which this system works. The
other lines contain realm/host entries. The first item on a line is a
realm, and the second is a host in that realm that is acting as a
“key distribution centre”. The words admin
server following a hosts name means that host also
provides an administrative database server. For further explanation
of these terms, please consult the Kerberos man pages.Now we have to add grunt.grondar.za
to the GRONDAR.ZA realm and also add an entry to
put all hosts in the .grondar.za
domain in the GRONDAR.ZA realm. The
krb.realms file would be updated as
follows:&prompt.root; cat krb.realms
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDUAgain, the other realms do not need to be there. They are here as
an example of how a machine may be made aware of multiple realms. You
may wish to remove them to simplify things.The first line puts the specific system into
the named realm. The rest of the lines show how to default systems of
a particular subdomain to a named realm.Now we are ready to create the database. This only needs to run
on the Kerberos server (or Key Distribution Centre). Issue the
kdb_init command to do this:&prompt.root; kdb_initRealm name [default ATHENA.MIT.EDU ]:GRONDAR.ZA
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:Now we have to save the key so that servers on the local machine
can pick it up. Use the kstash command to do
this.&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!This saves the encrypted master password in
/etc/kerberosIV/master_key.Making it all runTwo principals need to be added to the database for
each system that will be secured with Kerberos.
Their names are kpasswd and rcmd
These two principals are made for each system, with the instance being
the name of the individual system.These daemons, kpasswd and
rcmd allow other systems to change Kerberos
passwords and run commands like rcp,
rlogin and rsh.Now let's add these entries:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:passwdInstance:grunt
<Not found>, Create [y] ?y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name:rcmdInstance:grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitCreating the server fileWe now have to extract all the instances which define the services
on each machine. For this we use the ext_srvtab
command. This will create a file which must be copied or moved
by secure means to each Kerberos client's
/etc/kerberosIV directory. This file must be present on each server
and client, and is crucial to the operation of Kerberos.&prompt.root; ext_srvtab gruntEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....Now, this command only generates a temporary file which must be
renamed to srvtab so that all the server can pick
it up. Use the mv command to move it into place on
the original system:&prompt.root; mv grunt-new-srvtab srvtabIf the file is for a client system, and the network is not deemed
safe, then copy the
client-new-srvtab to
removable media and transport it by secure physical means. Be sure to
rename it to srvtab in the client's
/etc/kerberosIV directory, and make sure it is
mode 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabPopulating the databaseWe now have to add some user entries into the database. First
let's create an entry for the user jane. Use the
kdb_edit command to do this:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitTesting it all outFirst we have to start the Kerberos daemons. NOTE that if you
have correctly edited your /etc/rc.conf then this
will happen automatically when you reboot. This is only necessary on
the Kerberos server. Kerberos clients will automagically get what
they need from the /etc/kerberosIV
directory.&prompt.root; kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
&prompt.root; kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!Now we can try using the kinit command to get a
ticket for the id jane that we created
above:&prompt.user; kinit jane
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane"
Password:Try listing the tokens using klist to see if we
really have them:&prompt.user; klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZANow try changing the password using passwd to
check if the kpasswd daemon can get authorization to the Kerberos
database:&prompt.user; passwd
realm GRONDAR.ZA
Old password for jane:New Password for jane:
Verifying password
New Password for jane:
Password changed.Adding su privilegesKerberos allows us to give each user who
needs root privileges their own separatesupassword. We could now add an id which is
authorized to su to root.
This is controlled by having an instance of root
associated with a principal. Using kdb_edit we can
create the entry jane.root in the Kerberos
database:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitNow try getting tokens for it to make sure it works:&prompt.root; kinit jane.root
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
Password:Now we need to add the user to root's .klogin
file:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZANow try doing the su:&prompt.user; suPassword:and take a look at what tokens we have:&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZAUsing other commandsIn an earlier example, we created a principal called
jane with an instance root.
This was based on a user with the same name as the principal, and this
is a Kerberos default; that a
<principal>.<instance> of the form
<username>.root will allow
that <username> to su to
root if the necessary entries are in the .klogin
file in root's home directory:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZALikewise, if a user has in their own home directory lines of the
form:&prompt.user; cat ~/.klogin
jane@GRONDAR.ZA
jack@GRONDAR.ZAThis allows anyone in the GRONDAR.ZA realm
who has authenticated themselves to jane or
jack (via kinit, see above)
access to rlogin to jane's
account or files on this system (grunt) via
rlogin, rsh or
rcp.For example, Jane now logs into another system, using
Kerberos:&prompt.user; kinit
MIT Project Athena (grunt.grondar.za)
Password:
%prompt.user; rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995Or Jack logs into Jane's account on the same machine (Jane having
set up the .klogin file as above, and the person
in charge of Kerberos having set up principal
jack with a null instance:&prompt.user; kinit
&prompt.user; rlogin grunt -l jane
MIT Project Athena (grunt.grondar.za)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995FirewallsContributed by &a.gpalmer; and &a.alex;.Firewalls are an area of increasing interest for people who are
connected to the Internet, and are even finding applications on private
networks to provide enhanced security. This section will hopefully
explain what firewalls are, how to use them, and how to use the
facilities provided in the FreeBSD kernel to implement them.People often think that having a firewall between your companies
internal network and the “Big Bad Internet” will solve all
your security problems.It may help, but a poorly setup firewall system is more of a
security risk than not having one at all. A firewall can only add
another layer of security to your systems, but they will not be able
to stop a really determined cracker from penetrating your internal
network. If you let internal security lapse because you believe your
firewall to be impenetrable, you have just made the crackers job that
bit easier.What is a firewall?There are currently two distinct types of firewalls in common use
on the Internet today. The first type is more properly called a
packet filtering router, where the kernel on a
multi-homed machine chooses whether to forward or block packets based
on a set of rules. The second type, known as proxy
servers, rely on daemons to provide authentication and to
forward packets, possibly on a multi-homed machine which has kernel
packet forwarding disabled.Sometimes sites combine the two types of firewalls, so that only a
certain machine (known as a bastion host) is
allowed to send packets through a packet filtering router onto an
internal network. Proxy services are run on the bastion host, which
are generally more secure than normal authentication
mechanisms.FreeBSD comes with a kernel packet filter (known as
IPFW), which is what the rest of this
section will concentrate on. Proxy servers can be built on FreeBSD
from third party software, but there is such a variety of proxy
servers available that it would be impossible to cover them in this
document.Packet filtering routersA router is a machine which forwards packets between two or more
networks. A packet filtering router has an extra piece of code in
its kernel, which compares each packet to a list of rules before
deciding if it should be forwarded or not. Most modern IP routing
software has packet filtering code in it, which defaults to
forwarding all packets. To enable the filters, you need to define a
set of rules for the filtering code, so that it can decide if the
packet should be allowed to pass or not.To decide if a packet should be passed on or not, the code looks
through its set of rules for a rule which matches the contents of
this packets headers. Once a match is found, the rule action is
obeyed. The rule action could be to drop the packet, to forward the
packet, or even to send an ICMP message back to the originator.
Only the first match counts, as the rules are searched in order.
Hence, the list of rules can be referred to as a “rule
chain”.The packet matching criteria varies depending on the software
used, but typically you can specify rules which depend on the source
IP address of the packet, the destination IP address, the source
port number, the destination port number (for protocols which
support ports), or even the packet type (UDP, TCP, ICMP,
etc).Proxy serversProxy servers are machines which have had the normal system
daemons (telnetd, ftpd, etc) replaced with special servers. These
servers are called proxy servers as they
normally only allow onward connections to be made. This enables you
to run (for example) a proxy telnet server on your firewall host,
and people can telnet in to your firewall from the outside, go
through some authentication mechanism, and then gain access to the
internal network (alternatively, proxy servers can be used for
signals coming from the internal network and heading out).Proxy servers are normally more secure than normal servers, and
often have a wider variety of authentication mechanisms available,
including “one-shot” password systems so that even if
someone manages to discover what password you used, they will not be
able to use it to gain access to your systems as the password
instantly expires. As they do not actually give users access to the
host machine, it becomes a lot more difficult for someone to install
backdoors around your security system.Proxy servers often have ways of restricting access further, so
that only certain hosts can gain access to the servers, and often
they can be set up so that you can limit which users can talk to
which destination machine. Again, what facilities are available
depends largely on what proxy software you choose.What does IPFW allow me to do?IPFW, the software supplied with
FreeBSD, is a packet filtering and accounting system which resides in
the kernel, and has a user-land control utility,
&man.ipfw.8;. Together, they allow you to define and query the
rules currently used by the kernel in its routing decisions.There are two related parts to IPFW.
The firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of your
router, based on similar rules to the firewall section. This allows
you to see (for example) how much traffic your router is getting from
a certain machine, or how much WWW (World Wide Web) traffic it is
forwarding.As a result of the way that IPFW is
designed, you can use IPFW on non-router
machines to perform packet filtering on incoming and outgoing
connections. This is a special case of the more general use of
IPFW, and the same commands and techniques
should be used in this situation.Enabling IPFW on FreeBSDAs the main part of the IPFW system
lives in the kernel, you will need to add one or more options to your
kernel configuration file, depending on what facilities you want, and
recompile your kernel. See reconfiguring
the kernel for more details on how to recompile your
kernel.There are currently three kernel configuration options relevant to
IPFW:options IPFIREWALLCompiles into the kernel the code for packet
filtering.options IPFIREWALL_VERBOSEEnables code to allow logging of packets through
&man.syslogd.8;. Without this option, even if you specify
that packets should be logged in the filter rules, nothing will
happen.options IPFIREWALL_VERBOSE_LIMIT=10Limits the number of packets logged through
&man.syslogd.8; on a per entry basis. You may wish to use
this option in hostile environments in which you want to log
firewall activity, but do not want to be open to a denial of
service attack via syslog flooding.When a chain entry reaches the packet limit specified,
logging is turned off for that particular entry. To resume
logging, you will need to reset the associated counter using the
&man.ipfw.8; utility:&prompt.root; ipfw zero 4500Where 4500 is the chain entry you wish to continue
logging.Previous versions of FreeBSD contained an
IPFIREWALL_ACCT option. This is now obsolete as
the firewall code automatically includes accounting
facilities.Configuring IPFWThe configuration of the IPFW software
is done through the &man.ipfw.8; utility. The syntax for this
command looks quite complicated, but it is relatively simple once you
understand its structure.There are currently four different command categories used by the
utility: addition/deletion, listing, flushing, and clearing.
Addition/deletion is used to build the rules that control how packets
are accepted, rejected, and logged. Listing is used to examine the
contents of your rule set (otherwise known as the chain) and packet
counters (accounting). Flushing is used to remove all entries from
the chain. Clearing is used to zero out one or more accounting
entries.Altering the IPFW rulesThe syntax for this form of the command is:
ipfw-NcommandindexactionlogprotocoladdressesoptionsThere is one valid flag when using this form of the
command:-NResolve addresses and service names in output.The command given can be shortened to the
shortest unique form. The valid commands
are:addAdd an entry to the firewall/accounting rule listdeleteDelete an entry from the firewall/accounting rule
listPrevious versions of IPFW used
separate firewall and accounting entries. The present version
provides packet accounting with each firewall entry.If an index value is supplied, it used to
place the entry at a specific point in the chain. Otherwise, the
entry is placed at the end of the chain at an index 100 greater than
the last chain entry (this does not include the default policy, rule
65535, deny).The log option causes matching rules to be
output to the system console if the kernel was compiled with
IPFIREWALL_VERBOSE.Valid actions are:rejectDrop the packet, and send an ICMP host or port unreachable
(as appropriate) packet to the source.allowPass the packet on as normal. (aliases:
pass and
accept)denyDrop the packet. The source is not notified via an
ICMP message (thus it appears that the packet never
arrived at the destination).countUpdate packet counters but do not allow/deny the packet
based on this rule. The search continues with the next chain
entry.Each action will be recognized by the
shortest unambiguous prefix.The protocols which can be specified
are:allMatches any IP packeticmpMatches ICMP packetstcpMatches TCP packetsudpMatches UDP packetsThe address specification is:fromaddress/maskporttoaddress/markportvia interfaceYou can only specify port in
conjunction with protocols which support ports
(UDP and TCP).The is optional and may specify the IP
address or domain name of a local IP interface, or an interface name
(e.g. ed0) to match only packets coming
through this interface. Interface unit numbers can be specified
with an optional wildcard. For example, ppp*
would match all kernel PPP interfaces.The syntax used to specify an
address/mask is:
address
or
address/mask-bits
or
address:mask-patternA valid hostname may be specified in place of the IP address.
is a decimal
number representing how many bits in the address mask should be set.
e.g. specifying 192.216.222.1/24 will create a
mask which will allow any address in a class C subnet (in this case,
192.216.222) to be matched.
is an IP
address which will be logically AND'ed with the address given. The
keyword any may be used to specify “any IP
address”.The port numbers to be blocked are specified as:
port,port,port…
to specify either a single port or a list of ports, or
port-port
to specify a range of ports. You may also combine a single range
with a list, but the range must always be specified first.The options available are:fragMatches if the packet is not the first fragment of the
datagram.inMatches if the packet is on the way in.outMatches if the packet is on the way out.ipoptions specMatches if the IP header contains the comma separated list
of options specified in spec. The
supported list of IP options are: ssrr
(strict source route), lsrr (loose source
route), rr (record packet route), and
ts (timestamp). The absence of a
particular option may be denoted with a leading
!.establishedMatches if the packet is part of an already established
TCP connection (i.e. it has the RST or ACK bits set). You can
optimize the performance of the firewall by placing
established rules early in the
chain.setupMatches if the packet is an attempt to establish a TCP
connection (the SYN bit set is set but the ACK bit is
not).tcpflags flagsMatches if the TCP header contains the comma separated
list of flags. The supported flags
are fin, syn,
rst, psh,
ack, and urg. The
absence of a particular flag may be indicated by a leading
!.icmptypes typesMatches if the ICMP type is present in the list
types. The list may be specified
as any combination of ranges and/or individual types separated
by commas. Commonly used ICMP types are: 0
echo reply (ping reply), 3 destination
unreachable, 5 redirect,
8 echo request (ping request), and
11 time exceeded (used to indicate TTL
expiration as with &man.traceroute.8;).Listing the IPFW rulesThe syntax for this form of the command is:
ipfw-a-t-NlThere are three valid flags when using this form of the
command:-aWhile listing, show counter values. This option is the
only way to see accounting counters.-tDisplay the last match times for each chain entry. The
time listing is incompatible with the input syntax used by the
&man.ipfw.8; utility.-NAttempt to resolve given addresses and service
names.Flushing the IPFW rulesThe syntax for flushing the chain is:
ipfwflushThis causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny policy
will leave your system cut off from the network until allow entries
are added to the chain.Clearing the IPFW packet countersThe syntax for clearing one or more packet counters is:
ipfwzeroindexWhen used without an index argument,
all packet counters are cleared. If an
index is supplied, the clearing operation
only affects a specific chain entry.Example commands for ipfwThis command will deny all packets from the host evil.crackers.org to the telnet port of the
host nice.people.org by being forwarded
by the router:&prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23The next example denies and logs any TCP traffic from the entire
crackers.org network (a class C) to
the nice.people.org machine (any
port).&prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.orgIf you do not want people sending X sessions to your internal
network (a subnet of a class C), the following command will do the
necessary filtering:&prompt.root; ipfw add deny tcp from any to my.org/28 6000 setupTo see the accounting records:
&prompt.root; ipfw -a list
or in the short form
&prompt.root; ipfw -a lYou can also see the last time a chain entry was matched
with:&prompt.root; ipfw -at lBuilding a packet filtering firewallThe following suggestions are just that: suggestions. The
requirements of each firewall are different and I cannot tell you
how to build a firewall to meet your particular requirements.When initially setting up your firewall, unless you have a test
bench setup where you can configure your firewall host in a controlled
environment, I strongly recommend you use the logging version of the
commands and enable logging in the kernel. This will allow you to
quickly identify problem areas and cure them without too much
disruption. Even after the initial setup phase is complete, I
recommend using the logging for of `deny' as it allows tracing of
possible attacks and also modification of the firewall rules if your
requirements alter.If you use the logging versions of the accept
command, it can generate large amounts of log
data as one log line will be generated for every packet that passes
through the firewall, so large ftp/http transfers, etc, will really
slow the system down. It also increases the latencies on those
packets as it requires more work to be done by the kernel before the
packet can be passed on. syslogd with also start using up a lot
more processor time as it logs all the extra data to disk, and it
could quite easily fill the partition /var/log
is located on.You should enable your firewall from
/etc/rc.conf.local or
/etc/rc.conf. The associated manpage explains
which knobs to fiddle and lists some preset firewall configurations.
If you do not use a preset configuration, ipfw list
will output the current ruleset into a file that you can
pass to rc.conf. If you do not use
/etc/rc.conf.local or
/etc/rc.conf to enable your firewall,
it is important to make sure your firewall is enabled before
any IP interfaces are configured.
The next problem is what your firewall should actually
do! This is largely dependent on what access to
your network you want to allow from the outside, and how much access
to the outside world you want to allow from the inside. Some general
rules are:Block all incoming access to ports below 1024 for TCP. This is
where most of the security sensitive services are, like finger,
SMTP (mail) and telnet.Block all incoming UDP traffic. There
are very few useful services that travel over UDP, and what useful
traffic there is is normally a security threat (e.g. Suns RPC and
NFS protocols). This has its disadvantages also, since UDP is a
connectionless protocol, denying incoming UDP traffic also blocks
the replies to outgoing UDP traffic. This can cause a problem for
people (on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you'll have to allow
packets coming from ports 191 and 1525 to any internal UDP port
through the firewall. ntp is another service you may consider
allowing through, which comes from port 123.Block traffic to port 6000 from the outside. Port 6000 is the
port used for access to X11 servers, and can be a security threat
(especially if people are in the habit of doing xhost
+ on their workstations). X11 can actually use a
range of ports starting at 6000, the upper limit being how many X
displays you can run on the machine. The upper limit as defined
by RFC 1700 (Assigned Numbers) is 6063.Check what ports any internal servers use (e.g. SQL servers,
etc). It is probably a good idea to block those as well, as they
normally fall outside the 1-1024 range specified above.Another checklist for firewall configuration is available from
CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filteringAs I said above, these are only guidelines.
You will have to decide what filter rules you want to use on your
firewall yourself. I cannot accept ANY responsibility if someone
breaks into your network, even if you follow the advice given
above.
diff --git a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
index 1d4f043139..c6f1b9c097 100644
--- a/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/serialcomms/chapter.sgml
@@ -1,2731 +1,2731 @@
Serial CommunicationsSerial BasicsAssembled from FAQ.This section should give you some general information about serial
ports. If you do not find what you want here, check into the Terminal
and Dialup sections of the handbook.The ttydX (or
cuaaX) device is the
regular device you will want to open for your applications. When a
process opens the device, it will have a default set of terminal I/O
settings. You can see these settings with the command&prompt.root; stty -a -f /dev/ttyd1When you change the settings to this device, the settings are in
effect until the device is closed. When it is reopened, it goes back to
the default set. To make changes to the default set, you can open and
adjust the settings of the “initial state” device. For
example, to turn on CLOCAL mode, 8 bits, and
XON/XOFF flow control by default for ttyd5,
do:&prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoffA good place to do this is in /etc/rc.serial.
Now, an application will have these settings by default when it opens
ttyd5. It can still change these settings to its
liking, though.You can also prevent certain settings from being changed by an
application by making adjustments to the “lock state”
device. For example, to lock the speed of ttyd5 to
57600 bps, do&prompt.root; stty -f /dev/ttyld5 57600Now, an application that opens ttyd5 and tries
to change the speed of the port will be stuck with 57600 bps.Naturally, you should make the initial state and lock state devices
writable only by root. The
MAKEDEV script does not do
this when it creates the device entries.TerminalsContributed by &a.kelly; 28 July 1996Terminals provide a convenient and low-cost way to access the power
of your FreeBSD system when you are not at the computer's console or on
a connected network. This section describes how to use terminals with
FreeBSD.Uses and Types of TerminalsThe original Unix systems did not have consoles. Instead, people
logged in and ran programs through terminals that were connected to
the computer's serial ports. It is quite similar to using a modem and
some terminal software to dial into a remote system to do text-only
work.Today's PCs have consoles capable of high quality graphics, but
the ability to establish a login session on a serial port still exists
in nearly every Unix-style operating system today; FreeBSD is no
exception. By using a terminal attached to a unused serial port, you
can log in and run any text program that you would normally run on the
console or in an xterm window in the X Window
System.For the business user, you can attach many terminals to a FreeBSD
system and place them on your employees' desktops. For a home user, a
spare computer such as an older IBM PC or a Macintosh can be a
terminal wired into a more powerful computer running FreeBSD. You can
turn what might otherwise be a single-user computer into a powerful
multiple user system.For FreeBSD, there are three kinds of terminals:Dumb terminalsPCs acting as terminalsX terminalsThe remaining subsections describe each kind.Dumb TerminalsDumb terminals are specialized pieces of hardware that let you
connect to computers over serial lines. They are called
“dumb” because they have only enough computational power
to display, send, and receive text. You cannot run any programs on
them. It is the computer to which you connect them that has all the
power to run text editors, compilers, email, games, and so
forth.There are hundreds of kinds of dumb terminals made by many
manufacturers, including Digital Equipment Corporation's VT-100 and
Wyse's WY-75. Just about any kind will work with FreeBSD. Some
high-end terminals can even display graphics, but only certain
software packages can take advantage of these advanced
features.Dumb terminals are popular in work environments where workers do
not need access to graphic applications such as those provided by
the X Window System.PCs Acting As TerminalsIf a dumb terminal has just
enough ability to display, send, and receive text, then certainly
any spare personal computer can be a dumb terminal. All you need is
the proper cable and some terminal emulation
software to run on the computer.Such a configuration is popular in homes. For example, if your
spouse is busy working on your FreeBSD system's console, you can do
some text-only work at the same time from a less powerful personal
computer hooked up as a terminal to the FreeBSD system.X TerminalsX terminals are the most sophisticated kind of terminal
available. Instead of connecting to a serial port, they usually
connect to a network like Ethernet. Instead of being relegated to
text-only applications, they can display any X application.We introduce X terminals just for the sake of completeness.
However, this chapter does not cover setup,
configuration, or use of X terminals.Cables and PortsTo connect a terminal to your FreeBSD system, you need the right
kind of cable and a serial port to which to connect it. This section
tells you what to do. If you are already familiar with your terminal
and the cable it requires, skip to Configuration.CablesBecause terminals use serial ports, you need to use
serial—also known as RS-232C—cables to connect the
terminal to the FreeBSD system.There are a couple of kinds of serial cables. Which one
you'll use depends on the terminal you want to connect:If you are connecting a personal computer to act as a
terminal, use a null-modem
cable. A null-modem cable connects two computers or terminals
together.If you have an actual terminal, your best source of
information on what cable to use is the documentation that
accompanied the terminal. If you do not have the documentation,
then try a null-modem cable.
If that does not work, then try a standard cable.Also, the serial port on both the terminal
and your FreeBSD system must have connectors that will fit the cable
you are using.Null-modem cablesA null-modem cable passes some signals straight through, like
“signal ground,” but switches other signals. For
example, the “send data” pin on one end goes to the
“receive data” pin on the other end.If you like making your own cables, here is a table showing a
recommended way to construct a null-modem cable for use with
terminals. This table shows the RS-232C signal names and the pin
numbers on a DB-25 connector.SignalPin #Pin #SignalTxD2connects to3RxDRxD3connects to2TxDDTR20connects to6DSRDSR6connects to20DTRSG7connects to7SGDCD8connects to4RTSRTS45CTSCTS5connects to8DCDFor DCD to RTS, connect pins 4 to 5 internally in the
connector hood, and then to pin 8 in the remote
hood.Standard RS-232C CablesA standard serial cable passes all the RS-232C signals
straight-through. That is, the “send data” pin on one
end of the cable goes to the “send data” pin on the
other end. This is the type of cable to connect a modem to your
FreeBSD system, and the type of cable needed for some
terminals.PortsSerial ports are the devices through which data is transferred
between the FreeBSD host computer and the terminal. This section
describes the kinds of ports that exist and how they are addressed
in FreeBSD.Kinds of PortsSeveral kinds of serial ports exist. Before you purchase or
construct a cable, you need to make sure it will fit the ports on
your terminal and on the FreeBSD system.Most terminals will have DB25 ports. Personal computers,
including PCs running FreeBSD, will have DB25 or DB9 ports. If you
have a multiport serial card for your PC, you may have RJ-12 or
RJ-45 ports.See the documentation that accompanied the hardware for
specifications on the kind of port in use. A visual inspection of
the port often works, too.Port NamesIn FreeBSD, you access each serial port through an entry in
the /dev directory. There are two different
kinds of entries:Callin ports are named
/dev/ttydX
where X is the port number,
starting from zero. Generally, you use the callin port for
terminals. Callin ports require that the serial line assert
the data carrier detect (DCD) signal to work.Callout ports are named
/dev/cuaaX.
You usually do not use the callout port for terminals, just
for modems. You may use the callout port if the serial cable
or the terminal does not support the carrier detect
signal.See the &man.sio.4; manual page for more information.If you have connected a terminal to the first serial port
(COM1 in DOS parlance), then you want to
use /dev/ttyd0 to refer to the terminal. If
it is on the second serial port (also known as
COM2), it is
/dev/ttyd1, and so forth.Note that you may have to configure your kernel to support
each serial port, especially if you have a multiport serial card.
See Configuring the FreeBSD
Kernel for more information.ConfigurationThis section describes what you need to configure on your FreeBSD
system to enable a login session on a terminal. It assumes you have
already configured your kernel to support the serial port to which the
terminal is connected—and that you have connected it.In a nutshell, you need to tell the init
process, which is responsible for process control and initialization,
to start a getty process, which is responsible for
reading a login name and starting the login
program.To do so, you have to edit the /etc/ttys
file. First, use the su command to become root.
Then, make the following changes to
/etc/ttys:Add an line to /etc/ttys for the entry in
the /dev directory for the serial port if it
is not already there.Specify that /usr/libexec/getty be run on
the port, and specify the appropriate
getty type from the
/etc/gettytab file.Specify the default terminal type.Set the port to “on.”Specify whether the port should be
“secure.”Force init to reread the
/etc/ttys file.As an optional step, you may wish to create a custom
getty type for use in step 2 by making an
entry in /etc/gettytab. This document does
not explain how to do so; you are encouraged to see the
&man.gettytab.5; and the &man.getty.8; manual pages for more
information.The remaining sections detail how to do these steps. We will use
a running example throughout these sections to illustrate what we need
to do. In our example, we will connect two terminals to the system: a
Wyse-50 and a old 286 IBM PC running Procomm terminal software
emulating a VT-100 terminal. We connect the Wyse to the second serial
port and the 286 to the sixth serial port (a port on a multiport
serial card).For more information on the /etc/ttys
file, see the &man.ttys.5; manual page.Adding an Entry to /etc/ttysFirst, you need to add an entry to the
/etc/ttys file, unless one is already
there.The /etc/ttys file lists all of the ports
on your FreeBSD system where you want to allow logins. For example,
the first virtual console ttyv0 has an entry in
this file. You can log in on the console using this entry. This
file contains entries for the other virtual consoles, serial ports,
and pseudo-ttys. For a hardwired terminal, just list the serial
port's /dev entry without the
/dev part.When you installed your FreeBSD system, the
/etc/ttys file included entries for the first
four serial ports: ttyd0 through
ttyd3. If you are attaching a terminal on one
of those ports, you do not need to add an entry.In our example, we attached a Wyse-50 to the second serial port,
ttyd1, which is already in the file. We need
to add an entry for the 286 PC connected to the sixth serial port.
Here is an excerpt of the /etc/ttys file after
we add the new entry:
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
ttyd5Specifying the getty TypeNext, we need to specify what program will be run to handle the
logins on a terminal. For FreeBSD, the standard program to do that
is /usr/libexec/getty. It is what provides the
login: prompt.The program getty takes one (optional)
parameter on its command line, the getty
type. A getty type tells about
characteristics on the terminal line, like bps rate and parity. The
getty program reads these characteristics from
the file /etc/gettytab.The file /etc/gettytab contains lots of
entries for terminal lines both old and new. In almost all cases,
the entries that start with the text std will
work for hardwired terminals. These entries ignore parity. There is
a std entry for each bps rate from 110 to 115200.
Of course, you can add your own entries to this file. The manual
page &man.gettytab.5; provides more
information.When setting the getty type in the
/etc/ttys file, make sure that the
communications settings on the terminal match.For our example, the Wyse-50 uses no parity and connects at
38400 bps. The 286 PC uses no parity and connects at 19200 bps.
Here is the /etc/ttys file so far (showing just
the two terminals in which we are interested):
ttyd1 "/usr/libexec/getty std.38400" unknown off secure
ttyd5 "/usr/libexec/getty std.19200"Note that the second field—where we specify what program
to run—appears in quotes. This is important, otherwise the
type argument to getty might be interpreted as
the next field.Specifying the Default Terminal TypeThe third field in the /etc/ttys file lists
the default terminal type for the port. For dialup ports, you
typically put unknown or
dialup in this field because users may dial up
with practically any kind of terminal or software. For hardwired
terminals, the terminal type does not change, so you can put a real
terminal type in this field.Users will usually use the tset program in
their .login or .profile
files to check the terminal type and prompt for one if necessary.
By setting a terminal type in the /etc/ttys
file, users can forego such prompting.To find out what terminal types FreeBSD supports, see the
file /usr/share/misc/termcap. It lists
about 600 terminal types. You can add more if you wish. See
the &man.termcap.5; manual page for information.In our example, the Wyse-50 is a Wyse-50 type of terminal
(although it can emulate others, we will leave it in Wyse-50 mode).
The 286 PC is running Procomm which will be set to emulate a VT-100.
Here are the pertinent yet unfinished entries from the
/etc/ttys file:
ttyd1 "/usr/libexec/getty std.38400" wy50 off secure
ttyd5 "/usr/libexec/getty std.19200" vt100Enabling the PortThe next field in /etc/ttys, the fourth
field, tells whether to enable the port. Putting
on here will have the init
process start the program in the second field,
getty, which will prompt for a login. If you put
off in the fourth field, there will be no
getty, and hence no logins on the port.So, naturally, you want an on in this field.
Here again is the /etc/ttys file. We have
turned each port on.
ttyd1 "/usr/libexec/getty std.38400" wy50 on secure
ttyd5 "/usr/libexec/getty std.19200" vt100 onSpecifying Secure PortsWe have arrived at the last field (well, almost: there is an
optional window specifier, but we will ignore
that). The last field tells whether the port is secure.What does “secure” mean?It means that the root account (or any account with a user ID of
0) may login on the port. Insecure ports do not allow root to
login.How do you use secure and insecure ports?By marking a port as insecure, the terminal to which it is
connected will not allow root to login. People who know the root
password to your FreeBSD system will first have to login using a
regular user account. To gain superuser privileges, they will then
have to use the su command.Because of this, you will have two records to help track down
possible compromises of root privileges: both the
login and the su command make
records in the system log (and logins are also recorded in the
wtmp file).By marking a port as secure, the terminal will allow root in.
People who know the root password will just login as root. You will
not have the potentially useful login and su
command records.Which should you use?Just use “insecure.” Use “insecure”
even for terminals not in
public user areas or behind locked doors. It is quite easy to login
and use su if you need superuser
privileges.Here finally are the completed entries in the
/etc/ttys file, with comments added to describe
where the terminals are:
ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen
ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroomForce init to Reread
/etc/ttysWhen you boot FreeBSD, the first process,
init, will read the
/etc/ttys file and start the programs listed
for each enabled port to prompt for logins.After you edit /etc/ttys, you do not want
to have to reboot your system to get init to see
the changes. So, init will reread
/etc/ttys if it receives a SIGHUP (hangup)
signal.So, after you have saved your changes to
/etc/ttys, send SIGHUP to
init by typing:&prompt.root; kill -HUP 1(The init process always
has process ID 1.)If everything is set up correctly, all cables are in place, and
the terminals are powered up, you should see login prompts. Your
terminals are ready for their first logins!Debugging your connectionEven with the most meticulous attention to detail, something could
still go wrong while setting up a terminal. Here is a list of
symptoms and some suggested fixes.No login prompt appearsMake sure the terminal is plugged in and powered up. If it
is a personal computer acting as a terminal, make sure it is
running terminal emulation software on the correct serial
port.Make sure the cable is connected firmly to both the terminal
and the FreeBSD computer. Make sure it is the right kind of
cable.Make sure the terminal and FreeBSD agree on the bps rate and
parity settings. If you have a video display terminal, make
sure the contrast and brightness controls are turned up. If it
is a printing terminal, make sure paper and ink are in good
supply.Make sure that a getty process is running
and serving the terminal. Type &prompt.root;
ps -axww|grep getty to get a
list of running getty processes. You should
see an entry for the terminal. For example, the display
22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1
shows that a getty is running on the second
serial port ttyd1 and is using the
std.38400 entry in
/etc/gettytab.If no getty process is running, make sure
you have enabled the port in /etc/ttys.
Make sure you have run kill -HUP 1.Garbage appears instead of a login promptMake sure the terminal and FreeBSD agree on the bps rate and
parity settings. Check the getty processes to make sure the
correct getty type is in use. If
not, edit /etc/ttys and run kill
-HUP 1.Characters appear doubled; the password appears when
typedSwitch the terminal (or the terminal emulation software)
from “half duplex” or “local echo” to
“full duplex.”Dialin ServiceContributed by &a.ghelmer;.This document provides suggestions for configuring a FreeBSD system
to handle dialup modems. This document is written based on the author's
experience with FreeBSD versions 1.0, 1.1, and 1.1.5.1 (and experience
with dialup modems on other UNIX-like operating systems); however, this
document may not answer all of your questions or provide examples
specific enough to your environment. The author cannot be responsible if
you damage your system or lose data due to attempting to follow the
suggestions here.PrerequisitesTo begin with, the author assumes you have some basic knowledge of
FreeBSD. You need to have FreeBSD installed, know how to edit files
in a UNIX-like environment, and how to look up manual pages on the
system. As discussed below, you will need certain versions of
FreeBSD, and knowledge of some terminology & modem and
cabling.FreeBSD VersionFirst, it is assumed that you are using FreeBSD version 1.1 or
higher (including versions 2.x). FreeBSD version 1.0 included two
different serial drivers, which complicates the situation. Also,
the serial device driver (sio) has improved
in every release of FreeBSD, so more recent versions of FreeBSD are
assumed to have better and more efficient drivers than earlier
versions.TerminologyA quick rundown of terminology:bpsBits per Second — the rate at which data is
transmittedDTEData Terminal Equipment — for example, your
computerDCEData Communications Equipment — your modemRS-232EIA standard for serial communications via hardwareIf you need more information about these terms and data
communications in general, the author remembers reading that
The RS-232 Bible (anybody have an ISBN?) is a
good reference.When talking about communications data rates, the author does
not use the term “baud”. Baud refers to the number of
electrical state transitions that may be made in a period of time,
while “bps” (bits per second) is the
“correct” term to use (at least it does not seem to
bother the curmudgeons quite a much).External vs. Internal ModemsExternal modems seem to be more convenient for dialup, because
external modems often can be semi-permanently configured via
parameters stored in non-volatile RAM and they usually provide
lighted indicators that display the state of important RS-232
signals. Blinking lights impress visitors, but lights are also very
useful to see whether a modem is operating properly.Internal modems usually lack non-volatile RAM, so their
configuration may be limited only to setting DIP switches. If your
internal modem has any signal indicator lights, it is probably
difficult to view the lights when the system's cover is in
place.Modems and CablesA background knowledge of these items is assumedYou know how to connect your modem to your computer so that
the two can communicate (unless you have an internal modem,
which does not need such a cable)You are familiar with your modem's command set, or know
where to look up needed commandsYou know how to configure your modem (probably via a
terminal communications program) so you can set the non-volatile
RAM parametersThe first, connecting your modem, is usually simple — most
straight-through serial cables work without any problems. You need
to have a cable with appropriate connectors (DB-25 or DB-9, male or
female) on each end, and the cable must be a DCE-to-DTE cable with
these signals wired:Transmitted Data (SD)Received Data (RD)Request to Send (RTS)Clear to Send (CTS)Data Set Ready (DSR)Data Terminal Ready (DTR)Carrier Detect (CD)Signal Ground (SG)FreeBSD needs the RTS and
CTS signals for flow-control at speeds above
2400bps, the CD signal to detect when a call has
been answered or the line has been hung up, and the
DTR signal to reset the modem after a session is
complete. Some cables are wired without all of the needed signals,
so if you have problems, such as a login session not going away when
the line hangs up, you may have a problem with your cable.The second prerequisite depends on the modem(s) you use. If you
do not know your modem's command set by heart, you will need to have
the modem's reference book or user's guide handy. Sample commands
for USR Sportster 14,400 external modems will be given, which you
may be able to use as a reference for your own modem's
commands.Lastly, you will need to know how to setup your modem so that it
will work well with FreeBSD. Like other UNIX-like operating
systems, FreeBSD uses the hardware signals to find out when a call
has been answered or a line has been hung up and to hangup and reset
the modem after a call. FreeBSD avoids sending commands to the
modem or watching for status reports from the modem. If you are
familiar with connecting modems to PC-based bulletin board systems,
this may seem awkward.Serial Interface ConsiderationsFreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based
EIA RS-232C (CCITT V.24) communications interfaces. The 8250 and
16450 devices have single-character buffers. The 16550 device
provides a 16-character buffer, which allows for better system
performance. (Bugs in plain 16550's prevent the use of the
16-character buffer, so use 16550A's if possible). Because
single-character-buffer devices require more work by the operating
system than the 16-character-buffer devices, 16550A-based serial
interface cards are much preferred. If the system has many active
serial ports or will have a heavy load, 16550A-based cards are
better for low-error-rate communications.Quick OverviewHere is the process that FreeBSD follows to accept dialup logins.
A getty process, spawned by
init, patiently waits to open the assigned serial
port (/dev/ttyd0, for our example). The command
ps ax might show this: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0When a user dials the modem's line and the modems connect, the
CD line is asserted by the modem. The kernel
notices that carrier has been detected and completes
getty's open of the port. getty
sends a login: prompt at the specified initial line
speed. getty watches to see if legitimate
characters are received, and, in a typical configuration, if it finds
junk (probably due to the modem's connection speed being different
than getty's speed), getty tries
adjusting the line speeds until it receives reasonable
characters.We hope getty finds the correct speed and the
user sees a login: prompt. After the user enters
his/her login name, getty executes
/usr/bin/login, which completes the login by
asking for the user's password and then starting the user's
shell.Let's dive into the configuration...Kernel ConfigurationFreeBSD kernels typically come prepared to search for four serial
ports, known in the PC-DOS world as COM1:,
COM2:, COM3:, and
COM4:. FreeBSD can presently also handle
“dumb” multiport serial interface cards, such as the Boca
Board 1008 and 2016 (please see the manual page &man.sio.4; for kernel
configuration information if you have a multiport serial card). The
default kernel only looks for the standard COM ports, though.To see if your kernel recognizes any of your serial ports, watch
for messages while the kernel is booting, or use the
/sbin/dmesg command to replay the kernel's boot
messages. In particular, look for messages that start with the
characters sio. Hint: to view just the messages
that have the word sio, use the command:&prompt.root; /sbin/dmesg | grep 'sio'For example, on a system with four serial ports, these are the
serial-port specific kernel boot messages:sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
sio2 at 0x3e8-0x3ef irq 5 on isa
sio2: type 16550A
sio3 at 0x2e8-0x2ef irq 9 on isa
sio3: type 16550AIf your kernel does not recognize all of your serial ports, you
will probably need to configure a custom FreeBSD kernel for your
system.Please see the BSD System Manager's Manual chapter on
“Building Berkeley Kernels with Config” [the source for
which is in /usr/src/share/doc/smm] and
“FreeBSD Configuration Options” [in
/sys/conf/options and in
/sys/arch/conf/options.arch,
with arch for example being
i386] for more information on configuring and
building kernels. You may have to unpack the kernel source
distribution if have not installed the system sources already
(srcdist/srcsys.?? in FreeBSD 1.1,
srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire
source distribution in FreeBSD 2.0) to be able to configure and build
kernels.Create a kernel configuration file for your system (if you have
not already) by cding to
/sys/i386/conf. Then, if you are creating a new
custom configuration file, copy the file
GENERICAH (or GENERICBT, if
you have a BusTek SCSI controller on FreeBSD 1.x) to
YOURSYS, where YOURSYS is
the name of your system, but in upper-case letters. Edit the file,
and change the device lines:
device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr
device sio3 at isa? port "IO_COM4" tty irq 9 vector siointrYou can comment-out or completely remove lines for devices you do
not have. If you have a multiport serial board, such as the Boca
Board BB2016, please see the &man.sio.4; man page for complete
information on how to write configuration lines for multiport boards.
Be careful if you are using a configuration file that was previously
used for a different version of FreeBSD because the device flags have
changed between versions.port "IO_COM1" is a substitution for
port 0x3f8, IO_COM2 is
0x2f8, IO_COM3 is
0x3e8, and IO_COM4 is
0x2e8, which are fairly common port addresses for
their respective serial ports; interrupts 4, 3, 5, and 9 are fairly
common interrupt request lines. Also note that regular serial ports
cannot share interrupts on ISA-bus PCs
(multiport boards have on-board electronics that allow all the
16550A's on the board to share one or two interrupt request
lines).When you are finished adjusting the kernel configuration file, use
the program config as documented in “Building
Berkeley Kernels with Config” and the
&man.config.8; manual page to prepare a kernel building directory,
then build, install, and test the new kernel.Device Special FilesMost devices in the kernel are accessed through “device
special files”, which are located in the
/dev directory. The sio
devices are accessed through the
/dev/ttyd? (dial-in)
and /dev/cua0?
(call-out) devices. On FreeBSD version 1.1.5 and higher, there are
also initialization devices
(/dev/ttyid? and
/dev/cuai0?) and
locking devices
(/dev/ttyld? and
/dev/cual0?). The
initialization devices are used to initialize communications port
parameters each time a port is opened, such as
crtscts for modems which use
CTS/RTS signaling for flow control. The locking
devices are used to lock flags on ports to prevent users or programs
changing certain parameters; see the manual pages &man.termios.4;,
&man.sio.4;, and &man.stty.1; for
information on the terminal settings, locking & initializing
devices, and setting terminal options, respectively.Making Device Special FilesA shell script called MAKEDEV in the
/dev directory manages the device special
files. (The manual page for &man.MAKEDEV.8; on FreeBSD 1.1.5 is
fairly bogus in its discussion of COM ports, so
ignore it.) To use MAKEDEV to make dialup device
special files for COM1: (port 0),
cd to /dev and issue the
command MAKEDEV ttyd0. Likewise, to make dialup
device special files for COM2: (port 1),
use MAKEDEV ttyd1.MAKEDEV not only creates the
/dev/ttyd? device
special files, but also creates the
/dev/cua0? (and all
of the initializing and locking special files under FreeBSD 1.1.5
and up) and removes the hardwired terminal special file
/dev/tty0?, if it
exists.After making new device special files, be sure to check the
permissions on the files (especially the
/dev/cua* files) to make sure that only users
who should have access to those device special files can read &
write on them — you probably do not want to allow your average
user to use your modems to dialout. The default permissions on the
/dev/cua* files should be sufficient:crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01
crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01
crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01These permissions allow the user uucp and
users in the group dialer to use the call-out
devices.Configuration FilesThere are three system configuration files in the
/etc directory that you will probably need to
edit to allow dialup access to your FreeBSD system. The first,
/etc/gettytab, contains configuration information
for the /usr/libexec/getty daemon. Second,
/etc/ttys holds information that tells
/sbin/init what tty devices
should have getty processes running on them.
Lastly, you can place port initialization commands in the
/etc/rc.serial script if you have FreeBSD 1.1.5.1
or higher; otherwise, you can initialize ports in the
/etc/rc.local script.There are two schools of thought regarding dialup modems on UNIX.
One group likes to configure their modems and system so that no matter
at what speed a remote user dials in, the local computer-to-modem
RS-232 interface runs at a locked speed. The benefit of this
configuration is that the remote user always sees a system login
prompt immediately. The downside is that the system does not know
what a user's true data rate is, so full-screen programs like Emacs
will not adjust their screen-painting methods to make their response
better for slower connections.The other school configures their modems' RS-232 interface to vary
its speed based on the remote user's connection speed. For example,
V.32bis (14.4 Kbps) connections to the modem might make the modem run
its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the
modem's RS-232 interface run at 2400 bps. Because
getty does not understand any particular modem's
connection speed reporting, getty gives a
login: message at an initial speed and watches the
characters that come back in response. If the user sees junk, it is
assumed that they know they should press the
<Enter> key until they see a recognizable
prompt. If the data rates do not match, getty sees
anything the user types as “junk”, tries going to the next
speed and gives the login: prompt again. This
procedure can continue ad nauseum, but normally only takes a keystroke
or two before the user sees a good prompt. Obviously, this login
sequence does not look as clean as the former
“locked-speed” method, but a user on a low-speed
connection should receive better interactive response from full-screen
programs.The author will try to give balanced configuration information,
but is biased towards having the modem's data rate follow the
connection rate./etc/gettytab/etc/gettytab is a &man.termcap.5;-style
file of configuration information for &man.getty.8;. Please see the
&man.gettytab.5; manual page for complete information on the
format of the file and the list of capabilities.Locked-Speed ConfigIf you are locking your modem's data communications rate at a
particular speed, you probably will not need to make any changes
to /etc/gettytab.Matching-Speed ConfigYou will need to setup an entry in
/etc/gettytab to give
getty information about the speeds you wish to
use for your modem. If you have a 2400 bps modem, you can
probably use the existing D2400 entry. This
entry already exists in the FreeBSD 1.1.5.1
gettytab file, so you do not need to add it
unless it is missing under your version of FreeBSD:
#
# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
#
D2400|d2400|Fast-Dial-2400:\
:nx=D1200:tc=2400-baud:
3|D1200|Fast-Dial-1200:\
:nx=D300:tc=1200-baud:
5|D300|Fast-Dial-300:\
:nx=D2400:tc=300-baud:If you have a higher speed modem, you will probably need to
add an entry in /etc/gettytab; here is an
entry you could use for a 14.4 Kbps modem with a top interface
speed of 19.2 Kbps:
#
# Additions for a V.32bis Modem
#
um|V300|High Speed Modem at 300,8-bit:\
:nx=V19200:tc=std.300:
un|V1200|High Speed Modem at 1200,8-bit:\
:nx=V300:tc=std.1200:
uo|V2400|High Speed Modem at 2400,8-bit:\
:nx=V1200:tc=std.2400:
up|V9600|High Speed Modem at 9600,8-bit:\
:nx=V2400:tc=std.9600:
uq|V19200|High Speed Modem at 19200,8-bit:\
:nx=V9600:tc=std.19200:On FreeBSD 1.1.5 and later, this will result in 8-bit, no
parity connections. Under FreeBSD 1.1, add
:np: parameters to the
std.xxx entries at
the top of the file for 8 bits, no parity; otherwise, the default
is 7 bits, even parity.The example above starts the communications rate at 19.2 Kbps
(for a V.32bis connection), then cycles through 9600 bps (for
V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps.
Communications rate cycling is implemented with the
nx= (“next table”) capability.
Each of the lines uses a tc= (“table
continuation”) entry to pick up the rest of the
“standard” settings for a particular data rate.If you have a 28.8 Kbps modem and/or you want to take
advantage of compression on a 14.4 Kbps modem, you need to use a
higher communications rate than 19.2 Kbps. Here is an example of
a gettytab entry starting a 57.6 Kbps:
#
# Additions for a V.32bis or V.34 Modem
# Starting at 57.6 Kbps
#
vm|VH300|Very High Speed Modem at 300,8-bit:\
:nx=VH57600:tc=std.300:
vn|VH1200|Very High Speed Modem at 1200,8-bit:\
:nx=VH300:tc=std.1200:
vo|VH2400|Very High Speed Modem at 2400,8-bit:\
:nx=VH1200:tc=std.2400:
vp|VH9600|Very High Speed Modem at 9600,8-bit:\
:nx=VH2400:tc=std.9600:
vq|VH57600|Very High Speed Modem at 57600,8-bit:\
:nx=VH9600:tc=std.57600:If you have a slow CPU or a heavily loaded system and you do
not have 16550A-based serial ports, you may receive sio
“silo” errors at 57.6 Kbps./etc/ttys/etc/ttys is the list of
ttys for init to monitor.
/etc/ttys also provides security information to
login (user root may only
login on ttys marked secure). See the manual
page for
&man.ttys.5; for more information.You will need to either modify existing lines in
/etc/ttys or add new lines to make
init run getty processes
automatically on your new dialup ports. The general format of the
line will be the same, whether you are using a locked-speed or
matching-speed configuration:
ttyd0 "/usr/libexec/getty xxx" dialup onThe first item in the above line is the device special file for
this entry — ttyd0 means
/dev/ttyd0 is the file that this
getty will be watching. The second item,
"/usr/libexec/getty
xxx"
(xxx will be replaced by the initial
gettytab capability) is the process
init will run on the device. The third item,
dialup, is the default terminal type. The fourth
parameter, on, indicates to
init that the line is operational. There can be
a fifth parameter, secure, but it should only be
used for terminals which are physically secure (such as the system
console).The default terminal type (dialup in the
example above) may depend on local preferences.
dialup is the traditional default terminal type
on dialup lines so that users may customize their login scripts to
notice when the terminal is dialup and
automatically adjust their terminal type. However, the author finds
it easier at his site to specify vt102 as the
default terminal type, since the users just use VT102 emulation on
their remote systems.After you have made changes to /etc/ttys,
you may send the init process a
HUP signal to re-read the file. You can use the
command &prompt.root; kill -1
1 to send the signal. If this is your
first time setting up the system, though, you may want to wait until
your modem(s) are properly configured and connected before signaling
init.Locked-Speed ConfigFor a locked-speed configuration, your
ttys entry needs to have a fixed-speed entry
provided to getty. For a modem whose port
speed is locked at 19.2 Kbps, the ttys entry
might look like this:
ttyd0 "/usr/libexec/getty std.19200" dialup onIf your modem is locked at a different data rate, substitute
the appropriate name for the
std.speed entry for
std.19200 from
/etc/gettytab for your modem's data
rate.Matching-Speed ConfigIn a matching-speed configuration, your
ttys entry needs to reference the appropriate
beginning “auto-baud” (sic) entry in
/etc/gettytab. For example, if you added the
above suggested entry for a matching-speed modem that starts at
19.2 Kbps (the gettytab entry containing the
V19200 starting point), your
ttys entry might look like this:
ttyd0 "/usr/libexec/getty V19200" dialup on/etc/rc.serial or
/etc/rc.localHigh-speed modems, like V.32, V.32bis, and V.34 modems, need to
use hardware (RTS/CTS) flow control. You can
add stty commands to
/etc/rc.serial on FreeBSD 1.1.5.1 and up, or
/etc/rc.local on FreeBSD 1.1, to set the
hardware flow control flag in the FreeBSD kernel for the modem
ports.For example, on a sample FreeBSD 1.1.5.1 system,
/etc/rc.serial reads:
#!/bin/sh
#
# Serial port initial configuration
stty -f /dev/ttyid1 crtscts
stty -f /dev/cuai01 crtsctsThis sets the termios flag
crtscts on serial port #1's
(COM2:) dialin and dialout initialization
devices.On an old FreeBSD 1.1 system, these entries were added to
/etc/rc.local to set the
crtscts flag on the devices:
# Set serial ports to use RTS/CTS flow control
stty -f /dev/ttyd0 crtscts
stty -f /dev/ttyd1 crtscts
stty -f /dev/ttyd2 crtscts
stty -f /dev/ttyd3 crtsctsSince there is no initialization device special file on FreeBSD
1.1, one has to just set the flags on the sole device special file
and hope the flags are not cleared by a miscreant.Modem SettingsIf you have a modem whose parameters may be permanently set in
non-volatile RAM, you will need to use a terminal program (such as
Telix under PC-DOS or tip under FreeBSD) to set the
parameters. Connect to the modem using the same communications speed
as the initial speed getty will use and configure
the modem's non-volatile RAM to match these requirements:CD asserted when connectedDTR asserted for operation; dropping DTR
hangs up line & resets modemCTS transmitted data flow controlDisable XON/XOFF flow controlRTS received data flow controlQuiet mode (no result codes)No command echoPlease read the documentation for your modem to find out what
commands and/or DIP switch settings you need to give it.For example, to set the above parameters on a USRobotics
Sportster 14,400 external modem, one could give these commands to
the modem:
ATZ
AT&C1&D2&H1&I0&R2&WYou might also want to take this opportunity to adjust other
settings in the modem, such as whether it will use V.42bis and/or MNP5
compression.The USR Sportster 14,400 external modem also has some DIP switches
that need to be set; for other modems, perhaps you can use these
settings as an example:Switch 1: UP — DTR NormalSwitch 2: Do not care (Verbal Result Codes/Numeric Result
Codes)Switch 3: UP — Suppress Result CodesSwitch 4: DOWN — No echo, offline commandsSwitch 5: UP — Auto AnswerSwitch 6: UP — Carrier Detect NormalSwitch 7: UP — Load NVRAM DefaultsSwitch 8: Do not care (Smart Mode/Dumb Mode)Result codes should be disabled/suppressed for dialup modems to
avoid problems that can occur if getty mistakenly
gives a login: prompt to a modem that is in command
mode and the modem echoes the command or returns a result code. I
have heard this sequence can result in a extended, silly conversation
between getty and the modem.Locked-speed ConfigFor a locked-speed configuration, you will need to configure the
modem to maintain a constant modem-to-computer data rate independent
of the communications rate. On a USR Sportster 14,400 external
modem, these commands will lock the modem-to-computer data rate at
the speed used to issue the commands:
ATZ
AT&B1&WMatching-speed ConfigFor a variable-speed configuration, you will need to configure
your modem to adjust its serial port data rate to match the incoming
call rate. On a USR Sportster 14,400 external modem, these commands
will lock the modem's error-corrected data rate to the speed used to
issue the commands, but allow the serial port rate to vary for
non-error-corrected connections:
ATZ
AT&B2&WChecking the Modem's ConfigurationMost high-speed modems provide commands to view the modem's
current operating parameters in a somewhat human-readable fashion.
On the USR Sportster 14,400 external modems, the command
ATI5 displays the settings that are stored in the
non-volatile RAM. To see the true operating parameters of the modem
(as influenced by the USR's DIP switch settings), use the commands
ATZ and then ATI4.If you have a different brand of modem, check your modem's
manual to see how to double-check your modem's configuration
parameters.TroubleshootingHere are a few steps you can follow to check out the dialup modem
on your system.Checking out the FreeBSD systemHook up your modem to your FreeBSD system, boot the system, and,
if your modem has status indication lights, watch to see whether the
modem's DTR indicator lights when the
login: prompt appears on the system's console
— if it lights up, that should mean that FreeBSD has started a
getty process on the appropriate communications
port and is waiting for the modem to accept a call.If the DTR indicator doesn't light, login to
the FreeBSD system through the console and issue a ps
ax to see if FreeBSD is trying to run a
getty process on the correct port. You should see
a lines like this among the processes displayed: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0
115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0and the modem has not accepted a call yet, this means that
getty has completed its open on the
communications port. This could indicate a problem with the cabling
or a mis-configured modem, because getty should
not be able to open the communications port until
CD (carrier detect) has been asserted by the
modem.If you do not see any getty processes waiting
to open the desired
ttyd? port,
double-check your entries in /etc/ttys to see
if there are any mistakes there. Also, check the log file
/var/log/messages to see if there are any log
messages from init or getty
regarding any problems. If there are any messages, triple-check the
configuration files /etc/ttys and
/etc/gettytab, as well as the appropriate
device special files /dev/ttyd?, for any
mistakes, missing entries, or missing device special files.Try Dialing InTry dialing into the system; be sure to use 8 bits, no parity, 1
stop bit on the remote system. If you do not get a prompt right
away, or get garbage, try pressing <Enter>
about once per second. If you still do not see a
login: prompt after a while, try sending a
BREAK. If you are using a high-speed modem to do
the dialing, try dialing again after locking the dialing modem's
interface speed (via AT&B1 on a USR
Sportster, for example).If you still cannot get a login: prompt, check
/etc/gettytab again and double-check
thatThe initial capability name specified in
/etc/ttys for the line matches a name of a
capability in /etc/gettytabEach nx= entry matches another
gettytab capability nameEach tc= entry matches another
gettytab capability nameIf you dial but the modem on the FreeBSD system will not answer,
make sure that the modem is configured to answer the phone when
DTR is asserted. If the modem seems to be
configured correctly, verify that the DTR line is
asserted by checking the modem's indicator lights (if it has
any).If you have gone over everything several times and it still does
not work, take a break and come back to it later. If it still does
not work, perhaps you can send an electronic mail message to the
&a.questions;describing your modem and your problem, and the good
folks on the list will try to help.AcknowledgmentsThanks to these people for comments and advice:&a.kelly;for a number of good suggestionsDialout ServiceInformation integrated from FAQ.The following are tips to getting your host to be able to connect
over the modem to another computer. This is appropriate for
establishing a terminal session with a remote host.This is useful to log onto a BBS.This kind of connection can be extremely helpful to get a file on
the Internet if you have problems with PPP. If you need to ftp
something and PPP is broken, use the terminal session to ftp it. Then
use zmodem to transfer it to your machine.Why cannot I run tip or
cu?On your system, the programs tip and
cu are probably executable only by
uucp and group dialer. You
can use the group dialer to control who has
access to your modem or remote systems. Just add yourself to group
dialer.Alternatively, you can let everyone on your system run
tip and cu by typing:&prompt.root; chmod 4511 /usr/bin/tipYou do not have to run this command for cu,
since cu is just a hard link to
tip.My stock Hayes modem is not supported, what can I do?Actually, the man page for tip is out of date.
There is a generic Hayes dialer already built in. Just use
at=hayes in your /etc/remote
file.The Hayes driver is not smart enough to recognize some of the
advanced features of newer modems—messages like
BUSY, NO DIALTONE, or
CONNECT 115200 will just confuse it. You should
turn those messages off when you use tip (using
ATX0&W).Also, the dial timeout for tip is 60 seconds.
Your modem should use something less, or else tip will think there is
a communication problem. Try ATS7=45&W.Actually, as shipped tip does not yet support
it fully. The solution is to edit the file
tipconf.h in the directory
/usr/src/usr.bin/tip/tip Obviously you need the
source distribution to do this.Edit the line #define HAYES 0 to
#define HAYES 1. Then make and
make install. Everything works nicely after
that.How am I expected to enter these AT commands?Make what is called a “direct” entry in your
/etc/remote file. For example, if your modem is
hooked up to the first serial port, /dev/cuaa0,
then put in the following line:
cuaa0:dv=/dev/cuaa0:br#19200:pa=noneUse the highest bps rate your modem supports in the br capability.
Then, type tip cuaa0 and you will be connected to
your modem.If there is no /dev/cuaa0 on your system, do
this:&prompt.root; cd /dev
&prompt.root; MAKEDEV cuaa0Or use cu as root with the following command:&prompt.root; cu -lline -sspeedline is the serial port
(e.g./dev/cuaa0) and
speed is the speed
(e.g.57600). When you are done entering the AT
commands hit ~. to exit.The @ sign for the pn capability does not
work!The @ sign in the phone number capability tells
tip to look in /etc/phones for a phone number.
But the @ sign is also a special character in
capability files like /etc/remote. Escape it
with a backslash:
pn=\@How can I dial a phone number on the command line?Put what is called a “generic” entry in your
/etc/remote file. For example:
tip115200|Dial any phone number at 115200 bps:\
:dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
tip57600|Dial any phone number at 57600 bps:\
:dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:Then you can things like:&prompt.root; tip -115200 5551234If you prefer cu over tip,
use a generic cu entry:
cu115200|Use cu to dial any number at 115200bps:\
:dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:and type:&prompt.root; cu 5551234 -s 115200Do I have to type in the bps rate every time I do that?Put in an entry for tip1200 or
cu1200, but go ahead and use whatever bps rate is
appropriate with the br capability. tip thinks a
good default is 1200 bps which is why it looks for a
tip1200 entry. You do not have to use 1200 bps,
though.I access a number of hosts through a terminal server.Rather than waiting until you are connected and typing
CONNECT <host> each time, use tip's
cm capability. For example, these entries in
/etc/remote:
pain|pain.deep13.com|Forrester's machine:\
:cm=CONNECT pain\n:tc=deep13:
muffin|muffin.deep13.com|Frank's machine:\
:cm=CONNECT muffin\n:tc=deep13:
deep13:Gizmonics Institute terminal server:\
:dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234:will let you type tip pain or tip
muffin to connect to the hosts pain or muffin; and
tip deep13 to get to the terminal server.Can tip try more than one line for each site?This is often a problem where a university has several modem lines
and several thousand students trying to use them...Make an entry for your university in
/etc/remote and use @ for the
pn capability:
big-university:\
:pn=\@:tc=dialout
dialout:\
:dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:Then, list the phone numbers for the university in
/etc/phones:
big-university 5551111
big-university 5551112
big-university 5551113
big-university 5551114tip will try each one in the listed order, then
give up. If you want to keep retrying, run tip in
a while loop.Why do I have to hit CTRL+P twice to send CTRL+P once?CTRL+P is the default “force” character, used to tell
tip that the next character is literal data. You
can set the force character to any other character with the
~s escape, which means “set a
variable.”Type
~sforce=single-char
followed by a newline. single-char is any
single character. If you leave out
single-char, then the force character is
the nul character, which you can get by typing CTRL+2 or CTRL+SPACE.
A pretty good value for single-char is
SHIFT+CTRL+6, which I have seen only used on some terminal
servers.You can have the force character be whatever you want by
specifying the following in your $HOME/.tiprc
file:
force=<single-char>Suddenly everything I type is in UPPER CASE??You must have pressed CTRL+A, tip's
“raise character,” specially designed for people with
broken caps-lock keys. Use ~s as above and set the
variable raisechar to something reasonable. In
fact, you can set it to the same as the force character, if you never
expect to use either of these features.Here is a sample .tiprc file perfect for Emacs users who need to
type CTRL+2 and CTRL+A a lot:
force=^^
raisechar=^^The ^^ is SHIFT+CTRL+6.How can I do file transfers with tip?If you are talking to another UNIX system, you can send and
receive files with ~p (put) and
~t (take). These commands run
cat and echo on the remote
system to accept and send files. The syntax is:~plocal-fileremote-file~tremote-filelocal-fileThere is no error checking, so you probably should use another
protocol, like zmodem.How can I run zmodem with tip?To receive files, start the sending program on the remote end.
Then, type ~C rz to begin receiving them
locally.To send files, start the receiving program on the remote end.
Then, type ~C sz files
to send them to the remote system.Setting Up the Serial Console&a.yokota; and &a.wpaul:The text is heavily based on
/sys/i386/boot/biosboot/README.serial written by
&a.wpaul;.IntroductionThe FreeBSD/i386 operating system can boot on a system with only
a dumb terminal on a serial port as a console. Such a configuration
should be useful for two classes of people; system administrators who
wish to install FreeBSD on a dedicated file/compute/terminal server
machines that have no keyboard or monitor attached, and developers who
want to debug the kernel or device drivers.Starting from version 3.1, FreeBSD/i386 employs a three stage
bootstrap. The first two stages are in the boot block code which is
stored at the beginning of the FreeBSD slice on the boot disk. The
boot block will then load and run the boot loader
(/boot/loader) as the third stage code. (See
&man.boot.8; and &man.loader.8; for more details on the boot
process.)In order to set up the serial console you must configure the boot
block code, the boot loader code and the kernel.In FreeBSD version 3.0, the boot loader does not exist and there
are only two stages in the bootstrap; the boot blocks directly load
the kernel into memory. If you are using FreeBSD 3.0, then you should
disregard any reference to the boot loader in this section. You can
still use the serial port as a console.FreeBSD versions 2.X are quite different from 3.X, in that the
serial port driver, &man.sio.4;, must be configured in a different
way. This chapter will not describe the settings for version 2.X
systems. If you are using these older versions of FreeBSD, please
consult /sys/i386/boot/biosboot/README.serial
instead.6 Steps to Set up the Serial ConsolePrepare a serial cable.You will need either a null-modem cable or a standard serial
cable and a null-modem adapter. See for
a discussion on serial cables.Unplug your keyboard.Most PC systems probe for the keyboard during the Power-On
Self-Test (POST) and will generate an error if the keyboard is not
detected. Some machines complain loudly about the lack of a
keyboard and will not continue to boot until it is plugged
in.If your computer complains about the error, but boots anyway,
then you do not have to do anything special. (One machine with a
Phoenix BIOS that I have here merely says Keyboard
failed then continues to boot normally.)If your computer refuses to boot without a keyboard attached
then you will have to configure the BIOS so that it ignores this
error (if it can). Consult your motherboard's manual for details
on how to do this.Setting the keyboard to “Not installed” in the
BIOS setup does not mean that you will not
be able to use your keyboard. All this does is tell the BIOS
not to probe for a keyboard at power-on so that it will not
complain if the keyboard is not plugged in. You can leave the
keyboard plugged in even with this flag set to “Not
installed” and the keyboard will still work.If your system has a PS/2 mouse, chances are very good that
you may have to unplug your mouse as well as your keyboard.
This is because PS/2 mice share some hardware with the keyboard,
and leaving the mouse plugged in can fool the keyboard probe
into thinking the keyboard is still there. It is said that a
Gateway 2000 Pentium 90Mhz system with an AMI BIOS that behaves
this way. In general this is not a problem since the mouse is
not much good without the keyboard anyway.Plug a dumb terminal into COM1:
(sio0).If you do not have a dumb terminal, you can use an old PC/XT
with a modem program, or the serial port on another UNIX box. If
you do not have a COM1:
(sio0), get one. At this time, there is
no way to select a port other than COM1:
for the boot blocks without recompiling the boot blocks. If you
are already using COM1: for another
device, you will have to temporarily remove that device and
install a new boot block and kernel once you get FreeBSD up and
running. (It is assumed that COM1: will
be available on a file/compute/terminal server anyway; if you
really need COM1: for something else
(and you can not switch that something else to
COM2: (sio1)),
then you probably should not even be bothering with all this in
the first place.)Make sure the configuration file of your kernel has
appropriate flags set for COM1:
(sio0).Relevant flags are:0x10Enables console support for this unit. The other
console flags are ignored unless this is set. Currently, at
most one unit can have console support; the first one (in
config file order) with this flag set is preferred. This
option alone will not make the serial port the console. Set
the following flag or use the option
described below, together with this flag.0x20Forces this unit to be the console (unless there is
another higher priority console), regardless of the
option discussed below. This flag
replaces the COMCONSOLE option in FreeBSD
versions 2.X. The flag 0x20 must be used
together with the flag.0x40Reserves this unit (in conjunction with
0x10) and makes the unit unavailable for
normal access. You should not set this flag to the serial
port unit which you want to use as the serial console. The
only use of this flag is to designate the unit for kernel
remote debugging. See for more
information on remote debugging.In FreeBSD 4.0-CURRENT or later the semantics of the
flag 0x40 are slightly different and
there is another flag to specify a serial port for remote
debugging.Example:
device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4See &man.sio.4; for more details.If the flags were not set, you need to run UserConfig (on a
different console) or recompile the kernel.Create boot.config in the root directory
of the a partition on the boot drive.This file will instruct the boot block code how you would like
to boot the system. In order to activate the serial console, you
need one or more of the following options—if you want
multiple options, include them all on the same line:Toggles internal and serial consoles. You can use this
to switch console devices. For instance, if you boot from
the internal (video) console, you can use
to direct the boot loader and the kernel
to use the serial port as its console device. Alternatively,
if you boot from the serial port, you can use the
to tell the boot loader and the kernel
to use the video display as the console instead.Toggles single and dual console configurations. In the
single configuration the console will be either the internal
console (video display) or the serial port, depending on the
state of the option above. In the dual
console configuration, both the video display and the
serial port will become the console at the same time,
regardless of the state of the option.
However, that the dual console configuration takes effect
only during the boot block is running. Once the boot loader
gets control, the console specified by the
option becomes the only console.Makes the boot block probe the keyboard. If no keyboard
is found, the and
options are automatically set.Due to space constraints in the current version of the
boot blocks, the option is capable of
detecting extended keyboards only. Keyboards with less
than 101 keys (and without F11 and F12 keys) may not be
detected. Keyboards on some laptop computers may not be
properly found because of this limitation. If this is to
be the case with your system, you have to abandon using
the option. Unfortunately there is no
workaround for this problem.Use either the option to select the
console automatically, or the option to
activate the serial console.You may include other options described in &man.boot.8; as
well.The options, except for , will be passed to
the boot loader (/boot/loader). The boot
loader will determine which of the internal video or the serial
port should become the console by examining the state of the
option alone. This means that if you specify
the option but not the
option in /boot.config, you can use the
serial port as the console only during the boot block; the boot
loader will use the internal video display as the console.Boot the machine.When you start your FreeBSD box, the boot blocks will echo the
contents of /boot.config to the console. For
example;/boot.config: -P
Keyboard: noThe second line appears only if you put in
/boot.config and indicates presence/absence
of the keyboard. These messages go to either serial or internal
console, or both, depending on the option in
/boot.config.OptionsMessage goes tononeinternal consoleserial consoleserial and internal consolesserial and internal consoles, keyboard presentinternal console, keyboard absentserial consoleAfter the above messages, there will be a small pause before
the boot blocks continue loading the boot loader and before any
further messages printed to the console. Under normal
circumstances, you do not need to interrupt the boot blocks, but
you may want to do so in order to make sure things are set up
correctly.Hit any key, other than Enter/Return, at the console to
interrupt the boot process. The boot blocks will then prompt you
for further action. You should now see something like:>> FreeBSD/i386 BOOT
Default: 0:wd(0,a)/boot/loader
boot:Verify the above message appears on either the serial or
internal console or both, according to the options you put in
/boot.config. If the message appears in the
correct console, hit Enter/Return to continue the boot
process.If you want the serial console but you do not see the prompt
on the serial terminal, something is wrong with your settings. In
the meantime, you enter and hit Enter/Return
(if possible) to tell the boot block (and then the boot loader and
the kernel) to choose the serial port for the console. Once the
system is up, go back and check what went wrong.After the boot loader is loaded and you are in the third stage of
the boot process you can still switch between the internal console and
the serial console by setting appropriate environment variables in the
boot loader. See .SummaryHere is the summary of various settings discussed in this section
and the console eventually selected.Case 1: You set the flags to 0x10 for sio0device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4Options in /boot.configConsole during boot blocksConsole during boot loaderConsole in kernelnothinginternalinternalinternalserialserialserialserial and internalinternalinternalserial and internalserialserial, keyboard presentinternalinternalinternal, keyboard absentserial and internalserialserialCase 2: You set the flags to 0x30 for sio0device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4Options in /boot.configConsole during boot blocksConsole during boot loaderConsole in kernelnothinginternalinternalserialserialserialserialserial and internalinternalserialserial and internalserialserial, keyboard presentinternalinternalserial, keyboard absentserial and internalserialserialTips for the Serial ConsoleSetting A Faster Serial Port SpeedBy default the serial port settings are set to 9600 baud, 8
bits, no parity, 1 stop bit. If you wish to change the speed, you
need to recompile at least the boot blocks. Add the following line
to /etc/make.conf and compile new boot
blocks:BOOT_COMCONSOLE_SPEED=19200If the serial console is configured in some other way than by
booting with , or if the serial console used by
the kernel is different from the one used by the boot blocks, then
you must also add the following option to the kernel configuration
file and compile a new kernel:options CONSPEED=19200Using Serial Port Other Than sio0 For
The ConsoleUsing a port other than sio0 as the
console requires some recompiling. If you want to use another
serial port for whatever reasons, recompile the boot blocks, the
boot loader and the kernel as follows.Get the kernel source.Edit /etc/make.conf and set
BOOT_COMCONSOLE_PORT to the address of the
port you want to use (0x3F8, 0x2F8, 0x3E8 or 0x2E8). Only
sio0 through
sio3 (COM1:
through COM4:) can be used; multiport
serial cards will not work. No interrupt setting is
needed.Create a custom kernel configuration file and add
appropriate flags for the serial port you want to use. For
example, if you want to make sio1
(COM2:) the console:device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3ordevice sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3The console flags for the other serial ports should not be
set.Recompile and install the boot blocks:&prompt.root; cd /sys/boot/i386/boot2
&prompt.root; make
&prompt.root; make installRecompile and install the boot loader:&prompt.root; cd /sys/boot/i386/loader
&prompt.root; make
&prompt.root; make installRebuild and install the kernel.Write the boot blocks to the boot disk with
&man.disklabel.8; and boot from the new kernel.Entering the DDB Debugger from the Serial LineIf you wish to drop into the kernel debugger from the serial
console (useful for remote diagnostics, but also dangerous if you
generate a spurious BREAK on the serial port!) then you should
compile your kernel with the following options:options BREAK_TO_DEBUGGER
options DDBGetting a Login Prompt on the Serial ConsoleWhile this is not required, you may wish to get a
login prompt over the serial line, now that you
can see boot messages and can enter the kernel debugging session
through the serial console. Here is how to do it.Open the file /etc/ttys with an editor
and locate the lines:ttyd0 "/usr/libexec/getty std.9600" unknown off secure
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
ttyd2 "/usr/libexec/getty std.9600" unknown off secure
ttyd3 "/usr/libexec/getty std.9600" unknown off securettyd0 through ttyd3
corresponds to COM1 through
COM4. Change off to
on for the desired port. If you have changed the
speed of the serial port, you need to change
std.9600 to match the current setting, e.g.
std.19200.You may also want to change the terminal type from
unknown to the actual type of your serial
terminal.After editing the file, you must kill -HUP 1
to make this change take effect.Changing Console from the Boot LoaderPrevious sections described how to set up the serial console by
tweaking the boot block. This section shows that you can specify the
console by entering some commands and environment variables in the
boot loader. As the boot loader is invoked as the third stage of the
boot process, after the boot block, the settings in the boot loader
will override the settings in the boot block.Setting Up the Serial ConsoleYou can easily specify the boot loader and the kernel to use the
serial console by writing just one line in
/boot/loader.rc:set console=comconsoleThis will take effect regardless of the settings in the boot
block discussed in the previous section.You had better put the above line as the first line of
/boot/loader.rc so as to see boot messages on
the serial console as early as possible.Likewise, you can specify the internal console as:set console=vidconsoleIf you do not set the boot loader environment variable
console, the boot loader, and subsequently the
kernel, will use whichever console indicated by the
option in the boot block.In versions 3.2 or later, you may specify the console in
/boot/loader.conf.local or
/boot/loader.conf, rather than in
/boot/loader.rc. In this method your
/boot/loader.rc should look like:include /boot/loader.4th
startThen, create /boot/loader.conf.local and
put the following line there.console=comconsoleorconsole=vidconsoleSee &man.loader.conf.5; for more information.At the moment, the boot loader has no option equivalent to the
option in the boot block, and there is no
provision to automatically select the internal console and the
serial console based on the presence of the keyboard.Using Serial Port Other than sio0 for
the ConsoleYou need to recompile the boot loader to use a serial port other
than sio0 for the serial console. Follow the
procedure described in .CaveatsThe idea here is to allow people to set up dedicated servers that
require no graphics hardware or attached keyboards. Unfortunately,
while (most?) every system will let you boot without a keyboard, there
are quite a few that will not let you boot without a graphics adapter.
Machines with AMI BIOSes can be configured to boot with no graphics
adapter installed simply by changing the `graphics adapter' setting in
the CMOS configuration to `Not installed.'However, many machines do not support this option and will refuse
to boot if you have no display hardware in the system. With these
machines, you'll have to leave some kind of graphics card plugged in,
(even if it's just a junky mono board) although you will not have to
attach a monitor into it. You might also try installing an AMI
BIOS.
diff --git a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml b/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
index f9e8e1acee..5f632f1708 100644
--- a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
@@ -1,933 +1,933 @@
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 specific
areas of the FreeBSD project landscape.(in alphabetical order by last name):&a.asami;&a.jmb;&a.ache;&a.bde;&a.gibbs;&a.dg;&a.jkh;&a.phk;&a.rich;&a.gpalmer;&a.jdp;&a.dfr;&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 are
also developers.&a.ugen;&a.dbaker;&a.mbarkah;&a.stb;&a.pb;&a.abial;&a.jb;&a.torstenb;&a.dburr;&a.charnier;&a.luoqi;&a.ejc;&a.kjc;&a.gclarkii;&a.archie;&a.chris;&a.alc;&a.cracauer;&a.adam;&a.dillon;&a.mdodd;&a.dufault;&a.uhclem;&a.tegge;&a.deischen;&a.eivind;&a.julian;&a.rse;&a.ru;&a.se;&a.jasone;&a.sef;&a.green;&a.fenner;&a.jfieber;&a.jfitz;&a.scrappy;&a.lars;&a.dirk;&a.shige;&a.billf;&a.gallatin;&a.tg;&a.brandon;&a.graichen;&a.cg;&a.jgreco;&a.rgrimes;&a.jmg;&a.hanai;&a.mharo;&a.thepish;&a.jhay;&a.sheldonh;&a.helbig;&a.ghelmer;&a.erich;&a.nhibma;&a.flathill;&a.hosokawa;&a.hsu;&a.foxfair;&a.tom;&a.mph;&a.shin;&a.itojun;&a.iwasaki;&a.mjacob;&a.gj;&a.nsj;&a.ljo;&a.kato;&a.andreas;&a.motoyuki;&a.jkoshy;&a.kuriyama;&a.grog;&a.jlemon;&a.truckman;&a.lile;&a.kevlo;&a.imp;&a.jmacd;&a.smace;&a.gehenna;&a.mckay;&a.mckusick;&a.ken;&a.hm;&a.tedm;&a.jim;&a.marcel;&a.amurai;&a.markm;&a.max;&a.newton;&a.rnordier;&a.davidn;&a.obrien;&a.danny;&a.ljo;&a.fsmp;&a.smpatel;&a.wpaul;&a.alfred;&a.wes;&a.cpiazza;&a.steve;&a.mpp;&a.jraynard;&a.darrenr;&a.csgr;&a.martin;&a.paul;&a.roberto;&a.chuckr;&a.guido;&a.dima;&a.sada;&a.nsayer;&a.wosch;&a.ats;&a.dick;&a.jseger;&a.simokawa;&a.vanilla;&a.msmith;&a.des;&a.brian;&a.mks;&a.stark;&a.karl;&a.sumikawa;&a.nyan;&a.tanimura;&a.taoka;&a.dt;&a.cwt;&a.pst;&a.hoek;&a.nectar;&a.swallace;&a.dwhite;&a.nate;&a.yokota;&a.jmz;The FreeBSD Documentation ProjectThe 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
+ Documentation Project Architect&a.nik;Webmaster&a.wosch;Handbook & FAQ Editor&a.faq;News Editor&a.nsj;Deputy: &a.john;In the Press Editor&a.jkoshyFreeBSD Really-Quick NewsLetter EditorChris Coleman chrisc@vmunix.comGallery Editor&a.nsj;Deputy: &a.cawimm;Commercial Editor&a.nik;Web Changes Editor-User Groups Editor-LinuxDoc to DocBook conversion&a.nik;Who Is Responsible for WhatPrincipal Architect&a.dg;Documentation
Project Manager&a.nik;Internationalization&a.ache;Networking&a.wollman;Postmaster&a.jmb;Release Coordinator&a.jkh;Public Relations & Corporate Liaison&a.jkh;Security
Officer&a.imp;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;Webmaster&a.wosch;
diff --git a/en_US.ISO8859-1/books/handbook/x11/chapter.sgml b/en_US.ISO8859-1/books/handbook/x11/chapter.sgml
index 19bfa17e1c..c63032cdd1 100644
--- a/en_US.ISO8859-1/books/handbook/x11/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/x11/chapter.sgml
@@ -1,25 +1,25 @@
The X Window SystemPending the completion of this section, please refer to documentation
supplied by the The XFree86 Project,
Inc.
diff --git a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
index 8f3ecfdc06..a96cc080df 100644
--- a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml
@@ -1,934 +1,934 @@
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:hostdefault gatewayinterfaceLocal2Local1ethernetLocal1T1-GWPPPA 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
&man.traceroute.8; command. It is equally useful if you cannot seem
to make a connection to a remote machine (i.e. &man.ping.8;
fails).The &man.traceroute.8; 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
&man.traceroute.8;.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 0As a manual mount command on freebox:&prompt.root; 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 0As a manual mount command on fastws:&prompt.root; 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 InstructionsFind 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:helpprint help listip
print/set client's IP addressserver
print/set bootp/tftp server addressnetmask
print/set netmaskhostname nameprint/set hostnamekernel
print/set kernel namerootfs
print/set root filesystemswapfs
print/set swap filesystemswapsize
set diskless swapsize in Kbytesdiskbootboot from diskautobootcontinue boot processtrans
|turn transceiver on|offflags
set boot flagsA typical completely diskless cfg file might contain:
rootfs 192.1.2.3:/rootfs/myclient
swapfs 192.1.2.3:/swapfs
swapsize 20000
hostname myclient.mydomainA 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.mydomainAnd 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:&prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000Also, 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:&prompt.root; chmod 0600 /swapfs/swap.192.1.2.4Unpack 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 / and /usr
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 CardsContributed by &a.hm;.This section is really only relevant to ISDN users in countries
where the DSS1/Q.931 ISDN standard is supported.Some growing number of PC ISDN cards are supported under FreeBSD
2.2.x and up by the isdn4bsd driver package. It is still under
development but the reports show that it is successfully used all over
Europe.The latest isdn4bsd version is available from ftp://isdn4bsd@ftp.consol.de/pub/,
the main isdn4bsd ftp site (you have to log in as user
isdn4bsd , give your mail address as the password
and change to the pub directory. Anonymous ftp
as user ftp or anonymous
will not give the desired result).Isdn4bsd allows you to connect to other ISDN routers using either
IP over raw HDLC or by using synchronous PPP. A telephone answering
machine application is also available.Many ISDN PC cards are supported, mostly the ones with a Siemens
ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola,
Cologne Chip Designs) is currently under development. For an
up-to-date list of supported cards, please have a look at the README
file.In case you are interested in adding support for a different ISDN
protocol, a currently unsupported ISDN PC card or otherwise enhancing
isdn4bsd, please get in touch with hm@kts.org.A majordomo maintained mailing list is available. To join the
list, send mail to majordomo@FreeBSD.org and
specify:
subscribe freebsd-isdnin 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 PPP 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 PPP option, not the user-land iijPPP.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 serial ports
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 lineIf 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.
diff --git a/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml b/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml
index 2b8fe22c2a..a86cfe5598 100644
--- a/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/backups/chapter.sgml
@@ -1,621 +1,621 @@
BackupsIssues of hardware compatibility are among the most troublesome in the
computer industry today and FreeBSD is by no means immune to trouble. In
this respect, FreeBSD's advantage of being able to run on inexpensive
commodity PC hardware is also its liability when it comes to support for
the amazing variety of components on the market. While it would be
impossible to provide a exhaustive listing of hardware that FreeBSD
supports, this section serves as a catalog of the device drivers included
with FreeBSD and the hardware each drivers supports. Where possible and
appropriate, notes about specific products are included. You may also
want to refer to the kernel
configuration file section in this handbook for a list of
supported devices.As FreeBSD is a volunteer project without a funded testing department,
we depend on you, the user, for much of the information contained in this
catalog. If you have direct experience of hardware that does or does not
work with FreeBSD, please let us know by sending e-mail to the &a.doc;.
Questions about supported hardware should be directed to the &a.questions
(see Mailing Lists for more
information). When submitting information or asking a question, please
remember to specify exactly what version of FreeBSD you are using and
include as many details of your hardware as possible.* What about backups to floppies?Tape MediaThe major tape media are the 4mm, 8mm, QIC, mini-cartridge and
DLT.4mm (DDS: Digital Data Storage)4mm tapes are replacing QIC as the workstation backup media of
choice. This trend accelerated greatly when Conner purchased Archive,
a leading manufacturer of QIC drives, and then stopped production of
QIC drives. 4mm drives are small and quiet but do not have the
reputation for reliability that is enjoyed by 8mm drives. The
cartridges are less expensive and smaller (3 x 2 x 0.5 inches, 76 x 51
x 12 mm) than 8mm cartridges. 4mm, like 8mm, has comparatively short
head life for the same reason, both use helical scan.Data thruput on these drives starts ~150kB/s, peaking at ~500kB/s.
Data capacity starts at 1.3 GB and ends at 2.0 GB. Hardware
compression, available with most of these drives, approximately
doubles the capacity. Multi-drive tape library units can have 6
drives in a single cabinet with automatic tape changing. Library
capacities reach 240 GB.4mm drives, like 8mm drives, use helical-scan. All the benefits
and drawbacks of helical-scan apply to both 4mm and 8mm drives.Tapes should be retired from use after 2,000 passes or 100 full
backups.8mm (Exabyte)8mm tapes are the most common SCSI tape drives; they are the best
choice of exchanging tapes. Nearly every site has an exabyte 2 GB 8mm
tape drive. 8mm drives are reliable, convenient and quiet. Cartridges
are inexpensive and small (4.8 x 3.3 x 0.6 inches; 122 x 84 x 15 mm).
One downside of 8mm tape is relatively short head and tape life due to
the high rate of relative motion of the tape across the heads.Data thruput ranges from ~250kB/s to ~500kB/s. Data sizes start
at 300 MB and go up to 7 GB. Hardware compression, available with
most of these drives, approximately doubles the capacity. These
drives are available as single units or multi-drive tape libraries
with 6 drives and 120 tapes in a single cabinet. Tapes are changed
automatically by the unit. Library capacities reach 840+ GB.Data is recorded onto the tape using helical-scan, the heads are
positioned at an angle to the media (approximately 6 degrees). The
tape wraps around 270 degrees of the spool that holds the heads. The
spool spins while the tape slides over the spool. The result is a
high density of data and closely packed tracks that angle across the
tape from one edge to the other.QICQIC-150 tapes and drives are, perhaps, the most common tape drive
and media around. QIC tape drives are the least expensive "serious"
backup drives. The downside is the cost of media. QIC tapes are
expensive compared to 8mm or 4mm tapes, up to 5 times the price per GB
data storage. But, if your needs can be satisfied with a half-dozen
tapes, QIC may be the correct choice. QIC is the
most common tape drive. Every site has a QIC
drive of some density or another. Therein lies the rub, QIC has a
large number of densities on physically similar (sometimes identical)
tapes. QIC drives are not quiet. These drives audibly seek before
they begin to record data and are clearly audible whenever reading,
writing or seeking. QIC tapes measure (6 x 4 x 0.7 inches; 15.2 x
10.2 x 1.7 mm). Mini-cartridges, which
also use 1/4" wide tape are discussed separately. Tape libraries and
changers are not available.Data thruput ranges from ~150kB/s to ~500kB/s. Data capacity
ranges from 40 MB to 15 GB. Hardware compression is available on many
of the newer QIC drives. QIC drives are less frequently installed;
they are being supplanted by DAT drives.Data is recorded onto the tape in tracks. The tracks run along
the long axis of the tape media from one end to the other. The number
of tracks, and therefore the width of a track, varies with the tape's
capacity. Most if not all newer drives provide backward-compatibility
at least for reading (but often also for writing). QIC has a good
reputation regarding the safety of the data (the mechanics are simpler
and more robust than for helical scan drives).Tapes should be retired from use after 5,000 backups.* Mini-CartridgeDLTDLT has the fastest data transfer rate of all the drive types
listed here. The 1/2" (12.5mm) tape is contained in a single spool
cartridge (4 x 4 x 1 inches; 100 x 100 x 25 mm). The cartridge has a
swinging gate along one entire side of the cartridge. The drive
mechanism opens this gate to extract the tape leader. The tape leader
has an oval hole in it which the drive uses to "hook" the tape. The
take-up spool is located inside the tape drive. All the other tape
cartridges listed here (9 track tapes are the only exception) have
both the supply and take-up spools located inside the tape cartridge
itself.Data thruput is approximately 1.5MB/s, three times the thruput of
4mm, 8mm, or QIC tape drives. Data capacities range from 10GB to 20GB
for a single drive. Drives are available in both multi-tape changers
and multi-tape, multi-drive tape libraries containing from 5 to 900
tapes over 1 to 20 drives, providing from 50GB to 9TB of
storage.Data is recorded onto the tape in tracks parallel to the direction
of travel (just like QIC tapes). Two tracks are written at once.
Read/write head lifetimes are relatively long; once the tape stops
moving, there is no relative motion between the heads and the
tape.Using a new tape for the first timeThe first time that you try to read or write a new, completely
blank tape, the operation will fail. The console messages should be
similar to:sa0(ncr1:4:0): NOT READY asc:4,1
sa0(ncr1:4:0): Logical unit is in process of becoming readyThe tape does not contain an Identifier Block (block number 0).
All QIC tape drives since the adoption of QIC-525 standard write an
Identifier Block to the tape. There are two solutions:mt fsf 1 causes the tape drive to write an
Identifier Block to the tape.Use the front panel button to eject the tape.Re-insert the tape and &man.dump.8; data to the tape.&man.dump.8; will report DUMP: End of tape
detected and the console will show: HARDWARE
FAILURE info:280 asc:80,96rewind the tape using: mt rewindSubsequent tape operations are successful.Backup ProgramsThe three major programs are
&man.dump.8;,
&man.tar.1;,
and
&man.cpio.1;.Dump and Restore&man.dump.8; and &man.restore.8; are the traditional Unix backup
programs. They operate on the drive as a collection of disk blocks,
below the abstractions of files, links and directories that are
created by the filesystems. &man.dump.8; backs up devices, entire
filesystems, not parts of a filesystem and not directory trees that
span more than one filesystem, using either soft links &man.ln.1; or
mounting one filesystem onto another. &man.dump.8; does not write
files and directories to tape, but rather writes the data blocks that
are the building blocks of files and directories. &man.dump.8; has
quirks that remain from its early days in Version 6 of ATT Unix (circa
1975). The default parameters are suitable for 9-track tapes (6250
bpi), not the high-density media available today (up to 62,182 ftpi).
These defaults must be overridden on the command line to utilize the
capacity of current tape drives.&man.rdump.8; and &man.rrestore.8; backup data across the network
to a tape drive attached to another computer. Both programs rely upon
&man.rcmd.3; and &man.ruserok.3; to access the remote tape drive.
Therefore, the user performing the backup must have
rhosts access to the remote computer. The
arguments to &man.rdump.8; and &man.rrestore.8; must suitable to use
on the remote computer. (e.g. When rdump'ing from
a FreeBSD computer to an Exabyte tape drive connected to a Sun called
komodo, use: /sbin/rdump 0dsbfu 54000 13000
126 komodo:/dev/nrsa8 /dev/rda0a 2>&1) Beware: there
are security implications to allowing rhosts
commands. Evaluate your situation carefully.Tar&man.tar.1; also dates back to Version 6 of ATT Unix (circa 1975).
&man.tar.1; operates in cooperation with the filesystem; &man.tar.1;
writes files and directories to tape. &man.tar.1; does not support the
full range of options that are available from &man.cpio.1;, but
&man.tar.1; does not require the unusual command pipeline that
&man.cpio.1; uses.Most versions of &man.tar.1; do not support backups across the
network. The GNU version of &man.tar.1;, which FreeBSD utilizes,
supports remote devices using the same syntax as &man.rdump.8;. To
&man.tar.1; to an Exabyte tape drive connected to a Sun called
komodo, use: /usr/bin/tar cf
komodo:/dev/nrsa8 . 2>&1. For versions without remote
device support, you can use a pipeline and &man.rsh.1; to send the
data to a remote tape drive. (XXX add an example command)Cpio&man.cpio.1; is the original Unix file interchange tape program
for magnetic media. &man.cpio.1; has options (among many others) to
perform byte-swapping, write a number of different archives format,
and pipe the data to other programs. This last feature makes
&man.cpio.1; and excellent choice for installation media.
&man.cpio.1; does not know how to walk the directory tree and a list
of files must be provided through stdin.&man.cpio.1; does not support backups across the network. You can
use a pipeline and &man.rsh.1; to send the data to a remote tape
drive. (XXX add an example command)Pax&man.pax.1; is IEEE/POSIX's answer to &man.tar.1; and
&man.cpio.1;. Over the years the various versions of &man.tar.1;
and &man.cpio.1; have gotten slightly incompatible. So rather than
fight it out to fully standardize them, POSIX created a new archive
utility. &man.pax.1; attempts to read and write many of the various
&man.cpio.1; and &man.tar.1; formats, plus new formats of its own.
Its command set more resembles &man.cpio.1; than &man.tar.1;.AmandaAmanda
(Advanced Maryland Network Disk Archiver) is a client/server backup
system, rather than a single program. An Amanda server will backup to
a single tape drive any number of computers that have Amanda clients
and network communications with the Amanda server. A common problem
at locations with a number of large disks is the length of time
required to backup to data directly to tape exceeds the amount of time
available for the task. Amanda solves this problem. Amanda can use a
"holding disk" to backup several filesystems at the same time. Amanda
creates "archive sets": a group of tapes used over a period of time to
create full backups of all the filesystems listed in Amanda's
configuration file. The "archive set" also contains nightly
incremental (or differential) backups of all the filesystems.
Restoring a damaged filesystem requires the most recent full backup
and the incremental backups.The configuration file provides fine control backups and the
network traffic that Amanda generates. Amanda will use any of the
above backup programs to write the data to tape. Amanda is available
as either a port or a package, it is not installed by default.Do nothing“Do nothing” is not a computer program, but it is the
most widely used backup strategy. There are no initial costs. There
is no backup schedule to follow. Just say no. If something happens
to your data, grin and bear it!If your time and your data is worth little to nothing, then
“Do nothing” is the most suitable backup program for your
computer. But beware, Unix is a useful tool, you may find that within
six months you have a collection of files that are valuable to
you.“Do nothing” is the correct backup method for
/usr/obj and other directory trees that can be
exactly recreated by your computer. An example is the files that
comprise these handbook pages-they have been generated from
SGML input files. Creating backups of these
HTML files is not necessary. The
SGML source files are backed up regularly.Which Backup Program is Best?&man.dump.8; Period. Elizabeth D. Zwicky
torture tested all the backup programs discussed here. The clear
choice for preserving all your data and all the peculiarities of Unix
filesystems is &man.dump.8;. Elizabeth created filesystems containing
a large variety of unusual conditions (and some not so unusual ones)
and tested each program by do a backup and restore of that
filesystems. The peculiarities included: files with holes, files with
holes and a block of nulls, files with funny characters in their
names, unreadable and unwritable files, devices, files that change
size during the backup, files that are created/deleted during the
backup and more. She presented the results at LISA V in Oct. 1991.
See torture-testing
Backup and Archive Programs.Emergency Restore ProcedureBefore the DisasterThere are only four steps that you need to perform in
preparation for any disaster that may occur.First, print the disklabel from each of your disks
(e.g. disklabel da0 | lpr), your filesystem table
(/etc/fstab) and all boot messages, two copies of
each.Second, determine that the boot and fixit floppies
(boot.flp and fixit.flp)
have all your devices. The easiest way to check is to reboot your
machine with the boot floppy in the floppy drive and check the boot
messages. If all your devices are listed and functional, skip on to
step three.Otherwise, you have to create two custom bootable floppies which
has a kernel that can mount your all of your disks and access your
tape drive. These floppies must contain:
&man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, and
whichever backup program you use. These programs must be statically
linked. If you use &man.dump.8;, the floppy must contain
&man.restore.8;.Third, create backup tapes regularly. Any changes that you make
after your last backup may be irretrievably lost. Write-protect the
backup tapes.Fourth, test the floppies (either boot.flp
and fixit.flp or the two custom bootable
floppies you made in step two.) and backup tapes. Make notes of the
procedure. Store these notes with the bootable floppy, the
printouts and the backup tapes. You will be so distraught when
restoring that the notes may prevent you from destroying your backup
tapes (How? In place of tar xvf /dev/rsa0, you
might accidently type tar cvf /dev/rsa0 and
over-write your backup tape).For an added measure of security, make bootable floppies and two
backup tapes each time. Store one of each at a remote location. A
remote location is NOT the basement of the same office building. A
number of firms in the World Trade Center learned this lesson the
hard way. A remote location should be physically separated from
your computers and disk drives by a significant distance.An example script for creating a bootable floppy:
/mnt/sbin/init
gzip -c -best /sbin/fsck > /mnt/sbin/fsck
gzip -c -best /sbin/mount > /mnt/sbin/mount
gzip -c -best /sbin/halt > /mnt/sbin/halt
gzip -c -best /sbin/restore > /mnt/sbin/restore
gzip -c -best /bin/sh > /mnt/bin/sh
gzip -c -best /bin/sync > /mnt/bin/sync
cp /root/.profile /mnt/root
cp -f /dev/MAKEDEV /mnt/dev
chmod 755 /mnt/dev/MAKEDEV
chmod 500 /mnt/sbin/init
chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt
chmod 555 /mnt/bin/sh /mnt/bin/sync
chmod 6555 /mnt/sbin/restore
#
# create the devices nodes
#
cd /mnt/dev
./MAKEDEV std
./MAKEDEV da0
./MAKEDEV da1
./MAKEDEV da2
./MAKEDEV sa0
./MAKEDEV pty0
cd /
#
# create minimum filesystem table
#
cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd <After the DisasterThe key question is: did your hardware survive? You have been
doing regular backups so there is no need to worry about the
software.If the hardware has been damaged. First, replace those parts
that have been damaged.If your hardware is okay, check your floppies. If you are using
a custom boot floppy, boot single-user (type -s
at the boot: prompt). Skip the following
paragraph.If you are using the boot.flp and
fixit.flp floppies, keep reading. Insert the
boot.flp floppy in the first floppy drive and
boot the computer. The original install menu will be displayed on
the screen. Select the Fixit--Repair mode with CDROM or
floppy. option. Insert the
fixit.flp when prompted.
restore and the other programs that you need are
located in /mnt2/stand.Recover each filesystem separately.Try to &man.mount.8; (e.g. mount /dev/da0a
/mnt) the root partition of your first disk. If the
disklabel was damaged, use &man.disklabel.8; to re-partition and
label the disk to match the label that your printed and saved. Use
&man.newfs.8; to re-create the filesystems. Re-mount the root
partition of the floppy read-write (mount -u -o rw
/mnt). Use your backup program and backup tapes to
recover the data for this filesystem (e.g. restore vrf
/dev/sa0). Unmount the filesystem (e.g. umount
/mnt) Repeat for each filesystem that was
damaged.Once your system is running, backup your data onto new tapes.
Whatever caused the crash or data loss may strike again. An another
hour spent now, may save you from further distress later.* I did not prepare for the Disaster, What Now?
diff --git a/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml b/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml
index d0563703f7..81bc59f689 100644
--- a/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/basics/chapter.sgml
@@ -1,139 +1,139 @@
Unix BasicsThe Online ManualThe most comprehensive documentation on FreeBSD is in the form of
man pages. Nearly every program on the system
comes with a short reference manual explaining the basic operation and
various arguments. These manuals can be view with the
man command. Use of the man
command is simple:&prompt.user; man commandcommand is the name of the command you
wish to learn about. For example, to learn more about
ls command type:&prompt.user; man lsThe online manual is divided up into numbered sections:User commandsSystem calls and error numbersFunctions in the C librariesDevice driversFile formatsGames and other diversionsMiscellaneous informationSystem maintenance and operation commandsKernel developersIn some cases, the same topic may appear in more than one section of
the on-line manual. For example, there is a chmod
user command and a chmod() system call. In this
case, you can tell the man command which one you want
by specifying the section:&prompt.user; man 1 chmodThis will display the manual page for the user command
chmod. References to a particular section of the
on-line manual are traditionally placed in parenthesis in written
documentation, so &man.chmod.1; refers to the
chmod user command and &man.chmod.2; refers to the
system call.This is fine if you know the name of the command and simply wish to
know how to use it, but what if you cannot recall the command name? You
can use man to search for keywords in the command
descriptions by using the
switch:&prompt.user; man -k mailWith this command you will be presented with a list of commands that
have the keyword “mail” in their descriptions. This is
actually functionally equivalent to using the apropos
command.So, you are looking at all those fancy commands in
/usr/bin but do not even have the faintest idea
what most of them actually do? Simply do a
&prompt.user; cd /usr/bin; man -f *
or
&prompt.user; cd /usr/bin; whatis *
which does the same thing.GNU Info FilesFreeBSD includes many applications and utilities produced by the
Free Software Foundation (FSF). In addition to man pages, these
programs come with more extensive hypertext documents called
“info” files which can be viewed with the
info command or, if you installed
emacs, the info mode of
emacs.To use the &man.info.1; command, simply type:&prompt.user; infoFor a brief introduction, type h. For a
quick command reference, type ?.
diff --git a/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml b/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
index 3666b3bc11..872cb4615c 100644
--- a/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/bibliography/chapter.sgml
@@ -1,478 +1,478 @@
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.FreeBSD mit Methode (in German), published by Computer und
Literatur Verlag/Vertrieb Hanser, 1998. ISBN 3-932311-31-0.FreeBSD Install and Utilization Manual (in Japanese), published by Mainichi Communications Inc..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-6Ohio State
University has written a UNIX
Introductory Course which is available online in HTML and
postscript format.Jpman Project, Japan
FreeBSD Users Group. FreeBSD User's
Reference Manual (Japanese translation). Mainichi Communications
Inc., 1998. ISBN4-8399-0088-4 P3800E.Administrators' GuidesAlbitz, Paul and Liu, Cricket. DNS and
BIND, 2nd Ed. O'Reilly & Associates, Inc., 1997.
ISBN 1-56592-236-0Computer 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-0Frisch, Æleen. Essential System
Administration, 2nd Ed. O'Reilly & Associates,
Inc., 1995. ISBN 1-56592-127-5Hunt, 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-7Jpman Project, Japan
FreeBSD Users Group. FreeBSD System
Administrator's Manual (Japanese translation). Mainichi Communications
Inc., 1998. ISBN4-8399-0109-0 P3300E.Programmers' 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-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. Porting 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. 2nd Ed, PTR Prentice Hall, 1998. ISBN
0-13-490012-XWells, 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-9Schimmel, Curt. Unix Systems for Modern
Architectures. Reading, Mass. : Addison-Wesley, 1994.
ISBN 0-201-63338-8Stevens, 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 Internet Security: Repelling the Wily Hacker.
Reading, Mass. : Addison-Wesley, 1995. ISBN
0-201-63357-4Garfinkel, Simson and Gene Spafford. Practical UNIX
Security. 2nd Ed. O'Reilly & Associates, Inc.,
1996. ISBN 1-56592-148-8Garfinkel, Simson. PGP Pretty Good
Privacy O'Reilly & Associates, Inc., 1995. ISBN
1-56592-098-8Hardware 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-7Intel Corporation publishes documentation on their CPUs,
chipsets and standards on their developer web site,
usually as PDF files.Shanley, 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 Dictionary, 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. ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/misc/bsd-family-tree 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/Old BSD releases from the Computer Systems Research
group (CSRG). http://www.mckusick.com/csrg/:
The 4CD set covers all BSD versions from 1BSD to 4.4BSD and
4.4BSD-Lite2 (but not 2.11BSD, unfortunately). As well, the last
disk holds the final sources plus the SCCS files.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-2688
diff --git a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
index ad51a1de65..15d5bdb3d7 100644
--- a/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/contrib/chapter.sgml
@@ -1,5804 +1,5804 @@
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;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.eivind;Fix the union file system. Coordinator: &a.dg;Implement Int13 vm86 disk driver. Coordinator:
&a.hackers;New bus architecture. Coordinator: &a.newbus;Port existing ISA drivers to new architecture.Move all interrupt-management code to appropriate parts of
the bus drivers.Port PCI subsystem to new architecture. Coordinator:
&a.dfr;Figure out the right way to handle removable devices and
then use that as a substrate on which PC-Card and CardBus
support can be implemented.Resolve the probe/attach priority issue once and for
all.Move any remaining buses over to the new
architecture.Kernel issues. Overall coordination: &a.hackers;Add more pro-active security infrastructure. Overall
coordination: &a.security;Build something like Tripwire(TM) into the kernel, with a
remote and local part. There are a number of cryptographic
issues to getting this right; contact the coordinator for
details. Coordinator: &a.eivind;Make the entire kernel use suser()
instead of comparing to 0. It is presently using about half
of each. Coordinator: &a.eivind;Split securelevels into different parts, to allow an
administrator to throw away those privileges he can throw
away. Setting the overall securelevel needs to have the same
effect as now, obviously. Coordinator: &a.eivind;Make it possible to upload a list of “allowed
program” to BPF, and then block BPF from accepting other
programs. This would allow BPF to be used e.g. for DHCP,
without allowing an attacker to start snooping the local
network.Update the security checker script. We should at least
grab all the checks from the other BSD derivatives, and add
checks that a system with securelevel increased also have
reasonable flags on the relevant parts. Coordinator:
&a.eivind;Add authorization infrastructure to the kernel, to allow
different authorization policies. Part of this could be done
by modifying suser(). Coordinator:
&a.eivind;Add code to the NFS layer so that you cannot
chdir("..") out of an NFS partition. E.g.,
/usr is a UFS partition with
/usr/src NFS exported. Now it is
possible to use the NFS filehandle for
/usr/src to get access to
/usr.Medium priority tasksThe following tasks need to be done, but not with any particular
urgency:Full KLD based driver support/Configuration Manager.Write a configuration manager (in the 3rd stage boot?)
that probes your hardware in a sane manner, keeps only the
KLDs required for your hardware, etc.PCMCIA/PCCARD. Coordinators: &a.msmith; 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.msmith; 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 N items are from Terry Lambert
terry@lambert.orgNetWare 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.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).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 &ng.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!Work through the PR databaseThe FreeBSD PR
list shows all the current active problem reports and
requests for enhancement that have been submitted by FreeBSD users.
Look through the open PRs, and see if anything there takes your
interest. Some of these might be very simple tasks, that just need an
extra pair of eyes to look over them and confirm that the fix in the
PR is a good one. Others might be much more complex.Start with the PRs that have not been assigned to anyone else, but
if one them is assigned to someone else, but it looks like something
you can handle, e-mail the person it is assigned to and ask if you can
work on it—they might already have a patch ready to be tested,
or further ideas that you can discuss with them.How to ContributeContributions to the system generally fall into one or more of the
following 6 categories:Bug reports and general commentaryAn 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 mailing lists 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 &man.send-pr.1; program 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.
When including patches, do not use cut-and-paste
because cut-and-paste turns tabs into spaces and makes them unusable.
Consider compressing patches and using &man.uuencode.1; if they exceed
20KB. Upload very large submissions to ftp.FreeBSD.org:/pub/FreeBSD/incoming/.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 &man.send-pr.1; 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 Bug Reports and General
Commentary.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 Staying current with FreeBSD 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 &man.diff.1;
command, with the “context diff” form
being preferred. For example:&prompt.user; diff -c oldfile newfile
or
&prompt.user; 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 &man.diff.1; for more
details.Once you have a set of diffs (which you may test with the
&man.patch.1; command), you should submit them for inclusion with
FreeBSD. Use the &man.send-pr.1; program as described in Bug Reports and General Commentary.
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 &man.uuencode.1; 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 &man.send-pr.1;. 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.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(c)(3) (charitable)
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.dg;
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 Hubbard4041 Pike Lane, Suite FConcordCA, 94520(currently using the Walnut Creek CDROM address until a PO box
can be opened)Wire transfers may also be sent directly to:Bank Of AmericaConcord Main OfficeP.O. Box 37176San FranciscoCA, 94137-5176Routing #: 121-000-358Account #: 01411-07441 (FreeBSD, Inc.)Any correspondence related to donations should be sent to &a.jkh,
either via email or to the FreeBSD, Inc. postal address given above.
If you do not wish to be listed in our donors 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.dg;
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
admin@FreeBSD.org 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:&a.mbarkah and his employer,
Hemisphere Online, donated a Pentium Pro
(P6) 200Mhz CPUASA
Computers donated a Tyan 1662
motherboard.Joe McGuckin joe@via.net of ViaNet Communications donated
a Kingston ethernet controller.Jack O'Neill jack@diamond.xtalwind.net
donated an NCR 53C875 SCSI controller
card.Ulf Zimmermann ulf@Alameda.net 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 Anderson
ANDRSN@HOOVER.STANFORD.EDU&a.dillonEpilogue Technology
Corporation&a.sefDon Scott WildeGianmarco Giovannelli
gmarco@masternet.itJosef C. Grosch joeg@truenorth.orgRobert T. Morris&a.chuckrKenneth P. Stox ken@stox.sa.enteract.com of
Imaginary Landscape,
LLC.Dmitry S. Kohmanyuk dk@dog.farm.orgLaser5 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.BuffNETPacific
SolutionsSiemens AG
via Andre
AlbsmeierChris SilvaHardware 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.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 kuku@FreeBSD.org 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 history 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
doscmd command.Core Team AlumniThe following people were members of the FreeBSD core team during
the periods indicated. We thank them for their past efforts in the
service of the FreeBSD project.In rough chronological order:&a.guido (1995 - 1999)&a.dyson (1993 - 1998)&a.nate (1992 - 1996)&a.rgrimes (1992 - 1995)Andreas Schulz (1992 - 1995)&a.csgr (1993 - 1995)&a.paul (1992 - 1995)&a.smace (1993 - 1994)Andrew Moore (1993 - 1994)Christoph Robitschko (1993 - 1994)J. T. Conklin (1992 - 1993)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 and OpenBSD that have been
integrated into FreeBSD as well, and we would therefore like to thank
all the contributors to NetBSD and OpenBSD for their work.Additional FreeBSD Contributors(in alphabetical order by first name):ABURAYA Ryushirou rewsirow@ff.iij4u.or.jpAMAGAI Yoshiji amagai@nue.orgAaron Bornstein aaronb@j51.comAaron Smith aaron@mutex.orgAchim Patzner ap@noses.comAda T Lim ada@bsd.orgAdam Baran badam@mw.mil.plAdam Glass glass@postgres.berkeley.eduAdam McDougall mcdouga9@egr.msu.eduAdrian Colley aecolley@ois.ieAdrian Hall adrian@ibmpcug.co.ukAdrian Mariano adrian@cam.cornell.eduAdrian Steinmann ast@marabu.chAdam Strohl troll@digitalspark.netAdrian T. Filipi-Martin
atf3r@agate.cs.virginia.eduAjit Thyagarajan unknownAkio Morita
amorita@meadow.scphys.kyoto-u.ac.jpAkira SAWADA unknownAkira Watanabe
akira@myaw.ei.meisei-u.ac.jpAkito Fujita fujita@zoo.ncl.omron.co.jpAlain Kalker
A.C.P.M.Kalker@student.utwente.nlAlan Bawden alan@curry.epilogue.comAlec Wolman wolman@cs.washington.eduAled Morris aledm@routers.co.ukAlex garbanzo@hooked.netAlex D. Chen
dhchen@Canvas.dorm7.nccu.edu.twAlex G. Bulushev bag@demos.suAlex Le Heux alexlh@funk.orgAlex Perel veers@disturbed.netAlexander B. Povolotsky tarkhil@mgt.msk.ruAlexander Leidinger
netchild@wurzelausix.CS.Uni-SB.DEAlexander Langer alex@cichlids.comAlexandre Snarskii snar@paranoia.ruAlistair G. Crooks agc@uts.amdahl.comAllan Saddi asaddi@philosophysw.comAllen Campbell allenc@verinet.comAmakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jpAmancio Hasty hasty@star-gate.comAmir Farah amir@comtrol.comAmy Baron amee@beer.orgAnatoly A. Orehovsky tolik@mpeks.tomsk.suAnatoly Vorobey mellon@pobox.comAnders Nordby nickerne@nome.noAnders Thulin Anders.X.Thulin@telia.seAndras Olah olah@cs.utwente.nlAndre Albsmeier
Andre.Albsmeier@mchp.siemens.deAndre Oppermann andre@pipeline.chAndreas Haakh ah@alman.robin.deAndreas Kohout shanee@rabbit.augusta.deAndreas Lohr andreas@marvin.RoBIN.deAndreas Schulz unknownAndreas Wetzel mickey@deadline.snafu.deAndreas Wrede andreas@planix.comAndres Vega Garcia unknownAndrew Atrens atreand@statcan.caAndrew Boothman andrew@cream.orgAndrew Gillham gillham@andrews.eduAndrew Gordon andrew.gordon@net-tel.co.ukAndrew Herbert andrew@werple.apana.org.auAndrew J. Korty ajk@purdue.eduAndrew L. Moore alm@mclink.comAndrew McRae amcrae@cisco.comAndrew Stevenson andrew@ugh.net.auAndrew Timonin tim@pool1.convey.ruAndrew V. Stesin stesin@elvisti.kiev.uaAndrew Webster awebster@dataradio.comAndrey Zakhvatov andy@icc.surw.chel.suAndy Farkas andyf@speednet.com.auAndy Valencia ajv@csd.mot.comAndy Whitcroft andy@sarc.city.ac.ukAngelo Turetta ATuretta@stylo.itAnthony C. Chavez magus@xmission.comAnthony Yee-Hang Chan yeehang@netcom.comAnton Berezin tobez@plab.ku.dkAntti Kaipila anttik@iki.fiAre Bryne are.bryne@communique.noAri Suutari ari@suutari.iki.fiArjan de Vet devet@IAEhv.nlArne Henrik Juul arnej@Lise.Unit.NOAssar Westerlund assar@sics.seAtsushi Furuta furuta@sra.co.jpAtsushi Murai amurai@spec.co.jpBakul Shah bvs@bitblocks.comBarry Bierbauch pivrnec@vszbr.czBarry Lustig barry@ictv.comBen Hutchinson benhutch@xfiles.org.ukBen Jackson unknownBen Smithurst ben@scientia.demon.co.ukBen Walter bwalter@itachi.swcp.comBenjamin Lewis bhlewis@gte.netBernd Rosauer br@schiele-ct.deBill Kish kish@osf.orgBill Trost trost@cloud.rain.comBlaz Zupan blaz@amis.netBob Van Valzah Bob@whitebarn.comBob Willcox bob@luke.pmr.comBoris Staeblow balu@dva.in-berlin.deBoyd R. Faulkner faulkner@asgard.bga.comBrad Karp karp@eecs.harvard.eduBradley Dunn bradley@dunn.orgBrandon Fosdick bfoz@glue.umd.eduBrandon Gillespie brandon@roguetrader.com&a.wlloydBob Wilcox bob@obiwan.uucpBoyd Faulkner faulkner@mpd.tandem.comBrent J. Nordquist bjn@visi.comBrett Lymn blymn@mulga.awadi.com.AUBrett Taylor
brett@peloton.physics.montana.eduBrian Campbell brianc@pobox.comBrian Clapper bmc@willscreek.comBrian Cully shmit@kublai.comBrian Handy
handy@lambic.space.lockheed.comBrian Litzinger brian@MediaCity.comBrian McGovern bmcgover@cisco.comBrian Moore ziff@houdini.eecs.umich.eduBrian R. Haug haug@conterra.comBrian Tao taob@risc.orgBrion Moss brion@queeg.comBruce A. Mah bmah@ca.sandia.govBruce Albrecht bruce@zuhause.mn.orgBruce Gingery bgingery@gtcs.comBruce J. Keeler loodvrij@gridpoint.comBruce Murphy packrat@iinet.net.auBruce Walter walter@fortean.comCarey Jones mcj@acquiesce.orgCarl Fongheiser cmf@netins.netCarl Mascott cmascott@world.std.comCasper casper@acc.amCastor Fu castor@geocast.comCejka Rudolf cejkar@dcse.fee.vutbr.czChain Lee chain@110.netCharles Hannum mycroft@ai.mit.eduCharles Henrich henrich@msu.eduCharles Mott cmott@srv.netCharles Owens owensc@enc.eduChet Ramey chet@odin.INS.CWRU.EduChia-liang Kao clkao@CirX.ORGChiharu Shibata chi@bd.mbn.or.jpChip Norkus unknownChoi Jun Ho junker@jazz.snu.ac.krChris Csanady cc@tarsier.ca.sandia.govChris Dabrowski chris@vader.orgChris Dillon cdillon@wolves.k12.mo.usChris Shenton
cshenton@angst.it.hq.nasa.govChris Stenton jacs@gnome.co.ukChris Timmons skynyrd@opus.cts.cwu.eduChris Torek torek@ee.lbl.govChristian Gusenbauer
cg@fimp01.fim.uni-linz.ac.atChristian Haury Christian.Haury@sagem.frChristian Weisgerber
naddy@bigeye.rhein-neckar.deChristoph P. Kukulies kuku@FreeBSD.orgChristoph Robitschko
chmr@edvz.tu-graz.ac.atChristoph Weber-Fahr
wefa@callcenter.systemhaus.netChristopher G. Demetriou
cgd@postgres.berkeley.eduChristopher T. Johnson
cjohnson@neunacht.netgsi.comChrisy Luke chrisy@flix.netChuck Hein chein@cisco.comClive Lin clive@CiRX.ORGColman Reilly careilly@tcd.ieConrad Sabatier conrads@neosoft.comCoranth Gryphon gryphon@healer.comCornelis van der Laan
nils@guru.ims.uni-stuttgart.deCove Schneider cove@brazil.nbn.comCraig Leres leres@ee.lbl.govCraig Loomis unknownCraig Metz cmetz@inner.netCraig Spannring cts@internetcds.comCraig Struble cstruble@vt.eduCristian Ferretti cfs@riemann.mat.puc.clCurt Mayer curt@toad.comCy Schubert cschuber@uumail.gov.bc.caDI. Christian Gusenbauer
cg@scotty.edvz.uni-linz.ac.atDai Ishijima ishijima@tri.pref.osaka.jpDaisuke Watanabe NU7D-WTNB@asahi-net.or.jpDamian Hamill damian@cablenet.netDan Cross tenser@spitfire.ecsel.psu.eduDan Lukes dan@obluda.czDan Nelson dnelson@emsphone.comDan Walters hannibal@cyberstation.netDaniel M. Eischen
deischen@iworks.InterWorks.orgDaniel O'Connor doconnor@gsoft.com.auDaniel Poirot poirot@aio.jsc.nasa.govDaniel Rock rock@cs.uni-sb.deDanny Egen unknownDanny J. Zerkel dzerkel@phofarm.comDarren Reed avalon@coombs.anu.edu.auDave Adkins adkin003@tc.umn.eduDave Andersen angio@aros.netDave Blizzard dblizzar@sprynet.comDave Bodenstab imdave@synet.netDave Burgess burgess@hrd769.brooks.af.milDave Chapeskie dchapes@ddm.on.caDave Cornejo dave@dogwood.comDave Edmondson davided@sco.comDave Glowacki dglo@ssec.wisc.eduDave Marquardt marquard@austin.ibm.comDave Tweten tweten@FreeBSD.orgDavid A. Adkins adkin003@tc.umn.eduDavid A. Bader dbader@umiacs.umd.eduDavid Borman dab@bsdi.comDavid Dawes dawes@XFree86.orgDavid Filo filo@yahoo.comDavid Holland dholland@eecs.harvard.eduDavid Holloway daveh@gwythaint.tamis.comDavid Horwitt dhorwitt@ucsd.eduDavid Hovemeyer daveho@infocom.comDavid Jones dej@qpoint.torfree.netDavid Kelly dkelly@tomcat1.tbe.comDavid Kulp dkulp@neomorphic.comDavid L. Nugent davidn@blaze.net.auDavid Leonard d@scry.dstc.edu.auDavid Malone dwmalone@maths.tcd.ieDavid Muir Sharnoff muir@idiom.comDavid S. Miller davem@jenolan.rutgers.eduDavid Wolfskill dhw@whistle.comDean Gaudet dgaudet@arctic.orgDean Huxley dean@fsa.caDenis Fortin unknownDennis Glatting
dennis.glatting@software-munitions.comDenton Gentry denny1@home.comDerek Inksetter derek@saidev.comDima Sivachenko dima@Chg.RUDirk Keunecke dk@panda.rhein-main.deDirk Nehrling nerle@pdv.deDmitry Khrustalev dima@xyzzy.machaon.ruDmitry Kohmanyuk dk@farm.orgDom Mitchell dom@myrddin.demon.co.ukDominik Brettnacher domi@saargate.deDominik Rother dr@domix.deDon Croyle croyle@gelemna.ft-wayne.in.us&a.whiteside;Don Morrison dmorrisn@u.washington.eduDon Yuniskis dgy@rtd.comDonald Maddox dmaddox@conterra.comDoug Barton studded@dal.netDouglas Ambrisko ambrisko@whistle.comDouglas Carmichael dcarmich@mcs.comDouglas Crosher dtc@scrooge.ee.swin.oz.auDrew Derbyshire ahd@kew.comDuncan Barclay dmlb@ragnet.demon.co.ukDustin Sallings dustin@spy.netEckart "Isegrim" Hofmann
Isegrim@Wunder-Nett.orgEd Gold
vegold01@starbase.spd.louisville.eduEd Hudson elh@p5.spnet.comEdward Wang edward@edcom.comEdwin Groothus edwin@nwm.wan.philips.comEiji-usagi-MATSUmoto usagi@clave.gr.jpELISA Font ProjectElmar Bartel
bartel@informatik.tu-muenchen.deEric A. Griff eagriff@global2000.netEric Blood eblood@cs.unr.eduEric J. Haug ejh@slustl.slu.eduEric J. Schwertfeger eric@cybernut.comEric L. Hernes erich@lodgenet.comEric P. Scott eps@sirius.comEric Sprinkle eric@ennovatenetworks.comErich Stefan Boleyn erich@uruk.orgErik E. Rantapaa rantapaa@math.umn.eduErik H. Moe ehm@cris.comErnst Winter ewinter@lobo.muc.deEspen Skoglund espensk@stud.cs.uit.no>Eugene M. Kim astralblue@usa.netEugene Radchenko genie@qsar.chem.msu.suEvan Champion evanc@synapse.netFaried Nawaz fn@Hungry.COMFlemming Jacobsen fj@tfs.comFong-Ching Liaw fong@juniper.netFrancis M J Hsieh mjshieh@life.nthu.edu.twFrank Bartels knarf@camelot.deFrank Chen Hsiung Chan
frankch@waru.life.nthu.edu.twFrank Durda IV uhclem@nemesis.lonestar.orgFrank MacLachlan fpm@n2.netFrank Nobis fn@Radio-do.deFrank Volf volf@oasis.IAEhv.nlFrank ten Wolde franky@pinewood.nlFrank van der Linden frank@fwi.uva.nlFred Cawthorne fcawth@jjarray.umn.eduFred Gilham gilham@csl.sri.comFred Templin templin@erg.sri.comFrederick Earl Gray fgray@rice.eduFUJIMOTO Kensaku
fujimoto@oscar.elec.waseda.ac.jpFUJISHIMA Satsuki k5@respo.or.jpFURUSAWA Kazuhisa
furusawa@com.cs.osakafu-u.ac.jpGabor Kincses gabor@acm.orgGabor Zahemszky zgabor@CoDe.huG. Adam Stanislavadam@whizkidtech.netGarance A Drosehn gad@eclipse.its.rpi.eduGareth McCaughan gjm11@dpmms.cam.ac.ukGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGary J. garyj@rks32.pcs.dec.comGary Kline kline@thought.orgGaspar Chilingarov nightmar@lemming.acc.amGea-Suan Lin gsl@tpts4.seed.net.twGeoff Rehmet csgr@alpha.ru.ac.zaGeorg Wagner georg.wagner@ubs.comGerard Roudier groudier@club-internet.frGianmarco Giovannelli
gmarco@giovannelli.itGil Kloepfer Jr. gil@limbic.ssdl.comGilad Rom rom_glsa@ein-hashofet.co.ilGinga Kawaguti
ginga@amalthea.phys.s.u-tokyo.ac.jpGiles Lean giles@nemeton.com.auGlen Foster gfoster@gfoster.comGlenn Johnson gljohns@bellsouth.netGodmar Back gback@facility.cs.utah.eduGoran Hammarback goran@astro.uu.seGord Matzigkeit gord@enci.ucalgary.caGordon Greeff gvg@uunet.co.zaGraham Wheeler gram@cdsec.comGreg A. Woods woods@zeus.leitch.comGreg Ansley gja@ansley.comGreg Troxel gdt@ir.bbn.comGreg Ungerer gerg@stallion.oz.auGregory Bond gnb@itga.com.auGregory D. Moncreaff
moncrg@bt340707.res.ray.comGuy Harris guy@netapp.comGuy Helmer ghelmer@cs.iastate.eduHAMADA Naoki hamada@astec.co.jpHONDA Yasuhiro
honda@kashio.info.mie-u.ac.jpHOSOBUCHI Noriyuki hoso@buchi.tama.or.jpHannu Savolainen hannu@voxware.pp.fiHans Huebner hans@artcom.deHans Petter Bieker zerium@webindex.noHans Zuidam hans@brandinnovators.comHarlan Stenn Harlan.Stenn@pfcs.comHarold Barker hbarker@dsms.comHavard Eidnes
Havard.Eidnes@runit.sintef.noHeikki Suonsivu hsu@cs.hut.fiHeiko W. Rupp unknownHelmut F. Wirth hfwirth@ping.atHenrik Vestergaard Draboel
hvd@terry.ping.dkHerb Peyerl hpeyerl@NetBSD.orgHideaki Ohmon ohmon@tom.sfc.keio.ac.jpHidekazu Kuroki hidekazu@cs.titech.ac.jpHideki Yamamoto hyama@acm.orgHideyuki Suzuki
hideyuki@sat.t.u-tokyo.ac.jpHirayama Issei iss@mail.wbs.ne.jpHiroaki Sakai sakai@miya.ee.kagu.sut.ac.jpHiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jpHironori Ikura hikura@kaisei.orgHiroshi Nishikawa nis@pluto.dti.ne.jpHiroya Tsubakimoto unknownHolger Veit Holger.Veit@gmd.deHolm Tiffe holm@geophysik.tu-freiberg.deHorance Chou
horance@freedom.ie.cycu.edu.twHorihiro Kumagai kuma@jp.FreeBSD.orgHOTARU-YA hotaru@tail.netHr.Ladavac lada@ws2301.gud.siemens.co.atHubert Feyrer hubertf@NetBSD.ORGHugh F. Mahon hugh@nsmdserv.cnd.hp.comHugh Mahon h_mahon@fc.hp.comHung-Chi Chu hcchu@r350.ee.ntu.edu.twIMAI Takeshi take-i@ceres.dti.ne.jpIMAMURA Tomoaki
tomoak-i@is.aist-nara.ac.jpIan Dowse iedowse@maths.tcd.ieIan Holland ianh@tortuga.com.auIan Struble ian@broken.netIan Vaudrey i.vaudrey@bigfoot.comIgor Khasilev igor@jabber.paco.odessa.uaIgor Roshchin str@giganda.komkon.orgIgor Sviridov siac@ua.netIgor Vinokurov igor@zynaps.ruIkuo Nakagawa ikuo@isl.intec.co.jpIlya V. Komarov mur@lynx.ruIssei Suzuki issei@jp.FreeBSD.orgItsuro Saito saito@miv.t.u-tokyo.ac.jpJ. Bryant jbryant@argus.flash.netJ. David Lowe lowe@saturn5.comJ. Han hjh@best.comJ. Hawk jhawk@MIT.EDUJ.T. Conklin jtc@cygnus.comJ.T. Jang keith@email.gcn.net.twJack jack@zeus.xtalwind.netJacob Bohn Lorensen jacob@jblhome.ping.mkJagane D Sundar jagane@netcom.comJake Burkholder jake@checker.orgJake Hamby jehamby@lightside.comJames Clark jjc@jclark.comJames D. Stewart jds@c4systm.comJames Jegers jimj@miller.cs.uwm.eduJames Raynard
fhackers@jraynard.demon.co.ukJames T. Liu jtliu@phlebas.rockefeller.eduJames da Silva jds@cs.umd.eduJan Conard
charly@fachschaften.tu-muenchen.deJan Koum jkb@FreeBSD.orgJanick Taillandier
Janick.Taillandier@ratp.frJanusz Kokot janek@gaja.ipan.lublin.plJarle Greipsland jarle@idt.unit.noJason Garman init@risen.orgJason Thorpe thorpej@NetBSD.orgJason Wright jason@OpenBSD.orgJason Young
doogie@forbidden-donut.anet-stl.comJavier Martin Rueda jmrueda@diatel.upm.esJay Fenlason hack@datacube.comJaye Mathisen mrcpu@cdsnet.netJeff Bartig jeffb@doit.wisc.eduJeff Forys jeff@forys.cranbury.nj.usJeff Kletsky Jeff@Wagsky.comJeffrey Evans evans@scnc.k12.mi.usJeffrey Wheat jeff@cetlink.netJens Schweikhardt schweikh@noc.dfn.dJeremy Allison jallison@whistle.comJeremy Chatfield jdc@xinside.comJeremy Lea reg@shale.csir.co.zaJeremy Prior unknownJeroen Ruigrok/Asmodai asmodai@wxs.nlJesse Rosenstock jmr@ugcs.caltech.eduJian-Da Li jdli@csie.nctu.edu.twJim Babb babb@FreeBSD.orgJim Binkley jrb@cs.pdx.eduJim Carroll jim@carroll.comJim Flowers jflowers@ezo.netJim Leppek jleppek@harris.comJim Lowe james@cs.uwm.eduJim Mattson jmattson@sonic.netJim Mercer jim@komodo.reptiles.orgJim Wilson wilson@moria.cygnus.comJimbo Bahooli
griffin@blackhole.iceworld.orgJin Guojun jin@george.lbl.govJoachim Kuebart unknownJoao Carlos Mendes Luis jonny@jonny.eng.brJochen Pohl jpo.drs@sni.deJoe "Marcus" Clarke marcus@miami.eduJoe Abley jabley@clear.co.nzJoe Jih-Shian Lu jslu@dns.ntu.edu.twJoe Orthoefer j_orthoefer@tia.netJoe Traister traister@mojozone.orgJoel Faedi Joel.Faedi@esial.u-nancy.frJoel Ray Holveck joelh@gnu.orgJoel Sutton sutton@aardvark.apana.org.auJohan Granlund johan@granlund.nuJohan Karlsson k@numeri.campus.luth.seJohan Larsson johan@moon.campus.luth.seJohann Tonsing jtonsing@mikom.csir.co.zaJohannes Helander unknownJohannes Stille unknownJohn Baldwin jobaldwi@vt.eduJohn Beckett jbeckett@southern.eduJohn Beukema jbeukema@hk.super.netJohn Brezak unknownJohn Capo jc@irbs.comJohn F. Woods jfw@jfwhome.funhouse.comJohn Goerzen
jgoerzen@alexanderwohl.complete.orgJohn Hay jhay@mikom.csir.co.zaJohn Heidemann johnh@isi.eduJohn Hood cgull@owl.orgJohn Kohl unknownJohn Lind john@starfire.mn.orgJohn Mackin john@physiol.su.oz.auJohn P johnp@lodgenet.comJohn Perry perry@vishnu.alias.netJohn Preisler john@vapornet.comJohn Rochester jr@cs.mun.caJohn Sadler john_sadler@alum.mit.eduJohn Saunders john@pacer.nlc.net.auJohn W. DeBoskey jwd@unx.sas.comJohn Wehle john@feith.comJohn Woods jfw@eddie.mit.eduJon Morgan morgan@terminus.trailblazer.comJonathan H N Chin jc254@newton.cam.ac.ukJonathan Hanna
jh@pc-21490.bc.rogers.wave.caJorge Goncalves j@bug.fe.up.ptJorge M. Goncalves ee96199@tom.fe.up.ptJos Backus jbackus@plex.nlJose M. Alcaide jose@we.lc.ehu.esJose Marques jose@nobody.orgJosef Grosch
jgrosch@superior.mooseriver.comJosef Karthauser joe@uk.FreeBSD.orgJoseph Stein joes@wstein.comJosh Gilliam josh@quick.netJosh Tiefenbach josh@ican.netJuergen Lock nox@jelal.hb.north.deJuha Inkari inkari@cc.hut.fiJukka A. Ukkonen jua@iki.fiJulian Assange proff@suburbia.netJulian Coleman j.d.coleman@ncl.ac.uk&a.jhsJulian Jenkins kaveman@magna.com.auJunichi Satoh junichi@jp.FreeBSD.orgJunji SAKAI sakai@jp.FreeBSD.orgJunya WATANABE junya-w@remus.dti.ne.jpK.Higashino a00303@cc.hc.keio.ac.jpKUNISHIMA Takeo kunishi@c.oka-pu.ac.jpKai Vorma vode@snakemail.hut.fiKaleb S. Keithley kaleb@ics.comKaneda Hiloshi vanitas@ma3.seikyou.ne.jpKapil Chowksey kchowksey@hss.hns.comKarl Denninger karl@mcs.comKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comKato Takenori
kato@eclogite.eps.nagoya-u.ac.jpKATO Tsuguru tkato@prontomail.ne.jpKawanobe Koh kawanobe@st.rim.or.jpKazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jpKazuo Horikawa horikawa@jp.FreeBSD.orgKees Jan Koster kjk1@ukc.ac.ukKeith Bostic bostic@bostic.comKeith E. Walker unknownKeith Moore unknownKeith Sklower unknownKelly Yancey kbyanc@posi.netKen Hornstein unknownKen Key key@cs.utk.eduKen Mayer kmayer@freegate.comKenji Saito marukun@mx2.nisiq.netKenji Tomita tommyk@da2.so-net.or.jpKenneth Furge kenneth.furge@us.endress.comKenneth Monville desmo@bandwidth.orgKenneth R. Westerback krw@tcn.netKenneth Stailey kstailey@gnu.ai.mit.eduKent Talarico kent@shipwreck.tsoft.netKent Vander Velden graphix@iastate.eduKentaro Inagaki JBD01226@niftyserve.ne.jpKevin Bracey kbracey@art.acorn.co.ukKevin Day toasty@dragondata.comKevin Lahey kml@nas.nasa.govKevin Lokevlo@hello.com.twKevin Street street@iname.comKevin Van Maren vanmaren@fast.cs.utah.eduKiroh HARADA kiroh@kh.rim.or.jpKlaus Klein kleink@layla.inka.deKlaus-J. Wolf Yanestra@t-online.deKoichi Sato copan@ppp.fastnet.or.jpKostya Lukin lukin@okbmei.msk.suKouichi Hirabayashi kh@mogami-wire.co.jpKurt D. Zeilenga Kurt@Boolean.NETKurt Olsen kurto@tiny.mcs.usu.eduL. Jonas Olsson
ljo@ljo-slip.DIALIN.CWRU.EduLars Köller
Lars.Koeller@Uni-Bielefeld.DELarry Altneu larry@ALR.COMLaurence Lopez lopez@mv.mv.comLee Cremeans lcremean@tidalwave.netLiang Tai-hwa
avatar@www.mmlab.cse.yzu.edu.twLon Willett lon%softt.uucp@math.utah.eduLouis A. Mamakos louie@TransSys.COMLouis Mamakos loiue@TransSys.comLucas James Lucas.James@ldjpc.apana.org.auLyndon Nerenberg lyndon@orthanc.comM.C. Wong unknownMANTANI Nobutaka nobutaka@nobutaka.comMIHIRA Sanpei Yoshiro sanpei@sanpei.orgMITA Yoshio mita@jp.FreeBSD.orgMITSUNAGA Noriaki
mitchy@er.ams.eng.osaka-u.ac.jpMOROHOSHI Akihiko moro@race.u-tokyo.ac.jpMagnus Enbom dot@tinto.campus.luth.seMahesh Neelakanta mahesh@gcomm.comMakoto MATSUSHITA matusita@jp.FreeBSD.orgMakoto WATANABE
watanabe@zlab.phys.nagoya-u.ac.jpMalte Lance malte.lance@gmx.netManu Iyengar
iyengar@grunthos.pscwa.psca.comMarc Frajola marc@dev.comMarc Ramirez mrami@mramirez.sy.yale.eduMarc Slemko marcs@znep.comMarc van Kempen wmbfmk@urc.tue.nlMarc van Woerkom van.woerkom@netcologne.deMarcel Moolenaar marcel@scc.nlMario Sergio Fujikawa Ferreira
lioux@gns.com.brMark Andrews unknownMark Cammidge mark@gmtunx.ee.uct.ac.zaMark Diekhans markd@grizzly.comMark Huizer xaa@stack.nlMark J. Taylor mtaylor@cybernet.comMark Krentel krentel@rice.eduMark Mayo markm@vmunix.comMark Thompson thompson@tgsoft.comMark Tinguely tinguely@plains.nodak.eduMark Treacy unknownMark Valentine mark@linus.demon.co.ukMartin BirgmeierMartin Ibert mib@ppe.bb-data.deMartin Kammerhofer dada@sbox.tu-graz.ac.atMartin Renters martin@tdc.on.caMartti Kuparinen
martti.kuparinen@ericsson.comMasachika ISHIZUKA
ishizuka@isis.min.ntt.jpMas.TAKEMURA unknownMasafumi NAKANE max@wide.ad.jpMasahiro Sekiguchi
seki@sysrap.cs.fujitsu.co.jpMasanobu Saitoh msaitoh@spa.is.uec.ac.jpMasanori Kanaoka kana@saijo.mke.mei.co.jpMasanori Kiriake seiken@ARGV.ACMasatoshi TAMURA
tamrin@shinzan.kuee.kyoto-u.ac.jpMats Lofkvist mal@algonet.seMatt Bartley mbartley@lear35.cytex.comMatt Thomas matt@3am-software.comMatt White mwhite+@CMU.EDUMatthew C. Mead mmead@Glock.COMMatthew Cashdollar mattc@rfcnet.comMatthew Flatt mflatt@cs.rice.eduMatthew Fuller fullermd@futuresouth.comMatthew Stein matt@bdd.netMatthias Pfaller leo@dachau.marco.deMatthias Scheler tron@netbsd.orgMattias Gronlund
Mattias.Gronlund@sa.erisoft.seMattias Pantzare pantzer@ludd.luth.seMaurice Castro
maurice@planet.serc.rmit.edu.auMax Euston meuston@jmrodgers.comMax Khon fjoe@husky.iclub.nsu.ruMaxim Bolotin max@rsu.ruMaxim V. Sobolev sobomax@altavista.netMicha Class
michael_class@hpbbse.bbn.hp.comMichael Butler imb@scgt.oz.auMichael Butschky butsch@computi.erols.comMichael Clay mclay@weareb.orgMichael Elbel me@FreeBSD.orgMichael Galassi nerd@percival.rain.comMichael Hancock michaelh@cet.co.jpMichael Hohmuth hohmuth@inf.tu-dresden.deMichael Perlman canuck@caam.rice.eduMichael Petry petry@netwolf.NetMasters.comMichael Reifenberger root@totum.plaut.deMichael Sardo jaeger16@yahoo.comMichael Searle searle@longacre.demon.co.ukMichal Listos mcl@Amnesiac.123.orgMichio Karl Jinbo
karl@marcer.nagaokaut.ac.jpMiguel Angel Sagreras
msagre@cactus.fi.uba.arMihoko Tanaka m_tonaka@pa.yokogawa.co.jpMika Nystrom mika@cs.caltech.eduMikael Hybsch micke@dynas.seMikael Karpberg
karpen@ocean.campus.luth.seMike Del repenting@hotmail.comMike Durian durian@plutotech.comMike Durkin mdurkin@tsoft.sf-bay.orgMike E. Matsnev mike@azog.cs.msu.suMike Evans mevans@candle.comMike Grupenhoff kashmir@umiacs.umd.eduMike Hibler mike@marker.cs.utah.eduMike Karels unknownMike McGaughey mmcg@cs.monash.edu.auMike Meyer mwm@shiva.the-park.comMike Mitchell mitchell@ref.tfs.comMike Murphy mrm@alpharel.comMike Peck mike@binghamton.eduMike Spengler mks@msc.eduMikhail A. Sokolov mishania@demos.suMikhail Teterin mi@aldan.ziplink.netMing-I Hseh PA@FreeBSD.ee.Ntu.edu.TWMitsuru IWASAKI iwasaki@pc.jaring.myMitsuru Yoshida mitsuru@riken.go.jpMonte Mitzelfelt monte@gonefishing.orgMorgan Davis root@io.cts.comMostyn Lewis mostyn@mrl.comMotomichi Matsuzaki mzaki@e-mail.ne.jpMotoyuki Kasahara m-kasahr@sra.co.jpMotoyuki Konno motoyuki@snipe.rim.or.jpMurray Stokely murray@cdrom.comN.G.Smith ngs@sesame.hensa.ac.ukNAGAO Tadaaki nagao@cs.titech.ac.jpNAKAJI Hiroyuki
nakaji@tutrp.tut.ac.jpNAKAMURA Kazushi nkazushi@highway.or.jpNAKAMURA Motonori
motonori@econ.kyoto-u.ac.jpNIIMI Satoshi sa2c@and.or.jpNOKUBI Hirotaka h-nokubi@yyy.or.jpNadav Eiron nadav@barcode.co.ilNanbor Wang nw1@cs.wustl.eduNaofumi Honda
honda@Kururu.math.sci.hokudai.ac.jpNaoki Hamada nao@tom-yam.or.jpNarvi narvi@haldjas.folklore.eeNathan Ahlstrom nrahlstr@winternet.comNathan Dorfman nathan@rtfm.netNeal Fachan kneel@ishiboo.comNeil Blakey-Milner nbm@rucus.ru.ac.zaNiall Smart rotel@indigo.ieNick Barnes Nick.Barnes@pobox.comNick Handel nhandel@NeoSoft.comNick Hilliard nick@foobar.org&a.nsayer;Nick Williams njw@cs.city.ac.ukNickolay N. Dudorov nnd@itfs.nsk.suNiklas Hallqvist niklas@filippa.appli.seNisha Talagala nisha@cs.berkeley.eduNo Name ZW6T-KND@j.asahi-net.or.jpNo Name adrian@virginia.eduNo Name alex@elvisti.kiev.uaNo Name anto@netscape.netNo Name bobson@egg.ics.nitch.ac.jpNo Name bovynf@awe.beNo Name burg@is.ge.comNo Name chris@gnome.co.ukNo Name colsen@usa.netNo Name coredump@nervosa.comNo Name dannyman@arh0300.urh.uiuc.eduNo Name davids@SECNET.COMNo Name derek@free.orgNo Name devet@adv.IAEhv.nlNo Name djv@bedford.netNo Name dvv@sprint.netNo Name enami@ba2.so-net.or.jpNo Name flash@eru.tubank.msk.suNo Name flash@hway.ruNo Name fn@pain.csrv.uidaho.eduNo Name gclarkii@netport.neosoft.comNo Name gordon@sheaky.lonestar.orgNo Name graaf@iae.nlNo Name greg@greg.rim.or.jpNo Name grossman@cygnus.comNo Name gusw@fub46.zedat.fu-berlin.deNo Name hfir@math.rochester.eduNo Name hnokubi@yyy.or.jpNo Name iaint@css.tuu.utas.edu.auNo Name invis@visi.comNo Name ishisone@sra.co.jpNo Name iverson@lionheart.comNo Name jpt@magic.netNo Name junker@jazz.snu.ac.krNo Name k-sugyou@ccs.mt.nec.co.jpNo Name kenji@reseau.toyonaka.osaka.jpNo Name kfurge@worldnet.att.netNo Name lh@aus.orgNo Name lhecking@nmrc.ucc.ieNo Name mrgreen@mame.mu.oz.auNo Name nakagawa@jp.FreeBSD.orgNo Name ohki@gssm.otsuka.tsukuba.ac.jpNo Name owaki@st.rim.or.jpNo Name pechter@shell.monmouth.comNo Name pete@pelican.pelican.comNo Name pritc003@maroon.tc.umn.eduNo Name risner@stdio.comNo Name roman@rpd.univ.kiev.uaNo Name root@ns2.redline.ruNo Name root@uglabgw.ug.cs.sunysb.eduNo Name stephen.ma@jtec.com.auNo Name sumii@is.s.u-tokyo.ac.jpNo Name takas-su@is.aist-nara.ac.jpNo Name tamone@eig.unige.chNo Name tjevans@raleigh.ibm.comNo Name tony-o@iij.ad.jp amurai@spec.co.jpNo Name torii@tcd.hitachi.co.jpNo Name uenami@imasy.or.jpNo Name uhlar@netlab.skNo Name vode@hut.fiNo Name wlloyd@mpd.caNo Name wlr@furball.wellsfargo.comNo Name wmbfmk@urc.tue.nlNo Name yamagata@nwgpc.kek.jpNo Name ziggy@ryan.orgNobuhiro Yasutomi nobu@psrc.isac.co.jpNobuyuki Koganemaru
kogane@koganemaru.co.jpNorio Suzuki nosuzuki@e-mail.ne.jpNoritaka Ishizumi graphite@jp.FreeBSD.orgNoriyuki Soda soda@sra.co.jpOh Junseon hollywar@mail.holywar.netOlaf Wagner wagner@luthien.in-berlin.deOleg Sharoiko os@rsu.ruOleg V. Volkov rover@lglobus.ruOliver Breuninger ob@seicom.NETOliver Friedrichs oliver@secnet.comOliver Fromme
oliver.fromme@heim3.tu-clausthal.deOliver Laumann
net@informatik.uni-bremen.deOliver Oberdorf oly@world.std.comOlof Johansson offe@ludd.luth.seOsokin Sergey aka oZZ ozz@FreeBSD.org.ruPace Willisson pace@blitz.comPaco Rosich rosich@modico.eleinf.uv.esPalle Girgensohn girgen@partitur.seParag Patel parag@cgt.comPascal Pederiva pascal@zuo.dec.comPasvorn Boonmark boonmark@juniper.netPatrick Gardella patrick@cre8tivegroup.comPatrick Hausen unknownPaul Antonov apg@demos.suPaul F. Werkowski unknownPaul Fox pgf@foxharp.boston.ma.usPaul Koch koch@thehub.com.auPaul Kranenburg pk@NetBSD.orgPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPaul S. LaFollette, Jr. unknownPaul Saab paul@mu.orgPaul Sandys myj@nyct.netPaul T. Root proot@horton.iaces.comPaul Vixie paul@vix.comPaulo Menezes paulo@isr.uc.ptPaulo Menezes pm@dee.uc.ptPedro A M Vazquez vazquez@IQM.Unicamp.BRPedro Giffuni giffunip@asme.orgPete Bentley pete@demon.netPeter Childs pjchilds@imforei.apana.org.auPeter Cornelius pc@inr.fzk.dePeter Haight peterh@prognet.comPeter Jeremy perer.jeremy@alcatel.com.auPeter M. Chen pmchen@eecs.umich.eduPeter Much peter@citylink.dinoex.sub.orgPeter Olsson unknownPeter Philipp pjp@bsd-daemon.netPeter Stubbs PETERS@staidan.qld.edu.auPhil Maker pjm@cs.ntu.edu.auPhil Sutherland
philsuth@mycroft.dialix.oz.auPhil Taylor phil@zipmail.co.ukPhilip Musumeci philip@rmit.edu.auPierre Y. Dampure pierre.dampure@k2c.co.ukPius Fischer pius@ienet.comPomegranate daver@flag.blackened.netPowerdog Industries
kevin.ruddy@powerdog.comR. Kym HorsellRajesh Vaidheeswarran rv@fore.comRalf Friedl friedl@informatik.uni-kl.deRandal S. Masutani randal@comtest.comRandall Hopper rhh@ct.picker.comRandall W. Dean rwd@osf.orgRandy Bush rbush@bainbridge.verio.netReinier Bezuidenhout
rbezuide@mikom.csir.co.zaRemy Card Remy.Card@masi.ibp.frRicardas Cepas rch@richard.eu.orgRiccardo Veraldi veraldi@cs.unibo.itRichard Henderson richard@atheist.tamu.eduRichard Hwang rhwang@bigpanda.comRichard Kiss richard@homemail.comRichard J Kuhns rjk@watson.grauel.comRichard M. Neswold
rneswold@drmemory.fnal.govRichard Seaman, Jr. dick@tar.comRichard Stallman rms@gnu.ai.mit.eduRichard Straka straka@user1.inficad.comRichard Tobin richard@cogsci.ed.ac.ukRichard Wackerbarth rkw@Dataplex.NETRichard Winkel rich@math.missouri.eduRichard Wiwatowski rjwiwat@adelaide.on.netRick Macklem rick@snowhite.cis.uoguelph.caRick Macklin unknownRob Austein sra@epilogue.comRob Mallory rmallory@qualcomm.comRob Snow rsnow@txdirect.netRobert Crowe bob@speakez.comRobert D. Thrush rd@phoenix.aii.comRobert Eckardt
roberte@MEP.Ruhr-Uni-Bochum.deRobert Sanders rsanders@mindspring.comRobert Sexton robert@kudra.comRobert Shady rls@id.netRobert Swindells swindellsr@genrad.co.ukRobert Watson robert@cyrus.watson.orgRobert Withrow witr@rwwa.comRobert Yoder unknownRobin Carey
robin@mailgate.dtc.rankxerox.co.ukRoger Hardiman roger@cs.strath.ac.ukRoland Jesse jesse@cs.uni-magdeburg.deRon Bickers rbickers@intercenter.netRon Lenk rlenk@widget.xmission.comRonald Kuehn kuehn@rz.tu-clausthal.deRudolf Cejka unknownRuslan Belkin rus@home2.UA.netRuslan Ermilov ru@ucb.crimea.uaRuslan Shevchenko rssh@cam.grad.kiev.uaRussell L. Carter rcarter@pinyon.orgRussell Vincent rv@groa.uct.ac.zaRyan Younce ryany@pobox.comRyuichiro IMURA imura@cs.titech.ac.jpSANETO Takanori sanewo@strg.sony.co.jpSAWADA Mizuki miz@qb3.so-net.ne.jpSUGIMURA Takashi sugimura@jp.FreeBSD.orgSURANYI Peter
suranyip@jks.is.tsukuba.ac.jpSakai Hiroaki sakai@miya.ee.kagu.sut.ac.jpSakari Jalovaara sja@tekla.fiSam Hartman hartmans@mit.eduSamuel Lam skl@ScalableNetwork.comSamuele Zannoli zannoli@cs.unibo.itSander Vesik sander@haldjas.folklore.eeSandro Sigala ssigala@globalnet.itSascha Blank blank@fox.uni-trier.deSascha Wildner swildner@channelz.GUN.deSatoh Junichi junichi@astec.co.jpScot Elliott scot@poptart.orgScot W. Hetzel hetzels@westbend.netScott A. Kenney saken@rmta.ml.orgScott Blachowicz
scott.blachowicz@seaslug.orgScott Burris scott@pita.cns.ucla.eduScott Hazen Mueller scott@zorch.sf-bay.orgScott Michel scottm@cs.ucla.eduScott Mitchel scott@uk.FreeBSD.orgScott Reynolds scott@clmqt.marquette.mi.usSebastian Strollo seb@erix.ericsson.seSerge A. Babkin babkin@hq.icb.chel.suSerge V. Vakulenko vak@zebub.msk.suSergei Chechetkin
csl@whale.sunbay.crimea.uaSergei S. Laskavy laskavy@pc759.cs.msu.suSergey Gershtein sg@mplik.ruSergey Kosyakov ks@itp.ac.ruSergey Potapov sp@alkor.ruSergey Shkonda serg@bcs.zp.uaSergey V.Dorokhov svd@kbtelecom.nalnet.ruSergio Lenzi lenzi@bsi.com.brShaun Courtney shaun@emma.eng.uct.ac.zaShawn M. Carey smcarey@mailbox.syr.eduShigio Yamaguchi shigio@tamacom.comShinya Esu esu@yk.rim.or.jpShuichi Tanaka stanaka@bb.mbn.or.jpShunsuke Akiyama akiyama@jp.FreeBSD.orgSimon simon@masi.ibp.frSimon Burge simonb@telstra.com.auSimon J Gerraty sjg@melb.bull.oz.auSimon Marlow simonm@dcs.gla.ac.ukSimon Shapiro shimon@simon-shapiro.orgSin'ichiro MIYATANI siu@phaseone.co.jpSlaven Rezic eserte@cs.tu-berlin.deSoochon Radee slr@mitre.orgSoren Dayton csdayton@midway.uchicago.eduSoren Dossing sauber@netcom.comSoren S. Jorvang soren@dt.dkStefan Bethke stb@hanse.deStefan Eggers seggers@semyam.dinoco.deStefan Moeding s.moeding@ndh.netStefan Petri unknownStefan `Sec` Zehl sec@42.orgSteinar Haug sthaug@nethelp.noStephane E. Potvin sepotvin@videotron.caStephane Legrand stephane@lituus.frStephen Clawson
sclawson@marker.cs.utah.eduStephen F. Combs combssf@salem.ge.comStephen Farrell stephen@farrell.orgStephen Hocking sysseh@devetir.qld.gov.auStephen J. Roznowski sjr@home.netStephen McKay syssgm@devetir.qld.gov.auStephen Melvin melvin@zytek.comSteve Bauer sbauer@rock.sdsmt.eduSteve Coltrin spcoltri@io.comSteve Deering unknownSteve Gerakines steve2@genesis.tiac.netSteve Gericke steveg@comtrol.comSteve Piette steve@simon.chi.il.USSteve Schwarz schwarz@alpharel.comSteven G. Kargl
kargl@troutmask.apl.washington.eduSteven H. Samorodin samorodi@NUXI.comSteven McCanne mccanne@cs.berkeley.eduSteven Plite splite@purdue.eduSteven Wallace unknownStuart Henderson
stuart@internationalschool.co.ukSue Blake sue@welearn.com.auSugimoto Sadahiro ixtl@komaba.utmc.or.jpSugiura Shiro ssugiura@duo.co.jpSujal Patel smpatel@wam.umd.eduSune Stjerneby stjerneby@usa.netSuzuki Yoshiaki
zensyo@ann.tama.kawasaki.jpTadashi Kumano kumano@strl.nhk.or.jpTaguchi Takeshi taguchi@tohoku.iij.ad.jpTakahiro Yugawa yugawa@orleans.rim.or.jpTakanori Watanabe
takawata@shidahara1.planet.sci.kobe-u.ac.jpTakashi Mega mega@minz.orgTakashi Uozu j1594016@ed.kagu.sut.ac.jpTakayuki Ariga a00821@cc.hc.keio.ac.jpTakeru NAIKI naiki@bfd.es.hokudai.ac.jpTakeshi Amaike amaike@iri.co.jpTakeshi MUTOH mutoh@info.nara-k.ac.jpTakeshi Ohashi
ohashi@mickey.ai.kyutech.ac.jpTakeshi WATANABE
watanabe@crayon.earth.s.kobe-u.ac.jpTakuya SHIOZAKI
tshiozak@makino.ise.chuo-u.ac.jpTatoku Ogaito tacha@tera.fukui-med.ac.jpTatsumi HOSOKAWA hosokawa@jp.FreeBSD.orgTed Buswell tbuswell@mediaone.netTed Faber faber@isi.eduTed Lemon mellon@isc.orgTerry Lambert terry@lambert.orgTerry Lee terry@uivlsi.csl.uiuc.eduTetsuya Furukawa tetsuya@secom-sis.co.jpTheo de Raadt deraadt@OpenBSD.orgThomas thomas@mathematik.uni-Bremen.deThomas D. Dean tomdean@ix.netcom.comThomas David Rivers rivers@dignus.comThomas G. McWilliams tgm@netcom.comThomas Gellekum
thomas@ghpc8.ihf.rwth-aachen.deThomas Graichen
graichen@omega.physik.fu-berlin.deThomas König
Thomas.Koenig@ciw.uni-karlsruhe.deThomas Ptacek unknownThomas A. Stephens tas@stephens.orgThomas Stromberg tstrombe@rtci.comThomas Valentino Crimi
tcrimi+@andrew.cmu.eduThomas Wintergerst thomas@lemur.nord.deÞórður Ívarsson
totii@est.isTim Kientzle kientzle@netcom.comTim Singletary
tsingle@sunland.gsfc.nasa.govTim Wilkinson tim@sarc.city.ac.ukTimo J. Rinne tri@iki.fiTodd Miller millert@openbsd.orgTom root@majestix.cmr.noTom tom@sdf.comTom Gray - DCA dcasba@rain.orgTom Jobbins tom@tom.tjTom Pusateri pusateri@juniper.netTom Rush tarush@mindspring.comTom Samplonius tom@misery.sdf.comTomohiko Kurahashi
kura@melchior.q.t.u-tokyo.ac.jpTony Kimball alk@Think.COMTony Li tli@jnx.comTony Lynn wing@cc.nsysu.edu.twTony Maher tonym@angis.org.auTorbjorn Granlund tege@matematik.su.seToshihiko ARAI toshi@tenchi.ne.jpToshihiko SHIMOKAWA toshi@tea.forus.or.jpToshihiro Kanda candy@kgc.co.jpToshiomi Moriki
Toshiomi.Moriki@ma1.seikyou.ne.jpTrefor S. trefor@flevel.co.ukTrevor Blackwell tlb@viaweb.comURATA Shuichiro s-urata@nmit.tmg.nec.co.jpUdo Schweigert ust@cert.siemens.deUgo Paternostro paterno@dsi.unifi.itUlf Kieber kieber@sax.deUlli Linzen ulli@perceval.camelot.deUstimenko Semen semen@iclub.nsu.ruUwe Arndt arndt@mailhost.uni-koblenz.deVadim Chekan vadim@gc.lviv.uaVadim Kolontsov vadim@tversu.ac.ruVadim Mikhailov mvp@braz.ruVan Jacobson van@ee.lbl.govVasily V. Grechishnikov
bazilio@ns1.ied-vorstu.ac.ruVasim Valejev vasim@uddias.diaspro.comVernon J. Schryver vjs@mica.denver.sgi.comVic Abell abe@cc.purdue.eduVille Eerola ve@sci.fiVincent Poy vince@venus.gaianet.netVincenzo Capuano
VCAPUANO@vmprofs.esoc.esa.deVirgil Champlin champlin@pa.dec.comVladimir A. Jakovenko
vovik@ntu-kpi.kiev.uaVladimir Kushnir kushn@mail.kar.netVsevolod Lobko seva@alex-ua.comW. Gerald Hicks wghicks@bellsouth.netW. Richard Stevens rstevens@noao.eduWalt Howard howard@ee.utah.eduWarren Toomey wkt@csadfa.cs.adfa.oz.auWayne Scott wscott@ichips.intel.comWerner Griessl
werner@btp1da.phy.uni-bayreuth.deWes Santee wsantee@wsantee.oz.netWietse Venema wietse@wzv.win.tue.nlWilfredo Sanchez wsanchez@apple.comWiljo Heinen wiljo@freeside.ki.open.deWilko Bulte wilko@yedi.iaf.nlWill Andrews andrews@technologist.comWillem Jan Withagen wjw@surf.IAE.nlWilliam Jolitz withheldWilliam Liao william@tale.netWojtek Pilorz
wpilorz@celebris.bdk.lublin.plWolfgang Helbig helbig@ba-stuttgart.deWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@FreeBSD.orgWu Ching-hong woju@FreeBSD.ee.Ntu.edu.TWYarema yds@ingress.comYaroslav Terletsky ts@polynet.lviv.uaYasuhito FUTATSUKI futatuki@fureai.or.jpYasuhiro Fukama yasuf@big.or.jpYen-Shuo Su yssu@CCCA.NCTU.edu.twYing-Chieh Liao ijliao@csie.NCTU.edu.twYixin Jin yjin@rain.cs.ucla.eduYoshiaki Uchikawa yoshiaki@kt.rim.or.jpYoshihiko OHTA yohta@bres.tsukuba.ac.jpYoshihisa NAKAGAWA
y-nakaga@ccs.mt.nec.co.jpYoshikazu Goto gotoh@ae.anritsu.co.jpYoshimasa Ohnishi
ohnishi@isc.kyutech.ac.jpYoshishige Arai ryo2@on.rim.or.jpYuichi MATSUTAKA matutaka@osa.att.ne.jpYujiro MIYATA
miyata@bioele.nuee.nagoya-u.ac.jpYukihiro Nakai nacai@iname.comYusuke Nawano azuki@azkey.orgYuu Yashiki s974123@cc.matsuyama-u.ac.jpYuval Yarom yval@cs.huji.ac.ilYves Fonk yves@cpcoup5.tn.tudelft.nlYves Fonk yves@dutncp8.tn.tudelft.nlZach Heilig zach@gaffaneys.comZahemszhky Gabor zgabor@code.huZhong Ming-Xun zmx@mail.CDPA.nsysu.edu.twarci vega@sophia.inria.frder Mouse mouse@Collatz.McRCIM.McGill.EDUfrf frf@xocolatl.comEge Rekk aagero@aage.priv.no386BSD Patch Kit Patch Contributors(in alphabetical order by first name):Adam Glass glass@postgres.berkeley.eduAdrian Hall adrian@ibmpcug.co.ukAndrey A. Chernov ache@astral.msk.suAndrew Herbert andrew@werple.apana.org.auAndrew Moore alm@netcom.comAndy Valencia ajv@csd.mot.comjtk@netcom.comArne Henrik Juul arnej@Lise.Unit.NOBakul Shah bvs@bitblocks.comBarry Lustig barry@ictv.comBob Wilcox bob@obiwan.uucpBranko LankesterBrett Lymn blymn@mulga.awadi.com.AUCharles Hannum mycroft@ai.mit.eduChris G. Demetriou
cgd@postgres.berkeley.eduChris Torek torek@ee.lbl.govChristoph Robitschko
chmr@edvz.tu-graz.ac.atDaniel Poirot poirot@aio.jsc.nasa.govDave Burgess burgess@hrd769.brooks.af.milDave Rivers rivers@ponds.uucpDavid Dawes dawes@physics.su.OZ.AUDavid Greenman dg@Root.COMEric J. Haug ejh@slustl.slu.eduFelix Gaehtgens
felix@escape.vsse.in-berlin.deFrank Maclachlan fpm@crash.cts.comGary A. Browning gab10@griffcd.amdahl.comGary Howland gary@hotlava.comGeoff Rehmet csgr@alpha.ru.ac.zaGoran Hammarback goran@astro.uu.seGuido van Rooij guido@gvr.orgGuy Harris guy@auspex.comHavard Eidnes
Havard.Eidnes@runit.sintef.noHerb Peyerl hpeyerl@novatel.cuc.ab.caHolger Veit Holger.Veit@gmd.deIshii Masahiro, R. Kym HorsellJ.T. Conklin jtc@cygnus.comJagane D Sundar jagane@netcom.comJames Clark jjc@jclark.comJames Jegers jimj@miller.cs.uwm.eduJames W. DolterJames da Silva jds@cs.umd.edu et alJay Fenlason hack@datacube.comJim Wilson wilson@moria.cygnus.comJörg Lohse
lohse@tech7.informatik.uni-hamburg.deJörg Wunsch
joerg_wunsch@uriah.heep.sax.deJohn DysonJohn Woods jfw@eddie.mit.eduJordan K. Hubbard jkh@whisker.hubbard.ieJulian Elischer julian@dialix.oz.auJulian Stacey jhs@FreeBSD.orgKarl Dietz Karl.Dietz@triplan.comKarl Lehenbauer karl@NeoSoft.comkarl@one.neosoft.comKeith Bostic bostic@toe.CS.Berkeley.EDUKen HughesKent Talarico kent@shipwreck.tsoft.netKevin Lahey kml%rokkaku.UUCP@mathcs.emory.edukml@mosquito.cis.ufl.eduMarc Frajola marc@dev.comMark Tinguely tinguely@plains.nodak.edutinguely@hookie.cs.ndsu.NoDak.eduMartin Renters martin@tdc.on.caMichael Clay mclay@weareb.orgMichael Galassi nerd@percival.rain.comMike Durkin mdurkin@tsoft.sf-bay.orgNaoki Hamada nao@tom-yam.or.jpNate Williams nate@bsd.coe.montana.eduNick Handel nhandel@NeoSoft.comnick@madhouse.neosoft.comPace Willisson pace@blitz.comPaul Kranenburg pk@cs.few.eur.nlPaul Mackerras paulus@cs.anu.edu.auPaul Popelka paulp@uts.amdahl.comPeter da Silva peter@NeoSoft.comPhil Sutherland
philsuth@mycroft.dialix.oz.auPoul-Henning Kampphk@FreeBSD.orgRalf Friedl friedl@informatik.uni-kl.deRick Macklem root@snowhite.cis.uoguelph.caRobert D. Thrush rd@phoenix.aii.comRodney W. Grimes rgrimes@cdrom.comSascha Wildner swildner@channelz.GUN.deScott Burris scott@pita.cns.ucla.eduScott Reynolds scott@clmqt.marquette.mi.usSean Eric Fagan sef@kithrup.comSimon J Gerraty sjg@melb.bull.oz.ausjg@zen.void.oz.auStephen McKay syssgm@devetir.qld.gov.auTerry Lambert terry@icarus.weber.eduTerry Lee terry@uivlsi.csl.uiuc.eduTor Egge Tor.Egge@idi.ntnu.noWarren Toomey wkt@csadfa.cs.adfa.oz.auWiljo Heinen wiljo@freeside.ki.open.deWilliam Jolitz withheldWolfgang Solfrank ws@tools.deWolfgang Stanglmeier wolf@dentaro.GUN.deYuval Yarom yval@cs.huji.ac.il
diff --git a/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml b/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
index 0889a7e540..b5f4b3d7b4 100644
--- a/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/cutting-edge/chapter.sgml
@@ -1,2482 +1,2482 @@
The 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 not?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-currentJoin 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 important bulletins which
may be critical to your system's continued health.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 CTM facility. Unless
you have a good TCP/IP connection at a flat rate, this is
the way to do it.Use the cvsup program with
this
supfile. This is the second most recommended
method, since it allows you to grab the entire collection
once and then only what has changed from then on. Many people
run cvsup from cron and keep their sources up-to-date
automatically. For a fairly easy interface to this, simply
type:
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/lexYou can do:
ftp>cd usr.binftp>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 make world the first time
through as part of the upgrading process. Reading the &a.current;
will keep you up-to-date on other bootstrapping procedures that
sometimes become necessary as we move towards the next
release.Be active! If you are running 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 FreeBSD-current).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-stableJoin 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.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-stable
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.If you are installing a new system and want it to be as stable
as possible, you can simply grab the latest dated branch snapshot
from ftp://releng3.FreeBSD.org/pub/FreeBSD/
and install it like any other release.If you are already running a previous release of 2.2 and wish
to upgrade via sources then you can easily do so from ftp.FreeBSD.org. This can be done in one
of three ways:Use the CTM facility. Unless
you have a good TCP/IP connection at a flat rate, this is
the way to do it.Use the cvsup program with
this
supfile. This is the second most recommended
method, since it allows you to grab the entire collection
once and then only what has changed from then on. Many people
run cvsup from cron to keep their sources up-to-date
automatically. For a fairly easy interface to this, simply
type;
The FreeBSD mirror
sites database is more accurate than the mirror listing in the
handbook, as it gets its information form the DNS rather than relying on
static lists of hosts.Additionally, FreeBSD is available via anonymous FTP from the
following mirror sites. If you choose to obtain FreeBSD via anonymous
FTP, please try to use a site near you.Argentina,
Australia,
Brazil,
Canada,
China,
Czech Republic,
Denmark,
Estonia,
Finland,
France,
Germany,
Hong Kong,
Ireland,
Israel,
Japan,
Korea,
Netherlands,
New Zealand,
Poland,
Portugal,
Russia,
Saudi Arabia,
South Africa,
Spain,
Slovak Republic,
Slovenia,
Sweden,
Taiwan,
Thailand,
UK,
Ukraine,
USA.ArgentinaIn case of problems, please contact the hostmaster
hostmaster@ar.FreeBSD.org for this domain.ftp://ftp.ar.FreeBSD.org/pub/FreeBSDAustraliaIn case of problems, please contact the hostmaster
hostmaster@au.FreeBSD.org 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
hostmaster@br.FreeBSD.org 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
hostmaster@ca.FreeBSD.org for this domain.ftp://ftp.ca.FreeBSD.org/pub/FreeBSDChinaIn case of problems, please contact the hostmaster
phj@cn.FreeBSD.org for this domain.ftp://ftp.cn.FreeBSD.org/pub/FreeBSDCzech RepublicIn case of problems, please contact the hostmaster
hostmaster@cz.FreeBSD.org for this domain.ftp://ftp.cz.FreeBSD.org Contact: calda@dzungle.ms.mff.cuni.czftp://sunsite.mff.cuni.cz/OS/FreeBSD Contact: jj@sunsite.mff.cuni.cz.DenmarkIn case of problems, please contact the hostmaster
hostmaster@dk.FreeBSD.org for this domain.ftp://ftp.dk.freeBSD.ORG/pub/FreeBSDEstoniaIn case of problems, please contact the hostmaster
hostmaster@ee.FreeBSD.org for this domain.ftp://ftp.ee.FreeBSD.org/pub/FreeBSDFinlandIn case of problems, please contact the hostmaster
hostmaster@fi.FreeBSD.org for this domain.ftp://ftp.fi.FreeBSD.org/pub/FreeBSDFranceIn case of problems, please contact the hostmaster
hostmaster@fr.FreeBSD.org for this domain.ftp://ftp.fr.FreeBSD.org/pub/FreeBSDftp://ftp2.fr.FreeBSD.org/pub/FreeBSDftp://ftp3.fr.FreeBSD.org/pub/FreeBSDGermanyIn case of problems, please contact the hostmaster
hostmaster@de.FreeBSD.org 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
hostmaster@ie.FreeBSD.org for this domain.ftp://ftp.ie.FreeBSD.org/pub/FreeBSDIsraelIn case of problems, please contact the hostmaster
hostmaster@il.FreeBSD.org for this domain.ftp://ftp.il.FreeBSD.org/pub/FreeBSDftp://ftp2.il.FreeBSD.org/pub/FreeBSDJapanIn case of problems, please contact the hostmaster
hostmaster@jp.FreeBSD.org 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
hostmaster@kr.FreeBSD.org for this domain.ftp://ftp.kr.FreeBSD.org/pub/FreeBSDftp://ftp2.kr.FreeBSD.org/pub/FreeBSDftp://ftp3.kr.FreeBSD.org/pub/FreeBSDftp://ftp4.kr.FreeBSD.org/pub/FreeBSDftp://ftp5.kr.FreeBSD.org/pub/FreeBSDftp://ftp6.kr.FreeBSD.org/pub/FreeBSDNetherlandsIn case of problems, please contact the hostmaster
hostmaster@nl.FreeBSD.org for this domain.ftp://ftp.nl.FreeBSD.org/pub/FreeBSDNew ZealandIn case of problems, please contact the hostmaster
hostmaster@nz.FreeBSD.org for this domain.ftp://ftp.nz.FreeBSD.org/pub/FreeBSDPolandIn case of problems, please contact the hostmaster
hostmaster@pl.FreeBSD.org for this domain.ftp://ftp.pl.FreeBSD.org/pub/FreeBSDPortugalIn case of problems, please contact the hostmaster
hostmaster@pt.FreeBSD.org for this domain.ftp://ftp.pt.FreeBSD.org/pub/FreeBSDftp://ftp2.pt.FreeBSD.org/pub/FreeBSDRussiaIn case of problems, please contact the hostmaster
hostmaster@ru.FreeBSD.org for this domain.ftp://ftp.ru.FreeBSD.org/pub/FreeBSDftp://ftp2.ru.FreeBSD.org/pub/FreeBSDftp://ftp3.ru.FreeBSD.org/pub/FreeBSDftp://ftp4.ru.FreeBSD.org/pub/FreeBSDSaudi ArabiaIn case of problems, please contact
ftpadmin@isu.net.saftp://ftp.isu.net.sa/pub/mirrors/ftp.freebsd.orgSouth AfricaIn case of problems, please contact the hostmaster
hostmaster@za.FreeBSD.org for this domain.ftp://ftp.za.FreeBSD.org/pub/FreeBSDftp://ftp2.za.FreeBSD.org/pub/FreeBSDftp://ftp3.za.FreeBSD.org/pub/FreeBSDSlovak RepublicIn case of problems, please contact the hostmaster
hostmaster@sk.FreeBSD.org for this domain.ftp://ftp.sk.FreeBSD.org/pub/FreeBSDSloveniaIn case of problems, please contact the hostmaster
hostmaster@si.FreeBSD.org for this domain.ftp://ftp.si.FreeBSD.org/pub/FreeBSDSpainIn case of problems, please contact the hostmaster
hostmaster@es.FreeBSD.org for this domain.ftp://ftp.es.FreeBSD.org/pub/FreeBSDSwedenIn case of problems, please contact the hostmaster
hostmaster@se.FreeBSD.org for this domain.ftp://ftp.se.FreeBSD.org/pub/FreeBSDftp://ftp2.se.FreeBSD.org/pub/FreeBSDftp://ftp3.se.FreeBSD.org/pub/FreeBSDTaiwanIn case of problems, please contact the hostmaster
hostmaster@tw.FreeBSD.org 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: freebsd-mnt@lucky.net.UKIn case of problems, please contact the hostmaster
hostmaster@uk.FreeBSD.org 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
hostmaster@FreeBSD.org 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 hostmaster@internat.FreeBSD.org for
this domain.ftp://ftp.internat.FreeBSD.org/pub/FreeBSDftp://ftp2.internat.FreeBSD.org/pub/FreeBSDBrazilHostmaster hostmaster@br.FreeBSD.org for this
domain.ftp://ftp.br.FreeBSD.org/pub/FreeBSDFinlandftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt Contact: count@nic.funet.fi.CTM SitesCTM/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/development/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 SitesCVSup servers for FreeBSD are running
at the following sites:Argentinacvsup.ar.FreeBSD.org (maintainer
msagre@cactus.fi.uba.ar)Australiacvsup.au.FreeBSD.org (maintainer
dawes@physics.usyd.edu.au)Brazilcvsup.br.FreeBSD.org (maintainer
cvsup@cvsup.br.FreeBSD.org)cvsup2.br.FreeBSD.org (maintainer
tps@ti.sk)Canadacvsup.ca.FreeBSD.org (maintainer
dan@jaded.net)Chinacvsup.cn.FreeBSD.org (maintainer
phj@cn.FreeBSD.org)Czech Republiccvsup.cz.FreeBSD.org (maintainer
cejkar@dcse.fee.vutbr.cz)Denmarkcvsup.dk.FreeBSD.org (maintainer
jesper@skriver.dk)Estoniacvsup.ee.FreeBSD.org (maintainer
taavi@uninet.ee)Finlandcvsup.fi.FreeBSD.org (maintainer
count@key.sms.fi)cvsip2.fi.FreeBSD.org (maintainer
count@key.sms.fi)Francecvsup.fr.FreeBSD.org (maintainer
hostmaster@fr.FreeBSD.org)Germanycvsup.de.FreeBSD.org (maintainer
wosch@FreeBSD.org)cvsup2.de.FreeBSD.org (maintainer
petzi@FreeBSD.org)cvsup3.de.FreeBSD.org (maintainer
ag@leo.org)Icelandcvsup.is.FreeBSD.org (maintainer
adam@veda.is)Japancvsup.jp.FreeBSD.org (maintainer
simokawa@sat.t.u-tokyo.ac.jp)cvsup2.jp.FreeBSD.org (maintainer
max@FreeBSD.org)cvsup3.jp.FreeBSD.org (maintainer
shige@cin.nihon-u.ac.jp)cvsup4.jp.FreeBSD.org (maintainer
cvsup-admin@ftp.media.kyoto-u.ac.jp)cvsup5.jp.FreeBSD.org (maintainer
cvsup@imasy.or.jp)Koreacvsup.kr.FreeBSD.org (maintainer
cjh@kr.FreeBSD.org)Netherlandscvsup.nl.FreeBSD.org (maintainer
xaa@xaa.iae.nl)Norwaycvsup.no.FreeBSD.org (maintainer
Tor.Egge@idt.ntnu.no)Polandcvsup.pl.FreeBSD.org (maintainer
Mariusz@kam.pl)Russiacvsup.ru.FreeBSD.org (maintainer
mishania@demos.su)cvsup2.ru.FreeBSD.org (maintainer
dv@dv.ru)Spaincvsup.es.FreeBSD.org (maintainer
jesusr@FreeBSD.org)Swedencvsup.se.FreeBSD.org (maintainer
pantzer@ludd.luth.se)Slovak Republiccvsup.sk.FreeBSD.org (maintainer
tps@tps.sk)cvsup2.sk.FreeBSD.org (maintainer
tps@tps.sk)South Africacvsup.za.FreeBSD.org (maintainer
markm@FreeBSD.org)cvsup2.za.FreeBSD.org (maintainer
markm@FreeBSD.org)Taiwancvsup.tw.FreeBSD.org (maintainer
jdli@freebsd.csie.nctu.edu.tw)Ukrainecvsup2.ua.FreeBSD.org (maintainer
freebsd-mnt@lucky.net)United Kingdomcvsup.uk.FreeBSD.org (maintainer
joe@pavilion.net)cvsup2.uk.FreeBSD.org (maintainer
brian@FreeBSD.org)USAcvsup1.FreeBSD.org (maintainer
skynyrd@opus.cts.cwu.edu), Washington
statecvsup2.FreeBSD.org (maintainer
jdp@FreeBSD.org), Californiacvsup3.FreeBSD.org (maintainer
wollman@FreeBSD.org), Massachusettscvsup5.FreeBSD.org (maintainer
ck@adsu.bellsouth.com), Georgiacvsup6.FreeBSD.org (maintainer
jdp@FreeBSD.org), FloridaThe 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
markm@FreeBSD.org)The following CVSup site is especially
designed for CTM users. Unlike the other
CVSup mirrors, it is kept up-to-date by CTM.
That means if you CVSupcvs-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 CTMcvs-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
blank@fox.uni-trier.de)AFS SitesAFS servers for FreeBSD are running at the following sites;SwedenThe path to the files are:
/afs/stacken.kth.se/ftp/pub/FreeBSD
stacken.kth.se # Stacken Computer Club, KTH, Sweden
130.237.234.43 #hot.stacken.kth.se
130.237.237.230 #fishburger.stacken.kth.se
130.237.234.3 #milko.stacken.kth.seMaintainer ftp@stacken.kth.se
diff --git a/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml b/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
index 53e2f8a6d6..2ce4e58551 100644
--- a/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/pgpkeys/chapter.sgml
@@ -1,624 +1,624 @@
PGP keysIn 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>
f16 Fingerprint16 = 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0i for non-commercial use
mQCNAzG2GToAAAEEANI6+4SJAAgBpl53XcfEr1M9wZyBqC0tzpie7Zm4vhv3hO8s
o5BizSbcJheQimQiZAY4OnlrCpPxijMFSaihshs/VMAz1qbisUYAMqwGEO/T4QIB
nWNo0Q/qOniLMxUrxS1RpeW5vbghErHBKUX9GVhxbiVfbwc4wAHbXdKX5jjdAAUR
tCVKb25hdGhhbiBNLiBCcmVzbGVyIDxqbWJARnJlZUJTRC5PUkc+iQCVAwUQNbtI
gAHbXdKX5jjdAQHamQP+OQr10QRknamIPmuHmFYJZ0jU9XPIvTTMuOiUYLcXlTdn
GyTUuzhbEywgtOldW2V5iA8platXThtqC68NsnN/xQfHA5xmFXVbayNKn8H5stDY
2s/4+CZ06mmJfqYmONF1RCbUk/M84rVT3Gn2tydsxFh4Pm32lf4WREZWRiLqmw+J
AJUDBRA0DfF99RVb+45ULV0BAcZ0BACCydiSUG1VR0a5DBcHdtin2iZMPsJUPRqJ
tWvP6VeI8OFpNWQ4LW6ETAvn35HxV2kCcQMyht1kMD+KEJz7r8Vb94TS7KtZnNvk
2D1XUx8Locj6xel5c/Lnzlnnp7Bp1XbJj2u/NzCaZQ0eYBdP/k7RLYBYHQQln5x7
BOuiRJNVU4kAlQMFEDQLcShVLh4uc9KIpQEBJv4D/3mDrD0MM9EYOVuyXik3UGVI
8quYNA9ErVcLdt10NjYc16VI2HOnYVgPRag3Wt7W8wlXShpokfC/vCNt7f5JgRf8
h2a1/MjQxtlD+4/Js8k7GLa53oLon6YQYk32IEKexoLPwIRO4L2BHWa3GzHJJSP2
aTR/Ep90/pLdAOu/oJDUiQCVAwUQMqyL0LNaYutZnzI9AQF25QP9GFXhBrz2tiWz
2+0gWbpcGNnyZbfsVjF6ojGDdmsjJMyWCGw49XR/vPKYIJY9EYo4t49GIajRkISQ
NNiIz22fBAjT2uY9YlvnTJ9NJleMfHr4dybo7oEKYMWWijQzGjqf2m8wf9OaaofE
KwBX6nxcRbKsxm/BVLKczGYl3XtjkcuJAJUDBRA1ol5TZWCprDT5+dUBATzXA/9h
/ZUuhoRKTWViaistGJfWi26FB/Km5nDQBr/Erw3XksQCMwTLyEugg6dahQ1u9Y5E
5tKPxbB69eF+7JXVHE/z3zizR6VL3sdRx74TPacPsdhZRjChEQc0htLLYAPkJrFP
VAzAlSlm7qd+MXf8fJovQs6xPtZJXukQukPNlhqZ94kAPwMFEDSH/kF4tXKgazlt
bxECfk4AoO+VaFVfguUkWX10pPSSfvPyPKqiAJ4xn8RSIe1ttmnqkkDMhLh00mKj
lLQuSm9uYXRoYW4gTS4gQnJlc2xlciA8Sm9uYXRoYW4uQnJlc2xlckBVU2kubmV0
PokAlQMFEDXbdSkB213Sl+Y43QEBV/4D/RLJNTrtAqJ1ATxXWv9g8Cr3/YF0GTmx
5dIrJOpBup7eSSmiM/BL9Is4YMsoVbXCI/8TqA67TMICvq35PZU4wboQB8DqBAr+
gQ8578M7Ekw1OAF6JXY6AF2P8k7hMcVBcVOACELPT/NyPNByG5QRDoNmlsokJaWU
/2ls4QSBZZlb
=zbCw
-----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.3ia
mQCNAzFjX0IAAAEEAML+nm9/kDNPp43ZUZGjYkm2QLtoC1Wxr8JulZXqk7qmhYcQ
jvX+fyoriJ6/7ZlnLe2oG5j9tZOnRLPvMaz0g9CpW6Dz3nkXrNPkmOFV9B8D94Mk
tyFeRJFqnkCuqBj6D+H8FtBwEeeTecSh2tJ0bZZTXnAMhxeOdvUVW/uOVC1dAAUR
tCNKb3JkYW4gSy4gSHViYmFyZCA8amtoQEZyZWVCU0Qub3JnPokBFQMFEDXCTXQM
j46yp4IfPQEBwO8IAIN0J09AXBf86dFUTFGcAMrEQqOF5IL+KGorAjzuYxERhKfD
ZV7jA+sCQqxkWfcVcE20kVyVYqzZIkio9a5zXP6TwA247JkPt54S1PmMDYHNlRIY
laXlNoji+4q3HP2DfHqXRT2859rYpm/fG/v6pWkos5voPKcZ2OFEp9W+Ap88oqw+
5rx4VetZNJq1Epmis4INj6XqNqj85+MOOIYE+f445ohDM6B/Mxazd6cHFGGIR+az
VjZ6lCDMLjzhB5+FqfrDLYuMjqkMTR5z9DL+psUvPlCkYbQ11NEWtEmiIWjUcNJN
GCxGzv5bXk0XPu3ADwbPkFE2usW1cSM7AQFiwuyJAJUDBRAxe+Q9a1pnjYGyp3kB
AV7XA/oCSL/Cc2USpQ2ckwkGpyvIkYBPszIcabSNJAzm2hsU9Qa6WOPxD8olDddB
uJNiW/gznPC4NsQ0N8Zr4IqRX/TTDVf04WhLmd8AN9SOrVv2q0BKgU6fLuk979tJ
utrewH6PR2qBOjAaR0FJNk4pcYAHeT+e7KaKy96YFvWKIyDvc4kAlQMFEDF8ldof
f6kIA1j8vQEBDH4D/0Zm0oNlpXrAE1EOFrmp43HURHbij8n0Gra1w9sbfo4PV+/H
U8ojTdWLy6r0+prH7NODCkgtIQNpqLuqM8PF2pPtUJj9HwTmSqfaT/LMztfPA6PQ
csyT7xxdXl0+4xTDl1avGSJfYsI8XCAy85cTs+PQwuyzugE/iykJO1Bnj/paiQCV
AwUQMXvlBvUVW/uOVC1dAQF2fQP/RfYC6RrpFTZHjo2qsUHSRk0vmsYfwG5NHP5y
oQBMsaQJeSckN4n2JOgR4T75U4vS62aFxgPLJP3lOHkU2Vc7xhAuBvsbGr5RP8c5
LvPOeUEyz6ZArp1KUHrtcM2iK1FBOmY4dOYphWyWMkDgYExabqlrAq7FKZftpq/C
BiMRuaw=
=C/Jw
-----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
tCNQb3VsLUhlbm5pbmcgS2FtcCA8cGhrQEZyZWVCU0Qub3JnPokAlQMFEDQQ0aZ1
u244dqP3sQEBu4ID/jXFFeJgs2MdTDNOZM/FbfDhI4qxAbYUsqS3+Ra16yd8Wd/A
jV+IHJE2NomFWl8UrUjCGinXiwzPgK1OfFJrS9Og1wQLvAl0X84BA8MTP9BQr4w7
6I/RbksgUSrVCIO8MJwlydjSPocWGBeXlVjbZxXzyuJk7H+TG+zuI5BuBcNIiQCV
AwUQMwYr2rNaYutZnzI9AQHiIQP/XxtBWFXaBRgVLEhRNpS07YdU+LsZGlLOZehN
9L4UnJFHQQPNOpMey2gF7Y95aBOw5/1xS5vlQpwmRFCntWsm/gqdzK6rulfr1r5A
y94LO5TAC6ucNu396Y4vo1TyD1STnRC466KlvmtQtAtFGgXlORWLL9URLzcRFd1h
D0yXd9aJAJUDBRAxfo19a1pnjYGyp3kBAQqyA/4v64vP3l1F0Sadn6ias761hkz/
SMdTuLzILmofSCC4o4KWMjiWJHs2Soo41QlZi1+xMHzV32JKiwFlGtPHqL+EHyXy
Q4H3vmf9/1KF+0XCaMtgI0wWUMziPSTJK8xXbRRmMDK/0F4TnVVaUhnmf+h5K7O6
XdmejDTa0X/NWcicmIkAlQMFEDF8lef1FVv7jlQtXQEBcnwD/0ro1PpUtlkLmreD
tsGTkNa7MFLegrYRvDDrHOwPZH152W2jPUncY+eArQJakeHiTDmJNpFagLZglhE0
bqJyca+UwCXX+6upAclWHEBMg2byiWMMqyPVEEnpUoHM1sIkgdNWlfQAmipRBfYh
2LyCgWvR8CbtwPYIFvUmGgB3MR87iQCVAwUQMUseXB9/qQgDWPy9AQGPkwP/WEDy
El2Gkvua9COtMAifot2vTwuvWWpNopIEx0Ivey4aVbRLD90gGCJw8OGDEtqFPcNV
8aIiy3fYVKXGZZjvCKd7zRfhNmQn0eLDcymq2OX3aPrMc2rRlkT4Jx425ukR1gsO
qiQAgw91aWhY8dlw/EKzk8ojm52x4VgXaBACMjaJAJUDBRAxOUOg72G56RHVjtUB
AbL4A/9HOn5Qa0lq9tKI/HkSdc5fGQD/66VdCBAb292RbB7CS/EM07MdbcqRRYIa
0+0gwQ3OdsWPdCVgH5RIhp/WiC+UPkR1cY8N9Mg2kTwJfZZfNqN+BgWlgRMPN27C
OhYNl8Q33Nl9CpBLrZWABF44jPeT0EvvTzP/5ZQ7T75EsYKYiYkAlQMFEDDmryQA
8tkJ67sbQQEBPdsEALCj6v1OBuJLLJTlxmmrkqAZPVzt5QdeO3Eqa2tcPWcU0nqP
vHYMzZcZ7oFg58NZsWrhSQQDIB5e+K65Q/h6dC7W/aDskZd64jxtEznX2kt0/MOr
8OdsDis1K2f9KQftrAx81KmVwW4Tqtzl7NWTDXt44fMOtibCwVq8v2DFkTJy
=JKbP
-----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-----Developers&a.wosch;
Type Bits/KeyID Date User ID
pub 1024/2B7181AD 1997/08/09 Wolfram Schneider <wosch@FreeBSD.org>
Key fingerprint = CA 16 91 D9 75 33 F1 07 1B F0 B4 9F 3E 95 B6 09
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzPs+aEAAAEEAJqqMm2I9CxWMuHDvuVO/uh0QT0az5ByOktwYLxGXQmqPG1G
Q3hVuHWYs5Vfm/ARU9CRcVHFyqGQ3LepoRhDHk+JcASHan7ptdFsz7xk1iNNEoe0
vE2rns38HIbiyQ/2OZd4XsyhFOFtExNoBuyDyNoe3HbHVBQT7TmN/mkrcYGtAAUR
tCVXb2xmcmFtIFNjaG5laWRlciA8d29zY2hARnJlZUJTRC5vcmc+iQCVAwUQNxnH
AzmN/mkrcYGtAQF5vgP/SLOiI4AwuPHGwUFkwWPRtRzYSySXqwaPCop5mVak27wk
pCxGdzoJO2UgcE812Jt92Qas91yTT0gsSvOVNATaf0TM3KnKg5ZXT1QIzYevWtuv
2ovAG4au3lwiFPDJstnNAPcgLF3OPni5RCUqBjpZFhb/8YDfWYsMcyn4IEaJKre0
JFdvbGZyYW0gU2NobmVpZGVyIDxzY2huZWlkZXJAemliLmRlPokAlQMFEDcZxu85
jf5pK3GBrQEBCRgD/jPj1Ogx4O769soiguL1XEHcxhqtrpKZkKwxmDLRa0kJFwLp
bBJ3Qz3vwaB7n5gQU0JiL1B2M7IxVeHbiIV5pKp7FD248sm+HZvBg6aSnCg2JPUh
sHd1tK5X4SB5cjFt3Cj0LIN9/c9EUxm3SoML9bovmze60DckErrRNOuTk1IntCJX
b2xmcmFtIFNjaG5laWRlciA8d29zY2hAYXBmZWwuZGU+iQEVAwUQNmfWXAjJLLJO
sC7dAQEASAgAnE4g2fwMmFkQy17ATivljEaDZN/m0GdXHctdZ8CaPrWk/9/PTNK+
U6xCewqIKVwtqxVBMU1VpXUhWXfANWCB7a07D+2GrlB9JwO5NMFJ6g0WI/GCUXjC
xb3NTkNsvppL8Rdgc8wc4f23GG4CXVggdTD2oUjUH5Bl7afgOT4xLPAqePhS7hFB
UnMsbA94OfxPtHe5oqyaXt6cXH/SgphRhzPPZq0yjg0Ef+zfHVamvZ6Xl2aLZmSv
Cc/rb0ShYDYi39ly9OPPiBPGbSVw2Gg804qx3XAKiTFkLsbYQnRt7WuCPsOVjFkf
CbQS31TaclOyzenZdCAezubGIcrJAKZjMIkAlQMFEDPs+aE5jf5pK3GBrQEBlIAD
/3CRq6P0m1fi9fbPxnptuipnoFB/m3yF6IdhM8kSe4XlXcm7tS60gxQKZgBO3bDA
5QANcHdl41Vg95yBAZepPie6iQeAAoylRrONeIy6XShjx3S0WKmA4+C8kBTL+vwa
UqF9YJ1qesZQtsXlkWp/Z7N12RkueVAVQ7wRPwfnz6E3tC5Xb2xmcmFtIFNjaG5l
aWRlciA8d29zY2hAcGFua2UuZGUuZnJlZWJzZC5vcmc+iQCVAwUQNxnEqTmN/mkr
cYGtAQFnpQP9EpRZdG6oYN7d5abvIMN82Z9x71a4QBER+R62mU47wqdRG2b6jMMh
3k07b2oiprVuPhRw/GEPPQevb6RRT6SD9CPYAGfK3MDE8ZkMj4d+7cZDRJQ35sxv
gAzQwuA9l7kS0mt5jFRPcEg5/KpuyehRLckjx8jpEM7cEJDHXhBIuVg=
=3V1R
-----END PGP PUBLIC KEY BLOCK-----&a.brian;
Type Bits/KeyID Date User ID
pub 1024/666A7421 1997/04/30 Brian Somers <brian@awfulhak.org>
Key fingerprint = 2D 91 BD C2 94 2C 46 8F 8F 09 C4 FC AD 12 3B 21
Brian Somers <brian@uk.FreeBSD.org>
Brian Somers <brian@OpenBSD.org>
Brian Somers <brian@FreeBSD.org>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
mQCNAzNmogUAAAEEALdsjVsV2dzO8UU4EEo7z3nYuvB2Q6YJ8sBUYjB8/vfR5oZ9
7aEQjgY5//pXvS30rHUB9ghk4kIFSljzeMudE0K2zH5n2sxpLbBKWZRDLS7xnrDC
I3j9CNKwQBzMPs0fUT46gp96nf1X8wPiJXkDUEia/c0bRbXlLw7tvOdmanQhAAUR
tCFCcmlhbiBTb21lcnMgPGJyaWFuQGF3ZnVsaGFrLm9yZz6JAJUDBRA3Fjs4H3+p
CANY/L0BAZOxBACTZ1zPdaJzEdT4AfrebQbaU4ytEeodnVXZIkc8Il+LDlDOUAIe
k5PgnHTRM4yiwcZuYQrCDRFgdOofcFfRo0PD7mGFzd22qPGmbvHiDBCYCyhlkPXW
IDeoA1cX77JlU1NFdy0dZwuX7csaMlpjCkOPc7+856mr6pQi48zj7yZtrYkAlQMF
EDcUqZ2dZ0EADG4SFQEBEm0EAL2bBNc4vpxPrg3ATdZ/PekpL6lYj3s9pBf8f7eY
LXq438A/ywiWkrL74gXxcZ2Ey9AHZW+rbJPzUbrfMAgP3uWobeSvDyKRo1wtKnTY
Hy+OEIbBIHDmIUuK3L7KupBf7WAI46Q7fnyz0txvtRruDjvfoyl9/TSRfIKcaw2a
INh7iQCVAwUQNwyWpmdKPfFUsXG5AQEIrAQAmukv2u9ihcnO2Zaak265I+gYozu+
biAngdXNfhTGMeExFzdzQ8Qe7EJugMpIDEkJq2goY35sGitD+ogSVWECjcVbHIAP
M2u9axFGlK7fDOmmkH2ZWDMtwx2I5dZps3q2g9mY2O9Az5Yokp7GW7viSpWXHTRH
xOsuY6aze71U7RWJAHUDBRA3DAEvDuwDH3697LEBAWRHAv9XXkub6mir/DCxzKI2
AE3tek40lRfU6Iukjl/uzT9GXcL3uEjIewiPTwN+k4IL+qcCEdv8WZgv/tO45r59
IZQsicNaSAsKX/6Cxha6Hosg1jw4rjdyz13rgYRi/nreq5mJAJUDBRA2r0CM9p+f
Pnxlu7UBAYObA/40s5SwEpXTrePO78AoUFEa5Z4bgyxkpT7BVbq6m/oQtK509Xe2
M2y0XTLkd86oXpjyKzGzWq8T6ZTKNdF9+5LhS2ylJytdPq1AjDk2BocffWX4+pXn
RPiC6XcNdYGiQL8OTHvZESYQDiHeMfwA8WdMzFK1R80nJMwANYXjJJrLzYkAlQMF
EDNt51zvs7EFZlNtbQEBW0UD/jZB6UDdEFdhS0hxgahv5CxaQDWQbIEpAY9JL1yg
d1RWMKUFGXdRkWZmHEA4NvtwFFeam/HZm4yuGf8yldMyo84loTcVib7lKh4CumGx
FT5Pxeh/F8u9EeQzclRFSMhVl0BA2/HEGyjw0kbkprI/RD3pXD7ewTAUrj2O3XhE
InLgiQCVAwUQM3O9vWyr6JZzEUkFAQF9nAP9Hco0V/3Kl70N5ryPVgh41nUTd7Td
6fUjx8yPoSZLX8vVZ8XMyd8ULFmzsmA+2QG4HcKo/x/4s50O3o8c+o1qSYj0Tp+K
4Z8lneMVlgBNdrRcq4ijEgk0qGqSlsXyLElkVPEXAADBVgzf6yqvipDwXNVzl6e3
GPLE8U2TAnBFZX6JAJUDBRAzZqIFDu2852ZqdCEBATsuBACI3ofP7N3xuHSc7pWL
NsnFYVEc9utBaclcagxjLLzwPKzMBcLjNGyGXIZQNB0d4//UMUJcMS7vwZ8MIton
VubbnJVHuQvENloRRARtarF+LC7OLMCORrGtbt0FtYgvBaqtgXlNcKXD6hRT+ghR
bi3q34akA7Xw8tiFIxdVgSusALQjQnJpYW4gU29tZXJzIDxicmlhbkB1ay5GcmVl
QlNELm9yZz6JAJUDBRA3FLWcnWdBAAxuEhUBAcYYBACos9nKETuaH+z2h0Ws+IIY
mN9FEm8wpPUcQmX5GFhfBUQ+rJbflzv0jJ/f2ac9qJHgIIAlJ3pMkfMpU8UYHEuo
VCe4ZTU5sr4ZdBaF9kpm2OriFgZwIv4QAi7dCMu9ZwGRtZ3+z3DQsVSagucjZTIe
yTUR6K+7E3YXANQjOdqFZYkAlQMFEDcUpeQO7bznZmp0IQEB4HED/Ru3NjwWO1gl
xEiLTzRpU31Rh1Izw1lhVMVJkLAGBw9ieSkjvdIkuhqV1i+W4wKBClT0UOE28Kjp
WbBKPFIASRYzN4ySwpprsG5H45EFQosovYG/HPcMzXU2GMj0iwVTxnMq7I8oH588
ExHqfEN2ARD3ngmB2499ruyGl26pW/BftCBCcmlhbiBTb21lcnMgPGJyaWFuQE9w
ZW5CU0Qub3JnPokAlQMFEDcUtW6dZ0EADG4SFQEBQwsD/j9B/lkltIdnQdjOqR/b
dOBgJCtUf905y6kD+k4kbxeT1YAaA65KJ2o/Zj+i+69F2+BUJ/3kYB7prKwut2h0
ek1ZtncGxoAsQdFJ5JSeMkwUZ5qtGeCmVPb59+KPq3nU6p3RI8Bn77FzK//Qy+IW
/WFVJbf/6NCNCbyRiRjPbGl/iQCVAwUQNxSlyA7tvOdmanQhAQFzMAP/dvtsj3yB
C+seiy6fB/nS+NnKBoff3Ekv57FsZraGt4z9n4sW61eywaiRzuKlhHqrDE17STKa
fBOaV1Ntl7js7og5IFPWNlVh1cK+spDmd655D8pyshziDF6fSAsqGfTn35xl23Xj
O20MMK44j4I5V6rEyUDBDrmX49J56OFkfwa0IEJyaWFuIFNvbWVycyA8YnJpYW5A
RnJlZUJTRC5vcmc+iQCVAwUQNxS1Y51nQQAMbhIVAQHPBQP+IMUlE4DtEvSZFtG4
YK9usfHSkStIafh/F/JzSsqdceLZgwcuifbemw79Rhvqhp0Cyp7kuI2kHO3a19kZ
3ZXlDl3VDg41SV/Z5LzNw9vaZKuF/vtGaktOjac5E5aznWGIA5czwsRgydEOcd8O
VPMUMrdNWRI6XROtnbZaRSwmD8aJAJUDBRA3FKWuDu2852ZqdCEBAWVJA/4x3Mje
QKV+KQoO6mOyoIcD4GK1DjWDvNHGujJbFGBmARjr/PCm2cq42cPzBxnfRhCfyEvN
aesNB0NjLjRU/m7ziyVn92flAzHqqmU36aEdqooXUY2T3vOYzo+bM7VtInarG1iU
qw1G19GgXUwUkPvy9+dNIM/aYoI/e0Iv3P9uug==
=R3k0
-----END PGP PUBLIC KEY BLOCK-----
diff --git a/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml b/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml
index 83cf490b8a..78c96d8a32 100644
--- a/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml
@@ -1,391 +1,391 @@
Source Tree Guidelines and PoliciesContributed by &a.phk;.This chapter documents various guidelines and policies in force for
the FreeBSD source tree.MAINTAINER on MakefilesJune 1996.If a particular portion of the FreeBSD distribution is being
maintained by a person or group of persons, they can communicate this
fact to the world by adding a
MAINTAINER= email-addresses
line to the Makefiles covering this portion of the
source tree.The semantics of this are as follows:The maintainer owns and is responsible for that code. This means
that he is responsible for fixing bugs and answer problem reports
pertaining to that piece of the code, and in the case of contributed
software, for tracking new versions, as appropriate.Changes to directories which have a maintainer defined shall be sent
to the maintainer for review before being committed. Only if the
maintainer does not respond for an unacceptable period of time, to
several emails, will it be acceptable to commit changes without review
by the maintainer. However, it is suggested that you try and have the
changes reviewed by someone else if at all possible.It is of course not acceptable to add a person or group as
maintainer unless they agree to assume this duty. On the other hand it
doesn't have to be a committer and it can easily be a group of
people.Contributed SoftwareContributed by &a.phk; and &a.obrien;. June 1996.Some parts of the FreeBSD distribution consist of software that is
actively being maintained outside the FreeBSD project. For historical
reasons, we call this contributed software. Some
examples are perl, gcc and patch.Over the last couple of years, various methods have been used in
dealing with this type of software and all have some number of
advantages and drawbacks. No clear winner has emerged.Since this is the case, after some debate one of these methods has
been selected as the “official” method and will be required
for future imports of software of this kind. Furthermore, it is
strongly suggested that existing contributed software converge on this
model over time, as it has significant advantages over the old method,
including the ability to easily obtain diffs relative to the
“official” versions of the source by everyone (even without
cvs access). This will make it significantly easier to return changes
to the primary developers of the contributed software.Ultimately, however, it comes down to the people actually doing the
work. If using this model is particularly unsuited to the package being
dealt with, exceptions to these rules may be granted only with the
approval of the core team and with the general consensus of the other
developers. The ability to maintain the package in the future will be a
key issue in the decisions.Because of some unfortunate design limitations with the RCS file
format and CVS's use of vendor branches, minor, trivial and/or
cosmetic changes are strongly discouraged on
files that are still tracking the vendor branch. “Spelling
fixes” are explicitly included here under the
“cosmetic” category and are to be avoided for files with
revision 1.1.x.x. The repository bloat impact from a single character
change can be rather dramatic.The Tcl embedded programming
language will be used as example of how this model works:src/contrib/tcl contains the source as
distributed by the maintainers of this package. Parts that are entirely
not applicable for FreeBSD can be removed. In the case of Tcl, the
mac, win and
compat subdirectories were eliminated before the
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 and without RCS keyword expansion) with as few
FreeBSD-specific changes as possible. The 'easy-import' tool on
freefall will assist in doing the import, but if there are any doubts on
how to go about it, it is imperative that you ask first and not blunder
ahead and hope it “works out”. CVS is not forgiving of
import accidents and a fair amount of effort is required to back out
major mistakes.Because of the previously mentioned design limitations with CVS's
vendor branches, it is required that “official” patches from
the vendor be applied to the original distributed sources and the result
re-imported onto the vendor branch again. Official patches should never
be patched into the FreeBSD checked out version and "committed", as this
destroys the vendor branch coherency and makes importing future versions
rather difficult as there will be conflicts.Since many packages contain files that are meant for compatibility
with other architectures and environments that FreeBSD, it is
permissible to remove parts of the distribution tree that are of no
interest to FreeBSD in order to save space. Files containing copyright
notices and release-note kind of information applicable to the remaining
files shall not be removed.If it seems easier, the 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 outWhere the original distribution was obtained from and/or the
official master site.Where to send patches back to the original authorsPerhaps an overview of the FreeBSD-specific changes that have
been made.However, please do not import FREEBSD-upgrade
with the contributed source. Rather you should cvs add
FREEBSD-upgrade ; cvs ci after the initial import. Example
wording from src/contrib/cpio is below:
This directory contains virgin sources of the original distribution files
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
the files in this directory via patches and a cvs commit. New versions or
official-patch versions must be imported. Please remember to import with
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
For the import of GNU cpio 2.4.2, the following files were removed:
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
To upgrade to a newer version of cpio, when it is available:
1. Unpack the new version into an empty directory.
[Do not make ANY changes to the files.]
2. Remove the files listed above and any others that don't apply to
FreeBSD.
3. Use the command:
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
For example, to do the import of version 2.4.2, I typed:
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Follow the instructions printed out in step 3 to resolve any
conflicts between local FreeBSD changes and the newer version.
Do not, under any circumstances, deviate from this procedure.
To make local changes to cpio, simply patch and commit to the main
branch (aka HEAD). Never make local changes on the GNU branch.
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
inclusion in the next vendor release.
obrien@FreeBSD.org - 30 March 1997Encumbered filesIt might occasionally be necessary to include an encumbered file in
the FreeBSD source tree. For example, if a device requires a small
piece of binary code to be loaded to it before the device will operate,
and we do not have the source to that code, then the binary file is said
to be encumbered. The following policies apply to including encumbered
files in the FreeBSD source tree.Any file which is interpreted or executed by the system CPU(s)
and not in source format is encumbered.Any file with a license more restrictive than BSD or GNU is
encumbered.A file which contains downloadable binary data for use by the
hardware is not encumbered, unless (1) or (2) apply to it. It must
be stored in an architecture neutral ASCII format (file2c or
uuencoding is recommended).Any encumbered file requires specific approval from the Core team before it is added to the
CVS repository.Encumbered files go in src/contrib or
src/sys/contrib.The entire module should be kept together. There is no point in
splitting it, unless there is code-sharing with non-encumbered
code.Object files are named
arch/filename.o.uu>.Kernel files;Should always be referenced in
conf/files.* (for build simplicity).Should always be in LINT, but the Core team decides per case if it
should be commented out or not. The Core team can, of course, change
their minds later on.The Release Engineer
decides whether or not it goes in to the release.User-land files;The Core team decides if
the code should be part of make world.The Release Engineer
decides if it goes in to the release.Shared LibrariesContributed 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.
diff --git a/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml b/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml
index 1a3c352e3a..abb5058d42 100644
--- a/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/ppp-and-slip/chapter.sgml
@@ -1,2488 +1,2488 @@
PPP and SLIPIf your connection to the Internet is through a modem, or you wish to
provide other people with dialup connections to the Internet using
FreeBSD, you have the option of using PPP or SLIP. Furthermore, two
varieties of PPP are provided: user (sometimes
referred to as iijppp) and
kernel. The procedures for configuring both types of
PPP, and for setting up SLIP are described in this chapter.Setting up User PPPUser PPP was introduced to FreeBSD in release 2.0.5 as an addition
to the existing kernel implementation of PPP. So, what is different
about this new PPP that warrants its addition? To quote from the manual
page:
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.There are a large number of enhancements in version 2 of ppp. You
can discover what version you have by running ppp with no arguments and
typing show version at the prompt. It is a simple
matter to upgrade to the latest version of ppp (under any version of
FreeBSD) by downloading the latest archive via www.Awfulhak.org.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 addresses of one or more nameservers. Normally, you
will be given two IP numbers. You must have
this information for PPP version 1.x
unless you run your own nameserver. From version 2 onwards,
PPP supports nameserver address
negotiation. If your ISP supports this, then using the command
enable dns in your config file will tell
PPP to set the nameservers for
you.The following information may have been supplied by your ISP, but
is not strictly necessary:The IP address of your ISP's gateway. The gateway is the
machine to which you will connect and will be set up as your
default route. If your ISP hasn't given you
this number, we can make one up and your ISP's PPP server will
tell us the correct value when we connect.This IP number is referred to as HISADDR
by ppp.Your ISP's netmask. If your ISP hasn't given you this
information, you can safely use a netmask of 255.255.255.0.If your ISP allocates you a static IP address and hostname
then you can enter this information. Otherwise, we simply let the
peer assign whatever IP number it sees fit.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 1
in 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 Configuring the FreeBSD Kernel section
for more information on kernel configuration.You can check how many tunnel devices your current kernel has by
typing the following:&prompt.root; ifconfig -a
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff
tun1: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 576
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff
tun3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500This case shows four tunnel devices, two of which are currently
configured and being used. It should be noted that the
RUNNING flag above indicates that the interface has
been used at some point—it is not an error if your interface
does not show up as RUNNING.If 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
&man.modload.8; and &man.lkm.4; pages for further details.You may also wish to take this opportunity to configure a
firewall. Details can be found in the Firewalls 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:&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tun0If you require 16 tunnel devices in your kernel, you will need to
create more than just tun0:&prompt.root; cd /dev
&prompt.root; ./MAKEDEV tun15Also, to confirm that the kernel is configured correctly, the
following command should give the indicated output:&prompt.root; ifconfig tun0
tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500The RUNNING flag may not yet be set, in which
case you will see:&prompt.root; ifconfig tun0
tun0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500Name 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 (in this
order):
hosts
bindThese 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 /etc/hosts(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 /etc/resolv.conf 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.If you are running PPP version 2 or greater, the enable
dns command will tell PPP to request that your ISP
confirms the nameserver values. If your ISP supplies different
addresses (or if there are no nameserver lines in
/etc/resolv.conf), PPP will rewrite the file
with the ISP-supplied values.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 addressesYou will need to create a configuration file called
/etc/ppp/ppp.conf. It should look similar to
the example below.Lines that end in a : start in the first
column, all other lines should be indented as shown using spaces
or tabs.
1 default:
2 set device /dev/cuaa0
3 set speed 115200
4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\TTIMEOUT 40 CONNECT"
5 provider:
6 set phone "(0123) 456 7890"
7 set login "TIMEOUT 10 \"\" \"\" gin:--gin: foo word: bar col: ppp"
8 set timeout 300
9 set ifaddr x.x.x.xy.y.y.y 255.255.255.0 0.0.0.0
10 add default HISADDR
11 enable dnsDo 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 &man.chat.8; program. Refer to the
manual page for information on the features of this
language.Line 5:Identifies an entry for a provider called
“provider”.Line 6:Sets the phone number for this provider. Multiple phone
numbers may be specified using the : or
| character as a separator. The difference
between these separators is described in &man.ppp.8;.
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.
When you write this script for the first time, you should
enable “chat” logging to ensure that the
conversation is going as expected.If you're using PAP or CHAP, there will be no login at
this point, so your login string can be left blank. See PAP and CHAP
authentication for further details.Line 8: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:Sets the interface addresses. The string
x.x.x.x should be replaced by the
IP address that your provider has allocated to you. The
string y.y.y.y should be replaced
by the IP address that your ISP indicated for their gateway
(the machine to which you connect). If your ISP hasn't given
you a gateway address, use 10.0.0.2/0. If you need to use a
“guessed” address, make sure that you create an
entry in /etc/ppp/ppp.linkup as per the
instructions for PPP and
Dynamic IP addresses. If this line is omitted,
ppp cannot run in or
mode.Line 10:Adds a default route to your 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.Line 11:This line tells PPP to ask your ISP to confirm that your
nameserver addresses are correct. If your ISP supports this
facility, PPP can then update
/etc/resolv.conf with the correct
nameserver entries.It is not necessary to add an entry to
ppp.linkup when you have a static IP address as
your routing table entries are already correct before you connect.
You may however wish to create an entry to invoke programs after
connection. This is explained later with the sendmail
example.Example configuration files can be found in the
/etc/ppp directory.PPP and Dynamic IP addressesIf 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 PPP and Static IP addresses,
with the following change:
9 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0Again, do not include the line numbers, they are just for
reference in this discussion. Indentation of at least one space is
required.Line 9:The number after the / character is the
number of bits of the address that ppp will insist on. You
may wish to use IP numbers more appropriate to your
circumstances, but the above example will always work.The last argument (0.0.0.0) tells PPP
to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use
0.0.0.0 as the first argument to
set ifaddr as it prevents PPP from setting
up an initial route in mode.If you are running version 1.x of PPP, you will also need to
create an entry in /etc/ppp/ppp.linkup.
ppp.linkup is used after a connection has been
established. At this point, ppp will know what
IP addresses should really be used. The
following entry will delete the existing bogus routes, and create
correct ones:
1 provider:
2 delete ALL
3 add 0 0 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.Version 2 of PPP introduces “sticky routes”. Any
add or delete lines that
contain MYADDR or HISADDR will
be remembered, and any time the actual values of
MYADDR or HISADDR change, the
routes will be re-applied. This removes the necessity of repeating
these lines in ppp.linkup.Receiving incoming calls with pppThis section describes setting up ppp in a
server role.When you configure ppp to receive incoming
calls on a machine connected to a LAN, you must decide if you wish
to forward packets to the LAN. If you do, you should allocate the
peer an IP number from your LAN's subnet, and use the command
enable proxy
in your ppp.conf file. You should also confirm
that the /etc/rc.conf file (this file used to
be called /etc/sysconfig) contains the
following:
gateway=YESWhich getty?Configuring FreeBSD for Dialup
Services 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 Mgetty and
AutoPPP 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.You will also need to give them access to one or more sections
of the configuration file using the allow
command:
allow users fred maryIf this command is used in the default
section, it gives the specified users access to everything.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:&prompt.root; ln -s 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 .rhosts
which 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:&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred
&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam
&prompt.root; ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-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 proxyThe indenting is important.The default: section is loaded for each
session. For each dialup line enabled in
/etc/ttys create an entry similar to the one
for ttyd0: above. Each line should get a
unique IP address from your pool of IP addresses for dynamic
users.Setting up 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 AutoPPPConfiguring 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
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.
pap:
enable pap
set ifaddr 203.14.100.1 203.14.100.20-203.14.100.40
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/password file.If you wish to assign some users a static IP number, you can
specify the number as the third argument in
/etc/ppp/ppp.secret. See
/etc/ppp/ppp.secret.sample for
examples.MS extensionsIt is possible to configure PPP to supply DNS and NetBIOS
nameserver addresses on demand.To enable these extensions with PPP version 1.x, the
following lines might be added to the relevant section of
/etc/ppp/ppp.conf.
enable msext
set ns 203.14.100.1 203.14.100.2
set nbns 203.14.100.5And for PPP version 2 and above:
accept dns
set dns 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.In version 2 and above, if the set dns
line is omitted, PPP will use the values found in
/etc/resolv.conf.PAP and CHAP authenticationSome ISPs set their system up so that the authentication part of
your connection is done using either of the PAP or CHAP
authentication mechanisms. If this is the case, your ISP will not
give a login: prompt when you connect, but will
start talking PPP immediately.PAP is less secure than CHAP, but security is not normally an
issue here as passwords, although being sent as plain text with PAP,
are being transmitted down a serial line only. There's not much room
for crackers to “eavesdrop”.Referring back to the PPP and
Static IP addresses or PPP and Dynamic IP addresses
sections, the following alterations must be made:
7 set login
…
12 set authname MyUserName
13 set authkey 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 12:This line specifies your PAP/CHAP user name. You will
need to insert the correct value for
MyUserName.Line 13: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 both accepted by default.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
diagnostic port has been set up. To do this, add the following line
to your configuration:
set server /var/run/ppp-tun%d DiagnosticPassword 0177This will tell PPP to listen to the specified unix-domain
socket, asking clients for the specified password before allowing
access. The %d in the name is replaced with the
tun device number that is in use.Once a socket has been set up, the
&man.pppctl.8; program may be used in scripts that wish to
manipulate the running program.Final system configurationYou 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:&prompt.root; /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&prompt.root; 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&prompt.root; 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
&man.vipw.8; program).Create a profile in this users home directory that runs
ppp -direct direct-server or similar.Create an entry in /etc/ppp/ppp.conf.
The direct-server example should
suffice.Create an entry in
/etc/ppp/ppp.linkup.Update your /etc/rc.conf (or
sysconfig) file.AcknowledgmentsThis section of the handbook was last updated on Monday Aug 10,
1998 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:&prompt.root; /usr/src/usr.sbin/pppd.new/pppd /dev/tty0119200Use 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 serve must supply your IP address.
# if the remote host doesn't send your IP during
# IPCP negotiation, remove this option
passive # wait for LCP packets
domain <your.domain> # put your domain name here
: # put the IP of remote PPP host here
# it will be used to route packets via PPP link
# if you didn't specified the noipdefault option
# change this line to <local_ip>:<remote_ip>
defaultroute # put this if you want that PPP server will be
# your default router/etc/ppp/login.chat.script:(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 is&prompt.root; pppdThis 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 to /dev/modem from
/dev/cuaa1, and only use the modem name in my
configuration files. It can become quite cumbersome when you need to
fix a bunch of files in /etc and
.kermrc's all over the system!/dev/cuaa0 is COM1,
cuaa1 is COM2,
etc.Make sure you have
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 ns2By 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.domainYou 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=NOto:
defaultrouter=slip-gatewayMake a file /etc/resolv.conf which
contains:
domain HIP.Berkeley.EDU
nameserver 128.32.136.9
nameserver 128.32.136.12As 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:&prompt.root; slattach -h -c -s 115200 /dev/modemIf 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
&prompt.root; 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:&prompt.root; 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:&prompt.root; netstat -r
Routing tables
Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks:
(root node)
(root node)
Route Tree for Protocol Family inet:
(root node) =>
default inr-3.Berkeley.EDU UG 8 224515 sl0 - -
localhost.Berkel localhost.Berkeley UH 5 42127 lo0 - 0.438
inr-3.Berkeley.E silvia.HIP.Berkele UH 1 0 sl0 - -
silvia.HIP.Berke localhost.Berkeley UGH 34 47641234 lo0 - 0.438
(root node)(this is after transferring a bunch of files, your numbers
should be smaller).Setting up a SLIP 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
&man.sio.4; for information on the serial port device driver and
&man.ttys.5;, &man.gettytab.5;, &man.getty.8;, & &man.init.8;
for information relevant to configuring the system to accept logins on
modems, and perhaps &man.stty.1; for information on setting serial
port parameters (such as clocal for
directly-connected serial interfaces).Quick 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/sliploginWhen 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 &man.syslogd.8; and
&man.syslog.conf.5, and perhaps check
/etc/syslog.conf to see to which files
syslogd is logging).OK, enough of the examples — let us dive into setting up
the system.Kernel 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 2This is the line that defines the number of SLIP devices available
in the kernel; the number at the end of the line is the maximum number
of SLIP connections that may be operating simultaneously.Please refer to Configuring the
FreeBSD Kernel for help in reconfiguring your kernel.Sliplogin ConfigurationAs mentioned earlier, there are three files in the
/etc/sliphome directory that are part of the
configuration for /usr/sbin/sliplogin (see
&man.sliplogin.8; for the actual manual page for
sliplogin): slip.hosts, which
defines the SLIP users & their associated IP addresses;
slip.login, which usually just configures the
SLIP interface; and (optionally) slip.logout,
which undoes slip.login's effects when the serial
connection is terminated.slip.hosts Configuration/etc/sliphome/slip.hosts contains lines
which have at least four items, separated by whitespace:SLIP user's login IDLocal address (local to the SLIP server) of the SLIP
linkRemote address of the SLIP linkNetwork 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:
#
# login local-addr remote-addr mask opt1 opt2
# (normal,compress,noicmp)
#
Shelmerg dc-slip sl-helmerg 0xfffffc00 autocompAt the end of the line is one or more of the options. — no header compression — compress headers — compress headers if the
remote end allows it — disable ICMP packets (so any
“ping” packets will be dropped instead of using up
your bandwidth)Note that sliplogin under early releases of
FreeBSD 2 ignored the options that FreeBSD 1.x recognized, so the
options , ,
, and had no effect
until support was added in FreeBSD 2.2 (unless your
slip.login script included code to make use of
the flags).Your choice of local and remote addresses for your SLIP links
depends on whether you are going to dedicate a TCP/IP subnet or if
you are going to use “proxy ARP” on your SLIP server (it
is not “true” proxy ARP, but that is the terminology
used in this document to describe it). If you are not sure which
method to select or how to assign IP addresses, please refer to the
TCP/IP books referenced in the slips-prereqs section and/or
consult your IP network manager.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
&man.arp.8; to manage the proxy-ARP entries in the SLIP server's
ARP table.slip.login ConfigurationThe typical /etc/sliphome/slip.login file
looks like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 inet $4 $5 netmask $6This slip.login file merely
ifconfig's the appropriate SLIP interface with
the local and remote addresses and network mask of the SLIP
interface.If you have decided to use the “proxy ARP” method
(instead of using a separate subnet for your SLIP clients), your
/etc/sliphome/slip.login file will need to look
something like this:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# generic login file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 inet $4 $5 netmask $6
# Answer ARP requests for the SLIP client with our Ethernet addr
/usr/sbin/arp -s $5 00:11:22:33:44:55 pubThe 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 116This indicates that this particular system's Ethernet MAC
address is 00:02:c1:28:5f:4a — the
periods in the Ethernet MAC address given by netstat
-i must be changed to colons and leading zeros should be
added to each single-digit hexadecimal number to convert the address
into the form that
&man.arp.8; desires; see the manual page on &man.arp.8; for
complete information on usage.When you create /etc/sliphome/slip.login
and /etc/sliphome/slip.logout, the
“execute” bit (ie, chmod 755
/etc/sliphome/slip.login /etc/sliphome/slip.logout)
must be set, or sliplogin will be unable to
execute it.slip.logout Configuration/etc/sliphome/slip.logout is not strictly
needed (unless you are implementing “proxy ARP”), but if
you decide to create it, this is an example of a basic
slip.logout script:
#!/bin/sh -
#
# slip.logout
#
# logout file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 downIf you are using “proxy ARP”, you will want to have
/etc/sliphome/slip.logout remove the ARP entry
for the SLIP client:
#!/bin/sh -
#
# @(#)slip.logout
#
# logout file for a slip line. sliplogin invokes this with
# the parameters:
# 1 2 3 4 5 6 7-n
# slipunit ttyspeed loginname local-addr remote-addr mask opt-args
#
/sbin/ifconfig sl$1 down
# Quit answering ARP requests for the SLIP client
/usr/sbin/arp -d $5The arp -d $5 removes the ARP entry that
the “proxy ARP” slip.login added
when the SLIP client logged in.It bears repeating: make sure
/etc/sliphome/slip.logout has the execute
bit set for after you create it (ie, chmod
755 /etc/sliphome/slip.logout).Routing 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 ports
collection 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:
#
# 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 ;
} ;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 SeriniPiero@Strider.Inet.IT
diff --git a/en_US.ISO_8859-1/books/handbook/printing/chapter.sgml b/en_US.ISO_8859-1/books/handbook/printing/chapter.sgml
index 615765ce16..918b4132e0 100644
--- a/en_US.ISO_8859-1/books/handbook/printing/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/printing/chapter.sgml
@@ -1,4665 +1,4665 @@
PrintingContributed by &a.kelly; 30 September
1995In order to use printers with FreeBSD, you will need to set them up to
work with the Berkeley line printer spooling system, also known as the LPD
spooling system. It is the standard printer control system in FreeBSD.
This section introduces the LPD spooling system, often simply called
LPD.If you are already familiar with LPD or another printer spooling
system, you may wish to skip to section Setting up the spooling
system.What the Spooler DoesLPD controls everything about a host's printers. It is responsible
for a number of things:It controls access to attached printers and printers attached to
other hosts on the network.It enables users to submit files to be printed; these
submissions are known as jobs.It prevents multiple users from accessing a printer at the same
time by maintaining a queue for each
printer.It can print header pages (also known as
banner or burst pages) so
users can easily find jobs they have printed in a stack of
printouts.It takes care of communications parameters for printers
connected on serial ports.It can send jobs over the network to another LPD spooler on
another host.It can run special filters to format jobs to be printed for
various printer languages or printer capabilities.It can account for printer usage.Through a configuration file, and by providing the special filter
programs, you can enable the LPD system to do all or some subset of the
above for a great variety of printer hardware.Why You Should Use the SpoolerIf you are the sole user of your system, you may be wondering why
you should bother with the spooler when you do not need access control,
header pages, or printer accounting. While it is possible to enable
direct access to a printer, you should use the spooler anyway
sinceLPD prints jobs in the background; you do not have to wait for
data to be copied to the printer.LPD can conveniently run a job to be printed through filters to
add date/time headers or convert a special file format (such as a
TeX DVI file) into a format the printer will understand. You will
not have to do these steps manually.Many free and commercial programs that provide a print feature
usually expect to talk to the spooler on your system. By setting up
the spooling system, you will more easily support other software you
may later add or already have.Setting Up the Spooling SystemTo use printers with the LPD spooling system, you will need to set
up both your printer hardware and the LPD software. This document
describes two levels of setup:See section Simple Printer
Setup to learn how to connect a printer, tell LPD how to
communicate with it, and print plain text files to the
printer.See section Advanced Printer
Setup to find out how to print a variety of special file
formats, to print header pages, to print across a network, to
control access to printers, and to do printer accounting.Simple Printer SetupThis section tells how to configure printer hardware and the LPD
software to use the printer. It teaches the basics:Section Hardware Setup
gives some hints on connecting the printer to a port on your
computer.Section Software Setup
shows how to setup the LPD spooler configuration file
/etc/printcap.If you are setting up a printer that uses a network protocol to
accept data to print instead of a serial or parallel interface, see
Printers With Networked
Data Stream Interaces.Although this section is called “Simple Printer Setup,”
it is actually fairly complex. Getting the printer to work with your
computer and the LPD spooler is the hardest part. The advanced options
like header pages and accounting are fairly easy once you get the
printer working.Hardware SetupThis section tells about the various ways you can connect a
printer to your PC. It talks about the kinds of ports and cables, and
also the kernel configuration you may need to enable FreeBSD to speak
to the printer.If you have already connected your printer and have successfully
printed with it under another operating system, you can probably skip
to section Software
Setup.Ports and CablesNearly all printers you can get for a PC today support one or
both of the following interfaces:Serial interfaces use a serial port on
your computer to send data to the printer. Serial interfaces
are common in the computer industry and cables are readily
available and also easy to construct. Serial interfaces
sometimes need special cables and might require you to configure
somewhat complex communications options.Parallel interfaces use a parallel port
on your computer to send data to the printer. Parallel
interfaces are common in the PC market. Cables are readily
available but more difficult to construct by hand. There are
usually no communications options with parallel interfaces,
making their configuration exceedingly simple.Parallel interfaces are sometimes known as
“Centronics” interfaces, named after the connector
type on the printer.In general, serial interfaces are slower than parallel
interfaces. Parallel interfaces usually offer just one-way
communication (computer to printer) while serial gives you two-way.
Many newer parallel ports can also receive data from the printer,
but only few printers need to send data back to the computer. And
FreeBSD does not support two-way parallel communication yet.Usually, the only time you need two-way communication with the
printer is if the printer speaks PostScript. PostScript printers
can be very verbose. In fact, PostScript jobs are actually programs
sent to the printer; they need not produce paper at all and may
return results directly to the computer. PostScript also uses
two-way communication to tell the computer about problems, such as
errors in the PostScript program or paper jams. Your users may be
appreciative of such information. Furthermore, the best way to do
effective accounting with a PostScript printer requires two-way
communication: you ask the printer for its page count (how many
pages it has printed in its lifetime), then send the user's job,
then ask again for its page count. Subtract the two values and you
know how much paper to charge the user.So, which interface should you use?If you need two-way communication, use a serial port.
FreeBSD does not yet support two-way communication over a
parallel port.If you do not need two-way communication and can pick
parallel or serial, prefer the parallel interface. It keeps a
serial port free for other peripherals—such as a terminal
or a modem—and is faster most of the time. It is also
easier to configure.Finally, use whatever works.Parallel PortsTo hook up a printer using a parallel interface, connect the
Centronics cable between the printer and the computer. The
instructions that came with the printer, the computer, or both
should give you complete guidance.Remember which parallel port you used on the computer. The
first parallel port is /dev/lpt0 to FreeBSD;
the second is /dev/lpt1, and so on.Serial PortsTo hook up a printer using a serial interface, connect the
proper serial cable between the printer and the computer. The
instructions that came with the printer, the computer, or both
should give you complete guidance.If you are unsure what the “proper serial cable” is,
you may wish to try one of the following alternatives:A modem cable connects each pin of the
connector on one end of the cable straight through to its
corresponding pin of the connector on the other end. This type
of cable is also known as a “DTE-to-DCE”
cable.A null-modem cable connects some pins
straight through, swaps others (send data to receive data, for
example), and shorts some internally in each connector hood.
This type of cable is also known as a “DTE-to-DTE”
cable.A serial printer cable, required for
some unusual printers, is like the null modem cable, but sends
some signals to their counterparts instead of being internally
shorted.You should also set up the communications parameters for the
printer, usually through front-panel controls or DIP switches on the
printer. Choose the highest bps (bits per second, sometimes
baud rate) rate that both your computer and the
printer can support. Choose 7 or 8 data bits; none, even, or odd
parity; and 1 or 2 stop bits. Also choose a flow control protocol:
either none, or XON/XOFF (also known as “in-band” or
“software”) flow control. Remember these settings for
the software configuration that follows.Software SetupThis section describes the software setup necessary to print
with the LPD spooling system in FreeBSD.Here is an outline of the steps involved:Configure your kernel, if necessary, for the port you are
using for the printer; section Kernel Configuration tells you
what you need to do.Set the communications mode for the parallel port, if you are
using a parallel port; section Setting the Communication
Mode for the Parallel Port gives details.Test if the operating system can send data to the printer.
Section Checking Printer
Communications gives some suggestions on how to do
this.Set up LPD for the printer by modifying the file
/etc/printcap. Section The /etc/printcap File shows
you how.Kernel ConfigurationThe operating system kernel is compiled to work with a specific
set of devices. The serial or parallel interface for your printer
is a part of that set. Therefore, it might be necessary to add
support for an additional serial or parallel port if your kernel is
not already configured for one.To find out if the kernel you are currently using supports a
serial interface, type:&prompt.root; dmesg | grep sioNWhere N is the number of the serial
port, starting from zero. If you see output similar to the
following:sio2 at 0x3e8-0x3ef irq 5 on isa
sio2: type 16550Athen the kernel supports the port.To find out if the kernel supports a parallel interface,
type:&prompt.root; dmesg | grep lptNWhere N is the number of the parallel
port, starting from zero. If you see output similar to the
following lpt0 at 0x378-0x37f on isa then the
kernel supports the port.You might have to reconfigure your kernel in order for the
operating system to recognize and use the parallel or serial port
you are using for the printer.To add support for a serial port, see the section on kernel
configuration. To add support for a parallel port, see that section
and the section that follows.Adding /dev Entries for the PortsEven though the kernel may support communication along a
serial or parallel port, you will still need a software interface
through which programs running on the system can send and receive
data. That is what entries in the /dev
directory are for.To add a /dev entry for a
port:Become root with the &man.su.1; command. Enter the root
password when prompted.Change to the /dev directory:&prompt.root; cd /devType:&prompt.root; ./MAKEDEV portWhere port is the device entry
for the port you want to make. Use lpt0
for the first parallel port, lpt1 for the
second, and so on; use ttyd0 for the first
serial port, ttyd1 for the second, and so
on.Type:&prompt.root; ls -l portto make sure the device entry got created.Setting the Communication Mode for the Parallel PortWhen you are using the parallel interface, you can choose
whether FreeBSD should use interrupt-driven or polled
communication with the printer.The interrupt-driven method is the
default with the GENERIC kernel. With this method, the
operating system uses an IRQ line to determine when the
printer is ready for data.The polled method directs the
operating system to repeatedly ask the printer if it is ready
for more data. When it responds ready, the kernel sends more
data.The interrupt-driven method is somewhat faster but uses up a
precious IRQ line. You should use whichever one works.You can set the communications mode in two ways: by
configuring the kernel or by using the &man.lptcontrol.8;
program.To set the communications mode by configuring the
kernel:Edit your kernel configuration file. Look for or add an
lpt0 entry. If you are setting up the
second parallel port, use lpt1 instead.
Use lpt2 for the third port, and so
on.If you want interrupt-driven mode, add the
irq specifier:
device lpt0 at isa? port? tty irq N vector lptintrWhere N is the IRQ number
for your computer's parallel port.If you want polled mode, do not add the
irq specifier:
device lpt0 at isa? port? tty vector lptintrSave the file. Then configure, build, and install the
kernel, then reboot. See kernel
configuration for more details.To set the communications mode with
&man.lptcontrol.8;:Type:&prompt.root; lptcontrol -i -u Nto set interrupt-driven mode for
lptN.Type:&prompt.root; lptcontrol -p -u Nto set polled-mode for
lptN.You could put these commands in your
/etc/rc.local file to set the mode each time
your system boots. See &man.lptcontrol.8; for more
information.Checking Printer CommunicationsBefore proceeding to configure the spooling system, you should
make sure the operating system can successfully send data to your
printer. It is a lot easier to debug printer communication and
the spooling system separately.To test the printer, we will send some text to it. For
printers that can immediately print characters sent to them,
the program &man.lptest.1; is perfect: it generates all 96
printable ASCII characters in 96 lines.For a PostScript (or other language-based) printer, we will
need a more sophisticated test. A small PostScript program, such
as the following, will suffice:
%!PS
100 100 moveto 300 300 lineto stroke
310 310 moveto /Helvetica findfont 12 scalefont setfont
(Is this thing working?) show
showpageWhen this document refers to a printer language, I am
assuming a language like PostScript, and not Hewlett Packard's
PCL. Although PCL has great functionality, you can intermingle
plain text with its escape sequences. PostScript cannot directly
print plain text, and that is the kind of printer language for
which we must make special accommodations.Checking a Parallel PrinterThis section tells you how to check if FreeBSD can
communicate with a printer connected to a parallel port.To test a printer on a parallel
port:Become root with &man.su.1;.Send data to the printer.If the printer can print plain text, then use
&man.lptest.1;. Type:&prompt.root; lptest > /dev/lptNWhere N is the number of
the parallel port, starting from zero.If the printer understands PostScript or other
printer language, then send a small program to the
printer. Type:&prompt.root; cat > /dev/lptNThen, line by line, type the program
carefully as you cannot edit a line
once you have pressed RETURN or ENTER. When you have
finished entering the program, press CONTROL+D, or
whatever your end of file key is.Alternatively, you can put the program in a file and
type:&prompt.root; cat file > /dev/lptNWhere file is the name of
the file containing the program you want to send to the
printer.You should see something print. Do not worry if the text
does not look right; we will fix such things later.Checking a Serial PrinterThis section tells you how to check if FreeBSD can
communicate with a printer on a serial port.To test a printer on a serial
port:Become root with &man.su.1;.Edit the file /etc/remote. Add the
following entry:
printer:dv=/dev/port:br#bps-rate:pa=parityWhere port is the device
entry for the serial port (ttyd0,
ttyd1, etc.),
bps-rate is the bits-per-second
rate at which the printer communicates, and
parity is the parity required by
the printer (either even,
odd, none, or
zero).Here is a sample entry for a printer connected via a
serial line to the third serial port at 19200 bps with no
parity:
printer:dv=/dev/ttyd2:br#19200:pa=noneConnect to the printer with &man.tip.1;. Type:&prompt.root; tip printerIf this step does not work, edit the file
/etc/remote again and try using
/dev/cuaaN
instead of
/dev/ttydN.Send data to the printer.If the printer can print plain text, then use
&man.lptest.1;. Type:~$lptestIf the printer understands PostScript or other
printer language, then send a small program to the
printer. Type the program, line by line, very
carefully as backspacing or other editing
keys may be significant to the printer. You may also
need to type a special end-of-file key for the printer
so it knows it received the whole program. For
PostScript printers, press CONTROL+D.Alternatively, you can put the program in a file and
type:~>fileWhere file is the name of
the file containing the program. After
&man.tip.1; sends the file, press any required
end-of-file key.You should see something print. Do not worry if the text
does not look right; we will fix that later.Enabling the Spooler: The /etc/printcap
FileAt this point, your printer should be hooked up, your kernel
configured to communicate with it (if necessary), and you have been
able to send some simple data to the printer. Now, we are ready to
configure LPD to control access to your printer.You configure LPD by editing the file
/etc/printcap. The LPD spooling system reads
this file each time the spooler is used, so updates to the file take
immediate effect.The format of the &man.printcap.5; file is straightforward. Use
your favorite text editor to make changes to
/etc/printcap. The format is identical to
other capability files like
/usr/share/misc/termcap and
/etc/remote. For complete information about
the format, see the &man.cgetent.3;.The simple spooler configuration consists of the following
steps:Pick a name (and a few convenient aliases) for the printer,
and put them in the /etc/printcap file; see
Naming the
Printer.Turn off header pages (which are on by default) by inserting
the sh capability; see Suppressing Header
Pages.Make a spooling directory, and specify its location with the
sd capability; see Making the Spooling
Directory.Set the /dev entry to use for the
printer, and note it in /etc/printcap with
the lp capability; see Identifying the Printer
Device. Also, if the printer is on a serial port, set
up the communication parameters with the fs,
fc, xs, and
xc capabilities; see Configuring Spooler
Communications Parameters.Install a plain text input filter; see Installing the Text
FilterTest the setup by printing something with the
&man.lpr.1; command; see Trying It Out and Troubleshooting.Language-based printers, such as PostScript printers, cannot
directly print plain text. The simple setup outlined above and
described in the following sections assumes that if you are
installing such a printer you will print only files that the
printer can understand.Users often expect that they can print plain text to any of the
printers installed on your system. Programs that interface to LPD
to do their printing usually make the same assumption. If you are
installing such a printer and want to be able to print jobs in the
printer language and print plain text jobs, you
are strongly urged to add an additional step to the simple setup
outlined above: install an automatic plain-text-to-PostScript (or
other printer language) conversion program. Section Accommodating Plain Text
Jobs on PostScript Printers tells how to do this.Naming the PrinterThe first (easy) step is to pick a name for your printer. It
really does not matter whether you choose functional or whimsical
names since you can also provide a number aliases for the
printer.At least one of the printers specified in the
/etc/printcap should have the alias
lp. This is the default printer's name. If
users do not have the PRINTER environment variable
nor specify a printer name on the command line of any of the LPD
commands, then lp will be the default printer
they get to use.Also, it is common practice to make the last alias for a
printer be a full description of the printer, including make and
model.Once you have picked a name and some common aliases, put them
in the /etc/printcap file. The name of the
printer should start in the leftmost column. Separate each alias
with a vertical bar and put a colon after the last alias.In the following example, we start with a skeletal
/etc/printcap that defines two printers (a
Diablo 630 line printer and a Panasonic KX-P4455 PostScript laser
printer):
#
# /etc/printcap for host rose
#
rattan|line|diablo|lp|Diablo 630 Line Printer:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:In this example, the first printer is named
rattan and has as aliases
line, diablo,
lp, and Diablo 630 Line
Printer. Since it has the alias
lp, it is also the default printer. The second
is named bamboo, and has as aliases
ps, PS,
S, panasonic, and
Panasonic KX-P4455 PostScript v51.4.Suppressing Header PagesThe LPD spooling system will by default print a
header page for each job. The header page
contains the user name who requested the job, the host from which
the job came, and the name of the job, in nice large letters.
Unfortunately, all this extra text gets in the way of debugging
the simple printer setup, so we will suppress header pages.To suppress header pages, add the sh
capability to the entry for the printer in
/etc/printcap. Here is the example
/etc/printcap with sh
added:
#
# /etc/printcap for host rose - no header pages anywhere
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:Note how we used the correct format: the first line starts in
the leftmost column, and subsequent lines are indented with a
single TAB. Every line in an entry except the last ends in a
backslash character.Making the Spooling DirectoryThe next step in the simple spooler setup is to make a
spooling directory, a directory where print
jobs reside until they are printed, and where a number of other
spooler support files live.Because of the variable nature of spooling directories, it is
customary to put these directories under
/var/spool. It is not necessary to backup
the contents of spooling directories, either. Recreating them is
as simple as running &man.mkdir.1;.It is also customary to make the directory with a name that is
identical to the name of the printer, as shown below:&prompt.root; mkdir /var/spool/printer-nameHowever, if you have a lot of printers on your network, you
might want to put the spooling directories under a single
directory that you reserve just for printing with LPD. We will do
this for our two example printers rattan and
bamboo:&prompt.root; mkdir /var/spool/lpd
&prompt.root; mkdir /var/spool/lpd/rattan
&prompt.root; mkdir /var/spool/lpd/bambooIf you are concerned about the privacy of jobs that users
print, you might want to protect the spooling directory so it is
not publicly accessible. Spooling directories should be owned
and be readable, writable, and searchable by user daemon and
group daemon, and no one else. We will do this for our example
printers:&prompt.root; chown daemon.daemon /var/spool/lpd/rattan
&prompt.root; chown daemon.daemon /var/spool/lpd/bamboo
&prompt.root; chmod 770 /var/spool/lpd/rattan
&prompt.root; chmod 770 /var/spool/lpd/bambooFinally, you need to tell LPD about these directories using
the /etc/printcap file. You specify the
pathname of the spooling directory with the sd
capability:
#
# /etc/printcap for host rose - added spooling directories
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:Note that the name of the printer starts in the first column
but all other entries describing the printer should be indented
with a tab and each line escaped with a backslash.If you do not specify a spooling directory with
sd, the spooling system will use
/var/spool/lpd as a default.Identifying the Printer DeviceIn section Adding /dev
Entries for the Ports, we identified which entry in the
/dev directory FreeBSD will use to
communicate with the printer. Now, we tell LPD that information.
When the spooling system has a job to print, it will open the
specified device on behalf of the filter program (which is
responsible for passing data to the printer).List the /dev entry pathname in the
/etc/printcap file using the
lp capability.In our running example, let us assume that
rattan is on the first parallel port, and
bamboo is on a sixth serial port; here are the
additions to /etc/printcap:
#
# /etc/printcap for host rose - identified what devices to use
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:If you do not specify the lp capability for
a printer in your /etc/printcap file, LPD
uses /dev/lp as a default.
/dev/lp currently does not exist in
FreeBSD.If the printer you are installing is connected to a parallel
port, skip to the section Installing the Text Filter.
Otherwise, be sure to follow the instructions in the next
section.Configuring Spooler Communication ParametersFor printers on serial ports, LPD can set up the bps rate,
parity, and other serial communication parameters on behalf of the
filter program that sends data to the printer. This is
advantageous since:It lets you try different communication parameters by
simply editing the /etc/printcap file;
you do not have to recompile the filter program.It enables the spooling system to use the same filter
program for multiple printers which may have different serial
communication settings.The following /etc/printcap capabilities
control serial communication parameters of the device listed in
the lp capability:br#bps-rateSets the communications speed of the device to
bps-rate, where
bps-rate can be 50, 75, 110, 134,
150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, or
38400 bits-per-second.fc#clear-bitsClears the flag bits
clear-bits in the
sgttyb structure after opening
the device.fs#set-bitsSets the flag bits set-bits
in the sgttyb structure.xc#clear-bitsClears local mode bits
clear-bits after opening the
device.xs#set-bitsSets local mode bits
set-bits.For more information on the bits for the
fc, fs,
xc, and xs capabilities, see
the file
/usr/include/sys/ioctl_compat.h.When LPD opens the device specified by the
lp capability, it reads the flag bits in the
sgttyb structure; it clears any bits in the
fc capability, then sets bits in the
fs capability, then applies the resultant
setting. It does the same for the local mode bits as well.Let us add to our example printer on the sixth serial port.
We will set the bps rate to 38400. For the flag bits, we will set
the TANDEM, ANYP, LITOUT, FLUSHO, and PASS8 flags. For the local
mode bits, we will set the LITOUT and PASS8 flags:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:fs#0x82000c1:xs#0x820:Installing the Text FilterWe are now ready to tell LPD what text filter to use to send
jobs to the printer. A text filter, also
known as an input filter, is a program that
LPD runs when it has a job to print. When LPD runs the text
filter for a printer, it sets the filter's standard input to the
job to print, and its standard output to the printer device
specified with the lp capability. The filter
is expected to read the job from standard input, perform any
necessary translation for the printer, and write the results to
standard output, which will get printed. For more information on
the text filter, see section Filters.For our simple printer setup, the text filter can be a small
shell script that just executes /bin/cat to
send the job to the printer. FreeBSD comes with another filter
called lpf that handles backspacing and
underlining for printers that might not deal with such character
streams well. And, of course, you can use any other filter
program you want. The filter lpf is described
in detail in section lpf: a
Text Filter.First, let us make the shell script
/usr/local/libexec/if-simple be a simple text
filter. Put the following text into that file with your favorite
text editor:
#!/bin/sh
#
# if-simple - Simple text input filter for lpd
# Installed in /usr/local/libexec/if-simple
#
# Simply copies stdin to stdout. Ignores all filter arguments.
/bin/cat && exit 0
exit 2Make the file executable:&prompt.root; chmod 555 /usr/local/libexec/if-simpleAnd then tell LPD to use it by specifying it with the
if capability in
/etc/printcap. We will add it to the two
printers we have so far in the example
/etc/printcap:
#
# /etc/printcap for host rose - added text filter
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:\
:if=/usr/local/libexec/if-simple:Trying It OutYou have reached the end of the simple LPD setup.
Unfortunately, congratulations are not quite yet in order, since
we still have to test the setup and correct any problems. To test
the setup, try printing something. To print with the LPD system,
you use the command &man.lpr.1;,
which submits a job for printing.You can combine &man.lpr.1; with the &man.lptest.1; program,
introduced in section Checking
Printer Communications to generate some test text.To test the simple LPD setup:Type:&prompt.root; lptest 20 5 | lpr -Pprinter-nameWhere printer-name is a the name of
a printer (or an alias) specified in
/etc/printcap. To test the default printer,
type &man.lpr.1; without any
argument. Again, if you are testing a printer
that expects PostScript, send a PostScript program in that
language instead of using &man.lptest.1;. You can do so by
putting the program in a file and typing lpr
file.For a PostScript printer, you should get the results of the
program. If you are using &man.lptest.1;, then your results
should look like the following:
!"#$%&'()*+,-./01234
"#$%&'()*+,-./012345
#$%&'()*+,-./0123456
$%&'()*+,-./01234567
%&'()*+,-./012345678To further test the printer, try downloading larger programs
(for language-based printers) or running &man.lptest.1; with
different arguments. For example, lptest 80 60
will produce 60 lines of 80 characters each.If the printer did not work, see the next section, Troubleshooting.TroubleshootingAfter performing the simple test with &man.lptest.1;, you
might have gotten one of the following results instead of the
correct printout:It worked, after awhile; or, it did not eject a full
sheet.The printer printed the above, but it sat for awhile and
did nothing. In fact, you might have needed to press a
PRINT REMAINING or FORM FEED button on the printer to get
any results to appear.If this is the case, the printer was probably waiting to
see if there was any more data for your job before it
printed anything. To fix this problem, you can have the
text filter send a FORM FEED character (or whatever is
necessary) to the printer. This is usually sufficient to
have the printer immediately print any text remaining in its
internal buffer. It is also useful to make sure each print
job ends on a full sheet, so the next job does not start
somewhere on the middle of the last page of the previous
job.The following replacement for the shell script
/usr/local/libexec/if-simple prints a
form feed after it sends the job to the printer:
#!/bin/sh
#
# if-simple - Simple text input filter for lpd
# Installed in /usr/local/libexec/if-simple
#
# Simply copies stdin to stdout. Ignores all filter arguments.
# Writes a form feed character (\f) after printing job.
/bin/cat && printf "\f" && exit 0
exit 2It produced the “staircase effect.”You got the following on paper:
!"#$%&'()*+,-./01234
"#$%&'()*+,-./012345
#$%&'()*+,-./0123456You have become another victim of the
staircase effect, caused by conflicting
interpretations of what characters should indicate a
new-line. UNIX-style operating systems use a single
character: ASCII code 10, the line feed (LF). MS-DOS, OS/2,
and others uses a pair of characters, ASCII code 10
and ASCII code 13 (the carriage return
or CR). Many printers use the MS-DOS convention for
representing new-lines.When you print with FreeBSD, your text used just the
line feed character. The printer, upon seeing a line feed
character, advanced the paper one line, but maintained the
same horizontal position on the page for the next character
to print. That is what the carriage return is for: to move
the location of the next character to print to the left edge
of the paper.Here is what FreeBSD wants your printer to do:Printer received CRPrinter prints CRPrinter received LFPrinter prints CR + LFHere are some ways to achieve this:Use the printer's configuration switches or control
panel to alter its interpretation of these characters.
Check your printer's manual to find out how to do
this.If you boot your system into other operating
systems besides FreeBSD, you may have to
reconfigure the printer to use a
an interpretation for CR and LF characters that those
other operating systems use. You might prefer one of
the other solutions, below.Have FreeBSD's serial line driver automatically
convert LF to CR+LF. Of course, this works with
printers on serial ports only. To
enable this feature, set the CRMOD bit in
fs capability in the
/etc/printcap file for the
printer.Send an escape code to the
printer to have it temporarily treat LF characters
differently. Consult your printer's manual for escape
codes that your printer might support. When you find
the proper escape code, modify the text filter to send
the code first, then send the print job.Here is an example text filter for printers that
understand the Hewlett-Packard PCL escape codes. This
filter makes the printer treat LF characters as a LF and
CR; then it sends the job; then it sends a form feed to
eject the last page of the job. It should work with
nearly all Hewlett Packard printers.
#!/bin/sh
#
# hpif - Simple text input filter for lpd for HP-PCL based printers
# Installed in /usr/local/libexec/hpif
#
# Simply copies stdin to stdout. Ignores all filter arguments.
# Tells printer to treat LF as CR+LF. Ejects the page when done.
printf "\033&k2G" && cat && printf "\033&l0H" && exit 0
exit 2Here is an example
/etc/printcap from a host called
orchid. It has a single printer attached to its first
parallel port, a Hewlett Packard LaserJet 3Si named
teak. It is using the above script as
its text filter:
#
# /etc/printcap for host orchid
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/hpif:It overprinted each line.The printer never advanced a line. All of the lines of
text were printed on top of each other on one line.This problem is the “opposite” of the
staircase effect, described above, and is much rarer.
Somewhere, the LF characters that FreeBSD uses to end a line
are being treated as CR characters to return the print
location to the left edge of the paper, but not also down a
line.Use the printer's configuration switches or control
panel to enforce the following interpretation of LF and CR
characters:Printer receivesPrinter printsCRCRLFCR + LFThe printer lost characters.While printing, the printer did not print a few
characters in each line. The problem might have gotten
worse as the printer ran, losing more and more
characters.The problem is that the printer cannot keep up with the
speed at which the computer sends data over a serial line.
(This problem should not occur with printers on parallel
ports.) There are two ways to overcome the problem:If the printer supports XON/XOFF flow control, have
FreeBSD use it by specifying the TANDEM bit in the
fs capability.If the printer supports carrier flow control,
specify the MDMBUF bit in the fs
capability. Make sure the cable connecting the printer
to the computer is correctly wired for carrier flow
control.If the printer does not support any flow control,
use some combination of the NLDELAY, TBDELAY, CRDELAY,
VTDELAY, and BSDELAY bits in the fs
capability to add appropriate delays to the stream of
data sent to the printer.It printed garbage.The printer printed what appeared to be random garbage,
but not the desired text.This is usually another symptom of incorrect
communications parameters with a serial printer.
Double-check the bps rate in the br
capability, and the parity bits in the fs
and fc capabilities; make sure the
printer is using the same settings as specified in the
/etc/printcap file.Nothing happened.If nothing happened, the problem is probably within
FreeBSD and not the hardware. Add the log file
(lf) capability to the entry for the
printer you are debugging in the
/etc/printcap file. For example, here
is the entry for rattan, with the
lf capability:
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:\
:lf=/var/log/rattan.logThen, try printing again. Check the log file (in our
example, /var/log/rattan.log) to see
any error messages that might appear. Based on the messages
you see, try to correct the problem.If you do not specify a lf
capability, LPD uses /dev/console as a
default.Using PrintersThis section tells you how to use printers you have setup with
FreeBSD. Here is an overview of the user-level commands:&man.lpr.1;Print jobs&man.lpq.1;Check printer queues&man.lprm.1;Remove jobs from a printer's queueThere is also an administrative command, &man.lpc.8;, described in
the section Administrating the LPD
Spooler, used to control printers and their queues.All three of the commands &man.lpr.1;, &man.lprm.1;, and &man.lpq.1;
accept an option to specify on which
printer/queue to operate, as listed in the
/etc/printcap file. This enables you to submit,
remove, and check on jobs for various printers. If you do not use the
option, then these commands use the printer
specified in the PRINTER environment variable. Finally,
if you do not have a PRINTER environment variable, these
commands default to the printer named lp.Hereafter, the terminology default printer
means the printer named in the PRINTER environment
variable, or the printer named lp when there is no
PRINTER environment variable.Printing JobsTo print files, type:&prompt.user; lpr filename...This prints each of the listed files to the default printer. If
you list no files, &man.lpr.1; reads data to
print from standard input. For example, this command prints some
important system files:&prompt.user; lpr /etc/host.conf /etc/hosts.equivTo select a specific printer, type:&prompt.user; lpr -P printer-namefilename...This example prints a long listing of the current directory to the
printer named rattan:&prompt.user; ls -l | lpr -P rattanBecause no files were listed for the
&man.lpr.1; command, lpr read the data to print
from standard input, which was the output of the ls
-l command.The &man.lpr.1; command can also accept a wide variety of options
to control formatting, apply file conversions, generate multiple
copies, and so forth. For more information, see the section Printing Options.Checking JobsWhen you print with &man.lpr.1;, the data you wish to print is put
together in a package called a “print job”, which is sent
to the LPD spooling system. Each printer has a queue of jobs, and
your job waits in that queue along with other jobs from yourself and
from other users. The printer prints those jobs in a first-come,
first-served order.To display the queue for the default printer, type &man.lpq.1;.
For a specific printer, use the option. For
example, the command
&prompt.user; lpq -P bamboo
shows the queue for the printer named bamboo. Here
is an example of the output of the lpq
command:bamboo is ready and printing
Rank Owner Job Files Total Size
active kelly 9 /etc/host.conf, /etc/hosts.equiv 88 bytes
2nd kelly 10 (standard input) 1635 bytes
3rd mary 11 ... 78519 bytesThis shows three jobs in the queue for bamboo.
The first job, submitted by user kelly, got assigned “job
number” 9. Every job for a printer gets a unique job number.
Most of the time you can ignore the job number, but you will need it
if you want to cancel the job; see section Removing Jobs for details.Job number nine consists of two files; multiple files given on the
&man.lpr.1; command line are treated as part of a single job. It
is the currently active job (note the word active
under the “Rank” column), which means the printer should
be currently printing that job. The second job consists of data
passed as the standard input to the &man.lpr.1; command. The third
job came from user mary; it is a much larger
job. The pathname of the files she's trying to print is too long to
fit, so the &man.lpq.1; command just shows three dots.The very first line of the output from &man.lpq.1; is also useful:
it tells what the printer is currently doing (or at least what LPD
thinks the printer is doing).The &man.lpq.1; command also support a option
to generate a detailed long listing. Here is an example of
lpq -l:waiting for bamboo to become ready (offline ?)
kelly: 1st [job 009rose]
/etc/host.conf 73 bytes
/etc/hosts.equiv 15 bytes
kelly: 2nd [job 010rose]
(standard input) 1635 bytes
mary: 3rd [job 011rose]
/home/orchid/mary/research/venus/alpha-regio/mapping 78519 bytesRemoving JobsIf you change your mind about printing a job, you can remove the
job from the queue with the &man.lprm.1; command. Often, you can
even use &man.lprm.1; to remove an active job, but some or all of the
job might still get printed.To remove a job from the default printer, first use
&man.lpq.1; to find the job number. Then type:&prompt.user; lprm job-numberTo remove the job from a specific printer, add the
option. The following command removes job number
10 from the queue for the printer bamboo:&prompt.user; lprm -P bamboo 10The &man.lprm.1; command has a few shortcuts:lprm -Removes all jobs (for the default printer) belonging to
you.lprm userRemoves all jobs (for the default printer) belonging to
user. The superuser can remove other
users' jobs; you can remove only your own jobs.lprmWith no job number, user name, or
appearing on the command line,
&man.lprm.1; removes the currently active job on the
default printer, if it belongs to you. The superuser can remove
any active job.Just use the option with the above shortcuts
to operate on a specific printer instead of the default. For example,
the following command removes all jobs for the current user in the
queue for the printer named rattan:&prompt.user; lprm -P rattan -If you are working in a networked environment, &man.lprm.1; will
let you remove jobs only from the
host from which the jobs were submitted, even if the same printer is
available from other hosts. The following command sequence
demonstrates this:&prompt.user; lpr -P rattan myfile
&prompt.user; rlogin orchid
&prompt.user; lpq -P rattan
Rank Owner Job Files Total Size
active seeyan 12 ... 49123 bytes
2nd kelly 13 myfile 12 bytes
&prompt.user; lprm -P rattan 13
rose: Permission denied
&prompt.user; logout
&prompt.user; lprm -P rattan 13
dfA013rose dequeued
cfA013rose dequeued
Beyond Plain Text: Printing OptionsThe &man.lpr.1; command supports a number of options that control
formatting text, converting graphic and other file formats, producing
multiple copies, handling of the job, and more. This section
describes the options.Formatting and Conversion OptionsThe following &man.lpr.1; options control formatting of the
files in the job. Use these options if the job does not contain
plain text or if you want plain text formatted through the
&man.pr.1; utility.For example, the following command prints a DVI file (from the
TeX typesetting system) named fish-report.dvi
to the printer named bamboo:&prompt.user; lpr -P bamboo -d fish-report.dviThese options apply to every file in the job, so you cannot mix
(say) DVI and ditroff files together in a job. Instead, submit the
files as separate jobs, using a different conversion option for each
job.All of these options except and
require conversion filters installed for the
destination printer. For example, the option
requires the DVI conversion filter. Section Conversion
Filters gives details.Print cifplot files.Print DVI files.Print FORTRAN text files.Print plot data.Indent the output by number
columns; if you omit number, indent
by 8 columns. This option works only with certain conversion
filters.Do not put any space between the and
the number.Print literal text data, including control
characters.Print ditroff (device independent troff) data.-pFormat plain text with &man.pr.1; before printing. See
&man.pr.1; for more information.Use title on the
&man.pr.1; header instead of the file name. This option has
effect only when used with the
option.Print troff data.Print raster data.Here is an example: this command prints a nicely formatted
version of the &man.ls.1; manual page on the default printer:&prompt.user; zcat /usr/share/man/man1/ls.1.gz | troff -t -man | lpr -tThe &man.zcat.1; command uncompresses the source of the&man.ls.1; manual page and passes it to the &man.troff.1;
command, which formats that source and makes GNU troff output and
passes it to &man.lpr.1;, which submits the job to the LPD spooler.
Because we used the option to&man.lpr.1;, the spooler will convert the GNU troff output into
a format the default printer can understand when it prints the
job.Job Handling OptionsThe following options to &man.lpr.1; tell LPD to handle the job
specially:-# copiesProduce a number of copies of
each file in the job instead of just one copy. An
administrator may disable this option to reduce printer
wear-and-tear and encourage photocopier usage. See section
Restricting
Multiple Copies.This example prints three copies of
parser.c followed by three copies of
parser.h to the default printer:&prompt.user; lpr -#3 parser.c parser.h-mSend mail after completing the print job. With this
option, the LPD system will send mail to your account when it
finishes handling your job. In its message, it will tell you
if the job completed successfully or if there was an error,
and (often) what the error was.-sDo not copy the files to the spooling directory, but make
symbolic links to them instead.If you are printing a large job, you probably want to use
this option. It saves space in the spooling directory (your
job might overflow the free space on the filesystem where the
spooling directory resides). It saves time as well since LPD
will not have to copy each and every byte of your job to the
spooling directory.There is a drawback, though: since LPD will refer to the
original files directly, you cannot modify or remove them
until they have been printed.If you are printing to a remote printer, LPD will
eventually have to copy files from the local host to the
remote host, so the option will save
space only on the local spooling directory, not the remote.
It is still useful, though.-rRemove the files in the job after copying them to the
spooling directory, or after printing them with the
option. Be careful with this
option!Header Page OptionsThese options to &man.lpr.1; adjust the text that normally
appears on a job's header page. If header pages are suppressed for
the destination printer, these options have no effect. See section
Header Pages
for information about setting up header pages.-C textReplace the hostname on the header page with
text. The hostname is normally the
name of the host from which the job was submitted.-J textReplace the job name on the header page with
text. The job name is normally the
name of the first file of the job, or
stdin if you are printing standard
input.-hDo not print any header page.At some sites, this option may have no effect due to the
way header pages are generated. See Header
Pages for details.Administrating PrintersAs an administrator for your printers, you have had to install,
set up, and test them. Using the &man.lpc.8; command, you
can interact with your printers in yet more ways. With &man.lpc.8;,
you canStart and stop the printersEnable and disable their queuesRearrange the order of the jobs in each queue.First, a note about terminology: if a printer is
stopped, it will not print anything in its queue.
Users can still submit jobs, which will wait in the queue until the
printer is started or the queue is
cleared.If a queue is disabled, no user (except root)
can submit jobs for the printer. An enabled
queue allows jobs to be submitted. A printer can be
started for a disabled queue, in which case it
will continue to print jobs in the queue until the queue is
empty.In general, you have to have root privileges to use the
&man.lpc.8; command. Ordinary users can use the &man.lpc.8; command
to get printer status and to restart a hung printer only.Here is a summary of the &man.lpc.8; commands. Most of the
commands takes a printer-name argument to
tell on which printer to operate. You can use all
for the printer-name to mean all printers
listed in /etc/printcap.abort
printer-nameCancel the current job and stop the printer. Users can
still submit jobs if the queue's enabled.clean
printer-nameRemove old files from the printer's spooling directory.
Occasionally, the files that make up a job are not properly
removed by LPD, particularly if there have been errors during
printing or a lot of administrative activity. This command
finds files that do not belong in the spooling directory and
removes them.disable
printer-nameDisable queuing of new jobs. If the printer's started, it
will continue to print any jobs remaining in the queue. The
superuser (root) can always submit jobs, even to a disabled
queue.This command is useful while you are testing a new printer
or filter installation: disable the queue and submit jobs as
root. Other users will not be able to submit jobs until you
complete your testing and re-enable the queue with the
enable command.down printer-namemessageTake a printer down. Equivalent to
disable followed by stop.
The message appears as the printer's
status whenever a user checks the printer's queue with
&man.lpq.1; or status with lpc
status.enable
printer-nameEnable the queue for a printer. Users can submit jobs but
the printer will not print anything until it is started.help
command-namePrint help on the command
command-name. With no
command-name, print a summary of the
commands available.restart
printer-nameStart the printer. Ordinary users can use this command if
some extraordinary circumstance hangs LPD, but they cannot start
a printer stopped with either the stop or
down commands. The
restart command is equivalent to
abort followed by
start.start
printer-nameStart the printer. The printer will print jobs in its
queue.stop
printer-nameStop the printer. The printer will finish the current job
and will not print anything else in its queue. Even though the
printer is stopped, users can still submit jobs to an enabled
queue.topq printer-namejob-or-usernameRearrange the queue for
printer-name by placing the jobs with
the listed job numbers or the jobs
belonging to username at the top of
the queue. For this command, you cannot use
all as the
printer-name.up
printer-nameBring a printer up; the opposite of the
down command. Equivalent to
start followed by
enable.&man.lpc.8; accepts the above commands on the command line. If
you do not enter any commands, &man.lpc.8; enters an interactive mode,
where you can enter commands until you type exit,
quit, or end-of-file.Advanced Printer SetupThis section describes filters for printing specially formatted
files, header pages, printing across networks, and restricting and
accounting for printer usage.FiltersAlthough LPD handles network protocols, queuing, access control,
and other aspects of printing, most of the real
work happens in the filters. Filters are
programs that communicate with the printer and handle its device
dependencies and special requirements. In the simple printer setup,
we installed a plain text filter—an extremely simple one that
should work with most printers (section Installing the Text
Filter).However, in order to take advantage of format conversion, printer
accounting, specific printer quirks, and so on, you should understand
how filters work. It will ultimately be the filter's responsibility
to handle these aspects. And the bad news is that most of the time
you have to provide filters yourself. The good
news is that many are generally available; when they are not, they are
usually easy to write.Also, FreeBSD comes with one,
/usr/libexec/lpr/lpf, that works with many
printers that can print plain text. (It handles backspacing and tabs
in the file, and does accounting, but that is about all it does.)
There are also several filters and filter components in the FreeBSD
ports collection.Here is what you will find in this section:Section How Filters
Work, tries to give an overview of a filter's role in the
printing process. You should read this section to get an
understanding of what is happening “under the hood”
when LPD uses filters. This knowledge could help you anticipate
and debug problems you might encounter as you install more and
more filters on each of your printers.LPD expects every printer to be able to print plain text by
default. This presents a problem for PostScript (or other
language-based printers) which cannot directly print plain text.
Section Accommodating
Plain Text Jobs on PostScript Printers tells you what you
should do to overcome this problem. I recommend reading this
section if you have a PostScript printer.PostScript is a popular output format for many programs. Even
some people (myself included) write PostScript code directly. But
PostScript printers are expensive. Section Simulating PostScript on
Non-PostScript Printers tells how you can further modify
a printer's text filter to accept and print PostScript data on a
non-PostScript printer. I recommend reading
this section if you do not have a PostScript printer.Section Conversion
Filters tells about a way you can automate the conversion
of specific file formats, such as graphic or typesetting data,
into formats your printer can understand. After reading this
section, you should be able to set up your printers such that
users can type lpr -t to print troff data, or
lpr -d to print TeX DVI data, or lpr
-v to print raster image data, and so forth. I
recommend reading this section.Section Output
Filters tells all about a not often used feature of LPD:
output filters. Unless you are printing header pages (see Header Pages),
you can probably skip that section altogether.Section lpf: a Text
Filter describes lpf, a fairly
complete if simple text filter for line printers (and laser
printers that act like line printers) that comes with FreeBSD. If
you need a quick way to get printer accounting working for plain
text, or if you have a printer which emits smoke when it sees
backspace characters, you should definitely consider
lpf.How Filters WorkAs mentioned before, a filter is an executable program started
by LPD to handle the device-dependent part of communicating with the
printer.When LPD wants to print a file in a job, it starts a filter
program. It sets the filter's standard input to the file to print,
its standard output to the printer, and its standard error to the
error logging file (specified in the lf
capability in /etc/printcap, or
/dev/console by default).Which filter LPD starts and the filter's arguments depend on
what is listed in the /etc/printcap file and
what arguments the user specified for the job on the
&man.lpr.1; command line. For example, if the user typed
lpr -t, LPD would start the troff filter, listed
in the tf capability for the destination printer.
If the user wanted to print plain text, it would start the
if filter (this is mostly true: see Output Filters for
details).There are three kinds of filters you can specify in
/etc/printcap:The text filter, confusingly called the
input filter in LPD documentation, handles
regular text printing. Think of it as the default filter. LPD
expects every printer to be able to print plain text by default,
and it is the text filter's job to make sure backspaces, tabs,
or other special characters do not confuse the printer. If you
are in an environment where you have to account for printer
usage, the text filter must also account for pages printed,
usually by counting the number of lines printed and comparing
that to the number of lines per page the printer supports. The
text filter is started with the following argument list:
filter-name-c-wwidth-llength-iindent-n login-h hostacct-file
where
appears if the job's submitted with lpr
-lwidthis the value from the pw (page
width) capability specified in
/etc/printcap, default 132lengthis the value from the pl (page
length) capability, default 66indentis the amount of the indentation from lpr
-i, default 0loginis the account name of the user printing the
filehostis the host name from which the job was
submittedacct-fileis the name of the accounting file from the
af capability.A conversion filter converts a specific
file format into one the printer can render onto paper. For
example, ditroff typesetting data cannot be directly printed,
but you can install a conversion filter for ditroff files to
convert the ditroff data into a form the printer can digest and
print. Section Conversion
Filters tells all about them. Conversion filters also
need to do accounting, if you need printer accounting.
Conversion filters are started with the following arguments:
filter-name-xpixel-width-ypixel-height-n login-h hostacct-file
where pixel-width is the value
from the px capability (default 0) and
pixel-height is the value from the
py capability (default 0).The output filter is used only if there
is no text filter, or if header pages are enabled. In my
experience, output filters are rarely used. Section Output Filters describe
them. There are only two arguments to an output filter:
filter-name-wwidth-llength
which are identical to the text filters and
arguments.Filters should also exit with the
following exit status:exit 0If the filter printed the file successfully.exit 1If the filter failed to print the file but wants LPD to
try to print the file again. LPD will restart a filter if it
exits with this status.exit 2If the filter failed to print the file and does not want
LPD to try again. LPD will throw out the file.The text filter that comes with the FreeBSD release,
/usr/libexec/lpr/lpf, takes advantage of the
page width and length arguments to determine when to send a form
feed and how to account for printer usage. It uses the login, host,
and accounting file arguments to make the accounting entries.If you are shopping for filters, see if they are LPD-compatible.
If they are, they must support the argument lists described above.
If you plan on writing filters for general use, then have them
support the same argument lists and exit codes.Accommodating Plain Text Jobs on PostScript PrintersIf you are the only user of your computer and PostScript (or
other language-based) printer, and you promise to never send plain
text to your printer and to never use features of various programs
that will want to send plain text to your printer, then you do not
need to worry about this section at all.But, if you would like to send both PostScript and plain text
jobs to the printer, then you are urged to augment your printer
setup. To do so, we have the text filter detect if the arriving job
is plain text or PostScript. All PostScript jobs must start with
%! (for other printer languages, see your printer
documentation). If those are the first two characters in the job,
we have PostScript, and can pass the rest of the job directly. If
those are not the first two characters in the file, then the filter
will convert the text into PostScript and print the result.How do we do this?If you have got a serial printer, a great way to do it is to
install lprps. lprps is a
PostScript printer filter which performs two-way communication with
the printer. It updates the printer's status file with verbose
information from the printer, so users and administrators can see
exactly what the state of the printer is (such as toner
low or paper jam). But more
importantly, it includes a program called psif
which detects whether the incoming job is plain text and calls
textps (another program that comes with
lprps) to convert it to PostScript. It then uses
lprps to send the job to the printer.lprps is part of the FreeBSD ports collection
(see The Ports Collection). You can
fetch, build and install it yourself, of course. After installing
lprps, just specify the pathname to the
psif program that is part of
lprps. If you installed lprps
from the ports collection, use the following in the serial
PostScript printer's entry in
/etc/printcap:
:if=/usr/local/libexec/psif:You should also specify the rw capability;
that tells LPD to open the printer in read-write mode.If you have a parallel PostScript printer (and therefore cannot
use two-way communication with the printer, which
lprps needs), you can use the following shell
script as the text filter:
#!/bin/sh
#
# psif - Print PostScript or plain text on a PostScript printer
# Script version; NOT the version that comes with lprps
# Installed in /usr/local/libexec/psif
#
read first_line
first_two_chars=`expr "$first_line" : '\(..\)'`
if [ "$first_two_chars" = "%!" ]; then
#
# PostScript job, print it.
#
echo "$first_line" && cat && printf "\004" && exit 0
exit 2
else
#
# Plain text, convert it, then print it.
#
( echo "$first_line"; cat ) | /usr/local/bin/textps && printf "\004" && exit 0
exit 2
fiIn the above script, textps is a program we
installed separately to convert plain text to PostScript. You can
use any text-to-PostScript program you wish. The FreeBSD ports
collection (see The Ports Collection)
includes a full featured text-to-PostScript program called
a2ps that you might want to investigate.Simulating PostScript on Non-PostScript PrintersPostScript is the de facto standard for
high quality typesetting and printing. PostScript is, however, an
expensive standard. Thankfully, Alladin
Enterprises has a free PostScript work-alike called
Ghostscript that runs with FreeBSD.
Ghostscript can read most PostScript files and can render their
pages onto a variety of devices, including many brands of
non-PostScript printers. By installing Ghostscript and using a
special text filter for your printer, you can make your
non-PostScript printer act like a real PostScript printer.Ghostscript should be in the FreeBSD ports collection, if you
would like to install it from there. You can fetch, build, and
install it quite easily yourself, as well.To simulate PostScript, we have the text filter detect if it is
printing a PostScript file. If it is not, then the filter will pass
the file directly to the printer; otherwise, it will use Ghostscript
to first convert the file into a format the printer will
understand.Here is an example: the following script is a text filter
for Hewlett Packard DeskJet 500 printers. For other printers,
substitute the argument to the
gs (Ghostscript) command. (Type gs
-h to get a list of devices the current installation of
Ghostscript supports.)
#!/bin/sh
#
# ifhp - Print Ghostscript-simulated PostScript on a DeskJet 500
# Installed in /usr/local/libexec/hpif
#
# Treat LF as CR+LF:
#
printf "\033&k2G" || exit 2
#
# Read first two characters of the file
#
read first_line
first_two_chars=`expr "$first_line" : '\(..\)'`
if [ "$first_two_chars" = "%!" ]; then
#
# It is PostScript; use Ghostscript to scan-convert and print it.
#
# Note that PostScript files are actually interpreted programs,
# and those programs are allowed to write to stdout, which will
# mess up the printed output. So, we redirect stdout to stderr
# and then make descriptor 3 go to stdout, and have Ghostscript
# write its output there. Exercise for the clever reader:
# capture the stderr output from Ghostscript and mail it back to
# the user originating the print job.
#
exec 3>&1 1>&2
/usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 \
-sOutputFile=/dev/fd/3 - && exit 0
#
/usr/local/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=djet500 -sOutputFile=- - \
&& exit 0
else
#
# Plain text or HP/PCL, so just print it directly; print a form
# at the end to eject the last page.
#
echo $first_line && cat && printf "\033&l0H" && exit 0
fi
exit 2Finally, you need to notify LPD of the filter via the
if capability:
:if=/usr/local/libexec/hpif:That is it. You can type lpr plain.text and
lpr whatever.ps and both should print
successfully.Conversion FiltersAfter completing the simple setup described in Simple Printer Setup, the first
thing you will probably want to do is install conversion filters for
your favorite file formats (besides plain ASCII text).Why Install Conversion Filters?Conversion filters make printing various kinds of files easy.
As an example, suppose we do a lot of work with the TeX
typesetting system, and we have a PostScript printer. Every time
we generate a DVI file from TeX, we cannot print it directly until
we convert the DVI file into PostScript. The command sequence
goes like this:&prompt.user; dvips seaweed-analysis.dvi
&prompt.user; lpr seaweed-analysis.psBy installing a conversion filter for DVI files, we can skip
the hand conversion step each time by having LPD do it for us.
Now, each time we get a DVI file, we are just one step away from
printing it:&prompt.user; lpr -d seaweed-analysis.dviWe got LPD to do the DVI file conversion for us by specifying
the option. Section Formatting and Conversion
Options lists the conversion options.For each of the conversion options you want a printer to
support, install a conversion filter and
specify its pathname in /etc/printcap. A
conversion filter is like the text filter for the simple printer
setup (see section Installing
the Text Filter) except that instead of printing plain
text, the filter converts the file into a format the printer can
understand.Which Conversions Filters Should I Install?You should install the conversion filters you expect to use.
If you print a lot of DVI data, then a DVI conversion filter is in
order. If you have got plenty of troff to print out, then you
probably want a troff filter.The following table summarizes the filters that LPD works
with, their capability entries for the
/etc/printcap file, and how to invoke them
with the lpr command:File type/etc/printcap capabilitylpr optioncifplotcfDVIdfplotgfditroffnfFORTRAN textrftroffrfrastervfplain textifnone, , or
In our example, using lpr -d means the
printer needs a df capability in its entry in
/etc/printcap.Despite what others might contend, formats like FORTRAN text
and plot are probably obsolete. At your site, you can give new
meanings to these or any of the formatting options just by
installing custom filters. For example, suppose you would like to
directly print Printerleaf files (files from the Interleaf desktop
publishing program), but will never print plot files. You could
install a Printerleaf conversion filter under the
gf capability and then educate your users that
lpr -g mean “print Printerleaf
files.”Installing Conversion FiltersSince conversion filters are programs you install outside of
the base FreeBSD installation, they should probably go under
/usr/local. The directory
/usr/local/libexec is a popular location,
since they are specialized programs that only LPD will run;
regular users should not ever need to run them.To enable a conversion filter, specify its pathname under the
appropriate capability for the destination printer in
/etc/printcap.In our example, we will add the DVI conversion filter to the
entry for the printer named bamboo. Here is
the example /etc/printcap file again, with
the new df capability for the printer
bamboo.
#
# /etc/printcap for host rose - added df filter for bamboo
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:The DVI filter is a shell script named
/usr/local/libexec/psdf. Here is that
script:
#!bin/sh
#
# psdf - DVI to PostScript printer filter
# Installed in /usr/local/libexec/psdf
#
# Invoked by lpd when user runs lpr -d
#
exec /usr/local/bin/dvips -f | /usr/local/libexec/lprps "$@"This script runs dvips in filter mode (the
argument) on standard input, which is the job
to print. It then starts the PostScript printer filter
lprps (see section Accommodating Plain
Text Jobs on PostScript Printers) with the arguments LPD
passed to this script. lprps will use those
arguments to account for the pages printed.More Conversion Filter ExamplesSince there is no fixed set of steps to install conversion
filters, let me instead provide more examples. Use these as
guidance to making your own filters. Use them directly, if
appropriate.This example script is a raster (well, GIF file, actually)
conversion filter for a Hewlett Packard LaserJet III-Si
printer:
#!/bin/sh
#
# hpvf - Convert GIF files into HP/PCL, then print
# Installed in /usr/local/libexec/hpvf
PATH=/usr/X11R6/bin:$PATH; export PATH
giftopnm | ppmtopgm | pgmtopbm | pbmtolj -resolution 300 \
&& exit 0 \
|| exit 2It works by converting the GIF file into a portable anymap,
converting that into a portable graymap, converting that into a
portable bitmap, and converting that into LaserJet/PCL-compatible
data.Here is the /etc/printcap file with an
entry for a printer using the above filter:
#
# /etc/printcap for host orchid
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sh:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/hpif:\
:vf=/usr/local/libexec/hpvf:The following script is a conversion filter for troff data
from the groff typesetting system for the PostScript printer named
bamboo:
#!/bin/sh
#
# pstf - Convert groff's troff data into PS, then print.
# Installed in /usr/local/libexec/pstf
#
exec grops | /usr/local/libexec/lprps "$@"The above script makes use of lprps again
to handle the communication with the printer. If the printer were
on a parallel port, we would use this script instead:
#!/bin/sh
#
# pstf - Convert groff's troff data into PS, then print.
# Installed in /usr/local/libexec/pstf
#
exec gropsThat is it. Here is the entry we need to add to
/etc/printcap to enable the filter:
:tf=/usr/local/libexec/pstf:Here is an example that might make old hands at FORTRAN blush.
It is a FORTRAN-text filter for any printer that can directly
print plain text. We will install it for the printer
teak:
#!/bin/sh
#
# hprf - FORTRAN text filter for LaserJet 3si:
# Installed in /usr/local/libexec/hprf
#
printf "\033&k2G" && fpr && printf "\033&l0H" && exit 0
exit 2And we will add this line to the
/etc/printcap for the printer
teak to enable this filter:
:rf=/usr/local/libexec/hprf:Here is one final, somewhat complex example. We will add a
DVI filter to the LaserJet printer teak
introduced earlier. First, the easy part: updating
/etc/printcap with the location of the DVI
filter:
:df=/usr/local/libexec/hpdf:Now, for the hard part: making the filter. For that, we need
a DVI-to-LaserJet/PCL conversion program. The FreeBSD ports
collection (see The Ports Collection)
has one: dvi2xx is the name of the package.
Installing this package gives us the program we need,
dvilj2p, which converts DVI into LaserJet IIp,
LaserJet III, and LaserJet 2000 compatible codes.dvilj2p makes the filter
hpdf quite complex since
dvilj2p cannot read from standard input. It
wants to work with a filename. What is worse, the filename has to
end in .dvi so using
/dev/fd/0 for standard input is problematic.
We can get around that problem by linking (symbolically) a
temporary file name (one that ends in .dvi)
to /dev/fd/0, thereby forcing
dvilj2p to read from standard input.The only other fly in the ointment is the fact that we cannot
use /tmp for the temporary link. Symbolic
links are owned by user and group bin. The
filter runs as user daemon. And the
/tmp directory has the sticky bit set. The
filter can create the link, but it will not be able clean up when
done and remove it since the link will belong to a different
user.Instead, the filter will make the symbolic link in the current
working directory, which is the spooling directory (specified by
the sd capability in
/etc/printcap). This is a perfect place for
filters to do their work, especially since there is (sometimes)
more free disk space in the spooling directory than under
/tmp.Here, finally, is the filter:
#!/bin/sh
#
# hpdf - Print DVI data on HP/PCL printer
# Installed in /usr/local/libexec/hpdf
PATH=/usr/local/bin:$PATH; export PATH
#
# Define a function to clean up our temporary files. These exist
# in the current directory, which will be the spooling directory
# for the printer.
#
cleanup() {
rm -f hpdf$$.dvi
}
#
# Define a function to handle fatal errors: print the given message
# and exit 2. Exiting with 2 tells LPD to do not try to reprint the
# job.
#
fatal() {
echo "$@" 1>&2
cleanup
exit 2
}
#
# If user removes the job, LPD will send SIGINT, so trap SIGINT
# (and a few other signals) to clean up after ourselves.
#
trap cleanup 1 2 15
#
# Make sure we are not colliding with any existing files.
#
cleanup
#
# Link the DVI input file to standard input (the file to print).
#
ln -s /dev/fd/0 hpdf$$.dvi || fatal "Cannot symlink /dev/fd/0"
#
# Make LF = CR+LF
#
printf "\033&k2G" || fatal "Cannot initialize printer"
#
# Convert and print. Return value from dvilj2p does not seem to be
# reliable, so we ignore it.
#
dvilj2p -M1 -q -e- dfhp$$.dvi
#
# Clean up and exit
#
cleanup
exit 0Automated Conversion: An Alternative To Conversion
FiltersAll these conversion filters accomplish a lot for your
printing environment, but at the cost forcing the user to specify
(on the &man.lpr.1; command line) which one to use.
If your users are not particularly computer literate, having to
specify a filter option will become annoying. What is worse,
though, is that an incorrectly specified filter option may run a
filter on the wrong type of file and cause your printer to spew
out hundreds of sheets of paper.Rather than install conversion filters at all, you might want
to try having the text filter (since it is the default filter)
detect the type of file it has been asked to print and then
automatically run the right conversion filter. Tools such as
file can be of help here. Of course, it will
be hard to determine the differences between
some file types—and, of course, you can
still provide conversion filters just for them.The FreeBSD ports collection has a text filter that performs
automatic conversion called apsfilter. It can
detect plain text, PostScript, and DVI files, run the proper
conversions, and print.Output FiltersThe LPD spooling system supports one other type of filter that
we have not yet explored: an output filter. An output filter is
intended for printing plain text only, like the text filter, but
with many simplifications. If you are using an output filter but no
text filter, then:LPD starts an output filter once for the entire job instead
of once for each file in the job.LPD does not make any provision to identify the start or the
end of files within the job for the output filter.LPD does not pass the user's login or host to the filter, so
it is not intended to do accounting. In fact, it gets only two
arguments:filter-name-wwidth-llengthWhere width is from the
pw capability and
length is from the
pl capability for the printer in
question.Do not be seduced by an output filter's simplicity. If you
would like each file in a job to start on a different page an output
filter will not work. Use a text filter (also
known as an input filter); see section Installing the Text Filter.
Furthermore, an output filter is actually more
complex in that it has to examine the byte stream being
sent to it for special flag characters and must send signals to
itself on behalf of LPD.However, an output filter is necessary if
you want header pages and need to send escape sequences or other
initialization strings to be able to print the header page. (But it
is also futile if you want to charge header
pages to the requesting user's account, since LPD does not give any
user or host information to the output filter.)On a single printer, LPD allows both an output filter and text
or other filters. In such cases, LPD will start the output filter
to print the header page (see section Header Pages)
only. LPD then expects the output filter to stop
itself by sending two bytes to the filter: ASCII 031
followed by ASCII 001. When an output filter sees these two bytes
(031, 001), it should stop by sending SIGSTOP to itself. When LPD's
done running other filters, it will restart the output filter by
sending SIGCONT to it.If there is an output filter but no text
filter and LPD is working on a plain text job, LPD uses the output
filter to do the job. As stated before, the output filter will
print each file of the job in sequence with no intervening form
feeds or other paper advancement, and this is probably
not what you want. In almost all cases, you
need a text filter.The program lpf, which we introduced earlier
as a text filter, can also run as an output filter. If you need a
quick-and-dirty output filter but do not want to write the byte
detection and signal sending code, try lpf. You
can also wrap lpf in a shell script to handle any
initialization codes the printer might require.lpf: a Text FilterThe program /usr/libexec/lpr/lpf that comes
with FreeBSD binary distribution is a text filter (input filter)
that can indent output (job submitted with lpr
-i), allow literal characters to pass (job submitted
with lpr -l), adjust the printing position for
backspaces and tabs in the job, and account for pages printed. It
can also act like an output filter.lpf is suitable for many printing
environments. And although it has no capability to send
initialization sequences to a printer, it is easy to write a shell
script to do the needed initialization and then execute
lpf.In order for lpf to do page accounting
correctly, it needs correct values filled in for the
pw and pl capabilities in the
/etc/printcap file. It uses these values to
determine how much text can fit on a page and how many pages were in
a user's job. For more information on printer accounting, see Accounting for Printer
Usage.Header PagesIf you have lots of users, all of them using
various printers, then you probably want to consider header
pages as a necessary evil.Header pages, also known as banner or
burst pages identify to whom jobs belong after
they are printed. They are usually printed in large, bold letters,
perhaps with decorative borders, so that in a stack of printouts they
stand out from the real documents that comprise users' jobs. They
enable users to locate their jobs quickly. The obvious drawback to a
header page is that it is yet one more sheet that has to be printed
for every job, their ephemeral usefulness lasting not more than a few
minutes, ultimately finding themselves in a recycling bin or rubbish
heap. (Note that header pages go with each job, not each file in a
job, so the paper waste might not be that bad.)The LPD system can provide header pages automatically for your
printouts if your printer can directly print
plain text. If you have a PostScript printer, you will need an
external program to generate the header page; see Header Pages on
PostScript Printers.Enabling Header PagesIn the Simple Printer
Setup, we turned off header pages by specifying
sh (meaning “suppress header”) in the
/etc/printcap file. To enable header pages for
a printer, just remove the sh capability.Sounds too easy, right?You are right. You might have to provide
an output filter to send initialization strings to the printer.
Here is an example output filter for Hewlett Packard PCL-compatible
printers:
#!/bin/sh
#
# hpof - Output filter for Hewlett Packard PCL-compatible printers
# Installed in /usr/local/libexec/hpof
printf "\033&k2G" || exit 2
exec /usr/libexec/lpr/lpfSpecify the path to the output filter in the
of capability. See Output Filters for more
information.Here is an example /etc/printcap file for
the printer teak that we introduced earlier; we
enabled header pages and added the above output filter:
#
# /etc/printcap for host orchid
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/hpif:\
:vf=/usr/local/libexec/hpvf:\
:of=/usr/local/libexec/hpof:Now, when users print jobs to teak, they get
a header page with each job. If users want to spend time searching
for their printouts, they can suppress header pages by submitting
the job with lpr -h; see Header Page Options for
more &man.lpr.1; options.LPD prints a form feed character after the header page. If
your printer uses a different character or sequence of characters
to eject a page, specify them with the ff
capability in /etc/printcap.Controlling Header PagesBy enabling header pages, LPD will produce a long
header, a full page of large letters identifying the
user, host, and job. Here is an example (kelly printed the job
named outline from host rose):
k ll ll
k l l
k l l
k k eeee l l y y
k k e e l l y y
k k eeeeee l l y y
kk k e l l y y
k k e e l l y yy
k k eeee lll lll yyy y
y
y y
yyyy
ll
t l i
t l
oooo u u ttttt l ii n nnn eeee
o o u u t l i nn n e e
o o u u t l i n n eeeeee
o o u u t l i n n e
o o u uu t t l i n n e e
oooo uuu u tt lll iii n n eeee
r rrr oooo ssss eeee
rr r o o s s e e
r o o ss eeeeee
r o o ss e
r o o s s e e
r oooo ssss eeee
Job: outline
Date: Sun Sep 17 11:04:58 1995LPD appends a form feed after this text so the job starts on a
new page (unless you have sf (suppress form
feeds) in the destination printer's entry in
/etc/printcap).If you prefer, LPD can make a short header;
specify sb (short banner) in the
/etc/printcap file. The header page will look
like this:
rose:kelly Job: outline Date: Sun Sep 17 11:07:51 1995Also by default, LPD prints the header page first, then the job.
To reverse that, specify hl (header last) in
/etc/printcap.Accounting for Header PagesUsing LPD's built-in header pages enforces a particular paradigm
when it comes to printer accounting: header pages must be
free of charge.Why?Because the output filter is the only external program that will
have control when the header page is printed that could do
accounting, and it is not provided with any user or
host information or an accounting file, so it has no
idea whom to charge for printer use. It is also not enough to just
“add one page” to the text filter or any of the
conversion filters (which do have user and host information) since
users can suppress header pages with lpr -h.
They could still be charged for header pages they did not print.
Basically, lpr -h will be the preferred option of
environmentally-minded users, but you cannot offer any incentive to
use it.It is still not enough to have each of the
filters generate their own header pages (thereby being able to
charge for them). If users wanted the option of suppressing the
header pages with lpr -h, they will still get
them and be charged for them since LPD does not pass any knowledge
of the option to any of the filters.So, what are your options?You can:Accept LPD's paradigm and make header pages free.Install an alternative to LPD, such as LPRng or PLP. Section
Alternatives to the
Standard Spooler tells more about other spooling
software you can substitute for LPD.Write a smart output filter. Normally,
an output filter is not meant to do anything more than
initialize a printer or do some simple character conversion. It
is suited for header pages and plain text jobs (when there is no
text (input) filter). But, if there is a text filter for the
plain text jobs, then LPD will start the output filter only for
the header pages. And the output filter can parse the header
page text that LPD generates to determine what user and host to
charge for the header page. The only other problem with this
method is that the output filter still does not know what
accounting file to use (it is not passed the name of the file
from the af capability), but if you have a
well-known accounting file, you can hard-code that into the
output filter. To facilitate the parsing step, use the
sh (short header) capability in
/etc/printcap. Then again, all that might
be too much trouble, and users will certainly appreciate the
more generous system administrator who makes header pages
free.Header Pages on PostScript PrintersAs described above, LPD can generate a plain text header page
suitable for many printers. Of course, PostScript cannot directly
print plain text, so the header page feature of LPD is
useless—or mostly so.One obvious way to get header pages is to have every conversion
filter and the text filter generate the header page. The filters
should should use the user and host arguments to generate a suitable
header page. The drawback of this method is that users will always
get a header page, even if they submit jobs with lpr
-h.Let us explore this method. The following script takes three
arguments (user login name, host name, and job name) and makes a
simple PostScript header page:
#!/bin/sh
#
# make-ps-header - make a PostScript header page on stdout
# Installed in /usr/local/libexec/make-ps-header
#
#
# These are PostScript units (72 to the inch). Modify for A4 or
# whatever size paper you are using:
#
page_width=612
page_height=792
border=72
#
# Check arguments
#
if [ $# -ne 3 ]; then
echo "Usage: `basename $0` <user> <host> <job>" 1>&2
exit 1
fi
#
# Save these, mostly for readability in the PostScript, below.
#
user=$1
host=$2
job=$3
date=`date`
#
# Send the PostScript code to stdout.
#
exec cat <<EOF
%!PS
%
% Make sure we do not interfere with user's job that will follow
%
save
%
% Make a thick, unpleasant border around the edge of the paper.
%
$border $border moveto
$page_width $border 2 mul sub 0 rlineto
0 $page_height $border 2 mul sub rlineto
currentscreen 3 -1 roll pop 100 3 1 roll setscreen
$border 2 mul $page_width sub 0 rlineto closepath
0.8 setgray 10 setlinewidth stroke 0 setgray
%
% Display user's login name, nice and large and prominent
%
/Helvetica-Bold findfont 64 scalefont setfont
$page_width ($user) stringwidth pop sub 2 div $page_height 200 sub moveto
($user) show
%
% Now show the boring particulars
%
/Helvetica findfont 14 scalefont setfont
/y 200 def
[ (Job:) (Host:) (Date:) ] {
200 y moveto show /y y 18 sub def }
forall
/Helvetica-Bold findfont 14 scalefont setfont
/y 200 def
[ ($job) ($host) ($date) ] {
270 y moveto show /y y 18 sub def
} forall
%
% That is it
%
restore
showpage
EOFNow, each of the conversion filters and the text filter can call
this script to first generate the header page, and then print the
user's job. Here is the DVI conversion filter from earlier in this
document, modified to make a header page:
#!/bin/sh
#
# psdf - DVI to PostScript printer filter
# Installed in /usr/local/libexec/psdf
#
# Invoked by lpd when user runs lpr -d
#
orig_args="$@"
fail() {
echo "$@" 1>&2
exit 2
}
while getopts "x:y:n:h:" option; do
case $option in
x|y) ;; # Ignore
n) login=$OPTARG ;;
h) host=$OPTARG ;;
*) echo "LPD started `basename $0` wrong." 1>&2
exit 2
;;
esac
done
[ "$login" ] || fail "No login name"
[ "$host" ] || fail "No host name"
( /usr/local/libexec/make-ps-header $login $host "DVI File"
/usr/local/bin/dvips -f ) | eval /usr/local/libexec/lprps $orig_argsNotice how the filter has to parse the argument list in order to
determine the user and host name. The parsing for the other
conversion filters is identical. The text filter takes a slightly
different set of arguments, though (see section How Filters
Work).As we have mentioned before, the above scheme, though fairly
simple, disables the “suppress header page” option (the
option) to lpr. If users
wanted to save a tree (or a few pennies, if you charge for header
pages), they would not be able to do so, since every filter's going
to print a header page with every job.To allow users to shut off header pages on a per-job basis, you
will need to use the trick introduced in section Accounting for
Header Pages: write an output filter that parses the
LPD-generated header page and produces a PostScript version. If the
user submits the job with lpr -h, then LPD will
not generate a header page, and neither will your output filter.
Otherwise, your output filter will read the text from LPD and send
the appropriate header page PostScript code to the printer.If you have a PostScript printer on a serial line, you can make
use of lprps, which comes with an output filter,
psof, which does the above. Note that
psof does not charge for header pages.Networked PrintingFreeBSD supports networked printing: sending jobs to remote
printers. Networked printing generally refers to two different
things:Accessing a printer attached to a remote host. You install a
printer that has a conventional serial or parallel interface on
one host. Then, you set up LPD to enable access to the printer
from other hosts on the network. Section Printers Installed on
Remote Hosts tells how to do this.Accessing a printer attached directly to a network. The
printer has a network interface in addition (or in place of) a
more conventional serial or parallel interface. Such a printer
might work as follows:It might understand the LPD protocol and can even queue
jobs from remote hosts. In this case, it acts just like a
regular host running LPD. Follow the same procedure in
section Printers
Installed on Remote Hosts to set up such a
printer.It might support a data stream network connection. In this
case, you “attach” the printer to one host on the
network by making that host responsible for spooling jobs and
sending them to the printer. Section Printers with
Networked Data Stream Interfaces gives some
suggestions on installing such printers.Printers Installed on Remote HostsThe LPD spooling system has built-in support for sending jobs to
other hosts also running LPD (or are compatible with LPD). This
feature enables you to install a printer on one host and make it
accessible from other hosts. It also works with printers that have
network interfaces that understand the LPD protocol.To enable this kind of remote printing, first install a printer
on one host, the printer host, using the simple
printer setup described in Simple
Printer Setup. Do any advanced setup in Advanced Printer Setup that you
need. Make sure to test the printer and see if it works with the
features of LPD you have enabled. Also ensure that the
local host has authorization to use the LPD
service in the remote host (see Restricting Jobs
from Remote Printers).If you are using a printer with a network interface that is
compatible with LPD, then the printer host in
the discussion below is the printer itself, and the
printer name is the name you configured for the
printer. See the documentation that accompanied your printer and/or
printer-network interface.Then, on the other hosts you want to have access to the printer,
make an entry in their /etc/printcap files with
the following:Name the entry anything you want. For simplicity, though,
you probably want to use the same name and aliases as on the
printer host.Leave the lp capability blank, explicitly
(:lp=:).Make a spooling directory and specify its location in the
sd capability. LPD will store jobs here
before they get sent to the printer host.Place the name of the printer host in the
rm capability.Place the printer name on the printer
host in the rp
capability.That is it. You do not need to list conversion filters, page
dimensions, or anything else in the
/etc/printcap file.Here is an example. The host rose has two
printers, bamboo and rattan.
We will enable users on the host orchid to print to those printers.
Here is the /etc/printcap file for
orchid (back from section Enabling Header
Pages). It already had the entry for the printer
teak; we have added entries for the two printers
on the host rose:
#
# /etc/printcap for host orchid - added (remote) printers on rose
#
#
# teak is local; it is connected directly to orchid:
#
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:\
:if=/usr/local/libexec/ifhp:\
:vf=/usr/local/libexec/vfhp:\
:of=/usr/local/libexec/ofhp:
#
# rattan is connected to rose; send jobs for rattan to rose:
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan:
#
# bamboo is connected to rose as well:
#
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:Then, we just need to make spooling directories on
orchid:&prompt.root; mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo
&prompt.root; chmod 770 /var/spool/lpd/rattan /var/spool/lpd/bamboo
&prompt.root; chown daemon.daemon /var/spool/lpd/rattan /var/spool/lpd/bambooNow, users on orchid can print to
rattan and bamboo. If, for
example, a user on orchid typed
&prompt.user; lpr -P bamboo -d sushi-review.dvi
the LPD system on orchid would copy the job to the spooling
directory /var/spool/lpd/bamboo and note that
it was a DVI job. As soon as the host rose has room in its
bamboo spooling directory, the two LPDs would
transfer the file to rose. The file would wait in rose's queue
until it was finally printed. It would be converted from DVI to
PostScript (since bamboo is a PostScript printer) on rose.Printers with Networked Data Stream InterfacesOften, when you buy a network interface card for a printer, you
can get two versions: one which emulates a spooler (the more
expensive version), or one which just lets you send data to it as if
you were using a serial or parallel port (the cheaper version).
This section tells how to use the cheaper version. For the more
expensive one, see the previous section Printers Installed on
Remote Hosts.The format of the /etc/printcap file lets
you specify what serial or parallel interface to use, and (if you
are using a serial interface), what baud rate, whether to use flow
control, delays for tabs, conversion of newlines, and more. But
there is no way to specify a connection to a printer that is
listening on a TCP/IP or other network port.To send data to a networked printer, you need to develop a
communications program that can be called by the text and conversion
filters. Here is one such example: the script
netprint takes all data on standard input and
sends it to a network-attached printer. We specify the hostname of
the printer as the first argument and the port number to which to
connect as the second argument to netprint. Note
that this supports one-way communication only (FreeBSD to printer);
many network printers support two-way communication, and you might
want to take advantage of that (to get printer status, perform
accounting, etc.).
#!/usr/bin/perl
#
# netprint - Text filter for printer attached to network
# Installed in /usr/local/libexec/netprint
#
$#ARGV eq 1 || die "Usage: $0 <printer-hostname> <port-number>";
$printer_host = $ARGV[0];
$printer_port = $ARGV[1];
require 'sys/socket.ph';
($ignore, $ignore, $protocol) = getprotobyname('tcp');
($ignore, $ignore, $ignore, $ignore, $address)
= gethostbyname($printer_host);
$sockaddr = pack('S n a4 x8', &AF_INET, $printer_port, $address);
socket(PRINTER, &PF_INET, &SOCK_STREAM, $protocol)
|| die "Can't create TCP/IP stream socket: $!";
connect(PRINTER, $sockaddr) || die "Can't contact $printer_host: $!";
while (<STDIN>) { print PRINTER; }
exit 0;We can then use this script in various filters. Suppose we had
a Diablo 750-N line printer connected to the network. The printer
accepts data to print on port number 5100. The host name of the
printer is scrivener. Here is the text filter for the
printer:
#!/bin/sh
#
# diablo-if-net - Text filter for Diablo printer `scrivener' listening
# on port 5100. Installed in /usr/local/libexec/diablo-if-net
#
exec /usr/libexec/lpr/lpf "$@" | /usr/local/libexec/netprint scrivener 5100Restricting Printer UsageThis section gives information on restricting printer usage. The
LPD system lets you control who can access a printer, both locally or
remotely, whether they can print multiple copies, how large their jobs
can be, and how large the printer queues can get.Restricting Multiple CopiesThe LPD system makes it easy for users to print multiple copies
of a file. Users can print jobs with lpr -#5
(for example) and get five copies of each file in the job. Whether
this is a good thing is up to you.If you feel multiple copies cause unnecessary wear and tear on
your printers, you can disable the option to
&man.lpr.1; by adding the sc capability to the
/etc/printcap file. When users submit jobs
with the option, they will see:lpr: multiple copies are not allowedNote that if you have set up access to a printer remotely (see
section Printers
Installed on Remote Hosts), you need the
sc capability on the remote
/etc/printcap files as well, or else users will
still be able to submit multiple-copy jobs by using another
host.Here is an example. This is the
/etc/printcap file for the host
rose. The printer rattan is
quite hearty, so we will allow multiple copies, but the laser
printer bamboo's a bit more delicate, so we will
disable multiple copies by adding the sc
capability:
#
# /etc/printcap for host rose - restrict multiple copies on bamboo
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:Now, we also need to add the sc capability on
the host orchid's
/etc/printcap (and while we are at it, let us
disable multiple copies for the printer
teak):
#
# /etc/printcap for host orchid - no multiple copies for local
# printer teak or remote printer bamboo
teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\
:lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\
:if=/usr/local/libexec/ifhp:\
:vf=/usr/local/libexec/vfhp:\
:of=/usr/local/libexec/ofhp:
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc:By using the sc capability, we prevent the
use of lpr -#, but that still does not prevent
users from running &man.lpr.1;
multiple times, or from submitting the same file multiple times in
one job like this:&prompt.user; lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.signThere are many ways to prevent this abuse (including ignoring
it) which you are free to explore.Restricting Access To PrintersYou can control who can print to what printers by using the UNIX
group mechanism and the rg capability in
/etc/printcap. Just place the users you want
to have access to a printer in a certain group, and then name that
group in the rg capability.Users outside the group (including root) will be greeted with
lpr: Not a member of the restricted group
if they try to print to the controlled printer.As with the sc (suppress multiple copies)
capability, you need to specify rg on remote
hosts that also have access to your printers, if you feel it is
appropriate (see section Printers Installed on
Remote Hosts).For example, we will let anyone access the printer
rattan, but only those in group
artists can use bamboo. Here
is the familiar /etc/printcap for host
rose:
#
# /etc/printcap for host rose - restricted group for bamboo
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:Let us leave the other example
/etc/printcap file (for the host
orchid) alone. Of course, anyone on
orchid can print to bamboo. It
might be the case that we only allow certain logins on
orchid anyway, and want them to have access to the
printer. Or not.There can be only one restricted group per printer.Controlling Sizes of Jobs SubmittedIf you have many users accessing the printers, you probably need
to put an upper limit on the sizes of the files users can submit to
print. After all, there is only so much free space on the
filesystem that houses the spooling directories, and you also need
to make sure there is room for the jobs of other users.LPD enables you to limit the maximum byte size a file in a job
can be with the mx capability. The units are in
BUFSIZ blocks, which are 1024 bytes. If you put a zero for this
capability, there will be no limit on file size; however, if no
mx capability is specified, then a default limit
of 1000 blocks will be used.The limit applies to files in a job, and
not the total job size.LPD will not refuse a file that is larger than the limit you
place on a printer. Instead, it will queue as much of the file up
to the limit, which will then get printed. The rest will be
discarded. Whether this is correct behavior is up for
debate.Let us add limits to our example printers
rattan and bamboo. Since
those artists' PostScript files tend to be large, we will limit them
to five megabytes. We will put no limit on the plain text line
printer:
#
# /etc/printcap for host rose
#
#
# No limit on job size:
#
rattan|line|diablo|lp|Diablo 630 Line Printer:\
:sh:mx#0:sd=/var/spool/lpd/rattan:\
:lp=/dev/lpt0:\
:if=/usr/local/libexec/if-simple:
#
# Limit of five megabytes:
#
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:Again, the limits apply to the local users only. If you have
set up access to your printers remotely, remote users will not get
those limits. You will need to specify the mx
capability in the remote /etc/printcap files as
well. See section Printers Installed on
Remote Hosts for more information on remote
printing.There is another specialized way to limit job sizes from remote
printers; see section Restricting Jobs
from Remote Printers.Restricting Jobs from Remote PrintersThe LPD spooling system provides several ways to restrict print
jobs submitted from remote hosts:Host restrictionsYou can control from which remote hosts a local LPD
accepts requests with the files
/etc/hosts.equiv and
/etc/hosts.lpd. LPD checks to see if an
incoming request is from a host listed in either one of these
files. If not, LPD refuses the request.The format of these files is simple: one host name per
line. Note that the file
/etc/hosts.equiv is also used by the
&man.ruserok.3; protocol, and affects programs like
&man.rsh.1; and &man.rcp.1;, so be careful.For example, here is the
/etc/hosts.lpd file on the host
rose:
orchid
violet
madrigal.fishbaum.deThis means rose will accept requests from
the hosts orchid, violet,
and madrigal.fishbaum.de. If any
other host tries to access rose's LPD, LPD
will refuse them.Size restrictionsYou can control how much free space there needs to remain
on the filesystem where a spooling directory resides. Make a
file called minfree in the spooling
directory for the local printer. Insert in that file a number
representing how many disk blocks (512 bytes) of free space
there has to be for a remote job to be accepted.This lets you insure that remote users will not fill your
filesystem. You can also use it to give a certain priority to
local users: they will be able to queue jobs long after the
free disk space has fallen below the amount specified in the
minfree file.For example, let us add a minfree
file for the printer bamboo. We examine
/etc/printcap to find the spooling
directory for this printer; here is bamboo's
entry:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:The spooling directory is the given in the
sd capability. We will make three
megabytes (which is 6144 disk blocks) the amount of free disk
space that must exist on the filesystem for LPD to accept
remote jobs:&prompt.root; echo 6144 > /var/spool/lpd/bamboo/minfreeUser restrictionsYou can control which remote users can print to local
printers by specifying the rs capability in
/etc/printcap. When
rs appears in the entry for a
locally-attached printer, LPD will accept jobs from remote
hosts if the user submitting the job also
has an account of the same login name on the local host.
Otherwise, LPD refuses the job.This capability is particularly useful in an environment
where there are (for example) different departments sharing a
network, and some users transcend departmental boundaries. By
giving them accounts on your systems, they can use your
printers from their own departmental systems. If you would
rather allow them to use only your
printers and not your compute resources, you can give them
“token” accounts, with no home directory and a
useless shell like /usr/bin/false.Accounting for Printer UsageSo, you need to charge for printouts. And why not? Paper and ink
cost money. And then there are maintenance costs—printers are
loaded with moving parts and tend to break down. You have examined
your printers, usage patterns, and maintenance fees and have come up
with a per-page (or per-foot, per-meter, or per-whatever) cost. Now,
how do you actually start accounting for printouts?Well, the bad news is the LPD spooling system does not provide
much help in this department. Accounting is highly dependent on the
kind of printer in use, the formats being printed, and
your requirements in charging for printer
usage.To implement accounting, you have to modify a printer's text
filter (to charge for plain text jobs) and the conversion filters (to
charge for other file formats), to count pages or query the printer
for pages printed. You cannot get away with using the simple output
filter, since it cannot do accounting. See section Filters.Generally, there are two ways to do accounting:Periodic accounting is the more common
way, possibly because it is easier. Whenever someone prints a
job, the filter logs the user, host, and number of pages to an
accounting file. Every month, semester, year, or whatever time
period you prefer, you collect the accounting files for the
various printers, tally up the pages printed by users, and charge
for usage. Then you truncate all the logging files, starting with
a clean slate for the next period.Timely accounting is less common,
probably because it is more difficult. This method has the
filters charge users for printouts as soon as they use the
printers. Like disk quotas, the accounting is immediate. You can
prevent users from printing when their account goes in the red,
and might provide a way for users to check and adjust their
“print quotas.” But this method requires some database
code to track users and their quotas.The LPD spooling system supports both methods easily: since you
have to provide the filters (well, most of the time), you also have to
provide the accounting code. But there is a bright side: you have
enormous flexibility in your accounting methods. For example, you
choose whether to use periodic or timely accounting. You choose what
information to log: user names, host names, job types, pages printed,
square footage of paper used, how long the job took to print, and so
forth. And you do so by modifying the filters to save this
information.Quick and Dirty Printer AccountingFreeBSD comes with two programs that can get you set up with
simple periodic accounting right away. They are the text filter
lpf, described in section lpf: a Text Filter, and
&man.pac.8;, a program to gather and total
entries from printer accounting files.As mentioned in the section on filters (Filters), LPD starts
the text and the conversion filters with the name of the accounting
file to use on the filter command line. The filters can use this
argument to know where to write an accounting file entry. The name
of this file comes from the af capability in
/etc/printcap, and if not specified as an
absolute path, is relative to the spooling directory.LPD starts lpf with page width and length
arguments (from the pw and pl
capabilities). lpf uses these arguments to
determine how much paper will be used. After sending the file to
the printer, it then writes an accounting entry in the accounting
file. The entries look like this:
2.00 rose:andy
3.00 rose:kelly
3.00 orchid:mary
5.00 orchid:mary
2.00 orchid:zhangYou should use a separate accounting file for each printer, as
lpf has no file locking logic built into it, and
two lpfs might corrupt each other's entries if
they were to write to the same file at the same time. A easy way to
insure a separate accounting file for each printer is to use
af=acct in /etc/printcap.
Then, each accounting file will be in the spooling directory for a
printer, in a file named acct.When you are ready to charge users for printouts, run the
&man.pac.8; program. Just change to the spooling directory for
the printer you want to collect on and type pac.
You will get a dollar-centric summary like the following: Login pages/feet runs price
orchid:kelly 5.00 1 $ 0.10
orchid:mary 31.00 3 $ 0.62
orchid:zhang 9.00 1 $ 0.18
rose:andy 2.00 1 $ 0.04
rose:kelly 177.00 104 $ 3.54
rose:mary 87.00 32 $ 1.74
rose:root 26.00 12 $ 0.52
total 337.00 154 $ 6.74These are the arguments &man.pac.8; expects:Which printer to summarize.
This option works only if there is an absolute path in the
af capability in
/etc/printcap.Sort the output by cost instead of alphabetically by user
name.Ignore host name in the accounting files. With this
option, user smith on host
alpha is the same user
smith on host gamma.
Without, they are different users.Compute charges with price
dollars per page or per foot instead of the price from the
pc capability in
/etc/printcap, or two cents (the
default). You can specify price as
a floating point number.Reverse the sort order.Make an accounting summary file and truncate the
accounting file.name…Print accounting information for the given user
names only.In the default summary that &man.pac.8; produces, you see the
number of pages printed by each user from various hosts. If, at
your site, host does not matter (because users can use any host),
run pac -m, to produce the following
summary: Login pages/feet runs price
andy 2.00 1 $ 0.04
kelly 182.00 105 $ 3.64
mary 118.00 35 $ 2.36
root 26.00 12 $ 0.52
zhang 9.00 1 $ 0.18
total 337.00 154 $ 6.74To compute the dollar amount due,
&man.pac.8; uses the pc capability in the
/etc/printcap file (default of 200, or 2 cents
per page). Specify, in hundredths of cents, the price per page or
per foot you want to charge for printouts in this capability. You
can override this value when you run &man.pac.8; with the
option. The units for the
option are in dollars, though, not hundredths of cents. For
example,
&prompt.root; pac -p1.50
makes each page cost one dollar and fifty cents. You can really
rake in the profits by using this option.Finally, running pac -s will save the summary
information in a summary accounting file, which is named the same as
the printer's accounting file, but with _sum
appended to the name. It then truncates the accounting file. When
you run &man.pac.8; again, it rereads the
summary file to get starting totals, then adds information from the
regular accounting file.How Can You Count Pages Printed?In order to perform even remotely accurate accounting, you need
to be able to determine how much paper a job uses. This is the
essential problem of printer accounting.For plain text jobs, the problem's not that hard to solve: you
count how many lines are in a job and compare it to how many lines
per page your printer supports. Do not forget to take into account
backspaces in the file which overprint lines, or long logical lines
that wrap onto one or more additional physical lines.The text filter lpf (introduced in lpf: a Text Filter) takes
into account these things when it does accounting. If you are
writing a text filter which needs to do accounting, you might want
to examine lpf's source code.How do you handle other file formats, though?Well, for DVI-to-LaserJet or DVI-to-PostScript conversion, you
can have your filter parse the diagnostic output of
dvilj or dvips and look to see
how many pages were converted. You might be able to do similar
things with other file formats and conversion programs.But these methods suffer from the fact that the printer may not
actually print all those pages. For example, it could jam, run out
of toner, or explode—and the user would still get
charged.So, what can you do?There is only one sure way to do
accurate accounting. Get a printer that can
tell you how much paper it uses, and attach it via a serial line or
a network connection. Nearly all PostScript printers support this
notion. Other makes and models do as well (networked Imagen laser
printers, for example). Modify the filters for these printers to
get the page usage after they print each job and have them log
accounting information based on that value
only. There is no line counting nor
error-prone file examination required.Of course, you can always be generous and make all printouts
free.Alternatives to the Standard SpoolerIf you have been reading straight through this manual, by now you
have learned just about everything there is to know about the LPD
spooling system that comes with FreeBSD. You can probably appreciate
many of its shortcomings, which naturally leads to the question:
“What other spooling systems are out there (and work with
FreeBSD)?”Unfortunately, I have located only two
alternatives—and they are almost identical to each other! They
are:PLP, the Portable Line Printer Spooler SystemPLP was based on software developed by Patrick Powell and then
maintained by an Internet-wide group of developers. The main site
for the software is at ftp://ftp.iona.ie/pub/plp.
There is also a web
page.It is quite similar to the BSD LPD spooler, but boasts a
host of features, including:Better network support, including built-in support for
networked printers, NIS-maintained printcaps, and NFS-mounted
spooling directoriesSophisticated queue management, allowing multiple printers
on a queue, transfer of jobs between queues, and queue
redirectionRemote printer control functionsPrioritization of jobsExpansive security and access optionsLPRngLPRng, which purportedly means “LPR: the Next
Generation” is a complete rewrite of PLP. Patrick Powell
and Justin Mason (the principal maintainer of PLP) collaborated to
make LPRng. The main site for LPRng is ftp://dickory.sdsu.edu/pub/LPRng.AcknowledgmentsI would like to thank the following people who have assisted in the
development of this document:Daniel Eischen
deischen@iworks.interworks.orgFor providing a plethora of HP filter programs for
perusal.&a.jehamby;For the Ghostscript-to-HP filter.&a.jfieber; For debugging why printing from Windows 95 to a FreeBSD
system simulating a PostScript printer with Ghostscript didn't
produce correct output, and suggesting a fix, which is included
herein.Stephen Montgomery-Smith
stephen@math.missouri.eduFor suggesting using "\033&l0H" instead of "\f" to eject
the last page on HP printers; the latter could eject an extra
blank page while the former never does.My wife, Mary Kelly
urquhart@argyre.colorado.eduFor allowing me to spend more time with FreeBSD than
with her.
diff --git a/en_US.ISO_8859-1/books/handbook/quotas/chapter.sgml b/en_US.ISO_8859-1/books/handbook/quotas/chapter.sgml
index 680cb5fce0..d82b970be1 100644
--- a/en_US.ISO_8859-1/books/handbook/quotas/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/quotas/chapter.sgml
@@ -1,232 +1,232 @@
Disk QuotasContributed by &a.mpp;. 26 February
1996Quotas are an optional feature of the operating system that allow you
to limit the amount of disk space and/or the number of files a user, or
members of a group, may allocate on a per-file system basis. This is used
most often on timesharing systems where it is desirable to limit the
amount of resources any one user or group of users may allocate. This
will prevent one user from consuming all of the available disk
space.Configuring Your System to Enable Disk QuotasBefore attempting to use disk quotas it is necessary to make sure
that quotas are configured in your kernel. This is done by adding the
following line to your kernel configuration file:
options QUOTAThe stock GENERIC kernel does not have this
enabled by default, so you will have to configure, build and install a
custom kernel in order to use disk quotas. Please refer to the Configuring the FreeBSD Kernel section
for more information on kernel configuration.Next you will need to enable disk quotas in
/etc/sysconfig. This is done by changing the line:
quotas=NO
to:
quotas=YESIf you are running FreeBSD 2.2.2 or later, the configuration file
will be /etc/rc.conf instead and the variable name
changed to:
check_quotas=YESFinally you will need to edit /etc/fstab to
enable disk quotas on a per-file system basis. This is where you can
either enable user or group quotas or both for all of your file
systems.To enable per-user quotas on a file system, add the
userquota option to the options field in the
/etc/fstab entry for the file system you want to to
enable quotas on. For example:
/dev/da1s2g /home ufs rw,userquota 1 2Similarly, to enable group quotas, use the
groupquota option instead of the
userquota keyword. To enable both user and group
quotas, change the entry as follows:
/dev/da1s2g /home ufs rw,userquota,groupquota 1 2By default the quota files are stored in the root directory of the
file system with the names quota.user and
quota.group for user and group quotas respectively.
See man fstab for more information. Even though that
man page says that you can specify an alternate location for the quota
files, this is not recommended since all of the various quota utilities
do not seem to handle this properly.At this point you should reboot your system with your new kernel.
/etc/rc will automatically run the appropriate
commands to create the initial quota files for all of the quotas you
enabled in /etc/fstab, so there is no need to
manually create any zero length quota files.In the normal course of operations you should not be required to run
the quotacheck, quotaon, or
quotaoff commands manually. However, you may want to
read their man pages just to be familiar with their operation.Setting Quota LimitsOnce you have configured your system to enable quotas, verify that
they really are enabled. An easy way to do this is to run&prompt.root; quota -vYou should see a one line summary of disk usage and current quota
limits for each file system that quotas are enabled on.You are now ready to start assigning quota limits with the
edquota command.You have several options on how to enforce limits on the amount of
disk space a user or group may allocate, and how many files they may
create. You may limit allocations based on disk space (block quotas) or
number of files (inode quotas) or a combination of both. Each of these
limits are further broken down into two categories: hard and soft
limits.A hard limit may not be exceeded. Once a user reaches their hard
limit they may not make any further allocations on the file system in
question. For example, if the user has a hard limit of 500 blocks on a
file system and is currently using 490 blocks, the user can only
allocate an additional 10 blocks. Attempting to allocate an additional
11 blocks will fail.Soft limits on the other hand can be exceeded for a limited amount
of time. This period of time is known as the grace period, which is one
week by default. If a user stays over his or her soft limit longer than
their grace period, the soft limit will turn into a hard limit and no
further allocations will be allowed. When the user drops back below the
soft limit, the grace period will be reset.The following is an example of what you might see when you run
then edquota command. When the
edquota command is invoked, you are placed into the
editor specified by the EDITOR environment variable, or
in the vi editor if the EDITOR
variable is not set, to allow you to edit the quota limits.&prompt.root; edquota -u test
Quotas for user test:
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
inodes in use: 7, limits (soft = 50, hard = 60)
/usr/var: blocks in use: 0, limits (soft = 50, hard = 75)
inodes in use: 0, limits (soft = 50, hard = 60)You will normally see two lines for each file system that has quotas
enabled. One line for the block limits, and one line for inode limits.
Simply change the value you want updated to modify the quota limit. For
example, to raise this users block limit from a soft limit of 50 and a
hard limit of 75 to a soft limit of 500 and a hard limit of 600, change:
/usr: blocks in use: 65, limits (soft = 50, hard =
75) to: /usr: blocks in use: 65,
limits (soft = 500, hard = 600)The new quota limits will be in place when you exit the
editor.Sometimes it is desirable to set quota limits on a range of uids.
This can be done by use of the option on the
edquota command. First, assign the desired quota
limit to a user, and then run edquota -p protouser
startuid-enduid. For example, if user
test has the desired quota limits, the following
command can be used to duplicate those quota limits for uids 10,000
through 19,999:&prompt.root; edquota -p test 10000-19999The ability to specify uid ranges was added to the system after 2.1
was released. If you need this feature on a 2.1 system, you will need
to obtain a newer copy of edquota.See man edquota for more detailed
information.Checking Quota Limits and Disk UsageYou can use either the quota or the
repquota commands to check quota limits and disk
usage. The quota command can be used to check
individual user and group quotas and disk usage. Only the super-user
may examine quotas and usage for other users, or for groups that they
are not a member of. The repquota command can be
used to get a summary of all quotas and disk usage for file systems with
quotas enabled.The following is some sample output from the quota
-v command for a user that has quota limits on two file
systems.
Disk quotas for user test (uid 1002):
Filesystem blocks quota limit grace files quota limit grace
/usr 65* 50 75 5days 7 50 60
/usr/var 0 50 75 0 50 60On the /usr file system in the above example
this user is currently 15 blocks over their soft limit of 50 blocks and
has 5 days of their grace period left. Note the asterisk
* which indicates that the user is currently over
their quota limit.Normally file systems that the user is not using any disk space on
will not show up in the output from the quota
command, even if they have a quota limit assigned for that file system.
The option will display those file systems, such as
the /usr/var file system in the above
example.* Quotas over NFSThis section is still under development.
diff --git a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml
index 98e355eea3..3fa8f44a74 100644
--- a/en_US.ISO_8859-1/books/handbook/security/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/security/chapter.sgml
@@ -1,1612 +1,1612 @@
SecurityDES, MD5, and CryptContributed by &a.wollman; 24 September
1995.In order to protect the security of passwords on UN*X systems from
being easily exposed, passwords have traditionally been scrambled in
some way. Starting with Bell Labs' Seventh Edition Unix, passwords were
encrypted using what the security people call a “one-way hash
function”. That is to say, the password is transformed in such a
way that the original password cannot be regained except by brute-force
searching the space of possible passwords. Unfortunately, the only
secure method that was available to the AT&T researchers at the time
was based on DES, the Data Encryption Standard. This causes only
minimal difficulty for commercial vendors, but is a serious problem for
an operating system like FreeBSD where all the source code is freely
available, because national governments in many places like to place
restrictions on cross-border transport of DES and other encryption
software.So, the FreeBSD team was faced with a dilemma: how could we provide
compatibility with all those UNIX systems out there while still not
running afoul of the law? We decided to take a dual-track approach: we
would make distributions which contained only a non-regulated password
scrambler, and then provide as a separate add-on library the DES-based
password hash. The password-scrambling function was moved out of the C
library to a separate library, called libcrypt
because the name of the C function to implement it is
crypt. In FreeBSD 1.x and some pre-release 2.0
snapshots, the non-regulated scrambler uses an insecure function written
by Nate Williams; in subsequent releases this was replaced by a
mechanism using the RSA Data Security, Inc., MD5 one-way hash function.
Because neither of these functions involve encryption, they are believed
to be exportable from the US and importable into many other
countries.Meanwhile, work was also underway on the DES-based password hash
function. First, a version of the crypt function
which was written outside the US was imported, thus synchronizing the US
and non-US code. Then, the library was modified and split into two; the
DES libcrypt contains only the code involved in
performing the one-way password hash, and a separate
libcipher was created with the entry points to
actually perform encryption. The code was partitioned in this way to
make it easier to get an export license for the compiled library.Recognizing your crypt mechanismIt is fairly easy to recognize whether a particular password
string was created using the DES- or MD5-based hash function. MD5
password strings always begin with the characters
$1$. DES password strings do not have any
particular identifying characteristics, but they are shorter than MD5
passwords, and are coded in a 64-character alphabet which does not
include the $ character, so a relatively short
string which doesn't begin with a dollar sign is very likely a DES
password.Determining which library is being used on your system is fairly
easy for most programs, except for those like init
which are statically linked. (For those programs, the only way is to
try them on a known password and see if it works.) Programs which use
crypt are linked against
libcrypt, which for each type of library is a
symbolic link to the appropriate implementation. For example, on a
system using the DES versions:&prompt.user; ls -l /usr/lib/libcrypt*
lrwxr-xr-x 1 root wheel 13 Mar 19 06:56 libcrypt.a -> libdescrypt.a
lrwxr-xr-x 1 root wheel 18 Mar 19 06:56 libcrypt.so.2.0 -> libdescrypt.so.2.0
lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.aOn a system using the MD5-based libraries, the same links will be
present, but the target will be libscrypt rather
than libdescrypt.S/KeyContributed by &a.wollman; 25 September
1995.S/Key is a one-time password scheme based on a one-way hash function
(in our version, this is MD4 for compatibility; other versions have used
MD5 and DES-MAC). S/Key has been a standard part of all FreeBSD
distributions since version 1.1.5, and is also implemented on a large
and growing number of other systems. S/Key is a registered trademark of
Bell Communications Research, Inc.There are three different sorts of passwords which we will talk
about in the discussion below. The first is your usual UNIX-style or
Kerberos password; we will call this a “UNIX password”. The
second sort is the one-time password which is generated by the S/Key
key program and accepted by the
keyinit program and the login prompt; we will call
this a “one-time password”. The final sort of password is
the secret password which you give to the key program
(and sometimes the keyinit program) which it uses to
generate one-time passwords; we will call it a “secret
password” or just unqualified “password”.The secret password does not necessarily have anything to do with
your UNIX password (while they can be the same, this is not
recommended). While UNIX passwords are limited to eight characters in
length, your S/Key secret password can be as long as you like; I use
seven-word phrases. In general, the S/Key system operates completely
independently of the UNIX password system.There are in addition two other sorts of data involved in the S/Key
system; one is called the “seed” or (confusingly)
“key”, and consists of two letters and five digits, and the
other is the “iteration count” and is a number between 100
and 1. S/Key constructs a one-time password from these components by
concatenating the seed and the secret password, then applying a one-way
hash (the RSA Data Security, Inc., MD4 secure hash function)
iteration-count times, and turning the result into six short English
words. The login and su programs
keep track of the last one-time password used, and the user is
authenticated if the hash of the user-provided password is equal to the
previous password. Because a one-way hash function is used, it is not
possible to generate future one-time passwords having overheard one
which was successfully used; the iteration count is decremented after
each successful login to keep the user and login program in sync. (When
you get the iteration count down to 1, it is time to reinitialize
S/Key.)There are four programs involved in the S/Key system which we will
discuss below. The key program accepts an iteration
count, a seed, and a secret password, and generates a one-time password.
The keyinit program is used to initialized S/Key, and
to change passwords, iteration counts, or seeds; it takes either a
secret password, or an iteration count, seed, and one-time password.
The keyinfo program examines the
/etc/skeykeys file and prints out the invoking
user's current iteration count and seed. Finally, the
login and su programs contain the
necessary logic to accept S/Key one-time passwords for authentication.
The login program is also capable of disallowing the
use of UNIX passwords on connections coming from specified
addresses.There are four different sorts of operations we will cover. The
first is using the keyinit program over a secure
connection to set up S/Key for the first time, or to change your
password or seed. The second operation is using the
keyinit program over an insecure connection, in
conjunction with the key program over a secure
connection, to do the same. The third is using the
key program to log in over an insecure connection.
The fourth is using the key program to generate a
number of keys which can be written down or printed out to carry with
you when going to some location without secure connections to anywhere
(like at a conference).Secure connection initializationTo initialize S/Key, change your password, or change your seed
while logged in over a secure connection (e.g., on the console of a
machine), use the keyinit command without any
parameters while logged in as yourself:&prompt.user; keyinit
Updating wollman: ) these will not appear if you
Old key: ha73895 ) have not used S/Key before
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password: ) I typed my pass phrase here
Again secret password: ) I typed it again ID
wollman s/key is 99 ha73896 ) discussed below SAG
HAS FONT GOUT FATE BOOM )There is a lot of information here. At theEnter secret
password: prompt, you should enter some password or phrase
(I use phrases of minimum seven words) which will be needed to
generate login keys. The line starting `ID' gives the parameters of
your particular S/Key instance: your login name, the iteration count,
and seed. When logging in with S/Key, the system will remember these
parameters and present them back to you so you do not have to remember
them. The last line gives the particular one-time password which
corresponds to those parameters and your secret password; if you were
to re-login immediately, this one-time password is the one you would
use.Insecure connection initializationTo initialize S/Key or change your password or seed over an
insecure connection, you will need to already have a secure connection
to some place where you can run the key program;
this might be in the form of a desk accessory on a Macintosh, or a
shell prompt on a machine you trust (we will show the latter). You
will also need to make up an iteration count (100 is probably a good
value), and you may make up your own seed or use a randomly-generated
one. Over on the insecure connection (to the machine you are
initializing), use the keyinit -s command:&prompt.user; keyinit -s
Updating wollman: Old key: kh94741
Reminder you need the 6 English words from the skey command.
Enter sequence count from 1 to 9999:100 ) I typed this
Enter new key [default kh94742]:
s/key 100 kh94742To accept the default seed (which the keyinit
program confusingly calls a key), press return.
Then move over to your secure connection or S/Key desk accessory, and
give it the same parameters:&prompt.user; key 100 kh94742
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
HULL NAY YANG TREE TOUT VETONow switch back over to the insecure connection, and copy the
one-time password generated by key over to the
keyinit program:s/key access password:HULL NAY YANG TREE TOUT VETO
ID wollman s/key is 100 kh94742
HULL NAY YANG TREE TOUT VETOThe rest of the description from the previous section applies here
as well.Diversion: a login promptBefore explaining how to generate one-time passwords, we should go
over an S/Key login prompt:&prompt.user; telnet himalia
Trying 18.26.0.186...
Connected to himalia.lcs.mit.edu.
Escape character is '^]'.
s/key 92 hi52030
Password:Note that, before prompting for a password, the login program
prints out the iteration number and seed which you will need in order
to generate the appropriate key. You will also find a useful feature
(not shown here): if you press return at the password prompt, the
login program will turn echo on, so you can see what you are typing.
This can be extremely useful if you are attempting to type in an S/Key
by hand, such as from a printout.If this machine were configured to disallow UNIX passwords over a
connection from my machine, the prompt would have also included the
annotation (s/key required), indicating that only
S/Key one-time passwords will be accepted.Generating a single one-time passwordNow, to generate the one-time password needed to answer this login
prompt, we use a trusted machine and the key
program. (There are versions of the key program
from DOS and Windows machines, and there is an S/Key desk accessory
for Macintosh computers as well.) The command-line
key program takes as its parameters the iteration
count and seed; you can cut-and-paste right from the login prompt
starting at key to the end of the line.
Thus:&prompt.user; key 92 hi52030 ) pasted from previous section
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password: ) I typed my secret password
ADEN BED WOLF HAW HOT STUNAnd in the other window:s/key 92 hi52030 ) from previous section
Password:
(turning echo on)
Password:ADEN BED WOLF HAW HOT STUN
Last login: Wed Jun 28 15:31:00 from halloran-eldar.l
[etc.]This is the easiest mechanism if you have a
trusted machine. There is a Java S/Key key applet,
The Java OTP
Calculator, that you can download and run locally on any
Java supporting browser.Generating multiple one-time passwordsSometimes we have to go places where no trusted machines or
connections are available. In this case, it is possible to use the
key command to generate a number of one-time
passwords in the same command; these can then be printed out. For
example:&prompt.user; key -n 25 57 zz99999
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
33: WALT THY MALI DARN NIT HEAD
34: ASK RICE BEAU GINA DOUR STAG
…
56: AMOS BOWL LUG FAT CAIN INCH
57: GROW HAYS TUN DISH CAR BALMThe requests twenty-five keys in sequence;
the indicates the ending
iteration number; and the rest is as before. Note that these are
printed out in reverse order of eventual use. If
you are really paranoid, you might want to write the results down by
hand; otherwise you can cut-and-paste into lpr.
Note that each line shows both the iteration count and the one-time
password; you may still find it handy to scratch off passwords as you
use them.Restricting use of UNIX passwordsThe configuration file /etc/skey.access can
be used to configure restrictions on the use of UNIX passwords based
on the host name, user name, terminal port, or IP address of a login
session. The complete format of the file is documented in the
&man.skey.access.5; manual page; there are also some security
cautions there which should be read before depending on this file for
security.If there is no /etc/skey.access file (which
is the default state as FreeBSD is shipped), then all users will be
allowed to use UNIX passwords. If the file exists, however, then all
users will be required to use S/Key unless explicitly permitted to do
otherwise by configuration statements in the
skey.access file. In all cases, UNIX passwords
are permitted on the console.Here is a sample configuration file which illustrates the three
most common sorts of configuration statements:
permit internet 18.26.0.0 255.255.0.0
permit user jrl
permit port ttyd0The first line (permit internet) allows users
whose IP source address (which is vulnerable to spoofing) matches the
specified value and mask, to use UNIX passwords. This should not be
considered a security mechanism, but rather, a means to remind
authorized users that they are using an insecure network and need to
use S/Key for authentication.The second line (permit user) allows the
specified user to use UNIX passwords at any time. Generally speaking,
this should only be used for people who are either unable to use the
key program, like those with dumb terminals, or
those who are uneducable.The third line (permit port) allows all users
logging in on the specified terminal line to use UNIX passwords; this
would be used for dial-ups.KerberosContributed by &a.markm; (based on contribution by
&a.md;).Kerberos is a network add-on system/protocol that allows users to
authenticate themselves through the services of a secure server.
Services such as remote login, remote copy, secure inter-system file
copying and other high-risk tasks are made considerably safer and more
controllable.The following instructions can be used as a guide on how to set up
Kerberos as distributed for FreeBSD. However, you should refer to the
relevant manual pages for a complete description.In FreeBSD, the Kerberos is not that from the original 4.4BSD-Lite,
distribution, but eBones, which had been previously ported to FreeBSD
1.1.5.1, and was sourced from outside the USA/Canada, and is thus
available to system owners outside those countries.For those needing to get a legal foreign distribution of this
software, please do not get it from a USA or Canada
site. You will get that site in big trouble! A
legal copy of this is available from ftp.internat.FreeBSD.org, which is in South
Africa and an official FreeBSD mirror site.Creating the initial databaseThis is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should change
to the directory /etc/kerberosIV and check that
only the following files are present:&prompt.root; cd /etc/kerberosIV
&prompt.root; ls
README krb.conf krb.realmsIf any additional files (such as principal.*
or master_key) exist, then use the
kdb_destroy command to destroy the old Kerberos
database, of if Kerberos is not running, simply delete the extra
files.You should now edit the krb.conf and
krb.realms files to define your Kerberos realm.
In this case the realm will be GRONDAR.ZA and the
server is grunt.grondar.za. We edit or create
the krb.conf file:&prompt.root; cat krb.conf
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.govIn this case, the other realms do not need to be there. They are
here as an example of how a machine may be made aware of multiple
realms. You may wish to not include them for simplicity.The first line names the realm in which this system works. The
other lines contain realm/host entries. The first item on a line is a
realm, and the second is a host in that realm that is acting as a
“key distribution centre”. The words admin
server following a hosts name means that host also
provides an administrative database server. For further explanation
of these terms, please consult the Kerberos man pages.Now we have to add grunt.grondar.za
to the GRONDAR.ZA realm and also add an entry to
put all hosts in the .grondar.za
domain in the GRONDAR.ZA realm. The
krb.realms file would be updated as
follows:&prompt.root; cat krb.realms
grunt.grondar.za GRONDAR.ZA
.grondar.za GRONDAR.ZA
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDUAgain, the other realms do not need to be there. They are here as
an example of how a machine may be made aware of multiple realms. You
may wish to remove them to simplify things.The first line puts the specific system into
the named realm. The rest of the lines show how to default systems of
a particular subdomain to a named realm.Now we are ready to create the database. This only needs to run
on the Kerberos server (or Key Distribution Centre). Issue the
kdb_init command to do this:&prompt.root; kdb_initRealm name [default ATHENA.MIT.EDU ]:GRONDAR.ZA
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:Now we have to save the key so that servers on the local machine
can pick it up. Use the kstash command to do
this.&prompt.root; kstashEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!This saves the encrypted master password in
/etc/kerberosIV/master_key.Making it all runTwo principals need to be added to the database for
each system that will be secured with Kerberos.
Their names are kpasswd and rcmd
These two principals are made for each system, with the instance being
the name of the individual system.These daemons, kpasswd and
rcmd allow other systems to change Kerberos
passwords and run commands like rcp,
rlogin and rsh.Now let's add these entries:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:passwdInstance:grunt
<Not found>, Create [y] ?y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name:rcmdInstance:grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitCreating the server fileWe now have to extract all the instances which define the services
on each machine. For this we use the ext_srvtab
command. This will create a file which must be copied or moved
by secure means to each Kerberos client's
/etc/kerberosIV directory. This file must be present on each server
and client, and is crucial to the operation of Kerberos.&prompt.root; ext_srvtab gruntEnter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....Now, this command only generates a temporary file which must be
renamed to srvtab so that all the server can pick
it up. Use the mv command to move it into place on
the original system:&prompt.root; mv grunt-new-srvtab srvtabIf the file is for a client system, and the network is not deemed
safe, then copy the
client-new-srvtab to
removable media and transport it by secure physical means. Be sure to
rename it to srvtab in the client's
/etc/kerberosIV directory, and make sure it is
mode 600:&prompt.root; mv grumble-new-srvtab srvtab
&prompt.root; chmod 600 srvtabPopulating the databaseWe now have to add some user entries into the database. First
let's create an entry for the user jane. Use the
kdb_edit command to do this:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:
<Not found>, Create [y] ?y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- enter a secure password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitTesting it all outFirst we have to start the Kerberos daemons. NOTE that if you
have correctly edited your /etc/rc.conf then this
will happen automatically when you reboot. This is only necessary on
the Kerberos server. Kerberos clients will automagically get what
they need from the /etc/kerberosIV
directory.&prompt.root; kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: GRONDAR.ZA
&prompt.root; kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!Now we can try using the kinit command to get a
ticket for the id jane that we created
above:&prompt.user; kinit jane
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane"
Password:Try listing the tokens using klist to see if we
really have them:&prompt.user; klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZANow try changing the password using passwd to
check if the kpasswd daemon can get authorization to the Kerberos
database:&prompt.user; passwd
realm GRONDAR.ZA
Old password for jane:New Password for jane:
Verifying password
New Password for jane:
Password changed.Adding su privilegesKerberos allows us to give each user who
needs root privileges their own separatesupassword. We could now add an id which is
authorized to su to root.
This is controlled by having an instance of root
associated with a principal. Using kdb_edit we can
create the entry jane.root in the Kerberos
database:&prompt.root; kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name:janeInstance:root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- enter a SECURE password here
Verifying password
New Password: <---- re-enter the password here
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exitNow try getting tokens for it to make sure it works:&prompt.root; kinit jane.root
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
Password:Now we need to add the user to root's .klogin
file:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZANow try doing the su:&prompt.user; suPassword:and take a look at what tokens we have:&prompt.root; klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@GRONDAR.ZA
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZAUsing other commandsIn an earlier example, we created a principal called
jane with an instance root.
This was based on a user with the same name as the principal, and this
is a Kerberos default; that a
<principal>.<instance> of the form
<username>.root will allow
that <username> to su to
root if the necessary entries are in the .klogin
file in root's home directory:&prompt.root; cat /root/.klogin
jane.root@GRONDAR.ZALikewise, if a user has in their own home directory lines of the
form:&prompt.user; cat ~/.klogin
jane@GRONDAR.ZA
jack@GRONDAR.ZAThis allows anyone in the GRONDAR.ZA realm
who has authenticated themselves to jane or
jack (via kinit, see above)
access to rlogin to jane's
account or files on this system (grunt) via
rlogin, rsh or
rcp.For example, Jane now logs into another system, using
Kerberos:&prompt.user; kinit
MIT Project Athena (grunt.grondar.za)
Password:
%prompt.user; rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995Or Jack logs into Jane's account on the same machine (Jane having
set up the .klogin file as above, and the person
in charge of Kerberos having set up principal
jack with a null instance:&prompt.user; kinit
&prompt.user; rlogin grunt -l jane
MIT Project Athena (grunt.grondar.za)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995FirewallsContributed by &a.gpalmer; and &a.alex;.Firewalls are an area of increasing interest for people who are
connected to the Internet, and are even finding applications on private
networks to provide enhanced security. This section will hopefully
explain what firewalls are, how to use them, and how to use the
facilities provided in the FreeBSD kernel to implement them.People often think that having a firewall between your companies
internal network and the “Big Bad Internet” will solve all
your security problems.It may help, but a poorly setup firewall system is more of a
security risk than not having one at all. A firewall can only add
another layer of security to your systems, but they will not be able
to stop a really determined cracker from penetrating your internal
network. If you let internal security lapse because you believe your
firewall to be impenetrable, you have just made the crackers job that
bit easier.What is a firewall?There are currently two distinct types of firewalls in common use
on the Internet today. The first type is more properly called a
packet filtering router, where the kernel on a
multi-homed machine chooses whether to forward or block packets based
on a set of rules. The second type, known as proxy
servers, rely on daemons to provide authentication and to
forward packets, possibly on a multi-homed machine which has kernel
packet forwarding disabled.Sometimes sites combine the two types of firewalls, so that only a
certain machine (known as a bastion host) is
allowed to send packets through a packet filtering router onto an
internal network. Proxy services are run on the bastion host, which
are generally more secure than normal authentication
mechanisms.FreeBSD comes with a kernel packet filter (known as
IPFW), which is what the rest of this
section will concentrate on. Proxy servers can be built on FreeBSD
from third party software, but there is such a variety of proxy
servers available that it would be impossible to cover them in this
document.Packet filtering routersA router is a machine which forwards packets between two or more
networks. A packet filtering router has an extra piece of code in
its kernel, which compares each packet to a list of rules before
deciding if it should be forwarded or not. Most modern IP routing
software has packet filtering code in it, which defaults to
forwarding all packets. To enable the filters, you need to define a
set of rules for the filtering code, so that it can decide if the
packet should be allowed to pass or not.To decide if a packet should be passed on or not, the code looks
through its set of rules for a rule which matches the contents of
this packets headers. Once a match is found, the rule action is
obeyed. The rule action could be to drop the packet, to forward the
packet, or even to send an ICMP message back to the originator.
Only the first match counts, as the rules are searched in order.
Hence, the list of rules can be referred to as a “rule
chain”.The packet matching criteria varies depending on the software
used, but typically you can specify rules which depend on the source
IP address of the packet, the destination IP address, the source
port number, the destination port number (for protocols which
support ports), or even the packet type (UDP, TCP, ICMP,
etc).Proxy serversProxy servers are machines which have had the normal system
daemons (telnetd, ftpd, etc) replaced with special servers. These
servers are called proxy servers as they
normally only allow onward connections to be made. This enables you
to run (for example) a proxy telnet server on your firewall host,
and people can telnet in to your firewall from the outside, go
through some authentication mechanism, and then gain access to the
internal network (alternatively, proxy servers can be used for
signals coming from the internal network and heading out).Proxy servers are normally more secure than normal servers, and
often have a wider variety of authentication mechanisms available,
including “one-shot” password systems so that even if
someone manages to discover what password you used, they will not be
able to use it to gain access to your systems as the password
instantly expires. As they do not actually give users access to the
host machine, it becomes a lot more difficult for someone to install
backdoors around your security system.Proxy servers often have ways of restricting access further, so
that only certain hosts can gain access to the servers, and often
they can be set up so that you can limit which users can talk to
which destination machine. Again, what facilities are available
depends largely on what proxy software you choose.What does IPFW allow me to do?IPFW, the software supplied with
FreeBSD, is a packet filtering and accounting system which resides in
the kernel, and has a user-land control utility,
&man.ipfw.8;. Together, they allow you to define and query the
rules currently used by the kernel in its routing decisions.There are two related parts to IPFW.
The firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of your
router, based on similar rules to the firewall section. This allows
you to see (for example) how much traffic your router is getting from
a certain machine, or how much WWW (World Wide Web) traffic it is
forwarding.As a result of the way that IPFW is
designed, you can use IPFW on non-router
machines to perform packet filtering on incoming and outgoing
connections. This is a special case of the more general use of
IPFW, and the same commands and techniques
should be used in this situation.Enabling IPFW on FreeBSDAs the main part of the IPFW system
lives in the kernel, you will need to add one or more options to your
kernel configuration file, depending on what facilities you want, and
recompile your kernel. See reconfiguring
the kernel for more details on how to recompile your
kernel.There are currently three kernel configuration options relevant to
IPFW:options IPFIREWALLCompiles into the kernel the code for packet
filtering.options IPFIREWALL_VERBOSEEnables code to allow logging of packets through
&man.syslogd.8;. Without this option, even if you specify
that packets should be logged in the filter rules, nothing will
happen.options IPFIREWALL_VERBOSE_LIMIT=10Limits the number of packets logged through
&man.syslogd.8; on a per entry basis. You may wish to use
this option in hostile environments in which you want to log
firewall activity, but do not want to be open to a denial of
service attack via syslog flooding.When a chain entry reaches the packet limit specified,
logging is turned off for that particular entry. To resume
logging, you will need to reset the associated counter using the
&man.ipfw.8; utility:&prompt.root; ipfw zero 4500Where 4500 is the chain entry you wish to continue
logging.Previous versions of FreeBSD contained an
IPFIREWALL_ACCT option. This is now obsolete as
the firewall code automatically includes accounting
facilities.Configuring IPFWThe configuration of the IPFW software
is done through the &man.ipfw.8; utility. The syntax for this
command looks quite complicated, but it is relatively simple once you
understand its structure.There are currently four different command categories used by the
utility: addition/deletion, listing, flushing, and clearing.
Addition/deletion is used to build the rules that control how packets
are accepted, rejected, and logged. Listing is used to examine the
contents of your rule set (otherwise known as the chain) and packet
counters (accounting). Flushing is used to remove all entries from
the chain. Clearing is used to zero out one or more accounting
entries.Altering the IPFW rulesThe syntax for this form of the command is:
ipfw-NcommandindexactionlogprotocoladdressesoptionsThere is one valid flag when using this form of the
command:-NResolve addresses and service names in output.The command given can be shortened to the
shortest unique form. The valid commands
are:addAdd an entry to the firewall/accounting rule listdeleteDelete an entry from the firewall/accounting rule
listPrevious versions of IPFW used
separate firewall and accounting entries. The present version
provides packet accounting with each firewall entry.If an index value is supplied, it used to
place the entry at a specific point in the chain. Otherwise, the
entry is placed at the end of the chain at an index 100 greater than
the last chain entry (this does not include the default policy, rule
65535, deny).The log option causes matching rules to be
output to the system console if the kernel was compiled with
IPFIREWALL_VERBOSE.Valid actions are:rejectDrop the packet, and send an ICMP host or port unreachable
(as appropriate) packet to the source.allowPass the packet on as normal. (aliases:
pass and
accept)denyDrop the packet. The source is not notified via an
ICMP message (thus it appears that the packet never
arrived at the destination).countUpdate packet counters but do not allow/deny the packet
based on this rule. The search continues with the next chain
entry.Each action will be recognized by the
shortest unambiguous prefix.The protocols which can be specified
are:allMatches any IP packeticmpMatches ICMP packetstcpMatches TCP packetsudpMatches UDP packetsThe address specification is:fromaddress/maskporttoaddress/markportvia interfaceYou can only specify port in
conjunction with protocols which support ports
(UDP and TCP).The is optional and may specify the IP
address or domain name of a local IP interface, or an interface name
(e.g. ed0) to match only packets coming
through this interface. Interface unit numbers can be specified
with an optional wildcard. For example, ppp*
would match all kernel PPP interfaces.The syntax used to specify an
address/mask is:
address
or
address/mask-bits
or
address:mask-patternA valid hostname may be specified in place of the IP address.
is a decimal
number representing how many bits in the address mask should be set.
e.g. specifying 192.216.222.1/24 will create a
mask which will allow any address in a class C subnet (in this case,
192.216.222) to be matched.
is an IP
address which will be logically AND'ed with the address given. The
keyword any may be used to specify “any IP
address”.The port numbers to be blocked are specified as:
port,port,port…
to specify either a single port or a list of ports, or
port-port
to specify a range of ports. You may also combine a single range
with a list, but the range must always be specified first.The options available are:fragMatches if the packet is not the first fragment of the
datagram.inMatches if the packet is on the way in.outMatches if the packet is on the way out.ipoptions specMatches if the IP header contains the comma separated list
of options specified in spec. The
supported list of IP options are: ssrr
(strict source route), lsrr (loose source
route), rr (record packet route), and
ts (timestamp). The absence of a
particular option may be denoted with a leading
!.establishedMatches if the packet is part of an already established
TCP connection (i.e. it has the RST or ACK bits set). You can
optimize the performance of the firewall by placing
established rules early in the
chain.setupMatches if the packet is an attempt to establish a TCP
connection (the SYN bit set is set but the ACK bit is
not).tcpflags flagsMatches if the TCP header contains the comma separated
list of flags. The supported flags
are fin, syn,
rst, psh,
ack, and urg. The
absence of a particular flag may be indicated by a leading
!.icmptypes typesMatches if the ICMP type is present in the list
types. The list may be specified
as any combination of ranges and/or individual types separated
by commas. Commonly used ICMP types are: 0
echo reply (ping reply), 3 destination
unreachable, 5 redirect,
8 echo request (ping request), and
11 time exceeded (used to indicate TTL
expiration as with &man.traceroute.8;).Listing the IPFW rulesThe syntax for this form of the command is:
ipfw-a-t-NlThere are three valid flags when using this form of the
command:-aWhile listing, show counter values. This option is the
only way to see accounting counters.-tDisplay the last match times for each chain entry. The
time listing is incompatible with the input syntax used by the
&man.ipfw.8; utility.-NAttempt to resolve given addresses and service
names.Flushing the IPFW rulesThe syntax for flushing the chain is:
ipfwflushThis causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny policy
will leave your system cut off from the network until allow entries
are added to the chain.Clearing the IPFW packet countersThe syntax for clearing one or more packet counters is:
ipfwzeroindexWhen used without an index argument,
all packet counters are cleared. If an
index is supplied, the clearing operation
only affects a specific chain entry.Example commands for ipfwThis command will deny all packets from the host evil.crackers.org to the telnet port of the
host nice.people.org by being forwarded
by the router:&prompt.root ipfw add deny tcp from evil.crackers.org to nice.people.org 23The next example denies and logs any TCP traffic from the entire
crackers.org network (a class C) to
the nice.people.org machine (any
port).&prompt.root; ipfw add deny log tcp from evil.crackers.org/24 to nice.people.orgIf you do not want people sending X sessions to your internal
network (a subnet of a class C), the following command will do the
necessary filtering:&prompt.root; ipfw add deny tcp from any to my.org/28 6000 setupTo see the accounting records:
&prompt.root; ipfw -a list
or in the short form
&prompt.root; ipfw -a lYou can also see the last time a chain entry was matched
with:&prompt.root; ipfw -at lBuilding a packet filtering firewallThe following suggestions are just that: suggestions. The
requirements of each firewall are different and I cannot tell you
how to build a firewall to meet your particular requirements.When initially setting up your firewall, unless you have a test
bench setup where you can configure your firewall host in a controlled
environment, I strongly recommend you use the logging version of the
commands and enable logging in the kernel. This will allow you to
quickly identify problem areas and cure them without too much
disruption. Even after the initial setup phase is complete, I
recommend using the logging for of `deny' as it allows tracing of
possible attacks and also modification of the firewall rules if your
requirements alter.If you use the logging versions of the accept
command, it can generate large amounts of log
data as one log line will be generated for every packet that passes
through the firewall, so large ftp/http transfers, etc, will really
slow the system down. It also increases the latencies on those
packets as it requires more work to be done by the kernel before the
packet can be passed on. syslogd with also start using up a lot
more processor time as it logs all the extra data to disk, and it
could quite easily fill the partition /var/log
is located on.You should enable your firewall from
/etc/rc.conf.local or
/etc/rc.conf. The associated manpage explains
which knobs to fiddle and lists some preset firewall configurations.
If you do not use a preset configuration, ipfw list
will output the current ruleset into a file that you can
pass to rc.conf. If you do not use
/etc/rc.conf.local or
/etc/rc.conf to enable your firewall,
it is important to make sure your firewall is enabled before
any IP interfaces are configured.
The next problem is what your firewall should actually
do! This is largely dependent on what access to
your network you want to allow from the outside, and how much access
to the outside world you want to allow from the inside. Some general
rules are:Block all incoming access to ports below 1024 for TCP. This is
where most of the security sensitive services are, like finger,
SMTP (mail) and telnet.Block all incoming UDP traffic. There
are very few useful services that travel over UDP, and what useful
traffic there is is normally a security threat (e.g. Suns RPC and
NFS protocols). This has its disadvantages also, since UDP is a
connectionless protocol, denying incoming UDP traffic also blocks
the replies to outgoing UDP traffic. This can cause a problem for
people (on the inside) using external archie (prospero) servers.
If you want to allow access to archie, you'll have to allow
packets coming from ports 191 and 1525 to any internal UDP port
through the firewall. ntp is another service you may consider
allowing through, which comes from port 123.Block traffic to port 6000 from the outside. Port 6000 is the
port used for access to X11 servers, and can be a security threat
(especially if people are in the habit of doing xhost
+ on their workstations). X11 can actually use a
range of ports starting at 6000, the upper limit being how many X
displays you can run on the machine. The upper limit as defined
by RFC 1700 (Assigned Numbers) is 6063.Check what ports any internal servers use (e.g. SQL servers,
etc). It is probably a good idea to block those as well, as they
normally fall outside the 1-1024 range specified above.Another checklist for firewall configuration is available from
CERT at ftp://ftp.cert.org/pub/tech_tips/packet_filteringAs I said above, these are only guidelines.
You will have to decide what filter rules you want to use on your
firewall yourself. I cannot accept ANY responsibility if someone
breaks into your network, even if you follow the advice given
above.
diff --git a/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml b/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml
index 1d4f043139..c6f1b9c097 100644
--- a/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/serialcomms/chapter.sgml
@@ -1,2731 +1,2731 @@
Serial CommunicationsSerial BasicsAssembled from FAQ.This section should give you some general information about serial
ports. If you do not find what you want here, check into the Terminal
and Dialup sections of the handbook.The ttydX (or
cuaaX) device is the
regular device you will want to open for your applications. When a
process opens the device, it will have a default set of terminal I/O
settings. You can see these settings with the command&prompt.root; stty -a -f /dev/ttyd1When you change the settings to this device, the settings are in
effect until the device is closed. When it is reopened, it goes back to
the default set. To make changes to the default set, you can open and
adjust the settings of the “initial state” device. For
example, to turn on CLOCAL mode, 8 bits, and
XON/XOFF flow control by default for ttyd5,
do:&prompt.root; stty -f /dev/ttyid5 clocal cs8 ixon ixoffA good place to do this is in /etc/rc.serial.
Now, an application will have these settings by default when it opens
ttyd5. It can still change these settings to its
liking, though.You can also prevent certain settings from being changed by an
application by making adjustments to the “lock state”
device. For example, to lock the speed of ttyd5 to
57600 bps, do&prompt.root; stty -f /dev/ttyld5 57600Now, an application that opens ttyd5 and tries
to change the speed of the port will be stuck with 57600 bps.Naturally, you should make the initial state and lock state devices
writable only by root. The
MAKEDEV script does not do
this when it creates the device entries.TerminalsContributed by &a.kelly; 28 July 1996Terminals provide a convenient and low-cost way to access the power
of your FreeBSD system when you are not at the computer's console or on
a connected network. This section describes how to use terminals with
FreeBSD.Uses and Types of TerminalsThe original Unix systems did not have consoles. Instead, people
logged in and ran programs through terminals that were connected to
the computer's serial ports. It is quite similar to using a modem and
some terminal software to dial into a remote system to do text-only
work.Today's PCs have consoles capable of high quality graphics, but
the ability to establish a login session on a serial port still exists
in nearly every Unix-style operating system today; FreeBSD is no
exception. By using a terminal attached to a unused serial port, you
can log in and run any text program that you would normally run on the
console or in an xterm window in the X Window
System.For the business user, you can attach many terminals to a FreeBSD
system and place them on your employees' desktops. For a home user, a
spare computer such as an older IBM PC or a Macintosh can be a
terminal wired into a more powerful computer running FreeBSD. You can
turn what might otherwise be a single-user computer into a powerful
multiple user system.For FreeBSD, there are three kinds of terminals:Dumb terminalsPCs acting as terminalsX terminalsThe remaining subsections describe each kind.Dumb TerminalsDumb terminals are specialized pieces of hardware that let you
connect to computers over serial lines. They are called
“dumb” because they have only enough computational power
to display, send, and receive text. You cannot run any programs on
them. It is the computer to which you connect them that has all the
power to run text editors, compilers, email, games, and so
forth.There are hundreds of kinds of dumb terminals made by many
manufacturers, including Digital Equipment Corporation's VT-100 and
Wyse's WY-75. Just about any kind will work with FreeBSD. Some
high-end terminals can even display graphics, but only certain
software packages can take advantage of these advanced
features.Dumb terminals are popular in work environments where workers do
not need access to graphic applications such as those provided by
the X Window System.PCs Acting As TerminalsIf a dumb terminal has just
enough ability to display, send, and receive text, then certainly
any spare personal computer can be a dumb terminal. All you need is
the proper cable and some terminal emulation
software to run on the computer.Such a configuration is popular in homes. For example, if your
spouse is busy working on your FreeBSD system's console, you can do
some text-only work at the same time from a less powerful personal
computer hooked up as a terminal to the FreeBSD system.X TerminalsX terminals are the most sophisticated kind of terminal
available. Instead of connecting to a serial port, they usually
connect to a network like Ethernet. Instead of being relegated to
text-only applications, they can display any X application.We introduce X terminals just for the sake of completeness.
However, this chapter does not cover setup,
configuration, or use of X terminals.Cables and PortsTo connect a terminal to your FreeBSD system, you need the right
kind of cable and a serial port to which to connect it. This section
tells you what to do. If you are already familiar with your terminal
and the cable it requires, skip to Configuration.CablesBecause terminals use serial ports, you need to use
serial—also known as RS-232C—cables to connect the
terminal to the FreeBSD system.There are a couple of kinds of serial cables. Which one
you'll use depends on the terminal you want to connect:If you are connecting a personal computer to act as a
terminal, use a null-modem
cable. A null-modem cable connects two computers or terminals
together.If you have an actual terminal, your best source of
information on what cable to use is the documentation that
accompanied the terminal. If you do not have the documentation,
then try a null-modem cable.
If that does not work, then try a standard cable.Also, the serial port on both the terminal
and your FreeBSD system must have connectors that will fit the cable
you are using.Null-modem cablesA null-modem cable passes some signals straight through, like
“signal ground,” but switches other signals. For
example, the “send data” pin on one end goes to the
“receive data” pin on the other end.If you like making your own cables, here is a table showing a
recommended way to construct a null-modem cable for use with
terminals. This table shows the RS-232C signal names and the pin
numbers on a DB-25 connector.SignalPin #Pin #SignalTxD2connects to3RxDRxD3connects to2TxDDTR20connects to6DSRDSR6connects to20DTRSG7connects to7SGDCD8connects to4RTSRTS45CTSCTS5connects to8DCDFor DCD to RTS, connect pins 4 to 5 internally in the
connector hood, and then to pin 8 in the remote
hood.Standard RS-232C CablesA standard serial cable passes all the RS-232C signals
straight-through. That is, the “send data” pin on one
end of the cable goes to the “send data” pin on the
other end. This is the type of cable to connect a modem to your
FreeBSD system, and the type of cable needed for some
terminals.PortsSerial ports are the devices through which data is transferred
between the FreeBSD host computer and the terminal. This section
describes the kinds of ports that exist and how they are addressed
in FreeBSD.Kinds of PortsSeveral kinds of serial ports exist. Before you purchase or
construct a cable, you need to make sure it will fit the ports on
your terminal and on the FreeBSD system.Most terminals will have DB25 ports. Personal computers,
including PCs running FreeBSD, will have DB25 or DB9 ports. If you
have a multiport serial card for your PC, you may have RJ-12 or
RJ-45 ports.See the documentation that accompanied the hardware for
specifications on the kind of port in use. A visual inspection of
the port often works, too.Port NamesIn FreeBSD, you access each serial port through an entry in
the /dev directory. There are two different
kinds of entries:Callin ports are named
/dev/ttydX
where X is the port number,
starting from zero. Generally, you use the callin port for
terminals. Callin ports require that the serial line assert
the data carrier detect (DCD) signal to work.Callout ports are named
/dev/cuaaX.
You usually do not use the callout port for terminals, just
for modems. You may use the callout port if the serial cable
or the terminal does not support the carrier detect
signal.See the &man.sio.4; manual page for more information.If you have connected a terminal to the first serial port
(COM1 in DOS parlance), then you want to
use /dev/ttyd0 to refer to the terminal. If
it is on the second serial port (also known as
COM2), it is
/dev/ttyd1, and so forth.Note that you may have to configure your kernel to support
each serial port, especially if you have a multiport serial card.
See Configuring the FreeBSD
Kernel for more information.ConfigurationThis section describes what you need to configure on your FreeBSD
system to enable a login session on a terminal. It assumes you have
already configured your kernel to support the serial port to which the
terminal is connected—and that you have connected it.In a nutshell, you need to tell the init
process, which is responsible for process control and initialization,
to start a getty process, which is responsible for
reading a login name and starting the login
program.To do so, you have to edit the /etc/ttys
file. First, use the su command to become root.
Then, make the following changes to
/etc/ttys:Add an line to /etc/ttys for the entry in
the /dev directory for the serial port if it
is not already there.Specify that /usr/libexec/getty be run on
the port, and specify the appropriate
getty type from the
/etc/gettytab file.Specify the default terminal type.Set the port to “on.”Specify whether the port should be
“secure.”Force init to reread the
/etc/ttys file.As an optional step, you may wish to create a custom
getty type for use in step 2 by making an
entry in /etc/gettytab. This document does
not explain how to do so; you are encouraged to see the
&man.gettytab.5; and the &man.getty.8; manual pages for more
information.The remaining sections detail how to do these steps. We will use
a running example throughout these sections to illustrate what we need
to do. In our example, we will connect two terminals to the system: a
Wyse-50 and a old 286 IBM PC running Procomm terminal software
emulating a VT-100 terminal. We connect the Wyse to the second serial
port and the 286 to the sixth serial port (a port on a multiport
serial card).For more information on the /etc/ttys
file, see the &man.ttys.5; manual page.Adding an Entry to /etc/ttysFirst, you need to add an entry to the
/etc/ttys file, unless one is already
there.The /etc/ttys file lists all of the ports
on your FreeBSD system where you want to allow logins. For example,
the first virtual console ttyv0 has an entry in
this file. You can log in on the console using this entry. This
file contains entries for the other virtual consoles, serial ports,
and pseudo-ttys. For a hardwired terminal, just list the serial
port's /dev entry without the
/dev part.When you installed your FreeBSD system, the
/etc/ttys file included entries for the first
four serial ports: ttyd0 through
ttyd3. If you are attaching a terminal on one
of those ports, you do not need to add an entry.In our example, we attached a Wyse-50 to the second serial port,
ttyd1, which is already in the file. We need
to add an entry for the 286 PC connected to the sixth serial port.
Here is an excerpt of the /etc/ttys file after
we add the new entry:
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
ttyd5Specifying the getty TypeNext, we need to specify what program will be run to handle the
logins on a terminal. For FreeBSD, the standard program to do that
is /usr/libexec/getty. It is what provides the
login: prompt.The program getty takes one (optional)
parameter on its command line, the getty
type. A getty type tells about
characteristics on the terminal line, like bps rate and parity. The
getty program reads these characteristics from
the file /etc/gettytab.The file /etc/gettytab contains lots of
entries for terminal lines both old and new. In almost all cases,
the entries that start with the text std will
work for hardwired terminals. These entries ignore parity. There is
a std entry for each bps rate from 110 to 115200.
Of course, you can add your own entries to this file. The manual
page &man.gettytab.5; provides more
information.When setting the getty type in the
/etc/ttys file, make sure that the
communications settings on the terminal match.For our example, the Wyse-50 uses no parity and connects at
38400 bps. The 286 PC uses no parity and connects at 19200 bps.
Here is the /etc/ttys file so far (showing just
the two terminals in which we are interested):
ttyd1 "/usr/libexec/getty std.38400" unknown off secure
ttyd5 "/usr/libexec/getty std.19200"Note that the second field—where we specify what program
to run—appears in quotes. This is important, otherwise the
type argument to getty might be interpreted as
the next field.Specifying the Default Terminal TypeThe third field in the /etc/ttys file lists
the default terminal type for the port. For dialup ports, you
typically put unknown or
dialup in this field because users may dial up
with practically any kind of terminal or software. For hardwired
terminals, the terminal type does not change, so you can put a real
terminal type in this field.Users will usually use the tset program in
their .login or .profile
files to check the terminal type and prompt for one if necessary.
By setting a terminal type in the /etc/ttys
file, users can forego such prompting.To find out what terminal types FreeBSD supports, see the
file /usr/share/misc/termcap. It lists
about 600 terminal types. You can add more if you wish. See
the &man.termcap.5; manual page for information.In our example, the Wyse-50 is a Wyse-50 type of terminal
(although it can emulate others, we will leave it in Wyse-50 mode).
The 286 PC is running Procomm which will be set to emulate a VT-100.
Here are the pertinent yet unfinished entries from the
/etc/ttys file:
ttyd1 "/usr/libexec/getty std.38400" wy50 off secure
ttyd5 "/usr/libexec/getty std.19200" vt100Enabling the PortThe next field in /etc/ttys, the fourth
field, tells whether to enable the port. Putting
on here will have the init
process start the program in the second field,
getty, which will prompt for a login. If you put
off in the fourth field, there will be no
getty, and hence no logins on the port.So, naturally, you want an on in this field.
Here again is the /etc/ttys file. We have
turned each port on.
ttyd1 "/usr/libexec/getty std.38400" wy50 on secure
ttyd5 "/usr/libexec/getty std.19200" vt100 onSpecifying Secure PortsWe have arrived at the last field (well, almost: there is an
optional window specifier, but we will ignore
that). The last field tells whether the port is secure.What does “secure” mean?It means that the root account (or any account with a user ID of
0) may login on the port. Insecure ports do not allow root to
login.How do you use secure and insecure ports?By marking a port as insecure, the terminal to which it is
connected will not allow root to login. People who know the root
password to your FreeBSD system will first have to login using a
regular user account. To gain superuser privileges, they will then
have to use the su command.Because of this, you will have two records to help track down
possible compromises of root privileges: both the
login and the su command make
records in the system log (and logins are also recorded in the
wtmp file).By marking a port as secure, the terminal will allow root in.
People who know the root password will just login as root. You will
not have the potentially useful login and su
command records.Which should you use?Just use “insecure.” Use “insecure”
even for terminals not in
public user areas or behind locked doors. It is quite easy to login
and use su if you need superuser
privileges.Here finally are the completed entries in the
/etc/ttys file, with comments added to describe
where the terminals are:
ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen
ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroomForce init to Reread
/etc/ttysWhen you boot FreeBSD, the first process,
init, will read the
/etc/ttys file and start the programs listed
for each enabled port to prompt for logins.After you edit /etc/ttys, you do not want
to have to reboot your system to get init to see
the changes. So, init will reread
/etc/ttys if it receives a SIGHUP (hangup)
signal.So, after you have saved your changes to
/etc/ttys, send SIGHUP to
init by typing:&prompt.root; kill -HUP 1(The init process always
has process ID 1.)If everything is set up correctly, all cables are in place, and
the terminals are powered up, you should see login prompts. Your
terminals are ready for their first logins!Debugging your connectionEven with the most meticulous attention to detail, something could
still go wrong while setting up a terminal. Here is a list of
symptoms and some suggested fixes.No login prompt appearsMake sure the terminal is plugged in and powered up. If it
is a personal computer acting as a terminal, make sure it is
running terminal emulation software on the correct serial
port.Make sure the cable is connected firmly to both the terminal
and the FreeBSD computer. Make sure it is the right kind of
cable.Make sure the terminal and FreeBSD agree on the bps rate and
parity settings. If you have a video display terminal, make
sure the contrast and brightness controls are turned up. If it
is a printing terminal, make sure paper and ink are in good
supply.Make sure that a getty process is running
and serving the terminal. Type &prompt.root;
ps -axww|grep getty to get a
list of running getty processes. You should
see an entry for the terminal. For example, the display
22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1
shows that a getty is running on the second
serial port ttyd1 and is using the
std.38400 entry in
/etc/gettytab.If no getty process is running, make sure
you have enabled the port in /etc/ttys.
Make sure you have run kill -HUP 1.Garbage appears instead of a login promptMake sure the terminal and FreeBSD agree on the bps rate and
parity settings. Check the getty processes to make sure the
correct getty type is in use. If
not, edit /etc/ttys and run kill
-HUP 1.Characters appear doubled; the password appears when
typedSwitch the terminal (or the terminal emulation software)
from “half duplex” or “local echo” to
“full duplex.”Dialin ServiceContributed by &a.ghelmer;.This document provides suggestions for configuring a FreeBSD system
to handle dialup modems. This document is written based on the author's
experience with FreeBSD versions 1.0, 1.1, and 1.1.5.1 (and experience
with dialup modems on other UNIX-like operating systems); however, this
document may not answer all of your questions or provide examples
specific enough to your environment. The author cannot be responsible if
you damage your system or lose data due to attempting to follow the
suggestions here.PrerequisitesTo begin with, the author assumes you have some basic knowledge of
FreeBSD. You need to have FreeBSD installed, know how to edit files
in a UNIX-like environment, and how to look up manual pages on the
system. As discussed below, you will need certain versions of
FreeBSD, and knowledge of some terminology & modem and
cabling.FreeBSD VersionFirst, it is assumed that you are using FreeBSD version 1.1 or
higher (including versions 2.x). FreeBSD version 1.0 included two
different serial drivers, which complicates the situation. Also,
the serial device driver (sio) has improved
in every release of FreeBSD, so more recent versions of FreeBSD are
assumed to have better and more efficient drivers than earlier
versions.TerminologyA quick rundown of terminology:bpsBits per Second — the rate at which data is
transmittedDTEData Terminal Equipment — for example, your
computerDCEData Communications Equipment — your modemRS-232EIA standard for serial communications via hardwareIf you need more information about these terms and data
communications in general, the author remembers reading that
The RS-232 Bible (anybody have an ISBN?) is a
good reference.When talking about communications data rates, the author does
not use the term “baud”. Baud refers to the number of
electrical state transitions that may be made in a period of time,
while “bps” (bits per second) is the
“correct” term to use (at least it does not seem to
bother the curmudgeons quite a much).External vs. Internal ModemsExternal modems seem to be more convenient for dialup, because
external modems often can be semi-permanently configured via
parameters stored in non-volatile RAM and they usually provide
lighted indicators that display the state of important RS-232
signals. Blinking lights impress visitors, but lights are also very
useful to see whether a modem is operating properly.Internal modems usually lack non-volatile RAM, so their
configuration may be limited only to setting DIP switches. If your
internal modem has any signal indicator lights, it is probably
difficult to view the lights when the system's cover is in
place.Modems and CablesA background knowledge of these items is assumedYou know how to connect your modem to your computer so that
the two can communicate (unless you have an internal modem,
which does not need such a cable)You are familiar with your modem's command set, or know
where to look up needed commandsYou know how to configure your modem (probably via a
terminal communications program) so you can set the non-volatile
RAM parametersThe first, connecting your modem, is usually simple — most
straight-through serial cables work without any problems. You need
to have a cable with appropriate connectors (DB-25 or DB-9, male or
female) on each end, and the cable must be a DCE-to-DTE cable with
these signals wired:Transmitted Data (SD)Received Data (RD)Request to Send (RTS)Clear to Send (CTS)Data Set Ready (DSR)Data Terminal Ready (DTR)Carrier Detect (CD)Signal Ground (SG)FreeBSD needs the RTS and
CTS signals for flow-control at speeds above
2400bps, the CD signal to detect when a call has
been answered or the line has been hung up, and the
DTR signal to reset the modem after a session is
complete. Some cables are wired without all of the needed signals,
so if you have problems, such as a login session not going away when
the line hangs up, you may have a problem with your cable.The second prerequisite depends on the modem(s) you use. If you
do not know your modem's command set by heart, you will need to have
the modem's reference book or user's guide handy. Sample commands
for USR Sportster 14,400 external modems will be given, which you
may be able to use as a reference for your own modem's
commands.Lastly, you will need to know how to setup your modem so that it
will work well with FreeBSD. Like other UNIX-like operating
systems, FreeBSD uses the hardware signals to find out when a call
has been answered or a line has been hung up and to hangup and reset
the modem after a call. FreeBSD avoids sending commands to the
modem or watching for status reports from the modem. If you are
familiar with connecting modems to PC-based bulletin board systems,
this may seem awkward.Serial Interface ConsiderationsFreeBSD supports NS8250-, NS16450-, NS16550-, and NS16550A-based
EIA RS-232C (CCITT V.24) communications interfaces. The 8250 and
16450 devices have single-character buffers. The 16550 device
provides a 16-character buffer, which allows for better system
performance. (Bugs in plain 16550's prevent the use of the
16-character buffer, so use 16550A's if possible). Because
single-character-buffer devices require more work by the operating
system than the 16-character-buffer devices, 16550A-based serial
interface cards are much preferred. If the system has many active
serial ports or will have a heavy load, 16550A-based cards are
better for low-error-rate communications.Quick OverviewHere is the process that FreeBSD follows to accept dialup logins.
A getty process, spawned by
init, patiently waits to open the assigned serial
port (/dev/ttyd0, for our example). The command
ps ax might show this: 4850 ?? I 0:00.09 /usr/libexec/getty V19200 ttyd0When a user dials the modem's line and the modems connect, the
CD line is asserted by the modem. The kernel
notices that carrier has been detected and completes
getty's open of the port. getty
sends a login: prompt at the specified initial line
speed. getty watches to see if legitimate
characters are received, and, in a typical configuration, if it finds
junk (probably due to the modem's connection speed being different
than getty's speed), getty tries
adjusting the line speeds until it receives reasonable
characters.We hope getty finds the correct speed and the
user sees a login: prompt. After the user enters
his/her login name, getty executes
/usr/bin/login, which completes the login by
asking for the user's password and then starting the user's
shell.Let's dive into the configuration...Kernel ConfigurationFreeBSD kernels typically come prepared to search for four serial
ports, known in the PC-DOS world as COM1:,
COM2:, COM3:, and
COM4:. FreeBSD can presently also handle
“dumb” multiport serial interface cards, such as the Boca
Board 1008 and 2016 (please see the manual page &man.sio.4; for kernel
configuration information if you have a multiport serial card). The
default kernel only looks for the standard COM ports, though.To see if your kernel recognizes any of your serial ports, watch
for messages while the kernel is booting, or use the
/sbin/dmesg command to replay the kernel's boot
messages. In particular, look for messages that start with the
characters sio. Hint: to view just the messages
that have the word sio, use the command:&prompt.root; /sbin/dmesg | grep 'sio'For example, on a system with four serial ports, these are the
serial-port specific kernel boot messages:sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
sio2 at 0x3e8-0x3ef irq 5 on isa
sio2: type 16550A
sio3 at 0x2e8-0x2ef irq 9 on isa
sio3: type 16550AIf your kernel does not recognize all of your serial ports, you
will probably need to configure a custom FreeBSD kernel for your
system.Please see the BSD System Manager's Manual chapter on
“Building Berkeley Kernels with Config” [the source for
which is in /usr/src/share/doc/smm] and
“FreeBSD Configuration Options” [in
/sys/conf/options and in
/sys/arch/conf/options.arch,
with arch for example being
i386] for more information on configuring and
building kernels. You may have to unpack the kernel source
distribution if have not installed the system sources already
(srcdist/srcsys.?? in FreeBSD 1.1,
srcdist/sys.?? in FreeBSD 1.1.5.1, or the entire
source distribution in FreeBSD 2.0) to be able to configure and build
kernels.Create a kernel configuration file for your system (if you have
not already) by cding to
/sys/i386/conf. Then, if you are creating a new
custom configuration file, copy the file
GENERICAH (or GENERICBT, if
you have a BusTek SCSI controller on FreeBSD 1.x) to
YOURSYS, where YOURSYS is
the name of your system, but in upper-case letters. Edit the file,
and change the device lines:
device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr
device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr
device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr
device sio3 at isa? port "IO_COM4" tty irq 9 vector siointrYou can comment-out or completely remove lines for devices you do
not have. If you have a multiport serial board, such as the Boca
Board BB2016, please see the &man.sio.4; man page for complete
information on how to write configuration lines for multiport boards.
Be careful if you are using a configuration file that was previously
used for a different version of FreeBSD because the device flags have
changed between versions.port "IO_COM1" is a substitution for
port 0x3f8, IO_COM2 is
0x2f8, IO_COM3 is
0x3e8, and IO_COM4 is
0x2e8, which are fairly common port addresses for
their respective serial ports; interrupts 4, 3, 5, and 9 are fairly
common interrupt request lines. Also note that regular serial ports
cannot share interrupts on ISA-bus PCs
(multiport boards have on-board electronics that allow all the
16550A's on the board to share one or two interrupt request
lines).When you are finished adjusting the kernel configuration file, use
the program config as documented in “Building
Berkeley Kernels with Config” and the
&man.config.8; manual page to prepare a kernel building directory,
then build, install, and test the new kernel.Device Special FilesMost devices in the kernel are accessed through “device
special files”, which are located in the
/dev directory. The sio
devices are accessed through the
/dev/ttyd? (dial-in)
and /dev/cua0?
(call-out) devices. On FreeBSD version 1.1.5 and higher, there are
also initialization devices
(/dev/ttyid? and
/dev/cuai0?) and
locking devices
(/dev/ttyld? and
/dev/cual0?). The
initialization devices are used to initialize communications port
parameters each time a port is opened, such as
crtscts for modems which use
CTS/RTS signaling for flow control. The locking
devices are used to lock flags on ports to prevent users or programs
changing certain parameters; see the manual pages &man.termios.4;,
&man.sio.4;, and &man.stty.1; for
information on the terminal settings, locking & initializing
devices, and setting terminal options, respectively.Making Device Special FilesA shell script called MAKEDEV in the
/dev directory manages the device special
files. (The manual page for &man.MAKEDEV.8; on FreeBSD 1.1.5 is
fairly bogus in its discussion of COM ports, so
ignore it.) To use MAKEDEV to make dialup device
special files for COM1: (port 0),
cd to /dev and issue the
command MAKEDEV ttyd0. Likewise, to make dialup
device special files for COM2: (port 1),
use MAKEDEV ttyd1.MAKEDEV not only creates the
/dev/ttyd? device
special files, but also creates the
/dev/cua0? (and all
of the initializing and locking special files under FreeBSD 1.1.5
and up) and removes the hardwired terminal special file
/dev/tty0?, if it
exists.After making new device special files, be sure to check the
permissions on the files (especially the
/dev/cua* files) to make sure that only users
who should have access to those device special files can read &
write on them — you probably do not want to allow your average
user to use your modems to dialout. The default permissions on the
/dev/cua* files should be sufficient:crw-rw---- 1 uucp dialer 28, 129 Feb 15 14:38 /dev/cua01
crw-rw---- 1 uucp dialer 28, 161 Feb 15 14:38 /dev/cuai01
crw-rw---- 1 uucp dialer 28, 193 Feb 15 14:38 /dev/cual01These permissions allow the user uucp and
users in the group dialer to use the call-out
devices.Configuration FilesThere are three system configuration files in the
/etc directory that you will probably need to
edit to allow dialup access to your FreeBSD system. The first,
/etc/gettytab, contains configuration information
for the /usr/libexec/getty daemon. Second,
/etc/ttys holds information that tells
/sbin/init what tty devices
should have getty processes running on them.
Lastly, you can place port initialization commands in the
/etc/rc.serial script if you have FreeBSD 1.1.5.1
or higher; otherwise, you can initialize ports in the
/etc/rc.local script.There are two schools of thought regarding dialup modems on UNIX.
One group likes to configure their modems and system so that no matter
at what speed a remote user dials in, the local computer-to-modem
RS-232 interface runs at a locked speed. The benefit of this
configuration is that the remote user always sees a system login
prompt immediately. The downside is that the system does not know
what a user's true data rate is, so full-screen programs like Emacs
will not adjust their screen-painting methods to make their response
better for slower connections.The other school configures their modems' RS-232 interface to vary
its speed based on the remote user's connection speed. For example,
V.32bis (14.4 Kbps) connections to the modem might make the modem run
its RS-232 interface at 19.2 Kbps, while 2400 bps connections make the
modem's RS-232 interface run at 2400 bps. Because
getty does not understand any particular modem's
connection speed reporting, getty gives a
login: message at an initial speed and watches the
characters that come back in response. If the user sees junk, it is
assumed that they know they should press the
<Enter> key until they see a recognizable
prompt. If the data rates do not match, getty sees
anything the user types as “junk”, tries going to the next
speed and gives the login: prompt again. This
procedure can continue ad nauseum, but normally only takes a keystroke
or two before the user sees a good prompt. Obviously, this login
sequence does not look as clean as the former
“locked-speed” method, but a user on a low-speed
connection should receive better interactive response from full-screen
programs.The author will try to give balanced configuration information,
but is biased towards having the modem's data rate follow the
connection rate./etc/gettytab/etc/gettytab is a &man.termcap.5;-style
file of configuration information for &man.getty.8;. Please see the
&man.gettytab.5; manual page for complete information on the
format of the file and the list of capabilities.Locked-Speed ConfigIf you are locking your modem's data communications rate at a
particular speed, you probably will not need to make any changes
to /etc/gettytab.Matching-Speed ConfigYou will need to setup an entry in
/etc/gettytab to give
getty information about the speeds you wish to
use for your modem. If you have a 2400 bps modem, you can
probably use the existing D2400 entry. This
entry already exists in the FreeBSD 1.1.5.1
gettytab file, so you do not need to add it
unless it is missing under your version of FreeBSD:
#
# Fast dialup terminals, 2400/1200/300 rotary (can start either way)
#
D2400|d2400|Fast-Dial-2400:\
:nx=D1200:tc=2400-baud:
3|D1200|Fast-Dial-1200:\
:nx=D300:tc=1200-baud:
5|D300|Fast-Dial-300:\
:nx=D2400:tc=300-baud:If you have a higher speed modem, you will probably need to
add an entry in /etc/gettytab; here is an
entry you could use for a 14.4 Kbps modem with a top interface
speed of 19.2 Kbps:
#
# Additions for a V.32bis Modem
#
um|V300|High Speed Modem at 300,8-bit:\
:nx=V19200:tc=std.300:
un|V1200|High Speed Modem at 1200,8-bit:\
:nx=V300:tc=std.1200:
uo|V2400|High Speed Modem at 2400,8-bit:\
:nx=V1200:tc=std.2400:
up|V9600|High Speed Modem at 9600,8-bit:\
:nx=V2400:tc=std.9600:
uq|V19200|High Speed Modem at 19200,8-bit:\
:nx=V9600:tc=std.19200:On FreeBSD 1.1.5 and later, this will result in 8-bit, no
parity connections. Under FreeBSD 1.1, add
:np: parameters to the
std.xxx entries at
the top of the file for 8 bits, no parity; otherwise, the default
is 7 bits, even parity.The example above starts the communications rate at 19.2 Kbps
(for a V.32bis connection), then cycles through 9600 bps (for
V.32), 2400 bps, 1200 bps, 300 bps, and back to 19.2 Kbps.
Communications rate cycling is implemented with the
nx= (“next table”) capability.
Each of the lines uses a tc= (“table
continuation”) entry to pick up the rest of the
“standard” settings for a particular data rate.If you have a 28.8 Kbps modem and/or you want to take
advantage of compression on a 14.4 Kbps modem, you need to use a
higher communications rate than 19.2 Kbps. Here is an example of
a gettytab entry starting a 57.6 Kbps:
#
# Additions for a V.32bis or V.34 Modem
# Starting at 57.6 Kbps
#
vm|VH300|Very High Speed Modem at 300,8-bit:\
:nx=VH57600:tc=std.300:
vn|VH1200|Very High Speed Modem at 1200,8-bit:\
:nx=VH300:tc=std.1200:
vo|VH2400|Very High Speed Modem at 2400,8-bit:\
:nx=VH1200:tc=std.2400:
vp|VH9600|Very High Speed Modem at 9600,8-bit:\
:nx=VH2400:tc=std.9600:
vq|VH57600|Very High Speed Modem at 57600,8-bit:\
:nx=VH9600:tc=std.57600:If you have a slow CPU or a heavily loaded system and you do
not have 16550A-based serial ports, you may receive sio
“silo” errors at 57.6 Kbps./etc/ttys/etc/ttys is the list of
ttys for init to monitor.
/etc/ttys also provides security information to
login (user root may only
login on ttys marked secure). See the manual
page for
&man.ttys.5; for more information.You will need to either modify existing lines in
/etc/ttys or add new lines to make
init run getty processes
automatically on your new dialup ports. The general format of the
line will be the same, whether you are using a locked-speed or
matching-speed configuration:
ttyd0 "/usr/libexec/getty xxx" dialup onThe first item in the above line is the device special file for
this entry — ttyd0 means
/dev/ttyd0 is the file that this
getty will be watching. The second item,
"/usr/libexec/getty
xxx"
(xxx will be replaced by the initial
gettytab capability) is the process
init will run on the device. The third item,
dialup, is the default terminal type. The fourth
parameter, on, indicates to
init that the line is operational. There can be
a fifth parameter, secure, but it should only be
used for terminals which are physically secure (such as the system
console).The default terminal type (dialup in the
example above) may depend on local preferences.
dialup is the traditional default terminal type
on dialup lines so that users may customize their login scripts to
notice when the terminal is dialup and
automatically adjust their terminal type. However, the author finds
it easier at his site to specify vt102 as the
default terminal type, since the users just use VT102 emulation on
their remote systems.After you have made changes to /etc/ttys,
you may send the init process a
HUP signal to re-read the file. You can use the
command &prompt.root; kill -1
1 to send the signal. If this is your
first time setting up the system, though, you may want to wait until
your modem(s) are properly configured and connected before signaling
init.Locked-Speed ConfigFor a locked-speed configuration, your
ttys entry needs to have a fixed-speed entry
provided to getty. For a modem whose port
speed is locked at 19.2 Kbps, the ttys entry
might look like this:
ttyd0 "/usr/libexec/getty std.19200" dialup onIf your modem is locked at a different data rate, substitute
the appropriate name for the
std.speed entry for
std.19200 from
/etc/gettytab for your modem's data
rate.Matching-Speed ConfigIn a matching-speed configuration, your
ttys entry needs to reference the appropriate
beginning “auto-baud” (sic) entry in
/etc/gettytab. For example, if you added the
above suggested entry for a matching-speed modem that starts at
19.2 Kbps (the gettytab entry containing the
V19200 starting point), your
ttys entry might look like this:
ttyd0 "/usr/libexec/getty V19200" dialup on/etc/rc.serial or
/etc/rc.localHigh-speed modems, like V.32, V.32bis, and V.34 modems, need to
use hardware (RTS/CTS) flow control. You can
add stty commands to
/etc/rc.serial on FreeBSD 1.1.5.1 and up, or
/etc/rc.local on FreeBSD 1.1, to set the
hardware flow control flag in the FreeBSD kernel for the modem
ports.For example, on a sample FreeBSD 1.1.5.1 system,
/etc/rc.serial reads:
#!/bin/sh
#
# Serial port initial configuration
stty -f /dev/ttyid1 crtscts
stty -f /dev/cuai01 crtsctsThis sets the termios flag
crtscts on serial port #1's
(COM2:) dialin and dialout initialization
devices.On an old FreeBSD 1.1 system, these entries were added to
/etc/rc.local to set the
crtscts flag on the devices:
# Set serial ports to use RTS/CTS flow control
stty -f /dev/ttyd0 crtscts
stty -f /dev/ttyd1 crtscts
stty -f /dev/ttyd2 crtscts
stty -f /dev/ttyd3 crtsctsSince there is no initialization device special file on FreeBSD
1.1, one has to just set the flags on the sole device special file
and hope the flags are not cleared by a miscreant.Modem SettingsIf you have a modem whose parameters may be permanently set in
non-volatile RAM, you will need to use a terminal program (such as
Telix under PC-DOS or tip under FreeBSD) to set the
parameters. Connect to the modem using the same communications speed
as the initial speed getty will use and configure
the modem's non-volatile RAM to match these requirements:CD asserted when connectedDTR asserted for operation; dropping DTR
hangs up line & resets modemCTS transmitted data flow controlDisable XON/XOFF flow controlRTS received data flow controlQuiet mode (no result codes)No command echoPlease read the documentation for your modem to find out what
commands and/or DIP switch settings you need to give it.For example, to set the above parameters on a USRobotics
Sportster 14,400 external modem, one could give these commands to
the modem:
ATZ
AT&C1&D2&H1&I0&R2&WYou might also want to take this opportunity to adjust other
settings in the modem, such as whether it will use V.42bis and/or MNP5
compression.The USR Sportster 14,400 external modem also has some DIP switches
that need to be set; for other modems, perhaps you can use these
settings as an example:Switch 1: UP — DTR NormalSwitch 2: Do not care (Verbal Result Codes/Numeric Result
Codes)Switch 3: UP — Suppress Result CodesSwitch 4: DOWN — No echo, offline commandsSwitch 5: UP — Auto AnswerSwitch 6: UP — Carrier Detect NormalSwitch 7: UP — Load NVRAM DefaultsSwitch 8: Do not care (Smart Mode/Dumb Mode)Result codes should be disabled/suppressed for dialup modems to
avoid problems that can occur if getty mistakenly
gives a login: prompt to a modem that is in command
mode and the modem echoes the command or returns a result code. I
have heard this sequence can result in a extended, silly conversation
between getty and the modem.Locked-speed ConfigFor a locked-speed configuration, you will need to configure the
modem to maintain a constant modem-to-computer data rate independent
of the communications rate. On a USR Sportster 14,400 external
modem, these commands will lock the modem-to-computer data rate at
the speed used to issue the commands:
ATZ
AT&B1&WMatching-speed ConfigFor a variable-speed configuration, you will need to configure
your modem to adjust its serial port data rate to match the incoming
call rate. On a USR Sportster 14,400 external modem, these commands
will lock the modem's error-corrected data rate to the speed used to
issue the commands, but allow the serial port rate to vary for
non-error-corrected connections:
ATZ
AT&B2&WChecking the Modem's ConfigurationMost high-speed modems provide commands to view the modem's
current operating parameters in a somewhat human-readable fashion.
On the USR Sportster 14,400 external modems, the command
ATI5 displays the settings that are stored in the
non-volatile RAM. To see the true operating parameters of the modem
(as influenced by the USR's DIP switch settings), use the commands
ATZ and then ATI4.If you have a different brand of modem, check your modem's
manual to see how to double-check your modem's configuration
parameters.TroubleshootingHere are a few steps you can follow to check out the dialup modem
on your system.Checking out the FreeBSD systemHook up your modem to your FreeBSD system, boot the system, and,
if your modem has status indication lights, watch to see whether the
modem's DTR indicator lights when the
login: prompt appears on the system's console
— if it lights up, that should mean that FreeBSD has started a
getty process on the appropriate communications
port and is waiting for the modem to accept a call.If the DTR indicator doesn't light, login to
the FreeBSD system through the console and issue a ps
ax to see if FreeBSD is trying to run a
getty process on the correct port. You should see
a lines like this among the processes displayed: 114 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd0
115 ?? I 0:00.10 /usr/libexec/getty V19200 ttyd1If you see something different, like this: 114 d0 I 0:00.10 /usr/libexec/getty V19200 ttyd0and the modem has not accepted a call yet, this means that
getty has completed its open on the
communications port. This could indicate a problem with the cabling
or a mis-configured modem, because getty should
not be able to open the communications port until
CD (carrier detect) has been asserted by the
modem.If you do not see any getty processes waiting
to open the desired
ttyd? port,
double-check your entries in /etc/ttys to see
if there are any mistakes there. Also, check the log file
/var/log/messages to see if there are any log
messages from init or getty
regarding any problems. If there are any messages, triple-check the
configuration files /etc/ttys and
/etc/gettytab, as well as the appropriate
device special files /dev/ttyd?, for any
mistakes, missing entries, or missing device special files.Try Dialing InTry dialing into the system; be sure to use 8 bits, no parity, 1
stop bit on the remote system. If you do not get a prompt right
away, or get garbage, try pressing <Enter>
about once per second. If you still do not see a
login: prompt after a while, try sending a
BREAK. If you are using a high-speed modem to do
the dialing, try dialing again after locking the dialing modem's
interface speed (via AT&B1 on a USR
Sportster, for example).If you still cannot get a login: prompt, check
/etc/gettytab again and double-check
thatThe initial capability name specified in
/etc/ttys for the line matches a name of a
capability in /etc/gettytabEach nx= entry matches another
gettytab capability nameEach tc= entry matches another
gettytab capability nameIf you dial but the modem on the FreeBSD system will not answer,
make sure that the modem is configured to answer the phone when
DTR is asserted. If the modem seems to be
configured correctly, verify that the DTR line is
asserted by checking the modem's indicator lights (if it has
any).If you have gone over everything several times and it still does
not work, take a break and come back to it later. If it still does
not work, perhaps you can send an electronic mail message to the
&a.questions;describing your modem and your problem, and the good
folks on the list will try to help.AcknowledgmentsThanks to these people for comments and advice:&a.kelly;for a number of good suggestionsDialout ServiceInformation integrated from FAQ.The following are tips to getting your host to be able to connect
over the modem to another computer. This is appropriate for
establishing a terminal session with a remote host.This is useful to log onto a BBS.This kind of connection can be extremely helpful to get a file on
the Internet if you have problems with PPP. If you need to ftp
something and PPP is broken, use the terminal session to ftp it. Then
use zmodem to transfer it to your machine.Why cannot I run tip or
cu?On your system, the programs tip and
cu are probably executable only by
uucp and group dialer. You
can use the group dialer to control who has
access to your modem or remote systems. Just add yourself to group
dialer.Alternatively, you can let everyone on your system run
tip and cu by typing:&prompt.root; chmod 4511 /usr/bin/tipYou do not have to run this command for cu,
since cu is just a hard link to
tip.My stock Hayes modem is not supported, what can I do?Actually, the man page for tip is out of date.
There is a generic Hayes dialer already built in. Just use
at=hayes in your /etc/remote
file.The Hayes driver is not smart enough to recognize some of the
advanced features of newer modems—messages like
BUSY, NO DIALTONE, or
CONNECT 115200 will just confuse it. You should
turn those messages off when you use tip (using
ATX0&W).Also, the dial timeout for tip is 60 seconds.
Your modem should use something less, or else tip will think there is
a communication problem. Try ATS7=45&W.Actually, as shipped tip does not yet support
it fully. The solution is to edit the file
tipconf.h in the directory
/usr/src/usr.bin/tip/tip Obviously you need the
source distribution to do this.Edit the line #define HAYES 0 to
#define HAYES 1. Then make and
make install. Everything works nicely after
that.How am I expected to enter these AT commands?Make what is called a “direct” entry in your
/etc/remote file. For example, if your modem is
hooked up to the first serial port, /dev/cuaa0,
then put in the following line:
cuaa0:dv=/dev/cuaa0:br#19200:pa=noneUse the highest bps rate your modem supports in the br capability.
Then, type tip cuaa0 and you will be connected to
your modem.If there is no /dev/cuaa0 on your system, do
this:&prompt.root; cd /dev
&prompt.root; MAKEDEV cuaa0Or use cu as root with the following command:&prompt.root; cu -lline -sspeedline is the serial port
(e.g./dev/cuaa0) and
speed is the speed
(e.g.57600). When you are done entering the AT
commands hit ~. to exit.The @ sign for the pn capability does not
work!The @ sign in the phone number capability tells
tip to look in /etc/phones for a phone number.
But the @ sign is also a special character in
capability files like /etc/remote. Escape it
with a backslash:
pn=\@How can I dial a phone number on the command line?Put what is called a “generic” entry in your
/etc/remote file. For example:
tip115200|Dial any phone number at 115200 bps:\
:dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
tip57600|Dial any phone number at 57600 bps:\
:dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:Then you can things like:&prompt.root; tip -115200 5551234If you prefer cu over tip,
use a generic cu entry:
cu115200|Use cu to dial any number at 115200bps:\
:dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:and type:&prompt.root; cu 5551234 -s 115200Do I have to type in the bps rate every time I do that?Put in an entry for tip1200 or
cu1200, but go ahead and use whatever bps rate is
appropriate with the br capability. tip thinks a
good default is 1200 bps which is why it looks for a
tip1200 entry. You do not have to use 1200 bps,
though.I access a number of hosts through a terminal server.Rather than waiting until you are connected and typing
CONNECT <host> each time, use tip's
cm capability. For example, these entries in
/etc/remote:
pain|pain.deep13.com|Forrester's machine:\
:cm=CONNECT pain\n:tc=deep13:
muffin|muffin.deep13.com|Frank's machine:\
:cm=CONNECT muffin\n:tc=deep13:
deep13:Gizmonics Institute terminal server:\
:dv=/dev/cua02:br#38400:at=hayes:du:pa=none:pn=5551234:will let you type tip pain or tip
muffin to connect to the hosts pain or muffin; and
tip deep13 to get to the terminal server.Can tip try more than one line for each site?This is often a problem where a university has several modem lines
and several thousand students trying to use them...Make an entry for your university in
/etc/remote and use @ for the
pn capability:
big-university:\
:pn=\@:tc=dialout
dialout:\
:dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:Then, list the phone numbers for the university in
/etc/phones:
big-university 5551111
big-university 5551112
big-university 5551113
big-university 5551114tip will try each one in the listed order, then
give up. If you want to keep retrying, run tip in
a while loop.Why do I have to hit CTRL+P twice to send CTRL+P once?CTRL+P is the default “force” character, used to tell
tip that the next character is literal data. You
can set the force character to any other character with the
~s escape, which means “set a
variable.”Type
~sforce=single-char
followed by a newline. single-char is any
single character. If you leave out
single-char, then the force character is
the nul character, which you can get by typing CTRL+2 or CTRL+SPACE.
A pretty good value for single-char is
SHIFT+CTRL+6, which I have seen only used on some terminal
servers.You can have the force character be whatever you want by
specifying the following in your $HOME/.tiprc
file:
force=<single-char>Suddenly everything I type is in UPPER CASE??You must have pressed CTRL+A, tip's
“raise character,” specially designed for people with
broken caps-lock keys. Use ~s as above and set the
variable raisechar to something reasonable. In
fact, you can set it to the same as the force character, if you never
expect to use either of these features.Here is a sample .tiprc file perfect for Emacs users who need to
type CTRL+2 and CTRL+A a lot:
force=^^
raisechar=^^The ^^ is SHIFT+CTRL+6.How can I do file transfers with tip?If you are talking to another UNIX system, you can send and
receive files with ~p (put) and
~t (take). These commands run
cat and echo on the remote
system to accept and send files. The syntax is:~plocal-fileremote-file~tremote-filelocal-fileThere is no error checking, so you probably should use another
protocol, like zmodem.How can I run zmodem with tip?To receive files, start the sending program on the remote end.
Then, type ~C rz to begin receiving them
locally.To send files, start the receiving program on the remote end.
Then, type ~C sz files
to send them to the remote system.Setting Up the Serial Console&a.yokota; and &a.wpaul:The text is heavily based on
/sys/i386/boot/biosboot/README.serial written by
&a.wpaul;.IntroductionThe FreeBSD/i386 operating system can boot on a system with only
a dumb terminal on a serial port as a console. Such a configuration
should be useful for two classes of people; system administrators who
wish to install FreeBSD on a dedicated file/compute/terminal server
machines that have no keyboard or monitor attached, and developers who
want to debug the kernel or device drivers.Starting from version 3.1, FreeBSD/i386 employs a three stage
bootstrap. The first two stages are in the boot block code which is
stored at the beginning of the FreeBSD slice on the boot disk. The
boot block will then load and run the boot loader
(/boot/loader) as the third stage code. (See
&man.boot.8; and &man.loader.8; for more details on the boot
process.)In order to set up the serial console you must configure the boot
block code, the boot loader code and the kernel.In FreeBSD version 3.0, the boot loader does not exist and there
are only two stages in the bootstrap; the boot blocks directly load
the kernel into memory. If you are using FreeBSD 3.0, then you should
disregard any reference to the boot loader in this section. You can
still use the serial port as a console.FreeBSD versions 2.X are quite different from 3.X, in that the
serial port driver, &man.sio.4;, must be configured in a different
way. This chapter will not describe the settings for version 2.X
systems. If you are using these older versions of FreeBSD, please
consult /sys/i386/boot/biosboot/README.serial
instead.6 Steps to Set up the Serial ConsolePrepare a serial cable.You will need either a null-modem cable or a standard serial
cable and a null-modem adapter. See for
a discussion on serial cables.Unplug your keyboard.Most PC systems probe for the keyboard during the Power-On
Self-Test (POST) and will generate an error if the keyboard is not
detected. Some machines complain loudly about the lack of a
keyboard and will not continue to boot until it is plugged
in.If your computer complains about the error, but boots anyway,
then you do not have to do anything special. (One machine with a
Phoenix BIOS that I have here merely says Keyboard
failed then continues to boot normally.)If your computer refuses to boot without a keyboard attached
then you will have to configure the BIOS so that it ignores this
error (if it can). Consult your motherboard's manual for details
on how to do this.Setting the keyboard to “Not installed” in the
BIOS setup does not mean that you will not
be able to use your keyboard. All this does is tell the BIOS
not to probe for a keyboard at power-on so that it will not
complain if the keyboard is not plugged in. You can leave the
keyboard plugged in even with this flag set to “Not
installed” and the keyboard will still work.If your system has a PS/2 mouse, chances are very good that
you may have to unplug your mouse as well as your keyboard.
This is because PS/2 mice share some hardware with the keyboard,
and leaving the mouse plugged in can fool the keyboard probe
into thinking the keyboard is still there. It is said that a
Gateway 2000 Pentium 90Mhz system with an AMI BIOS that behaves
this way. In general this is not a problem since the mouse is
not much good without the keyboard anyway.Plug a dumb terminal into COM1:
(sio0).If you do not have a dumb terminal, you can use an old PC/XT
with a modem program, or the serial port on another UNIX box. If
you do not have a COM1:
(sio0), get one. At this time, there is
no way to select a port other than COM1:
for the boot blocks without recompiling the boot blocks. If you
are already using COM1: for another
device, you will have to temporarily remove that device and
install a new boot block and kernel once you get FreeBSD up and
running. (It is assumed that COM1: will
be available on a file/compute/terminal server anyway; if you
really need COM1: for something else
(and you can not switch that something else to
COM2: (sio1)),
then you probably should not even be bothering with all this in
the first place.)Make sure the configuration file of your kernel has
appropriate flags set for COM1:
(sio0).Relevant flags are:0x10Enables console support for this unit. The other
console flags are ignored unless this is set. Currently, at
most one unit can have console support; the first one (in
config file order) with this flag set is preferred. This
option alone will not make the serial port the console. Set
the following flag or use the option
described below, together with this flag.0x20Forces this unit to be the console (unless there is
another higher priority console), regardless of the
option discussed below. This flag
replaces the COMCONSOLE option in FreeBSD
versions 2.X. The flag 0x20 must be used
together with the flag.0x40Reserves this unit (in conjunction with
0x10) and makes the unit unavailable for
normal access. You should not set this flag to the serial
port unit which you want to use as the serial console. The
only use of this flag is to designate the unit for kernel
remote debugging. See for more
information on remote debugging.In FreeBSD 4.0-CURRENT or later the semantics of the
flag 0x40 are slightly different and
there is another flag to specify a serial port for remote
debugging.Example:
device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4See &man.sio.4; for more details.If the flags were not set, you need to run UserConfig (on a
different console) or recompile the kernel.Create boot.config in the root directory
of the a partition on the boot drive.This file will instruct the boot block code how you would like
to boot the system. In order to activate the serial console, you
need one or more of the following options—if you want
multiple options, include them all on the same line:Toggles internal and serial consoles. You can use this
to switch console devices. For instance, if you boot from
the internal (video) console, you can use
to direct the boot loader and the kernel
to use the serial port as its console device. Alternatively,
if you boot from the serial port, you can use the
to tell the boot loader and the kernel
to use the video display as the console instead.Toggles single and dual console configurations. In the
single configuration the console will be either the internal
console (video display) or the serial port, depending on the
state of the option above. In the dual
console configuration, both the video display and the
serial port will become the console at the same time,
regardless of the state of the option.
However, that the dual console configuration takes effect
only during the boot block is running. Once the boot loader
gets control, the console specified by the
option becomes the only console.Makes the boot block probe the keyboard. If no keyboard
is found, the and
options are automatically set.Due to space constraints in the current version of the
boot blocks, the option is capable of
detecting extended keyboards only. Keyboards with less
than 101 keys (and without F11 and F12 keys) may not be
detected. Keyboards on some laptop computers may not be
properly found because of this limitation. If this is to
be the case with your system, you have to abandon using
the option. Unfortunately there is no
workaround for this problem.Use either the option to select the
console automatically, or the option to
activate the serial console.You may include other options described in &man.boot.8; as
well.The options, except for , will be passed to
the boot loader (/boot/loader). The boot
loader will determine which of the internal video or the serial
port should become the console by examining the state of the
option alone. This means that if you specify
the option but not the
option in /boot.config, you can use the
serial port as the console only during the boot block; the boot
loader will use the internal video display as the console.Boot the machine.When you start your FreeBSD box, the boot blocks will echo the
contents of /boot.config to the console. For
example;/boot.config: -P
Keyboard: noThe second line appears only if you put in
/boot.config and indicates presence/absence
of the keyboard. These messages go to either serial or internal
console, or both, depending on the option in
/boot.config.OptionsMessage goes tononeinternal consoleserial consoleserial and internal consolesserial and internal consoles, keyboard presentinternal console, keyboard absentserial consoleAfter the above messages, there will be a small pause before
the boot blocks continue loading the boot loader and before any
further messages printed to the console. Under normal
circumstances, you do not need to interrupt the boot blocks, but
you may want to do so in order to make sure things are set up
correctly.Hit any key, other than Enter/Return, at the console to
interrupt the boot process. The boot blocks will then prompt you
for further action. You should now see something like:>> FreeBSD/i386 BOOT
Default: 0:wd(0,a)/boot/loader
boot:Verify the above message appears on either the serial or
internal console or both, according to the options you put in
/boot.config. If the message appears in the
correct console, hit Enter/Return to continue the boot
process.If you want the serial console but you do not see the prompt
on the serial terminal, something is wrong with your settings. In
the meantime, you enter and hit Enter/Return
(if possible) to tell the boot block (and then the boot loader and
the kernel) to choose the serial port for the console. Once the
system is up, go back and check what went wrong.After the boot loader is loaded and you are in the third stage of
the boot process you can still switch between the internal console and
the serial console by setting appropriate environment variables in the
boot loader. See .SummaryHere is the summary of various settings discussed in this section
and the console eventually selected.Case 1: You set the flags to 0x10 for sio0device sio0 at isa? port "IO_COM1" tty flags 0x10 irq 4Options in /boot.configConsole during boot blocksConsole during boot loaderConsole in kernelnothinginternalinternalinternalserialserialserialserial and internalinternalinternalserial and internalserialserial, keyboard presentinternalinternalinternal, keyboard absentserial and internalserialserialCase 2: You set the flags to 0x30 for sio0device sio0 at isa? port "IO_COM1" tty flags 0x30 irq 4Options in /boot.configConsole during boot blocksConsole during boot loaderConsole in kernelnothinginternalinternalserialserialserialserialserial and internalinternalserialserial and internalserialserial, keyboard presentinternalinternalserial, keyboard absentserial and internalserialserialTips for the Serial ConsoleSetting A Faster Serial Port SpeedBy default the serial port settings are set to 9600 baud, 8
bits, no parity, 1 stop bit. If you wish to change the speed, you
need to recompile at least the boot blocks. Add the following line
to /etc/make.conf and compile new boot
blocks:BOOT_COMCONSOLE_SPEED=19200If the serial console is configured in some other way than by
booting with , or if the serial console used by
the kernel is different from the one used by the boot blocks, then
you must also add the following option to the kernel configuration
file and compile a new kernel:options CONSPEED=19200Using Serial Port Other Than sio0 For
The ConsoleUsing a port other than sio0 as the
console requires some recompiling. If you want to use another
serial port for whatever reasons, recompile the boot blocks, the
boot loader and the kernel as follows.Get the kernel source.Edit /etc/make.conf and set
BOOT_COMCONSOLE_PORT to the address of the
port you want to use (0x3F8, 0x2F8, 0x3E8 or 0x2E8). Only
sio0 through
sio3 (COM1:
through COM4:) can be used; multiport
serial cards will not work. No interrupt setting is
needed.Create a custom kernel configuration file and add
appropriate flags for the serial port you want to use. For
example, if you want to make sio1
(COM2:) the console:device sio1 at isa? port "IO_COM2" tty flags 0x10 irq 3ordevice sio1 at isa? port "IO_COM2" tty flags 0x30 irq 3The console flags for the other serial ports should not be
set.Recompile and install the boot blocks:&prompt.root; cd /sys/boot/i386/boot2
&prompt.root; make
&prompt.root; make installRecompile and install the boot loader:&prompt.root; cd /sys/boot/i386/loader
&prompt.root; make
&prompt.root; make installRebuild and install the kernel.Write the boot blocks to the boot disk with
&man.disklabel.8; and boot from the new kernel.Entering the DDB Debugger from the Serial LineIf you wish to drop into the kernel debugger from the serial
console (useful for remote diagnostics, but also dangerous if you
generate a spurious BREAK on the serial port!) then you should
compile your kernel with the following options:options BREAK_TO_DEBUGGER
options DDBGetting a Login Prompt on the Serial ConsoleWhile this is not required, you may wish to get a
login prompt over the serial line, now that you
can see boot messages and can enter the kernel debugging session
through the serial console. Here is how to do it.Open the file /etc/ttys with an editor
and locate the lines:ttyd0 "/usr/libexec/getty std.9600" unknown off secure
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
ttyd2 "/usr/libexec/getty std.9600" unknown off secure
ttyd3 "/usr/libexec/getty std.9600" unknown off securettyd0 through ttyd3
corresponds to COM1 through
COM4. Change off to
on for the desired port. If you have changed the
speed of the serial port, you need to change
std.9600 to match the current setting, e.g.
std.19200.You may also want to change the terminal type from
unknown to the actual type of your serial
terminal.After editing the file, you must kill -HUP 1
to make this change take effect.Changing Console from the Boot LoaderPrevious sections described how to set up the serial console by
tweaking the boot block. This section shows that you can specify the
console by entering some commands and environment variables in the
boot loader. As the boot loader is invoked as the third stage of the
boot process, after the boot block, the settings in the boot loader
will override the settings in the boot block.Setting Up the Serial ConsoleYou can easily specify the boot loader and the kernel to use the
serial console by writing just one line in
/boot/loader.rc:set console=comconsoleThis will take effect regardless of the settings in the boot
block discussed in the previous section.You had better put the above line as the first line of
/boot/loader.rc so as to see boot messages on
the serial console as early as possible.Likewise, you can specify the internal console as:set console=vidconsoleIf you do not set the boot loader environment variable
console, the boot loader, and subsequently the
kernel, will use whichever console indicated by the
option in the boot block.In versions 3.2 or later, you may specify the console in
/boot/loader.conf.local or
/boot/loader.conf, rather than in
/boot/loader.rc. In this method your
/boot/loader.rc should look like:include /boot/loader.4th
startThen, create /boot/loader.conf.local and
put the following line there.console=comconsoleorconsole=vidconsoleSee &man.loader.conf.5; for more information.At the moment, the boot loader has no option equivalent to the
option in the boot block, and there is no
provision to automatically select the internal console and the
serial console based on the presence of the keyboard.Using Serial Port Other than sio0 for
the ConsoleYou need to recompile the boot loader to use a serial port other
than sio0 for the serial console. Follow the
procedure described in .CaveatsThe idea here is to allow people to set up dedicated servers that
require no graphics hardware or attached keyboards. Unfortunately,
while (most?) every system will let you boot without a keyboard, there
are quite a few that will not let you boot without a graphics adapter.
Machines with AMI BIOSes can be configured to boot with no graphics
adapter installed simply by changing the `graphics adapter' setting in
the CMOS configuration to `Not installed.'However, many machines do not support this option and will refuse
to boot if you have no display hardware in the system. With these
machines, you'll have to leave some kind of graphics card plugged in,
(even if it's just a junky mono board) although you will not have to
attach a monitor into it. You might also try installing an AMI
BIOS.
diff --git a/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml b/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
index f9e8e1acee..5f632f1708 100644
--- a/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/staff/chapter.sgml
@@ -1,933 +1,933 @@
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 specific
areas of the FreeBSD project landscape.(in alphabetical order by last name):&a.asami;&a.jmb;&a.ache;&a.bde;&a.gibbs;&a.dg;&a.jkh;&a.phk;&a.rich;&a.gpalmer;&a.jdp;&a.dfr;&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 are
also developers.&a.ugen;&a.dbaker;&a.mbarkah;&a.stb;&a.pb;&a.abial;&a.jb;&a.torstenb;&a.dburr;&a.charnier;&a.luoqi;&a.ejc;&a.kjc;&a.gclarkii;&a.archie;&a.chris;&a.alc;&a.cracauer;&a.adam;&a.dillon;&a.mdodd;&a.dufault;&a.uhclem;&a.tegge;&a.deischen;&a.eivind;&a.julian;&a.rse;&a.ru;&a.se;&a.jasone;&a.sef;&a.green;&a.fenner;&a.jfieber;&a.jfitz;&a.scrappy;&a.lars;&a.dirk;&a.shige;&a.billf;&a.gallatin;&a.tg;&a.brandon;&a.graichen;&a.cg;&a.jgreco;&a.rgrimes;&a.jmg;&a.hanai;&a.mharo;&a.thepish;&a.jhay;&a.sheldonh;&a.helbig;&a.ghelmer;&a.erich;&a.nhibma;&a.flathill;&a.hosokawa;&a.hsu;&a.foxfair;&a.tom;&a.mph;&a.shin;&a.itojun;&a.iwasaki;&a.mjacob;&a.gj;&a.nsj;&a.ljo;&a.kato;&a.andreas;&a.motoyuki;&a.jkoshy;&a.kuriyama;&a.grog;&a.jlemon;&a.truckman;&a.lile;&a.kevlo;&a.imp;&a.jmacd;&a.smace;&a.gehenna;&a.mckay;&a.mckusick;&a.ken;&a.hm;&a.tedm;&a.jim;&a.marcel;&a.amurai;&a.markm;&a.max;&a.newton;&a.rnordier;&a.davidn;&a.obrien;&a.danny;&a.ljo;&a.fsmp;&a.smpatel;&a.wpaul;&a.alfred;&a.wes;&a.cpiazza;&a.steve;&a.mpp;&a.jraynard;&a.darrenr;&a.csgr;&a.martin;&a.paul;&a.roberto;&a.chuckr;&a.guido;&a.dima;&a.sada;&a.nsayer;&a.wosch;&a.ats;&a.dick;&a.jseger;&a.simokawa;&a.vanilla;&a.msmith;&a.des;&a.brian;&a.mks;&a.stark;&a.karl;&a.sumikawa;&a.nyan;&a.tanimura;&a.taoka;&a.dt;&a.cwt;&a.pst;&a.hoek;&a.nectar;&a.swallace;&a.dwhite;&a.nate;&a.yokota;&a.jmz;The FreeBSD Documentation ProjectThe 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
+ Documentation Project Architect&a.nik;Webmaster&a.wosch;Handbook & FAQ Editor&a.faq;News Editor&a.nsj;Deputy: &a.john;In the Press Editor&a.jkoshyFreeBSD Really-Quick NewsLetter EditorChris Coleman chrisc@vmunix.comGallery Editor&a.nsj;Deputy: &a.cawimm;Commercial Editor&a.nik;Web Changes Editor-User Groups Editor-LinuxDoc to DocBook conversion&a.nik;Who Is Responsible for WhatPrincipal Architect&a.dg;Documentation
Project Manager&a.nik;Internationalization&a.ache;Networking&a.wollman;Postmaster&a.jmb;Release Coordinator&a.jkh;Public Relations & Corporate Liaison&a.jkh;Security
Officer&a.imp;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;Webmaster&a.wosch;
diff --git a/en_US.ISO_8859-1/books/handbook/x11/chapter.sgml b/en_US.ISO_8859-1/books/handbook/x11/chapter.sgml
index 19bfa17e1c..c63032cdd1 100644
--- a/en_US.ISO_8859-1/books/handbook/x11/chapter.sgml
+++ b/en_US.ISO_8859-1/books/handbook/x11/chapter.sgml
@@ -1,25 +1,25 @@
The X Window SystemPending the completion of this section, please refer to documentation
supplied by the The XFree86 Project,
Inc.